Compartilhar via


Confiabilidade no Solução VMware no Azure

Solução VMware no Azure fornece nuvens privadas que contêm clusters VMware vSphere criados a partir de infraestrutura de Azure bare-metal dedicada. Você pode migrar cargas de trabalho de seus ambientes locais, implantar novas VMs (máquinas virtuais) e consumir Azure serviços de suas nuvens privadas. Você pode usar uma combinação de recursos VMware e nativos de Azure para habilitar a alta disponibilidade e resiliência de suas cargas de trabalho.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar os Solução VMware no Azure resilientes a possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) Solução VMware no Azure.

Recomendações de implantação de produção

Solução VMware no Azure implantações exigem um planejamento cuidadoso em uma variedade de áreas e geralmente exigem vários serviços de Azure. Para obter mais informações, consulte Solução VMware no Azure workloads no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Solução VMware no Azure usa uma HCI (infraestrutura hiperconvergente) com clusters VMware vSphere.

Ao implantar Solução VMware no Azure, você implanta uma nuvem private, que tem um ou mais clusters. Cada cluster contém hosts ESXi que fornecem computação, armazenamento por meio de SAN virtual (vSAN) e rede por meio do VMware NSX. Há duas gerações de Solução VMware no Azure:

  • A Gen 1 utiliza hardware bare-metal especializado para os nós e adota abordagens de rede dedicadas. Para obter mais informações sobre os principais conceitos, consulte Solução VMware no Azure conceitos privados de nuvem e cluster.

  • Gen 2 usa tipos de VM Azure padrão e redes virtuais Azure. Essa arquitetura simplifica a arquitetura de rede, aprimora as velocidades de transferência de dados, reduz a latência das cargas de trabalho e melhora o desempenho quando você acessa outros serviços Azure.

Tolerância a falhas

Solução VMware no Azure fornece vários mecanismos para lidar com falhas no nível da infraestrutura e do aplicativo:

  • HA (alta disponibilidade do vSphere): a HA do vSphere monitora hosts ESXi e VMs. Se um host falhar, ele reiniciará automaticamente as VMs afetadas em hosts íntegros. A HA do vSphere é ativada por padrão e reserva capacidade de computação e memória para uma única falha de nó.

  • Tolerância a falhas vSAN: as políticas de armazenamento vSAN protegem contra falhas transitórias no nível do armazenamento, mantendo várias cópias de dados entre hosts. Se um caminho de armazenamento ou disco tiver problemas transitórios, o vSAN gerenciará automaticamente o failover para caminhos de armazenamento saudáveis.

  • Redundância de rede: A Solução VMware no Azure fornece caminhos de rede redundantes e vários adaptadores de rede VMkernel para lidar com falhas transitórias no nível da rede.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas Azure quando se comunicam com apis, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Para aplicativos executados em VMs Solução VMware no Azure, implemente práticas padrão para lidar com falhas transitórias:

  • Configure políticas de repetição apropriadas com retirada exponencial.

  • Use padrões de disjuntor para chamadas de serviço externas.

  • Monitore a integridade do aplicativo e implemente a degradação normal.

  • Crie aplicativos sem estado quando possível para reduzir o impacto das reinicializações de VM.

Resiliência a falhas de zona de disponibilidade

as zonas Availability são grupos fisicamente separados de datacenters em uma região Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Solução VMware no Azure Gen 1 dá suporte a zonas de disponibilidade por meio de clusters estendidos , que distribuem hosts ESXi em duas zonas de disponibilidade em uma região. Microsoft seleciona as zonas a serem usadas. O cluster opera em uma configuração ativa-ativa nas duas zonas, e o vSAN também se estende por várias zonas. Você pode designar se cada carga de trabalho é implantada em uma ou duas zonas.

Um nó de testemunha é implantado automaticamente em uma terceira zona de disponibilidade para fornecer quorum para cenários de divisão de cérebro. Microsoft gerencia o nó de testemunha automaticamente.

Diagrama que mostra um cluster estendido vSAN gerenciado que abrange duas zonas de disponibilidade e um nó testemunha em uma terceira zona de disponibilidade.

