O que é o Solução VMware no Azure?

O Solução VMware no Azure fornece uma cloud privada que contém clusters VMware vSphere construídos a partir de infraestrutura bare-metal dedicada do Azure. Solução VMware no Azure está disponível em Azure Commercial e 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, pode migrar cargas de trabalho dos seus ambientes on-premises, implementar novas máquinas virtuais (VMs) e consumir serviços Azure a partir das suas clouds privadas. Para obter informações sobre o SLA, veja a página acordos de nível de serviço da Azure.

O Solução VMware no Azure é uma solução validada por VMware com validação e testes contínuos de melhorias e atualizações. A Microsoft gere e mantém a infraestrutura e o software de cloud privada, permitindo-lhe focar-se no desenvolvimento e execução de cargas de trabalho nas suas clouds privadas para entregar valor ao negócio.

O diagrama mostra a adjacência entre clouds privadas e VNets no Azure, serviços Azure e ambientes on-premises. O acesso à rede de clouds privadas para serviços Azure ou VNets proporciona integração orientada por SLA dos endpoints de serviço Azure. O ExpressRoute Global Reach liga o seu ambiente local à sua cloud privada Solução VMware no Azure.

Tipos de nuvem privada do Solução VMware no Azure

O Solução VMware no Azure fornece duas gerações diferentes de cloud privada:

1. O Solução VMware no Azure Generation 1 fornece clusters VMware vSphere construídos a partir de hosts bare-metal dedicados implantados nas instalações de data center da Azure. Os circuitos ExpressRoute geridos pela Microsoft fornecem conectividade entre os hosts VMware vSphere e os recursos nativos do Azure implantados em Redes Virtuais.

2. Solução VMware no Azure Geração 2 fornece clusters VMware vSphere construídos a partir de hosts bare-metal dedicados da Azure. O Solução VMware no Azure Generation 2 apresenta uma arquitetura de rede atualizada em que os hosts VMware vSphere estão diretamente ligados às Redes Virtuais do Azure. Esta oferta só é suportada no AV64 SKU.

Servidores, clusters e nuvens privadas

Os clusters Solução VMware no Azure baseiam-se numa infraestrutura hiperconvergente. A tabela a seguir mostra as especificações de CPU, memória, disco e rede do host.

Um cluster Solução VMware no Azure requer um número mínimo de três hosts. Só podes usar hosts do mesmo tipo numa única cloud privada Solução VMware no Azure. 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 AV64: É necessário um cloud privado Solução VMware no Azure implementado com AV36, AV36P, AV48 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.

A ESA aplica-se às implementações do AV64 Gen 2.

Pode implementar novas clouds privadas ou escalar existentes através do portal Azure ou da CLI do Azure.

Solução VMware no Azure extensão da nuvem privada utilizando nós de tamanho AV64

O AV64 é um SKU host Solução VMware no Azure, disponível para expandir a cloud privada Solução VMware no Azure construída com os SKU AV36, AV36P ou AV52 existentes. Se quiseres implementar o AV64 diretamente, consulta Solução VMware no Azure num Rede Virtual do Azure. Use a documentação Microsoft para verificar a disponibilidade do 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 solução Azure VMware de cloud privada é criada usando AV36, AV36P, AV48 ou AV52 numa região/AZ suportada por 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 Solução VMware no Azure cloud privada existente: Quando um cliente tem uma cloud privada Solução VMware no Azure implementada, pode escalar a cloud privada adicionando um cluster de nós AV64 vCenter separado a essa nuvem privada. Nesse cenário, os clientes devem usar as seguintes etapas:

1. Obtenha uma aprovação de quota AV64 da Microsoft com um mínimo de três nós. Adicione outros detalhes sobre a cloud privada Solução VMware no Azure que planeia expandir usando AV64.
2. Use um fluxo de trabalho existente do Solução VMware no Azure add-cluster com hosts AV64 para expansão.

O cliente planeia criar uma nova Solução VMware no Azure cloud privada: Quando um cliente quer uma nova cloud privada Solução VMware no Azure que possa usar o SKU AV64, mas apenas para expansão. Neste caso, o cliente cumpre o requisito de ter uma cloud privada Solução VMware no Azure construída com SKU AV36, AV36P ou AV52. 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 e AV64, com um mínimo de três nós cada.
2. Crie uma cloud privada Solução VMware no Azure usando SKU AV36, AV36P ou AV52.
3. Use um fluxo de trabalho existente do Solução VMware no Azure Add-cluster com hosts AV64 para expandir.

