Rede de nuvem particular para o Google Cloud VMware Engine

Publicado pela primeira vez: 25 de janeiro de 2021

Neste documento, você encontra uma visão geral do Google Cloud VMware Engine, discute conceitos de rede, analisa os fluxos de tráfego mais comuns e vê algumas considerações sobre como usar o VMware Engine para desenvolver uma arquitetura. Neste documento, explicamos como o VMware Engine funciona, quais são os recursos dele e o que deve ser considerado ao decidir a melhor arquitetura.

Este documento será relevante se você for um engenheiro de rede, engenheiro de nuvem, arquiteto ou operador encarregado de projetar, manter ou solucionar problemas de segurança, conectividade e disponibilidade de aplicativos protegidos por VMware hospedados no Google Cloud.

Veja neste documento mais informações sobre o VMware Engine e os requisitos e capacidades dele. Conforme você se aprofundar na tecnologia, ou se planeja testar ou implantar a produção, este documento ajuda a entender como o VMware Engine funciona e como integrá-lo a um ambiente novo ou atual do Google Cloud. Este documento analisa todos os aspectos da rede e ajuda a determinar a melhor solução para seu caso de uso.

A rede do VMware Engine se integra a redes de nuvem privada virtual (VPC) que tenham conectividade atual com redes locais e também com outros serviços do Google Cloud. O VMware Engine foi criado com base em uma infraestrutura de alto desempenho, confiável e de alta capacidade para proporcionar aos clientes uma experiência otimizada e econômica com o VMware.

Visão geral

O VMware Engine é um serviço do Google que ajuda a migrar e executar suas cargas de trabalho VMware no Google Cloud.

O VMware Engine fornece um data center totalmente gerenciado definido por software (SDDC, na sigla em inglês), que consiste nos seguintes componentes: VMware vSphere, vCenter Server, vSAN e NSX-T. O VMware Engine inclui o HCX (em inglês) para migração em nuvem em um ambiente dedicado no Google Cloud para dar suporte a cargas de trabalho de produção corporativas. É possível usar o VMware Engine para migrar ou estender as cargas de trabalho locais para o Google Cloud conectando-se a um ambiente VMware dedicado diretamente pelo Console do Google Cloud. Esse recurso permite migrar para a nuvem sem ter o custo ou a complexidade dos aplicativos de refatoração, além de permitir executar e gerenciar cargas de trabalho de maneira consistente com o ambiente local. Ao executar as cargas de trabalho VMware no Google Cloud, você reduz a carga operacional enquanto aproveita a escala e a agilidade, além de manter a continuidade com suas ferramentas, políticas e processos atuais.

O VMware Engine foi criado na infraestrutura escalonável e de alto desempenho do Google Cloud. Ele tem uma rede totalmente redundante e dedicada de 100 Gbps, que fornece até 99,99% de disponibilidade para atender às necessidades da sua pilha do VMware. Os serviços e rede como Cloud Interconnect e Cloud VPN oferecem acesso dos seus ambientes locais para a nuvem. A alta largura de banda dessas conexões com serviços em nuvem é otimizada para desempenho e flexibilidade, minimizando os custos e a sobrecarga operacional. A compatibilidade completa e de ponta a ponta é integrada para fornecer uma experiência perfeita nesse serviço e no restante do Google Cloud.

Depois de mover as cargas de trabalho, você terá acesso imediato aos serviços do Google Cloud, como BigQuery, Operações do Cloud, Cloud Storage, Anthos e Cloud AI. O Google Cloud também oferece faturamento e gerenciamento de identidade e controle de acesso integrados para unificar sua experiência com outros produtos e serviços do Google Cloud.

Casos de uso

O diagrama a seguir é uma arquitetura de referência representativa que mostra como migrar ou estender seu ambiente VMware para o Google Cloud, além de se beneficiar dos serviços do Google Cloud. O VMware Engine oferece soluções para os casos de uso a seguir.

Arquitetura de referência que mostra como migrar ou estender seu ambiente VMware para o Google Cloud.

Requisitos de integração

Antes de iniciar a implantação do VMware no Google Cloud, leia os requisitos de integração.

Componentes do sistema

Em um nível alto, os componentes do VMware Engine são os seguintes:

  • Google Cloud:
    • VMware Engine:
      • NSX-T
      • HCX
      • vCenter
      • vSAN
    • Sua organização do Google Cloud:
      • Seu projeto do Google Cloud que tem uma rede VPC
      • Cloud Interconnect usando a Interconexão por parceiro ou a Interconexão dedicada ou a conexão por Cloud VPN para sistemas locais
      • Conexão de acesso privado a serviços para a região do VMware Engine
    • Conexão de acesso privado a serviços
    • Integração de serviços gerenciados do Google
  • (Opcional) Recursos locais:
    • Rede
    • Armazenamento
    • HCX (recomendado para conexões L2, também conhecida como extensão L2)
    • vCenter

Uma nuvem particular é uma pilha VMware isolada que consiste em hosts ESXi, vCenter, vSAN, NSX-T e HCX. Esses componentes são conhecidos coletivamente como os componentes do Google Cloud VMware Engine e são implantados quando o administrador da nuvem cria uma nuvem particular. Assim, os usuários da sua organização podem acessar de maneira privada as nuvens particulares do VMware Engine pelas redes VPC, estabelecendo uma conexão de acesso privado a serviços. O diagrama a seguir mostra essa arquitetura.

Acesso privado a serviços.

O acesso privado a serviços é uma conexão privada entre sua rede VPC e uma rede de propriedade do Google ou de terceiros. O Google ou o terceiro, entidades que oferecem serviços, também são conhecidos como produtores de serviços.

