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

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 Google Cloud zona de destino. 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 ou mais VPCs de trânsito, em que toda a conectividade externa é processada.
  • Uma ou mais VPCs de acesso a serviços, que podem ser usadas 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 redes e sub-redes VPC, hubs do Network Connectivity Center, peering de rede VPC 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 redes VPC. 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, como as de transferência de dados 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 uma 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. Para simplificar a ilustração, o diagrama mostra uma única VPC de trânsito, mas é possível usar várias VPCs de trânsito para conectividade em diferentes regiões.

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 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 Interconexão entre nuvens, 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 VPCGoogle 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 redeGoogle 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 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 noGoogle Cloud.

Os principais recursos que fornecem conectividade de entrada com a Internet são os produtos do Cloud Load Balancing do Google. O design de uma rede 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 Alternativas ao uso de um IP externo externo. 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 doGoogle 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 mais detalhes, 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 próxima geração do Cloud e o proxy da Web seguro para fornecer uma filtragem mais profunda em URLs HTTP e HTTPS. Em todos os casos, no entanto, 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 Cloudque 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 redes VPC.

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

Para ter performance e escalonabilidade ideais com os serviços de rede na nuvem integrados, as VPCs precisam ser conectadas usando o Network Connectivity Center, conforme descrito em Conectividade entre VPCs com o Network Connectivity Center. O Network Connectivity Center oferece o seguinte:

  • Acesso transitivo a endpoints L4 e L7 do Private Service Connect e aos serviços associados
  • Acesso transitivo a redes locais aprendidas pelo BGP
  • Escala de rede VPC de 250 redes por hub

Se quiser inserir dispositivos virtuais de rede (NVAs, na sigla em inglês) para firewall ou outras funções de rede, use o peering de rede VPC. Os firewalls de perímetro podem permanecer em redes externas. Se a inserção de NVA for um requisito, use o padrão de conectividade entre VPCs com peering de rede VPC para interconectar suas VPCs.

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.

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 ponto de acesso da API.

Conectividade entre VPCs com o Network Connectivity Center

Recomendamos que as VPCs de aplicativo, de trânsito e de acesso a serviços se conectem usando os spokes da VPC do Network Connectivity Center.

Os pontos de acesso do consumidor de serviços são implantados em VPCs de acesso a serviços quando precisam ser acessíveis de outras redes (outras VPCs ou redes externas). É possível implantar pontos de acesso do consumidor de serviços em VPCs de aplicativos se eles precisarem ser acessados apenas de dentro da VPC.

Se você precisar dar acesso a serviços por trás do acesso a serviços particulares, crie uma VPC de acesso a serviços conectada a uma VPC de trânsito usando a VPN de alta disponibilidade. Em seguida, conecte a VPC de serviços gerenciados à VPC de acesso a serviços. A VPN de alta disponibilidade permite o roteamento transitivo de outras redes.

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

  • Network Connectivity Center: fornece conectividade entre VPCs de trânsito, VPCs de aplicativos e VPCs de acesso a serviços que hospedam endpoints do Private Service Connect.
  • Conexões de alta disponibilidade entre VPCs: fornecem conectividade transitiva para sub-redes de acesso a serviços particulares hospedadas em VPCs de acesso a serviços. Essas VPCs de acesso a serviços não devem ser adicionadas como um spoke do hub do Network Connectivity Center.

Ao combinar esses tipos de conectividade, planeje as seguintes considerações:

  • Redistribuição de sub-redes de peering de rede VPC e peering do Network Connectivity Center em roteamento dinâmico (para a VPC de acesso a serviços por VPN de alta disponibilidade e para redes externas por interconexões híbridas)
  • Considerações sobre roteamento multirregional
  • Propagação de rotas dinâmicas no peering de rede VPC e no peering do Network Connectivity Center (da VPC de acesso a serviços por VPN de alta disponibilidade e de redes externas por interconexões híbridas)

