Segmentação de rede e conectividade para aplicativos distribuídos em rede entre nuvens

Last reviewed 2024-04-05 UTC

Este documento faz parte de uma série de guias de design para a rede entre nuvens.

A série consiste nas partes a seguir:

Nesta parte, exploramos a conectividade e a estrutura de segmentação de rede, que são a base do design. Este documento explica as fases em que você faz as seguintes escolhas:

  • A segmentação geral da rede e a estrutura do projeto.
  • Onde você coloca a carga de trabalho.
  • Como seus projetos são conectados a redes externas de provedores de nuvem e no local, incluindo o design para conectividade, roteamento e criptografia.
  • Como as redes VPC são conectadas internamente entre si.
  • Como suas sub-redes VPC do Google Cloud estão conectadas entre si e a outras redes, incluindo como você configura a acessibilidade do serviço e o DNS.

Segmentação de rede e estrutura do projeto

Durante a etapa de planejamento, é preciso decidir entre uma das duas estruturas de projeto:

  • Um projeto host de infraestrutura consolidado, em que você usa um único projeto host de infraestrutura para gerenciar todos os recursos de rede de todos os aplicativos
  • Projetos host segmentados, em que você usa um projeto host de infraestrutura em combinação com um projeto host diferente para cada aplicativo

Durante o estágio de planejamento, recomendamos que você também decida os domínios administrativos dos seus ambientes de carga de trabalho. Defina o escopo das permissões para os administradores e desenvolvedores de infraestrutura com base no princípio de privilégio mínimo e determine o escopo dos recursos do aplicativo em diferentes projetos de aplicativo. Como os administradores de infraestrutura precisam configurar a conectividade para compartilhar recursos, esses recursos podem ser gerenciados dentro de um projeto. Por exemplo, para configurar a conectividade com recursos de infraestrutura compartilhados, os administradores de infraestrutura podem usar um projeto de infraestrutura para gerenciar esses recursos compartilhados. Ao mesmo tempo, a equipe de desenvolvimento pode gerenciar as cargas de trabalho em um projeto e a equipe de produção pode gerenciar as cargas de trabalho em um projeto separado. Os desenvolvedores usariam os recursos de infraestrutura no projeto para criar e gerenciar recursos, serviços, balanceamento de carga e políticas de roteamento de DNS para as cargas de trabalho.

Além disso, você precisa decidir quantas redes VPC vão implementar inicialmente e como elas serão organizadas na hierarquia de recursos. Para mais detalhes sobre como escolher uma hierarquia de recursos, consulte Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud. Para detalhes sobre como escolher o número de redes VPC, consulte Como decidir se criar várias redes VPC.

Para a rede entre nuvens, recomendamos o uso das VPCs a seguir:

  • Uma ou mais VPCs de aplicativo para hospedar os recursos dos aplicativos diferentes.
  • Uma VPC de trânsito, em que toda a conectividade externa é processada.
  • Uma VPC de Serviços opcionais, que pode ser usada para consolidar a implantação do acesso particular a serviços publicados.

O diagrama a seguir mostra uma representação visual da estrutura VPC recomendada que acabou de ser descrita. É possível usar a estrutura da VPC mostrada no diagrama com uma estrutura de projeto consolidada ou segmentada, conforme descrito nas seções a seguir. O diagrama mostrado aqui não mostra a conectividade entre as redes VPC.

Estrutura de VPC recomendada

Projeto host de infraestrutura consolidado

É possível usar um projeto host de infraestrutura consolidado para gerenciar todos os recursos de rede, como sub-redes, peering e balanceadores de carga.

Várias VPCs compartilhadas de aplicativos com os projetos de serviço de aplicativo correspondentes podem ser criadas no projeto host da infraestrutura para corresponder à estrutura da organização. Use vários projetos de serviço de aplicativo para delegar a administração de recursos. Toda a rede em todas as VPCs de aplicativos é faturada no projeto host da infraestrutura consolidada.

Para essa estrutura de projeto, muitos projetos de serviço de aplicativo podem compartilhar um número menor de VPCs de aplicativo.

