GCNBRASIL.

Gestão de Crises e Continuidade dos Negócios

  • Increase font size
  • Default font size
  • Decrease font size

Lições para GCN da recente interrupção do Azure

Email Print PDF

Em 4 de setembro de 2018, as tempestades que atingiram o sul do Texas resultaram na inatividade do datacenter da Microsoft, o que teve impactos indiretos também em serviços executados em outras localidades. Analisamos neste artigo o incidente e as lições que podem ser aprendidas com ele.

Atualmente serviços em nuvem, como o Azure, são essenciais para muitas organizações, portanto, qualquer período de inatividade pode causar problemas relacionados a continuidade dos negócios. Uma grande paralisação, como a ocorrida em 4 de setembro, lembra às organizações que apesar dos serviços em nuvem serem confiáveis, as interrupções são possíveis e precisam ser previstas.  Este texto considera as possíveis ações preparatórias que as organizações podem desenvolver.

A interrupção

A Microsoft explicou os motivos da interrupção da seguinte forma:
“No início da manhã de 4 de setembro de 2018, tempestades extremamente fortes atingiram o sul do Texas, próximo as instalações da Microsoft. Vários datacenters do Azure na região registraram oscilações e quedas de tensão na rede de transmissão da concessionária. Às 08:42, um raio causou grandes variações de tensão na distribuição de energia.  Essas variações de tensão fizeram que uma parte de um datacenter do Azure passasse a utilizar energia proveniente de seus geradores.  Além disso, essas oscilações de energia desligaram os sistemas de resfriamento do datacenter, apesar de existirem supressores de surtos instalados.  Inicialmente, o datacenter conseguiu manter sua temperatura operacional por meio de um buffer térmico utilizado dentro do sistema de resfriamento.  No entanto, quando esse buffer térmico foi esgotado, a temperatura do datacenter excedeu os limites operacionais seguros e um desligamento automático dos dispositivos foi iniciado.  Esse mecanismo de desligamento destina-se a preservar a integridade da infraestrutura e dos dados, mas, nesse caso, as temperaturas aumentaram tão rapidamente em partes do datacenter que alguns equipamentos foram danificados antes que pudessem ser desligados.  Um número significativo de servidores de armazenamento foi danificado, bem como um pequeno número de ativos de rede e unidades de energia.
Enquanto a tempestade ainda estava acontecendo, as equipes locais tomaram uma série de ações para evitar mais danos - incluindo a transferência do restante do datacenter para os geradores, estabilizando assim o fornecimento de energia.  Para iniciar a recuperação da infraestrutura, primeiramente foram recuperados os balanceadores de carga (SLB) do Azure.  Os serviços SLB são essenciais para a rede do Azure, gerenciando o roteamento do tráfego dos clientes e da plataforma.  Num segundo momento foram recuperados os servidores de armazenamento e os dados armazenados.  Isso envolveu a substituição dos componentes de infraestrutura que falharam, a migração de dados de clientes dos servidores danificados para servidores íntegros e a validação de integridade destes dados.  Esse processo demandou algum tempo devido ao número de servidores danificados e à necessidade de trabalhar com cuidado para manter a integridade dos dados dos clientes.  A decisão foi tomada visando à recuperação de dados e não a transferência dos serviços para outro datacenter, uma vez que isso poderia resultar na perda de dados devido à natureza assíncrona da replicação geográfica.
Apesar das redundâncias existentes no local, há cenários em que uma falha de resfriamento no datacenter pode afetar a carga de trabalho dos clientes. Infelizmente, esse conjunto específico de problemas também causou um impacto em cascata nos serviços executados fora da região atingida.”

Possíveis medidas de continuidade dos negócios

Diante do ocorrido, o que as organizações poderiam ter feito para minimizar o impacto dessa interrupção?  Ninguém pode culpar a Microsoft por um desastre natural, como um relâmpago.  Mas no final do dia, se seu único plano de recuperação de desastre for ligar, enviar um tweet ou um e-mail para a Microsoft até que o problema seja resolvido, você acaba percebendo que nada disso adianta.  Cabe a você garantir que os planos de continuidade e de recuperação de desastres do seu negócio estejam preparados para este tipo de incidente. Aqui estão alguns dos meus pensamentos iniciais sobre as possíveis medidas de continuidade e as questões levantadas por este incidente:

