{"id":84108,"date":"2020-06-05T07:42:44","date_gmt":"2020-06-05T05:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra"},"modified":"2020-06-05T07:42:44","modified_gmt":"2020-06-05T05:42:44","slug":"tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"Deve-se \"apagar\" servidores se o teste de fuma\u00e7a do data center \"pegar fogo\"?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O que voc\u00ea sentiria se, em um belo dia de ver\u00e3o, o data center com seu equipamento fosse assim?<\/p>\n

\"Deve-se
\n
\nOl\u00e1 a todos! Meu nome \u00e9 Dmitry Samsonov, sou administrador de sistemas chefe na \"Odnoklassniki<\/a><\/noindex>\". Na foto, um dos quatro data centers onde est\u00e1 o equipamento que atende nosso projeto. Atr\u00e1s dessas paredes est\u00e3o cerca de 4 mil unidades de hardware: servidores, sistemas de armazenamento de dados, equipamentos de rede, etc. \u2014 quase \u2153 de todo o nosso equipamento.
\nA maioria dos servidores \u00e9 Linux. Existem tamb\u00e9m algumas dezenas de servidores Windows (MS SQL) \u2014 nosso legado, do qual estamos nos afastando gradualmente ao longo dos anos.
\nEnt\u00e3o, no dia 5 de junho de 2019, \u00e0s 14:35, os engenheiros de um de nossos data centers relataram um alarme de inc\u00eandio.
\n<\/a><\/noindex><\/p>\n

Nega\u00e7\u00e3o<\/h4>\n

\n14:45. Incidentes menores de fuma\u00e7a em data centers ocorrem com mais frequ\u00eancia do que parece. Os indicadores dentro das salas estavam normais, portanto, nossa primeira rea\u00e7\u00e3o foi relativamente calma: instauramos uma proibi\u00e7\u00e3o de altera\u00e7\u00f5es no ambiente de produ\u00e7\u00e3o, ou seja, qualquer modifica\u00e7\u00e3o de configura\u00e7\u00f5es, lan\u00e7amento de novas vers\u00f5es, etc., exceto para trabalhos relacionados \u00e0 repara\u00e7\u00e3o de algo.<\/p>\n

Raiva<\/h4>\n

\nVoc\u00ea j\u00e1 tentou perguntar aos bombeiros onde exatamente no telhado ocorreu o inc\u00eandio, ou tentou ir ao telhado em chamas para avaliar a situa\u00e7\u00e3o? Qual \u00e9 o n\u00edvel de confian\u00e7a nas informa\u00e7\u00f5es obtidas atrav\u00e9s de cinco pessoas?<\/p>\n

14:50. Recebemos a informa\u00e7\u00e3o de que o fogo est\u00e1 se aproximando do sistema de refrigera\u00e7\u00e3o<\/b>. Mas ir\u00e1 chegar? O administrador de sistemas de plant\u00e3o est\u00e1 redirecionando o tr\u00e1fego externo das frentes desse data center.<\/p>\n

Atualmente, as frentes de todos os nossos servi\u00e7os est\u00e3o duplicadas em tr\u00eas data centers, usando balanceamento no n\u00edvel de DNS, o que permite remover endere\u00e7os de um data center do DNS, protegendo assim os usu\u00e1rios de poss\u00edveis problemas de acesso aos servi\u00e7os. No caso de problemas j\u00e1 terem ocorrido no data center, ele sai da rota\u00e7\u00e3o automaticamente. Mais detalhes podem ser lidos aqui: Balanceamento de carga e toler\u00e2ncia a falhas em \"\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438\".<\/a><\/noindex><\/p><\/blockquote>\n

\nAt\u00e9 agora, o inc\u00eandio n\u00e3o nos afetou de forma alguma \u2014 nem os usu\u00e1rios, nem o equipamento sofreram danos. Isso \u00e9 um acidente? A primeira se\u00e7\u00e3o do documento \"Plano de A\u00e7\u00e3o em Caso de Acidente\" define o que \u00e9 um \"Acidente\", e a se\u00e7\u00e3o termina assim:
\n\u00abSe houver d\u00favidas sobre se isso \u00e9 um acidente ou n\u00e3o, ent\u00e3o \u00e9 um acidente!<\/u>\u00bb<\/b><\/p>\n

