Por que monitorar sistemas de armazenamento?


Alguém vai cair em breve

Porque o SHD armazena o santo dos santos - dados. Se os dados não estiverem mais disponíveis, eles terão um cheiro frito muito em breve. Ou se de repente o lugar acabou - também é uma surpresa desagradável. Portanto, o monitoramento deve ser obrigatório e deve abranger os sistemas de armazenamento.

Existem duas abordagens principais para monitorar o armazenamento . Use um sistema de monitoramento universal como o Nagios, Icinga, que coletará informações via SNMP ou compre software altamente especializado dos fabricantes dos próprios sistemas de armazenamento. Obviamente, a segunda opção fornece uma análise mais profunda do estado do ferro, mostra coisas específicas como o estado do cache, Iops, taxa de acertos, carregamento do controlador etc. Essa é a opção mais frequentemente escolhida pelos nossos clientes, que têm matrizes grandes e caras em serviço. .

A propósito, nem tudo é tão tranquilo com o software de monitoramento comercial. Mais detalhadamente vou contar mais. Será, por assim dizer, uma experiência em primeira mão. Ao mesmo tempo, por quase dois anos, eu estava finalizando um desses sistemas para milhares de pedaços de papel verde de um fornecedor famoso. E ele atendeu para que até o suporte do fornecedor começasse a me consultar. Mas alguns problemas de software foram substituídos por outros, assim como alguns indianos do suporte foram substituídos por novos indianos - e foi então que tive a idéia, se não agir radicalmente ... Em geral, tudo começou com isso.

O que há de errado com o software do fornecedor?


Como eu disse, o monitoramento do fabricante monitora perfeitamente os sistemas de armazenamento do mesmo fabricante. Esta é a sua principal vantagem. As desvantagens crescem a partir daqui: matrizes de outros fabricantes são suportadas de forma limitada ou nenhuma. Acontece que, se você tiver várias matrizes diferentes no farm, precisará de várias ferramentas de monitoramento diferentes. Sim, e não se esqueça de qual e quando e quando precisar analisá-lo na próxima vez. Idealmente, geralmente pelo administrador para cada matriz.

Não é nenhum segredo que as ferramentas dos fabricantes vendem dinheiro e são bastante grandes. E a extensão do suporte também custa um centavo. E alguns fornecedores dominaram um novo foco: anunciam o fim do ciclo de vida de seu software e oferecem simplesmente a compra de outro produto, sem migração de licenças. Essa configuração aconteceu há alguns meses com um de nossos clientes. Não há opções: se você quiser continuar monitorando o hardware - faça uma nova compra.

Se você aprofundar o software do fornecedor, outros recursos desagradáveis ​​serão exibidos. Por exemplo, em vários produtos, você pode ver a imagem do status atual, mas não pode ver o histórico do período anterior. Ou a história é limitada: o log é reescrito a cada 3 dias. Simplesmente não há necessidade de falar sobre o acúmulo de estatísticas. E, muitas vezes, o histórico de eventos é necessário para previsões, por exemplo, a compra de peças de reposição, para relatórios e para investigar incidentes. Por exemplo, os freios de algum sistema comercial podem ser acionados no sistema de armazenamento e, se não houver dados reais, não há nada a esconder.

E, finalmente, não podemos deixar de reclamar da velocidade das atualizações e mudanças no software do fornecedor. Oh, quantas vezes me deparei com esse problema durante minha longa prática! Novos modelos de arrays estão saindo, novos firmwares estão saindo, novas configurações aparecem. Tudo isso interrompe com facilidade o monitoramento de trabalho: ou algum tipo de informação deixa de ser coletado ou as matrizes geralmente caem. Em um novo microcódigo, um fabricante desativou o suporte para versões antigas do SSL e o software de monitoramento ainda não suportava o protocolo TLS. E, a princípio, ninguém conseguiu encontrar uma razão. Após minha própria investigação, enviei essas entradas para o fabricante, e elas já atualizavam as bibliotecas antigas. No entanto, toda essa burocracia durou indefinidamente.

