Sobre a migração para Google Cloud com Hybrid Subnets

O Hybrid Subnets ajuda a migrar cargas de trabalho de outra rede (a rede de origem) para uma sub-rede de nuvem privada virtual (VPC) sem precisar mudar os endereços IP. Ao combinar uma sub-rede na rede de origem com uma sub-rede VPC, você cria uma única sub-rede lógica que permite migrar cargas de trabalho individuais e instâncias de máquina virtual (VM) ao longo do tempo. Depois que todas as cargas de trabalho e VMs forem migradas, desative a sub-rede de origem.

As Hybrid Subnets também oferecem suporte à migração de VMs do Google Cloud para uma rede local ou entre duas redes VPC.

Um diagrama de três estágios ilustra a migração de cargas de trabalho de locais para Google Cloud usando Hybrid Subnets.
Figura 1. Durante a migração, uma sub-rede híbrida fornece conectividade entre cargas de trabalho em uma rede de origem e uma rede VPC (clique para ampliar).

Especificações

Hybrid Subnets tem as seguintes especificações.

  • Propriedades:
    • Uma sub-rede híbrida é uma única sub-rede lógica que combina um segmento de uma rede de origem com uma sub-rede em uma rede VPC.
    • A conectividade interna é mantida entre todas as VMs e cargas de trabalho em uma sub-rede híbrida.
    • A rede de origem pode ser uma rede local ou outra rede VPC. O segmento pode ser uma sub-rede inteira ou parte dela.
    • As duas partes de uma sub-rede híbrida precisam estar conectadas por um produto de conectividade de rede, como o Cloud VPN ou o Cloud Interconnect.
    • O intervalo de endereços IPv4 principal da sub-rede VPC precisa corresponder ao intervalo do segmento da rede de origem usado pela sub-rede híbrida.
  • Configuração da rede VPC:
    • É necessário ativar o roteamento de sub-rede híbrida para configurar uma sub-rede VPC como parte de uma sub-rede híbrida. Quando o roteamento de sub-rede híbrida está ativado, as rotas personalizadas podem entrar em conflito (sobreposição) com os intervalos de endereços IPv4 principais e secundários das sub-redes.
    • Você usa as rotas divulgadas personalizadas do Cloud Router para anunciar seletivamente os endereços IP das VMs ao migrá-las para a sub-rede VPC. Para oferecer suporte ao proxy ARP e à correspondência de prefixo mais longo, essas rotas precisam ser mais específicas (ter uma máscara de sub-rede mais longa) do que o intervalo de endereços IP da sub-rede híbrida. É possível usar rotas /32 para VMs individuais.
  • Configuração de rede de origem:
    • Você precisa configurar o ARP do proxy na rede de origem.
    • Configure a rede de origem para anunciar o intervalo de endereços IP da sub-rede híbrida.
Um Cloud Router e um roteador local processam o roteamento entre as duas partes de uma sub-rede híbrida que usa um intervalo de endereços IP compartilhado e sobreposto.
Figura 2. Este diagrama oferece uma visão geral das etapas para criar uma sub-rede híbrida e como um Cloud Router e um roteador local encaminham pacotes entre as duas partes de uma sub-rede híbrida (clique para ampliar).

Roteamento de sub-rede híbrida

Uma sub-rede híbrida combina uma sub-rede em uma rede de origem com uma sub-rede VPC para criar uma única sub-rede lógica. As cargas de trabalho nas duas partes da sub-rede híbrida mantêm a conectividade interna. Uma carga de trabalho pode enviar tráfego para um destino em qualquer parte da sub-rede híbrida como se fosse local, independente da localização do destino.

Roteamento de rede VPC

Durante a etapa de correspondência de rotas de sub-rede do modelo de roteamento da VPC, se o destino de um pacote corresponder a uma rota de sub-rede local ou de peering,o Google Cloud tentará entregar o pacote usando a rota de sub-rede correspondente. Em uma sub-rede regular, se o destino não estiver associado a uma VM em execução ou a uma regra de encaminhamento interno, o pacote será descartado, e todas as outras rotas serão ignoradas.

No entanto, se o roteamento de sub-rede híbrida estiver ativado para a sub-rede, a rota de sub-rede se tornará uma rota de sub-rede híbrida, e o comportamento de roteamento será diferente:

  • Se o pacote estiver associado a uma instância de VM em execução ou a uma regra de encaminhamento interno na sub-rede VPC,o Google Cloudvai entregar o pacote com base na rota de sub-rede híbrida local.
  • Se o pacote não estiver associado a uma VM em execução ou a uma regra de encaminhamento interno na sub-rede VPC,o Google Cloud vai usar um processo de roteamento especial para recursos não correspondentes. Esse processo inclui a verificação de rotas dinâmicas e estáticas personalizadas que se sobrepõem ao intervalo da sub-rede híbrida. Em uma sub-rede híbrida configurada corretamente, os pacotes são roteados para a rede de origem usando uma rota dinâmica local que o Cloud Router aprende para a sub-rede de origem.
