O que é o Azure VMware Solution?

A Solução VMware do Azure fornece nuvens privadas que contêm clusters VMware vSphere criados a partir da infraestrutura bare-metal dedicada do Azure. A Solução VMware do Azure está disponível no Azure Commercial e no Azure Government. A implantação inicial mínima é de três hosts, com a opção de adicionar mais hosts, até um máximo de 16 hosts por cluster. Todas as nuvens privadas provisionadas têm VMware vCenter Server, VMware vSAN, VMware vSphere e VMware NSX. Como resultado, você pode migrar cargas de trabalho de seus ambientes locais, implantar novas máquinas virtuais (VMs) e consumir serviços do Azure de suas nuvens privadas. Para obter informações sobre o SLA, consulte a página Contratos de nível de serviço do Azure .

A Solução VMware do Azure é uma solução validada pela VMware com validação e testes contínuos de melhorias e atualizações. A Microsoft gerencia e mantém a infraestrutura e o software de nuvem privada, permitindo que você se concentre no desenvolvimento e na execução de cargas de trabalho em suas nuvens privadas para oferecer valor comercial.

O diagrama mostra a adjacência entre nuvens privadas e VNets no Azure, serviços do Azure e ambientes on-premises. O acesso à rede das nuvens privadas aos serviços do Azure ou às redes virtuais proporciona uma integração orientada por SLA dos endpoints de serviço do Azure. O ExpressRoute Global Reach conecta seu ambiente local à nuvem privada da Solução VMware do Azure.

Tipos de nuvens privadas da solução Azure VMware

Azure VMware Solution oferece duas diferentes gerações de nuvens privadas:

1. O Azure VMware Solution Generation 1 fornece clusters VMware vSphere criados a partir de hosts bare-metal dedicados implantados em instalações de data center do Azure. Os circuitos ExpressRoute gerenciados pela Microsoft fornecem conectividade entre hosts VMware vSphere e recursos nativos do Azure implantados em Redes Virtuais.

2. O Azure VMware Solution Generation 2 (Public Preview) fornece clusters VMware vSphere criados a partir de hosts bare-metal dedicados do Azure. O Azure VMware Solution Generation 2 apresenta uma arquitetura de rede atualizada em que os hosts VMware vSphere são diretamente conectados às Redes Virtuais do Azure. Esta oferta só é suportada no AV64 SKU.

Servidores, clusters e nuvens privadas

Os clusters da Solução VMware do Azure são baseados em uma infraestrutura hiperconvergente. A tabela a seguir mostra as especificações de CPU, memória, disco e rede do host.

Um cluster da Solução VMware do Azure requer um número mínimo de três hosts. Você pode usar hosts do mesmo tipo somente em uma única nuvem privada do Azure VMware Solution. Os hosts usados para criar ou dimensionar clusters vêm de um pool isolado de hosts. Esses hosts passaram por testes de hardware e tiveram todos os dados excluídos com segurança antes de serem adicionados a um cluster.

Todos os tipos de host anteriores têm taxa de transferência de interface de rede de 100 Gbps.

*Os detalhes estão disponíveis através da calculadora de preços do Azure.

**Pré-requisito do AV64: é necessária uma nuvem privada da Solução VMware do Azure implantada com AV36, AV36P ou AV52 antes de adicionar o AV64.

O Raw é baseado no Sistema Internacional de Unidades (SI) fornecido pelos fabricantes de discos. Exemplo: 1 TB Raw = 1000000000000 bytes. O espaço calculado por um computador em binário (binário de 1 TB = binário de 1099511627776 bytes) é igual a 931,3 gigabytes convertidos a partir do decimal bruto.

Você pode implantar nuvens privadas novas ou dimensionar existentes por meio do portal do Azure ou da CLI do Azure.

Extensão de nuvem privada da Solução VMware do Azure com tamanho de nó AV64

O AV64 é um SKU de host da Azure VMware Solution, que está disponível para expandir a nuvem privada da Azure VMware Solution construída com os SKU existentes AV36, AV36P ou AV52. Se você quiser implantar o AV64 diretamente, consulte a Solução VMware do Azure em uma Rede Virtual do Azure. Use a documentação da Microsoft para verificar a disponibilidade da SKU AV64 na região.

Pré-requisito para expansão AV64 em AV36, AV36P, e AV52

Consulte os seguintes pré-requisitos para a implantação do cluster AV64.

• Uma nuvem privada da solução VMware do Azure é criada usando AV36, AV36P, AV48 ou AV52 na região/AZ com suporte AV64.

• Você precisa de um /23 ou de três blocos de endereço /25 (contíguos ou não contíguos) para o gerenciamento de cluster AV64.

Capacidade de suporte para cenários de clientes

Cliente com nuvem privada existente do Azure VMware Solution: quando um cliente tem uma nuvem privada do Azure VMware Solution implantada, ele pode dimensionar a nuvem privada adicionando um cluster de nó AV64 vCenter separado a essa nuvem privada. Nesse cenário, os clientes devem usar as seguintes etapas:

1. Obtenha uma aprovação de cota AV64 da Microsoft com o mínimo de três nós. Adicione outros detalhes na nuvem privada da Solução VMware do Azure que você planeja estender usando o AV64.
2. Utilize um fluxo de trabalho de adição de cluster existente da Solução VMware do Azure com hosts AV64 para expandir.

O cliente planeja criar uma nova nuvem privada do Azure VMware Solution: quando um cliente deseja uma nova nuvem privada do Azure VMware Solution que possa usar o AV64 SKU, mas apenas para expansão. Nesse caso, o cliente atende ao pré-requisito de ter uma nuvem privada da Solução VMware do Azure criada com AV36, AV36P ou AV52 SKU. O cliente necessita adquirir pelo menos três nós de AV36, AV36P ou AV52 SKU antes de expandir usando AV64. Para esse cenário, use as seguintes etapas:

1. Obtenha aprovação de quota da Microsoft para AV36, AV36P, AV52 ou AV64, com um mínimo de três nós cada.
2. Crie uma nuvem privada da Solução VMware do Azure usando AV36, AV36P ou AV52 SKU.
3. Utilize um fluxo de trabalho de adição de cluster existente da Solução VMware do Azure com hosts AV64 para expandir.

Azure VMware Solution stretched clusters private cloud: O AV64 SKU não é suportado com a nuvem privada de clusters estendidos do Azure VMware Solution. Isso significa que uma expansão baseada em AV64 não é possível para uma nuvem privada de clusters estendidos da Solução VMware do Azure.

Compatibilidade melhorada com vMotion (EVC) com extensão AV64

Adicionar nós AV64 a uma cloud privada Azure VMware Solution cria um ambiente heterogéneo, o que resulta em problemas de Compatibilidade VMotion Aprimorada (EVC) entre clusters AV64 e clusters SKU base usando SKUs AV36, AV36P ou AV52. Os clusters AV64 utilizam o modo EVC Icelake devido aos seus CPUs Intel Icelake, enquanto os clusters AV36, AV36P e AV52, construídos sobre CPUs Intel mais antigos, não têm o modo EVC explícito ativado. Detalhes sobre as gerações de CPU para cada SKU são fornecidos acima.

A heterogeneidade dos modos EVC entre clusters apresenta desafios para operações vMotion ao vivo, conforme definido pela Broadcom, com base no cenário específico e na direção da migração. A secção seguinte fornece um resumo da experiência do utilizador ao realizar vMotion ao vivo entre AV64 e os clusters base.

• vMotion para o cluster AV64 a partir do cluster SKU Base – isto funciona bem, pois a máquina virtual é migrada com vMotion de um cluster com modo EVC inferior para um cluster com modo EVC superior.

• vMotion para o cluster SKU base do cluster AV64 – dois cenários

  • Se a máquina virtual tiver sido previamente movida do cluster base e não tiver sido religada, o vMotion ao vivo será bem-sucedido.

  • Se a máquina virtual foi criada num cluster AV64 ou reiniciada, mesmo tendo sido previamente efetuado vMotion a partir do cluster base do SKU, o vMotion em tempo real falhará com um erro de compatibilidade EVC.

Os clientes podem evitar problemas de vMotion ao vivo entre clusters base SKU e AV64 definindo o modo EVC ao nível da VM para corresponder a um modo EVC inferior do cluster base, ou desligar a máquina virtual e executar um vMotion a frio.

Projeto e recomendações do domínio de falha (FD) do AV64 Cluster vSAN

Os clusters de host tradicionais da Solução VMware do Azure não têm configuração explícita do vSAN FD. O raciocínio é que a lógica de alocação de host garante, dentro de clusters, que não haja dois hosts residindo no mesmo domínio de falha física dentro de uma região do Azure. Esse recurso inerentemente traz resiliência e alta disponibilidade para armazenamento, que a configuração vSAN FD deve trazer. Mais informações sobre o vSAN FD podem ser encontradas na documentação do VMware.

Os clusters de anfitriões do Azure VMware Solution AV64 têm uma configuração explícita de domínio falha (FD) do vSAN. O plano de controle da Solução VMware do Azure configura sete domínios de falha (FDs) vSAN para clusters AV64. Os hosts são balanceados uniformemente entre os sete FDs à medida que os utilizadores escalam os hosts num cluster de três nós para dezasseis nós. Algumas regiões do Azure ainda suportam um máximo de cinco FDs como parte da versão inicial do AV64 SKU. Consulte a tabela de mapeamento de tipos de host na zona de disponibilidade da região do Azure para obter mais informações.

Recomendação de tamanho de cluster

O tamanho mínimo do grupo de nós vSphere da Solução Azure VMware é três. A redundância de dados vSAN é tratada garantindo que o tamanho mínimo do cluster de três hosts esteja em diferentes FDs vSAN. Em um cluster vSAN com três hosts, cada um em um FD diferente, se um FD falhar (por exemplo, a parte superior do switch de rack falhar), os dados do vSAN serão protegidos. Operações como a criação de objetos (nova VM, VMDK e outras) falhariam. O mesmo acontece com todas as atividades de manutenção em que um host ESXi é colocado no modo de manutenção e/ou reinicializado. Para evitar cenários como esses, a recomendação é implantar clusters vSAN com um mínimo de quatro hosts ESXi.

Fluxo de trabalho de remoção de host AV64 e práticas recomendadas

Devido à configuração do domínio de falha (FD) vSAN do cluster AV64 e à necessidade de equilibrar os hosts em todos os FDs, a remoção de hosts do cluster AV64 difere da dos clusters de host com outras SKUs na Solução VMware do Azure tradicional.

Atualmente, um usuário pode selecionar um ou mais hosts a serem removidos do cluster usando portal ou API. Uma condição é que um cluster deve ter um mínimo de três hosts. No entanto, um cluster AV64 se comporta de forma diferente em determinados cenários quando o AV64 usa vSAN FDs. Qualquer solicitação de remoção de host é verificada em relação a um possível desequilíbrio do vSAN FD. Se uma solicitação de remoção de host criar um desequilíbrio, a solicitação será rejeitada com a resposta http 409-Conflict. O código de status de resposta http 409-Conflict indica um conflito de solicitação com o estado atual do recurso de destino (hosts).

Os três cenários a seguir mostram exemplos de instâncias que normalmente cometem erros e demonstram métodos diferentes que podem ser usados para remover hosts sem criar um desequilíbrio de domínio de falha (FD) vSAN.

• A remoção de um host cria um desequilíbrio no vSAN FD, levando a uma diferença de hosts entre o FD mais e o menos povoado ser maior do que um. No exemplo a seguir, os usuários precisam remover um dos hosts do FD 1 antes de remover os hosts de outros FDs.

  

• Várias solicitações de remoção de host são feitas ao mesmo tempo e certas remoções de host criam um desequilíbrio. Nesse cenário, o plano de controlo da Solução VMware do Azure remove apenas hosts, sem criar desequilíbrio. No exemplo a seguir, os usuários não podem aceitar os dois hosts dos mesmos FDs, a menos que estejam reduzindo o tamanho do cluster para quatro ou menos.

  

• A remoção de um host selecionado resulta em menos de três FDs ativos no vSAN. Não se espera que este cenário ocorra, dado que todas as regiões AV64 têm cinco ou sete FDs. Ao adicionar hosts, a unidade de controlo da Solução VMware do Azure assegura que os hosts sejam adicionados de forma uniforme a partir de todos os sete FDs. No exemplo a seguir, os usuários podem remover um dos hosts do FD 1, mas não do FD 2 ou 3.

  

Como identificar o host que pode ser removido sem causar um desequilíbrio do vSAN FD: um usuário pode acessar a interface do vSphere Client para obter o estado atual dos vSAN FDs e hosts associados a cada um deles. Isso ajuda a identificar hosts (com base nos exemplos anteriores) que podem ser removidos sem afetar o saldo do vSAN FD e evitar erros na operação de remoção.

Configuração RAID suportada pelo AV64

Esta tabela fornece a lista de configurações RAID suportadas e requisitos de host em clusters AV64. As políticas RAID-6 FTT2 e RAID-1 FTT3 são suportadas com o AV64 SKU em algumas regiões. Em regiões do Azure que atualmente estão restritas a cinco FDs, a Microsoft permite que os clientes usem a política de armazenamento RAID-5 FTT1 vSAN para clusters AV64 com seis ou mais nós para atender ao contrato de nível de serviço (SLA). Consulte a tabela de mapeamento de tipos de host na zona de disponibilidade da região do Azure para obter mais informações.

Armazenamento

A Solução VMware do Azure suporta a expansão da capacidade de armazenamento de dados para além do que está incluído no vSAN utilizando os serviços de armazenamento do Azure, permitindo-lhe expandir a capacidade de armazenamento de dados sem dimensionar os clusters. Para obter mais informações, consulte Opções de expansão da capacidade do armazenamento de dados.

Rede

A Solução VMware do Azure oferece um ambiente de nuvem privada acessível a partir de sites locais e recursos baseados no Azure. Serviços como Azure ExpressRoute, conexões VPN ou WAN Virtual do Azure fornecem a conectividade. No entanto, esses serviços exigem intervalos de endereços de rede específicos e portas de firewall para habilitar os serviços.