E uma vez que falhamos o piloto no cliente. Foi proposto o uso de software de fornecedores, e o cliente gostou de tudo em termos de funcionalidade e interface. Infelizmente, porém, seus principais sistemas produtivos não eram suportados. Eles estavam prontos para esperar um mês ou dois, mas o fornecedor disse que não há planos para incluir esses sistemas no suporte no futuro próximo (e isso foi apenas uma atualização da linha Hitachi AMS no HUS).

Em geral, muitos inconvenientes e, por algum motivo, muito dinheiro.

Há muito tempo eu não peguei damas ...


Frustrado com esse estado de coisas, sempre pensei em como implementar meu próprio monitoramento de armazenamento. Se você conhece bem a matriz e possui sua CLI, poderá obter rapidamente as informações necessárias sobre o estado ou chegar ao fundo dos problemas. Obviamente, antes disso, é necessário escavar muitas docas, fóruns de fumaça e bases de conhecimento de fornecedores, fragmentando informações diferentes. Mas quando você sabe qual comando digitar com qual chave e o que cada coluna de saída significa, você já é um guru. Restou incorporar esse conhecimento em uma interface conveniente, que continuará a fazer tudo por você.

Admito que a princípio planejei escrever a interface do zero também, mas depois me deparei com o Zabbix - uma ferramenta madura com uma grande comunidade, que também é fácil de expandir. Tinha tudo o que eu precisava: uma interface, um modelo, notificações, um sistema de gatilho, agentes proxy de cliente. Restava apenas a essa combinação fornecer corretamente informações sobre sistemas de armazenamento e valores limite de vários parâmetros. O caso começou a ferver. Temos uma equipe de especialistas em matrizes. Obviamente, é impossível conhecer todas as matrizes por uma pessoa, por isso estamos divididos por modelo e fabricante.

Outra dificuldade no desenvolvimento de seu próprio monitoramento é a capacidade de acessar os próprios pedaços de ferro e para que eles ainda não tenham medo de carregar, quebrar e realizar todo tipo de experimento. Felizmente, os recursos do nosso laboratório permitiram tudo isso.

A primeira coisa a monitorar é a integridade de todos os componentes de hardware. Alguma coisa pode ser feita via SNMP, mas na maioria dos casos, essa é uma pesquisa usando um protocolo especial (SMI-S, API REST, API SOAP e outros). Devo dizer que as próprias matrizes permitem configurar notificações sobre falhas nelas. E todos os clientes usam isso pelo menos. Mas o que acontece se a notificação em si na matriz quebrar? Isso aconteceu, e mais de uma vez, quando a matriz ficou em silêncio por semanas e pareceu a todos que tudo estava em ordem, ficou em silêncio. E, de repente, ficou claro que um número crítico de discos voava nele, mas já era tarde demais.

O segundo ponto importante a ser monitorado é o desempenho. Porque quando uma performance se baseia em um sistema de armazenamento com um atraso de gravação de alguns segundos, o Oracle pode simplesmente subir e descer. Não faço ideia. É o desempenho em grandes infraestruturas com muitos sistemas de armazenamento que é o pior controlado. E o Zabbix possui uma análise preditiva extremamente conveniente: com base na previsão, você pode definir o valor da métrica, que ela se tornará no futuro. Por exemplo, criamos um gatilho que funcionará se houver uma previsão de que haverá apenas 3 meses restantes para o descarte atual. Ou, por exemplo, que o tempo de resposta de acordo com a previsão em duas semanas será maior em 50 milissegundos. O monitoramento nos dá tempo para aprender sobre os problemas futuros com antecedência e fazer algo já.

