Olá a todos! Com este artigo, AERODISK abre um blog no Habré. Viva, camaradas!
Artigos anteriores no Habré discutiram questões sobre a arquitetura e configuração básica dos sistemas de armazenamento. Neste artigo, consideraremos uma questão que não foi abordada anteriormente, mas é frequentemente questionada - sobre a tolerância a falhas dos sistemas de armazenamento AERODISK ENGINE. Nossa equipe fará de tudo para garantir que o sistema de armazenamento AERODISK pare de funcionar, ou seja, quebrá-lo.
Acontece que já estão pendurados no Habré artigos sobre a história da nossa empresa, sobre os nossos produtos, bem como um exemplo de implementação bem sucedida, para o qual Muito obrigado aos nossos parceiros - empresas TS Solution e Softline.
Portanto, não treinarei aqui habilidades de gerenciamento de copiar e colar, mas simplesmente fornecerei links para os originais destes artigos:
Também quero compartilhar boas notícias. Mas vou começar, é claro, com o problema. Nós, como jovens fornecedores, entre outros custos, enfrentamos constantemente o fato de que muitos engenheiros e administradores simplesmente não sabem como operar adequadamente nosso sistema de armazenamento.
É claro que o gerenciamento da maioria dos sistemas de armazenamento parece aproximadamente o mesmo do ponto de vista de um administrador, mas cada fabricante tem suas próprias características. E não somos exceção aqui.
Portanto, para simplificar a tarefa de formar especialistas em informática, decidimos dedicar este ano ao ensino gratuito. Para isso, estamos abrindo uma rede de Centros de Competência AERODISK em muitas grandes cidades da Rússia, onde qualquer especialista técnico interessado pode fazer um curso totalmente gratuito e receber um certificado na administração de sistemas de armazenamento AERODISK ENGINE.
Em cada Centro de Competência instalaremos um estande de demonstração completo do sistema de armazenamento AERODISK e um servidor físico, no qual nosso professor realizará treinamento presencial. Publicaremos o cronograma de trabalho dos Centros de Competência quando surgirem, mas já abrimos um centro em Nizhny Novgorod e a cidade de Krasnodar é a próxima. Você pode se inscrever no treinamento usando os links abaixo. Aqui estão as informações atualmente conhecidas sobre cidades e datas:
- Nizhny Novgorod (JÁ ABERTO – você pode se inscrever aqui );
Até 16 de abril de 2019, você poderá visitar o centro em qualquer horário de funcionamento, e no dia 16 de abril de 2019 será organizado um grande curso de formação. - Krasnodar (ABERTURA EM BREVE - você pode se inscrever aqui );
De 9 a 25 de abril de 2019, você poderá visitar o centro em qualquer horário de funcionamento, e no dia 25 de abril de 2019 será organizado um grande curso de formação. - Yekaterinburg (ABERTURA EM BREVE, acompanhe as informações em nosso site ou no Habré);
Maio-junho de 2019. - Novosibirsk (acompanhe as informações em nosso site ou no Habré);
Outubro de 2019 - Krasnoyarsk (acompanhe as informações em nosso site ou no Habré);
Novembro de 2019.
E, claro, se Moscou não estiver longe de você, a qualquer momento você poderá visitar nosso escritório em Moscou e passar por um treinamento semelhante.
Todos. Terminamos o marketing, vamos passar para a tecnologia!
No Habré publicaremos regularmente artigos técnicos sobre nossos produtos, testes de carga, comparações, recursos de uso e implementações interessantes.
Testes de colisão do sistema de armazenamento AERODISK ENGINE N2, teste de resistência
AVISO! Depois de ler o artigo, você pode dizer: bem, é claro, o vendedor irá verificar se tudo funciona “com força”, condições de estufa, etc. Eu responderei: nada disso! Ao contrário dos nossos concorrentes estrangeiros, estamos localizados aqui, perto de você, e você sempre pode vir até nós (em Moscou ou em qualquer Comitê Central) e testar nosso sistema de armazenamento de qualquer forma. Assim, não faz muito sentido ajustarmos os resultados a uma imagem ideal do mundo, porque Somos muito fáceis de verificar. Para quem tem preguiça de ir e não tem tempo, podemos organizar testes remotos. Temos um laboratório especial para isso. Contate-nos.
ACHTUNG-2! Este teste não é um teste de carga, porque aqui nos preocupamos apenas com tolerância a falhas. Em algumas semanas prepararemos um estande mais potente e realizaremos testes de carga do sistema de armazenamento, publicando os resultados aqui (aliás, solicitações de testes são aceitas).
Então, vamos quebrar isso.
bancada de teste
Nosso estande é composto pelas seguintes ferragens:
- 1 x sistema de armazenamento Aerodisk Engine N2 (2 controladores, 64 GB de cache, 8 portas FC 8 Gb/s, 4 portas Ethernet 10 Gb/s SFP+, 4 portas Ethernet 1 Gb/s); Os seguintes discos estão instalados no sistema de armazenamento:
- 4 discos SSD SAS de 900 GB;
- 12 discos SAS 10k de 1,2 TB;
- 1 x Servidor físico com Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xportas FC 8Gb/s, 2xportas Ethernet 10Gb/s SFP+);
- 2 interruptores SAN 8G;
- 2 x interruptores LAN 10G;
Conectamos o servidor ao sistema de armazenamento por meio de switches via Ethernet FC e 10G. O diagrama do suporte está abaixo.
Os componentes de que precisamos, como MPIO e iniciador iSCSI, são instalados no Windows Server.
As zonas são configuradas nos switches FC, as VLANs correspondentes são configuradas nos switches LAN e o MTU 9000 é instalado nas portas de armazenamento, switches e host (como fazer tudo isso está descrito em nossa documentação, portanto não descreveremos esse processo aqui).
Metodologia de Teste
O plano de teste de colisão é o seguinte:
- Verificando a falha das portas FC e Ethernet.
- Verificação de falha de energia.
- Verificação de falha do controlador.
- Verificando falha de disco em um grupo/conjunto.
Todos os testes serão realizados sob condições de carga sintética, que iremos gerar pelo programa IOMETER. Paralelamente, realizaremos os mesmos testes, mas sob condições de copiar arquivos grandes para o sistema de armazenamento.
A configuração do IOmeter é a seguinte:
- Ler/Escrever – 70/30
- Bloco – 128k (decidimos lavar os sistemas de armazenamento em blocos grandes)
- Número de threads – 128 (que é muito semelhante à carga produtiva)
- Totalmente Aleatório
- Número de trabalhadores – 4 (2 para FC, 2 para iSCSI)
A prova tem os seguintes objetivos:
- Certifique-se de que o processo sintético de carregamento e cópia não interrompa ou cause erros em vários cenários de falha.
- Certifique-se de que o processo de comutação de portas, controladores, etc. seja suficientemente automatizado e não exija ações do administrador em caso de falhas (ou seja, durante failovers, não estamos falando de failbacks, é claro).
- Certifique-se de que as informações nos logs sejam exibidas corretamente.
Preparando o host e o sistema de armazenamento
Configuramos o acesso em bloco no sistema de armazenamento usando portas FC e Ethernet (FC e iSCSI, respectivamente). O pessoal da TS Solution descreveu detalhadamente como fazer isso em um artigo anterior (). E, claro, ninguém cancelou manuais e cursos.
Montamos um grupo híbrido usando todas as unidades que tínhamos. 2 discos SSD foram adicionados ao cache, 2 discos SSD foram adicionados como uma camada de armazenamento adicional (camada Online). Agrupamos 12 drives SAS10k em RAID-60P (paridade tripla) para verificar a falha de três drives do grupo ao mesmo tempo. Um disco foi deixado para substituição automática.
Conectamos dois LUNs (um via FC e outro via iSCSI).
O proprietário de ambos os LUNs é o controlador Engine-0
Vamos começar o teste
Habilitamos o IOMETER com a configuração acima.
Registramos uma taxa de transferência de 1.8 GB/s e uma latência de 3 milissegundos. Não há erros (contagem total de erros).
Ao mesmo tempo, a partir da unidade local “C” do nosso host, começamos paralelamente a copiar dois arquivos grandes de 100 GB para LUNs de armazenamento FC e iSCSI (unidades E e G no Windows), usando outras interfaces.
Acima está o processo de cópia para LUN FC, abaixo para iSCSI.
Teste nº 1: Desativando portas de E/S
Aproximamo-nos do sistema de armazenamento por trás))) e com um leve movimento da mão retiramos todos os cabos FC e Ethernet 10G do controlador Engine-0. É como se uma faxineira com um esfregão passasse e decidisse lavar o chão exatamente onde estava o ranho e os cabos (ou seja, o controlador ainda funciona, mas as portas de E/S estão desligadas).
Vejamos o IOMETER e a cópia de arquivos. A taxa de transferência caiu para 0,5 GB/s, mas retornou rapidamente ao nível anterior (em cerca de 4 a 5 segundos). Não há erros.
A cópia de arquivos não parou, há uma queda na velocidade, mas não é nada crítica (de 840 MB/s caiu para 720 MB/s). A cópia não parou.
Observamos os logs do sistema de armazenamento e vemos uma mensagem sobre a indisponibilidade de portas e a realocação automática do grupo.
O painel de informações também nos diz que nem tudo está muito bem com as portas FC.
O sistema de armazenamento sobreviveu a uma falha nas portas de E/S com sucesso.
Teste nº 2. Desativando o controlador de armazenamento
Quase imediatamente (depois de reconectar os cabos ao sistema de armazenamento), decidimos finalizar o sistema de armazenamento puxando o controlador para fora do chassi.
Novamente abordamos o sistema de armazenamento por trás (gostamos))) e desta vez retiramos o controlador do Motor-1, que neste momento é o dono do RDG (para o qual o grupo se mudou).
A situação no IOmeter é a seguinte. A E/S parou por cerca de 5 segundos. Os erros não se acumulam.
Após 5 segundos, a E/S foi retomada com aproximadamente a mesma taxa de transferência, mas com latências de 35 milissegundos (latências corrigidas após cerca de alguns minutos). Como pode ser visto nas capturas de tela, o valor da contagem total de erros é 0, ou seja, não houve erros de escrita ou leitura.
Vejamos como copiar nossos arquivos. Como você pode ver, não foi interrompido, houve uma leve queda no desempenho, mas no geral tudo voltou aos mesmos ~800 MB/s.
Entramos no sistema de armazenamento e vemos uma maldição no painel de informações de que o controlador do Engine-1 não está disponível (claro, nós o matamos).
Também vemos uma entrada semelhante nos logs.
O controlador de armazenamento também sobreviveu a uma falha com sucesso.
Teste nº 3: Desconectando a fonte de alimentação.
Por precaução, começamos a copiar os arquivos novamente, mas não paramos o IOMETER.
Puxamos a fonte de alimentação.
Outro alerta foi adicionado ao sistema de armazenamento no painel de informações.
Também no menu de sensores vemos que os sensores associados à fonte de alimentação retirada ficaram vermelhos.
O sistema de armazenamento continua funcionando. A falha da fonte de alimentação não afeta de forma alguma o funcionamento do sistema de armazenamento, do ponto de vista do host, a velocidade de cópia e os indicadores IOMETER permaneceram inalterados.
Teste de falha de energia aprovado com sucesso.
Antes do teste final, decidimos dar um pouco de vida ao sistema de armazenamento, recolocar o controlador e a fonte de alimentação, e também colocar os cabos em ordem, o que o sistema de armazenamento nos informou com alegria com ícones verdes em seu painel de saúde .
Teste nº 4. Falha de três discos em um grupo
Antes deste teste, realizamos uma etapa adicional de preparação. O fato é que o sistema de armazenamento ENGINE oferece algo muito útil - diferentes políticas de reconstrução. A TS Solution escreveu sobre esse recurso anteriormente, mas vamos relembrar sua essência. O administrador de armazenamento pode especificar a prioridade para alocação de recursos durante a reconstrução. Seja na direção do desempenho de E/S, ou seja, a reconstrução demora mais, mas não há redução de desempenho. Ou na direção da velocidade de reconstrução, mas a produtividade será reduzida. Ou uma opção equilibrada. Como o desempenho do armazenamento durante a reconstrução do grupo de discos é sempre uma dor de cabeça para o administrador, testaremos uma política com uma tendência ao desempenho de E/S e às custas da velocidade de reconstrução.
Agora vamos verificar se há falha no disco. Também habilitamos a gravação em LUNs (arquivos e IOMETER). Como temos um grupo com paridade tripla (RAID-60P), isso significa que o sistema deve suportar a falha de três discos, e após a falha a substituição automática deve funcionar, um disco deve ocupar o lugar de um dos com falha. no ODR, e a reconstrução deve começar a partir dele.
Começar. Primeiro, através da interface de armazenamento, vamos destacar os discos que queremos retirar (para não perder e puxar o disco de troca automática).
Verificamos a indicação no hardware. Está tudo bem, vemos três discos destacados.
E retiramos esses três discos.
Vejamos o que há no host. E aí... nada de especial aconteceu.
Os indicadores de cópia (são maiores que no início, porque o cache aqueceu) e o IOMETER não mudam muito ao remover os discos e iniciar a reconstrução (entre 5-10%).
Vejamos o que há no sistema de armazenamento.
Na situação do grupo, vemos que o processo de reestruturação já começou e está próximo de ser concluído.
No esqueleto do RDG você pode ver que 2 discos estão com status vermelho e um já foi substituído. O disco de substituição automática não está mais lá; ele substituiu o terceiro disco com falha. A reconstrução levou vários minutos, a gravação de arquivos quando 3 discos falharam não foi interrompida e o desempenho de E/S não mudou muito.
O teste de falha de disco definitivamente passou com sucesso.
Conclusão
Neste ponto, decidimos acabar com a violência contra os sistemas de armazenamento. Vamos resumir:
- Verificação de falha na porta FC - bem-sucedida
- Verificação de falha na porta Ethernet - bem-sucedida
- Verificação de falha do controlador - bem-sucedida
- Teste de falha de energia - bem-sucedido
- Verificando falha de disco no grouppool - bem-sucedido
Nenhuma das falhas interrompeu a gravação ou causou erros na carga sintética; claro que houve queda de desempenho (e sabemos como superá-lo, o que faremos em breve), mas como se trata de segundos, é bastante aceitável. Conclusão: a tolerância a falhas de todos os componentes do sistema de armazenamento AERODISK funcionou no nível, não houve pontos de falha.
Obviamente, não podemos testar todos os cenários de falha em um artigo, mas tentamos cobrir os mais populares. Portanto, envie seus comentários, sugestões para futuras publicações e, claro, críticas adequadas. Teremos o maior prazer em discutir (ou melhor ainda, venha para o treinamento, duplico a programação por precaução)! Até novos testes!
- Nizhny Novgorod (JÁ ABERTO – você pode se inscrever aqui );
Até 16 de abril de 2019, você poderá visitar o centro em qualquer horário de funcionamento, e no dia 16 de abril de 2019 será organizado um grande curso de formação. - Krasnodar (ABERTURA EM BREVE - você pode se inscrever aqui );
De 9 a 25 de abril de 2019, você poderá visitar o centro em qualquer horário de funcionamento, e no dia 25 de abril de 2019 será organizado um grande curso de formação. - Yekaterinburg (ABERTURA EM BREVE, acompanhe as informações em nosso site ou no Habré);
Maio-junho de 2019. - Novosibirsk (acompanhe as informações em nosso site ou no Habré);
Outubro de 2019 - Krasnoyarsk (acompanhe as informações em nosso site ou no Habré);
Novembro de 2019.
Fonte: habr.com