Rede de nuvem privada para VMware Engine
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 a você 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 de rede na nuvem 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. O suporte completo oferece uma experiência integrada e flexível em todo o 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.
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
- VMware Engine:
- (Opcional) Recursos locais:
- Rede
- Storage
- HCX (recomendado para conexões de Camada 2, também conhecido 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.
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 entidades terceirizadas que oferecem serviços também são conhecidos como fornecedores de serviços.
Para cada uma das suas redes VPC conectadas ao VMware Engine, há uma rede VPC do produtor de serviços que é criada quando você cria uma conexão de acesso a serviços particulares no Google Cloud. Seu projeto do Google Cloud contém uma rede VPC compartilhada que pode ser usada para se conectar a outros serviços do Google Cloud, como Memorystore e Cloud SQL. Por exemplo, é possível realizar a migração lift-and-shift de VMs locais do MySQL ou do PostgreSQL para o VMware Engine e migrá-las para o Cloud SQL usando o Serviço de migração de banco de dados incorporado do Google Cloud, sem deixar de acessar suas cargas de trabalho do VMware Engine para acessar esses bancos de dados.
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 da Camada 2 (L2) e a migração da carga de trabalho. No entanto, recomendamos o HCL para migração e carga de trabalho eficientes, porque esse recurso é implantado automaticamente quando você cria sua nuvem privada quando você seleciona essa opção.
Recursos de rede
Veja a seguir um resumo dos recursos de rede no VMware Engine:
- Conectividade multi-VPC: o VMware Engine permite conectar a mesma nuvem privada a várias redes VPC (até três no total, ou duas no caso de uso do serviço de Internet regional). Essas redes VPC podem ser redes VPC do consumidor ou Serviços gerenciados de parceiros (MPS, na sigla em inglês).
- 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).
- Recursos de roteamento regionais e globais: é possível controlar se as redes VPC compartilhadas do produtor de serviços que conectam suas nuvens privadas podem rotear somente em uma região ou globalmente.
- 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.
- 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.
- Recursos de DNS
- DNS para acesso ao dispositivo de gerenciamento: a resolução de endereço global dos dispositivos de gerenciamento do VMware Engine (como vCenter e NSX Manager) usando o Cloud DNS permite que você acesse os dispositivos sem intervenção do usuário.
- 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 para determinados servidores DNS, criar um servidor DNS no VMware Engine ou no local ou usar o Cloud DNS ou o Compute Engine.
- 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 de Camada 2 site a site e de Camada 3: esses serviços são configurados diretamente no NSX usando a VPN de Camada 2 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 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. Endereços IP públicos de uso privado (PUPI) também são suportados.
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:
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 privada. | /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 conexão de serviço particular nos 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 a partir da 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 particular para suas cargas de trabalho em execução no VMware Engine ou nas suas redes VPC. 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 fornecedores 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 por meio do acesso a serviços privados.
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 endereço 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 de serviços particular, 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 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 privada (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 rede 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 rede VPC. As rotas exportadas exibem nuvens privadas 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:
- Conectividade do usuário remoto:
- Conectividade local:
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.
As opções de conectividade da VPN são a VPN de NSX-T IPsec, a VPN de NSX-T Camada 2 e a VPN de HCX Camada 2, por exemplo, para configurar uma extensão da Camada 2. Um caso de uso para a VPN NSX-T IPsec é a criptografia de ponta a ponta com a terminação de VPN diretamente na nuvem privada do VMware Engine. Para mais informações sobre os recursos da VPN NSX-T, consulte a documentação da rede privada virtual do 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 roteadores 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 da rede VPC
- 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.
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 a rede VPC
É possível fornecer entrada para o VMware Engine através da rede VPC 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 scripting em vários locais.
Entrada usando a rede 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 pela rede VPC
- 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.
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 sua
rede VPC. 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 sua rede VPC 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 sua rede 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 do VPC Service Controls.
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 privada foi projetado para eliminar pontos únicos de falha.
O diagrama a seguir mostra dois caminhos de rede para comunicação entre nuvens privadas no VMware Engine. O caminho depende se as nuvens privadas estão na mesma região ou em regiões diferentes:
- 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 privadas acontece localmente.
- Se nuvens privadas estiverem em regiões diferentes, a conectividade passará pela rede VPC do produtor de serviço, que é gerenciada e de propriedade do Google. Nesse caso, o modo de roteamento está definido como global.
Visão geral do serviço: nuvem particular para VPC
Nesta seção, analisamos a conectividade entre sua rede VPC e a nuvem privada. 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.
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 privada a uma rede VPC. A diferença é que, quando você conecta uma nuvem privada à 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 privada no local, você tem uma rede VPC no projeto e na organização, e a conectividade está entre a nuvem privada e o data center local.
Como mencionado anteriormente, quando você configura o VMware Engine, é necessário alocar uma sub-rede e, de preferência, também as sub-redes do VMware Engine para evitar conflitos futuros para a conexão de acesso particular 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 privada.
Depois que a conexão de peering de VPC é criada e provisionada, a rede VPC do produtor de serviços é conectada à sua rede VPC. Isso permite que todas as sub-redes e endereços IP na sua rede VPC sejam acessados pela nuvem privada. 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.
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 um servidor DNS no 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 suporta a maioria das APIs e serviços Google, como Cloud Storage, Cloud Spanner e BigQuery. O Acesso privado do Google não suporta o App Engine, Memorystore ou Filestore. Para mais informações sobre as opções de acesso privado, consulte Opções de acesso privado para serviços.
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.
O diagrama a seguir mostra dois caminhos de rede para comunicação com APIs e serviços do Google. A configuração do Acesso privado do Google depende do acesso à Internet ativado para o VMware Engine:
- Se o acesso à Internet for pelo VMware Engine e ativado para a região, o Acesso privado do Google e o acesso à Internet usam o gateway da Internet.
- Se você fornecer acesso à Internet (anunciando uma rota
0.0.0.0/0) no local ou através da rede VPC, a comunicação usará o gateway da Internet da rede VPC do produtor de serviços. O acesso através do serviço de Internet do VMware Engine é ignorado.
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 para alcançar no local por meio da VPN, do Interconnect ou por meio da rede VPC.
Para todo o tráfego, desative o acesso à Internet e os serviços de IP públicos para a
região do VMware Engine e injete uma rota 0.0.0.0/0 padrão
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 sua rede VPC e se a rota foi exportada para a rede VPC do locatário.
Além disso, você precisa ativar o VPC Service Controls na conexão de peering de VPC entre sua rede VPC e o VMware Engine.
Por fim, o acesso às APIs do Google usa o endereço IP virtual restrito. Portanto, o DNS precisa ser configurado de acordo com os registros CNAME e A necessários. O acesso às APIs do Google é feito por meio da Organização do Google, e não pela sua rede VPC.
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 privada e MPS, o VMware Engine usa a conectividade multi-VPC. Esse recurso permite estabelecer conectividade não apenas com outras redes VPC do consumidor, mas também com os MPS do Google. O diagrama a seguir é uma versão simplificada da conectividade entre uma nuvem privada e os MPS, assim como outras redes VPC do consumidor.
Outros recursos: VMware
Para mais informações sobre a pilha do VMware, consulte Versões dos componentes do VMware e o Guia de design do NSX 3.0 (ambos em inglês).