Quando você implanta uma nuvem privada, redes privadas para gerenciamento, provisionamento e vMotion são criadas. Você utiliza estas redes privadas para aceder ao VMware vCenter Server, ao VMware NSX Manager, e para funcionalidades como o vMotion ou a implantação de máquinas virtuais.

O ExpressRoute Global Reach é usado para conectar nuvens privadas a ambientes locais. Ele conecta circuitos diretamente no nível do Microsoft Edge. A conexão requer uma rede virtual (vNet) com um circuito de ExpressRoute para as instalações locais na sua subscrição. O motivo é que os gateways vNet (ExpressRoute Gateways) não conseguem transitar tráfego, o que significa que é possível ligar dois circuitos ao mesmo gateway, mas este não envia o tráfego de um circuito para o outro.

Cada ambiente do Azure VMware Solution é uma região ExpressRoute própria (com seu próprio dispositivo MSEE virtual), o que permite ligar o "Global Reach" ao ponto de emparelhamento local. Ele permite que você conecte várias instâncias do Azure VMware Solution em uma região ao mesmo local de emparelhamento.

As máquinas virtuais implantadas na nuvem privada são acessíveis à Internet por meio da funcionalidade IP pública da WAN Virtual do Azure . Para novas nuvens privadas, o acesso à Internet está desativado por padrão.

Para obter mais informações, consulte Arquitetura de rede.

Acesso e segurança

As nuvens privadas da Solução VMware do Azure usam o controle de acesso baseado em função do vSphere para maior segurança. Você pode integrar os recursos LDAP do vSphere SSO com o Microsoft Entra ID. Para obter mais informações, consulte a página Arquitetura de acesso e identidade .

A criptografia de dados em repouso do vSAN, por padrão, é habilitada e usada para fornecer segurança de armazenamento de dados vSAN. Para obter mais informações, consulte Arquitetura de armazenamento.

Residência de dados e informações de clientes

A Solução VMware do Azure não armazena dados de clientes.

Versões de software VMware

A tabela a seguir lista as versões de software usadas em novas implantações de nuvens privadas do Azure VMware Solution.

Se o número de compilação listado não corresponder ao número de compilação listado nas notas de versão, é porque um patch personalizado foi aplicado para provedores de nuvem.

A versão atual do software em execução é aplicada a novos clusters que são adicionados a uma nuvem privada existente, se a versão do vCenter Server oferecer suporte a ela.

Manutenção do ciclo de vida do host e do software

As atualizações regulares da nuvem privada da Solução VMware do Azure e do software VMware garantem que a segurança, a estabilidade e os conjuntos de recursos mais recentes estejam em execução nas suas nuvens privadas. Para obter mais informações, consulte Manutenção do host e gerenciamento do ciclo de vida.

Monitorando sua nuvem privada

Depois de implantar a Solução VMware do Azure em sua assinatura, os logs do Azure Monitor são gerados automaticamente.

Na sua nuvem privada, você pode:

• Colete logs em cada uma de suas VMs.
• Baixe e instale o agente MMA em VMs Linux e Windows.
• Habilite a extensão de diagnóstico do Azure.
• Crie e execute novas consultas.
• Execute as mesmas consultas que você normalmente executa em suas VMs.

Os padrões de monitoramento dentro da Solução VMware do Azure são semelhantes às VMs do Azure na plataforma IaaS. Para obter mais informações e instruções, consulte Monitorando VMs do Azure com o Azure Monitor.

Comunicação com o cliente

Você pode encontrar problemas de serviço, manutenção planejada, avisos de integridade e notificações de avisos de segurança publicados por meio da Integridade do Serviço no portal do Azure. Você pode tomar ações oportunas ao configurar alertas de registro de atividades para essas notificações. Para obter mais informações, consulte Criar alertas de integridade do serviço usando o portal do Azure.

Matriz de responsabilidade da Solução VMware do Azure - Microsoft vs cliente

A Solução VMware do Azure implementa um modelo de responsabilidade partilhada que define funções e responsabilidades distintas das duas partes envolvidas na oferta: cliente e Microsoft. As responsabilidades de função partilhada são ilustradas mais pormenorizadamente nos dois quadros seguintes.

A tabela de matriz de responsabilidade compartilhada descreve as principais tarefas que os clientes e a Microsoft lidam na implantação e no gerenciamento da nuvem privada e das cargas de trabalho do aplicativo do cliente.

A tabela a seguir fornece uma lista detalhada de funções e responsabilidades entre o cliente e a Microsoft, que engloba as tarefas e definições mais frequentes. Para mais informações, contacte a Microsoft.

Próximos passos

O próximo passo é aprender os principais conceitos de arquitetura de nuvem privada.