Confiabilidade na Solução Azure VMware

A Solução Azure VMware Gen 1 suporta zonas de disponibilidade através de clusters estendidos, que distribuem os hosts ESXi entre duas zonas de disponibilidade dentro de uma região. A Microsoft seleciona as zonas a utilizar. O teu cluster corre numa configuração ativo-ativo nas duas zonas, e o vSAN também abrange várias zonas. Pode indicar se cada carga de trabalho está distribuída em uma ou duas zonas.

Um nó testemunha é automaticamente implantado numa terceira zona de disponibilidade para garantir quórum em cenários de cérebro dividido. A Microsoft gere automaticamente o nó testemunho.

Um cluster padrão é aquele que não se estende por várias zonas. Num cluster padrão, o cluster e todos os seus hospedeiros ESXi são considerados não zonais ou regionais. Clusters não zonais podem ser colocados em qualquer zona de disponibilidade dentro da região e a Microsoft seleciona essa zona. Se uma zona de disponibilidade na região sofrer uma falha, agrupamentos e hospedeiros não zonais podem estar na zona afetada e podem sofrer tempo de inatividade.

O Azure VMware Solution Gen 2 suporta implementações zonais de clouds privadas. Quando configuras uma cloud privada zonal, cada um dos seus clusters e todos os seus hosts ESXi são implementados numa única zona de disponibilidade que selecionas.

Uma cloud privada zonal não protege contra falhas nas zonas de disponibilidade. Pode implementar várias clouds privadas em zonas de disponibilidade separadas para maior resiliência, mas é responsável por implementar e configurar cada cloud privada de forma independente.

Se não selecionares uma zona de disponibilidade, a tua cloud privada, os seus clusters e todos os seus hosts ESXi são considerados não zonais ou regionais. Clusters não zonais podem ser colocados em qualquer zona de disponibilidade dentro da região e a Microsoft seleciona essa zona. Se uma zona de disponibilidade na região sofrer uma interrupção, agrupamentos não zonais podem estar na zona afetada e sofrer períodos de inatividade.

• Apoio regional: Clusters esticados estão disponíveis em regiões Azure selecionadas que suportam a configuração de clusters alongados. Verifique a tabela de mapeamento de zonas de disponibilidade de regiões Azure para o tipo de host para o suporte atual de região.

• Número mínimo de anfitriões: Implante um mínimo de seis hosts em duas zonas de disponibilidade (três hosts por zona) para permitir uma configuração de cluster estendida. Quando se escala para dentro ou para fora, tem de escalar em pares para que o número de anfitriões seja igual em cada zona.

• SKUs de host: Clusters esticados são suportados com tipos de host AV36, AV36P e AV52. O SKU AV64 não é suportado com clusters estendidos.

Apoio regional: Pode implementar clouds privadas zonais em regiões que suportem Azure VMware Solution Gen 2 e também zonas de disponibilidade.

Considerações

Cada zona de disponibilidade numa região pode suportar tipos específicos de hospedeiros. Para uma lista detalhada dos tipos de hosts disponíveis em cada zona, consulte a tabela de mapeamento de zonas de disponibilidade de região para tipos de host Azure.

• Implementar um novo cluster: Quando cria uma nova cloud privada Azure VMware Solution numa região suportada, pode configurá-la como um cluster estendido durante a implementação. Esta configuração distribui os hosts automaticamente entre duas zonas de disponibilidade. Para obter mais informações, consulte Implementar clusters expandidos vSAN.

• Clusters existentes: Não se pode converter um cluster padrão num cluster alongado, nem se pode converter um cluster alongado num cluster padrão. Em vez disso, precisa de implementar um novo cluster e migrar as suas cargas de trabalho.

• Implementar um novo cluster: Quando cria uma nova cloud privada Azure VMware Solution numa região suportada, pode selecionar a sua zona de disponibilidade.

• Clusters existentes: Não podes alterar a configuração da zona de disponibilidade de um cluster existente. Em vez disso, precisa de implementar um novo cluster e migrar as suas cargas de trabalho.

Esta secção descreve o que esperar quando o seu cluster está sobrecarregado e todas as zonas de disponibilidade estão operacionais.

• Operação entre regiões: As VMs podem funcionar em hosts em qualquer uma das zonas de disponibilidade. A colocação das VMs pode ser controlada usando regras de afinidade e anti-afinidade do vSphere DRS para otimizar requisitos de desempenho ou disponibilidade.