Para cada rede VPC de cliente conectada ao VMware Engine, há uma rede VPC de produtor de serviço que é criada quando os clientes criam uma conexão de acesso privado a serviços no Google Cloud. Esse projeto contém uma rede VPC compartilhada que pode ser usada para se conectar a outros serviços do Google Cloud, como o Cloud SQL e o Memorystore.

O VMware não exige que você use o NSX-T no local. Além disso, o uso do HCX não é obrigatório para nenhum dos casos de uso, porque é possível usar outros mecanismos para alcançar uma extensão de camada 2 (L2) e a migração da carga de trabalho. No entanto, recomendamos o HCX para uma migração eficiente e a conveniente de cargas de trabalho eficientes, porque esse recurso é implantado automaticamente quando você cria a nuvem particular. Em outras palavras, o HCX será implantado independente de você usá-lo ou não.

Recursos de rede

Veja a seguir um resumo dos recursos de rede no VMware Engine:

  • Sub-redes: é possível criar sub-redes de gerenciamento e carga de trabalho em nuvens particulares.
  • Roteamento dinâmico: as sub-redes do VMware Engine administradas pelo NSX são anunciadas automaticamente para o restante da rede do Google, assim como para seus locais, pelo Border Gateway Protocol (BGP).
  • Serviço de IP público e gateway de Internet (entrada e saída): o VMware Engine tem um serviço de IP público próprio para entrada e saída do gateway de Internet. Este é um serviço regional.
  • Políticas de firewall: o VMware Engine permite criar políticas de firewall L4 e L7 usando o firewall distribuído NSX (leste-oeste) e o firewall de gateway NSX (norte-sul). Por exemplo, é possível aplicar controles granulares para acessar cargas de trabalho com endereços IP públicos, como servidores da Web.
  • Cadeia de serviços para a segurança leste-oeste: oferece a capacidade de registrar uma solução de segurança do parceiro (IDS, IPS ou NGFW) para configurar serviços de rede para inspecionar o tráfego leste-oeste entre VMs.
  • Serviço de detecção de invasão (IDS, na sigla em inglês) distribuído NSX-T: a versão do NSX em execução no VMware Engine é compatível com IDS distribuído NSX para detecção e geração de relatórios de ameaças. Esse recurso requer uma licença extra do VMware. Para mais informações, consulte IDS/IPS distribuído NSX do VMware.
  • Proteção do endpoint: as VMs que contam o VMware Engine podem ser protegidas contra malware e vírus pela integração de parceiros, com terceiros compatíveis. Para mais informações, consulte a documentação oficial da VMware.
  • Acesso privado a outros serviços do Google: o VMware Engine se integra a outros serviços do Google Cloud usando o Acesso privado do Google e o acesso privado a serviços. Para uma lista completa dos serviços compatíveis, consulte Opções de acesso privado a serviços.
  • Perfis de DNS
    • DNS para gerenciamento: para cada nuvem particular, o VMware Engine implanta automaticamente um par de servidores DNS para resolver os vários componentes de gerenciamento (vCenter, NSX Manager e assim por diante).
    • DNS para cargas de trabalho: para cada nuvem particular, você decide qual é a melhor configuração de DNS. O serviço DNS NSX-T permite encaminhar consultas DNS a determinados servidores DNS, além de criar seu servidor DNS no VMware Engine ou local, ou usar o Cloud DNS.
  • Servidor DHCP: o suporte ao servidor DHCP para segmentos NSX-T está incluído.
  • Redirecionamento do DHCP: o redirecionamento do DHCP permite que as organizações se integrem a um sistema de gerenciamento de endereços IP locais (IPAM, na sigla em inglês), por exemplo.
  • VPN ponto a site: o gateway VPN de ponto a site permite que você se conecte remotamente à sua rede do VMware Engine de um computador cliente para a nuvem particular. Para se conectar ao VMware Engine do computador, é necessário um cliente VPN. Faça o download do cliente OpenVPN para Windows ou Viscosity para macOS.
  • VPN L2 site a site e VPN L3: esses serviços são configurados diretamente no NSX usando a VPN L2 e a VPN IPsec, respectivamente.
  • Balanceamento de carga: esse serviço usa os recursos de balanceamento de carga integrados do NSX-T, que incluem compatibilidade com L4 e L7, além de verificações de integridade.
  • Compatibilidade com roteamento multicast de IP parcial: o protocolo multicast independente (PIM, na sigla em inglês) é compatível, conforme descrito na documentação da VMware.
  • Suporte parcial ao IPv6: este recurso permite que as organizações aproveitem o IPv6 para seus aplicativos compatíveis com VMware Engine, conforme descrito na Guia de criação do NSX-T 3.0.
  • Migração de VM de longa distância (vMotion): as migrações em tempo real (com aplicativos em execução) e a frio (aplicativos desativados) são compatíveis entre o local e a nuvem ou entre nuvens no VMware Engine com otimização da WAN incorporada, criptografia e mobilidade com replicação. Isso é possível por causa do VMware HCX, que está incluído no serviço.
  • Operações de rede avançadas: é possível usar ferramentas e instrumentação NSX integradas, como espelhamento de portas, Traceflow, captura de pacotes e SNMP v1/v2/v3 com pesquisa e armadilhas, entre outros.

Redes e intervalos de endereços

