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

Nesta página, descrevemos como usar o roteamento de sub-rede híbrida para ajudar a migrar cargas de trabalho para Google Cloud.

O roteamento de sub-rede híbrida permite que uma rede VPC compartilhe um bloco CIDR com uma rede local conectada. Se um pacote corresponder a uma rota de sub-rede híbrida, mas o endereço IP de destino não estiver associado a um recurso nessa sub-rede, Google Cloud poderá rotear o pacote para a rede local usando rotas dinâmicas ou estáticas.

Essa configuração ajuda a migrar cargas de trabalho para Google Cloud de forma incremental sem precisar mudar os endereços IP delas. Durante a migração, as cargas de trabalho que foram migradas para a rede VPC podem se comunicar com aquelas que permanecem na rede local usando endereços IP internos. Depois que todas as cargas de trabalho forem migradas, você poderá desativar o roteamento de sub-rede híbrida para restaurar o comportamento normal de roteamento.

A migração para Google Cloud o com Hybrid Subnets exige três componentes distintos que funcionam juntos:

  • Conectividade: as redes locais e VPC precisam estar conectadas por um produto de conectividade de rede como o Cloud VPN ou Cloud Interconnect. As Hybrid Subnets não fornecem essa conectividade por conta própria.
  • Roteamento de sub-rede híbrida: é necessário ativar o roteamento de sub-rede híbrida aplicando a flag allow-cidr-routes-overlap a um recurso de sub-rede.
  • Ferramenta de migração: você precisa de uma ferramenta de migração, como o Migrate to Virtual Machines, para migrar cargas de trabalho para Google Cloud.
Um diagrama de três estágios ilustra a migração de cargas de trabalho do local para Google Cloud usando Hybrid Subnets.
Figura 1. Durante a migração, o roteamento de sub-rede híbrida permite que cargas de trabalho em uma rede local se comuniquem com cargas de trabalho em uma rede VPC conectada usando endereços IP internos, mesmo que as sub-redes em ambas as redes usem o mesmo bloco CIDR (clique para ampliar).

Especificações

Para configurar as Hybrid Subnets para oferecer suporte à migração de cargas de trabalho para Google Cloud de uma rede local, seu ambiente precisa atender aos seguintes requisitos.

  • Requisitos de conectividade:
    • As redes locais e VPC precisam estar conectadas por um produto de conectividade de rede como o Cloud VPN ou Cloud Interconnect.
    • Os túneis de VPN de alta disponibilidade ou anexos da VLAN, os Cloud Routers e as sub-redes com o roteamento de sub-rede híbrida ativado precisam estar na mesma região.
  • Configuração da rede VPC:
    • Um intervalo de endereços IPv4 da sub-rede com o roteamento de sub-rede híbrida ativado precisa corresponder a um bloco CIDR na rede local que hospeda as cargas de trabalho que você quer migrar. Na maioria dos casos de uso, o intervalo de endereços IPv4 principal da sub-rede corresponde a um bloco CIDR na rede local.
    • É necessário ativar o roteamento de sub-rede híbrida. Quando o roteamento de sub-rede híbrida está ativado, as regras de interações entre rotas de sub-rede e rotas estáticas e as regras de interações entre rotas de sub-rede e rotas dinâmicas não são aplicadas. Rotas estáticas ou dinâmicas locais e de peering podem existir mesmo que os destinos correspondam ou se encaixem no intervalo de endereços IPv4 principal da sub-rede ou em qualquer um dos intervalos de endereços IPv4 secundários.
    • É necessário configurar rotas divulgadas personalizadas do Cloud Router para anunciar seletivamente os endereços IP das VMs ao migrá-las para a rede VPC. Para oferecer suporte ao ARP do proxy e à correspondência de prefixo mais longo, essas rotas divulgadas personalizadas precisam ser mais específicas (ter uma máscara de sub-rede mais longa) do que o intervalo de endereços IPv4 da sub-rede que tem o roteamento de sub-rede ativado. É possível usar uma rota divulgada personalizada /32 para cada endereço IP de uma VM migrada.
  • Configuração da rede local:
    • É necessário configurar o ARP do proxy para o roteador local.
    • É necessário configurar o roteador local para anunciar o intervalo de endereços IP do bloco CIDR compartilhado.
Um Cloud Router e um roteador local processam o roteamento em um bloco CIDR compartilhado entre redes locais e VPC.
Figura 2. Este diagrama resume como configurar uma rede VPC e uma rede local para manter a conectividade interna em um bloco CIDR compartilhado (clique para ampliar).

Roteamento de sub-rede híbrida

Quando você concluir a configuração descrita nas especificações das Hybrid Subnets, as VMs em ambas as redes poderão se comunicar usando endereços IP internos.

As seções a seguir descrevem o comportamento de roteamento na rede VPC que contém uma sub-rede com o roteamento de sub-rede híbrida ativado e em uma rede local depois que essa configuração estiver em vigor.