14:53. Nomeado o coordenador de emerg\u00eancia.<\/p>\n

O coordenador \u00e9 a pessoa que controla a comunica\u00e7\u00e3o entre todos os participantes, avalia a magnitude da emerg\u00eancia, utiliza o \"Plano de A\u00e7\u00e3o em Caso de Emerg\u00eancia\", chama o pessoal necess\u00e1rio, supervisiona a conclus\u00e3o dos reparos e, o mais importante, delega quaisquer tarefas. Em outras palavras, \u00e9 a pessoa que gerencia todo o processo de elimina\u00e7\u00e3o da emerg\u00eancia.<\/p><\/blockquote>\n

<\/p>\n

Negocia\u00e7\u00e3o<\/h4>\n

\n15:01. Come\u00e7amos a desligar os servidores que n\u00e3o est\u00e3o vinculados \u00e0 produ\u00e7\u00e3o.
\n15:03. Desligamos corretamente todos os servi\u00e7os reservados.
\nIsso inclui n\u00e3o apenas os front-ends (nos quais os usu\u00e1rios j\u00e1 n\u00e3o acessam neste momento) e seus servi\u00e7os auxiliares (l\u00f3gica de neg\u00f3cios, caches etc.), mas tamb\u00e9m v\u00e1rias bases de dados com fator de replica\u00e7\u00e3o 2 ou mais (Cassandra<\/a><\/noindex>, armazenamento de dados bin\u00e1rios<\/a><\/noindex>, armazenamento frio<\/a><\/noindex>, NewSQL<\/a><\/noindex> e outros).
\n15:06. Recebemos informa\u00e7\u00f5es de que um inc\u00eandio amea\u00e7a uma das salas do data center.<\/b> Nesta sala n\u00e3o temos equipamentos, mas o fato de que o fogo pode se espalhar do telhado para as salas muda muito a situa\u00e7\u00e3o.
\n(Mais tarde ficou claro que n\u00e3o havia amea\u00e7a f\u00edsica para a sala, pois estava hermeticamente isolada do telhado. A amea\u00e7a era apenas para o sistema de refrigera\u00e7\u00e3o dessa sala.)
\n15:07. Permitimos a execu\u00e7\u00e3o de comandos nos servidores em modo acelerado sem verifica\u00e7\u00f5es adicionais (sem nosso querido calculador<\/a><\/noindex>).
\n15:08. A temperatura nas salas est\u00e1 dentro da norma.
\n15:12. Foi registrado um aumento de temperatura nas salas.<\/b>
\n15:13. Mais da metade dos servidores no data center est\u00e1 desligada. Continuamos.
\n15:16. Decidimos desligar todo o equipamento.
\n15:21. Come\u00e7amos a cortar a alimenta\u00e7\u00e3o dos servidores stateless sem desligar adequadamente o aplicativo e o sistema operacional.
\n15:23. Um grupo \u00e9 destacado para ser respons\u00e1vel pelo MS SQL (s\u00e3o poucos, a depend\u00eancia dos servi\u00e7os deles n\u00e3o \u00e9 grande, mas o procedimento de recupera\u00e7\u00e3o \u00e9 mais demorado e complicado do que, por exemplo, o do Cassandra).<\/p>\n

Depress\u00e3o<\/h4>\n

