Windows 上的 16TB 卷和 SNMP

Question

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

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

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

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

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

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

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

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

--更新--

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

--更新 2 --

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

Answer 1

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

来自Redhat Bugreport #748410：

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

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

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

然而，直到最后一个兆字节的值都是不正确的；ymmv。

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