Muitas empresas querem migrar os clusters do VMware para a nuvem para aproveitar a escalabilidade, a resiliência, a elasticidade e os serviços de nível superior da nuvem, como o Vertex AI Studio e o BigQuery. As empresas também querem mudar os gastos de um modelo de hardware com uso intensivo de capital para um modelo de despesas operacionais mais flexível. Para ajudar as empresas a criar rapidamente um ambiente operacional que siga as práticas recomendadas do Google Cloud, criamos o blueprint empresarial do Google Cloud VMware Engine. Este modelo oferece um guia completo para implantar um ambiente VMware pronto para uso empresarial e migrar as cargas de trabalho de VM para a nuvem.
O VMware Engine é um serviço totalmente gerenciado que permite executar a plataforma VMware no Google Cloud. Suas cargas de trabalho da VMware operam em hardware dedicado do Google Cloud, totalmente integrado aos serviços do Google Cloud. O Google cuida da infraestrutura, da rede e do gerenciamento. O blueprint permite implantar um projeto do Google Cloud que contém uma nuvem particular do VMware Engine, uma rede do VMware Engine gerenciada pelo Google e as conexões de peering de rede VPC que permitem o fluxo de tráfego de ponta a ponta.
O blueprint empresarial do VMware Engine inclui o seguinte:
- Repositórios do GitHub que contêm o código do Terraform e scripts auxiliares necessários para implantar a plataforma VMware Engine
- Um guia para os controles de arquitetura, rede e segurança que você usa para implementar os repositórios do GitHub (este documento).
O blueprint foi projetado para ser executado em uma base de serviços de nível básico, como redes VPC. Você pode usar o blueprint de base empresarial ou o Fabric FAST para criar a base desse blueprint.
Este documento é destinado a arquitetos de nuvem, administradores de plataformas de nuvem, administradores do VMware Engine e engenheiros do VMware Engine que podem usar o blueprint para criar e implantar clusters do VMware no Google Cloud. O blueprint se concentra no design e na implantação de uma nova nuvem privada do VMware Engine e pressupõe que você já conhece o VMware e o serviço gerenciado do VMware Engine.
Visão geral do blueprint empresarial do VMware Engine
O modelo empresarial do VMware Engine depende de uma abordagem em camadas para ativar a plataforma VMware Engine. O diagrama a seguir mostra a interação de vários componentes deste blueprint com outros blueprints e serviços.
O diagrama inclui os seguintes pontos:
- A infraestrutura do Google Cloud fornece recursos de segurança, como criptografia em repouso e criptografia em trânsito e elementos básicos, como computação e armazenamento.
- A base empresarial fornece uma referência de recursos, como rede, identidade, políticas, monitoramento e geração de registros. Esses recursos permitem adotar rapidamente o Google Cloud e atender aos requisitos de arquitetura da sua organização.
O modelo empresarial do VMware Engine oferece o seguinte:
- Uma rede do VMware Engine
- conectividade particular a redes, APIs e serviços da Google Virtual Private Cloud
- Uma nuvem privada do VMware Engine
- Recursos de backup
- Cloud Load Balancing
- Google Cloud Armor
- Os casos de uso incluem migrações de data center, expansão de capacidade elástica de data center, infraestrutura de área de trabalho virtual (VDI, na sigla em inglês) e cenários de recuperação de desastres de data center.
A automação de implantação usando um pipeline de CI/CD oferece as ferramentas para automatizar o provisionamento, a configuração e o gerenciamento da infraestrutura. A automação ajuda a garantir implantações consistentes, confiáveis e auditáveis, minimizar erros manuais e acelerar o ciclo de desenvolvimento geral.
Arquitetura
O diagrama a seguir mostra a arquitetura que o blueprint empresarial do VMware Engine implanta.
O blueprint implanta o seguinte:
- Um projeto do Google Cloud chamado projeto autônomo do VMware Engine que contém uma nuvem particular do VMware Engine
- Um projeto gerenciado pelo Google para a rede do VMware Engine
- As conexões de peering de rede VPC para que o tráfego possa fluir dos aplicativos do VMware Engine para os clientes
A nuvem privada do VMware Engine consiste nos seguintes componentes:
- Ferramentas de gerenciamento:VLAN e sub-rede para a rede de gerenciamento dos hosts ESXi, servidor DNS, servidor vCenter
- Backup:infraestrutura de backup para VMs de carga de trabalho
- Máquinas virtuais:VMs de carga de trabalho
- vCenter Server:gerenciamento centralizado do ambiente vSphere em nuvem privada
- NSX Manager:oferece uma interface única para configurar, monitorar e gerenciar os serviços de rede e segurança do NSX-T.
- Hosts ESXi:hipervisor em nós dedicados
- Armazenamento vSAN:plataforma de armazenamento hiperconvergente e definida por software
- Rede de sobreposição do NSX-T:software de virtualização e segurança de rede
- VMware HCX: migração de aplicativos e rebalanceamento de carga de trabalho em data centers e nuvens
Informações gerais sobre a rede do VMware Engine
A rede do VMware Engine é uma rede dedicada que conecta a nuvem privada do VMware Engine, as redes VPC e os ambientes locais. A rede do VMware Engine tem os seguintes recursos:
- Conectividade de nuvem privada:cada nuvem privada do VMware Engine está conectada a uma rede do VMware Engine, permitindo a comunicação entre as cargas de trabalho na nuvem privada.
- Conectividade de rede do VMware Engine:use o peering de rede VPC para estabelecer conectividade entre redes do VMware Engine e uma VPC do Google. Essa conectividade permite a comunicação entre cargas de trabalho executadas no VMware Engine e em outros serviços no Google Cloud.
- Conectividade local:para criar uma solução de nuvem híbrida, é possível estender as redes do VMware Engine para data centers locais usando o Cloud VPN ou o Cloud Interconnect.
- Serviços de rede:as redes do VMware Engine usam vários serviços de rede, incluindo os seguintes:
Com o VMware Engine, você é responsável por criar e gerenciar VMs de carga de trabalho usando a plataforma de gerenciamento de aplicativos do VMware. O Google Cloud é responsável por corrigir e atualizar os componentes da infraestrutura e corrigir os componentes com falha.
Principais decisões de arquitetura
| arearea de decisão | Decisão | Raciocínio da decisão |
|---|---|---|
| Base | É possível implementar o blueprint empresarial do VMware Engine no blueprint de fundação empresarial, no Fabric FAST ou em uma fundação que atenda aos pré-requisitos definidos. | O blueprint de base empresarial e o Fabric FAST fornecem os recursos básicos que ajudam as empresas a adotar o Google Cloud. |
| Compute | É possível implantar um único cluster particular em uma região específica ou dois clusters particulares em duas regiões. | A configuração de cluster particular único permite o gerenciamento simplificado e a otimização de custos. |
| O blueprint implanta um nó reserva. | Um único nó reserva permite que você tenha capacidade para lidar com falhas, eventos de manutenção e flutuações de carga de trabalho, minimizando os custos. | |
| O backup e a recuperação de desastres são gerenciados usando o Serviço de backup e DR. | O backup e o DR permitem usar um serviço gerenciado e reduzir a quantidade de administração necessária para uma implantação do VMware Engine. | |
| Rede | O blueprint ativa a conectividade híbrida. | A conectividade híbrida permite conectar seu ambiente local ao ambiente do Google Cloud. |
| A nuvem privada usa um espaço IP particular, roteável e contíguo. | O espaço IP contíguo facilita o gerenciamento de endereços IP. Quando o espaço IP é roteável, a nuvem privada pode se comunicar com seus recursos locais. | |
| O acesso à Internet é fornecido por um balanceador de carga do Cloud e é protegido pelo Google Cloud Armor. | O Google Cloud Armor aprimora a postura de segurança da carga de trabalho, enquanto o Cloud Load Balancing ajuda a ativar a escalonabilidade e a alta disponibilidade da carga de trabalho. | |
| O blueprint ativa o Cloud DNS. | O Cloud DNS resolve nomes internos e externos. |
Perfis de plataforma
O blueprint usa dois grupos de usuários: um grupo de engenharia de plataforma de nuvem e um grupo de engenharia de plataforma VMware. Esses grupos têm as seguintes responsabilidades:
- O grupo de engenharia da plataforma de nuvem é responsável pela implantação da base do blueprint do VMware Engine e pela implantação do blueprint.
- O grupo de engenharia de plataforma do VMware é responsável pela configuração e operação dos componentes do VMware que fazem parte da nuvem privada.
Se você estiver implantando o blueprint no blueprint de base corporativa ou no Fabric FAST, o grupo de engenharia da plataforma de nuvem será criado como parte do processo de implantação inicial. O grupo de engenharia de plataforma do VMware é implantado como parte deste blueprint.
Estrutura da organização
O blueprint empresarial do VMware Engine é baseado na estrutura organizacional do blueprint de base empresarial e do Fabric FAST. Ele adiciona um projeto independente do VMware Engine nos ambientes de produção, não produção e de desenvolvimento. O diagrama a seguir mostra a estrutura do modelo.
Rede
O modelo empresarial do VMware Engine oferece as seguintes opções de rede:
- Uma única rede VPC compartilhada para uma nuvem privada do VMware Engine
- Duas instâncias de VPC compartilhada para uma nuvem particular
Ambas as opções são implantadas em uma única região e permitem gerenciar o tráfego do seu ambiente local.
O diagrama a seguir mostra uma única rede VPC compartilhada para uma única região.
Separação de instâncias VPC compartilhadas permite agrupar custos e tráfego de rede em unidades de negócios distintas, mantendo a separação lógica na nuvem privada do VMware Engine. O diagrama a seguir mostra várias redes VPC compartilhadas em uma única região.
Rede de nuvem privada
Na nuvem privada, a rede é alimentada pelo NSX-T, que fornece uma camada de rede definida por software com recursos avançados, como microsegmentação, roteamento e balanceamento de carga. O blueprint do VMware Engine cria uma rede para seu serviço do VMware Engine. Essa rede é um único espaço de endereço de camada 3. O roteamento é ativado por padrão, permitindo que todas as nuvens e sub-redes particulares na região se comuniquem sem configuração extra. Como mostrado no diagrama abaixo, quando uma nuvem privada é criada, várias sub-redes são criadas, consistindo em sub-redes de gerenciamento, de serviço, de carga de trabalho e de serviço de borda.
Ao configurar a nuvem privada, é necessário selecionar um intervalo CIDR que não se sobreponha a outras redes na nuvem privada, na rede local, na rede de gerenciamento de nuvem privada ou nos intervalos de endereços IP de sub-rede na rede VPC. Depois que você seleciona um intervalo CIDR, o VMware Engine alocará automaticamente endereços IP para várias sub-redes. Usando um exemplo de intervalo CIDR 10.0.0.0/24, a tabela a seguir mostra os intervalos de endereços IP do blueprint para as sub-redes de gerenciamento.
| Sub-rede | Descrição | Intervalo de endereços IP |
|---|---|---|
| Gerenciamento de sistema | VLAN e sub-rede para a rede de gerenciamento dos hosts ESXi, servidor DNS e servidor vCenter | 10.0.0.0/26 |
| VMotion | VLAN e sub-rede para a rede vMotion dos hosts ESXi | 10.0.0.64/28 |
| Uplink HCX | Uplink para dispositivos HCX IX (mobilidade) e NE (extensão) para alcançar pares e permitir a criação da malha de serviço do HCX. | 10.0.0.216/29 |
As VMs de carga de trabalho estão contidas na sub-rede NSX-T. Os uplinks de borda NST-T oferecem conectividade externa. O tamanho do intervalo CIDR da nuvem privada define o número de nós ESXi que podem ser suportados na sub-rede NST-T. Os nós do ESXi usam a sub-rede do VSAN para transporte de armazenamento.
A tabela a seguir mostra os intervalos de endereços IP da sub-rede de transporte do host NSX-T, das sub-redes de uplink de borda NSX-T e das sub-redes do VSAN com base em um intervalo CIDR de 10.0.0.0/24.
| Sub-rede | Descrição | Intervalo de endereços IP |
|---|---|---|
| VSAN | A sub-rede do VSAN é responsável pelo tráfego de armazenamento entre hosts ESXI e clusters de armazenamento do VSAN. | 10.0.0.80/28 |
| Transporte para host NSX-T | A VLAN e a sub-rede para a zona de host ESXi responsável pela conectividade de rede, permitindo firewall, roteamento, balanceamento de carga e outros serviços de rede. | 10.0.0.128/27 |
| Uplink-N de borda do NSX-T [N=1-4] | O uplink de borda do NSX-T permite que sistemas externos acessem serviços e aplicativos em execução na rede do NSX-T. |
|
Para sub-redes de serviço e a sub-rede de serviço de borda, o VMware Engine não aloca um intervalo ou prefixo CIDR. Portanto, é necessário especificar um intervalo e um prefixo CIDR não sobrepostos. A tabela a seguir mostra os blocos CIDR do blueprint para as sub-redes de serviço e a sub-rede de serviço de borda.
| Sub-rede | Descrição | Intervalo de endereços IP |
|---|---|---|
| Service-N [N=1-5] | As sub-redes de serviço permitem que as máquinas virtuais ignorem o transporte do NSX e se comuniquem diretamente com a rede do Google Cloud para permitir comunicações de alta velocidade. |
|
| Serviço de borda | Obrigatório se estiverem ativados os serviços de borda opcionais, como VPN de ponto a site, acesso à Internet e endereço IP público. Os intervalos são determinados para cada região. | 10.0.1.0/26 |
Roteamento
Exceto as redes estendidas da sua rede local ou de outras nuvens privadas do VMware Engine, todas as comunicações no VMware Engine e para endereços IP externos são roteadas (pela camada 3) por padrão. O blueprint configura um Cloud Router associado à conexão híbrida local (usando o Cloud VPN ou o Cloud Interconnect) com rotas divulgadas personalizadas resumidas para os intervalos de endereços IP do VMware Engine. As rotas de segmento do NSX são sintetizadas no nível 0. O blueprint ativa os serviços DHCP pelo Relay DHCP do NSX-T para os serviços DHCP configurados na nuvem privada do VMware Engine.
Configuração do DNS
O VMware Engine permite usar uma zona do Cloud DNS no projeto como um endpoint de resolução de DNS único para todos os dispositivos de gerenciamento conectados em uma rede VPC com peering. É possível fazer isso mesmo que suas nuvens privadas sejam implantadas em diferentes regiões.
Ao configurar a resolução de endereço para várias e únicas nuvens privadas, configure a resolução de endereço global usando o Cloud DNS.
Por padrão, é possível resolver a zona de gerenciamento de qualquer uma das redes VPC que tenham o Cloud DNS ativado.
Quando o blueprint cria uma nuvem privada vinculada a uma rede padrão do VMware Engine, uma zona DNS de gerenciamento associada é criada e preenchida automaticamente com as entradas dos dispositivos de gerenciamento.
Se a rede padrão do VMware Engine for uma rede VPC com peering com uma VPC ou outra rede do VMware Engine, o blueprint vai criar automaticamente uma vinculação de zona de DNS de gerenciamento. Essa vinculação de zona garante a resolução de dispositivos de gerenciamento das VMs do Google Cloud nessa rede. O diagrama a seguir mostra a topologia do Cloud DNS.
Tráfego de saída do VMware Engine para a Internet
O blueprint oferece as três opções a seguir para o tráfego de saída do VMware Engine para a Internet:
- Saída pelo ambiente local do cliente
- Saída pelo gateway de Internet do VMware Engine
- Saída pela VPC anexada do cliente usando um endereço IP externo
O diagrama a seguir mostra essas opções.
Tráfego de entrada da Internet para o VMware Engine
O blueprint oferece as três opções a seguir para o tráfego vindo da Internet para o VMware Engine:
- Entrada pelo ambiente local do cliente
- Entrada por uma VPC do cliente com o Cloud Load Balancing e, possivelmente, o Google Cloud Armor
- Entrada pelo VMware Engine usando um endereço IP externo
O diagrama a seguir mostra essas opções.
Geração de registros
O blueprint permite enviar as ações administrativas do VMware Engine para os registros de auditoria do Cloud usando um sink de registro. Ao analisar os registros de auditoria do VMware Engine, os administradores podem identificar comportamentos suspeitos, investigar incidentes e demonstrar conformidade com os requisitos regulamentares.
As exportações de registro também podem servir como fontes de ingestão para sistemas de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês). O Google oferece suporte às seguintes fontes de transferência que atendem ao VMware Engine:
- A organização do Google Cloud de hospedagem, que inclui a telemetria de recursos e do cloud fabric
- Componentes de serviço do VMware
- Cargas de trabalho executadas no VMware Engine
O Google SecOps inclui um pipeline de ingestão de registros automatizado integrado para ingestão de dados da organização e fornece sistemas de encaminhamento para enviar a telemetria de streaming do VMware Engine e das cargas de trabalho para o pipeline de ingestão do Google SecOps. O Google SecOps enriquece a telemetria com conteúdo contextual e permite a pesquisa. Você pode usar o Google SecOps para encontrar e acompanhar problemas de segurança à medida que eles se desenvolvem.
Monitoramento
O blueprint instala um agente independente para o Cloud Monitoring para encaminhar métricas da sua nuvem privada para o Cloud Monitoring. O blueprint configura painéis predefinidos que fornecem uma visão geral dos recursos do VMware Engine e da utilização de recursos. No servidor vCenter do VMware, o VMware fornece ferramentas para ajudar a monitorar o ambiente e para localizar a origem dos problemas. Use essas ferramentas como parte das suas operações contínuas e como um complemento a outras opções de monitoramento.
Conforme mostrado no diagrama a seguir, o blueprint automatiza a implantação do agente independente usando um grupo de instâncias gerenciado implantado na VPC do cliente. O agente coleta métricas e registros do syslog do VMware vCenter e os encaminha para o Cloud Monitoring e o Cloud Logging.
Backups
O blueprint usa Backup e DR para fornecer serviços de proteção de dados para seus workloads do VMware. O serviço usa um dispositivo gerenciado implantado na VPC do cliente. O dispositivo está conectado ao plano de controle do Google por meio do Acesso privado do Google e de websockets. Os backups são armazenados no Cloud Storage, e o serviço oferece opções de recuperação granular, permitindo que você restaure arquivos individuais ou VMs inteiras para um ponto específico.
Práticas recomendadas de operações
Esta seção descreve algumas práticas recomendadas que podem ser implementadas, dependendo do ambiente e dos requisitos, após a implantação do blueprint.
Adicionar mais nós sobressalentes
Os clusters do VMware Engine são dimensionados automaticamente para ter pelo menos um nó extra para resiliência. Um nó reserva é um comportamento inerente no HA do vSphere, o que significa que esse nó está disponível no cluster e é faturado de acordo.
É possível adicionar mais nós sobressalentes ao cluster para garantir a capacidade durante janelas de manutenção. Essa decisão pode gerar custos de consumo adicionais, e esses nós são gerenciados diretamente pela sua organização.
Os nós sobressalentes adicionados aparecem como nós extras no cluster do vSphere. Opcionalmente, você pode programar cargas de trabalho nos nós sobressalentes.
Considere os limites de recursos para nuvens privadas
As nuvens privadas do VMware Engine têm limites de recurso em componentes de computação, armazenamento e rede. Considere esses limites durante a implantação da nuvem privada para que o ambiente possa ser dimensionado de acordo com as demandas da carga de trabalho.
Implementar opções de gerenciamento de custos
É possível implementar uma ou mais das seguintes opções para gerenciar seus custos:
- Descontos por compromisso de uso (CUDs)
- Escalonamento automático
- Limites de contagem de núcleos
- Sobresubscrição da capacidade de computação
Usar descontos por compromisso de uso
Os CUDs oferecem preços com desconto em troca do seu compromisso de usar um nível mínimo de recursos por um período especificado. Os CUDs do VMware Engine são aplicados para agregar o uso de nós do VMware Engine em uma região, oferecendo custos baixos e previsíveis, sem a necessidade de fazer alterações ou atualizações manuais. Os descontos se aplicam ao uso do nó do VMware Engine nas regiões em que o serviço está disponível e em que você comprou os CUDs.
Use o escalonamento automático.
O VMware Engine permite adicionar ou remover nós automaticamente em um cluster com base em limites e marcas d'água predefinidos. Essas políticas são acionadas se uma condição especificada for mantida por pelo menos 30 minutos. Ao aplicar ou atualizar uma política de escalonamento automático em um cluster do vSphere (padrão ou esticado), considere o seguinte:
- Por padrão, o escalonamento automático fica desativado. É necessário ativá-lo explicitamente para cada cluster.
- Em um cluster estendido, o número de nós especificado na política é adicionado ou removido por zona, o que afeta o faturamento.
- Como o uso de computação, memória e armazenamento geralmente são independentes, as políticas de escalonamento automático que monitoram várias métricas usam a lógica OR para adição do nó e a lógica AND para remoção do nó.
- Os valores máximos de escalonamento automático são determinados pelas cotas disponíveis no seu projeto do Google Cloud e na nuvem privada do VMware Engine.
- Ativar o escalonamento automático e adicionar ou remover manualmente um nó não são mutuamente exclusivos. Por exemplo, com a política de otimização de capacidade de armazenamento, é possível remover manualmente um nó se o espaço em disco da VM for reduzido o suficiente para acomodar todas as VMs no cluster. Embora seja possível remover nós manualmente, essa não é uma prática recomendada ao usar o escalonamento automático.
Limitar a contagem de núcleos
O VMware Engine permite que os administradores reduzam o número de núcleos de CPU eficazes expostos ao SO convidado, que é a VM em execução sobre o VMware Engine. Alguns contratos de licença de software exigem que você reduz as cores expostas.
Subscrever demais a capacidade de computação do VMware Engine
A supersubscrição da capacidade de computação do VMware Engine é uma prática padrão e, diferente dos nós de locatário único do Compute Engine, não gera custos adicionais. Uma proporção de supersubscrição maior pode ajudar a diminuir o número de nós faturáveis eficazes no seu ambiente, mas pode afetar o desempenho do aplicativo. Ao dimensionar cargas de trabalho empresariais, recomendamos usar uma proporção de 4:1 para começar e, em seguida, modificar a proporção com base em fatores aplicáveis ao seu caso de uso.
Implantar o blueprint
É possível implantar o blueprint no blueprint de base empresarial ou no Fabric FAST.
Para implantar o blueprint no blueprint de base empresarial, faça o seguinte:
- Implantar o blueprint de base empresarial.
- Implante o blueprint empresarial do VMware Engine. Para instruções, consulte o repositório de modelo empresarial do VMware Engine.
Para implantar o blueprint no Fabric FAST, consulte o repositório do Fabric FAST. O Google Cloud VMware Engine Stage implanta o modelo empresarial do VMware Engine.
Implantar o blueprint sem o blueprint de bases empresariais ou o Fabric FAST
Para implantar o blueprint sem implantar primeiro o blueprint de bases empresariais ou o Fabric FAST, verifique se os seguintes recursos estão no seu ambiente:
- Uma hierarquia de organização com
development,nonproductione pastasproduction - Uma rede VPC compartilhada para cada pasta
- Um esquema de endereço IP que considera os intervalos de endereços IP necessários para as nuvens privadas do VMware Engine.
- Um mecanismo de DNS para suas nuvens privadas do VMware Engine
- Políticas de firewall alinhadas à sua postura de segurança
- Um mecanismo para acessar APIs do Google Cloud por meio de endereços IP internos.
- Um mecanismo de conectividade com o ambiente no local
- Geração de registros centralizada para segurança e auditoria
- Políticas da organização alinhadas com sua postura de segurança
- Um pipeline que pode ser usado para implantar o VMware Engine
A seguir
- Leia sobre o VMware Engine.
- Saiba como migrar instâncias de VM do VMware para sua nuvem privada.
- Leia as práticas recomendadas de computação.
- Leia as práticas recomendadas de rede.
- Leia as práticas recomendadas para a segurança do VMware Engine.
- Leia as práticas recomendadas de armazenamento.
- Leia as práticas recomendadas para precificação.
- Acesse a página do VMware Engine.