{"id":34264,"date":"2019-10-31T21:57:17","date_gmt":"2019-10-31T18:57:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom\/"},"modified":"2019-10-31T21:57:17","modified_gmt":"2019-10-31T18:57:17","slug":"glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom","title":{"rendered":"A principal raz\u00e3o para falhas em data centers \u00e9 a conex\u00e3o entre o computador e a cadeira","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O tema de grandes falhas em centros de dados modernos levanta quest\u00f5es que n\u00e3o foram respondidas no primeiro artigo \u2014 decidimos expandi-lo.<\/em><\/p>\n

\n\"A<\/a><\/noindex><\/p>\n

Se acreditarmos nas estat\u00edsticas do Uptime Institute, a maior parte dos incidentes em data centers est\u00e1 relacionada a falhas no sistema de fornecimento de energia \u2014 essas representam 39% dos casos. O fator humano vem em seguida, contribuindo com mais 24% das falhas. A terceira causa mais significativa (15%) foram falhas no sistema de climatiza\u00e7\u00e3o, enquanto desastres naturais ocuparam o quarto lugar (12%). A soma de outros imprevistos representa apenas 10%. Sem questionar os dados de uma organiza\u00e7\u00e3o respeit\u00e1vel, vamos destacar um aspecto comum entre diferentes incidentes e tentar entender se poderiam ter sido evitados. Spoiler: na maioria dos casos, poderiam.<\/p>\n

<\/p>\n

A ci\u00eancia dos contatos<\/h2>\n

<\/p>\n

Simplificando, existem apenas dois problemas com o fornecimento de energia: ou n\u00e3o h\u00e1 contato onde deveria haver, ou h\u00e1 contato onde n\u00e3o deveria. Pode-se discutir por muito tempo sobre a confiabilidade dos modernos sistemas de fornecimento de energia ininterrupta, mas eles n\u00e3o salvam sempre. Um exemplo \u00e9 o famoso caso do centro de processamento de dados da British Airways, pertencente \u00e0 empresa-m\u00e3e International Airlines Group. Nas proximidades do aeroporto de Heathrow, est\u00e3o localizados dois desses centros \u2014 Boadicea House e Comet House. No primeiro, em 27 de maio de 2017, ocorreu uma interrup\u00e7\u00e3o acidental de energia, que levou a uma sobrecarga e falha do sistema de UPS. Como resultado, parte do equipamento de TI foi fisicamente danificada, e a recupera\u00e7\u00e3o dessa falha levou tr\u00eas dias. <\/p>\n

<\/p>\n

A companhia a\u00e9rea teve que cancelar ou adiar mais de mil voos, cerca de 75 mil passageiros n\u00e3o conseguiram decolar a tempo \u2014 o pagamento de indeniza\u00e7\u00f5es custou $128 milh\u00f5es, sem contar os gastos necess\u00e1rios para restaurar a funcionalidade dos data centers. A hist\u00f3ria sobre as causas da falha de energia \u00e9 confusa. Se acreditarmos nos resultados da investiga\u00e7\u00e3o interna divulgados pelo CEO da International Airlines Group, Willie Walsh, o incidente ocorreu devido a um erro dos engenheiros. No entanto, o sistema de fornecimento de energia ininterrupta deveria ter suportado tal desligamento \u2014 foi para isso que foi instalado. Os centros de dados eram geridos por especialistas da empresa de outsourcing CBRE Managed Services, por isso a British Airways tentou recuperar o valor dos danos atrav\u00e9s da corte de Londres. <\/p>\n

\n\"A<\/p>\n

Faltas de energia ocorrem de forma semelhante: primeiro h\u00e1 uma interrup\u00e7\u00e3o causada pelo fornecedor de eletricidade, \u00e0s vezes devido a condi\u00e7\u00f5es clim\u00e1ticas adversas ou problemas internos (incluindo erros humanos), e ent\u00e3o o sistema de energia ininterrupta n\u00e3o suporta a carga ou uma breve interrup\u00e7\u00e3o na sinusoide provoca falhas em muitos servi\u00e7os, cujo restabelecimento leva muito tempo e dinheiro. \u00c9 poss\u00edvel evitar tais falhas? Sem d\u00favida. Se o sistema for projetado corretamente, no entanto, at\u00e9 mesmo os criadores de grandes datacenters n\u00e3o est\u00e3o isentos de erros. <\/p>\n

<\/p>\n

Fator humano<\/h2>\n

<\/p>\n

Quando a causa imediata do incidente \u00e9 a a\u00e7\u00e3o inadequada da equipe do datacenter, os problemas geralmente (mas nem sempre) afetam a parte de software da infraestrutura de TI. Esses acidentes acontecem at\u00e9 mesmo em grandes corpora\u00e7\u00f5es. Em fevereiro de 2017, devido a um comando digitado incorretamente por um membro da equipe t\u00e9cnica de um dos datacenters, parte dos servidores da Amazon Web Services foi desligada. O erro ocorreu durante a depura\u00e7\u00e3o do processo de faturamento para os clientes do servi\u00e7o de armazenamento em nuvem Amazon Simple Storage Service (S3). O colaborador tentava remover um determinado n\u00famero de servidores virtuais utilizados pelo sistema de faturamento, mas atingiu um cluster maior.<\/p>\n

\n\"A<\/p>\n

Como resultado do erro do engenheiro, servidores que hospedavam m\u00f3dulos importantes do servi\u00e7o de armazenamento em nuvem da Amazon foram deletados. Em primeiro lugar, o subsistema de indexa\u00e7\u00e3o, que continha informa\u00e7\u00f5es sobre metadados e localiza\u00e7\u00e3o de todos os objetos S3 na regi\u00e3o americana US-EAST-1, foi afetado. O incidente tamb\u00e9m impactou o subsistema utilizado para armazenar dados e gerenciar o espa\u00e7o de armazenamento dispon\u00edvel. Ap\u00f3s a exclus\u00e3o das m\u00e1quinas virtuais, esses dois subsistemas exigiram um rein\u00edcio completo, e em seguida os engenheiros da Amazon enfrentaram uma surpresa \u2014 durante um longo per\u00edodo, o servi\u00e7o de armazenamento em nuvem p\u00fablico n\u00e3o conseguiu atender aos pedidos dos clientes. <\/p>\n

<\/p>\n

O efeito foi significativo, pois muitos grandes recursos utilizam o Amazon S3. As falhas afetaram o Trello, Coursera, IFTTT e, o que \u00e9 ainda mais preocupante, os servi\u00e7os de grandes parceiros da Amazon na lista do S&P 500. Calcular os danos nessas situa\u00e7\u00f5es \u00e9 complicado, mas a estimativa girou em torno de centenas de milh\u00f5es de d\u00f3lares. Como voc\u00ea pode ver, para derrubar o servi\u00e7o da maior plataforma de nuvem, uma \u00fanica linha de comando errada \u00e9 suficiente. Este n\u00e3o \u00e9 um caso isolado, em 16 de maio de 2019, durante manuten\u00e7\u00e3o programada, o servi\u00e7o Yandex.Cloud removeu<\/a><\/noindex> m\u00e1quinas virtuais de usu\u00e1rios na zona ru-central1-c que estiveram uma vez no status SUSPENDED. Aqui, os dados dos clientes j\u00e1 foram comprometidos, parte dos quais foi permanentemente perdida. Claro, as pessoas n\u00e3o s\u00e3o perfeitas, mas os sistemas modernos de seguran\u00e7a da informa\u00e7\u00e3o j\u00e1 podem controlar as a\u00e7\u00f5es de usu\u00e1rios privilegiados antes da execu\u00e7\u00e3o de seus comandos. Se solu\u00e7\u00f5es como essas forem implementadas na Yandex ou na Amazon, incidentes semelhantes poder\u00e3o ser evitados.<\/p>\n

\n\"A<\/p>\n

Resfriamento congelado<\/h2>\n

<\/p>\n

Em janeiro de 2017, ocorreu um grande acidente no data center da empresa \u2018MegaFon\u2019 em Dmitrov. Naquela \u00e9poca, a temperatura na regi\u00e3o de Moscou caiu para -35 \u00b0C, o que levou \u00e0 falha dos sistemas de resfriamento da instala\u00e7\u00e3o. O servi\u00e7o de imprensa da operadora n\u00e3o divulgou amplamente as causas do incidente \u2014 as empresas russas s\u00e3o extremamente relutantes em falar sobre acidentes em suas instala\u00e7\u00f5es; em termos de transpar\u00eancia, estamos muito atr\u00e1s do Ocidente. Nos meios sociais, havia uma vers\u00e3o de que o fluido de aquecimento havia congelado nos tubos enterrados nas ruas, resultando na fuga de etilenoglicol. Se acreditarmos nisso, o servi\u00e7o de manuten\u00e7\u00e3o n\u00e3o conseguiu obter rapidamente 30 toneladas de refrigerante devido ao longo feriado e teve que improvisar usando recursos dispon\u00edveis, organizando um resfriamento improvisado, violando as regras de opera\u00e7\u00e3o do sistema. O frio intenso agravou o problema - em janeiro, a R\u00fassia passou a ter uma inesperada onda de frio, embora ningu\u00e9m a esperasse. No final, a equipe teve que desligar parte dos racks de servidores, o que fez com que alguns servi\u00e7os da operadora ficassem indispon\u00edveis por dois dias. <\/p>\n

\n\"A<\/p>\n

Provavelmente, aqui tamb\u00e9m se pode falar de anomalias meteorol\u00f3gicas, mas temperaturas t\u00e3o baixas n\u00e3o s\u00e3o incomuns para a regi\u00e3o metropolitana. No inverno, a temperatura em Moscou pode cair ainda mais, por isso, os data centers s\u00e3o projetados para operar de forma est\u00e1vel a \u221242\u00b0C. Com frequ\u00eancia, os sistemas de resfriamento falham no frio devido \u00e0 concentra\u00e7\u00e3o insuficiente de glic\u00f3is e ao excesso de \u00e1gua na solu\u00e7\u00e3o do fluido t\u00e9rmico. Problemas com a instala\u00e7\u00e3o de tubula\u00e7\u00f5es ou erros de c\u00e1lculo no projeto e teste do sistema tamb\u00e9m ocorrem, geralmente relacionados ao desejo de economizar. Como resultado, ocorre um acidente s\u00e9rio que poderia ser evitado.<\/p>\n

<\/p>\n

Desastres naturais <\/h2>\n

<\/p>\n

Com frequ\u00eancia, tempestades e\/ou furac\u00f5es interrompem a opera\u00e7\u00e3o da infraestrutura do data center, levando \u00e0 parada dos servi\u00e7os e\/ou danos f\u00edsicos aos equipamentos. Incidentes provocados por condi\u00e7\u00f5es meteorol\u00f3gicas adversas ocorrem com bastante frequ\u00eancia. Em 2012, o furac\u00e3o Sandy passou pela costa oeste dos EUA, trazendo fortes chuvas. O data center da Peer 1, localizado em um edif\u00edcio alto no Lower Manhattan, perdeu a alimenta\u00e7\u00e3o el\u00e9trica externa<\/a><\/noindex>, ap\u00f3s a \u00e1gua do mar salgada inundar os por\u00f5es. Os geradores de emerg\u00eancia estavam localizados no 18\u00ba andar, e o fornecimento de combust\u00edvel para eles era limitado \u2014 as regras implementadas em Nova York ap\u00f3s os ataques de 11 de setembro pro\u00edbem o armazenamento de grandes quantidades de combust\u00edvel nos andares superiores. <\/p>\n

\n