O diagrama a seguir fornece uma representação visual do projeto host da infraestrutura consolidada e de vários projetos de serviço de aplicativo que acabaram de ser descritos. O diagrama não mostra a conectividade entre todos os projetos.

Projeto host de infraestrutura consolidado e vários projetos de serviços de aplicativo

Projetos host segmentados

Nesse padrão, cada grupo de aplicativos tem o próprio projeto host de aplicativo e VPCs. Vários projetos de serviço de aplicativo podem ser anexados ao projeto host. O faturamento de serviços de rede é dividido entre o projeto host da infraestrutura e os projetos host do aplicativo. As taxas de infraestrutura são faturadas para o projeto host da infraestrutura, e as taxas de rede para aplicativos são faturadas para cada projeto host de aplicativo.

O diagrama a seguir é uma representação visual dos vários projetos host e de vários projetos de serviço de aplicativo que foram descritos recentemente. O diagrama não mostra a conectividade entre todos os projetos.

Vários projetos de host e vários projetos de serviço de aplicativo

Colocação da carga de trabalho

Muitas opções de conectividade dependem dos locais regionais das suas cargas de trabalho. Para orientação sobre como colocar cargas de trabalho, consulte Práticas recomendadas para a seleção de regiões do Compute Engine. Decida onde suas cargas de trabalho estarão antes de escolher os locais de conectividade.

Conectividade externa e híbrida

Nesta seção, descrevemos os requisitos e as recomendações para os seguintes caminhos de conectividade:

  • Conexões particulares com outros provedores de nuvem
  • Conexões particulares com data centers no local
  • Conectividade com a Internet para cargas de trabalho, principalmente conectividade de saída

A rede entre nuvens envolve a interconexão de várias redes de nuvem ou redes locais. As redes externas podem pertencer e gerenciar diferentes organizações. Essas redes se conectam fisicamente umas às outras em uma ou mais interfaces de rede para rede (NNIs, na sigla em inglês). A combinação de NNIs precisa ser projetada, provisionada e configurada para desempenho, resiliência, privacidade e segurança.

Para modularidade, reutilização e a capacidade de inserir NVAs de segurança, coloque conexões externas e roteamento em uma VPC de trânsito, que funciona como um serviço de conectividade compartilhado para outras VPCs. As políticas de roteamento para resiliência, failover e preferência de caminho entre domínios podem ser configuradas uma vez na VPC de trânsito e aproveitadas por muitas outras redes VPC.

O design das NNIs e a conectividade externa são usados posteriormente para conectividade interna e rede VPC.

O diagrama a seguir mostra a VPC de trânsito servindo como um serviço de conectividade compartilhada para outras VPCs, que são conectadas usando peering de rede VPC, Network Connectivity Center ou VPN de alta disponibilidade:

VPC de trânsito usada como serviço de conectividade compartilhada para outras VPCs

Conexões particulares com outros provedores de nuvem

Se você tem serviços em execução em outras redes de provedor de serviços de nuvem (CSP, na sigla em inglês) que quer conectar à sua rede do Google Cloud, é possível se conectar a elas pela Internet ou por conexões particulares. Recomendamos conexões particulares.

Ao escolher as opções, considere a capacidade de processamento, a privacidade, o custo e a viabilidade operacional.

Para maximizar a capacidade e melhorar a privacidade, use uma conexão direta de alta velocidade entre as redes de nuvem. Conexões diretas eliminam a necessidade de equipamentos de rede física intermediários. Recomendamos usar o Cross-Cloud Interconnect, que fornece essas conexões diretas, bem como criptografia MACsec e uma taxa de capacidade de até 100 Gbps por link.

Se não for possível usar o Cross-Cloud Interconnect, você poderá usar a Interconexão dedicada ou a Interconexão por parceiro por meio de uma instalação de colocation.

Selecione os locais onde você se conecta aos outros CSPs com base na proximidade do local às regiões segmentadas. Para escolher o local, considere o seguinte:

  • Verifique a lista de locais:
    • No caso do Cross-Cloud Interconnect, verifique a lista de locais disponíveis para o Google Cloud e os CSPs. A disponibilidade varia de acordo com o provedor de nuvem.
    • Para a Interconexão dedicada ou a Interconexão por parceiro, escolha um local de baixa latência para a instalação de colocation.
  • Avalie a latência entre o ponto de presença (POP) fornecido e a região relevante em cada CSP.

