Balanceamento de carga TCP/UDP interno e redes conectadas

Nesta página, você verá cenários para acessar um balanceador de carga interno na sua rede de nuvem privada virtual (VPC, na sigla em inglês) usando uma rede conectada. Antes de analisar as informações nesta página, você já deve estar familiarizado com os conceitos do guia a seguir:

Como usar peering de rede VPC

Quando você usa o peering de rede VPC para conectar sua rede VPC a outra rede, o Google Cloud compartilha rotas de sub-rede entre as redes. As rotas de sub-rede permitem que o tráfego da rede de peering alcance os balanceadores de carga internos na sua rede. O acesso é permitido se as afirmações abaixo forem verdadeiras:

  • Para balanceadores de carga TCP/UDP internos, você precisa criar regras de firewall de entrada para permitir o tráfego de VMs cliente na rede com peering. As regras de firewall do Google Cloud não são compartilhadas entre redes ao usar o peering de rede VPC.
  • As instâncias de máquina virtual (VM, na sigla em inglês) do cliente na rede de peering estão localizadas na mesma região do balanceador de carga interno, a menos que você configure o acesso global (somente para balanceadores de carga TCP/UDP internos). Com o acesso global configurado, as instâncias de VM cliente de qualquer região da rede VPC com peering podem acessar seu balanceador de carga TCP/UDP interno. O acesso global não é compatível com o balanceamento de carga de HTTP(S) interno.

Não é possível compartilhar apenas alguns balanceadores de carga TCP/UDP ou HTTP(S) internos usando peering de rede VPC. Todos os balanceadores de carga internos são compartilhados automaticamente. Você pode limitar o acesso aos back-ends do balanceador de carga das seguintes maneiras:

  • Para balanceadores de carga TCP/UDP internos, é possível usar regras de firewall de entrada aplicáveis a instâncias de VM de back-end.

  • Para balanceadores de carga HTTP(S) internos, é possível configurar as VMs ou os endpoints de back-end para controlar o acesso usando cabeçalhos HTTP. Por exemplo, X-Forwarded-For.

Como usar o Cloud VPN e o Cloud Interconnect

É possível acessar um balanceador de carga interno usando uma rede de peering conectada por um túnel do Cloud VPN ou por um anexo de interconexão (VLAN) para uma Interconexão dedicada ou Interconexão por parceiro. A rede de peering pode ser uma rede local, outra rede VPC do Google Cloud ou uma rede virtual hospedada por um provedor de nuvem diferente.

Acesso por meio de túneis do Cloud VPN

É possível acessar um balanceador de carga interno por meio de um túnel do Cloud VPN quando todas as condições a seguir forem atendidas.

Na rede do balanceador de carga interno

  • O gateway e o túnel do Cloud VPN estão localizados na mesma região dos componentes do balanceador de carga interno, a menos que você configure o acesso global (somente para balanceadores de carga TCP/UDP internos).

  • As rotas fornecem caminhos para o tráfego de saída voltar à rede de peering (cliente). Se você estiver usando os túneis do Cloud VPN com roteamento dinâmico, considere o modo de roteamento dinâmico da rede do Cloud VPN do balanceador de carga. O modo de roteamento dinâmico determina quais rotas dinâmicas personalizadas estão disponíveis para os back-ends.

  • No caso do balanceador de carga TCP/UDP interno, você configurou regras de firewall para que os clientes locais possam se comunicar com as VMs de back-end do balanceador de carga.

Na rede de peering

A rede de peering precisa ter pelo menos um túnel do Cloud VPN com rotas para a sub-rede em que o balanceador de carga interno está definido.

Se a rede de peering for outra rede VPC do Google Cloud:

  • O gateway do Cloud VPN da rede de peering pode ser localizado em qualquer região.

  • Em túneis do Cloud VPN que usam roteamento dinâmico, o modo de roteamento dinâmico da rede VPC determina quais rotas estão disponíveis para os clientes de cada região. Para fornecer um conjunto consistente de rotas dinâmicas personalizadas para os clientes de todas as regiões, use o modo de roteamento dinâmico global.

O diagrama a seguir destaca os principais conceitos ao acessar um balanceador de carga interno por meio de um gateway do Cloud VPN e seu túnel associado. O Cloud VPN conecta sua rede local com segurança à rede VPC do Google Cloud usando túneis do Cloud VPN.

Balanceamento de carga TCP/UDP interno e Cloud VPN (clique para ampliar)
Balanceamento de carga interno e Cloud VPN (clique para ampliar)

Observe os seguintes elementos de configuração associados a este exemplo:

  • Na lb-network, foi configurado um túnel do Cloud VPN que usa roteamento dinâmico. O túnel VPN, o gateway e o Cloud Router estão localizados em us-west1, a mesma região dos componentes do balanceador de carga interno.
  • As regras de firewall de entrada permitidas foram configuradas para serem aplicadas às VMs de back-end nos grupos de instâncias ig-a e ig-c para que eles possam receber tráfego de endereços IP na rede VPC e da rede local, 10.1.2.0/24 e 192.168.1.0/24. Nenhuma regra de firewall de negação de saída foi criada. Portanto, a regra de saída de permissão implícita se aplica.
  • Pacotes enviados de clientes nas redes locais, inclusive de 192.168.1.0/24, para o endereço IP do balanceador de carga interno, 10.1.2.99, são entregues diretamente a uma VM de back-end íntegra, como vm-a2, de acordo com a afinidade de sessão configurada.
  • As respostas enviadas das VMs de back-end, como vm-a2, são entregues por meio do túnel VPN aos clientes locais.