• Replicação de dados entre regiões: o vSAN replica os dados de forma síncrona entre zonas de disponibilidade. Cada operação de escrita é confirmada por ambas as zonas antes da conclusão, garantindo uma integridade consistente dos dados.

Esta secção descreve o que esperar quando o seu cluster é implementado numa nuvem privada zonal e todas as zonas de disponibilidade estão operacionais.

• Operação entre regiões: As VMs funcionam em hosts dentro da zona de disponibilidade do cluster.

• Replicação de dados entre regiões: Nenhum dado é replicado para outra zona.

Esta secção descreve o que esperar quando o seu cluster está sobrecarregado e ocorre uma falha na zona de disponibilidade.

• Deteção e resposta: O Azure VMware Solution gere a resposta ao nível da infraestrutura a falhas de zona. O vSphere HA deteta automaticamente falhas de zona e inicia procedimentos de reinício da VM, se necessário.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar o Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Service Health para o notificar de problemas.

• Pedidos ativos: Todas as VMs em execução na zona de disponibilidade interrompida são reiniciadas em hosts na zona de disponibilidade sobrevivente. Os pedidos ativos e as ligações às VMs afetadas são terminados, e os clientes são responsáveis por os tentar novamente.

• Tempo de inatividade previsto: O tempo para reiniciar VMs falhadas na zona saudável é normalmente de alguns minutos, dependendo da configuração da VM e dos procedimentos de arranque. O conjunto esticado mantém-se operacional com capacidade reduzida.

  Se a zona de disponibilidade falhada contiver o nó testemunha, a testemunha torna-se inacessível. Enquanto houver réplicas de dados suficientes disponíveis, os anfitriões de dados e cargas de trabalho em execução continuam a operar sem perda imediata de dados. No entanto, o vSAN perde a consciência do quórum neste estado, o que o impede de tomar decisões seguras de colocação e recuperação, fazendo com que certas operações sejam bloqueadas, como a ligação da VM após falhas, o reequilíbrio e as reparações.

• Perda de dados esperada: Como o vSAN utiliza replicação síncrona entre zonas, não se espera perda de dados durante uma falha de zona.

• Redistribuição: o vSphere DRS redistribui automaticamente as cargas de trabalho das VMs para a zona de disponibilidade sobrevivente. O encaminhamento do tráfego de rede através do VMware NSX adapta-se automaticamente à nova posição da VM.

Esta secção descreve o que esperar quando o seu cluster é implementado numa nuvem privada zonal e ocorre uma falha na zona de disponibilidade.

• Deteção e resposta: É preciso detetar a perda de uma zona de disponibilidade. Se necessário, pode iniciar um failover para um cluster secundário que precriou noutra zona de disponibilidade.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar o Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Service Health para o notificar de problemas.

• Pedidos ativos: Os pedidos ativos e as ligações às VMs afetadas são terminados, e os clientes são responsáveis por os tentar novamente.

• Tempo de inatividade previsto: Quando uma zona está indisponível, o seu cluster e as suas cargas de trabalho ficam indisponíveis até que a zona de disponibilidade recupere.

• Perda de dados esperada: Os dados na zona afetada não estão disponíveis até que a zona recupere.

• Redistribuição: És responsável por transferir o tráfego para outros clusters em zonas saudáveis, se necessário.

Quando a zona de disponibilidade recupera, o vSphere DRS pode opcionalmente redistribuir VMs de volta para a zona recuperada com base nas regras de configuração e afinidade do seu DRS. Também pode controlar manualmente a colocação da VM usando operações vMotion.

Quando a zona de disponibilidade recupera, os clusters e anfitriões dessa zona ficam novamente disponíveis. Você é responsável por todos os procedimentos de recuperação de zona e sincronização de dados que suas cargas de trabalho exigem.

• Testar a resiliência das aplicações a reinicializações de VMs e alterações no caminho da rede, especialmente quando tens clusters esticados ou implementas aplicações em clusters separados em zonas diferentes.

Como o Azure VMware Solution gere a resposta da infraestrutura a falhas de zona, precisa principalmente de testar a resposta da sua aplicação aos reinícios da VM.

És responsável por qualquer resposta de infraestrutura a falhas de zona, como failover para outro cluster numa zona ou região diferente. Certifique-se de testar cuidadosamente os seus processos de resposta.

Clusters configurados como clusters esticados têm um SLA de infraestrutura de disponibilidade de carga de trabalho mais elevado.