O Google Cloud VMware Engine cria uma rede para cada região em que o serviço do VMware Engine está implantado. A rede é um único espaço de endereço de camada 3 do TCP com roteamento ativado por padrão. Todas as nuvens e sub-redes particulares criadas nesta região podem se comunicar sem configurações extras. Você pode criar segmentos de rede (sub-redes) usando NSX-T para suas máquinas virtuais de carga de trabalho. É possível configurar qualquer intervalo de endereços RFC 1918 que não se sobreponha a redes locais, à rede de gerenciamento da nuvem particular ou a qualquer sub-rede VPC.

Por padrão, todas as sub-redes podem se comunicar entre si, reduzindo a sobrecarga de configuração para o roteamento entre as nuvens particulares. O tráfego de dados em nuvens particulares na mesma região permanece na mesma rede da camada 3 e transfere pela infraestrutura de rede local na região. Portanto, a saída não é necessária para a comunicação entre essas nuvens particulares. Essa abordagem elimina qualquer penalidade de desempenho de saída ou WAN quando você implanta cargas de trabalho diferentes em nuvens particulares diferentes.

Conceitualmente, uma nuvem particular é criada como um ambiente isolado da pilha do VMware (ESXi, hosts, vCenter, vSAN e NSX) gerenciado por um servidor do vCenter. Os componentes de gerenciamento são implantados na rede selecionada para o intervalo CIDR de sub-redes do vSphere/vSAN. O intervalo CIDR da rede é dividido em diferentes sub-redes durante a implantação.

Como gerenciar sub-redes no VMware Engine

O VMware Engine usa vários intervalos de endereços IP. Alguns dos intervalos de endereços IP são obrigatórios e alguns dependem dos serviços que você planeja implantar. Os espaços de endereço não podem se sobrepor a nenhuma das sub-redes locais, sub-redes VPC ou sub-redes de carga de trabalho planejadas. Nas seções a seguir, você verá o conjunto de intervalos de endereços e os serviços correspondentes que usam esses intervalos.

No diagrama a seguir, é apresentada uma visão geral das sub-redes de gerenciamento dos serviços explicados nas próximas seções:

Sub-redes de gerenciamento.

CIDR do vSphere/vSAN

Os seguintes intervalos de endereços IP são necessários para inicializar e criar uma nuvem particular:

Nome Descrição Intervalo de endereços
CIDR do vSphere/vSAN Obrigatório para redes de gerenciamento VMware. Precisa ser especificado durante a criação da nuvem particular. Também é necessário para o vMotion. /21, /22, /23 ou /24
.

Quando você cria uma nuvem particular, várias sub-redes de gerenciamento são criadas automaticamente. As sub-redes de gerenciamento usam a alocação de CIDR do vSphere/vSAN necessária descrita anteriormente neste documento. Veja abaixo um exemplo de arquitetura e descrição das diferentes sub-redes criadas usando esse intervalo CIDR:

  • Gerenciamento do sistema: VLAN e sub-rede para a rede de gerenciamento dos hosts ESXi, servidor DNS e servidor vCenter.
  • vMotion: VLAN e sub-rede para a rede vMotion dos hosts ESXi.
  • vSAN: VLAN e sub-rede para a rede vSAN de hosts ESXi.
  • NsxtEdgeUplink1: VLAN e sub-rede para uplinks de VLAN para uma rede externa.
  • NsxtEdgeUplink2: VLAN e sub-rede para uplinks de VLAN para uma rede externa.
  • NsxtEdgeTransport: VLAN e sub-rede para zonas de transporte controlam o alcance das redes da camada 2 no NSX-T.
  • NsxtHostTransport: VLAN e sub-rede para a zona de transporte do host.

Exemplo:

O intervalo CIDR de sub-redes vSphere/vSAN especificado é dividido em várias sub-redes. A tabela a seguir é um exemplo de divisão dos prefixos permitidos (de /21 a /24) usando 192.168.0.0 como o intervalo CIDR.

CIDR/prefixo de sub-redes especificadas do vSphere/vSAN 192.168.0.0/21 192.168.0.0/22 192.168.0.0/23 192.168.0.0/24
Gerenciamento de sistema 192.168.0.0/24 192.168.0.0/24 192.168.0.0/25 192.168.0.0/26
vMotion 192.168.1.0/24 192.168.1.0/25 192.168.0.128/26 192.168.0.64/27
vSAN 192.168.2.0/24 192.168.1.128/25 192.168.0.192/26 192.168.0.96/27
Transporte para host NSX-T 192.168.4.0/23 192.168.2.0/24 192.168.1.0/25 192.168.0.128/26
Transporte de borda de NSX-T 192.168.7.208/28 192.168.3.208/28 192.168.1.208/28 192.168.0.208/28
Uplink1 de borda NSX-T 192.168.7.224/28 192.168.3.224/28 192.168.1.224/28 192.168.0.224/28
Uplink2 de borda NSX-T 192.168.7.240/28 192.168.3.240/28 192.168.1.240/28 192.168.0.240/28

Dependendo do intervalo CIDR selecionado, a máscara de sub-rede para cada sub-rede muda. Por exemplo, se você selecionar um CIDR vSphere/vSAN de /21, as sub-redes a seguir são criadas: uma sub-rede de gerenciamento de sistema /24, uma sub-rede vMotion /24, uma sub-rede vSAN /24, uma sub-rede de transporte de host NSX-T /23, uma sub-rede de transporte de borda NSX-T /28, um uplink1 de borda NSX-T /28 e um uplink2 de borda NSX-T /28.

Intervalo CIDR de implantação do HCX

Os seguintes intervalos de endereços IP são necessários para HCX na sua nuvem particular:

Nome Descrição Intervalo de endereços
Intervalo CIDR de implantação do HCX Obrigatório para implantar redes HCX. Opcional durante a criação da nuvem particular. /27 ou maior

Intervalo de endereços atribuído