Veja como resolver problemas do Cloud VPN em Solução de problemas do Cloud VPN.

Acessar pelo Cloud Interconnect

É possível acessar um balanceador de carga interno de uma rede de peering local conectada à rede VPC do balanceador de carga quando todas as condições a seguir forem atendidas na rede do balanceador de carga interno:

  • O anexo de interconexão (VLAN) e seu Cloud Router estiverem localizados na mesma região dos componentes do balanceador de carga. No entanto, apenas para o balanceador de carga TCP/UDP interno, configure acesso global.

  • Os roteadores locais compartilham rotas adequadas que fornecem caminhos de retorno para as respostas de VMs de back-end aos clientes locais. Os anexos de interconexão (VLANs) para a Interconexão dedicada e a Interconexão por parceiro usam os roteadores do Cloud Router. O conjunto de rotas dinâmicas personalizadas que eles aprendem depende do modo de roteamento dinâmico da rede do balanceador de carga.

  • No caso do balanceador de carga TCP/UDP interno, você configurou regras de firewall para que os clientes locais possam se comunicar com as VMs de back-end do balanceador de carga.

Na rede local, precisa existir pelo menos um anexo de interconexão (VLAN) com as rotas apropriadas. Os destinos dessas rotas incluem a sub-rede em que o balanceador de carga interno está definido. As regras de firewall de saída também precisam ser configuradas adequadamente.

Acesso global para balanceamento de carga TCP/UDP interno

Quando você configura o acesso global para o balanceamento de carga TCP/UDP interno, os recursos a seguir podem ser localizados em qualquer região:

  • Cloud Routers
  • Gateways e túneis do Cloud VPN
  • Anexos do Cloud Interconnect (VLANs)

No diagrama:

  • O Cloud Router está na região europe-west1.
  • O front-end e os back-ends do balanceador de carga TCP/UDP interno estão na região us-east1.
  • O Cloud Router usa peering com o roteador VPN local.
  • A sessão de peering do protocolo do gateway de borda (BGP) pode ser feita por meio do Cloud VPN ou do Cloud Interconnect com o peering direto ou com a Interconexão por parceiro.
Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)
Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)

O modo de roteamento dinâmico da rede VPC está definido como global para ativar o Cloud Router em europe-west1 e divulgar as rotas de sub-redes em qualquer região da rede VPC do balanceador de carga TCP/UDP interno.

Vários caminhos de saída

Em ambientes de produção, você precisa usar vários túneis do Cloud VPN ou anexos do Cloud Interconnect (VLANs) para redundância. Esta seção discute os requisitos ao usar vários túneis ou VLANs.

No diagrama a seguir, dois túneis do Cloud VPN conectam lb-network a uma rede local. Embora aqui sejam usados túneis do Cloud VPN, os mesmos princípios se aplicam ao Cloud Interconnect.

Balanceamento de carga TCP/UDP interno e vários túneis do Cloud VPN (clique para
       ampliar)
Balanceamento de carga interno e vários túneis do Cloud VPN (clique para ampliar)

Você precisa configurar cada túnel ou cada anexo do Cloud Interconnect (VLAN) na mesma região que o balanceador de carga interno, a menos que tenha ativado o acesso global (somente para balanceadores de carga TCP/UDP internos). Vários túneis ou VLANs podem fornecer largura de banda extra ou ser usados como caminhos em espera para redundância.

Tenha em mente os seguintes pontos:

  • Se a rede local tiver duas rotas com as mesmas prioridades, cada uma com um destino de 10.1.2.0/24 e um próximo salto correspondente a um túnel VPN diferente na mesma região do balanceador de carga interno, o tráfego poderá ser enviado da rede local (192.168.1.0/24) para o balanceador de carga usando vários caminhos de custo igual (ECMP, na sigla em inglês).
  • Depois que os pacotes são entregues à rede VPC, o balanceador de carga interno os distribui para as VMs de back-end de acordo com a afinidade de sessão configurada.
  • Se lb-network tiver duas rotas, cada uma com o destino 192.168.1.0/24 e um próximo salto correspondente a diferentes túneis VPN, as respostas das VMs de back-end poderão ser entregues em cada túnel de acordo com a prioridade das rotas na rede. Se diferentes prioridades de rota forem usadas, um túnel poderá servir como um backup para o outro. Se as mesmas prioridades forem usadas, as respostas serão entregues usando ECMP.
  • As respostas enviadas das VMs de back-end, como vm-a2, são entregues diretamente aos clientes locais por meio do túnel apropriado. Da perspectiva de lb-network, se as rotas ou os túneis VPN forem alterados, o tráfego poderá sair usando um túnel diferente. Isso pode resultar em redefinições de sessão TCP se uma conexão em andamento for interrompida.

A seguir