Sobre Hybrid Subnets

As Hybrid Subnets permitem combinar uma sub-rede local com uma sub-rede de nuvem privada virtual (VPC) para criar uma única sub-rede lógica. É possível migrar cargas de trabalho individuais e instâncias de máquina virtual (VM) da sub-rede local para a sub-rede VPC ao longo do tempo, sem precisar alterar endereços IP. Depois que todas as cargas de trabalho e VMs forem migradas, desative a sub-rede local.

Em uma sub-rede híbrida, os roteadores locais e os Cloud Routers divulgam rotas usando o protocolo de gateway de borda (BGP). Clique para ampliar.

Hybrid Subnets e Migrate to Virtual Machines

Recomendamos usar Migrate to Virtual Machines com Hybrid Subnets para automatizar o processo de migração de VMs de uma origem do VMware. O Google oferece suporte ao Migrate to Virtual Machines.

Para mais informações sobre as opções de migração, consulte Recursos de migração.

Como alternativa, use ferramentas de migração de terceiros com Hybrid Subnets, desde que os requisitos das Hybrid Subnets descritos neste documento sejam atendidos.

Para receber suporte sobre o planejamento de uma migração para o Google Cloud usando Hybrid Subnets, registre um caso de suporte.

Para informações sobre como planejar uma migração com o Migrate to VMs, consulte Jornada de migração com o Migrate to VMs.

Especificações

  • As Hybrid Subnets exigem um produto de conectividade de rede, como o Cloud VPN ou o Cloud Interconnect.
  • Um roteador local usa o ARP do Proxy para rotear o tráfego de máquinas locais para VMs do Google Cloud usando rotas aprendidas com divulgações de rotas personalizadas do Cloud Router.
  • O intervalo de endereços IPv4 principal da sub-rede do Google Cloud precisa corresponder ao intervalo de endereços IP da sub-rede local.
  • Ative o flag allow-cidr-routes-overlap de uma sub-rede VPC para configurá-la como uma sub-rede híbrida. Quando allow-cidr-routes-overlap está ativado, o Google Cloud permite que rotas personalizadas se sobreponham a intervalos de endereços IP de sub-rede.
  • O flag allow-cidr-routes-overlap se aplica aos intervalos de sub-rede IPv4 principais e secundários e aos intervalos de sub-rede IPv6.
  • A conectividade interna é mantida entre todas as VMs e cargas de trabalho em uma sub-rede híbrida.
  • Você usa o Cloud Router rotas divulgadas personalizadas para anunciar seletivamente os endereços IP das VMs ao migrá-las para a sub-rede VPC.
  • Ao migrar cargas de trabalho de uma rede local para o Google Cloud, você atualiza as divulgações de rota personalizada do Cloud Router para incluir os endereços IP das VMs migradas.
  • É possível conectar uma sub-rede híbrida a uma rede VPC com peering usando o peering de rede VPC. A configuração de peering da rede VPC que contém a sub-rede híbrida precisa ser definida para exportar rotas personalizadas. A configuração de peering da outra rede VPC precisa ser definida para importar rotas personalizadas.