Em uma sub-rede híbrida, o pacote A é roteado localmente, e o pacote B é roteado para um destino local.
Figura 3. As VMs em uma sub-rede híbrida podem alcançar destinos em uma sub-rede local e em uma sub-rede de rede VPC, mesmo que ambas compartilhem o mesmo intervalo de endereços IP sobrepostos (clique para ampliar).

Por exemplo, na Figura 3, o pacote A é roteado para uma VM na parte VPC de uma sub-rede híbrida usando uma rota de sub-rede híbrida local. O destino do pacote B não está associado a uma VM em execução ou a uma regra de encaminhamento interno na parte da VPC da sub-rede híbrida. Portanto, o Google Cloud verifica se há rotas personalizadas conflitantes. Uma correspondência é encontrada, e Google Cloud usa a rota dinâmica personalizada sobreposta para entregar o pacote B à rede de origem.

Roteamento de rede de origem

Quando uma carga de trabalho na rede de origem envia um pacote para um destino no intervalo de endereços IP da sub-rede híbrida, o roteador ou o dispositivo de primeiro salto da rede de origem realiza uma pesquisa na tabela de rotas.

Se o destino estiver associado a uma carga de trabalho na rede de origem, o roteador não vai intervir com o proxy ARP. O destino recebe a solicitação ARP e responde com o próprio endereço MAC. O pacote é entregue localmente.

Se o destino estiver na parte VPC da sub-rede híbrida e o roteador tiver aprendido uma rota dinâmica para o destino mais específica do que a rota da sub-rede local, o roteador vai selecionar a rota dinâmica usando a correspondência de prefixo mais longo. Isso aciona a funcionalidade de ARP proxy do roteador. O roteador responde com o próprio endereço MAC e encaminha o pacote para o Cloud Router na rede VPC.

Um roteador local usa o ARP do proxy para rotear um pacote de uma carga de trabalho em uma rede de origem para uma VM migrada para Google Cloud.
Figura 4. Um roteador local usa o ARP do proxy para rotear um pacote de uma carga de trabalho em uma rede de origem para uma VM migrada para o Google Cloud(clique para ampliar).

Limitações

Hybrid Subnets tem as seguintes limitações:

  • Limitações de recursos:

    Essas limitações de recursos não são aplicadas por limites ou cotas do Google Cloud . Exceder esses limites pode causar problemas de conectividade e estabilidade.

  • Trânsito e rotas não compatíveis:

    • Os pacotes são descartados se o próximo salto de uma rota conflitante estiver em uma região diferente da sub-rede híbrida.
    • Os seguintes tipos de rotas não são aceitos como rotas conflitantes:
      • Rotas padrão geradas pelo sistema
      • Rotas com base em políticas
      • Rotas estáticas com tags de rede
      • Rotas com destinos que contêm ou são mais amplos do que a rota de sub-rede híbrida
    • O Network Connectivity Center não é totalmente compatível com Hybrid Subnets. É possível configurar uma rede VPC que contenha uma sub-rede híbrida para ser um spoke de um hub do Network Connectivity Center. No entanto, o tráfego dos raios conectados para o intervalo de endereços IP da sub-rede híbrida tem um comportamento de roteamento imprevisível.
    • O Hybrid NAT é indisponível com Hybrid Subnets. Embora seja possível configurar uma sub-rede híbrida para usar o NAT híbrido, o recurso não é aplicado ao tráfego afetado pelo roteamento de sub-rede híbrida.
    • O roteamento de sub-rede híbrida não se aplica ao tráfego IPv6.
    • 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.
    • 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.
    • As cargas de trabalho na rede de origem não conseguem acessar APIs e serviços do Google usando o Acesso privado do Google.
    • As cargas de trabalho na rede de origem não conseguem acessar endpoints do Private Service Connect para APIs do Google.

  • Cenários de migração não compatíveis:

    • 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.
    • As Hybrid Subnets não são compatíveis com a migração de VMs de uma origem do Azure ou da AWS.
    • As Hybrid Subnets não são compatíveis com a transferência de dados site a site.
    • As Hybrid Subnets não oferecem suporte ao Google Cloud VMware Engine como destino da migração. Se o VMware Engine for seu destino de migração, recomendamos migrar VMs do VMware usando o VMware HCX.

  • Outras limitações:

    • As Hybrid Subnets não detectam conflitos de endereços IP entre a rede de origem e as partes da VPC de uma sub-rede híbrida. Verifique se cada endereço IP (exceto o gateway padrão) é usado apenas uma vez.
    • As Hybrid Subnets não podem hospedar cargas de trabalho nos endereços IP reservados em sub-redes IPv4.
    • As cargas de trabalho na rede de origem não podem ser endpoints para grupos de endpoints de rede de conectividade híbrida que usam verificações de integridade centralizadas.
    • O encaminhamento de entrada do Cloud DNS não responde a solicitações de DNS de cargas de trabalho na rede de origem.