Para maximizar a confiabilidade das conexões entre nuvens, recomendamos uma configuração que ofereça suporte a um SLA de tempo de atividade de 99,99% para cargas de trabalho de produção. Para mais detalhes, consulte Alta disponibilidade do Cross-Cloud Interconnect, Estabelecer disponibilidade de 99,99% para a Interconexão dedicada e Estabelecer disponibilidade de 99,99% na Interconexão por parceiro.

Se você não precisar de alta largura de banda entre diferentes CSPs, poderá usar túneis de VPN. Essa abordagem ajuda você a dar os primeiros passos e é possível fazer upgrade para o Cross-Cloud Interconnect quando seus aplicativos distribuídos usarem mais largura de banda. Túneis VPN também podem atingir um SLA de 99,99%. Para detalhes, consulte Topologias de VPN de alta disponibilidade.

Conexões particulares com data centers no local

Para conectividade com data centers particulares, use uma das seguintes opções de conectividade híbrida:

  • Interconexão dedicada
  • Interconexão por parceiro
  • VPN de alta disponibilidade

As considerações de roteamento para essas conexões são semelhantes às de Conexões particulares com outros provedores de nuvem.

O diagrama a seguir mostra as conexões com redes locais e como os roteadores locais podem se conectar ao Cloud Router por meio de uma política de peering:

Conexões com redes locais

Roteamento entre domínios com redes externas

Para aumentar a resiliência e a capacidade entre as redes, use vários caminhos para conectá-las.

Quando o tráfego é transferido entre domínios de rede, ele precisa ser inspecionado por dispositivos de segurança com estado. Como resultado, é necessária uma simetria de fluxo no limite entre os domínios.

Para redes que transferem dados entre várias regiões, o custo e o nível de qualidade de serviço de cada rede pode ser significativamente diferente. Com base nessas diferenças, você pode decidir usar algumas redes em vez de outras.

Configure sua política de roteamento entre domínios para atender aos seus requisitos de trânsito inter-regional, simetria de tráfego, capacidade de processamento e resiliência.

A configuração das políticas de roteamento entre domínios depende das funções disponíveis na borda de cada domínio. A configuração também depende de como os domínios vizinhos são estruturados a partir de um sistema autônomo e da perspectiva de endereçamento IP (sub-rede) em diferentes regiões. Para melhorar a escalonabilidade sem exceder os limites de prefixo em dispositivos de borda, recomendamos que seu plano de endereçamento IP resulte em menos prefixos agregados para cada combinação de região e domínio.

Ao projetar o roteamento inter-regional, considere o seguinte:

  • As redes VPC do Google Cloud e o Cloud Router oferecem suporte ao roteamento global entre regiões. Outros CSPs podem ter VPCs regionais e escopos do protocolo de gateway de borda (BGP, na sigla em inglês). Para mais detalhes, consulte a documentação do seu outro CSP.
  • O Cloud Router anuncia automaticamente rotas com preferências de caminho predeterminadas com base na proximidade regional. Esse comportamento depende do modo de roteamento dinâmico configurado da VPC. Pode ser necessário substituir essas preferências pelo comportamento de roteamento que você quer.
  • Diferentes CSPs oferecem suporte a diferentes funções de BGP e detecção de encaminhamento bidirecional (BFD, na sigla em inglês), e o Cloud Router do Google também tem recursos específicos de política de rota, conforme descrito em Estabelecer sessões do BGP.
  • CSPs diferentes podem usar atributos de tie-breaking do BGP distintos para determinar a preferência pelas rotas. Consulte a documentação da sua CSP para mais detalhes.

Roteamento entre domínios de região única

Sugerimos que você comece com o roteamento entre domínios de região única, que é baseado para criar conexões de várias regiões com roteamento entre domínios.

