Volumes de 16 TB e SNMP no Windows

Question

À medida que os volumes maiores que 16 TB se tornaram mais comuns, foi reconhecido que o valor de 32 bits usado para relatar o tamanho e uso do disco dentro da MIB padrão "HOST-RESOURCES" no SNMP não era grande o suficiente para informar o tamanho de disco adequado. / p>

O Net-SNMP parece ter resolvido esse problema simplesmente manipulando o valor de "AllocationUnits" para manter um valor de 32 bits para a utilização do disco (já que o tamanho total do disco / uso é igual ao valor do espaço de 32 bits multiplicado pela unidade de alocação) , para permitir o cálculo de um volume maior que 8 / 16TB. Presumindo que você não tenha nenhum interesse de relatório na unidade de alocação e esteja ok com um pequeno nível de imprecisão. isso parece uma solução elegante.

link

No entanto, o serviço SNMP embutido no Windows parece continuar sofrendo com esse erro, simplesmente relatando o módulo do espaço em disco usado / atribuído, resultando em relatórios de tamanho de disco imprecisos.

Existe uma maneira de permitir que o Windows relate corretamente o uso de disco para volumes acima de 16 TB? Tentamos simplesmente instalar o Net-SNMP 5.5 x64 e desativar totalmente o serviço SNMP do Windows, mas isso infelizmente não resolveu nosso problema.

Ao usar as extensões do NetSNMP, as informações que coletamos para o disco em particular no qual estamos interessados são as seguintes:

Essesresultadossãoosmesmos,independentementedeestarmosusandooserviçoSNMPdoWindowsouoNetSNMP.

EuvipessoasdacomunidadeCactimencionaremsimplesmentecriarumasolução.Infelizmente,estamosusandooObserviumparamonitoramentorápidoebásicodesistemas.Seoproblemanãopudersercorrigidonoladodajanela,oObserviumpodefazerrelatóriosdeMIBspersonalizados?

-Atualizar-

Examinandoamençãoaorelatóriodeerrosdeadicionar"realStorageUnits" ao arquivo snmpd.conf, tivemos o seguinte problema ao definir essa diretiva:

-Atualização2-

Bem,depoisdemuitomexer,nãoparecenenhumadasversõesdoWindowsdoNet-SNMPcomoadiretiva"realStorageUnits". A inclusão da diretiva resulta em um aviso ao iniciar o SNMP. Nós tentamos na versão 5.5, 5.6 e 5.7. Alguém aqui já descobriu como obter o SNMP para relatar 16+ volumes de TB no Windows?

    

Answer 1

Há algum tempo, havia um patch para o Net-SNMP 5.5, que introduziu uma nova opção realStorageUnits para o arquivo de configuração.

Do Redhat Bugreport # 748410 :

To address this issue [negative hrStorageSite values], this update adds a new option to the /etc/snmp/snmpd.conf configuration file, realStorageUnits. By changing the value of this option to 0, users can now enable recalculating all values in hrStorageTable to ensure that the multiplication of hrStorageSize and hrStorageAllocationUnits always produces an accurate device size.

(o texto entre [colchetes] é meu)

Portanto, adicionar a diretiva de configuração realStorageUnits 0 ao seu snmpd.conf pode estar solucionando o seu problema.

No entanto, os valores não estarão corretos até o último megabyte; ymmv.

Não sei se este patch foi incluído na sua distribuição binária de Net-SNMP, mas seria ótimo se você pudesse reportar os resultados e qual binário você está usando. Além disso, não testei a falta de hardware adequado no momento.

    

Answer 2

Eu sei que isso não é uma resposta direta à sua pergunta, mas talvez ajude. Sugiro que você tente entrar em contato com a equipe que cria o SNMP Informant: link

Eles estendem o agente SNMP do Windows para contornar as limitações da Microsoft para alguns dos seus OIDs. Eu o uso com o Zenoss para obter números mais precisos de utilização e armazenamento da CPU e há uma boa chance de que isso funcione em torno do seu problema, mas não posso dizer com certeza.