Windows上的16TB卷和SNMP

随着大于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扩展时，我们为感兴趣的特定磁盘收集的信息如下：

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

我见过仙人掌社区的人们提到只是编写解决方案的脚本。不幸的是，我们使用Observium进行快速和基本的系统监视。如果无法从Window侧解决此问题，是否可以使Observium报告自定义MIB？

- 更新 -

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

- 更新2 -

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

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

来自Redhat Bugreport＃748410：

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

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

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

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

我无法确定此修补程序是否包含在您的Net-SNMP二进制发行版中，但是如果您可以报告结果以及所使用的二进制文件，那就太好了。另外，我现在还没有测试它是否缺少足够的硬件。

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

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