Os seguintes endereços IP são necessários para o acesso privado a serviços no VMware Engine:

Nome Descrição Intervalo de endereços
Intervalo de endereços atribuído Intervalo de endereços a ser usado para Private Server Connection aos serviços do Google Cloud, incluindo o VMware Engine. /24 ou maior

Serviços de borda e sub-rede do cliente

Os seguintes intervalos de endereços IP são necessários para ativar os serviços de rede de borda fornecidos pelo VMware Engine:

Nome Descrição Intervalo de endereços
Intervalo CIDR para serviços 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 por região. /26
Sub-rede do cliente Obrigatório para VPN ponto a site. Os endereços DHCP são fornecidos à conexão VPN por uma sub-rede do cliente. /24

Opções de Acesso privado do Google a serviços

O Google Cloud oferece várias opções de acesso privado para cargas de trabalho em execução no VMware Engine ou nas redes da nuvem privada virtual do Google. O acesso privado a serviços fornece uma conexão particular entre sua rede VPC e o serviço do VMware Engine. Quando você usa o Acesso privado do Google, suas cargas de trabalho da VMware podem acessar outras APIs e serviços Cloud sem sair da rede do Google Cloud.

Acesso privado a serviços

O VMware Engine usa o acesso privado a serviços para conectar sua rede VPC a uma rede VPC de produtor de serviço em uma pasta de locatário na organização do Google usando endereçamento IP particular.

Para mais informações sobre como configurar o acesso privado a serviços, consulte Como configurar o acesso privado a serviços. O acesso privado a serviços cria uma conexão de peering de rede VPC. Por isso, é importante importar e exportar rotas.

O Google e terceiros, conhecidos conjuntamente como produtores de serviços, podem oferecer serviços com endereços IP internos hospedados em uma rede VPC. O acesso privado a serviços permite que você acesse esses endereços IP internos. A conexão particular permite a seguinte funcionalidade:

  • As instâncias de VM na sua rede VPC e as VMs do VMware se comunicam exclusivamente usando endereços IP internos. As instâncias de VM não precisam de acesso à Internet ou de endereços IP externos para alcançar serviços disponíveis pelo acesso privado a serviços.

  • Comunicação entre os serviços compatíveis do VMware e do Google Cloud que são compatíveis com o acesso privado a serviços usando endereços IP internos.

  • Se você tiver conectividade local usando o Cloud VPN ou o Cloud Interconnect com sua rede VPC, poderá usar conexões locais atuais para se conectar à nuvem particular do VMware Engine.

Se você estiver usando uma rede VPC compartilhada no seu próprio projeto, o intervalo de IP alocado e a conexão particular precisarão ser criados no projeto host para permitir que as instâncias de VM em projetos de serviço tenham conectividade com o ambiente.

É possível configurar o acesso privado a serviços independentemente da criação da nuvem particular do VMware Engine. Também é possível criar uma conexão particular antes ou depois de criar a nuvem particular a que você quer conectar sua rede VPC.

Portanto, ao configurar o acesso privado a serviços, você precisa alocar um intervalo de endereços IP internos e criar uma conexão particular, conforme mencionado na seção anterior. Esse intervalo alocado é um bloco CIDR reservado usado para a conexão de acesso privado a serviços e não pode ser usado na sua rede VPC local. Esse intervalo é reservado apenas para produtores de serviços e evita a sobreposição entre sua rede VPC e a rede VPC do produtor de serviço. Quando você cria uma conexão particular a serviços, precisa especificar uma alocação. Para mais informações sobre o lado do produtor de serviços, consulte Como ativar o acesso privado a serviços.

Para evitar sobreposições de endereços IP, recomendamos alocar todas as sub-redes do VMware Engine na conexão particular a serviços. Na captura de tela a seguir, o bloco CIDR do VMware Engine é usado para a conexão particular a serviços e o bloco gcve-2 CIDR é alocado para evitar sobreposições de endereços IP:

O bloco CIDR do VMware Engine é usado para a conexão particular a serviços.

O Service Networking não verifica endereços sobrepostos em rotas dinâmicas recebidas. Por isso, você precisa associar o acesso privado a serviços com prefixos reservados para serviços que não sejam do VMware. Isso evita os problemas causados pela sobreposição de endereços IP porque você está reservando intervalos CIDR e não poderá usá-los na sua rede VPC.

Ao configurar o acesso privado a serviços, verifique se a conexão de peering de VPC está configurada corretamente para importar e exportar todas as rotas na conexão particular servicenetworking-googleapis-com. Você também precisa observar o ID do projeto de peering para usá-lo ao configurar uma conexão particular no VMware Engine.

A rede VPC do produtor de serviço é automaticamente conectada ao serviço VMware Engine, que contém sua nuvem particular (um vCenter particular e instalação NSX-T única).

O VMware Engine usa a mesma conexão com vários serviços do Google Cloud provisionados na VPC do produtor de serviços que usam acesso privado a serviços, como Cloud SQL, Memorystore para Redis, Memorystore para Memcached, AI Platform Training e clusters particulares do GKE. Se você quiser usar esses serviços, selecione o intervalo CIDR usado para estabelecer a conexão particular a serviços com o VMware Engine.

No portal de serviços do VMware Engine, quando o status da região estiver conectado, será possível revisar a conexão particular usando o ID do projeto de locatário da região correspondente. Os detalhes da conexão particular exibem as rotas aprendidas pelo peering de VPC. As rotas exportadas exibem nuvens particulares aprendidas da região e exportadas por peering de VPC.