O diagrama a seguir mostra uma VPC de acesso a serviços que hospeda sub-redes de acesso a serviços particulares conectadas à VPC de trânsito com VPN de alta disponibilidade. O diagrama também mostra as VPCs de aplicativo, de trânsito e de acesso a serviços que hospedam endpoints do consumidor do Private Service Connect conectados usando o Network Connectivity Center:

Estrutura geral da rede entre nuvens usando spokes de VPC do Network Connectivity Center

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

  • Rede externa: 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.
  • Rede VPC de trânsito: uma rede VPC no projeto hub que recebe conexões de redes locais e de outros CSPs e, em seguida, serve como um caminho de trânsito de outras VPCs para redes locais e de CSP.
  • VPCs de app: projetos e redes VPC que hospedam vários aplicativos.
  • VPC do consumidor para acesso a serviços particulares: uma rede VPC que hospeda acesso centralizado a serviços particulares para serviços necessários aos aplicativos em outras redes.
  • VPC de serviços gerenciados: serviços fornecidos e gerenciados por outras entidades, mas disponibilizados para aplicativos em execução em redes VPC.
  • VPC do consumidor para o Private Service Connect: uma rede VPC que hospeda pontos de acesso do Private Service Connect a serviços hospedados em outras redes.

Use a central de conectividade de rede para conectar as VPCs de aplicativo aos anexos da VLAN do Cloud Interconnect e às instâncias da VPN de alta disponibilidade nas VPCs de trânsito. Transforme todas as VPCs em spokes do hub do Network Connectivity Center e transforme os anexos da VLAN e as VPNs de alta disponibilidade em spokes híbridos do mesmo hub do Network Connectivity Center. Use a topologia de malha padrão do Network Connectivity Center para ativar a comunicação entre todos os spokes (VPC e híbridos). Essa topologia também permite a comunicação entre as VPCs de aplicativos sujeitas às políticas do Cloud NGFW. As VPCs de serviço do consumidor conectadas por VPN de alta disponibilidade não podem ser spokes do hub do Network Connectivity Center. Os endpoints do Private Service Connect podem ser implantados em spokes de VPC do Network Connectivity Center e não exigem uma conexão de VPN de alta disponibilidade para transitividade entre VPCs ao usar o Network Connectivity Center.

Conectividade entre VPCs com o peering de rede VPC

Quando os pontos de acesso do consumidor de serviços publicados são implantados em uma VPC de acesso a serviços, recomendamos que as VPCs de aplicativo se conectem usando o peering de rede VPC à VPC de trânsito e que as VPCs de acesso a serviços se conectem à VPC de trânsito por 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 acesso a serviços.

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

  • Peering de rede VPC: fornece conectividade entre a VPC de trânsito e as VPCs do aplicativo.
  • Conexões de alta disponibilidade entre VPCs: fornecem conectividade transitiva entre as VPCs de acesso a serviços e a VPC de trânsito.

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

  • Redistribuição de sub-redes de peering VPC em roteamento dinâmico (para a VPC de acesso a serviços por VPN de alta disponibilidade e para redes externas por conexões híbridas)
  • Considerações sobre roteamento multirregional
  • Propagação de rotas dinâmicas no peering de VPC (da VPC de acesso a serviços por VPN de alta disponibilidade e de redes externas por conexões híbridas)

O diagrama a seguir mostra uma VPC de acesso a serviços 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:

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 acesso a 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 de peering de rede VPC, quando as VPCs de aplicativo precisam se comunicar entre si, é possível conectá-las a um hub do Network Connectivity Center como spokes VPC. 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.

A segurança da carga de trabalho para conexões leste-oeste entre VPCs de aplicativos pode usar o firewall de última geração do Cloud.

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

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 doGoogle Cloud . O encaminhamento de DNS precisa ser ativado bidirecionalmente entreGoogle 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 acesso a serviços, 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 acesso a 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: