Estruturar clusters dispersos do vSAN

Neste artigo, saiba como projetar um cluster estendido vSAN para uma nuvem privada do Azure VMware Solution.

Fundo

A infraestrutura global do Azure está dividida em Regiões. Cada região suporta os serviços para uma determinada geografia. Dentro de cada região, o Azure cria ilhas de infraestrutura isoladas e redundantes chamadas zonas de disponibilidade (AZ). Um AZ atua como um limite para o gerenciamento de recursos. A computação e outros recursos disponíveis para um AZ são finitos e podem se esgotar pelas demandas do cliente. Um AZ é construído para ser resiliente independentemente, o que significa que falhas em um AZ não afetam outros AZs.

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

Os clusters estendidos permitem a configuração de domínios de falha vSAN em duas AZs para notificar o vCenter Server de que os hosts residem em cada zona de disponibilidade (AZ). Cada domínio de falha é nomeado após o 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 ficar inativa, ela será tratada como um evento vSphere HA e a máquina virtual será reiniciada na outra AZ.

Benefícios do cluster estendido:

• Melhore a disponibilidade dos aplicativos.
• Forneça um recurso de RPO (Recovery Point Objetive, objetivo de ponto de recuperação) zero para aplicativos corporativos sem a necessidade de redesenhá-los ou implantar soluções caras de recuperação de desastres (DR).
• Uma nuvem privada com clusters estendidos foi projetada para fornecer 99,99% de disponibilidade devido à sua resiliência a falhas AZ.
• Permita que os clientes se concentrem nos principais requisitos e recursos do aplicativo, em vez da disponibilidade da infraestrutura.

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

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

O diagrama a seguir mostra o fluxo normal de tráfego de rede dentro de um cluster vSAN estendido por duas AZs.

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

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

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

  • Apesar de várias camadas de redundância incorporadas na malha, se uma falha inter-AZ resultar no particionamento do site secundário, o vSphere HA 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, o vSphere HA tentaria reiniciar as VMs de carga de trabalho no site secundário. Se o vSphere HA tentasse reiniciar as VMs de carga de trabalho no site secundário, colocaria as VMs de carga de trabalho em um estado instável.

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

    

    

    O diagrama a seguir mostra o fluxo de tráfego de rede dentro de um cluster vSAN estendido durante uma falha completa do local.

    

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

Disponibilidade da região de clusters estendidos

Os clusters estendidos da Solução VMware do Azure estão disponíveis nas seguintes regiões:

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

Políticas de armazenamento suportadas

As seguintes políticas SPBM são suportadas com um PFTT de "Dual Site Mirroring" e SFTT de "RAID 1 (Mirroring)" ativado como as políticas padrão para o cluster:

• Configurações de tolerância a desastres do site (PFTT):
  • Espelhamento de site duplo
  • Nenhum - mantenha os dados sobre os preferidos
  • Nenhum - manter dados sobre não preferidos
• Falhas locais de tolerância (SFTT):
  • 1 falha – RAID 1 (espelhamento)
  • 1 falha – RAID 5 (Erasure coding), requer um mínimo de quatro hosts em cada AZ
  • 2 falhas – RAID 1 (Espelhamento)
  • 2 falhas – RAID 6 (Erasure coding), requer um mínimo de seis hosts em cada AZ
  • 3 falhas – RAID 1 (Espelhamento)

FAQ

Estão previstas outras regiões?

Atualmente, há cinco regiões suportadas para clusters esticados.

Que tipo de SLA a Solução VMware do 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 sã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 é usada pelas VMs de carga de trabalho.
• A conformidade com os Requisitos Adicionais capturados nos detalhes do SLA da Solução VMware do Azure é necessária para atingir as metas de disponibilidade.

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

N.º 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, uma opção não é fornecida 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 a que devo estar atento?

• Depois que uma nuvem privada é criada com um cluster estendido, ela não pode 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 expansão e a expansão de clusters esticados só podem acontecer em pares. Um mínimo de seis nós e um máximo de 16 nós são suportados em um ambiente de cluster estendido. Para obter mais informações, veja Subscrição do Azure e limites, quotas e restrições do serviço.
• As VMs de carga de trabalho do cliente são reiniciadas com uma prioridade média do vSphere HA. As VMs de gerenciamento têm a prioridade de reinicialização mais alta.
• A solução depende do vSphere HA e do vSAN para reinicializações e replicação. O RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é determinado pela quantidade de tempo que o vSphere HA leva para reiniciar uma VM na AZ sobrevivente após a falha de um único AZ.
• Atualmente não há suporte em um ambiente de cluster estendido:
  • Recursos lançados recentemente, como IP público até NSX Edge e armazenamento externo, como armazenamentos de dados ANF.
  • Complementos de recuperação de desastres como VMware SRM, Zerto e JetStream.
• Abra um tíquete de suporte no portal do Azure para os seguintes cenários (certifique-se de selecionar Clusters Estendidos como um Tipo de Problema):
  • Conecte uma nuvem privada a uma nuvem privada de cluster estendida.
  • Conecte duas nuvens privadas de cluster estendidas em uma única região.

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

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

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

N.º Uma combinação de clusters estendidos e padrão não é suportada na mesma nuvem privada. Um ambiente de cluster estendido ou padrão é selecionado quando você cria a nuvem privada. Quando uma nuvem privada é criada com um cluster estendido, a suposição é que todos os clusters criados dentro dessa nuvem privada são esticados na natureza.

Quanto custa a solução?

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

Sou cobrado pelo nó testemunha e pelo tráfego inter-AZ?

N.º Os clientes não veem uma cobrança pelo nó testemunha e pelo tráfego inter-AZ. O nó testemunha é totalmente gerenciado pelo serviço e a Solução VMware do Azure fornece o gerenciamento necessário do ciclo de vida do nó testemunha. Como toda a solução é gerenciada por serviços, o cliente só precisa identificar a política de SPBM apropriada a ser definida para as máquinas virtuais de carga de trabalho. O resto é gerido através da Microsoft.