Os projetos que usam o Cloud Interconnect precisam ter no mínimo dois locais de conexão que estejam na mesma região, mas diferentes domínios de disponibilidade de borda.

Decida se você quer configurar essas conexões duplicadas em um design ativo/ativo ou ativo/passivo:

  • Ativo/ativo usa o roteamento de vários caminhos de custo igual (ECMP, na sigla em inglês) para agregar a largura de banda de ambos os caminhos e usá-los simultaneamente para o tráfego entre domínios. O Cloud Interconnect também é compatível com o uso de links agregados do LACP para alcançar até 200 Gbps de largura de banda agregada por caminho.
  • Ativo/passivo força um link a ficar em espera, assumindo o tráfego apenas se o link ativo for interrompido.

Recomendamos um design ativo/ativo para links intrarregionais. No entanto, algumas topologias de rede no local, combinadas com o uso de funções de segurança com estado, podem exigir um projeto ativo/passivo.

O Cloud Router é instanciado em várias zonas, o que fornece maior resiliência do que um único elemento. O diagrama a seguir mostra como todas as conexões resilientes convergem em um único Cloud Router dentro de uma região. Esse projeto é compatível com um SLA de disponibilidade de 99,9% em uma única área metropolitana ao seguir as diretrizes de Estabelecer disponibilidade de 99,9% para a Interconexão dedicada.

O diagrama a seguir mostra dois roteadores locais conectados de maneira redundante ao serviço gerenciado do Cloud Router em uma única região:

Conexões resilientes podem usar um único Cloud Router

Roteamento multirregional entre domínios

Para fornecer conectividade de backup, as redes podem fazer peering em várias áreas geográficas. Ao conectar as redes em várias regiões, o SLA de disponibilidade pode aumentar para 99,99%.

O diagrama a seguir mostra as arquiteturas de SLA de 99,99%. Ele mostra roteadores locais em dois locais diferentes conectados de maneira redundante aos serviços gerenciados do Cloud Router em duas regiões diferentes.

Conexões do Cloud Interconnect em várias regiões

Além da resiliência, o design de roteamento multirregional precisa ter simetria de fluxo. O design também deve indicar a rede preferencial para comunicações inter-regionais, o que pode ser feito com roteamento de hot-potato e cold-potato. Parear o roteamento de cold-potato em um domínio com o roteamento de hot-potato no domínio de peering. Para o domínio frio, recomendamos o uso do domínio de rede do Google Cloud, que fornece a funcionalidade de roteamento de VPC global.

A simetria de fluxo nem sempre é obrigatória, mas ela pode causar problemas em funções de segurança com estado.

O diagrama a seguir mostra como usar o roteamento hot-potato e cold-potato para especificar sua rede de transporte público inter-regional preferida. Nesse caso, o tráfego dos prefixos X e Y permanece na rede de origem até chegar à região mais próxima do destino (roteamento Cold-potato). O tráfego dos prefixos A e B alterna para a outra rede na região de origem e, em seguida, viaja pela outra rede até o destino (roteamento hot-potato).

Usar o roteamento hot-potato e cold-potato para especificar a rede de trânsito inter-regional preferida

Criptografia do tráfego entre domínios

Salvo indicação em contrário, o tráfego não é criptografado nas conexões do Cloud Interconnect entre diferentes CSPs ou entre o Google Cloud e data centers no local. Se a organização exigir criptografia para esse tráfego, use os seguintes recursos:

  • MACsec para Cloud Interconnect: criptografa o tráfego por meio de conexões do Cloud Interconnect entre seus roteadores e os roteadores de borda do Google. Para mais detalhes, consulte Visão geral do MACsec para o Cloud Interconnect.
  • VPN de alta disponibilidade por meio do Cloud Interconnect: usa vários túneis de VPN de alta disponibilidade para poder fornecer a largura de banda total das conexões subjacentes do Cloud Interconnect. Os túneis de VPN de alta disponibilidade são criptografados por IPsec e implantados em conexões do Cloud Interconnect que também podem ser criptografados por MACsec. Nessa configuração, as conexões do Cloud Interconnect são configuradas para permitir apenas o tráfego de VPN de alta disponibilidade. Para detalhes, consulte Visão geral da VPN de alta disponibilidade sobre o Cloud Interconnect.