Roteamento na 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 tentará entregar o pacote usando a rota de sub-rede correspondente. Google Cloud Em uma sub-rede normal, 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:

  • Recursos correspondentes: se o destino do pacote corresponder à interface de rede de uma instância de VM em execução ou a uma regra de encaminhamento interno na sub-rede, Google Cloud o entregará o pacote à interface ou à regra de encaminhamento. Esse comportamento é o mesmo de uma sub-rede normal.
  • Recursos não correspondentes: se o destino do pacote não corresponder a um recurso na sub-rede, Google Cloud seguirá o processo de recursos não correspondentes em sub-redes híbridas. Esse processo roteia pacotes para próximos saltos de rotas estáticas ou dinâmicas locais ou de peering, desde que tenham próximos saltos na mesma região que a sub-rede híbrida. As rotas estáticas ou dinâmicas locais ou de peering fornecem um caminho para entregar o pacote à rede local.
Em uma sub-rede com roteamento de sub-rede híbrida ativado, o pacote A é roteado localmente, e o pacote B é roteado para um destino local.
Figura 3. Em uma sub-rede que usa o roteamento de sub-rede híbrida, se o destino de um pacote corresponder a um recurso na sub-rede, Google Cloud o roteará o tráfego para esse recurso. Para recursos não correspondentes, Google Cloud o usará o processo de recursos não correspondentes em sub-redes híbridas (clique para ampliar).

Por exemplo, na Figura 3, o pacote A é roteado para uma VM na sub-rede local 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 sub-rede que usa o roteamento de sub-rede híbrida. Portanto, Google Cloud verifica se há rotas dinâmicas ou estáticas que se encaixam no intervalo de destino da rota de sub-rede híbrida. Uma correspondência é encontrada, e Google Cloud usa a rota dinâmica para entregar o pacote B à rede local.

Roteamento na rede local

Esta seção descreve o comportamento de roteamento em uma rede local. Neste exemplo, a rede local está conectada a uma rede VPC usando túneis do Cloud VPN.

Quando uma VM do cliente na rede local envia um pacote para uma VM do servidor que está no bloco CIDR compartilhado pelas duas redes, o roteador ou o dispositivo de primeiro salto da rede local realiza uma pesquisa na tabela de roteamento:

  • Se a VM do servidor estiver associada a um endereço IP na rede local, o roteador local não vai intervir com o ARP do proxy. A VM do servidor responde aos pacotes who-has do ARP da VM do cliente com respostas que contêm o endereço MAC do servidor. A VM do cliente envia um frame Ethernet para a VM do servidor.

  • Se a VM do servidor não estiver associada a um endereço IP na rede local e o roteador local tiver recebido um anúncio de rota personalizada específico das sessões do BGP do Cloud Router dos túneis do Cloud VPN na rede VPC, o roteador local vai intervir com o ARP do proxy. O roteador local responde aos pacotes who-has do ARP da VM do cliente com respostas que contêm o endereço MAC do roteador. A VM do cliente envia um frame Ethernet para o roteador local, e o roteador local extrai o pacote IP e o encaminha para um dos túneis do Cloud VPN. Isso entrega o pacote à VM na sub-rede que tem o roteamento de sub-rede híbrida ativado.

Um roteador local usa o ARP do Proxy para rotear um pacote de uma carga de trabalho em uma rede local 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 na rede local para uma VM que foi migrada para Google Cloud (clique para ampliar).

Limitações

As Hybrid Subnets têm as seguintes limitações.

  • Gerenciamento de endereços IP e tráfego com suporte:

    • IPv6: as Hybrid Subnets não oferecem suporte ao tráfego IPv6.

    • Transmissão e multicast: as Hybrid Subnets não oferecem suporte ao tráfego de transmissão e multicast.

    • Conflitos de endereços IP: as Hybrid Subnets não detectam conflitos de endereços IP entre recursos na rede local e na rede VPC que contém a sub-rede que tem o roteamento de sub-rede híbrida ativado. Verifique se cada endereço IP, exceto o gateway padrão, é usado apenas uma vez.

    • Endereços inutilizáveis: os dois primeiros e os dois últimos endereços IPv4 no intervalo de endereços IPv4 principal de uma sub-rede não podem ser usados por nenhum Google Cloud recurso. Essa regra permanece em vigor mesmo que você ative o roteamento de sub-rede híbrida. Para mais informações, consulte Endereços inutilizáveis em intervalos de sub-rede IPv4 ranges.

  • Regiões incompatíveis: os pacotes são descartados se o próximo salto de uma rota estática ou dinâmica correspondente no intervalo de destino da rota de sub-rede híbrida correspondente estiver em uma região diferente da região da sub-rede. Para mais informações, consulte Limitação de regionalidade.

  • Rotas estáticas com tags de rede: verifique se qualquer rota estática correspondente no intervalo de destino da rota de sub-rede híbrida correspondente não usa tags de rede. As rotas estáticas correspondentes que usam tags de rede resultam em perda de pacotes quando há taxas de pacotes altas.

  • Interações de produtos sem suporte: não use Hybrid Subnets com o seguinte.

    • Network Connectivity Center (NCC): O NCC não tem suporte para Hybrid Subnets. Google CloudO não impede que você exporte sub-redes que tenham o roteamento de sub-rede híbrida ativado para um hub do NCC, mas isso pode resultar em um comportamento de roteamento imprevisível.

    • NEGs de conectividade híbrida: os sistemas de sondagem de verificação de integridade do Google para verificações de integridade centralizadas não podem se comunicar com endpoints em um NEG híbrido se os endpoints se encaixarem em uma rota de sub-rede híbrida.

    • Hybrid NAT: o Hybrid NAT não tem suporte para Hybrid Subnets. O Hybrid NAT não realiza NAT de origem (SNAT) em pacotes enviados de VMs para destinos em uma rota estática ou dinâmica se uma rota de sub-rede híbrida for correspondida primeiro.

