Acerca da migração para o Google Cloud com sub-redes híbridas

As sub-redes híbridas ajudam a migrar cargas de trabalho de outra rede, a rede de origem, para uma sub-rede da nuvem privada virtual (VPC) sem ter de alterar endereços IP. Ao combinar uma sub-rede na rede de origem com uma sub-rede da VPC, cria uma única sub-rede lógica que lhe permite migrar cargas de trabalho individuais e instâncias de máquinas virtuais (VM) ao longo do tempo. Depois de todas as cargas de trabalho e VMs terem sido migradas, pode desativar a sub-rede de origem.

As sub-redes híbridas também suportam a migração de VMs de Google Cloud para uma rede no local ou entre duas redes da VPC.

Um diagrama de três fases ilustra a migração de cargas de trabalho de no local para Google Cloud através de sub-redes híbridas.
Figura 1. Durante a migração, uma sub-rede híbrida oferece conetividade entre cargas de trabalho numa rede de origem e uma rede VPC (clique para aumentar).

Especificações

As sub-redes híbridas têm 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 numa rede VPC.
    • A conetividade interna é mantida entre todas as VMs e cargas de trabalho numa sub-rede híbrida.
    • A rede de origem pode ser uma rede nas instalações ou outra rede VPC. O segmento pode ser uma sub-rede completa ou parte de uma.
    • As duas partes de uma sub-rede híbrida têm de estar ligadas por um produto de conetividade de rede, como o Cloud VPN ou o Cloud Interconnect.
    • O intervalo de endereços IPv4 principal da sub-rede da VPC tem de corresponder ao intervalo do segmento da rede de origem usado pela sub-rede híbrida.
  • Configuração da rede VPC:
    • Tem de ativar o encaminhamento de sub-redes híbridas para configurar uma sub-rede da VPC como parte de uma sub-rede híbrida. Quando o encaminhamento de sub-redes híbrido está ativado, as rotas personalizadas podem entrar em conflito (sobrepor-se) com os intervalos de endereços IPv4 principais e secundários das sub-redes.
    • Usa rotas anunciadas personalizadas do Cloud Router para anunciar seletivamente os endereços IP das VMs à medida que as migra para a sub-rede da VPC. Para suportar o ARP de proxy e a correspondência do prefixo mais longo, estas rotas têm de 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. Pode usar rotas /32 para VMs individuais.
  • Configuração da rede de origem:
    • Tem de configurar o ARP proxy na rede de origem.
    • Tem de configurar a rede de origem para anunciar o intervalo de endereços IP da sub-rede híbrida.
Um Cloud Router e um router no local processam o encaminhamento entre as duas partes de uma sub-rede híbrida que usa um intervalo de endereços IP partilhado e sobreposto.
Figura 2. Este diagrama oferece uma vista geral dos passos para criar uma sub-rede híbrida e como um Cloud Router e um router no local encaminham pacotes entre as duas partes de uma sub-rede híbrida (clique para aumentar).

Encaminhamento de sub-redes híbridas

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

Encaminhamento da rede da VPC

Durante o passo de correspondência de trajetos de sub-rede do modelo de encaminhamento da VPC, se o destino de um pacote corresponder a um trajeto de sub-rede local ou de peering,o Google Cloud tenta entregar o pacote através do trajeto de sub-rede correspondente. Numa 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 é rejeitado e todas as outras rotas são ignoradas.

No entanto, se o encaminhamento de sub-rede híbrido estiver ativado para a sub-rede, o caminho da sub-rede torna-se um caminho de sub-rede híbrido e o comportamento de encaminhamento é 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, Google Cloud entrega 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 da VPC, Google Cloud usa um processo de encaminhamento especial para recursos não correspondentes. Este processo inclui a verificação de rotas dinâmicas e estáticas personalizadas que se sobrepõem ao intervalo da sub-rede híbrida. Numa sub-rede híbrida configurada corretamente, os pacotes são encaminhados para a rede de origem através de uma rota dinâmica local que o Cloud Router aprende para a sub-rede de origem.
Numa sub-rede híbrida, o pacote A é encaminhado localmente e o pacote B é encaminhado para um destino no local.
Figura 3. As VMs numa sub-rede híbrida podem alcançar destinos numa sub-rede no local e numa sub-rede de rede VPC, mesmo que ambas as sub-redes partilhem o mesmo intervalo de endereços IP sobrepostos (clique para aumentar).

Por exemplo, na figura 3, o pacote A é encaminhado para uma VM na VPC parte de uma sub-rede híbrida através de uma rota de sub-rede híbrida local. O destino do pacote B não está associado a uma VM em execução nem a uma regra de encaminhamento interno na parte da VPC da sub-rede híbrida, pelo que o Google Cloud verifica se existem rotas personalizadas em conflito. É encontrada uma correspondência e Google Cloud usa a rota dinâmica personalizada sobreposta para enviar o pacote B para a rede de origem.