Em algum momento, percebemos que é bom saber sobre o estado do armazenamento, é claro, mas é muito melhor entender o que mais está acontecendo na rede e no lado do servidor. Como resultado, após vários meses de trabalho, tornou-se possível ver os servidores, a rede e os sistemas de armazenamento em uma interface. Apareceram não apenas plug-ins e conectores para armazenamento, mas também uma ligação útil na forma de mapas de topologia de rede. Até agora, é claro, o plug-in leva em consideração nossa experiência e nossas necessidades, mas se você nos disser o que precisa ver nele, nós o modificaremos.


Topologia de ponta a ponta para o cluster VMware: da máquina virtual ao volume de armazenamento



Desempenho

No gráfico de desempenho da matriz, vemos que o sistema está muito sobrecarregado. A alta utilização de grupos de discos indica que os discos estão sobrecarregados. Existem muitas operações de E / S nas portas de armazenamento, o que significa que os sistemas de TI carregam a matriz por sua parte. Bem, o gráfico característico do tempo de resposta, bem como a utilização de processadores acima dos valores recomendados. Veredicto - muitas tarefas foram colocadas na matriz; algumas delas precisam ser migradas.


Mapa da rede de armazenamento: localizando gargalos

Sumário


O que conseguimos? Equipamos o popular e muito comum sistema de monitoramento Zabbix com novos recursos, incluindo:

  1. Coleta de informações sobre o status de todo o hardware e componentes lógicos das matrizes e comutadores de disco da rede de armazenamento.
  2. Estatísticas de desempenho para absolutamente todos os sistemas para os quais criamos plugins (os fornecedores têm lacunas a esse respeito).
  3. Mapas topológicos de uma rede de armazenamento compartilhada e de ponta a ponta de máquinas virtuais para volumes em sistemas de armazenamento (até agora apenas para VMware).
  4. Coleta de todas as informações de inventário.
  5. A quantidade de espaço em disco.

O próprio Zabbix permite criar notificações muito legais, definir limites, enviar cartas informativas sobre o problema. Por exemplo, se a porta do switch cair (ou o tráfego na porta ficar muito grande), a mensagem conterá não apenas o nome do switch com o número da porta, mas também informações sobre o dispositivo conectado.

Quais sistemas nós suportamos atualmente? Muitos diferentes:

  1. Todas as matrizes da Hitachi (AMS, HUS, VSP, VSP G).
  2. Matrizes Dell-EMC CLARiiON, VNX, Unity, ISILON, Compellent.
  3. Matrizes HPE 3PAR, P9500, XP7.
  4. Matrizes do IBM Storwize, DS5000.
  5. Matrizes NetApp FAS (modo 7, modo c).
  6. HPE StoreOnce, bibliotecas de disco do EMC DataDomain.
  7. Comutadores de bicho-da-seda Brocade, Cisco MDS.

Também temos extensões para alguns sistemas operacionais (Windows, ESX), com os quais coletamos dados no FC HBA para desenhar mapas topológicos no futuro. Desenvolvimento ativo de plugins para OpenStack e sistemas de virtualização.

Ao desenvolver plug-ins, é levada em consideração a experiência de nossos engenheiros, por trás dos quais existem muitos casos para resolver problemas em matrizes - hardware e desempenho. Novos plugins são desenvolvidos sob solicitação em pouco tempo devido ao grande número de bibliotecas prontas.

Alguns de nossos clientes configuram o sistema da seguinte forma: notificações com o número do contrato, pessoas de contato e todos os parâmetros do componente defeituoso são automaticamente enviadas para o nosso correio. Isso reduz o tempo de reação e solicita as peças de reposição necessárias, uma vez que o engenheiro de serviço não precisa chamar e esclarecer muitas informações - mesmo à noite. O aplicativo vai imediatamente para o trabalho.

Como você resolve os problemas de monitoramento de sua infraestrutura, em particular de armazenamento? Conte-nos nos comentários ou na carta ao correio VRyzhevsky@croc.ru

Source: https://habr.com/ru/post/pt413247/


All Articles