Na parte superior do diagrama, uma legenda indica que o logotipo do Microsoft Azure representa a plataforma Azure; um ícone de pino de localização, rotulado como zonas de disponibilidade dupla em uma região do Azure, representa duas zonas de disponibilidade; e um ícone de chave representa uma única assinatura do Azure. O diagrama é dividido em três seções principais. À esquerda, a zona de disponibilidade um é identificada como o local preferencial. À direita, a zona de disponibilidade dois é identificada como o local secundário. Na parte inferior, a zona de disponibilidade três é rotulada como o site testemunha. Uma caixa que representa a nuvem privada A do Solução VMware no Azure abrange as zonas de disponibilidade um e dois. Dentro da zona de disponibilidade 1, quatro componentes são organizados horizontalmente: um ícone de rack de servidor representa hosts ESXi bare-metal do Azure, um ícone de camadas empilhadas representa o domínio de falha preferido do datastore VMware vSAN, um ícone de servidor representa o servidor VMware vCenter e um ícone de topologia de rede representa VMware NSX. Um rótulo de armazenamento de dados vSAN estendido se estende horizontalmente entre ambas as zonas e conecta o domínio de falha preferencial do armazenamento de dados VMware vSAN na zona de disponibilidade um ao domínio de falha secundário do armazenamento de dados VMware vSAN na zona de disponibilidade dois. A metade inferior da zona de disponibilidade um contém três componentes organizados horizontalmente. Um ícone de selo circular representa o VMware NSX Edge A. Um ícone de rede de nuvem representa o VMware HCX. Um ícone de tela representa aplicativos SLA Gold. Na zona de disponibilidade dois, duas filas de componentes são organizadas horizontalmente. A linha superior inclui os hospedeiros ESXi bare-metal do Azure e o domínio de falha secundário do datastore VMware vSAN. A linha inferior contém aplicativos VMware NSX Edge B, Gold SLA colocados em uma caixa tracejada, um ícone de monitor que representa aplicativos SLA Silver e um ícone de monitor que representa aplicativos SLA Bronze. Uma linha pontilhada rotula a replicação síncrona baseada em políticas, conectando os aplicativos SLA Ouro na Zona de Disponibilidade 1 ao box de aplicativos SLA Ouro na Zona de Disponibilidade 2. Essa linha indica sincronização ou replicação entre esses aplicativos entre zonas. Linhas sólidas conectam a zona de disponibilidade um e a zona de disponibilidade dois a uma caixa rotulada como zona de disponibilidade três. Este é o local testemunha na parte inferior do diagrama. A zona de disponibilidade três contém um dispositivo de testemunha VMware vSAN.

Um cluster padrão é um cluster que não é estendido entre zonas. Em um cluster padrão, o cluster e todos os hosts ESXi são considerados nonzoais ou regionais. Os clusters não zonais podem ser colocados em qualquer zona de disponibilidade dentro da região, e a Microsoft é quem seleciona a zona. Se uma zona de disponibilidade na região sofrer uma interrupção, os clusters e hosts nonzonal poderão estar na zona afetada e poderão ter tempo de inatividade.

Solução VMware no Azure Gen 2 dá suporte a implantações zonal de nuvens privadas. Quando você configura uma nuvem privada zonal, cada um de seus clusters e todos os hosts ESXi são implantados em uma única zona de disponibilidade selecionada.

Uma nuvem privada zonal não protege contra falhas na zona de disponibilidade. Você pode implantar várias nuvens privadas em zonas de disponibilidade separadas para maior resiliência, mas é responsável por implantar e configurar cada nuvem privada de forma independente.

Se você não selecionar uma zona de disponibilidade, sua nuvem privada, seus clusters e todos os hosts ESXi serão considerados nonzoais ou regionais. Os clusters não zonais podem ser colocados em qualquer zona de disponibilidade dentro da região, e a Microsoft seleciona a zona. Se uma zona de disponibilidade na região sofrer uma interrupção, os clusters não zonais na zona afetada podem sofrer inatividade.

Para obter mais informações sobre o suporte à zona de disponibilidade para outras gerações, selecione a geração apropriada no início deste artigo.

