16 ТБ томов и SNMP в Windows

Поскольку объемы больше 16 ТБ стали более распространенными, было признано, что 32-разрядное значение, используемое для отчета о размере диска и использовании в стандартной MIB «HOST-RESOURCES» в SNMP, было недостаточно большим, чтобы сообщить правильный размер диска.

Net-SNMP, кажется, решил эту проблему, просто манипулируя значением «AllocationUnits», чтобы поддерживать 32-битное значение для использования диска (поскольку общий размер / использование диска равно 32-битному значению пространства, умноженному на единицу выделения), чтобы для расчета объема больше 8 / 16TB. Предполагая, что у вас нет отчетного интереса к единице распределения, и все в порядке с небольшой степенью неточности. это похоже на элегантное решение.

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

Однако встроенная в Windows служба SNMP, похоже, продолжает страдать от этой ошибки, просто сообщая по модулю занятого / назначенного дискового пространства, что приводит к неточным отчетам о размере диска.

Есть ли способ, позволяющий Windows правильно сообщать об использовании диска для томов более 16 ТБ? Мы попытались просто установить Net-SNMP 5.5 x64 и полностью отключить службу Windows SNMP, однако, к сожалению, это не решило нашу проблему.

При использовании расширений NetSNMP информация, которую мы собираем для конкретного интересующего нас диска, выглядит следующим образом:

Эти результаты одинаковы, независимо от того, используем ли мы стандартную службу SNMP для Windows или NetSNMP.

Я видел, как люди в сообществе Cacti упоминают просто написание решения. К сожалению, мы используем Observium для быстрого и простого мониторинга систем. Если проблема не может быть исправлена ​​на стороне окна, можно ли сделать Observium для отчета о пользовательских MIB?

- Обновление -

Изучив упоминание в отчете об ошибке о добавлении «realStorageUnits» в файл snmpd.conf, мы столкнулись со следующей проблемой при установке этой директивы:

- Обновление 2 -

Что ж, после долгих попыток он не похож ни на одну из версий Net-SNMP для Windows, как на директиву realStorageUnits. Включение директивы приводит к предупреждению при запуске SNMP. Мы пробовали версии 5.5, 5.6 и 5.7. Кто-нибудь здесь когда-нибудь выяснил, как заставить SNMP сообщать о томах объемом более 16 ТБ в Windows?

Некоторое время назад был патч для Net-SNMP 5.5, который представил новую опцию realStorageUnitsдля файла конфигурации.

Из багрепорта Redhat # 748410 :

Чтобы устранить эту проблему [отрицательные значения hrStorageSite], это обновление добавляет новую опцию в файл конфигурации /etc/snmp/snmpd.conf, realStorageUnits. Изменив значение этого параметра на 0, пользователи теперь могут включить пересчет всех значений в hrStorageTable, чтобы при умножении hrStorageSize и hrStorageAllocationUnits всегда получался точный размер устройства.

(текст в [скобках] мой)

Поэтому добавление директивы конфигурации realStorageUnits 0в ваш snmpd.conf может решить вашу проблему.

Однако значения не будут правильными до самого последнего мегабайта; YMMV.

Я не могу сказать, был ли этот патч включен в ваш бинарный дистрибутив Net-SNMP, но было бы здорово, если бы вы могли сообщить о результатах и ​​какой бинарный файл вы используете. Кроме того, я не проверял это из-за отсутствия адекватного оборудования прямо сейчас.

Я знаю, что это не прямой ответ на ваш вопрос, но, возможно, это поможет. Я предлагаю вам попробовать связаться с командой, которая делает SNMP Informant: http://www.snmp-informant.com/

Они расширяют агент Windows SNMP, чтобы обойти ограничения Microsoft для некоторых из своих OID. Я использую его с Zenoss, чтобы получить более точные данные об использовании процессора и хранилище, и есть большая вероятность, что это обойдет вашу проблему, но я не могу сказать наверняка.