Qual versão de firmware é a mais “correta” e “funcional”? Se um sistema de armazenamento garante uma tolerância a falhas de 99,9999%, isso significa que funcionará ininterruptamente mesmo sem uma atualização de software? Ou, pelo contrário, para obter a máxima tolerância a falhas, deve sempre instalar o firmware mais recente? Tentaremos responder a essas perguntas com base em nossa experiência.
Pequena introdução
Todos nós entendemos que cada versão de software, seja um sistema operacional ou um driver para um dispositivo, muitas vezes contém defeitos/bugs e outras “funcionalidades” que podem não “aparecer” até o final da vida útil do equipamento, ou “abrir”. apenas sob certas condições. O número e a importância de tais nuances dependem da complexidade (funcionalidade) do software e da qualidade dos testes durante o seu desenvolvimento.
Muitas vezes, os usuários ficam no “firmware de fábrica” (o famoso “funciona, então não mexa”) ou instalam sempre a versão mais recente (no seu entendimento, o mais recente significa o mais funcional). Usamos uma abordagem diferente - analisamos as notas de lançamento de tudo o que é usado equipamento e selecione cuidadosamente o firmware apropriado para cada equipamento.
Chegamos a essa conclusão, como dizem, com experiência. Usando nosso exemplo de operação, diremos por que a confiabilidade prometida de 99,9999% dos sistemas de armazenamento não significa nada se você não monitorar prontamente as atualizações e descrições de software. Nosso case é adequado para usuários de sistemas de armazenamento de qualquer fornecedor, pois situação semelhante pode acontecer com hardware de qualquer fabricante.
Escolhendo um novo sistema de armazenamento
No final do ano passado, um interessante sistema de armazenamento de dados foi adicionado à nossa infraestrutura: um modelo júnior da linha IBM FlashSystem 5000, que na época da compra se chamava Storwize V5010e. Agora é vendido sob o nome FlashSystem 5010, mas na verdade é a mesma base de hardware com o mesmo Spectrum Virtualize dentro.
A presença de um sistema de gerenciamento unificado é, aliás, o principal diferencial do IBM FlashSystem. Para os modelos das séries mais jovens, praticamente não difere dos modelos das mais produtivas. A escolha de um modelo específico fornece apenas a base de hardware adequada, cujas características permitem utilizar uma ou outra funcionalidade ou proporcionar um maior nível de escalabilidade. O software identifica o hardware e fornece as funcionalidades necessárias e suficientes para esta plataforma.
IBM Flash System 5010
Brevemente sobre nosso modelo 5010. Este é um sistema básico de armazenamento em bloco com controlador duplo. Ele pode acomodar discos NLSAS, SAS, SSD. A colocação de NVMe não está disponível nele, pois este modelo de armazenamento está posicionado para solucionar problemas que não requerem o desempenho de drives NVMe.
O sistema de armazenamento foi adquirido para acomodar informações de arquivo ou dados que não são acessados com frequência. Portanto, o conjunto padrão de suas funcionalidades foi suficiente para nós: Tiering (Easy Tier), Thin Provision. O desempenho em discos NLSAS no nível de 1000 a 2000 IOPS também foi bastante satisfatório para nós.
Nossa experiência - como não atualizamos o firmware a tempo
Agora, sobre a atualização do software em si. No momento da compra o sistema já possuía uma versão um pouco desatualizada do software Spectrum Virtualize, a saber, 8.2.1.3.
Estudamos as descrições do firmware e planejamos uma atualização para 8.2.1.9. Se tivéssemos sido um pouco mais eficientes, este artigo não existiria - o bug não teria ocorrido em um firmware mais recente. Porém, por alguns motivos, a atualização deste sistema foi adiada.
Como resultado, um ligeiro atraso na atualização gerou um quadro extremamente desagradável, como na descrição do link: .
Sim, no firmware dessa versão era relevante o chamado APAR (Relatório de Análise de Programa Autorizado) HU02104. Aparece da seguinte forma. Sob carga, sob certas circunstâncias, o cache começa a transbordar e, em seguida, o sistema entra no modo de proteção, no qual desativa a E/S do pool. No nosso caso, parecia desconectar 3 discos para um grupo RAID no modo RAID 6. A desconexão ocorre por 6 minutos. Em seguida, o acesso aos volumes do pool é restaurado.
Se alguém não estiver familiarizado com a estrutura e nomenclatura de entidades lógicas no contexto do IBM Spectrum Virtualize, explicarei brevemente.
Estrutura dos elementos lógicos do sistema de armazenamento
Os discos são coletados em grupos chamados MDisk (Disco Gerenciado). O MDisk pode ser um RAID clássico (0,1,10,5,6) ou virtualizado - DRAID (Distributed RAID). Usar DRAID permite aumentar o desempenho do array, porque... Todos os discos do grupo serão usados e o tempo de reconstrução será reduzido, devido ao fato de que apenas alguns blocos precisarão ser restaurados, e nem todos os dados do disco com falha.
Distribuição de blocos de dados entre discos ao usar RAID distribuído (DRAID) no modo RAID-5.
E este diagrama mostra a lógica de como funciona uma reconstrução DRAID no caso de falha de um disco:
Lógica de reconstrução DRAID quando um disco falha
Em seguida, um ou mais MDisks formam um chamado Pool. Dentro do mesmo conjunto, não é recomendado usar MDisk com diferentes níveis de RAID/DRAID em discos do mesmo tipo. Não vamos entrar nisso muito profundamente, porque... planejamos abordar isso em um dos artigos a seguir. Pois bem, na verdade o Pool é dividido em Volumes, que são apresentados por meio de um ou outro protocolo de acesso de bloco aos hosts.
Então, nós, como resultado da situação descrita em APAR HU02104, devido à falha lógica de três discos, o MDisk deixou de funcionar, o que, por sua vez, resultou na falha do Pool e dos Volumes correspondentes.
Como esses sistemas são bastante inteligentes, eles podem ser conectados ao sistema de monitoramento baseado em nuvem IBM Storage Insights, que envia automaticamente uma solicitação de serviço ao suporte IBM caso ocorra um problema. Uma aplicação é criada e os especialistas da IBM realizam diagnósticos remotamente e entram em contato com o usuário do sistema.
Graças a isso, o problema foi resolvido rapidamente e foi recebida uma recomendação imediata do serviço de suporte para atualizar nosso sistema para o firmware 8.2.1.9 previamente selecionado, que naquele momento já havia sido corrigido. Isso confirma .
Resultados e nossas recomendações
Como diz o ditado: “tudo está bem quando acaba bem”. O bug no firmware não causou problemas sérios - os servidores foram restaurados o mais rápido possível e sem perda de dados. Alguns clientes tiveram que reiniciar máquinas virtuais, mas em geral estávamos preparados para consequências mais negativas, já que fazemos backups diários de todos os elementos da infraestrutura e máquinas clientes.
Recebemos a confirmação de que mesmo sistemas confiáveis com 99,9999% de disponibilidade prometida requerem atenção e manutenção oportuna. Com base na situação, tiramos algumas conclusões e compartilhamos nossas recomendações:
-
É imperativo monitorar o lançamento de atualizações, estudar as Notas de Versão para correções de problemas potencialmente críticos e realizar as atualizações planejadas em tempo hábil.
Este é um ponto organizacional e até bastante óbvio, no qual, ao que parece, não vale a pena focar. No entanto, neste “terreno plano” você pode tropeçar com bastante facilidade. Na verdade, foi esse momento que acrescentou os problemas descritos acima. Tenha muito cuidado ao elaborar os regulamentos de atualização e monitore o cumprimento dos mesmos com o mesmo cuidado. Este ponto está mais relacionado ao conceito de “disciplina”.
-
É sempre melhor manter o sistema com a versão de software mais recente. Além disso, o atual não é aquele que tem uma designação numérica maior, mas sim aquele com data de lançamento posterior.
Por exemplo, a IBM mantém pelo menos duas versões de software atualizadas para seus sistemas de armazenamento. No momento em que este livro foi escrito, eram 8.2 e 8.3. As atualizações para 8.2 são lançadas mais cedo. Uma atualização semelhante para 8.3 geralmente é lançada com um pequeno atraso.
A versão 8.3 tem uma série de vantagens funcionais, por exemplo, a capacidade de expandir o MDisk (no modo DRAID) adicionando um ou mais novos discos (esse recurso apareceu desde a versão 8.3.1). Esta é uma funcionalidade bastante básica, mas no 8.2, infelizmente, não existe tal recurso.
-
Se não for possível atualizar por algum motivo, então para versões do software Spectrum Virtualize anteriores às versões 8.2.1.9 e 8.3.1.0 (onde o bug descrito acima é relevante), para reduzir o risco de sua ocorrência, o suporte técnico da IBM recomenda limitando o desempenho do sistema no nível do pool, conforme mostrado na figura abaixo (a foto foi tirada na versão Russified da GUI). O valor de 10000 IOPS é mostrado como exemplo e é selecionado de acordo com as características do seu sistema.
Limitando o desempenho do armazenamento IBM
-
É necessário calcular corretamente a carga nos sistemas de armazenamento e evitar sobrecargas. Para fazer isso, você pode usar o dimensionador IBM (se tiver acesso a ele) ou a ajuda de parceiros ou recursos de terceiros. É imperativo compreender o perfil de carga no sistema de armazenamento, porque O desempenho em MB/s e IOPS varia muito dependendo de pelo menos os seguintes parâmetros:
-
tipo de operação: leitura ou gravação,
-
tamanho do bloco de operação,
-
porcentagem de operações de leitura e gravação no fluxo total de E/S.
Além disso, a velocidade das operações é afetada pela forma como os blocos de dados são lidos: sequencialmente ou em ordem aleatória. Ao realizar múltiplas operações de acesso a dados no lado da aplicação, existe o conceito de operações dependentes. Também é aconselhável levar isso em consideração. Tudo isso pode ajudar a ver a totalidade dos dados dos contadores de desempenho do SO, sistema de armazenamento, servidores/hipervisores, bem como a compreender as características operacionais de aplicações, SGBDs e outros “consumidores” de recursos de disco.
-
-
E, por fim, certifique-se de ter os backups atualizados e funcionando. A programação de backup deve ser configurada com base em valores de RPO aceitáveis para o negócio, e verificações periódicas de integridade dos backups devem ser verificadas (alguns fornecedores de software de backup têm verificação automatizada implementada em seus produtos) para garantir um valor de RTO aceitável.
Obrigado por ler até o fim.
Estamos prontos para responder suas dúvidas e comentários nos comentários. Também, onde realizamos promoções regulares (descontos em IaaS e brindes para códigos promocionais de até 100% no VPS), escrevemos notícias interessantes e anunciamos novos artigos no blog Habr.
Fonte: habr.com