Encaminhamento 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 router ou o dispositivo de primeiro salto da rede de origem executa uma pesquisa na tabela de encaminhamento.

Se o destino estiver associado a uma carga de trabalho na rede de origem, o router não intervém no ARP de proxy. O destino recebe o pedido ARP e responde com o respetivo endereço MAC, e o pacote é entregue localmente.

Se o destino estiver na parte da VPC da sub-rede híbrida e o router tiver aprendido um trajeto dinâmico para o destino que seja mais específico do que o trajeto da sub-rede local, o router seleciona o trajeto dinâmico através da correspondência do prefixo mais longo. Isto aciona a funcionalidade ARP de proxy do router. O router responde com o seu próprio endereço MAC e encaminha o pacote para o Cloud Router na rede da VPC.

Um router no local usa o ARP de proxy para encaminhar um pacote de uma carga de trabalho numa rede de origem para uma VM que migrou para Google Cloud.
Figura 4. Um router no local usa o ARP proxy para encaminhar um pacote de uma carga de trabalho numa rede de origem para uma VM que foi migrada para Google Cloud (clique para aumentar).

Limitações

As sub-redes híbridas têm as seguintes limitações.

  • Limitações de recursos:

    Estas limitações de recursos não são aplicadas por Google Cloud limites nem quotas. Excedê-los pode causar problemas de conetividade e estabilidade.

  • Tráfego e trajetos não suportados:

    • Os pacotes são ignorados se o próximo salto de uma rota em conflito estiver numa região diferente da sub-rede híbrida.
    • Os seguintes tipos de trajetos não são suportados como trajetos em conflito:
      • Rotas predefinidas geradas pelo sistema
      • Rotas baseadas em políticas
      • Rotas estáticas com etiquetas 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 suportado com sub-redes híbridas. Pode configurar uma rede de 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 ligados ao intervalo de endereços IP da sub-rede híbrida tem um comportamento de encaminhamento imprevisível.
    • O NAT híbrido não é suportado com sub-redes híbridas. Embora possa configurar uma sub-rede híbrida para usar o NAT híbrido, a funcionalidade não é aplicada ao tráfego afetado pelo encaminhamento de sub-rede híbrida.
    • O encaminhamento de sub-rede híbrido não se aplica ao tráfego IPv6.
    • O tráfego de transmissão e multidifusão numa sub-rede híbrida não é suportado.
    • Não pode usar ligações de interconexão de parceiros da camada 3 que não suportem o anúncio de rotas /32 com sub-redes híbridas.
    • O Cloud Router de uma sub-rede híbrida não pode exceder o número máximo de rotas anunciadas personalizadas por sessão BGP.
    • As cargas de trabalho na rede de origem não conseguem aceder às APIs Google e aos serviços através do acesso privado à Google.
    • As cargas de trabalho na rede de origem não conseguem aceder aos pontos finais do Private Service Connect para APIs Google.

  • Cenários de migração não suportados:

    • As sub-redes híbridas não suportam a migração de cargas de trabalho de outros fornecedores de serviços na nuvem.
    • As sub-redes híbridas não suportam a migração de VMs de uma origem do Azure ou da AWS.
    • As sub-redes híbridas não suportam a transferência de dados de site para site.
    • As sub-redes híbridas não suportam o Google Cloud VMware Engine como destino de migração. Se o VMware Engine for o seu destino de migração, recomendamos que migre as VMs VMware através do VMware HCX.

  • Outras limitações:

    • As sub-redes híbridas não detetam conflitos de endereços IP entre a rede de origem e as partes da VPC de uma sub-rede híbrida. Certifique-se de que cada endereço IP (exceto o gateway predefinido) é usado apenas uma vez.
    • As sub-redes híbridas não podem alojar cargas de trabalho nos endereços IP reservados nas sub-redes IPv4.
    • As cargas de trabalho na rede de origem não podem ser pontos finais para grupos de pontos finais de rede de conetividade híbrida que usam verificações de estado centralizadas.
    • O encaminhamento de entrada do Cloud DNS não responde a pedidos DNS de cargas de trabalho na rede de origem.

Opções de migração

A Google recomenda a utilização do Migrate to Virtual Machines com sub-redes híbridas para automatizar o processo de migração de VMs de uma origem do VMware ou de uma origem do Google Cloud VMware Engine.

Em alternativa, pode usar ferramentas de migração de terceiros com sub-redes híbridas, desde que os requisitos das sub-redes híbridas descritos neste documento sejam cumpridos.

Para obter informações sobre o planeamento de uma migração com o Migrate to Virtual Machines, consulte o artigo Percurso de migração com o Migrate to VMs.

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

Para receber apoio técnico para planear uma migração para Google Cloud usando sub-redes híbridas, apresente um registo de apoio técnico.

Considerações sobre a utilização de sub-redes híbridas

As secções seguintes descrevem as considerações para usar sub-redes híbridas.

ARP de proxy e sub-redes híbridas