\n15:25. Recebemos informa\u00e7\u00f5es sobre o corte de energia em quatro salas de 16 (n\u00ba 6, 7, 8, 9).<\/b> Nos sal\u00f5es 7 e 8 est\u00e1 nosso equipamento. Ainda n\u00e3o temos informa\u00e7\u00f5es sobre duas de nossas salas (n\u00ba 1 e 3).
\nNormalmente, em caso de inc\u00eandio, a alimenta\u00e7\u00e3o el\u00e9trica \u00e9 cortada imediatamente, mas nesse caso, gra\u00e7as ao trabalho coordenado dos bombeiros e da equipe t\u00e9cnica do data center, ela n\u00e3o foi desligada em todos os locais e n\u00e3o imediatamente, mas conforme necessidade.
\n(Mais tarde, foi descoberto que a energia nas salas 8 e 9 n\u00e3o foi desligada.)
\n15:28. Come\u00e7amos a restaurar os bancos de dados MS SQL de backups em outros data centers.
\nQuanto tempo ser\u00e1 necess\u00e1rio para isso? A largura de banda da rede ser\u00e1 suficiente em todo o percurso?
\n15:37. Foi registrado o desligamento de algumas se\u00e7\u00f5es da rede.<\/b>
\nA rede de gerenciamento e a rede de produ\u00e7\u00e3o est\u00e3o fisicamente isoladas uma da outra. Se a rede de produ\u00e7\u00e3o estiver dispon\u00edvel, voc\u00ea pode acessar o servidor, parar o aplicativo e desligar o sistema operacional. Se n\u00e3o estiver dispon\u00edvel, \u00e9 poss\u00edvel acessar via IPMI, parar o aplicativo e desligar o sistema operacional. Se nenhuma das redes estiver dispon\u00edvel, voc\u00ea n\u00e3o poder\u00e1 fazer nada. 'Obrigado, capit\u00e3o!', voc\u00ea pode pensar.
\n\u2018E, de fato, tem bastante agita\u00e7\u00e3o\u2019, voc\u00ea pode pensar tamb\u00e9m.
\nO problema \u00e9 que os servidores, mesmo sem inc\u00eandio, geram uma quantidade enorme de calor. Mais precisamente, quando h\u00e1 refrigera\u00e7\u00e3o, eles geram calor; e quando n\u00e3o h\u00e1, criam um inferno que, na melhor das hip\u00f3teses, derrete parte do equipamento e desliga outra parte, e na pior\u2026 provoca um inc\u00eandio dentro da sala, que praticamente garantir\u00e1 a destrui\u00e7\u00e3o de tudo.<\/p>\n

\"Deve-se
\n
\n15:39. Registramos problemas com o banco de dados conf.<\/p>\n

O banco de dados conf \u00e9 o backend do servi\u00e7o hom\u00f4nimo, que \u00e9 utilizado por todos os aplicativos de produ\u00e7\u00e3o para altera\u00e7\u00f5es operacionais nas configura\u00e7\u00f5es. Sem esse banco de dados, n\u00e3o conseguimos gerenciar as opera\u00e7\u00f5es do portal, mas o pr\u00f3prio portal ainda pode funcionar.<\/p><\/blockquote>\n

\n15:41. Os sensores de temperatura no equipamento de rede Core registram leituras pr\u00f3ximas ao limite permitido. Esta \u00e9 uma caixa que ocupa um rack e garante o funcionamento de todas as redes dentro do data center.<\/p>\n

\"Deve-se
\n
\n15:42. O rastreador de problemas e a wiki est\u00e3o indispon\u00edveis, mudamos para o modo de espera.
\nIsso n\u00e3o \u00e9 produ\u00e7\u00e3o, mas em caso de emerg\u00eancia, a acessibilidade de qualquer base de conhecimento pode ser cr\u00edtica.
\n15:50. Um dos sistemas de monitoramento desligou.
\nExistem v\u00e1rios, e eles s\u00e3o respons\u00e1veis por diferentes aspectos do funcionamento dos servi\u00e7os. Alguns deles est\u00e3o configurados para funcionar de forma aut\u00f4noma dentro de cada data center (ou seja, monitoram apenas seu pr\u00f3prio data center), outros consistem em componentes distribu\u00eddos que lidam de forma transparente com a perda de qualquer data center.
\nNeste caso, parou de funcionar o sistema de dete\u00e7\u00e3o de anomalias de indicadores de l\u00f3gica de neg\u00f3cios<\/a><\/noindex>, que funciona no modo master-standby. Mudamos para o standby.<\/p>\n

Aceita\u00e7\u00e3o<\/h4>\n

\n15:51. Atrav\u00e9s do IPMI, desligamos todos os servidores sem um encerramento adequado, exceto o MS SQL.
\nVoc\u00ea est\u00e1 pronto para gerenciar servidores em massa atrav\u00e9s do IPMI, se necess\u00e1rio?<\/p>\n

