主页 / server / 问题 / 432348
Accepted
Univ426
Asked: 2012-09-27 12:51:23 +0800 CST

Windows 上的 16TB 卷和 SNMP

  • 772

随着大于 16TB 的卷变得越来越普遍，人们认识到用于报告磁盘大小和 SNMP 中标准“HOST-RESOURCES”MIB 中使用情况的 32 位值不足以报告正确的磁盘大小。

Net-SNMP 似乎通过简单地操纵“AllocationUnits”的值来解决这个问题，以维持磁盘利用率的 32 位值（因为总磁盘大小/使用等于 32 位空间值乘以分配单元），以允许用于计算大于 8/16TB 的卷。假设您对分配单位没有任何报告兴趣，并且可以接受少量的不准确。这似乎是一个优雅的解决方案。

https://bugzilla.redhat.com/show_bug.cgi?id=654384

然而，Windows 内置的 SNMP 服务似乎继续遭受此错误的困扰，它只是报告已用/分配的磁盘空间的模数，导致磁盘大小报告不准确。

有没有办法让 Windows 正确报告超过 16TB 的卷的磁盘使用情况？我们试图简单地安装 Net-SNMP 5.5 x64 并完全禁用 Windows SNMP 服务，但遗憾的是这并没有解决我们的问题。

使用 NetSNMP 扩展时，我们为感兴趣的特定磁盘收集的信息如下：

在此处输入图像描述

无论我们使用的是普通 Windows SNMP 服务还是 NetSNMP，这些结果都是相同的。

我见过 Cacti 社区的人提到简单地编写解决方案的脚本。不幸的是，我们正在使用 Observium 进行快速和基本的系统监控。如果问题无法在 Window 方面得到纠正，是否可以让 Observium 报告自定义 MIB？

--更新--

查看错误报告中提到的将“realStorageUnits”添加到 snmpd.conf 文件中，我们在设置该指令时遇到了以下问题：

realStorageUnits 为我们保驾护航

--更新 2 --

好吧，经过大量修改后，它看起来不像任何 Windows 版本的 Net-SNMP，就像“realStorageUnits”指令一样。包含指令会在启动 SNMP 时产生警告。我们尝试了 5.5、5.6 和 5.7 版本。这里有没有人想出如何让 SNMP 在 Windows 上报告 16+ TB 卷？

windows

2 个回答

  1. Best Answer

    不久前，Net-SNMP 5.5 有一个补丁，它为配置文件引入了一个新选项realStorageUnits。

    来自Redhat 错误报告#748410：

    为解决此问题 [负 hrStorageSite 值]，此更新向 /etc/snmp/snmpd.conf 配置文件 realStorageUnits 添加了一个新选项。通过将此选项的值更改为 0，用户现在可以重新计算 hrStorageTable 中的所有值，以确保 hrStorageSize 和 hrStorageAllocationUnits 的乘积始终产生准确的设备大小。

    （[括号]中的文字是我的）

    因此，将配置指令添加realStorageUnits 0到您的 snmpd.conf 可能会解决您的问题。

    但是，这些值直到最后一个兆字节都是不正确的；嗯。

    我不知道这个补丁是否包含在您的 Net-SNMP 二进制分发版中，但如果您能报告结果和您使用的二进制文件，那就太好了。另外，由于现在没有足够的硬件，我没有测试它。

    • 2

  2. 我知道这不是您问题的直接答案，但也许会有所帮助。我建议您尝试联系制作 SNMP Informant 的团队：http ://www.snmp-informant.com/

    他们扩展了 Windows SNMP 代理以绕过 Microsoft 对其某些 OID 的限制。我将它与 Zenoss 一起使用以获得更准确的 CPU 利用率和存储数量，这很有可能会解决您的问题，但我不能肯定地说。

    • 1

相关问题