Requirements

  • Region support: Clusters estendidos estão disponíveis apenas em regiões da Azure que dão suporte à configuração de clusters estendidos. Verifique a tabela de mapeamento de zona de disponibilidade para tipo de host da região do Azure para suporte à região atual.

  • Hosts mínimos: Implante um mínimo de seis hosts em duas zonas de disponibilidade (três hosts para cada zona) para habilitar a configuração de cluster estendido. Ao escalar ou reduzir horizontalmente, você deve dimensionar em pares para que cada zona tenha um número igual de hosts.

  • SKUs de host: Os tipos de host AV36, AV36P e AV52 dão suporte a clusters estendidos. O SKU AV64 não dá suporte a clusters estendidos.

Considerações

Cada zona de disponibilidade em uma região pode dar suporte a tipos de host específicos. Para obter uma lista detalhada dos tipos de host disponíveis em cada zona, consulte a tabela de mapeamento de zona de disponibilidade na região do Azure para tipo de host.

Custo

Você incorre em custos para cada nó no cluster, independentemente da configuração da zona de disponibilidade do cluster. Para obter informações detalhadas sobre preços, consulte Solução VMware no Azure preços.

Configurar o suporte à zona de disponibilidade

  • Implemente um novo cluster: Ao criar uma nova nuvem privada do Solução VMware no Azure em uma região suportada, você pode configurá-la como um cluster estendido durante a implantação. Essa configuração distribui hosts em duas zonas de disponibilidade automaticamente. Para obter mais informações, consulte Implantar clusters estendidos do vSAN.

  • Clusters existentes: Você não pode converter um cluster padrão em um cluster estendido e não pode converter um cluster estendido em um cluster padrão. Em vez disso, você precisa implantar um novo cluster e migrar suas cargas de trabalho.

  • Deploy um novo cluster: Ao criar uma nova nuvem privada Solução VMware no Azure em uma região com suporte, você pode selecionar sua zona de disponibilidade.

  • Clusters existentes: Não é possível alterar a configuração da zona de disponibilidade de um cluster existente. Em vez disso, você precisa implantar um novo cluster e migrar suas cargas de trabalho.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando o cluster está estendido e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: As VMs podem ser executadas em hosts em qualquer zona de disponibilidade. Você pode controlar o posicionamento da VM usando a afinidade do DRS (Agendador de Recursos Distribuídos) do vSphere e as regras anti-afinidade para otimizar os requisitos de desempenho ou disponibilidade.

  • Replicação de dados entre zonas: o vSAN replica dados de forma síncrona entre zonas de disponibilidade. Ambas as zonas confirmam cada operação de gravação antes de ela ser concluída para garantir a consistência da integridade dos dados.

Esta seção descreve o que esperar quando o cluster é implantado em uma nuvem privada zonal e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: As VMs são executadas em hosts dentro da zona de disponibilidade do cluster.

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

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando o cluster é expandido e ocorre uma interrupção em uma zona de disponibilidade.

  • Detecção e resposta: Solução VMware no Azure gerencia a resposta em nível de infraestrutura a falhas de zona. A HA do vSphere detecta automaticamente falhas de zona e inicia procedimentos de reinicialização da VM, se necessário.
  • Notification: Microsoft não notifica automaticamente quando uma zona está inoperante. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.
  • Solicitações ativas: Todas as VMs executadas na zona de disponibilidade com falha são reiniciadas em hosts na zona de disponibilidade íntegra. As solicitações ativas e as conexões com as VMs afetadas são encerradas e os clientes são responsáveis por repeti-las.

  • Tempo de inatividade esperado: O tempo para reiniciar VMs com falha na zona íntegra normalmente é de alguns minutos, dependendo da configuração da VM e dos procedimentos de inicialização. O cluster estendido permanece operacional com capacidade reduzida.

    Se a zona de disponibilidade com falha contiver o nó de testemunha, a testemunha ficará inacessível. Enquanto as réplicas de dados suficientes permanecerem disponíveis, os hosts de dados e as cargas de trabalho em execução continuarão a operar sem perda imediata de dados. No entanto, a vSAN perde a capacidade de detectar quórum nesse estado. A perda de quorum o impede de tomar decisões de posicionamento e recuperação com segurança. Ele também bloqueia determinadas operações, como ativação de VM após falhas, rebalanceamento e reparos.

  • Perda de dados esperada: Como o vSAN usa a replicação síncrona entre zonas, nenhuma perda de dados é esperada durante uma falha de zona.

  • Redistribuição: o DRS do vSphere redistribui automaticamente cargas de trabalho de VM para a zona de disponibilidade íntegra. O roteamento de tráfego de rede por meio do VMware NSX se adapta automaticamente ao novo posicionamento da VM.

