Como você se sentiria se em um belo dia de verão o data center com seu equipamento fosse assim?
Olá a todos! Meu nome é Dmitry Samsonov, trabalho como administrador de sistema líder em "" A foto mostra um dos quatro data centers onde estão instalados os equipamentos que atendem ao nosso projeto. Atrás destas paredes existem cerca de 4 mil equipamentos: servidores, sistemas de armazenamento de dados, equipamentos de rede, etc. - quase ⅓ de todos os nossos equipamentos.
A maioria dos servidores são Linux. Existem também várias dezenas de servidores em Windows (MS SQL) - a nossa herança, que temos abandonado sistematicamente há muitos anos.
Assim, em 5 de junho de 2019, às 14h35, engenheiros de um de nossos data centers relataram um alarme de incêndio.
Negação
14:45. Pequenos incidentes com fumaça em data centers são mais comuns do que você imagina. Os indicadores dentro dos corredores estavam normais, então nossa primeira reação foi relativamente calma: proibiram o trabalho com produção, ou seja, qualquer mudança de configuração, lançamento de novas versões, etc., exceto trabalhos relacionados a consertar alguma coisa.
Raiva
Você já tentou descobrir com os bombeiros exatamente onde ocorreu o incêndio no telhado ou subir você mesmo em um telhado em chamas para avaliar a situação? Qual será o grau de confiança nas informações recebidas através de cinco pessoas?
14: 50. Foi recebida informação de que o fogo está se aproximando do sistema de refrigeração. Mas isso virá? O administrador do sistema de plantão remove o tráfego externo das frentes deste data center.
Neste momento, as frentes de todos os nossos serviços estão duplicadas em três data centers, é utilizado o balanceamento ao nível do DNS, o que nos permite retirar os endereços de um data center do DNS, protegendo assim os utilizadores de potenciais problemas de acesso aos serviços . Caso já tenham ocorrido problemas no data center, ele sai do rodízio automaticamente. Você pode ler mais aqui:
O incêndio ainda não nos afetou de forma alguma - nem os utilizadores nem os equipamentos foram danificados. Isso é um acidente? A primeira seção do documento “Plano de Ação para Acidentes” define o conceito de “Acidente”, e a seção termina assim:
«Se houver alguma dúvida se houve acidente ou não, então é acidente!»
14:53. Um coordenador de emergência é nomeado.
O coordenador é quem controla a comunicação entre todos os participantes, avalia a dimensão do acidente, utiliza o Plano de Ação de Emergência, atrai o pessoal necessário, acompanha a conclusão dos reparos e, o mais importante, delega quaisquer tarefas. Em outras palavras, é a pessoa que gerencia todo o processo de resposta a emergências.
Negociação
15:01. Começamos a desabilitar servidores que não estão relacionados à produção.
15:03. Desligamos corretamente todos os serviços reservados.
Isto inclui não apenas fronts (que a esta altura os usuários não acessam mais) e seus serviços auxiliares (lógica de negócios, caches, etc.), mas também vários bancos de dados com fator de replicação 2 ou mais (, , , etc.).
15: 06. Foi recebida informação de que um incêndio está ameaçando uma das salas do data center. Não temos equipamentos nesta sala, mas o fato de o fogo poder se espalhar do telhado para os corredores muda muito a imagem do que está acontecendo.
(Mais tarde descobriu-se que não havia ameaça física ao salão, uma vez que estava hermeticamente vedado do telhado. A ameaça era apenas para o sistema de refrigeração deste salão.)
15h07. Permitimos a execução de comandos em servidores em modo acelerado sem verificações adicionais ().
15:08. A temperatura nos corredores está dentro dos limites normais.
15: 12. Foi registrado aumento de temperatura nos corredores.
15:13. Mais da metade dos servidores do data center estão desligados. Vamos continuar.
15:16. Foi tomada a decisão de desligar todos os equipamentos.
15:21. Começamos a desligar a energia dos servidores sem estado sem desligar corretamente o aplicativo e o sistema operacional.
15:23. É alocado um grupo de responsáveis pelo MS SQL (são poucos, a dependência dos serviços deles não é grande, mas o procedimento de restauração da funcionalidade é mais demorado e mais complicado do que, por exemplo, Cassandra).
Depressão
15: 25. Foram recebidas informações sobre o corte de energia em quatro dos 16 salões (nº 6, 7, 8, 9). Nossos equipamentos estão localizados nos corredores 7 e 8. Não há informações sobre nossos dois salões (nº 1 e 3).
Normalmente, durante incêndios, a fonte de alimentação é desligada imediatamente, mas neste caso, graças ao trabalho coordenado dos bombeiros e do pessoal técnico do data center, ela não foi desligada em todos os lugares e não imediatamente, mas conforme necessário.
(Mais tarde foi descoberto que a energia não foi desligada nos corredores 8 e 9.)
15:28. Estamos começando a implantar bancos de dados MS SQL a partir de backups em outros data centers.
Quanto tempo vai demorar? Existe capacidade de rede suficiente para todo o percurso?
15: 37. Foi registrado desligamento de alguns pontos da rede.
A gestão e a rede de produção estão fisicamente isoladas uma da outra. Se a rede de produção estiver disponível, você poderá acessar o servidor, interromper o aplicativo e desligar o sistema operacional. Se não estiver disponível, você pode fazer login via IPMI, interromper o aplicativo e desligar o sistema operacional. Se não houver nenhuma das redes, você não poderá fazer nada. “Obrigado, capitão!”, você pensará.
“E, em geral, há muita turbulência”, você também pode pensar.
Acontece que os servidores, mesmo sem incêndio, geram uma enorme quantidade de calor. Mais precisamente, quando há resfriamento, eles geram calor, e quando não há resfriamento, criam um inferno infernal, que, na melhor das hipóteses, derreterá parte do equipamento e desligará outra parte, e na pior das hipóteses... causará um incêndio dentro do corredor, que quase certamente destruirá tudo.
15:39. Corrigimos problemas com o banco de dados conf.
O banco de dados conf é o backend do serviço de mesmo nome, usado por todos os aplicativos de produção para alterar rapidamente as configurações. Sem esta base não podemos controlar o funcionamento do portal, mas o próprio portal pode funcionar.
15:41. Os sensores de temperatura nos equipamentos da rede Core registram leituras próximas do máximo permitido. Trata-se de uma caixa que ocupa um rack inteiro e garante o funcionamento de todas as redes dentro do data center.
15:42. O rastreador de problemas e o wiki não estão disponíveis, mude para o modo de espera.
Não se trata de produção, mas em caso de acidente, a disponibilidade de qualquer base de conhecimento pode ser crítica.
15:50. Um dos sistemas de monitoramento foi desligado.
São vários e são responsáveis por diversos aspectos dos serviços. Alguns deles são configurados para operar de forma autônoma dentro de cada data center (ou seja, monitoram apenas o próprio data center), outros consistem em componentes distribuídos que sobrevivem de forma transparente à perda de qualquer data center.
Neste caso parou de funcionar , que opera no modo master-standby. Mudou para o modo de espera.
Aceitação
15:51. Todos os servidores, exceto MS SQL, foram desligados via IPMI sem desligar corretamente.
Você está pronto para um gerenciamento massivo de servidores via IPMI, se necessário?
O exato momento em que o resgate dos equipamentos do data center é concluído nesta fase. Tudo o que poderia ser feito foi feito. Alguns colegas podem descansar.
16: 13. Foram recebidas informações de que tubos de freon de aparelhos de ar condicionado estouraram no telhado - isso atrasará o lançamento do data center após a eliminação do incêndio.
16:19. Segundo dados recebidos da equipe técnica do data center, o aumento da temperatura nos corredores cessou.
17:10. O banco de dados conf foi restaurado. Agora podemos alterar as configurações do aplicativo.
Por que isso é tão importante se tudo é tolerante a falhas e funciona mesmo sem um data center?
Em primeiro lugar, nem tudo é tolerante a falhas. Existem vários serviços secundários que ainda não sobreviveram suficientemente bem a uma falha no data center e existem bancos de dados em modo de espera principal. A capacidade de gerenciar as configurações permite fazer tudo o que for necessário para minimizar o impacto das consequências de um acidente nos usuários, mesmo em condições difíceis.
Em segundo lugar, tornou-se claro que o funcionamento do centro de dados não seria totalmente restaurado nas próximas horas, pelo que foi necessário tomar medidas para garantir que a indisponibilidade a longo prazo das réplicas não conduzisse a problemas adicionais, como discos cheios em os data centers restantes.
17:29. Hora da pizza! Empregamos pessoas, não robôs.
Reabilitação
18:02. Nos pavilhões nº 8 (nosso), 9, 10 e 11 a temperatura estabilizou. Um dos que permanece offline (nº 7) abriga nossos equipamentos, e a temperatura ali continua subindo.
18:31. Deram luz verde para o arranque dos equipamentos dos corredores nº 1 e 3 - estes corredores não foram afetados pelo incêndio.
Atualmente, os servidores estão sendo lançados nos corredores nº 1, 3, 8, começando pelos mais críticos. A operação correta de todos os serviços em execução é verificada. Ainda existem problemas com o corredor nº 7.
18:44. A equipe técnica do data center descobriu que na sala nº 7 (onde estão localizados apenas nossos equipamentos) muitos servidores não estão desligados. De acordo com nossos dados, 26 servidores permanecem online lá. Após uma segunda verificação, encontramos 58 servidores.
20:18. Os técnicos do data center sopram ar através de uma sala sem ar-condicionado por meio de dutos móveis que passam pelos corredores.
23:08. O primeiro administrador foi mandado para casa. Alguém precisa dormir à noite para continuar trabalhando amanhã. A seguir, liberaremos mais alguns administradores e desenvolvedores.
02:56. Lançamos tudo o que poderia ser lançado. Fazemos muitas verificações de todos os serviços por meio de testes automáticos.
03:02. O ar condicionado do último 7º salão foi restaurado.
03:36. Colocamos as frentes do data center em rotação no DNS. A partir deste momento o tráfego de usuários começa a chegar.
Estamos mandando a maior parte da equipe administrativa para casa. Mas deixamos algumas pessoas para trás.
Pequenas perguntas frequentes:
P: O que aconteceu das 18h31 às 02h56?
R: Seguindo o “Plano de Ação para Desastres”, lançamos todos os serviços, começando pelos mais importantes. Nesse caso, o coordenador do chat entrega o atendimento a um administrador gratuito, que verifica se o SO e o aplicativo foram iniciados, se há erros e se os indicadores estão normais. Após a conclusão do lançamento, ele informa ao chat que está livre e recebe um novo atendimento do coordenador.
O processo é ainda mais lento por falha de hardware. Mesmo que a parada do sistema operacional e o desligamento dos servidores tenham ocorrido corretamente, alguns servidores não retornam devido a falhas repentinas de discos, memória e chassis. Quando a energia é perdida, a taxa de falhas aumenta.
P: Por que você não pode simplesmente executar tudo de uma vez e depois corrigir o que surge no monitoramento?
R: Tudo deve ser feito gradativamente, pois existem dependências entre os serviços. E tudo deve ser verificado na hora, sem esperar o monitoramento - porque é melhor lidar com os problemas na hora, sem esperar que eles piorem.
7:40. O último administrador (coordenador) foi para a cama. O primeiro dia de trabalho foi concluído.
8:09. Os primeiros desenvolvedores, engenheiros e administradores do data center (incluindo o novo coordenador) iniciaram o trabalho de restauração.
09:37. Começamos a levantar o salão nº 7 (o último).
Ao mesmo tempo, continuamos restaurando o que não foi consertado em outras salas: substituindo discos/memória/servidores, consertando tudo que “queima” no monitoramento, trocando funções em esquemas master-standby e outras coisinhas, das quais existem no entanto, bastante.
17:08. Permitimos todo o trabalho regular com produção.
21:45. O trabalho do segundo dia está concluído.
09:45. Hoje é sexta-feira. Ainda existem alguns pequenos problemas no monitoramento. O fim de semana está chegando, todo mundo quer relaxar. Continuamos a reparar massivamente tudo o que podemos. Tarefas administrativas regulares que poderiam ter sido adiadas foram adiadas. O coordenador é novo.
15:40. De repente, metade da pilha de equipamentos da rede Core em OUTRO data center foi reiniciada. As frentes foram retiradas de rotação para minimizar riscos. Não há efeito para os usuários. Mais tarde descobriu-se que era um chassi com defeito. O coordenador está trabalhando na reparação de dois acidentes ao mesmo tempo.
17:17. A operação da rede em outro data center foi restaurada, tudo foi verificado. O data center é colocado em rotação.
18:29. A obra do terceiro dia e, em geral, a restauração após o acidente foi concluída.
Posfácio
04.04.2013, , "Colegas de classe" —durante três dias o portal ficou total ou parcialmente indisponível. Ao longo de todo esse tempo, mais de 100 pessoas de diferentes cidades, de diferentes empresas (muito obrigado mais uma vez!), remota e diretamente nos data centers, de forma manual e automática, repararam milhares de servidores.
Tiramos conclusões. Para evitar que isso aconteça novamente, realizamos e continuamos realizando um extenso trabalho até hoje.
Quais são as principais diferenças entre o acidente atual e o 404?
- Temos um “Plano de Ação para Acidentes”. Trimestralmente, realizamos exercícios - encenamos uma situação de emergência, que um grupo de administradores (todos por sua vez) deve eliminar usando o “Plano de Ação de Emergência”. Os principais administradores de sistema se revezam no papel de coordenador.
- Trimestralmente, em modo de teste, isolamos os data centers (todos por sua vez) via redes LAN e WAN, o que nos permite identificar prontamente gargalos.
- Menos discos danificados porque restringimos os padrões: menos horas de operação, valores limite mais rígidos para S.M.A.R.T.,
- Abandonamos completamente o BerkeleyDB, um banco de dados antigo e instável que exigia muito tempo para se recuperar após a reinicialização do servidor.
- Reduzimos o número de servidores com MS SQL e diminuímos a dependência dos restantes.
- Nós temos o nosso próprio , para onde estamos migrando ativamente todos os serviços há dois anos. A nuvem simplifica muito todo o ciclo de trabalho com o aplicativo e, em caso de acidente, fornece ferramentas exclusivas como:
- parada correta de todos os aplicativos com um clique;
- migração fácil de aplicativos de servidores com falha;
- lançamento classificado automaticamente (em ordem de prioridade dos serviços) de um data center inteiro.
O acidente descrito neste artigo foi o maior desde o 404º dia. É claro que nem tudo correu bem. Por exemplo, durante a indisponibilidade de um data center danificado por incêndio em outro data center, um disco de um dos servidores falhou, ou seja, apenas uma das três réplicas do cluster Cassandra permaneceu acessível, razão pela qual 4,2% dos dispositivos móveis os usuários do aplicativo não conseguiram fazer login. Ao mesmo tempo, os usuários já conectados continuaram a trabalhar. No total, como resultado do acidente, foram identificados mais de 30 problemas - desde bugs banais até deficiências na arquitetura do serviço.
Mas a diferença mais importante entre o acidente atual e o 404 é que enquanto eliminávamos as consequências do incêndio, os usuários ainda enviavam mensagens de texto e faziam videochamadas para , jogavam, ouviam música, trocavam presentes, assistiam a vídeos, séries e canais de TV em e também transmitido em .
Como vão seus acidentes?
Fonte: habr.com