Uma nuvem particular representa um único vCenter e uma única instalação de NSX-T com no máximo 64 nós. É possível implantar várias nuvens particulares e, se você atingir o limite de 64 nós para uma nuvem particular, poderá criar outra nuvem particular. Isso significa que você gerencia duas nuvens particulares, duas instalações do vCenter e duas instalações NSX-T.

Dependendo do caso de uso, é possível implantar uma única nuvem particular ou implantar várias nuvens particulares sem atingir o limite de 64 nós. Por exemplo, é possível implantar uma nuvem particular com cargas de trabalho de banco de dados e uma nuvem particular separada para um caso de uso de VDI, ou uma nuvem particular para cargas de trabalho nas Américas, e uma nuvem particular diferente para cargas de trabalho EMEA. Alternativamente, é possível separar cargas de trabalho em vários clusters na mesma nuvem particular, dependendo do seu caso de uso.

Acesso privado do Google

O Acesso privado do Google permite que você se conecte a APIs e serviços do Google sem atribuir endereços IP externos às VMs do VMware Engine. Depois que o Acesso privado do Google é configurado, o tráfego é roteado para o gateway da Internet e para o serviço solicitado sem sair da rede do Google.

Para mais informações, consulte Acesso privado do Google: mais detalhes.

Principais fluxos de tráfego

Nesta seção, analisamos alguns fluxos de tráfego importantes e descrevemos a arquitetura usada para abranger todos os fluxos de rede.

Veja a seguir exemplos do que você precisa considerar ao criar um design para o VMware Engine.

Conectividade entre VMware Engine e usuário remoto

Veja a seguir as opções para acessar o ambiente VMware Engine em um data center local ou de um local remoto:

Os gateways de VPN fornecem conectividade segura entre vários locais, como redes locais, redes VPC e nuvens particulares. Essas conexões de VPN criptografadas passam pela Internet e são encerradas em um gateway de VPN. Quando você cria várias conexões para o mesmo gateway da VPN, todos os túneis da VPN compartilham a largura de banda do gateway disponível.

Gateways VPN de ponto a site permitem que os usuários se conectem remotamente ao VMware Engine pelos computadores. Só é possível criar um gateway de VPN de ponto a site por região.

O gateway da VPN de ponto a site permite conexões TCP e UDP, e é possível escolher o protocolo a ser usado quando você se conecta pelo computador. Além disso, a sub-rede do cliente configurada é usada para clientes TCP e UDP, e o intervalo definido pelo bloco CIDR é dividido em duas sub-redes, uma para clientes TCP e outra para clientes UDP.

Uma VPN ponto a site envia tráfego criptografado entre uma rede regional do VMware Engine e um computador cliente. É possível usar a VPN ponto a ponto para acessar sua rede de nuvem particular, incluindo o vCenter da nuvem particular e VMs de carga de trabalho. Para informações sobre a configuração do gateway da VPN de ponto para site, consulte Como configurar gateways de VPN na rede do VMware Engine.

Também é possível usar o Cloud VPN para conectividade VPN entre sites ou o Cloud Interconnect para estabelecer conexões entre sua rede local e a nuvem particular do VMware Engine. Provisione o Cloud VPN e o Cloud Interconnect na sua rede VPC. Para mais informações, consulte a documentação do Cloud VPN e do Cloud Interconnect.

Outra opção para a conectividade VPN é, por exemplo, VPN NSX-T IPsec, VPN NSX-T L2 e a VPN HCX L2, por exemplo, para configurar uma extensão L2. Um caso de uso para a VPN NSX-T IPsec é a criptografia completa com a terminação de VPN diretamente na nuvem particular do VMware Engine. Para mais informações sobre os recursos da VPN NSX-T, consulte a documentação da rede privada virtual da VMware.

Recomendamos que você configure o acesso privado a serviços na rede VPC em que o Cloud Router ou o Cloud VPN está localizado (e onde os anexos da VLAN existem caso o protocolo de gateway de borda esteja sendo usado). Caso contrário, as rotas de VPC precisarão ser configuradas. Se a arquitetura tiver várias conexões de peering de VPC, lembre-se de que o peering de VPC não é transitivo.

As rotas locais anunciadas por interconexão ou VPN são propagadas automaticamente pelo acesso privado a serviços se a importação e exportação de rotas estiver configurada. Isso requer que você edite manualmente as rotas de importação e exportação na conexão de peering de VPC.

Além disso, lembre-se de que as rotas aprendidas pelo acesso privado a serviços não são propagadas automaticamente para sistemas locais. Isso acontece porque o peering de rede VPC não é compatível com o roteamento transitivo. As rotas importadas de outras redes não são divulgadas automaticamente pelos Cloud Routers na sua rede VPC. No entanto, é possível usar divulgações de intervalo de IP personalizadas desses Cloud Routers na sua rede VPC para compartilhar rotas para destinos na rede com peering. Para túneis do Cloud VPN que usam roteamento estático, você precisa configurar rotas estáticas para os intervalos de destino da rede com peering na sua rede local.

Entrada para o VMware Engine

Nesta seção, descrevemos as seguintes opções para entrada no VMware Engine:

  • Entrada usando o serviço de IP público do VMware Engine
  • Entrada do VPC do cliente
  • Entrada de um data center no local

A opção selecionada depende de onde você quer fazer peering da sua infraestrutura do Google Cloud com a Internet. No diagrama a seguir, mostramos essas opções de entrada.

Opções de entrada.

As seções a seguir descrevem cada opção em detalhes.

Entrada usando o VMware Engine

Quando você usa o gateway de Internet do VMware Engine, é possível criar e excluir endereços IP públicos sob demanda para recursos dentro da nuvem particular do portal do VMware Engine. Nesse cenário, cada endereço IP público corresponde a um endereço IP de nuvem particular configurado exclusivo.