Clusters suspensos de cloud privada do Solução VMware no Azure: O SKU AV64 não é suportado com clusters suspensos de cloud privada do Solução VMware no Azure. Isto significa que uma expansão baseada em AV64 não é possível para uma cloud privada de clusters estendidos Solução VMware no Azure.

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

Adicionar nós AV64 a uma nuvem privada do Solução VMware no Azure cria um ambiente heterogéneo, o que resulta em problemas de Compatibilidade vMotion Melhorada (EVC) entre clusters AV64 e clusters base SKU que usam 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 tradicionais do Solução VMware no Azure não têm configuração explícita de FD vSAN. A razão é que a lógica de alocação de hosts garante, dentro dos clusters, que nenhum host reside no mesmo domínio físico de falha dentro de uma região 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 host Solução VMware no Azure AV64 têm uma configuração explícita de domínio de falha vSAN (FD). O Solução VMware no Azure control plane configura sete domínios de falha vSAN (FDs) 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 do lançamento inicial do SKU AV64. Consulte a tabela de mapeamento de zonas de disponibilidade de regiões do Azure para tipos de host para mais informações.

Recomendação de tamanho de cluster

O tamanho mínimo do cluster de nós vSphere suportado pelo Solução VMware no Azure é 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 vSAN (FD) do cluster AV64 e à necessidade de hosts equilibrados entre todos os FDs, a remoção do host do cluster AV64 difere dos clusters tradicionais do Solução VMware no Azure com outros SKUs.

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. Neste cenário, o plano de controlo do Solução VMware no Azure remove apenas os hosts, que não criam 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, o plano de controlo do Solução VMware no Azure trata de adicionar hosts de todos os sete FDs de forma uniforme. 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. Nas regiões do Azure atualmente limitadas a cinco FDs, a Microsoft permite que os clientes utilizem a política de armazenamento RAID-5 FTT1 vSAN para clusters AV64 com seis ou mais nós, para cumprir o acordo de nível de serviço (SLA). Consulte a tabela de mapeamento de zona de disponibilidade da região do Azure para o tipo de host para mais informações.

Armazenamento

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

Rede

O Solução VMware no Azure oferece um ambiente de cloud 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. Liga circuitos diretamente ao 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 Solução VMware no Azure é a sua própria região do ExpressRoute (o seu próprio dispositivo virtual MSEE), o que permite ligar o Global Reach ao local de peering "local". Permite ligar múltiplas instâncias do Solução VMware no Azure numa mesma região à mesma localização de peering.

As máquinas virtuais implementadas na nuvem privada são acessíveis à internet através da funcionalidade WAN Virtual do Azure IP pública. 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 clouds privadas do Solução VMware no Azure utilizam controlo de acesso baseado em papéis vSphere para maior segurança. Pode integrar capacidades vSphere SSO LDAP 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

O Solução VMware no Azure não armazena dados de clientes.

Versões de software VMware

A tabela seguinte lista as versões de software utilizadas em novas implementações de clouds privadas do Solução VMware no Azure.

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

Atualizações regulares da cloud privada Solução VMware no Azure e do software VMware garantem que a segurança, estabilidade e conjuntos de funcionalidades mais recentes estejam a correr nas suas clouds privadas. Para obter mais informações, consulte Manutenção do host e gerenciamento do ciclo de vida.

Monitorando sua nuvem privada

Depois de implementar o Solução VMware no Azure na sua subscrição, os registos do Azure Monitor são gerados automaticamente.

Na sua nuvem privada, você pode:

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

Os padrões de monitorização dentro do Solução VMware no Azure são semelhantes aos VMs do Azure na plataforma IaaS. Para mais informações e instruções, consulte Monitorização de VMs do Azure com o Azure Monitor.

Comunicação com o cliente

Pode encontrar notificações de problemas de serviço, manutenção planeada, avisos de saúde e avisos de segurança publicados através do Service Health no portal Azure. Você pode tomar ações oportunas ao configurar alertas de registro de atividades para essas notificações. Para mais informações, consulte Create Service Health alerts usando o portal Azure.

Solução VMware no Azure responsibility matrix - Microsoft vs customer

O Solução VMware no Azure implementa um modelo de responsabilidade partilhada que define papéis e responsabilidades distintos 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 da matriz de responsabilidades partilhadas descreve as principais tarefas que os clientes e a Microsoft desempenham na implementação e gestão tanto da cloud privada como das cargas de trabalho das aplicações do cliente.

A tabela seguinte apresenta uma lista detalhada de funções e responsabilidades entre o cliente e a Microsoft, que abrange as tarefas e definições mais frequentes. Para mais perguntas, contacte a Microsoft.

Próximos passos

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