Limitações

  • O número máximo de VMs em uma rede VPC que usa Hybrid Subnets é 130. Exceder esse limite pode causar problemas de conectividade e estabilidade.
  • O Cloud Router de uma sub-rede híbrida não pode exceder o número máximo de divulgações de rotas personalizadas por sessão do BGP.
  • O tráfego de transmissão e multicast dentro de uma sub-rede híbrida não é compatível.
  • Não é possível usar conexões de Interconexão por parceiro da camada 3 que não oferecem suporte ao anúncio de rotas /32 com Hybrid Subnets.
  • As Hybrid Subnets não oferecem suporte a IPv6.
  • As Hybrid Subnets não oferecem suporte ao Google Cloud VMware Engine. Recomendamos migrar VMs do VMware usando o VMware HCX.
  • Se uma carga de trabalho local tiver o mesmo endereço IP que o Cloud Router, as cargas de trabalho na parte VPC de uma sub-rede híbrida não poderão enviar pacotes para esse endereço IP. Por exemplo, se o intervalo de endereços IP da sub-rede híbrida for 192.168.1.0/24, as cargas de trabalho na sub-rede VPC não poderão acessar 192.168.1.1.
  • As Hybrid Subnets não podem hospedar cargas de trabalho nos endereços IP reservados em sub-redes IPv4.
  • O encaminhamento de entrada do Cloud DNS não responde a solicitações de DNS de cargas de trabalho na parte local de uma sub-rede híbrida.
  • As cargas de trabalho na parte local de uma sub-rede híbrida não conseguem acessar APIs e serviços do Google usando o Acesso privado do Google.
  • As cargas de trabalho na parte local de uma sub-rede híbrida não conseguem acessar endpoints do Private Service Connect para APIs do Google.
  • As Hybrid Subnets não são compatíveis com a transferência de dados site a site.
  • As Hybrid Subnets não são compatíveis com a migração de cargas de trabalho de outros provedores de serviços em nuvem ou a migração de cargas de trabalho no Google Cloud porque esses ambientes não são compatíveis com o ARP do proxy.
  • As Hybrid Subnets não podem se conectar a redes em peering usando o Network Connectivity Center.

Considerações para o uso de Hybrid Subnets

As seções a seguir descrevem considerações para o uso de Hybrid Subnets.

Desempenho da rede

As Hybrid Subnets usam a camada 3 do modelo OSI para rotear pacotes entre as partes local e VPC de uma sub-rede híbrida. Essa abordagem ajuda as Hybrid Subnets a evitar desafios de latência, instabilidade e capacidade de processamento que podem acontecer durante migrações quando existem algumas cargas de trabalho em uma rede local, mas outras cargas de trabalho migraram para a nuvem.

Mais especificamente, evitar o encapsulamento da camada 2 ajuda a evitar a degradação do desempenho associada ao encapsulamento e à criptografia de uma sobreposição extra da camada 2. Além disso, o roteamento da camada 3 permite que as Hybrid Subnets evitem um problema comum com o encapsulamento da camada 2, em que o tráfego é enviado para um nó central antes de chegar a destinos que podem estar próximos do ponto de origem do tráfego. Esse problema, às vezes, é chamado de tromboning de rede.

A abordagem das Hybrid Subnets para o roteamento indica que você pode esperar o desempenho de uma sub-rede híbrida semelhante ou igual a uma rede que não usa Hybrid Subnets.

ARP do proxy e Hybrid Subnets

O ARP do proxy é necessário para Hybrid Subnets. Recomendamos o seguinte para usar o ARP do proxy na parte local de uma sub-rede híbrida:

  • Consulte o fornecedor da malha de rede local para conhecer as práticas recomendadas relacionadas à ativação do ARP do proxy e à proteção do ambiente de rede.
  • Desative o ARP do proxy depois de concluir a migração para o Google Cloud.

Firewalls e Hybrid Subnets

As Hybrid Subnets evitam desafios relacionados ao uso de firewalls com tráfego encapsulado em sobreposições da camada 2. Para o tráfego da camada 2, os firewalls só podem inspecionar pacotes em ou além dos endpoints de sobreposição, a menos que você tome medidas específicas, como descriptografia transparente ou inspeções profundas do tráfego de sobreposição.

Não são necessárias considerações especiais para usar firewalls e regras de firewall atuais com Hybrid Subnets. No entanto, pode ser necessário Configurar regras de firewall para garantir que as VMs do Google Cloud possam se comunicar com cargas de trabalho locais.

Preços

Não há cobrança adicional pelo uso de Hybrid Subnets. No entanto, você é cobrado por recursos e tráfego de rede na parte do Google Cloud de uma sub-rede híbrida.

Para mais informações, consulte Preços da nuvem privada virtual.

A seguir