A entrada pública pode ser fornecida por gateway de IP público, que também é responsável pelo NAT, para que os usuários provenientes da Internet pública se conectem ao endereço IP público do Google. O endereço IP público do Google é convertido em um endereço IP particular de máquina virtual no VMware Engine (com segmentos NSX-T).

Quando você cria regras de firewall para permitir conexões de entrada de fora de um IP público exposto, as regras de firewall são aplicadas a um gateway IP público e essas regras de firewall precisam ser provisionadas no portal do VMware Engine.

Um roteador lógico nível 0 geralmente é usado para o roteamento norte-sul, como uma máquina virtual conectada à Internet. Um roteador lógico nível 1 é usado para o roteamento leste-oeste, sendo possível configurar várias sub-redes para o nível 1.

Um endereço IP público permite que os recursos da Internet se comuniquem com entradas de recursos particulares da nuvem em um endereço IP particular. O endereço IP particular é uma máquina virtual ou um balanceador de carga de software no seu vCenter da nuvem particular. Com o endereço IP público, é possível expor à Internet os serviços em execução na nuvem particular.

Um recurso associado a um endereço IP público sempre usa o endereço IP público para acessar a Internet. Por padrão, apenas o acesso de saída à Internet é permitido em um endereço IP público, e o tráfego de entrada nesse endereço IP é negado. Para permitir o tráfego de entrada, crie uma regra de firewall para o endereço IP público com a porta específica.

Os usuários da sua organização podem expor e alocar IPs públicos para nós específicos na nuvem particular, como cargas de trabalho de VM. O endereço IP público pode ser atribuído a apenas um endereço IP particular. O endereço IP público é dedicado ao endereço IP particular até que você o cancele. Recomendamos que você não exponha hosts ESXi ou vCenter.

Se você quiser alocar um IP público, será necessário fornecer um nome, um local ou uma região, além do endereço local anexado.

Entrada usando uma rede VPC de um cliente

É possível fornecer entrada para o VMware Engine por rede VPC do cliente usando o Cloud Load Balancing. Ao selecionar o balanceador de carga, dependendo dos recursos necessários, é possível criar um grupo de instâncias gerenciadas (MIG) ou um grupo de instâncias não gerenciadas como o back-end do balanceador de carga para representar o tráfego pela conexão de peering de VPC. Nesse cenário, também é possível usar um dispositivo de rede virtual de terceiros do Google Cloud Marketplace.
É possível combinar o Cloud Load Balancing com Traga seu próprio IP (BYOIP, na sigla em inglês) caso queira usar seu próprio espaço de IP público no Google e com o Google Cloud Armor para ajudar a proteger seus aplicativos e sites contra ataques distribuídos de negação de serviço (DDOS, na sigla em inglês) e ataques na Web, como injeção SQL ou scripts entre sites.

Entrada usando o cliente no local

Para fornecer uma entrada local, recomendamos usar o Cloud Interconnect. Para prova de conceito ou caso você tenha baixa capacidade e nenhum requisito de latência, use o Cloud VPN.

Saída do VMware Engine

Há várias opções de saída do VMware Engine:

  • Saída por gateway de Internet do VMware Engine
  • Saída por VPC do cliente
  • Saída por data center no local

Na arquitetura a seguir, é possível ver essas opções para um fluxo de saída da perspectiva do VMware Engine.

Fluxo de saída da perspectiva do VMware Engine.

Saída pública usando o VMware Engine

É possível configurar o acesso à Internet e os serviços IP públicos para suas cargas de trabalho separadamente para cada região. Direcione o tráfego vinculado à Internet das cargas de trabalho de VMware usando a borda da Internet do Google Cloud ou uma conexão local.

O tráfego de uma máquina virtual hospedada em uma nuvem particular do VMware Engine destinado à saída de Internet pública por gateway de nível 0. O gateway de nível 0 encaminha o tráfego para o gateway da Internet. O gateway da Internet realiza a conversão de endereço de porta de origem (PAT, na sigla em inglês). O serviço de Internet é regional, o que significa que ele é ativado para cada região separadamente.

Saída pública usando sua rede VPC

Alternativamente, no portal de serviços do VMware Engine, é possível desativar serviços de Internet e IP públicos e fornecer saída pública da rede VPC do cliente. Nesse caso, o acesso à Internet será feito pela sua rede VPC se você tiver anunciado uma rota 0.0.0.0/0 padrão. Se você quiser usar esse fluxo de pacotes, desative o acesso à Internet para a região do VMware Engine e injete uma rota 0.0.0.0/0 padrão.

Você também precisa remover todos os endereços IP públicos alocados e os gateways de VPN de ponto a site antes de sair do tráfego pela rede VPC.

A rota padrão precisa estar visível na rede VPC do cliente e, depois, será propagada automaticamente para o VMware Engine. Um pré-requisito é ativar o VPC Service Controls na conexão de peering de VPC entre a VPC e o VMware Engine.

Para executar a conversão de endereços de rede (NAT), é possível implantar uma instância do Compute Engine ou ter uma rota padrão 0.0.0.0/0 que aponte para um balanceador de carga interno pareado a um cluster centralizado de dispositivos de rede virtual de terceiros (disponível no Cloud Marketplace) e execute NAT de origem na instância para sair da rede VPC para a Internet pública. Para mais informações, consulte Como usar rotas na sua rede VPC.

Saída pública usando um data center no local