Aquele momento em que o resgate do equipamento no data center foi conclu\u00eddo nesta etapa. Tudo que podia ser feito, foi feito. Alguns colegas podem descansar.<\/i>
\n16:13. Recebemos informa\u00e7\u00f5es de que os canos de freon dos condicionadores de ar estouraram no telhado \u2014 isso atrasar\u00e1 a abertura do data center ap\u00f3s a extin\u00e7\u00e3o do inc\u00eandio.<\/b>
\n16:19. De acordo com os dados recebidos do pessoal t\u00e9cnico do data center, a temperatura nas salas deixou de subir.
\n17:10. Restauramos a opera\u00e7\u00e3o da base conf. Agora podemos alterar as configura\u00e7\u00f5es dos aplicativos.
\nPor que isso \u00e9 t\u00e3o importante, se tudo \u00e9 tolerante a falhas e funciona at\u00e9 sem um data center?
\nEm primeiro lugar, nem tudo \u00e9 tolerante a falhas. Existem v\u00e1rios servi\u00e7os secund\u00e1rios que ainda n\u00e3o suportam bem a falha de um data center, e h\u00e1 bases em modo master-standby. A capacidade de gerenciar as configura\u00e7\u00f5es permite fazer tudo o que for necess\u00e1rio para minimizar o impacto das consequ\u00eancias de uma emerg\u00eancia sobre os usu\u00e1rios, mesmo em condi\u00e7\u00f5es dif\u00edceis.
\nEm segundo lugar, ficou claro que o funcionamento do data center n\u00e3o ser\u00e1 totalmente restaurado nas pr\u00f3ximas horas, portanto, foi necess\u00e1rio tomar medidas para que a indisponibilidade prolongada das r\u00e9plicas n\u00e3o resultasse em problemas adicionais, como a satura\u00e7\u00e3o dos discos nos restantes data centers.
\n17:29. Hora da pizza! Temos pessoas trabalhando, n\u00e3o rob\u00f4s.<\/p>\n

\"Deve-se
\n<\/p>\n

Reabilita\u00e7\u00e3o<\/h4>\n

\n18:02. A temperatura estabilizou nas salas n\u00ba 8 (nossa), 9, 10 e 11. Em uma das que permanecem desligadas (n\u00ba 7), est\u00e1 nosso equipamento, e a temperatura continua subindo.
\n18:31. Demos sinal verde para iniciar o equipamento nas salas n\u00ba 1 e 3 \u2014 essas salas n\u00e3o foram afetadas pelo inc\u00eandio.<\/p>\n

Atualmente, estamos iniciando servidores nas salas n\u00ba 1, 3 e 8, come\u00e7ando pelos mais cr\u00edticos. Estamos verificando a opera\u00e7\u00e3o correta de todos os servi\u00e7os iniciados. Ainda existem problemas na sala n\u00ba 7.<\/i><\/p>\n

18:44. O pessoal t\u00e9cnico do data center descobriu que, na sala n\u00ba 7 (onde est\u00e1 apenas nosso equipamento), muitos servidores n\u00e3o est\u00e3o desligados. De acordo com nossas informa\u00e7\u00f5es, 26 servidores permanecem ligados. Ap\u00f3s nova verifica\u00e7\u00e3o, encontramos 58 servidores.
\n20:18. O pessoal t\u00e9cnico do data center est\u00e1 ventilando o ar na sala sem condicionadores atrav\u00e9s de dutos m\u00f3veis, que foram instalados pelos corredores.
\n23:08. Liberamos o primeiro administrador para casa. Algu\u00e9m precisa descansar \u00e0 noite para continuar o trabalho amanh\u00e3. A seguir, liberamos mais alguns administradores e desenvolvedores.
\n02:56. Iniciamos tudo que podia ser iniciado. Estamos fazendo uma grande verifica\u00e7\u00e3o de todos os servi\u00e7os com autotestes.<\/p>\n

\"Deve-se
\n
\n03:02. O ar condicionado na \u00faltima sala, a 7\u00aa, foi restaurado.
\n03:36. Colocamos os frontes no data center em rota\u00e7\u00e3o no DNS. A partir deste momento, o tr\u00e1fego de usu\u00e1rios come\u00e7a a chegar.
\nLiberamos a maior parte da equipe de administradores para casa. Mas mantemos algumas pessoas.<\/p>\n