As sub-redes híbridas requerem que o proxy ARP seja configurado no router da rede de origem ou no dispositivo de primeiro salto (o ponto onde um anfitrião envia primeiro tráfego que tem um destino fora da respetiva rede local).

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

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

  • Consulte o fornecedor da estrutura da sua rede de origem para conhecer as práticas recomendadas relacionadas com a ativação do ARP de proxy e a proteção do seu ambiente de rede.
  • Desative o ARP de 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 em conflito (rotas personalizadas que se sobrepõem ao intervalo de endereços da sub-rede híbrida) têm de ter todos os respetivos saltos seguintes na mesma região que a sub-rede híbrida.

Se um trajeto em conflito tiver próximos trajetos numa região diferente:

  • Se o trajeto tiver uma combinação de saltos seguintes locais e remotos, o tráfego é ignorado sempre que o ECMP seleciona um salto seguinte numa região remota. Esta eliminação de pacotes ocorre mesmo que o pacote também corresponda a uma rota menos específica que tenha saltos seguintes na mesma região.
  • Se a rota não tiver saltos seguintes na mesma região que a sub-rede híbrida, o pacote é rejeitado.

Certifique-se de que os seguintes recursos estão localizados na mesma região:

  • A sub-rede de VPC configurada como uma sub-rede híbrida
  • O Cloud Router que aprende rotas para a sua rede de origem
  • Os túneis de VPN de alta disponibilidade ou as associações VLAN que oferecem conetividade híbrida

Por exemplo, suponhamos que existe uma sub-rede híbrida com o intervalo de endereços IP 192.0.2.0/24. A sub-rede da VPC está na região us-central1. O Cloud Router memorizou dois trajetos em conflito:

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

É enviado um pacote para o destino 192.0.2.2. Este endereço IP não está associado a uma VM em execução ou a uma regra de encaminhamento interno na sub-rede da VPC, pelo que o modelo de seleção de rotas seleciona a rota personalizada que tem o destino mais específico, que é 192.0.2.0/30. Este trajeto não tem um próximo salto na região da sub-rede híbrida, pelo que o pacote é rejeitado.

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

Intercâmbio de redes da VPC

Pode ligar uma sub-rede híbrida a uma rede VPC de pares através do intercâmbio da rede da VPC. A rede VPC da sub-rede híbrida tem de ser configurada para exportar a sub-rede e as rotas personalizadas, e a rede VPC com peering tem de ser configurada para as importar.

Quando a rede VPC com peering programou os caminhos, pode alcançar destinos no intervalo de endereços IP da sub-rede híbrida, independentemente de existirem na rede de origem ou na rede com peering. Google Cloud

As rotas não sã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 quota de rotas dinâmicas por região por grupo de peering foi excedida.
  • As duas redes da VPC não estão diretamente interligadas. O intercâmbio das redes da VPC não é transitivo.

Se alguma dessas condições for verdadeira, a sub-rede híbrida não funciona corretamente do ponto de vista da rede VPC com peering.

Desempenho da rede

As sub-redes híbridas usam a camada 3 do modelo OSI para encaminhar pacotes entre a rede de origem e as partes da VPC de uma sub-rede híbrida. Esta abordagem ajuda as sub-redes híbridas a evitar desafios com a latência, as variações e o débito que podem ocorrer durante as migrações quando algumas cargas de trabalho existem numa rede de origem, mas outras cargas de trabalho foram migradas para a nuvem.

Em particular, evitar a tunelização da camada 2 ajuda a impedir a degradação do desempenho associada à encapsulagem e à encriptação de uma sobreposição da camada 2 adicional. Além disso, o encaminhamento da camada 3 permite que as sub-redes híbridas evitem um problema comum com a tunelização da camada 2, em que o tráfego é enviado para um nó central antes de chegar a destinos que podem estar perto do ponto de origem do tráfego. Por vezes, este problema é denominado network tromboning.

A abordagem das sub-redes híbridas à encaminhamento significa que pode esperar um desempenho de uma sub-rede híbrida semelhante ou igual ao de uma rede que não usa sub-redes híbridas.

Firewalls e sub-redes híbridas

As sub-redes híbridas evitam desafios relacionados com a utilização de firewalls com tráfego encapsulado em sobreposições da camada 2. Para o tráfego da camada 2, as firewalls só podem inspecionar pacotes nos pontos finais de sobreposição ou além destes, a menos que tome medidas específicas, como desencriptação transparente ou inspeções detalhadas do tráfego de sobreposição.

Não são necessárias considerações especiais para usar firewalls e regras de firewall existentes com sub-redes híbridas. No entanto, pode ter de configurar regras de firewall para garantir que as VMs podem comunicar com cargas de trabalho na rede de origem. Google Cloud

Preços

Não existem custos adicionais para usar sub-redes híbridas. No entanto, são-lhe cobrados recursos e tráfego de rede na parte da VPC de uma sub-rede híbrida.

Para mais informações, consulte os preços da Virtual Private Cloud.

O que se segue?