Conectividade com a Internet para cargas de trabalho

Para a conectividade de entrada e saída com a Internet, presume-se que o tráfego de resposta siga com estado a direção inversa da direção da solicitação original.

Geralmente, os recursos que fornecem conectividade de entrada de Internet são separados dos recursos de Internet de saída, com exceção dos endereços IP externos que fornecem as duas rotas simultaneamente.

Conectividade de entrada com a Internet

A conectividade de entrada de Internet se preocupa principalmente em fornecer endpoints públicos para serviços hospedados na nuvem. Exemplos disso incluem conectividade com a Internet para servidores de aplicativos da Web e servidores de jogos hospedados no Google Cloud.

Os principais recursos que fornecem conectividade de entrada com a Internet são os produtos do Cloud Load Balancing do Google.

Todos os tipos de Cloud Load Balancing fornecem o próprio caminho para o tráfego que retorna à origem da Internet, independente de você usar ou não VPCcaminhos de retorno especiais ousub-redes de proxy definidas pelo usuário. Em geral, o design da VPC é independente da capacidade de fornecer conectividade de entrada de Internet.

Conectividade de saída com a Internet

Exemplos de conectividade de Internet de saída (em que a solicitação inicial se origina da carga de trabalho para um destino da Internet) incluem cargas de trabalho que acessam APIs de terceiros, download de pacotes e atualizações de software e envio de notificações push para endpoints de webhook na na Internet.

Para conectividade de saída, use as opções integradas do Google Cloud, conforme descrito em Como criar conectividade com a Internet para VMs particulares. Como alternativa, é possível usar NVAs NGFW centrais, conforme descrito em Segurança de rede.

O principal caminho para fornecer conectividade de saída com a Internet é o destino padrão do gateway de Internet na tabela de roteamento da VPC, que geralmente é a rota padrão nas VPCs do Google. Os IPs externos e o Cloud NAT (serviço gerenciado NAT do Google Cloud), exigem uma rota que aponte para o gateway de Internet padrão da VPC. Portanto, os designs de roteamento de VPC que substituem a rota padrão precisam fornecer conectividade de saída por outros meios. Para saber mais, consulte a Visão geral do Cloud Router.

Para proteger a conectividade de saída, o Google Cloud oferece a aplicação do Firewall de última geração do Cloud e o Proxy seguro da Web para uma filtragem mais profunda de URLs HTTP e HTTPS. No entanto, em todos os casos, o tráfego segue a rota padrão para o gateway de Internet padrão ou por uma rota padrão personalizada na tabela de roteamento da VPC.

Como usar seus próprios IPs

É possível usar endereços IPv4 de propriedade do Google para conectividade com a Internet ou traga seus próprios endereços IP (BYOIP, na sigla em inglês) para usar um espaço IPv4 da sua organização. A maioria dos produtos do Google Cloud que exigem um endereço IP roteável pela Internet é compatível com o uso de intervalos do BYOIP.

Também é possível controlar a reputação do espaço de IP pelo uso exclusivo dele. O BYOIP ajuda na portabilidade da conectividade e pode economizar os custos dos endereços IP.

Conectividade interna e rede VPC

Com o serviço de conectividade externa e híbrida configurado, os recursos na VPC de trânsito podem alcançar as redes externas. A próxima etapa é disponibilizar essa conectividade para os recursos hospedados em outras VPCs.

Veja no diagrama a seguir a estrutura geral da VPC, independentemente de como você ativou a conectividade externa. Ele mostra uma VPC de trânsito que encerra conexões externas e hospeda um Cloud Router em todas as regiões. Cada Cloud Router recebe rotas de pares externos nas NNIs de cada região. As VPCs do aplicativo são conectadas à VPC de trânsito para que possam compartilhar conectividade externa. Além disso, a VPC de trânsito funciona como um hub para as VPCs spoke. As VPCs spoke podem hospedar aplicativos, serviços ou uma combinação de ambos.

Estrutura geral da rede entre nuvens