Pequenas FAQ:
\nQ: O que aconteceu das 18:31 \u00e0s 02:56?
\nA: Seguindo o \"Plano de A\u00e7\u00e3o em Caso de Emerg\u00eancia\", iniciamos todos os servi\u00e7os, come\u00e7ando pelos mais importantes. Ao mesmo tempo, o coordenador no chat atribui um servi\u00e7o a um administrador livre, que verifica se o sistema operacional e o aplicativo foram iniciados, se n\u00e3o h\u00e1 erros, se os indicadores est\u00e3o normais. Ap\u00f3s concluir a inicializa\u00e7\u00e3o, ele informa no chat que est\u00e1 livre e recebe um novo servi\u00e7o do coordenador.
\nO processo \u00e9 adicionalmente atrasado por hardware com falha. Mesmo que a parada do sistema operacional e a desconex\u00e3o dos servidores tenham ocorrido corretamente, parte dos servidores n\u00e3o retorna devido a discos, mem\u00f3ria ou chassis que falharam inesperadamente. Quando h\u00e1 perda de energia, a taxa de falhas aumenta.
\nQ: Por que n\u00e3o podemos simplesmente iniciar tudo de uma vez e depois consertar o que aparecer no monitoramento?
\nA: Tudo precisa ser feito gradualmente, porque existem depend\u00eancias entre os servi\u00e7os. E \u00e9 necess\u00e1rio verificar tudo imediatamente, sem esperar pelo monitoramento \u2014 porque \u00e9 melhor resolver problemas logo, sem esperar que se agravem.<\/p><\/blockquote>\n

\n7:40. O \u00faltimo administrador (coordenador) foi dormir. O trabalho do primeiro dia foi conclu\u00eddo.
\n8:09. Os primeiros desenvolvedores, engenheiros nos data centers e administradores (incluindo o novo coordenador) come\u00e7aram os trabalhos de restaura\u00e7\u00e3o.
\n09:37. Come\u00e7amos a levantar a sala n\u00ba 7 (a \u00faltima).
\nParalelamente, continuamos a restaurar o que n\u00e3o foi consertado em outras salas: substitui\u00e7\u00e3o de discos\/mem\u00f3ria\/servidores, consertar tudo que 'est\u00e1 pegando fogo' no monitoramento, revers\u00e3o de pap\u00e9is nos esquemas master-standby e outras pequenas coisas, que ainda assim s\u00e3o bastante numerosas.
\n17:08. Liberamos todos os trabalhos de rotina com a produ\u00e7\u00e3o.
\n21:45. O trabalho do segundo dia foi conclu\u00eddo.
\n09:45. Hoje \u00e9 sexta-feira. No monitoramento, ainda h\u00e1 muitos pequenos problemas. O fim de semana se aproxima e todos querem descansar. Continuamos a consertar em massa tudo o que \u00e9 poss\u00edvel. As tarefas administrativas que poderiam ser adiadas foram adiadas. O coordenador \u00e9 novo.
\n15:40. De repente, reiniciou metade do stack de equipamentos de rede em OUTRO datacenter. Retiramos da rota\u00e7\u00e3o as frentes para minimizar riscos. N\u00e3o houve efeito para os usu\u00e1rios. Mais tarde, foi descoberto que era um chassi defeituoso. O coordenador est\u00e1 lidando com o reparo de duas falhas simultaneamente.
\n17:17. O funcionamento da rede em outro datacenter foi restaurado, tudo verificado. O datacenter foi reintegrado \u00e0 rota\u00e7\u00e3o.
\n18:29. O trabalho do terceiro dia e, no geral, a recupera\u00e7\u00e3o ap\u00f3s a falha foram conclu\u00eddos.<\/p>\n

Ep\u00edlogo<\/h4>\n

\n04.04.2013, no dia do erro 404<\/a><\/noindex>, \"Odnoklassniki\" passou pela maior falha<\/a><\/noindex> \u2014 por tr\u00eas dias, o portal ficou total ou parcialmente inacess\u00edvel. Durante todo esse tempo, mais de 100 pessoas de v\u00e1rias cidades e empresas (mais uma vez, muito obrigado!), remotamente e diretamente nos datacenters, manualmente e automaticamente consertaram milhares de servidores.
\nTiramos li\u00e7\u00f5es. Para que isso n\u00e3o se repita, realizamos e continuamos a realizar, at\u00e9 hoje, um trabalho extensivo.<\/p>\n

Quais s\u00e3o as principais diferen\u00e7as entre a atual falha e a 404?<\/p>\n