Descrever os recursos de alta disponibilidade e recuperação de desastres do Azure para Máquinas Virtuais do Azure
O Azure fornece três opções principais para melhorar a disponibilidade para implantações IaaS:
Conjuntos de Disponibilidade
Zonas de Disponibilidade
Azure Site Recovery
Todas essas três opções são externas à máquina virtual (VM) e não sabem que tipo de carga de trabalho está sendo executada dentro dela.
Conjuntos de disponibilidade
Os conjuntos de disponibilidade fornecem tempo de atividade em relação à manutenção relacionada ao Azure e pontos únicos de falha em um único data center. Este foi um dos primeiros recursos de disponibilidade introduzidos na plataforma Azure e, efetivamente, pode ser considerado como regras de antiafinidade para suas VMs. Isso significa que, se você tivesse duas VMs do SQL Server em um conjunto de disponibilidade ou par de envio de logs, elas teriam a garantia de nunca serem 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 para a Infraestrutura do Azure subjacente. Domínios de falha são conjuntos de servidores dentro de um data center, que usam a mesma fonte de energia e 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. Os domínios de atualização, indicados pela UD na imagem abaixo, indicam grupos de máquinas virtuais e hardware físico subjacente que podem ser reinicializados ao mesmo tempo. Diferentes domínios de atualização garantem a separação.
Os conjuntos e zonas de disponibilidade não protegem contra falhas no convidado, como uma falha do SO ou RDBMS; é por isso que você precisa implementar soluções adicionais, como AGs ou FCIs, para garantir que você atenda aos RTOs e RPOs. Os conjuntos de disponibilidade e as zonas 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 em seu próprio conjunto de disponibilidade. Por exemplo, se você estivesse criando um aplicativo Web que tenha um back-end do SQL Server junto com os Serviços de Domínio Ative Directory (AD DS), 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 IaaS. O Azure também fornece Zonas de Disponibilidade, mas as duas não podem ser combinadas. Você pode escolher um ou outro.
Zonas de disponibilidade
As zonas de disponibilidade são responsáveis por falhas no nível do 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 de VM em uma região que ofereça suporte a Zonas de Disponibilidade, você tem a opção de implantar esses recursos na Zona 1, 2 ou 3. Uma zona é um local físico exclusivo, ou seja, um data center, dentro de uma região do Azure.
Os números de zona são representações lógicas. Por exemplo, se dois assinantes do Azure implantarem uma VM na Zona 1 em suas próprias assinaturas, isso não significa que essas VMs existam no mesmo data center físico do Azure. Além disso, devido à distância, pode haver alguma latência adicional introduzida em implantações zonais. Você deve testar a latência entre suas VMs para garantir que a latência atenda às metas de desempenho. Na maioria dos casos, a latência de ida e volta será inferior a 1 milissegundo, o que suporta a movimentação síncrona de dados 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 trabalhar 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 desastres para essa VM. Como observado anteriormente, esse recurso não sabe que o SQL Server está sendo executado na VM e não sabe nada sobre transações. Embora o Azure Site Recovery possa atender ao RTO, ele pode não atender ao RPO, pois não está contabilizando onde 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 prefira usar um método baseado em banco de dados para recuperação de desastres, o Azure Site Recovery funciona bem se atender às suas necessidades de RTO e RPO.