Configure também o encaminhamento de DNS e o peering na VPC de trânsito. Para mais detalhes, consulte a seção Design da infraestrutura DNS.

Para melhor desempenho e serviços de rede integrados na nuvem, recomendamos interconectar as VPCs com a rede entre nuvens ou o peering de rede VPC, em vez de uma VPN de alta disponibilidade.

Os endpoints do Private Service Connect e os front-ends de acesso a serviços particulares não podem ser acessados no peering de rede VPC ou na rede entre nuvens. Recomendamos o uso da VPN de alta disponibilidade para conectividade entre VPCs para superar essas limitações. Como o uso da VPN de alta disponibilidade para conectividade entre VPCs pode resultar em menor capacidade e maior sobrecarga operacional, o design de serviços centralizados reduz o período da implantação da VPN de alta disponibilidade.

Como alternativa, é possível implementar a conectividade transitiva inter-VPC para endpoints de serviço publicados colocando um balanceador de carga de rede de proxy interno na frente dos endpoints de serviço. Essa abordagem tem algumas limitações a serem consideradas, que são discutidas na seção conectividade com spokes do Network Connectivity Center usando o balanceamento de carga.

As seções a seguir discutem os possíveis designs de conectividade híbrida que oferece suporte à conectividade de IP base e a implantações de endpoint da API.

Conectividade entre VPCs para acesso a serviços compartilhados

Quando endpoints de serviço publicados são implantados em uma VPC de serviços, recomendamos que as VPCs do aplicativo conectem-se por peering de rede VPC ao hub (VPC de trânsito) e que a VPC de serviços se conecte ao hub usando uma VPN de alta disponibilidade.

Nesse design, a VPC de trânsito é o hub, e você implanta os pontos de acesso do consumidor para endpoints de serviço particulares em uma VPC de serviços.

O design é uma combinação de dois tipos de conectividade:

  • Peering de rede VPC: fornece conectividade entre a VPC hub e as VPCs do aplicativo.
  • Conexões de alta disponibilidade entre VPCs: fornecem conectividade transitiva da VPC de serviços para o hub.

Para orientações detalhadas e blueprints de configuração para implantar esses tipos de conectividade, consulte Arquitetura de rede Hub-and-spoke.

Ao combinar essas arquiteturas, planeje as seguintes considerações:

  • Redistribuição de sub-redes de peering VPC em roteamento dinâmico (para VPN de alta disponibilidade e para híbrido)
  • Considerações sobre roteamento multirregional
  • Propagação de rotas dinâmicas no peering de VPC (da VPN de alta disponibilidade e da nuvem híbrida)

O diagrama a seguir mostra uma VPC de serviços conectada à VPC de trânsito com a VPN de alta disponibilidade e as VPCs de aplicativo conectadas à VPC de trânsito com peering de rede VPC:

VPC de serviços centrais conectada à VPC de trânsito com VPN de alta disponibilidade e as VPCs de aplicativo conectadas à VPC de trânsito com peering de rede VPC

A estrutura mostrada no diagrama anterior contém estes componentes:

  • Local do cliente: um data center ou escritório remoto onde você tem equipamentos de rede. Neste exemplo, presumimos que os locais estão conectados entre si usando uma rede externa.
  • Área metropolitana: uma área metropolitana com um ou mais domínios de disponibilidade de borda do Cloud Interconnect. O Cloud Interconnect se conecta a outras redes nessas áreas metropolitanas.
  • Projeto Hub: um projeto que hospeda pelo menos uma rede VPC que serve como hub para outras redes VPC.
  • VPC de trânsito: Uma rede VPC no projeto hub que chega a conexões do local e de outros CSPs e, em seguida, atua como um caminho de trânsito de outras VPCs para redes locais e de CSP.
  • Projetos host de app e VPCs: projetos e redes VPC que hospedam vários aplicativos.
  • VPC de serviços: uma rede VPC que hospeda acesso centralizado aos serviços necessários para os aplicativos nas redes VPC dos aplicativos.
  • VPC de serviços gerenciados: serviços fornecidos e gerenciados por outras entidades, mas disponibilizados para aplicativos em execução em redes VPC.

