O que é a Solução VMware no Azure?
A Solução VMware no Azure fornece nuvens privadas que contêm clusters VMware vSphere criados com base na infraestrutura bare metal dedicada do Azure. A Solução VMware no Azure está disponível no Azure Comercial e no Azure Governamental. 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, o VMware vSAN, o VMware vSphere e o VMware NSX. Como resultado, você pode migrar cargas de trabalho dos ambientes locais, implantar novas VMs (máquinas virtuais) e consumir os serviços do Azure nas suas nuvens privadas. Para obter informações sobre o SLA, confira a página Contratos de Nível de Serviço do Azure.
A Solução VMware no Azure é uma solução validada pela VMware, com validação contínua e testes de aprimoramentos e atualizações. A Microsoft gerencia e mantém a infraestrutura de nuvem privada e o software, permitindo que você se concentre no desenvolvimento e execução de cargas de trabalho em suas nuvens privadas para fornecer valor comercial.
O diagrama mostra a adjacência entre as nuvens privadas e as VNETs no Azure, nos serviços do Azure e nos ambientes locais. O acesso à rede das nuvens privadas para os serviços do Azure ou VNets fornece integração controlada por SLA dos pontos de extremidade de serviço do Azure. O Alcance Global do ExpressRoute conecta seu ambiente local à nuvem privada da Solução VMware no Azure.
Hosts, clusters e nuvens privadas
Os clusters da Solução VMware no Azure são baseados em infraestrutura hiperconvergente. A tabela a seguir mostra as especificações de CPU, memória, disco e rede do host.
| Tipo de host | CPU (Núcleos/GHz) | RAM (GB) | Camada de cache do vSAN (TB, bruto) | Camada de capacidade do vSAN (TB, bruto) | Disponibilidade regional |
|---|---|---|---|---|---|
| AV36 | CPUs duplas Intel Xeon Gold 6140 (microarquitetura Skylake) com 18 núcleos/CPU de 2,3 GHz, total de 36 núcleos físicos (72 núcleos lógicos com hyperthreading) | 576 | 3,2 (NVMe) | 15,20 (SSD) | Regiões selecionadas (*) |
| AV36P | CPUs duplas Intel Xeon Gold 6240 (microarquitetura Cascade Lake) com 18 núcleos/CPU de 2,6 GHz/3,9 GHz Turbo, Total de 36 núcleos físicos (72 núcleos lógicos com hyperthreading) | 768 | 1,5 (Cache da Intel) | 19,20 (NVMe) | Regiões selecionadas (*) |
| AV52 | CPUs duplas Intel Xeon Platinum 8270 (microarquitetura Cascade Lake) com 26 núcleos/CPU de 2,7 GHz/4,0 GHz Turbo, Total de 52 núcleos físicos (104 núcleos lógicos com hyperthreading) | 1.536 | 1,5 (Cache da Intel) | 38,40 (NVMe) | Regiões selecionadas (*) |
| AV64 | CPUs duplas Intel Xeon Platinum 8370C (microarquitetura Ice Lake) com 32 núcleos/CPU de 2,8 GHz/3,5 GHz Turbo, Total de 64 núcleos físicos (128 núcleos lógicos com hyperthreading) | 1\.024 | 3,84 (NVMe) | 15,36 (NVMe) | Regiões selecionadas (**) |
Um cluster da Solução VMware no Azure exige um número mínimo de três hosts. É possível usar apenas hosts do mesmo tipo em uma única nuvem privada da Solução VMware no Azure. Os hosts usados para criar ou escalar os clusters são provenientes de um pool isolado de hosts. Esses hosts foram aprovados nos testes de hardware e tiveram todos os dados excluídos com segurança antes de serem adicionados ao cluster.
Todos os tipos de host acima têm taxa de transferência de interface de rede de 100 Gbps.
(*) detalhes disponíveis por meio da calculadora de preços do Azure.
(**) Pré-requisito do AV64: uma nuvem privada da Solução VMware no Azure implantada com AV36, AV36P ou AV52 é necessária antes de adicionar o AV64.
Com o portal do Azure ou a CLI do Azure, é possível implantar novas nuvens privadas ou dimensionar as existentes.
Extensão de nuvem privada da Solução VMware no Azure comum tamanho de nó AV64
AV64 é um novo SKU de host da Solução VMware no Azure, que está disponível para expandir (não criar) a nuvem privada da Solução VMware no Azure existente criada com os SKUs AV36, AV36P ou AV52. Use a documentação da Microsoft para verificar a disponibilidade do SKU AV64 na sua região.
Pré-requisitos para o uso do AV64
Confira os pré-requisitos a seguir para a implantação do cluster AV64.
Uma nuvem privada da Solução VMware no Azure é criada usando AV36, AV36P ou AV52 na região/AZ com suporte ao AV64.
Você precisa de um /23 ou três (contíguos ou não contíguos) /25 blocos de endereços para gerenciamento do cluster AV64.
Suportabilidade para cenários do cliente
Cliente com uma nuvem privada da Solução VMware no Azure existente: quando tiver uma nuvem privada da Solução VMware no Azure implantada, o cliente pode ampliar a nuvem privada adicionando um cluster de nós AV64 do vCenter separado. Nesse cenário, os clientes devem usar as seguintes etapas:
- Obter uma aprovação de cota do AV64 junto à Microsoft com um mínimo de três nós. Adicionar outros detalhes na nuvem privada da Solução VMware no Azure que você planeja ampliar usando o AV64.
- Usar um fluxo de trabalho de adicionar cluster da Solução VMware no Azure existente com hosts AV64 para expandir.
O cliente planeja criar uma nova nuvem privada da Solução VMware no Azure: quando um cliente quer uma nova nuvem privada da Solução VMware no Azure que possa usar o SKU AV64, mas apenas para fins de expansão. Nesse caso, o cliente cumpre o pré-requisito de ter uma nuvem privada da Solução VMware no Azure criada com os SKUs AV36, AV36P ou AV52. O cliente precisa comprar um mínimo de três nós dos SKUs AV36, AV36P ou AV52 antes de se expandir usando o AV64. Para esse cenário, use as seguintes etapas:
- Obtenha a aprovação de cota de AV36, AV36P ou AV52 e AV64 da Microsoft com um mínimo de três nós cada.
- Crie uma nuvem privada da Solução VMware no Azure usando os SKUs AV36, AV36P ou AV52.
- Use um fluxo de trabalho de adicionar cluster da Solução VMware no Azure existente com hosts AV64 para expandir.
Nuvem privada de cluster estendido da Solução VMware no Azure: o SKU AV64 não tem suporte com a nuvem privada de cluster estendido da Solução VMware no Azure. Isso significa que uma expansão baseada em AV64 não é possível para uma nuvem privada de cluster estendido da Solução VMware no Azure.
Design e recomendações do domínio de falha (FD) de vSAN do cluster AV64
Os clusters de host tradicionais da Solução VMware no Azure não têm uma configuração explícita do FD de VSAN. A justificativa é que a lógica de alocação de host garante, dentro de clusters, que nunca existam dois hosts residindo no mesmo domínio de falha físico dentro de uma região do Azure. Esse recurso, inerentemente, adiciona resiliência e alta disponibilidade ao armazenamento, o que, supostamente, a configuração do FD de VSAN deve adicionar. Mais informações sobre o FD de VSAN podem ser encontradas na documentação do VMware.
Os clusters de host AV64 da Solução VMware no Azure têm uma configuração explícita do domínio de falha (FD) de vSAN. O painel de controle da Solução VMware no Azure configura cinco FDs (domínios de falha) de vSAN para os clusters do AV64. Os hosts são equilibrados de modo uniforme entre os cinco FDs à medida que os usuários escalam verticalmente os hosts em um cluster de três a 16 nós.
Recomendação de tamanho do cluster
O tamanho mínimo do cluster da vSphere com suporte da Solução VMware no Azure é de três nós. A redundância de dados da vSAN é resolvida com a garantia de que clusters com o tamanho mínimo de três hosts estejam em FDs de vSAN diferentes. Em um cluster de vSAN com três hosts, cada um em um FD diferente, se um FD falhar (por exemplo, se o comutador no topo do rack falhar) os dados da vSAN estarão protegidos. Operações como a criação de objeto (uma nova VM, um VMDK e outros) iriam falhar. O mesmo ocorre 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 os clusters de vSAN com, no mínimo, quatro hosts ESXi.
Fluxo de trabalho e boas práticas de remoção de host AV64
Devido à configuração do domínio de falha de vSAN do cluster AV64 e à necessidade de hosts balanceados em todos os FDs, a remoção do host do cluster AV64 difere da remoção nos clusters de host tradicionais da Solução VMware no Azure com outros SKUs.
Atualmente, um usuário pode selecionar um ou mais hosts a serem removidos do cluster usando o portal ou a API. Uma condição é que um cluster deve ter no mínimo três hosts. No entanto, um cluster AV64 se comporta de forma diferente em determinados cenários quando o AV64 usa FDs de vSAN. Qualquer solicitação de remoção de host é verificada em relação a um possível desequilíbrio do FD de vSAN. 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 da 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 apresentam erros e demonstram métodos diferentes que podem ser usados para remover os hosts sem criar um desequilíbrio de FD (domínio de falha) de vSAN.
A remoção de um host cria um desequilíbrio de FD de vSAN com uma diferença de mais de um host nos hosts entre os FDs mais e menos preenchidos. No exemplo a seguir, os usuários precisam remover um dos hosts do FD 1 antes de remover hosts de outros FDs.
Várias solicitações de remoção de host são feitas ao mesmo tempo e algumas remoções de host criam um desequilíbrio. Nesse cenário, o painel de controle da Solução VMware no Azure remove apenas hosts, o que não cria um desequilíbrio. No exemplo a seguir, os usuários não podem tirar 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 faz com que menos de três FDs de vSAN fiquem ativos. Esse cenário não deve ocorrer, considerando que todas as regiões do AV64 têm cinco FDs. Durante a adição de hosts, o painel de controle da Solução VMware no Azure cuida da adição uniforme de hosts de todos os cinco FDs. No exemplo a seguir, os usuários podem remover um dos hosts do FD 1, mas não dos FDs 2 ou 3.
Como identificar o host que pode ser removido sem causar um desequilíbrio de FD de vSAN: um usuário pode acessar a interface do usuário da vSphere para obter o estado atual de FDs de vSAN e dos hosts associados a cada um deles. Isso ajuda a identificar os hosts (com base nos exemplos anteriores) que podem ser removidos sem afetar o equilíbrio de FDs de vSAN e a evitar erros na operação de remoção.
Configuração RAID com suporte ao AV64
Essa tabela fornece a lista de requisitos de host e da configuração RAID com suporte no cluster AV64. As políticas RAID-6 FTT2 e RAID-1 FTT3 terão suporte no futuro no SKU AV64. A Microsoft permite que os clientes usem a política de armazenamento de vSAN RAID-5 FTT1 nos clusters AV64 com seis ou mais nós para cumprir o contrato de nível de serviço.
| Configuração RAID | Falhas a tolerar (FTT) | Hosts mínimos necessários |
|---|---|---|
| Configuração padrão RAID-1 (espelhamento). | 1 | 3 |
| RAID-5 (codificação de eliminação) | 1 | 4 |
| RAID-1 (espelhamento) | 2 | 5 |
Armazenamento
A Solução VMware no Azure dá suporte à expansão da capacidade do armazenamento de dados, além do que está incluído no vSAN usando os serviços de armazenamento do Azure, permitindo que você expanda a capacidade do armazenamento de dados sem escalar os clusters. Para obter mais informações, veja Opções de expansão da capacidade do armazenamento de dados.
Rede
A Solução VMware no Azure oferece um ambiente de nuvem privada acessível de recursos de sites locais e baseados no Azure. Serviços como o Azure ExpressRoute, as conexões VPN ou a WAN Virtual do Azure fornecem a conectividade. No entanto, esses serviços exigem intervalos de endereços de rede e portas de firewall específicos para que sejam habilitados.
Quando você implanta uma nuvem privada, as redes privadas para o gerenciamento, o provisionamento e o vMotion são criadas. Você usará essas redes privadas para acessar o VMware vCenter Server e o VMware NSX-T Data Center NSX-T Manager, bem como o vMotion ou a implantação da máquina virtual.
O Alcance Global do ExpressRoute é usado para conectar nuvens privadas com os ambientes locais. Ele conecta circuitos diretamente no nível do Microsoft Edge. A conexão requer uma VNet (rede virtual) com um circuito de ExpressRoute para local na assinatura. O motivo disso é que os gateways da VNet (Gateways do ExpressRoute) não podem transmitir o tráfego, o que significa que você pode anexar dois circuitos ao mesmo gateway, mas ele não envia o tráfego de um circuito para o outro.
Cada ambiente de Solução VMware no Azure é uma região própria do ExpressRoute (um dispositivo virtual MSEE próprio), o que permite que você conecte o Alcance Global à localização do emparelhamento 'local'. Isso permite que você conecte várias instâncias de Solução VMware no Azure em uma região à mesma localização de emparelhamento.
Observação
Para locais em que o Alcance Global do ExpressRoute não está habilitado, por exemplo, devido a regulamentos locais, você precisa criar uma solução de roteamento usando VMs de IaaS do Azure. Para obter alguns exemplos, consulte Cloud Adoption Framework do Azure – topologia de rede e conectividade para Solução VMware no Azure.
As máquinas virtuais implantadas na nuvem privada podem ser acessadas pela Internet por meio da funcionalidade IP público da WAN Virtual do Azure. Para as novas nuvens privadas, o acesso à Internet é desabilitado por padrão.
Para obter mais informações, consulte Arquitetura de rede.
Acesso e segurança
As nuvens privadas da Solução VMware no Azure usam o controle de acesso baseado em função do vSphere para aumentar a segurança. Você pode integrar as funcionalidades LDAP do SSO do vSphere com o Microsoft Entra ID. Para mais informações, confira a página Arquitetura de acesso e identidade.
A criptografia de dados em repouso do vSAN está habilitada por padrão e é usada para fornecer segurança ao armazenamento de dados do vSAN. Para saber mais, confira Arquitetura de armazenamento.
Residência de dados e dados do cliente
A Solução VMware no Azure não armazena os dados do cliente.
Versões do software VMware
As versões de software da solução VMware usadas em novas implantações de nuvens privadas da Solução VMware do Azure são:
| Software | Versão |
|---|---|
| VMware vCenter Server | 7.0 U3o |
| VMware ESXi | 7.0 U3o com TianfuCup HotPatch |
| VMware do vSAN | 7.0 U3 |
| Formato do VMware vSAN no disco | 15 |
| Arquitetura de armazenamento do VMware vSAN | OSA |
| VMware NSX | 4.1.1 |
| VMware HCX | 4.7.0 |
| Gerenciador do Site Recovery do VMware | 8.7.0.3 |
| Replicação do VMware vSphere | 8.7.0.3 |
A versão do software em execução no momento é aplicada aos novos clusters adicionados a uma nuvem privada existente.
Manutenção do ciclo de vida do host e do software
As atualizações regulares da nuvem privada da Solução VMware no Azure e do software da 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, confira Manutenção do host e gerenciamento do ciclo de vida.
Monitoramento da nuvem privada
Os logs do Azure Monitor são gerados automaticamente após a implantação da Solução VMware no Azure na sua assinatura.
Na sua nuvem privada, você pode:
- Coletar logs em cada uma das suas VMs.
- Baixar e instalar o agente MMA em VMs do Linux e do Windows.
- Habilitar a extensão de diagnóstico do Azure.
- Criar e executar novas consultas.
- Executar as mesmas consultas que você costuma executar nas suas VMs.
Os padrões de monitoramento da Solução VMware no Azure são semelhantes às VMs do Azure na plataforma IaaS. Para obter mais informações e instruções, confira Como monitorar VMs do Azure com o Azure Monitor.
Comunicação do 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 do log de atividades para essas notificações. Para obter mais informações, confira Criar alertas de Integridade do Serviço do Azure usando o portal do Azure.
Matriz de responsabilidades da Solução VMware no Azure – Comparação entre a Microsoft e o Cliente
A Solução VMware no Azure implementa um modelo de responsabilidades compartilhadas que define funções e responsabilidades distintas das duas partes envolvidas na oferta: cliente e Microsoft. As responsabilidades de função compartilhada são ilustradas mais detalhadamente nas duas tabelas a seguir.
A tabela de matriz de responsabilidades compartilhada descreve as principais tarefas que os clientes e a Microsoft realizam na implantação e gerenciamento das cargas de trabalho do cliente e do aplicativo de nuvem privada.
A tabela a seguir fornece uma lista detalhada de funções e responsabilidades entre o cliente e a Microsoft, que abrange as tarefas e as definições mais frequentes. Em caso de outras perguntas, entre em contato com a Microsoft.
| Função | Tarefa/detalhes |
|---|---|
| Microsoft – Solução VMware no Azure | Infraestrutura física
(opcional) Implantações do VMware HCX com o perfil de computação totalmente configurado no lado da nuvem como um complemento (opcional) VMware SRM implanta, atualiza e escala/reduz verticalmente Suporte – Plataformas de nuvem privada e VMware HCX |
| Customer | Solicitar a cotação do host da Solução VMware no Azure com a Microsoft Planeje e crie uma solicitação de nuvens privadas no portal do Azure com:
Adicionar ou excluir solicitações de hosts ao cluster por meio do portal Implantação/gerenciamento do ciclo de vida de soluções de parceiros (terceiros) |
| Ecossistema de parceiros | Suporte para o produto/a solução. Para referência, estas são algumas das soluções/alguns dos produtos compatíveis de parceiros da Solução VMware no Azure:
|
Próximas etapas
A próxima etapa é aprender os conceitos principais de arquitetura de nuvem privada.