DevSecOps

4 out, 2018

Alta disponibilidade no Azure

Publicidade

Como de conhecimento, no dia 04 de setembro de 2018, o Azure passou por algumas dificuldades técnicas e instabilidades no DataCenter Central Sul dos Estados Unidos. De acordo com a página oficial de status do Azure, um evento climático ocorreu perto do DataCenter do centro-sul dos EUA.

Isso resultou em uma oscilação de energia que afetou os sistemas de resfriamento do DataCenter. Devido aos fatos, procedimentos automatizados entraram em ação para manter a integridade da estrutura da plataforma causando então um processo automático de desligamento.

A severe weather event, including lightning strikes, occurred near one of the South Central US datacenters. This resulted in power voltage fluctuations that impacted the data center cooling systems. Automated procedures to ensure data and hardware integrity went into effect and critical hardware entered a structured power-down process.

Para quem utiliza este DataCenter como local de hospedagem dos recursos, consequentemente teve todos os sistemas instáveis, ou totalmente fora do ar. Digo isto, pois mesmo não utilizando essa região como local de hospedagem das aplicações no qual eu trabalho, sofremos com outros recursos que também foram afetados, como o VSTS (Visual Studio Team Services).

Tanto o Azure como qualquer outro player de Cloud está sujeito a este tipo de problema, uma vez que eventos climáticos podem acontecer a qualquer momento, e não estamos 100% protegidos deste tipo de situação. Mas como podemos resolver essa questão?

Quando estamos em um cenário de Cloud, temos a vantagem de ter nossos ambientes em múltiplas regiões. Porém, nem todos os serviços contam com replicação automática, como o Azure SQL e CosmosDB, onde podemos ativar a replicação geográfica.

No caso das aplicações, precisamos pensar em uma estratégia de Deploy Bi-Direcional para manter os dois ambientes sempre atualizados, quando trabalhamos com um processo de Integração Contínua e Deploy Contínuo. Isso tudo fica mais fácil, pois todo o processo de publicação é feito de forma automatizada.

Pensando na solução descrita acima, segue abaixo os pontos principais para montar este ambiente de forma mais simples possível.

  • Ambiente Primário e Secundário — Será necessário criar um ambiente em uma região e replicá-lo em outra região. Ex.: Ambiente Primário na Região Central Sul do EUA e Ambiente Secundário na Região Leste ou Oeste, ou até mesmo outra região como o Sul do Brasil.
  • Geo Replicação — Use a Replicação Geográfica para criar uma réplica secundária em uma região diferente caso esteja utilizando SQL Server ou Cosmos DB
  • Azure Traffic Manager — O Traffic Manager tem como principal finalidade direcionar o Request de Entrada para o endereço primário que determinarmos nas configurações, caso o mesmo esteja indisponível, automaticamente ele desviará o fluxo para o endereço secundário.
  • Estratégias de Deploy — Para manter a aplicação sempre atualizada na segunda região, podemos utilizar de alguns meios para este fim. Caso você utilize um processo de Deploy Contínuo, podemos publicar de forma bem rápida, pois o procedimento é automatizado. Uma das maneiras para resolvermos essa questão seria a utilização do VSTS, uma das ferramentas mais completas em uma cultura de DevOps.

Abaixo segue um diagrama retirado da documentação oficial do Azure. Inclusive essa abordagem acima foi elaborada a partir dessa documentação. É muito importante lembrar que existem algumas recomendações em cima de cada tópico descrito acima, no qual você pode encontrar diretamente nesta mesma documentação.

Azure Alta Disponibilidade Modelagem

Pessoal, por hoje é só. Espero ter ajudado a todos, e se tiverem alguma dúvida, deixem um comentário logo abaixo!

Referências