Projetar clusters estendidos vSAN

Neste artigo, aprenda a projetar um cluster estendido vSAN em uma nuvem privada da Solução VMware no Azure.

Tela de fundo

A infraestrutura global do Azure é dividida em regiões. Cada região dá suporte aos serviços para determinada geografia. Em cada região, o Azure cria ilhas isoladas e redundantes de infraestrutura chamadas AZ (zona de disponibilidade). Uma AZ atua como um limite para o gerenciamento de recursos. A computação e os outros recursos disponíveis em uma AZ são finitos e podem se esgotar devido às demandas dos clientes. Uma AZ é criada para ser resiliente de modo independente, significando que falhas em uma AZ não afetam outras AZs.

Com a Solução VMware no Azure, os hosts ESXi implantados em um cluster vSphere padrão residem tradicionalmente em uma única AZ (zona de disponibilidade) do Azure e são protegidos pela HA (alta disponibilidade) do vSphere. No entanto, a solução não protege as cargas de trabalho contra uma falha da AZ do Azure. Para proteger contra uma falha da AZ, um único cluster vSAN pode ser habilitado para abranger duas zonas de disponibilidade separadas, chamadas de cluster estendido vSAN.

Clusters estendidos permitem que a configuração de domínios de falha vSAN em duas AZs notifique o vCenter Server de que os hosts residem em cada AZ (zona de disponibilidade). Cada domínio de falha é nomeado após a AZ em que reside para aumentar a clareza. Quando você estende um cluster vSAN em duas AZs dentro de uma região, se uma AZ for desativada, ela será tratada como um evento de HA do vSphere e a máquina virtual será reiniciada na outra AZ.

Benefícios do cluster estendido:

• Melhorar a disponibilidade de aplicativos.
• Fornecer uma funcionalidade de RPO (objetivo de ponto de recuperação) zero para aplicativos empresariais sem a necessidade de reprojetá-los ou implantar soluções caras de DR (recuperação de desastre).
• Uma nuvem privada com clusters estendidos foi projetada para fornecer 99,99% de disponibilidade devido à sua resiliência a falhas de AZ.
• Permitir que os clientes se concentrem nos principais requisitos e recursos do aplicativo, em vez da disponibilidade da infraestrutura.

Para proteger contra cenários de dupla personalidade e ajudar a medir a integridade do site, uma testemunha vSAN gerenciada é criada em uma terceira AZ. Com uma cópia dos dados em cada AZ, a HA do vSphere tenta se recuperar de qualquer falha usando uma simples reinicialização da máquina virtual.

O diagrama a seguir ilustra um cluster vSAN estendido em duas AZs.

Em resumo, os clusters estendidos simplificam as necessidades de proteção fornecendo os mesmos controles e funcionalidades confiáveis, além da escala e flexibilidade da infraestrutura do Azure.

É importante entender que as nuvens privadas de cluster estendido oferecem apenas uma camada extra de resiliência e não abordam todos os cenários de falha. Por exemplo, as nuvens privadas de cluster estendido:

• Não protegem contra falhas no nível da região no Azure ou cenários de perda de dados causados por problemas de aplicativo ou políticas de armazenamento mal planejadas.
• Fornecem proteção contra uma falha de zona única, mas não são projetadas para fornecer proteção contra falhas duplas ou progressivas. Por exemplo:

  • Apesar de várias camadas de redundância internas na malha, se uma falha entre AZs resultar no particionamento do site secundário, a HA do vSphere começará a desligar as VMs de carga de trabalho no site secundário.

    O diagrama a seguir mostra o cenário de particionamento de site secundário.

    

  • Se o particionamento do site secundário progredisse para a falha do site primário ou resultasse em um particionamento completo, a HA do vSphere tentaria reiniciar as VMs de carga de trabalho no site secundário. Se a HA do vSphere tentasse reiniciar as VMs de carga de trabalho no site secundário, essas VMs ficariam em um estado instável.

    Os diagramas a seguir mostram os cenários de falha do site preferencial ou particionamento completo da rede.

    

    

Deve-se observar que esses tipos de falhas, embora raros, estão fora do escopo da proteção oferecida por uma nuvem privada de cluster estendido. Devido a esses tipos de falhas raras, uma solução de cluster estendido deve ser considerada como uma solução de alta disponibilidade multi-AZ dependente da HA do vSphere. É importante entender que uma solução de cluster estendido não é destinada a substituir uma estratégia abrangente de recuperação de desastre de várias regiões que pode ser empregada para garantir a disponibilidade do aplicativo. O motivo é que uma solução de recuperação de desastre normalmente tem planos de gerenciamento e controle separados em regiões separadas do Azure. Os clusters estendidos da Solução VMware no Azure têm um único plano de controle e gerenciamento estendido em duas zonas de disponibilidade na mesma região do Azure. Por exemplo, um vCenter Server, um cluster NSX Manager, um par de VMs do NSX Edge.

Disponibilidade de região dos clusters estendidos

Cluster estendidos da Solução VMware no Azure estão disponíveis nas seguintes regiões:

• Sul do Reino Unido (em AV36 e AV36P)
• Oeste da Europa (em AV36 e AV36P)
• Centro-Oeste da Alemanha (em AV36 e AV36P)
• Leste da Austrália (em AV36P)
• Leste dos EUA (em AV36P)

