Woluminy 16 TB i SNMP w systemie Windows

Ponieważ woluminy większe niż 16 TB stały się bardziej powszechne, uznano, że 32-bitowa wartość użyta do zgłoszenia wielkości dysku i użycia w standardowej MIB „HOST-RESOURCES” w SNMP nie była wystarczająco duża, aby zgłosić właściwy rozmiar dysku.

Wydaje się, że Net-SNMP rozwiązał ten problem, po prostu manipulując wartością „AllocationUnits” w celu utrzymania 32-bitowej wartości wykorzystania dysku (ponieważ całkowity rozmiar / użycie dysku jest równe 32-bitowej wartości przestrzeni razy jednostka alokacji), aby umożliwić do obliczenia objętości większej niż 8/16 TB. Zakładając, że nie masz żadnego zainteresowania raportowaniem w jednostce alokacji i jesteś w porządku z niewielkim poziomem niedokładności. wydaje się to eleganckim rozwiązaniem.

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

Wygląda jednak na to, że system Windows wbudowany w usługę SNMP nadal cierpi z powodu tego błędu, po prostu zgłaszając moduł wykorzystanego / przydzielonego miejsca na dysku, co powoduje niedokładne raportowanie rozmiaru dysku.

Czy istnieje sposób, aby umożliwić systemowi Windows prawidłowe zgłaszanie użycia dysku dla woluminów powyżej 16 TB? Próbowaliśmy po prostu zainstalować Net-SNMP 5.5 x64 i całkowicie wyłączyć usługę Windows SNMP, jednak niestety to nie rozwiązało naszego problemu.

Podczas korzystania z rozszerzeń NetSNMP informacje, które zbieramy dla konkretnego dysku, który nas interesuje, są następujące:

Wyniki są takie same, niezależnie od tego, czy korzystamy z waniliowej usługi Windows SNMP, czy NetSNMP.

Widziałem, jak ludzie ze społeczności Cacti wspominali po prostu o znalezieniu rozwiązania. Niestety używamy Observium do szybkiego i podstawowego monitorowania systemów. Jeśli problemu nie można naprawić po stronie okna, czy można przeprowadzić obserwację w celu zgłoszenia niestandardowych baz MIB?

- Aktualizacja -

Analizując wzmiankę w raporcie o błędzie dotyczącą dodania „realStorageUnits” do pliku snmpd.conf, napotkaliśmy następujący problem podczas ustawiania tej dyrektywy:

- Aktualizacja 2 -

Cóż, po wielu majstrowaniach nie wygląda na żadną z wersji Net-SNMP Windows, jak dyrektywa „realStorageUnits”. Dołączenie dyrektywy powoduje wyświetlenie ostrzeżenia podczas uruchamiania SNMP. Wypróbowaliśmy wersje 5.5, 5.6 i 5.7. Czy ktoś tu kiedykolwiek wymyślił, jak zmusić SNMP do zgłaszania ponad 16 TB woluminów w systemie Windows?

Jakiś czas temu pojawiła się łatka do Net-SNMP 5.5, która wprowadziła nową opcję realStorageUnitsdla pliku konfiguracyjnego.

Z raportu o błędach Redhat # 748410 :

Aby rozwiązać ten problem [ujemne wartości hrStorageSite], ta aktualizacja dodaje nową opcję do pliku konfiguracyjnego /etc/snmp/snmpd.conf, realStorageUnits. Zmieniając wartość tej opcji na 0, użytkownicy mogą teraz włączyć ponowne obliczanie wszystkich wartości w hrStorageTable, aby zapewnić, że mnożenie hrStorageSize i hrStorageAllocationUnits zawsze daje dokładny rozmiar urządzenia.

(tekst w [nawiasach kwadratowych] jest mój)

Tak więc dodanie dyrektywy konfiguracyjnej realStorageUnits 0do pliku snmpd.conf może rozwiązać problem.

Jednak wartości nie będą prawidłowe do ostatniego megabajta; ymmv.

Nie wiem, czy ta łatka została uwzględniona w twojej binarnej dystrybucji Net-SNMP, ale byłoby wspaniale, gdybyś mógł zgłosić wyniki i jakiego binarnego używasz. Ponadto nie testowałem go teraz pod kątem braku odpowiedniego sprzętu.

Wiem, że nie jest to bezpośrednia odpowiedź na twoje pytanie, ale być może pomoże. Proponuję spróbować skontaktować się z zespołem, który tworzy Informator SNMP: http://www.snmp-informant.com/

Rozszerzają one agenta SNMP systemu Windows, aby obejść ograniczenia Microsoftu dotyczące niektórych ich identyfikatorów OID. Używam go z Zenoss, aby uzyskać dokładniejsze wykorzystanie procesora i numery pamięci i istnieje spora szansa, że ​​to obejdzie twój problem, ale nie jestem pewien.