É possível sair pelo data center local se você desativar os serviços de Internet e IP público e fornecer a saída pública do local. Ao fazer isso, o acesso à Internet flui pela rede VPC antes de chegar ao data center local pelo Cloud VPN ou Cloud Interconnect.

Para implementar a saída pública pelo seu data center local, anuncie uma rota 0.0.0.0/0 padrão e ative o VPC Service Controls na conexão de peering para que a rota padrão seja importada corretamente, conforme descrito aqui. Para mais informações sobre o VPC Service Controls, consulte a documentação oficial.

Se o VPC Service Controls estiver desativado na conexão de peering de VPC, o acesso à Internet por uma conexão local também será desativado, mesmo que uma rota padrão (0.0.0.0/0) seja anunciada e propagada pela conexão de peering de VPC.

Visão geral do serviço: nuvem particular para nuvem particular

As nuvens particulares são gerenciadas pelo portal do VMware Engine. As nuvens particulares têm o próprio servidor vCenter, que está no próprio domínio de gerenciamento. A pilha VMware é executada em nós de hardware bare metal dedicados e isolados nos locais do Google Cloud. O ambiente de nuvem particular foi projetado para eliminar pontos únicos de falha.

O diagrama a seguir mostra a arquitetura e o fluxo de tráfego quando duas nuvens particulares se comunicam.

Fluxo de tráfego quando duas nuvens particulares se comunicam.

A comunicação entre duas nuvens particulares na mesma região dentro do serviço do VMware Engine é por conectividade direta. É possível implantar várias nuvens particulares na mesma região. Dessa maneira, a comunicação entre essas nuvens particulares acontece localmente.

Se nuvens particulares estiverem em regiões diferentes, a conectividade passará pela rede VPC do produtor de serviço, que é gerenciada e de propriedade do Google.

Os clientes começam com uma nuvem particular e podem expandir ou aumentar os nós sob demanda, bem como reduzir e colocar os novos nós em um cluster atual do vSphere ou criá-los em um novo cluster (todos dentro da mesma nuvem particular).

Visão geral do serviço: nuvem particular para VPC

Nesta seção, analisamos a conectividade entre sua rede VPC e a nuvem particular. A rede VPC usa o modelo de acesso privado a serviços para fazer peering com a rede VPC do produtor de serviço. Em seguida, ela amplia a conectividade para a região do VMware Engine. O roteamento global é ativado na rede VPC do produtor de serviços. Todas as redes criadas no portal de serviços do VMware Engine são divulgadas automaticamente pelo roteador de nível 0 no NSX-T. Verifique se a conexão de peering tem a sinalização de importação e exportação ativada para trocar rotas e tem conectividade entre o VMware Engine e sua VPC.

O diagrama a seguir mostra o fluxo de tráfego nesse caso.

Nuvem particular para VPC: fluxo de tráfego.

Visão geral do serviço: nuvem particular para VPC compartilhada

Quando você usa uma rede VPC compartilhada, a conectividade é semelhante ao exemplo anterior de conexão de uma nuvem particular a uma rede VPC. A diferença é que, quando você conecta uma nuvem particular à rede VPC compartilhada, as cargas de trabalho ficam no projeto de serviço e usam o espaço de endereço IP na rede VPC compartilhada do projeto host. Por isso, você precisa configurar o acesso privado a serviços no projeto host em que a rede VPC compartilhada e a Interconexão ou VPN estão configuradas.

Por exemplo, se você quer ter a nuvem particular, o IAM e o faturamento em um projeto de serviço, certifique-se de que a conexão de acesso privado a serviços seja estabelecida na rede VPC compartilhada do projeto host.

Visão geral do serviço: nuvem particular para o local

No caso da nuvem particular para o local, o cliente tem uma rede VPC no projeto e na organização. A conectividade é entre a nuvem particular e o data center local.

Como mencionado anteriormente, quando o cliente está configurando o VMware Engine, é necessário alocar uma sub-rede (e também idealmente as sub-redes do serviço VMware Engine para evitar conflitos futuros) para a conexão de acesso privado a serviços. Ao alocar essa sub-rede, é criada uma rede VPC de produtor de serviço que conecta à região do VMware Engine em que está a nuvem particular.

Depois que a conexão de peering de VPC é criada e provisionada, a rede VPC do produtor de serviço é conectada à rede VPC do cliente. Isso permite que todas as sub-redes e endereços IP na rede VPC do cliente sejam acessados pela nuvem particular. Ative o recurso de importação e exportação de rotas na conexão de peering de VPC quando configurar o acesso privado a serviços.

O diagrama a seguir mostra a conectividade completa entre uma nuvem particular no VMware Engine e um data center local.

Conectividade completa entre uma nuvem particular no VMware Engine e um data center local.

Acesso privado do Google: mais detalhes

Como mencionado anteriormente, é possível usar o Acesso privado do Google para se conectar a serviços e APIs do Google sem fornecer endereços IP externos aos recursos do Google Cloud, para que o serviço do VMware Engine possa aproveitar isso e usar o gateway da Internet para alcançar as APIs Google.

As instâncias de VM que só têm endereços IP internos podem usar o Acesso privado do Google para acessar endereços IP externos das APIs e serviços Google. Quando o Acesso privado do Google é configurado, o tráfego é roteado para o gateway da Internet e para o serviço solicitado.

Para ativar o Acesso privado do Google para VMware Engine, configure o servidor DNS no seu ambiente do VMware Engine para usar o endereço IP virtual particular. Para mais informações, consulte Acesso privado do Google para hosts locais e Como configurar o Acesso privado do Google para hosts locais. O domínio private.googleapis.com usa 199.36.153.8/30.

