Descrever os recursos de alta disponibilidade e de recuperação de desastre do Azure para Máquinas Virtuais do Azure
O Azure oferece três opções principais para aprimorar a disponibilidade para implantações de IaaS:
Conjuntos de Disponibilidade
Zonas de Disponibilidades
Azure Site Recovery
Todas essas três opções são externas à VM (máquina virtual) e não sabem que tipo de carga de trabalho está sendo executada nela.
Conjuntos de disponibilidade
Os conjuntos de disponibilidade fornecem tempo de atividade para a manutenção relacionada ao Azure e pontos únicos de falha em um só data center. Esse foi um dos primeiros recursos de disponibilidade introduzidos na plataforma do Azure e pode efetivamente ser considerado como regras antiafinidade para suas VMs. Isso significa que, se você tiver duas VMs do SQL Server em um conjunto de disponibilidade ou em um par de envio de logs, haverá a garantia de que elas nunca serão executadas no mesmo servidor físico.
Os conjuntos de disponibilidade são separados em domínios de falha e domínios de atualização para dar suporte a ambas as atualizações à infraestrutura subjacente do Azure. Os domínios de falha são conjuntos de servidores em um data center que usam a mesma fonte de alimentação e a mesma rede. Pode haver até três domínios de falha em um data center, conforme descrito na imagem abaixo por FD 0, 1 e 2. Domínios de atualização, denotados por UD na imagem abaixo, indicam grupos de máquinas virtuais e o hardware físico subjacente que podem ser reinicializados ao mesmo tempo. Domínios de atualização diferentes garantem a separação.
As zonas e os conjuntos de disponibilidade não protegem contra falhas no convidado, como uma falha de SO ou do RDBMS. Por isso, é preciso implementar soluções adicionais, como AGs ou FCIs, para garantir o cumprimento dos RTOs e dos RPOs. As zonas e os conjuntos de disponibilidade são projetados para limitar o impacto de problemas ambientais no nível do Azure, como falha de datacenter, falha de hardware físico, interrupções de rede e interrupções de energia.
Para um aplicativo de várias camadas, você deve colocar cada camada do aplicativo no próprio conjunto de disponibilidade. Por exemplo, se você estivesse criando um aplicativo Web com um back-end SQL Server juntamente com o AD DS (Active Directory Domain Services), criaria um conjunto de disponibilidade para cada camada (Web, banco de dados e AD DS).
Os conjuntos de disponibilidade não são a única maneira de separar VMs de IaaS. O Azure também fornece Zonas de Disponibilidade, mas não é possível combinar as duas opções. Você precisa escolher uma ou outra.
Zonas de disponibilidade
As zonas de disponibilidade consideram falha no nível de data center no Azure. Cada região do Azure consiste em muitos data centers com conexões de rede de baixa latência entre eles. Ao implantar recursos da VM em uma região com suporte a Zonas de Disponibilidade, você tem a opção de implantar esses recursos na zona 1, 2 ou 3. Uma zona é uma localização física exclusiva, ou seja, uma data center, em uma região do Azure.
Os números de zona são representações lógicas. Por exemplo, se dois assinantes do Azure implantam uma VM na Zona 1, cada um em sua respectiva assinatura, isso não significa que essas VMs existem no mesmo data center físico do Azure. Além disso, devido à distância, pode ser introduzida uma latência adicional em implantações zonais. Você deve testar a latência entre as VMs para garantir que a latência cumpra os objetivos de desempenho. Na maioria dos casos, a latência de ida e volta será menor que um milissegundo, o que dá suporte à movimentação de dados síncrona em recursos como grupos de disponibilidade. Você também pode implantar o Banco de Dados SQL do Azure em Zonas de Disponibilidade.
Azure Site Recovery
O Azure Site Recovery fornece disponibilidade aprimorada para VMs no nível do Azure e pode funcionar com VMs que hospedam o SQL Server. O Azure Site Recovery replica uma VM de uma região do Azure para outra para criar uma solução de recuperação de desastre para essa VM. Conforme observado anteriormente, esse recurso não sabe que o SQL Server está em execução na VM e não sabe nada sobre transações. Embora o Azure Site Recovery possa cumprir o RTO, talvez não atenda ao RPO, pois não é responsável pelo local em que os dados estão dentro do SQL Server. O Azure Site Recovery tem um RTO mensal declarado de duas horas. Embora a maioria dos profissionais de banco de dados possa preferir usar um método baseado em banco de dados para recuperação de desastres, o Azure Site Recovery funcionará bem se atender às suas necessidades de RTO e RPO.