Esta seção descreve o que esperar quando o cluster é implantado em uma nuvem privada zonal e ocorre uma interrupção de zona de disponibilidade.

  • Detecção e resposta: Você precisa detectar a perda de uma zona de disponibilidade. Se necessário, você pode iniciar um failover para um cluster secundário criado anteriormente em outra zona de disponibilidade.
  • Notification: Microsoft não notifica automaticamente quando uma zona está inoperante. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.
  • Solicitações ativas: As solicitações ativas e as conexões com as VMs afetadas são encerradas e os clientes são responsáveis por repeti-las.

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

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

  • Redistribuição: Você é responsável por alternar o tráfego para outros clusters em zonas saudáveis, caso seja necessário.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, o DRS do vSphere pode, opcionalmente, redistribuir VMs de volta para a zona recuperada com base em suas regras de configuração e afinidade de DRS. Você também pode controlar manualmente o posicionamento da VM usando operações de vMotion.

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

Testar falhas em zonas

Para se preparar para falhas de zona, teste a resiliência do seu aplicativo em relação às reinicializações de VMs e às alterações nos caminhos de rede, especialmente se você tiver clusters estendidos ou implantar aplicativos em clusters separados em diferentes zonas.

Como Solução VMware no Azure gerencia a resposta de infraestrutura a falhas de zona, você precisa principalmente testar a resposta do aplicativo às reinicializações da VM.

Você é responsável por qualquer resposta de infraestrutura a falhas de zona, como failover para outro cluster em uma zona ou região diferente. Verifique se você testa minuciosamente seus processos de resposta.

Resiliência a falhas em toda a região

Cada cluster Solução VMware no Azure é implantado em uma única região Azure. Se a região ficar indisponível, sua nuvem privada e todos os recursos dentro dela ficarão indisponíveis.

No entanto, você também pode criar soluções personalizadas de várias regiões que combinam diferentes abordagens ou se integram à sua infraestrutura existente para atender aos seus requisitos de negócios específicos e aos objetivos de recuperação.

Soluções personalizadas de várias regiões para resiliência

Para obter resiliência de várias regiões com Solução VMware no Azure, você precisa implantar nuvens privadas separadas em várias regiões e implementar failover e outras soluções de recuperação de desastre (DR).

Uma variedade de opções dá suporte a diferentes requisitos de resiliência. Para obter mais informações, consulte soluções de recuperação de desastres para máquinas virtuais do Solução VMware no Azure.

Backup e restauração

Solução VMware no Azure faz backup automático de componentes de gerenciamento, como vCenter Server, NSX Manager e HCX Manager, se habilitado. Para restaurar componentes desses backups de gerenciamento, crie uma solicitação Suporte do Azure.

Para suas cargas de trabalho de VM, Solução VMware no Azure dá suporte a várias abordagens de backup. Para obter mais informações, consulte soluções de backup para VMs do Solução VMware no Azure.

Resiliência à manutenção do serviço

Azure faz a manutenção automática da plataforma para aplicar atualizações de segurança, implantar novos recursos e melhorar a confiabilidade do serviço.

Para saber como a manutenção afeta Solução VMware no Azure componentes e entender os componentes que você é responsável por manter versus os componentes que Microsoft mantém, consulte Solução VMware no Azure manutenção de nuvem privada.

Você pode configurar as janelas de manutenção do cluster para reduzir a probabilidade de que a manutenção afete suas cargas de trabalho de produção. Para obter mais informações, consulte Planejar manutenção de autoatendimento para Solução VMware no Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Solução VMware no Azure fornece SLAs de disponibilidade diferentes para infraestrutura de carga de trabalho e para operações de gerenciamento.

Os clusters configurados como clusters estendidos têm um SLA de disponibilidade de infraestrutura de carga de trabalho mais alta.

No entanto, para se qualificar para os SLAs de disponibilidade, você deve configurar seu cluster de maneiras específicas. Para obter mais informações, consulte o texto do SLA.