Обсяги 16 ТБ та SNMP у Windows

Оскільки обсяги, що перевищують 16 ТБ, стали більш поширеними, було визнано, що значення 32 біт, яке використовується для повідомлення про розмір та використання диска в межах стандартного "HOST-RESOURCES" MIB в SNMP, було недостатньо великим, щоб повідомити про належний розмір диска.

Схоже, Net-SNMP вирішив це питання, просто маніпулюючи значенням "AllocationUnits", щоб підтримувати 32-бітове значення для використання диска (оскільки загальний розмір / використання диска дорівнює 32-бітовому просторовому значенню, відміченому одиницею розподілу), щоб дозволити для розрахунку обсягу більше 8/16 ТБ. Якщо припустити, що ви не маєте жодного інтересу до звітування в одиниці розподілу, і ви добре з невеликим рівнем неточності. це здається елегантним рішенням.

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

Однак, віконний вбудований сервіс SNMP, як видається, продовжує страждати від цієї помилки, просто повідомляючи про модуль використовуваного / призначеного дискового простору, в результаті чого неточні звіти про розмір диска.

Чи є спосіб увімкнути Windows правильно повідомляти про використання диска для обсягів понад 16 ТБ? Ми намагалися просто встановити Net-SNMP 5.5 x64 та повністю відключити службу Windows SNMP, однак це, на жаль, не вирішило нашу проблему.

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

Ці результати однакові незалежно від того, використовуємо ми службу ванільного Windows SNMP чи NetSNMP.

Я бачив, як люди в громаді кактусів згадують про просто розробка рішення. На жаль, ми використовуємо Observium для швидкого та базового моніторингу систем. Якщо проблему не вдається виправити на стороні Вікна, чи може Обсервіум зробити звіт про власні MIB?

- Оновлення -

Розглядаючи згадку звіту про помилку щодо додавання "realStorageUnits" до файлу snmpd.conf, під час встановлення цієї директиви у нас виникла наступна проблема:

- Оновлення 2 -

Ну, після довгого майстерності, він не схожий ні на одну з версій Windows Net-SNMP, як на директиву "realStorageUnits". Включення директиви призводить до попередження при запуску SNMP. Ми приміряли версії 5.5, 5.6 та 5.7. Хтось тут коли-небудь придумав, як змусити SNMP повідомляти про 16+ томів ТБ у Windows?

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

З Буграпорту Редхат # 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/

Вони розширюють агент SNMP Windows, щоб подолати обмеження Microsoft для деяких своїх OID. Я використовую його разом із Zenoss, щоб отримати більш точне використання процесора та номери пам’яті, і є хороший шанс, що це обійдеться навколо вашої проблеми, але я не можу сказати напевно.