Políticas de armazenamento com suporte

Há suporte para as seguintes políticas de SPBM, com um PFTT de "Espelhamento de Site Duplo" e SFTT de "RAID 1 (Espelhamento)" habilitados como as políticas padrão para o cluster:

• Configurações de tolerância a desastres do site (PFTT):
  • Espelhamento de site duplo
  • Nenhum – manter dados em preferenciais
  • Nenhum – manter dados em não preferenciais
• Falhas locais a serem toleradas (SFTT):
  • 1 falha – RAID 1 (Espelhamento)
  • 1 falha – RAID 5 (Codificação de eliminação), exige um mínimo de quatro hosts em cada AZ
  • 2 falhas – RAID 1 (Espelhamento)
  • 2 falhas – RAID 6 (Codificação de eliminação), exige um mínimo de seis hosts em cada AZ
  • 3 falhas – RAID 1 (Espelhamento)

Perguntas frequentes

Há outras regiões planejadas?

Atualmente, há cinco regiões com suporte para clusters estendidos.

Que tipo de SLA a Solução VMware no Azure fornece com os clusters estendidos?

Uma nuvem privada criada com um cluster estendido vSAN foi projetada para oferecer um compromisso de disponibilidade de infraestrutura de 99,99% quando as seguintes condições existirem:

• Um mínimo de seis nós estão implantados no cluster (3 em cada zona de disponibilidade).
• Quando uma política de armazenamento de VM de PFTT de "Espelhamento de Site Duplo" e um SFTT de 1 é usado pelas VMs de carga de trabalho.
• A conformidade com os requisitos adicionais capturados nos detalhes do SLA da Solução VMware no Azure é necessária para atingir as metas de disponibilidade.

Tenho como escolher a zona de disponibilidade na qual uma nuvem privada é implantada?

Não. Um cluster estendido é criado entre duas zonas de disponibilidade, enquanto a terceira zona é usada para implantar o nó testemunha. Como todas as zonas são efetivamente usadas para implantar um ambiente de cluster estendido, não é oferecida uma escolha ao cliente. Em vez disso, o cliente opta por implantar hosts em várias AZs no momento da criação da nuvem privada.

Quais são as limitações que devo estar ciente?

• Depois de criar uma nuvem privada com um cluster estendido, ela não poderá ser alterada para uma nuvem privada de cluster padrão. Da mesma forma, uma nuvem privada de cluster padrão não pode ser alterada para uma nuvem privada de cluster estendida após a criação.
• A escala horizontal e a redução horizontal de clusters estendidos só podem acontecer em pares. Há suporte para um mínimo de seis nós e um máximo de 16 nós em um ambiente de cluster estendido. Para saber mais, confira Assinatura e limites de serviço, cotas e restrições do Azure.
• As VMs de carga de trabalho do cliente são reiniciadas com uma prioridade média de HA do vSphere. As VMs de gerenciamento têm a maior prioridade de reinicialização.
• A solução depende da HA de vSphere e vSAN para reinicializações e replicação. O RTO (objetivo de tempo de recuperação) é determinado pelo tempo necessário para que a HA do vSphere reinicie uma VM na AZ sobrevivente após a falha de uma única AZ.
• No momento, não há suporte em um ambiente de cluster estendido:
  • Recursos lançados recentemente, como IP público até o NSX Edge e o armazenamento externo, como armazenamento de dados ANF.
  • Complementos de recuperação de desastre, como VMware SRM, Zerto e JetStream.
• Abra um tíquete de suporte no portal do Azure para os seguintes cenários (selecione Clusters Estendidos como um Tipo de Problema):
  • Conectar uma nuvem privada a uma nuvem privada de cluster estendido.
  • Conectar duas nuvens privadas de cluster estendido em uma única região.

Que tipo de latências devo esperar entre as AZs (zonas de disponibilidade)?

Os clusters estendidos vSAN operam dentro de um RTT (tempo de resposta) de 5 milissegundos e 10 Gb/s ou maior largura de banda entre as AZs que hospedam as VMs de carga de trabalho. A implantação de cluster estendido da Solução VMware no Azure segue esse princípio de orientação. Considere essas informações ao implantar aplicativos (com SFTT de espelhamento de site duplo, que usa gravações síncronas) que têm requisitos rigorosos de latência.

Posso combinar clusters estendidos e padrão na minha nuvem privada?

Não. Não há suporte para uma combinação de clusters estendidos e padrão na mesma nuvem privada. Um ambiente de cluster estendido ou padrão é selecionado quando você cria a nuvem privada. Ao criar nuvem privada com um cluster estendido, supõe-se que todos os clusters criados nessa nuvem privada são estendidos por natureza.

Quanto custa a solução?

Os clientes são cobrados com base no número de nós implantados na nuvem privada.

Eu sou cobrado pelo nó testemunha e pelo tráfego entre zonas de disponibilidade?

Não. Os clientes não serão cobrados pelo nó testemunha e pelo tráfego entre zonas de disponibilidade. O nó testemunha é totalmente gerenciado pelo serviço e a Solução VMware no Azure fornece o gerenciamento do ciclo de vida necessário do nó testemunha. Como toda a solução é gerenciada pelo serviço, o cliente só precisa identificar a política SPBM apropriada a ser definida para as máquinas virtuais de carga de trabalho. O restante é gerenciado pela Microsoft.