Lembre-se também das seguintes limitações práticas.

  • A rede no local precisa oferecer suporte ao proxy ARP: as Hybrid Subnets não oferecem suporte à migração de cargas de trabalho de redes remotas em outros provedores de serviços em nuvem, como Azure ou AWS, porque essas redes remotas não oferecem suporte ao proxy ARP.

  • A rede local precisa aceitar anúncios de rota /32: se você usar a Interconexão por parceiro da camada 3, verifique com o parceiro se ele oferece suporte ao recebimento de prefixos /32.

Opções de migração

O Google recomenda usar 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 o 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 para migrar cargas de trabalho para Google Cloud.

ARP do proxy e Hybrid Subnets

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

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

Recomendamos o seguinte para usar o ARP do proxy na rede local:

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

Limitação de regionalidade

Essa limitação se aplica quando o tráfego corresponde a uma rota de sub-rede híbrida, mas o endereço IP de destino não está associado a uma VM em execução ou a uma regra de encaminhamento interno. Durante a etapa de recursos não correspondentes em sub-redes híbridas do modelo de seleção de rotas do Google Cloud, as rotas são avaliadas como se a origem de um pacote estivesse na mesma rede VPC que a rota de sub-rede híbrida.

Se uma rota estática ou dinâmica com um intervalo de destino que se encaixa em uma rota de sub-rede híbrida tiver próximos saltos em uma região diferente:

  • Se a rota tiver uma combinação de próximos saltos, em que alguns estão na mesma região que a rota de sub-rede híbrida e alguns estão em outras regiões, o tráfego será descartado sempre que o ECMP selecionar um próximo salto em uma região diferente da sub-rede. Essa queda de pacote acontece mesmo que o pacote também corresponda a uma rota menos específica que tenha próximos saltos na região da sub-rede.
  • Se a rota não tiver próximos saltos na mesma região que a sub-rede que usa o roteamento de sub-rede híbrida, o pacote será descartado.

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

  • A sub-rede que tem o roteamento de sub-rede híbrida ativado
  • O Cloud Router que aprende rotas para sua rede local
  • 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 com o intervalo de endereços IP 192.0.2.0/24 que tenha o roteamento de sub-rede híbrida ativado. A sub-rede está na região us-central1. O Cloud Router aprendeu duas rotas com intervalos de destino que se encaixam na rota de sub-rede híbrida:

  • Uma rota dinâmica com intervalo de destino 192.0.2.0/25 e um próximo salto na região us-central1
  • Uma rota dinâmica 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 interno na sub-rede local. Portanto, o modelo de seleção de rotas seleciona a rota personalizada que tem 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, 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 rede VPC que contém uma sub-rede que usa o roteamento de sub-rede híbrida a uma rede VPC com peering usando o peering de rede VPC.

O tráfego de clientes em uma rede com peering pode alcançar destinos no bloco CIDR compartilhado, independentemente de os destinos serem Google Cloud recursos ou na rede local. Se um pacote de um cliente na rede com peering tiver um destino que corresponda a uma rota de sub-rede híbrida de peering e o destino não corresponder a uma VM em execução ou a uma regra de encaminhamento interno, o pacote poderá ser roteado usando uma rota estática ou dinâmica na rede VPC com peering.

O roteamento usando uma rota estática ou dinâmica na rede VPC com peering não depende da troca de rotas personalizadas com a rede VPC que contém o cliente. No entanto, o seguinte ainda é relevante:

  • Verifique se o uso das rotas dinâmicas por região por grupo de peering cota na rede VPC que contém o cliente é menor que o limite da cota.

  • Verifique se não há outras rotas na rede VPC do cliente para os intervalos de destino que correspondem às rotas estáticas ou dinâmicas na rede com peering que se encaixam na rota de sub-rede híbrida de peering.

Desempenho da rede

As Hybrid Subnets usam a camada 3 do modelo OSI para rotear pacotes entre as redes locais e VPC. 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 network tromboning.

Como as Hybrid Subnets usam essa abordagem de roteamento, você pode esperar um desempenho 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, é necessário Configurar regras de firewall para garantir que as Google Cloud VMs possam se comunicar com cargas de trabalho na rede local.

Preços

Para informações sobre preços das Hybrid Subnets, consulte Preços da nuvem privada virtual.

A seguir