Para gerenciar a resolução de DNS, use o serviço DNS fornecido no NSX-T para encaminhar solicitações a um servidor DNS especificado. O servidor DNS pode ser uma VM no VMware Engine, no Cloud DNS ou no servidor DNS local. Dependendo de como você acessa a Internet, uma dessas opções será usada conforme descrito em uma seção anterior.

O Acesso privado do Google é compatível com a maioria das APIs e serviços Google, como Cloud Storage, Cloud Spanner e BigQuery. No momento, o Acesso privado do Google não é compatível com o App Engine, o Memorystore, o Filestore ou o Cloud SQL.

Veja a seguir exemplos de como usar o VMware Engine com os serviços do Google Cloud:

  • acessar o Cloud Storage a partir de VMs do VMware para exportar dados ou como um destino de armazenamento estendido;
  • monitorar todos os seus aplicativos públicos, particulares e híbridos usando o Cloud Monitoring;
  • importar dados de bancos de dados para o BigQuery para análise;
  • implantar o Anthos para implantações de aplicativo privado em contêiner e de alto desempenho.

A configuração do Acesso privado do Google depende do acesso à Internet ativado para o VMware Engine e é representado no diagrama a seguir. Ele é fornecido pelo 1) gateway de Internet do serviço VMware Engine ou 2) gateway da Internet da rede VPC do produtor de serviço.

Configuração do Acesso privado do Google.

Se o acesso à Internet for pelo VMware Engine e ativado para a região, o Acesso privado do Google e o acesso à Internet usarão o gateway da Internet.

Se você fornecer acesso à Internet no local ou pela sua rede VPC, desative o serviço de IP público do VMware Engine e configure o VPC Service Controls na conexão de peering. Isso remove a rota padrão 0.0.0.0/0 com o gateway da Internet de próximo salto da rede VPC de locatário na organização do Google. Nesse caso, a rota padrão da rede local ou da rede VPC é aceita e uma rota é adicionada ao endereço IP virtual restrito 199.36.153.4/30 que aponta para o gateway da Internet na rede VPC do locatário.

Opção 1: Acesso privado do Google com acesso à Internet pelo VMware Engine

Caso você forneça acesso à Internet pelo VMware Engine para uma região, o Acesso privado do Google e a Internet usarão o gateway da Internet e realizarão o PAT. Nesse caso, você não precisa de outra configuração, exceto para a resolução de DNS para o Acesso privado do Google.

Opção 2: Acesso privado do Google com acesso à Internet pela VPC local ou do cliente

Se você fornecer acesso à Internet por rede local ou por sua rede VPC, será necessário configurar o serviço VMware Engine para rotear pacotes para as APIs Google pelo gateway da Internet na rede VPC de locatário da organização. Você precisa configurar o serviço VMware Engine para rotear pacotes para outro tráfego pela rede VPC do cliente para alcançar o local via VPN ou interconexão ou pela rede VPC do cliente. Para todo o tráfego, o acesso à Internet e os serviços de IP público precisam ser desativados para a região do VMware, e uma rota 0.0.0.0/0 padrão precisa ser injetada no local.

Se você fornecer acesso à Internet no local ou pela sua rede VPC, remova todos os endereços IP públicos alocados e gateways da VPN de ponto a site antes de desativar o serviço de IP público. Verifique se a rota está visível na rede VPC do cliente e se a rota foi exportada para a rede VPC de locatário.

Além disso, você precisa ativar o VPC Service Controls na conexão de peering de VPC entre sua VPC e o VMware Engine.

Por fim, o acesso às APIs Google precisará usar o endereço IP virtual restrito. Portanto, o DNS precisa ser configurado de acordo com os registros CNAME e A necessários, e o acesso às APIs Google será pela organização do Google, não pela rede VPC do cliente.

Nuvem particular para serviços gerenciados de parceiros

Os serviços gerenciados de parceiros (MPS, na sigla em inglês) permitem que você forneça ofertas de software como serviço (SaaS) crítico para clientes do Google Cloud via hardware e software hospedados em uma instalação de colocation dos MPS.

Para o fluxo de tráfego entre uma nuvem particular e MPS, o peering de VPC não é transitivo. Nesse caso, é preciso configurar uma VPN entre o NSX-T nível 0 no VMware Engine e o Cloud VPN na rede VPC. As rotas são trocadas usando o Border Gateway Protocol (BGP) e os mesmos serviços de acesso privado que usam o modelo de peering de VPC se aplicam aos MPS. Ao usar o Cloud VPN e o BGP, configure divulgações de rota personalizadas para que essas rotas sejam anunciadas para NSX-T nível 0 e haja conectividade completa. Um exemplo dessa abordagem é o NetApp Cloud Volumes Service para Google Cloud, que usa acesso privado a serviços para criar uma conexão de caminho de dados de alta capacidade e baixa latência. No entanto, a nuvem particular para provedores de serviços gerenciados não funciona com dados armazenados para cargas de trabalho de VMware.

No diagrama a seguir, mostramos a conectividade completa entre uma nuvem particular no VMware Engine e MPS.

Conectividade completa entre uma nuvem particular no VMware Engine e MPS.

Se você precisa usar um MPS e desativou o acesso à Internet pelo VMware Engine e sua rota padrão vier da VPC do produtor de serviço, configure endereços IP RFC 1918 da conexão VPN. A conexão VPN funciona entre o NSX-T e um dispositivo virtual na rede VPC do cliente, como um dispositivo de rede virtual de terceiros do Cloud Marketplace.

Outros recursos: VMware

Para mais informações sobre a pilha do VMware, consulte versões do componente VMware e o Guia de design NSX 3.0 oficial (links em inglês).