Para o design hub e spoke, quando as VPCs do aplicativo precisam se comunicar entre si, é possível conectá-las a um hub do Network Connectivity Center como spokes. Essa abordagem fornece conectividade entre todas as VPCs no hub do Network Connectivity Center. É possível criar subgrupos de comunicação usando vários hubs do Network Connectivity Center. Qualquer restrição de comunicação necessária entre os endpoints em um hub específico pode ser alcançada usando políticas de firewall.

Conectividade com VPCs spoke do Network Connectivity Center usando o balanceamento de carga

Esse padrão inclui todas as VPCs como spoke em um hub do Network Connectivity Center e pode acomodar até 250 VPCs interconectadas. Um hub do Network Connectivity Center é uma construção de plano de gerenciamento que cria conectividade completa do plano de dados de malha entre todas as redes VPC registradas como spokes para o hub do Network Connectivity Center. O padrão oferece conectividade de qualquer lugar e permite a implantação de pontos de acesso a serviços gerenciados em qualquer VPC.

Para superar as limitações de transitividade, pontos de acesso a serviços gerenciados e conexões híbridas são acessados por balanceadores de carga de rede de proxy internos. A segurança da carga de trabalho para conexões leste-oeste pode usar o firewall de última geração do Cloud. Também é possível usar NAT Inter-VPC com esse padrão.

Esse padrão tem algumas limitações. Portanto, considere os fatores abaixo antes de adotá-lo:

  • Não é possível usar NVAs para firewalls de perímetro com esse padrão. Os firewalls de perímetro precisam permanecer em redes externas.
  • Há suporte apenas para o tráfego TCP de e para redes externas. Essa limitação ocorre porque as conexões com redes externas são executadas por um balanceador de carga de rede de proxy interno.
  • Os serviços publicados terão um front-end adicional no balanceador de carga do proxy. Esse front-end extra prolifera registros adicionais no DNS e exige buscas de DNS dividido.
  • Os serviços da camada 4 exigem um novo balanceador de carga de rede de proxy interno para cada novo serviço. Talvez você precise de balanceadores de carga diferentes dependendo dos protocolos necessários para a conexão.
  • As cotas de balanceamento de carga são limitadas para cada rede VPC. Essa é uma consideração importante porque os serviços de camada 4 exigem um novo balanceador de carga de rede de proxy interno para cada serviço de destino.
  • A opção de design escolhida para alta disponibilidade e failover entre regiões depende dos seus requisitos.
  • O tráfego criptografado no limite híbrido tem implicações na coordenação do gerenciamento de certificados.

Se as considerações anteriores forem comprometimentos gerenciáveis ou irrelevantes para seu ambiente, recomendamos esse padrão como a opção preferida.

O diagrama a seguir mostra um hub híbrido do Network Connectivity Center como um plano de gerenciamento para as conexões do Cloud Interconnect. Ele também mostra um hub da VPC do Network Connectivity Center conectando os spokes VPC do aplicativo e dos serviços:

VPCs de aplicativo conectadas como spokes a um hub do Network Connectivity Center

Balanceamento de carga de proxy para transitividade

Não é possível acessar as VPCs spoke do Network Connectivity Center:

  • Endpoints e front-ends de serviço gerenciados do Private Service Connect.
  • Redes atrás de conexões híbridas (Cloud Interconnect ou VPN de alta disponibilidade), porque rotas dinâmicas não são propagadas pela rede entre nuvens.

Essas limitações de transitividade podem ser superadas com a implantação de balanceadores de carga de rede de proxy interno com os recursos não transitivos processados como grupos de endpoints de rede híbridos (NEGs, na sigla em inglês). É possível implantar balanceadores de carga de rede de proxy interno na frente dos front-ends do serviço e na frente dos endpoints acessíveis nas conexões híbridas. Os front-ends do balanceador de carga de rede de proxy interno são implantados em sub-redes VPC que são propagadas entre VPCs spoke de rede entre nuvens. Os balanceadores de carga de rede de proxy interno permitem a acessibilidade na rede entre nuvens dos recursos não transitivos. Para hosts e serviços externos, endpoints do Private Service Connect e redes de acesso a serviços particulares, os back-ends precisam ser configurados como NEGs híbridos. Os back-ends do Private Service Connect são o único modelo em que os NEGs não precisam ser híbridos.