Conjuntos de Disponibilidade - nesse cenário, mesmo se você criou Clusters ou Balanceadores de Carga do Azure, se a região inteira ficar offline, você ainda estaria offlline.  Embora seja recomendável utilizar os Conjuntos de Disponibilidade, especialmente para a inatividade planejada, mas nesse caso específico, você ainda estaria offline.
Os conjuntos de disponibilidade garantem que as VMs implantadas no Azure sejam distribuídas entre vários nós de hardware isolados em um cluster.

Zonas de disponibilidade - embora ainda não esteja disponível na região centro-sul dos EUA, parece que o conceito de Zonas de disponibilidade implantadas no Azure poderia ter minimizado o impacto da indisponibilidade.  Supondo que a queda de raios tenha impactado apenas um data center, outro data center em outra outra zona de disponibilidade deve ter permanecido operacional.  No entanto, as interrupções de outros serviços não regionais, como o Active Directory do Azure (AAD), parecem ter sido afetadas, portanto, não acredito que o Availability Zones tenha isolado completamente este problema.

Balanceadores de carga globais, clusters de failover em regiões cruzadas, etc. - esteja você criando clusters SANLess que cruzam regiões ou usando balanceadores de carga globais para distribuir a carga em várias regiões, você pode minimizar o impacto, mas você ainda pode ser afetado pela interrupção do AAD.

Nuvem híbrida, nuvem cruzada - a única maneira de garantir a resiliência em um cenário de falha na nuvem é ter um plano de recuperação de desastre que inclua replicação de dados em tempo real para um local fora de seu provedor de nuvem principal e um plano que possibilite a utilização de aplicativos on-line desse outro local.  Esses dois locais devem ser totalmente independentes e não devem depender de serviços de seu local principal para estarem disponíveis, como o AAD.  O local de recuperação de desastre pode ser em outro provedor de nuvem, nesse caso, a AWS ou o Google Cloud Platform parecem alternativas lógicas ou você pode utilizar seu próprio data center, mas isso acaba com o propósito de executar serviços na nuvem.

Software como serviço - enquanto softwares as a service como o Azure Active Directory (ADD), o Banco de Dados SQL do Azure (Database-as-Service) ou uma das muitas ofertas de SaaS de qualquer um dos provedores de nuvem podem parecer atraentes, você realmente precisa planejar para o pior cenário. Como você pode confiar um aplicativo essencial aos seus negócios para um único fornecedor, isso pode reduzir suas opções de DR, o que inclui a recuperação FORA do provedor de serviços em nuvem atual.  Eu não tenho nenhum conselho a dar, além de investigar suas opções de DR antes de implementar qualquer serviço do tipo SaaS, e se a recuperação fora da nuvem não for uma opção, pense bastante antes de contratar este serviço.  No mínimo, conscientize as partes interessadas de que, se o provedor de serviços de nuvem tiver um dia realmente ruim e esse serviço estiver off-line, talvez não haja nada que você possa fazer a não ser ligar e reclamar.

Acredito que em um futuro muito próximo você começará a ouvir mais e mais sobre a disponibilidade de nuvem cruzada e sobre as pessoas que utilizam soluções para construir estratégias robustas de Alta Disponibilidade e Recuperação de Desastres que cruzam provedores de nuvem. Os modelos de nuvens cruzadas ou de nuvem híbrida são a única maneira de realmente se preparar para as interrupções mais prováveis dos serviços que estão na nuvem.

Tradução livre do artigo de Dave Bermingham.
Fonte: https://www.continuitycentral.com

 

PUBLICIDADE


Translate

Portuguese English French German Italian Spanish

Creative Commons License
Site GCNBRASIL - Creative Commons Atribuição-Uso Não-Comercial-Vedada a Criação de Obras Derivadas 2.5 Brasil License.