Opções de migração

O Google recomenda usar o Migrate to Virtual Machines com Hybrid Subnets para automatizar o processo de migração de VMs de uma origem do VMware ou de uma origem do Google Cloud VMware Engine.

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 informações sobre como planejar uma migração com o Migrate to Virtual Machines, consulte Jornada de migração com o Migrate to VMs.

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

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

Considerações para o uso de Hybrid Subnets

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

ARP do proxy e Hybrid Subnets

As Hybrid Subnets exigem que o ARP do proxy seja configurado no roteador da rede de origem ou no dispositivo de primeiro salto (o ponto em que um host envia tráfego pela primeira vez com um destino fora da rede local).

O dispositivo de primeiro salto pode ser um roteador, um dispositivo virtual, um firewall ou uma VM executando uma solução de software como choparp.

Recomendamos o seguinte para usar o ARP do proxy na sua rede de origem:

  • Consulte o fornecedor da malha de rede de origem 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.

Limitação de regionalidade

Para que uma sub-rede híbrida funcione corretamente, as rotas conflitantes (rotas personalizadas que se sobrepõem ao intervalo de endereços da sub-rede híbrida) precisam ter todos os próximos saltos na mesma região da sub-rede híbrida.

Se uma rota conflitante tiver próximos saltos em uma região diferente:

  • Se a rota tiver uma combinação de próximos saltos locais e remotos, o tráfego será descartado sempre que o ECMP selecionar um próximo salto em uma região remota. Essa perda de pacote acontece mesmo que o pacote também corresponda a uma rota menos específica que tenha próximos saltos na mesma região.
  • Se a rota não tiver próximos saltos na mesma região que a sub-rede híbrida, o pacote será descartado.

Verifique se os seguintes recursos estão na mesma região:

  • A sub-rede VPC configurada como uma sub-rede híbrida
  • O Cloud Router que aprende rotas para sua rede de origem
  • Os túneis de VPN de alta disponibilidade ou anexos da VLAN que fornecem conectividade híbrida

Por exemplo, suponha que haja uma sub-rede híbrida com o intervalo de endereços IP 192.0.2.0/24. A sub-rede VPC está na região us-central1. O Cloud Router aprendeu duas rotas conflitantes:

  • Uma rota personalizada com intervalo de destino 192.0.2.0/25 e um próximo salto na região us-central1
  • Uma rota personalizada com intervalo de destino 192.0.2.0/30 e um próximo salto na região us-west1.

Um pacote é enviado para o destino 192.0.2.2. Esse endereço IP não está associado a uma VM em execução ou a uma regra de encaminhamento interna na sub-rede da VPC. Portanto, o modelo de seleção de rota escolhe a rota personalizada com o destino mais específico, que é 192.0.2.0/30. Essa rota não tem um próximo salto na região da sub-rede híbrida, então o pacote é descartado.

Para mais informações, consulte recursos não correspondentes em sub-redes híbridas.

Peering de rede VPC

É possível conectar uma sub-rede híbrida a uma rede VPC com peering usando o peering de rede VPC. A rede VPC da sub-rede híbrida precisa ser configurada para exportar rotas de sub-rede e personalizadas, e a rede VPC com peering precisa ser configurada para importá-las.

Quando a rede VPC em peering programa as rotas, ela pode acessar destinos dentro do intervalo de endereços IP da sub-rede híbrida, independentemente de existirem em Google Cloud ou na rede de origem.

As rotas não serão programadas para a rede com peering nos seguintes casos:

  • Uma rota de sub-rede local na rede com peering tem um intervalo de destino idêntico ao da rota importada.
  • A cota de rotas dinâmicas por região por grupo de peering foi excedida.
  • As duas redes VPC não têm peering direto. O peering de rede VPC não é transitivo.

Se alguma dessas condições for verdadeira, a sub-rede híbrida não vai funcionar corretamente na perspectiva da rede VPC com peering.

Desempenho da rede

As Hybrid Subnets usam a camada 3 do modelo OSI para rotear pacotes entre a rede de origem e as partes da 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 algumas cargas de trabalho existem em uma rede de origem, mas outras 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.

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, talvez seja necessário configurar regras de firewall para garantir que as VMs do Google Cloud possam se comunicar com cargas de trabalho na rede de origem.

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 da VPC de uma sub-rede híbrida.

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

A seguir