Projeto da infraestrutura de DNS

Em um ambiente híbrido, o Cloud DNS ou um provedor externo (local ou CSP) pode processar uma busca DNS. Os servidores DNS externos são autoritativos para zonas DNS externas, e o Cloud DNS é autoritativo para zonas do Google Cloud. O encaminhamento de DNS precisa ser ativado bidirecionalmente entre o Google Cloud e as redes externas, e os firewalls precisam ser configurados para permitir o tráfego de resolução de DNS.

Se você usa uma VPC compartilhada para sua VPC de serviços centrais, em que administradores de diferentes projetos de serviços de aplicativos podem instanciar os próprios serviços, use uma vinculação entre projetos de zonas de DNS. A vinculação entre projetos permite a segmentação e a delegação do namespace DNS aos administradores do projeto de serviço.

No caso de trânsito, quando as redes externas se comunicam com outras redes externas pelo Google Cloud, as zonas de DNS externas precisam ser configuradas para encaminhar solicitações diretamente entre si. A rede entre nuvens do Google forneceria conectividade para que as solicitações e respostas de DNS fossem concluídas, mas o Google Cloud DNS está envolvido no encaminhamento de qualquer tráfego de resolução de DNS entre zonas em redes externas. Todas as regras de firewall aplicadas na rede entre nuvens precisam permitir o tráfego de resolução de DNS entre as redes externas.

O diagrama a seguir mostra um design de DNS que pode ser usado com qualquer uma das configurações de conectividade VPC hub e spoke propostas neste guia de design:

Design de DNS que pode ser usado com padrões de conectividade hub e spoke

O diagrama anterior mostra as etapas a seguir no fluxo de design:

  1. DNS local
    Configure os servidores DNS locais para que sejam autoritativos para zonas DNS locais. Configure o encaminhamento de DNS (para nomes do Google Cloud DNS) segmentando o endereço IP de encaminhamento de entrada do Cloud DNS, que é criado por meio dopolítica de servidor de entrada na VPC hub. Essa configuração permite que a rede local resolva nomes do Google Cloud DNS.
  2. VPC de trânsito - proxy de saída DNS
    Anuncie o intervalo 35.199.192.0/19 do proxy de saída de DNS do Google para a rede local usando os Cloud Routers. As solicitações de DNS de saída do Google para o local são provenientes desse intervalo de endereços IP.
  3. VPC de trânsito: Cloud DNS
    1. Configure uma política de servidor de entrada para solicitações DNS de entrada do local.
    2. Configure a zona de encaminhamento do Cloud DNS (para nomes de DNS locais) segmentando servidores DNS locais.
  4. VPC de serviços: Cloud DNS
    1. Configurar a zona de peering de DNS de serviços (para nomes de DNS locais) definindo a VPC hub como a rede de peering. A resolução de DNS para recursos locais e de serviço passam pela VPC de hub.
    2. Configurar as zonas particulares de DNS de serviços no projeto host de serviços e anexar a VPC compartilhada de serviços, a VPC compartilhada do aplicativo e a VPC de hub à zona. Isso permite que todos os hosts (no local e em todos os projetos de serviço) resolvam os nomes DNS dos serviços.
  5. Projeto host do app: Cloud DNS
    1. Configure uma zona de peering de DNS do app para nomes de DNS locais definindo a VPC do hub como a rede de peering. A resolução de DNS para hosts locais passa pela VPC hub.
    2. Configurar zonas particulares de DNS do app no projeto host do app e anexar a VPC do aplicativo, a VPC compartilhada de serviços e a VPC de hub à zona. Essa configuração permite que todos os hosts (no local e em todos os projetos de serviço) resolvam os nomes DNS do app.

Para mais informações, consulte Arquitetura híbrida que usa uma rede VPC hub conectada a redes VPC spoke.

A seguir

Colaboradores

Autores:

Outros colaboradores: