O que você sentiria se, em um belo dia de verão, um data center com seu equipamento se pareceria com isso?
Olá pessoal! Meu nome é Dmitry Samsonov, trabalho como administrador de sistemas líder em
Odnoklassniki . A foto mostra um dos quatro data centers em que o equipamento que atende ao nosso projeto está instalado. Por trás dessas paredes existem cerca de 4 mil unidades de equipamentos: servidores, sistema de armazenamento de dados, equipamentos de rede, etc. - quase ⅓ de todos os nossos equipamentos.
A maioria dos servidores é Linux. Existem várias dezenas de servidores Windows (MS SQL) - nosso legado, que recusamos sistematicamente há muitos anos.
Assim, em 5 de junho de 2019 às 14:35, os engenheiros de um de nossos data centers relataram um alarme de incêndio.
Negação
14:45. Incidentes menores de fumaça nos data centers são mais comuns do que parecem. Os indicadores dentro dos corredores eram normais, então nossa primeira reação foi relativamente calma: introduzimos uma proibição de trabalhar com produção, ou seja, qualquer alteração na configuração, lançando novas versões etc., exceto pelo trabalho relacionado à correção de algo.
Raiva
Alguma vez você já tentou descobrir com os bombeiros exatamente onde havia um incêndio no telhado ou subir em um telhado em chamas para avaliar a situação? Qual será o grau de confiança nas informações recebidas por cinco pessoas?
14:50.
Foi recebida informação de que o incêndio está se aproximando do sistema de refrigeração . Mas isso virá? O administrador do sistema de plantão exibe tráfego externo das frentes desse data center.
No momento, as frentes de todos os nossos serviços são duplicadas em três datacenters, é usado o balanceamento no nível DNS, que permite remover os endereços de um datacenter do DNS, protegendo os usuários de possíveis problemas com o acesso aos serviços. Caso já tenham ocorrido problemas no datacenter, ele sai automaticamente da rotação. Mais detalhes podem ser encontrados aqui: Balanceamento de carga e tolerância a falhas em Odnoklassniki.
O incêndio ainda não nos afetou de forma alguma - nem usuários nem equipamentos foram afetados. É um acidente? A primeira seção do documento "Plano de Ação para Acidentes" define o conceito de "Acidente" e a seção termina da seguinte forma:
“Em caso de dúvida, um acidente ou não, então é um acidente! "14:53. Um coordenador de acidentes é nomeado.
Um coordenador é uma pessoa que controla a comunicação entre todos os participantes, estima a escala do acidente, usa o "Plano de Ação para Acidentes", atrai a equipe necessária, monitora a conclusão do reparo e, mais importante, delega todas as tarefas. Em outras palavras, essa é a pessoa que gerencia todo o processo de eliminação do acidente.
Negociação
15:01. Começamos a desconectar servidores que não estão vinculados à produção.
15:03. Desative todos os serviços reservados corretamente.
Isso inclui não apenas as frentes (nas quais os usuários não estão mais conectados) 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 (
Cassandra ,
armazenamento de dados binários ,
armazenamento a frio ,
NewSQL , etc.).
15:06.
Foi recebida informação de que um incêndio ameaça um dos corredores do data center. Não temos equipamentos nesta sala, mas o fato de o fogo se espalhar do telhado para as salas muda muito a imagem do que está acontecendo.
(Mais tarde, verificou-se que não havia ameaça física ao salão, uma vez que estava hermeticamente isolado do telhado. A ameaça era apenas para o sistema de refrigeração desse salão.)
15:07. Permitimos a execução de comandos em servidores no modo acelerado sem verificações adicionais (
sem a nossa calculadora favorita ).
15:08. A temperatura nos quartos está dentro dos limites normais.
15:12.
Foi registrado um aumento de temperatura nos corredores.15:13. Mais da metade dos servidores no data center estão desativados. Nós continuamos.
15:16. Foi decidido desligar todos os equipamentos.
15:21 Começamos a desligar os servidores sem estado sem desligar corretamente o aplicativo e os SOs.
15:23. Um grupo de responsáveis pelo MS SQL é destacado (existem poucos, a dependência de serviços neles não é grande, mas o procedimento de recuperação leva mais tempo e é mais complicado do que, por exemplo, Cassandra).
Depressão
15:25.
Foram recebidas informações sobre como desligar a energia em quatro das 16 salas (Nº 6, 7, 8, 9). Nos sétimo e oitavo salões estão nossos equipamentos. Não há mais informações sobre nossos dois quartos (nºs 1 e 3).
Normalmente, durante incêndios, a energia é desligada imediatamente, mas, neste caso, graças ao trabalho coordenado dos bombeiros e do pessoal técnico do data center, ela foi desligada não em todos os lugares e não imediatamente, mas se necessário.
(Mais tarde, verificou-se que a energia nos corredores 8 e 9 não foi desligada.)
15:28. Começamos a implantar bancos de dados MS SQL a partir de backups em outros data centers.
Quanto tempo vai demorar? Existe largura de banda de rede suficiente para toda a rota?
15:37.
Bloqueou algumas partes da rede.A rede de gerenciamento e produção é fisicamente isolada uma da outra. Se a rede de produção estiver disponível, você poderá acessar o servidor, parar o aplicativo e desligar o sistema operacional. Se não estiver disponível, você poderá acessar o IPMI, parar o aplicativo e desligar o sistema operacional. Se não houver rede, você não poderá fazer nada. "Obrigado cap!" Você vai pensar.
"De qualquer forma, há muita confusão", você também pode pensar.
O problema é que os servidores, mesmo sem incêndio, geram uma quantidade enorme de calor. Mais precisamente, quando há resfriamento, eles geram calor, e quando não há, eles criam um inferno infernal, que na melhor das hipóteses derreterá alguns dos equipamentos e desligará o outro, e na pior das hipóteses ... causará um incêndio dentro do salão, que quase certamente destruirá tudo.
15:39. Corrigimos problemas com o banco de dados conf.
O banco de dados conf é o back-end do serviço com o mesmo nome, usado por todos os aplicativos de produção para alterar rapidamente as configurações. Sem essa base, não podemos controlar o portal, mas o próprio portal pode funcionar.
15:41. Os sensores de temperatura nos equipamentos da rede Core registram leituras próximas ao máximo permitido. Essa é uma caixa que ocupa um rack inteiro e garante a operação de todas as redes dentro do data center.
15:42. O rastreador de problemas e o wiki não estão disponíveis, alterne para o modo de espera.
Isso não é produção, mas em um acidente, a disponibilidade de qualquer base de conhecimento pode ser crítica.
15:50. Um dos sistemas de monitoramento foi desconectado.
Existem vários deles, e eles são responsáveis por vários aspectos do trabalho dos serviços. Alguns deles estão configurados para funcionar autonomamente dentro de cada data center (ou seja, monitoram apenas o data center), enquanto outros consistem em componentes distribuídos que sobrevivem de forma transparente à perda de qualquer data center.
Nesse caso, o
sistema para detectar anomalias nos indicadores de lógica de negócios que funciona no modo de espera principal parou de funcionar. Mude para o modo de espera.
Aceitação
15:51. Por meio do IPMI, todos os servidores, exceto o MS SQL, foram desativados sem um desligamento correto.
Você está pronto para o gerenciamento de servidores em massa através do IPMI, se necessário?
O exato momento em que o resgate de equipamentos no data center, nesta fase, é concluído. Tudo o que poderia ser feito foi feito. Alguns colegas podem relaxar.
16:13.
Havia informações de que os tubos freon dos aparelhos de ar-condicionado estouravam no teto - isso atrasaria o lançamento do data center após a eliminação do incêndio.16:19. De acordo com dados recebidos da equipe técnica do data center, o aumento de temperatura nos corredores parou.
17:10. Restaurou o trabalho do banco de dados conf. Agora podemos alterar as configurações do aplicativo.
Por que é tão importante se tudo é tolerante a falhas e funciona mesmo sem um data center?
Primeiro, nem tudo é tolerante a falhas. Existem vários serviços secundários que não sobrevivem à falha do data center suficientemente bem e existem bases no modo de espera principal. A capacidade de gerenciar as configurações permite que você faça todo o necessário para minimizar o impacto das consequências do acidente nos usuários, mesmo em condições difíceis.
Em segundo lugar, ficou claro que, nas próximas horas, o datacenter não se recuperará completamente; portanto, era necessário tomar medidas para que a indisponibilidade a longo prazo de réplicas não levasse a problemas adicionais, como estouros de disco nos demais datacenters.
17:29. Hora da pizza! Temos pessoas trabalhando, não robôs.
Reabilitação
18:02. Nos quartos n ° 8 (nosso), 9, 10 e 11, a temperatura se estabilizou. Em um dos que permanecem desconectados (nº 7), nossos equipamentos estão localizados e a temperatura continua aumentando.
18:31. Eles deram luz verde para lançar equipamentos nos corredores Nos. 1 e 3 - o fogo não afetou esses corredores.
Atualmente, os servidores estão sendo lançados nos corredores nº 1, 3, 8, começando pelos mais críticos. Verifica a operação correta de todos os serviços em execução. Ainda há problemas com o quarto 7.
18:44. A equipe técnica do data center descobriu que no hall número 7 (onde apenas nosso equipamento está localizado), muitos servidores não estão desligados. Segundo nossos dados, 26 servidores permanecem lá. Após a verificação, encontramos 58 servidores.
20:18. A equipe técnica do data center sopra ar na sala sem ar-condicionado através de dutos móveis dispostos nos corredores.
23:08. Eles deixaram o primeiro administrador ir para casa. Alguém precisa dormir à noite para continuar trabalhando amanhã. Em seguida, lançamos outra parte dos administradores e desenvolvedores.
02:56. Lançamos tudo o que poderia ser lançado. Fazemos uma grande verificação de todos os serviços com autotestes.
03:02 Ar condicionado no último, sétimo salão restaurado.
03:36. Eles colocaram as frentes do centro de dados em rotação no DNS. A partir deste momento, o tráfego do usuário começa a chegar.
Dissolvemos a maioria da equipe de administradores domésticos. Mas deixamos algumas pessoas.
Pequenas FAQ:
P: O que aconteceu das 18:31 às 02:56?
R: Seguindo o “Plano de Ação para Acidentes”, lançamos todos os serviços, começando pelos mais importantes. Ao mesmo tempo, o coordenador do bate-papo presta um serviço a um administrador gratuito, que verifica se o SO e o aplicativo foram iniciados, se há algum erro ou se os indicadores estão normais. Após a conclusão do lançamento, ele informa ao bate-papo que está livre e recebe um novo serviço do coordenador.
O processo é adicionalmente inibido pelo ferro com falha. Mesmo que o desligamento e desativação do sistema operacional dos servidores estejam corretos, alguns deles não retornam devido a falhas de unidades, memória ou chassi com falha repentina. Com a perda de energia, a taxa de falha aumenta.
P: Por que você não pode simplesmente iniciar tudo de uma vez e depois reparar o que sai do monitoramento?
R: Tudo precisa ser feito gradualmente, porque existem dependências entre os serviços. E tudo deve ser verificado imediatamente, sem esperar pelo monitoramento - porque é melhor lidar com os problemas imediatamente, não esperar pelo seu agravamento.
7:40 da manhã O último administrador (coordenador) foi para a cama. O trabalho do primeiro dia está concluído.
8:09 da manhã Os primeiros desenvolvedores, engenheiros nos datacenters e administradores (incluindo o novo coordenador) começaram os trabalhos de restauração.
09:37. Começamos a elevar o número 7 do salão (o último).
Ao mesmo tempo, continuamos restaurando o que não terminamos em outras salas: substituindo discos / memória / servidores, consertando tudo o que está pegando fogo no monitoramento, alternando funções de inversão em circuitos de espera principal e outras pequenas coisas, que são, no entanto, bastante.
17:08. Permita todo o trabalho regular com a produção.
21:45. O trabalho do segundo dia está concluído.
09:45. Hoje é sexta-feira. Ainda existem alguns problemas menores no monitoramento. Antes do fim de semana, todo mundo quer relaxar. Continuamos a reparar massivamente tudo o que é possível. Tarefas administrativas normais que podem ser adiadas são adiadas. O coordenador é novo.
15:40. De repente, metade da pilha principal de equipamentos de rede no OTHER data center foi reiniciada. Frentes removidas da rotação para minimizar riscos. Não há efeito para os usuários. Mais tarde, descobriu-se que era um chassi ruim. O coordenador trabalha com a correção de duas falhas ao mesmo tempo.
17:17. A rede em outro data center é restaurada, tudo está verificado. O centro de dados está em rotação.
18:29. O trabalho do terceiro dia e, em geral, a recuperação do acidente está concluído.
Posfácio
04/04/2013,
no dia do erro 404 , Odnoklassniki
sobreviveu a um acidente grave - por três dias o portal ficou total ou parcialmente indisponível. Durante esse período, mais de 100 pessoas de diferentes cidades, de diferentes empresas (muito obrigado novamente!) Remotamente e diretamente nos data centers, repararam manual e automaticamente milhares de servidores.
Tiramos conclusões. Para evitar que isso aconteça novamente, realizamos e continuamos a realizar 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 de Emergência". Uma vez por trimestre, realizamos exercícios - realizamos uma emergência, que um grupo de administradores (por sua vez) deve eliminar usando o "Plano de Ação de Emergência". Os principais administradores de sistema se revezam na definição do papel de coordenador.
- Trimestralmente no modo de teste, isole os datacenters (todos por sua vez) pela LAN e WAN, o que permite identificar gargalos em tempo hábil.
- Menos unidades defeituosas, porque reforçamos os padrões: menos horas de funcionamento, limites mais rígidos para o SMART,
- BerkeleyDB completamente abandonado - um banco de dados antigo e instável que exigia muito tempo para se recuperar da reinicialização do servidor.
- Reduza o número de servidores com MS SQL e reduza a dependência do restante.
- Temos nossa própria nuvem - uma nuvem , onde temos migrado ativamente todos os serviços nos últimos dois anos. A nuvem simplifica bastante todo o ciclo de trabalho com o aplicativo e, em caso de acidente, fornece ferramentas exclusivas como:
- correto interrompa todos os aplicativos em um clique;
- migração simples de aplicativos de servidores com falha;
- classificação automática (em ordem de prioridade dos serviços), lançando um data center inteiro.
O acidente descrito neste artigo se tornou o maior desde o dia 404. Claro, nem tudo correu bem. Por exemplo, durante a indisponibilidade do gravador de data center em outro data center, um disco travou em um dos servidores, ou seja, apenas uma das três réplicas no cluster Cassandra estava disponível, devido à qual 4,2% dos usuários de aplicativos móveis não puderam efetuar login . Ao mesmo tempo, os usuários já conectados continuaram trabalhando. No total, mais de 30 problemas foram identificados de acordo com os resultados do acidente - de bugs banais a falhas de arquitetura de serviço.
Mas a diferença mais importante entre o acidente atual e o 404º é que, enquanto eliminamos as consequências do incêndio, os usuários ainda se correspondiam e faziam videochamadas em
Tamtam , jogavam jogos, ouviam música, davam presentes uns aos outros, assistiam vídeos, programas de TV e canais de TV em
OK e também transmitido para o
OK Live .
Como estão indo seus acidentes?