O Azure tem algumas formas de alta disponibilidade, e quando fazemos arquitetura para algum cliente sempre é importante ter isto em mente, pois caso exista alguma falha no datacenter principal que está alocado determinado recurso. Pode causar prejuízo para o cliente.

A alta disponibilidade em alguns casos é algo que deve também ser debatido com o cliente, pois pode gerar um custo, que talvez o cliente não esteja ciente.

Tipos de alta disponibilidade

Quando falamos de alta disponibilidade no Azure temos que avaliar alguns pontos:

SLA;

Custo;

Recurso possuí disponibilidade em todas as regiões.

Availability Set

A primeira parte de disponibilidade no Azure é o Availability set. Que basicamente coloca os recursos em racks diferentes.

Neste momento temos apenas a alta disponibilidade de hardware, caso ocorra algum problema com algum rack no datacenter do Azure e a Vm 01 ficar indisponível a 02 continuará ativa.

Este tipo de disponibilidade pode ser importante para algumas cargas de trabalho, porém para ambientes de “missão crítica” não é recomendado está arquitetura.

Availability Zone

O availability Zone são 2 ou mais datacenters equivalentes do Azure dentro de uma região, separados por KMs de distância.

Quando configuramos 01 VM por exemplo, temos a opção de replicar está VM para uma segunda ou terceira zona da mesma região.

Quando a VM por exemplo está sendo replicada, e temos uma interrupção na zona primária, a zona secundária assume. Desta forma não temos problema de uma aplicação por exemplo ficar fora por algum desastre natural ou, outro tipo de problema.

Neste caso temos que avaliar quais datacenters possuem zonas de replicação, porém como dito anteriormente para ambientes em “missão crítica” também não é recomendado. Caso a região toda do Azure tenha algum problema, o ambiente como todo pode ficar fora.

Disaster Recovery

Neste modelo temos a possibilidade de replicar as cargas de trabalho para uma outra região do Azure. Neste caso não somente de Azure para Azure, como de Hyper-v e VMware também.

Para ambientes de “missão crítica” é o mais recomendado, evitando diversos problemas mencionados acima.

Conclusão

Sempre que vamos fazer uma arquitetura para cliente, devemos pensar em inúmeros fatores como mencionei acima, porém também devemos conhecer a tecnologia. Não no nível de nos tornarmos especialistas, mas sim qual o suporte que tem dentro do Azure ou outra cloud, qual o nível de disponibilidade, tipo de replicação

Um exemplo claro disto é a replicação de Active Directory é diferente da suportada pelo AKS por exemplo, isto influência na arquitetura. Neste caso é sempre importante entender se a aplicação ou, produto de terceiro funciona de forma esperada quando falamos de DR e zona de redundância.