2
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以上的卷?