Segmentação de rede e conetividade para aplicações distribuídas na rede entre nuvens

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

A série é composta pelas seguintes partes:

Esta parte explora a estrutura de segmentação de rede e a conetividade, que é a base do design. Este documento explica as fases em que faz as seguintes escolhas:

  • A segmentação geral da rede e a estrutura do projeto.
  • Onde coloca a sua carga de trabalho.
  • Como os seus projetos estão ligados a redes externas nas instalações e de outros fornecedores de nuvem, incluindo a conceção da conetividade, do encaminhamento e da encriptação.
  • Como as suas redes VPC estão ligadas internamente entre si.
  • Como as suas Google Cloud sub-redes VPC estão ligadas umas às outras e a outras redes, incluindo como configura a acessibilidade do serviço e o DNS.

Segmentação de rede e estrutura do projeto

Durante a fase de planeamento, tem de decidir entre uma de duas estruturas de projeto:

  • Um projeto anfitrião de infraestrutura consolidado, no qual usa um único projeto anfitrião de infraestrutura para gerir todos os recursos de rede para todas as aplicações
  • Projetos de anfitriões segmentados, nos quais usa um projeto de anfitrião de infraestrutura em combinação com um projeto de anfitrião diferente para cada aplicação

Durante a fase de planeamento, recomendamos que também decida os domínios administrativos para os seus ambientes de carga de trabalho. Defina o âmbito das autorizações para os seus administradores e programadores de infraestrutura com base no princípio do menor privilégio e defina o âmbito dos recursos da aplicação em diferentes projetos de aplicações. Uma vez que os administradores de infraestrutura têm de configurar a conetividade para partilhar recursos, os recursos de infraestrutura podem ser processados num projeto de infraestrutura. Por exemplo, para configurar a conetividade a recursos de infraestrutura partilhados, os administradores de infraestrutura podem usar um projeto de infraestrutura para processar esses recursos partilhados. Ao mesmo tempo, a equipa de desenvolvimento pode gerir as respetivas cargas de trabalho num projeto e a equipa de produção pode gerir as respetivas cargas de trabalho num projeto separado. Em seguida, os programadores usariam os recursos de infraestrutura no projeto de infraestrutura para criar e gerir recursos, serviços, equilíbrio de carga e políticas de encaminhamento DNS para as respetivas cargas de trabalho.

Além disso, tem de decidir quantas redes VPC vai implementar inicialmente e como vão ser organizadas na hierarquia de recursos. Para ver detalhes sobre como escolher uma hierarquia de recursos, consulte o artigo Decida uma hierarquia de recursos para a sua Google Cloud zona de destino. Para ver detalhes sobre como escolher o número de redes VPC, consulte o artigo Decidir se deve criar várias redes VPC.

Para a rede entre nuvens, recomendamos que use as seguintes VPCs:

  • Uma ou mais VPCs de aplicações para alojar os recursos das diferentes aplicações.
  • Uma ou mais VPCs de trânsito, onde toda a conetividade externa é processada.
  • Uma ou mais VPCs de acesso a serviços, que podem ser usadas para consolidar a implementação do acesso privado a serviços publicados.

O diagrama seguinte mostra uma representação visual da estrutura de VPC recomendada que acabámos de descrever. Pode usar a estrutura de VPC apresentada no diagrama com uma estrutura de projeto consolidada ou segmentada, conforme descrito nas secções subsequentes. O diagrama apresentado aqui não mostra a conetividade entre as redes VPC.

Estrutura de VPC recomendada

Projeto anfitrião de infraestrutura consolidada

Pode usar um projeto anfitrião de infraestrutura consolidada para gerir todos os recursos de rede, como redes de VPC e sub-redes, hubs do Network Connectivity Center, intercâmbio da rede da VPC e equilibradores de carga.

É possível criar várias VPCs partilhadas de aplicações com os respetivos projetos de serviços de aplicações no projeto anfitrião da infraestrutura para corresponder à estrutura da organização. Use vários projetos de serviços de aplicações para delegar a administração de recursos. Toda a rede em todas as VPCs da aplicação é faturada ao projeto anfitrião da infraestrutura consolidada.

Para esta estrutura de projeto, muitos projetos de serviços de aplicações podem partilhar um número menor de VPCs de aplicações.

O diagrama seguinte oferece uma representação visual do projeto anfitrião da infraestrutura consolidada e dos vários projetos de serviços de aplicações que acabámos de descrever. O diagrama não mostra a conetividade entre todos os projetos.

Projeto anfitrião de infraestrutura consolidado e vários projetos de serviço de aplicações

Projetos de anfitriões segmentados

Neste padrão, cada grupo de aplicações tem o seu próprio projeto de anfitrião de aplicações e redes VPC. É possível anexar vários projetos de serviços de aplicações ao projeto de anfitrião. A faturação dos serviços de rede é dividida entre o projeto de alojamento da infraestrutura e os projetos de alojamento da aplicação. As cobranças de infraestrutura são faturadas ao projeto de anfitrião de infraestrutura e as cobranças de rede, como as de transferência de dados para aplicações, são faturadas a cada projeto de anfitrião de aplicações.

O diagrama seguinte oferece uma representação visual dos vários projetos de anfitrião e projetos de serviços de aplicações que acabámos de descrever. O diagrama não mostra a conetividade entre todos os projetos.

Vários projetos anfitriões e vários projetos de serviços de aplicações

Posicionamento da carga de trabalho

Muitas opções de conetividade dependem das localizações regionais das suas cargas de trabalho. Para obter orientações sobre o posicionamento de cargas de trabalho, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine. Deve decidir onde as suas cargas de trabalho vão estar antes de escolher localizações de conetividade.

Conetividade externa e híbrida

Esta secção descreve os requisitos e as recomendações para os seguintes caminhos de conetividade:

  • Ligações privadas a outros fornecedores de nuvem
  • Ligações privadas a centros de dados no local
  • Conetividade à Internet para cargas de trabalho, particularmente conetividade de saída

A rede entre nuvens envolve a interligação de várias redes na nuvem ou redes nas instalações. As redes externas podem ser detidas e geridas por organizações diferentes. Estas redes ligam-se fisicamente entre si através de uma ou mais interfaces de rede a rede (NNIs). A combinação de NNIs tem de ser concebida, aprovisionada e configurada para o desempenho, a resiliência, a privacidade e a segurança.

Para modularidade, reutilização e a capacidade de inserir NVAs de segurança, coloque as ligações externas e o encaminhamento numa VPC de trânsito, que serve como um serviço de conetividade partilhado para outras VPCs. As políticas de encaminhamento para resiliência, comutação por falha e preferência de caminho entre domínios podem ser configuradas uma vez na VPC de trânsito e usadas por muitas outras redes de VPC.

O design das NNIs e da conetividade externa é usado posteriormente para a conetividade interna e a rede VPC.

O diagrama seguinte mostra uma VPC de trânsito que funciona como um serviço de conetividade partilhado para outras VPCs, que estão ligadas através do intercâmbio da rede da VPC, do Network Connectivity Center ou da VPN de alta disponibilidade. Para simplificar a ilustração, o diagrama mostra uma única VPC de trânsito, mas pode usar várias VPCs de trânsito para a conetividade em diferentes regiões.

VPC de trânsito usada como um serviço de conetividade partilhada para outras VPCs

Ligações privadas a outros fornecedores de nuvem

Se tiver serviços em execução noutras redes de fornecedores de serviços na nuvem (CSP) que queira ligar à sua Google Cloud rede, pode ligar-se a eles através da Internet ou de ligações privadas. Recomendamos ligações privadas.

Ao escolher opções, considere o débito, a privacidade, o custo e a viabilidade operacional.

Para maximizar a taxa de transferência e melhorar a privacidade, use uma ligação direta de alta velocidade entre redes de nuvem. As ligações diretas eliminam a necessidade de equipamento de rede físico intermédio. Recomendamos que use o Cross-Cloud Interconnect, que oferece estas ligações diretas, bem como encriptação MACsec e uma taxa de débito de até 100 Gbps por link.

Se não puder usar a Interligação entre clouds, pode usar a Interligação dedicada ou a Interligação de parceiro através de uma instalação de colocation.

Selecione as localizações onde se liga aos outros FSCs com base na proximidade da localização às regiões de destino. Para a seleção de localizações, tenha em atenção o seguinte:

  • Consulte a lista de localizações:
    • Para o Cross-Cloud Interconnect, consulte a lista de localizações que estão disponíveis para ambos os fornecedores de serviços na nuvem e os CSPs (a disponibilidade varia consoante o fornecedor de serviços na nuvem). Google Cloud
    • Para o Dedicated Interconnect ou o Partner Interconnect, escolha uma localização de baixa latência para a instalação de colocation.
  • Avalie a latência entre o limite do ponto de presença (POP) especificado e a região relevante em cada CSP.

Para maximizar a fiabilidade das suas ligações entre nuvens, recomendamos uma configuração que suporte um SLA de tempo de atividade de 99,99% para cargas de trabalho de produção. Para ver detalhes, consulte os artigos Disponibilidade elevada do Cross-Cloud Interconnect, Estabeleça uma disponibilidade de 99,99% para o Dedicated Interconnect e Estabeleça uma disponibilidade de 99,99% para o Partner Interconnect.

Se não precisar de uma largura de banda elevada entre diferentes PSCs, é possível usar túneis VPN. Esta abordagem pode ajudar a começar e pode atualizar para o Cross-Cloud Interconnect quando as suas aplicações distribuídas usarem mais largura de banda. Os túneis de VPN também podem atingir um SLA de 99,99%. Para ver detalhes, consulte as topologias de VPN de HA.

Ligações privadas a centros de dados no local

Para a conetividade a centros de dados privados, pode usar uma das seguintes opções de conetividade híbrida:

  • Interligação dedicada
  • Interligação de parceiro
  • HA VPN

As considerações de encaminhamento para estas ligações são semelhantes às das ligações privadas a outros fornecedores de nuvem.

O diagrama seguinte mostra as ligações a redes no local e como os routers no local podem ligar-se ao Cloud Router através de uma política de peering:

Ligações a redes no local

Encaminhamento entre domínios com redes externas

Para aumentar a capacidade de recuperação e o débito entre as redes, use vários caminhos para ligar as redes.

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

Para redes que transferem dados em várias regiões, o custo e o nível de qualidade do serviço de cada rede podem diferir significativamente. Pode optar por usar algumas redes em detrimento de outras, com base nestas diferenças.

Configure a sua política de encaminhamento entre domínios para cumprir os seus requisitos de trânsito inter-regional, simetria de tráfego, taxa de transferência e resiliência.

A configuração das políticas de encaminhamento entre domínios depende das funções disponíveis no limite de cada domínio. A configuração também depende da forma como os domínios adjacentes estão estruturados do ponto de vista de um sistema autónomo e do endereçamento IP (sub-rede) em diferentes regiões. Para melhorar a escalabilidade sem exceder os limites de prefixos nos dispositivos periféricos, recomendamos que o seu plano de endereçamento IP resulte em menos prefixos agregados para cada combinação de região e domínio.

Ao criar o encaminhamento entre regiões, considere o seguinte:

  • AsGoogle Cloud redes VPC e o Cloud Router suportam o encaminhamento global entre regiões. Outros CSPs podem ter VPCs regionais e âmbitos do Border Gateway Protocol (BGP). Para ver detalhes, consulte a documentação do seu outro PSC.
  • O Cloud Router anuncia automaticamente rotas com preferências de caminho predeterminadas com base na proximidade regional. Este comportamento de encaminhamento depende do modo de encaminhamento dinâmico configurado da VPC. Pode ter de substituir estas preferências para obter o comportamento de encaminhamento pretendido.
  • Os diferentes CSPs suportam diferentes funções de BGP e Bidirectional Forwarding Detection (BFD) e o Cloud Router da Google também tem capacidades específicas de política de rotas, conforme descrito em Estabeleça sessões de BGP.
  • Os diferentes PSCs podem usar diferentes atributos de desempate do BGP para determinar a preferência de rotas. Consulte a documentação do seu PSC para ver detalhes.

Encaminhamento entre domínios de região única

Sugerimos que comece com o encaminhamento entre domínios de região única, que usa como base para criar associações de várias regiões com encaminhamento entre domínios.

Os designs que usam o Cloud Interconnect têm de ter, no mínimo, duas localizações de ligação que estejam na mesma região, mas em diferentes domínios de disponibilidade de limite.

Decida se quer configurar estas ligações duplicadas num design ativo/ativo ou ativo/passivo:

  • A configuração ativo/ativo usa o encaminhamento de vários caminhos de custo igual (ECMP) para agregar a largura de banda de ambos os caminhos e usá-los simultaneamente para tráfego entre domínios. O Cloud Interconnect também suporta a utilização de links agregados com LACP para alcançar até 200 Gbps de largura de banda agregada por caminho.
  • O modo ativo/passivo força um link a ser um standby pronto, que só assume o tráfego se o link ativo for interrompido.

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

O Cloud Router é instanciado em várias zonas, o que oferece uma maior capacidade de recuperação do que um único elemento. O diagrama seguinte mostra como todas as ligações resilientes convergem num único router na nuvem numa região. Este design pode suportar um SLA de disponibilidade de 99,9% numa única área metropolitana quando segue as diretrizes para estabelecer uma disponibilidade de 99,9% para o Dedicated Interconnect.

O diagrama seguinte mostra dois routers no local ligados de forma redundante ao serviço Cloud Router gerido numa única região:

As ligações resilientes podem usar um único Cloud Router

Encaminhamento entre domínios em várias regiões

Para oferecer conectividade alternativa, as redes podem estabelecer relações de intercâmbio em várias áreas geográficas. Ao associar as redes em várias regiões, o SLA de disponibilidade pode aumentar para 99,99%.

O diagrama seguinte mostra as arquiteturas de SLA de 99,99%. Mostra routers no local em duas localizações diferentes ligados de forma redundante aos serviços de Cloud Router geridos em duas regiões diferentes.

Ligações do Cloud Interconnect em várias regiões

Além da resiliência, o design de encaminhamento multirregional deve alcançar a simetria do fluxo. O design também deve indicar a rede preferencial para comunicações inter-regionais, o que pode fazer com o encaminhamento hot-potato e cold-potato. Combine o encaminhamento de batata fria num domínio com o encaminhamento de batata quente no domínio paritário. Para o domínio cold-potato, recomendamos que use o Google Cloud domínio de rede, que oferece funcionalidade de encaminhamento de VPC global.

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

O diagrama seguinte mostra como pode usar o encaminhamento hot-potato e cold-potato para especificar a sua rede de trânsito inter-regional preferida. Neste caso, o tráfego dos prefixos X e Y permanece na rede de origem até chegar à região mais próxima do destino (encaminhamento de batata fria). O tráfego dos prefixos A e B muda para a outra rede na região de origem e, em seguida, viaja pela outra rede até ao destino (encaminhamento hot-potato).

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

Encriptação do tráfego entre domínios

Salvo indicação em contrário, o tráfego não é encriptado nas ligações do Cloud Interconnect entre diferentes CSPs ou entre Google Cloud e centros de dados nas instalações. Se a sua organização exigir encriptação para este tráfego, pode usar as seguintes capacidades:

  • MACsec para o Cloud Interconnect: encripta o tráfego através de ligações do Cloud Interconnect entre os seus routers e os routers de limite da Google. Para ver detalhes, consulte a vista geral do MACsec para o Cloud Interconnect.
  • VPN de alta disponibilidade através do Cloud Interconnect: usa vários túneis de VPN de alta disponibilidade para poder fornecer a largura de banda total das ligações do Cloud Interconnect subjacentes. Os túneis de VPN de alta disponibilidade são encriptados com IPsec e implementados através de ligações do Cloud Interconnect que também podem ser encriptadas com MACsec. Nesta configuração, as ligações do Cloud Interconnect estão configuradas para permitir apenas o tráfego de VPN de alta disponibilidade. Para obter detalhes, consulte a vista geral da VPN de HA através do Cloud Interconnect.

Ligação à Internet para cargas de trabalho

Para a conetividade à Internet de entrada e saída, considera-se que o tráfego de resposta segue o sentido inverso do sentido do pedido original.

Geralmente, as funcionalidades que oferecem conetividade de Internet de entrada são separadas das funcionalidades de Internet de saída, com exceção dos endereços IP externos, que oferecem ambas as direções em simultâneo.

Conetividade de Internet de entrada

A conetividade de Internet de entrada está principalmente relacionada com o fornecimento de pontos finais públicos para serviços alojados na nuvem. Alguns exemplos incluem a conetividade à Internet com servidores de aplicações Web e servidores de jogos alojados emGoogle Cloud.

As principais funcionalidades que oferecem conetividade de Internet de entrada são os produtos de Cloud Load Balancing da Google. A conceção de uma rede VPC é independente da sua capacidade de fornecer conetividade de Internet de entrada:

Ligação à Internet de saída

Exemplos de conetividade de Internet de saída (em que o pedido inicial tem origem na carga de trabalho para um destino na Internet) incluem cargas de trabalho que acedem a APIs de terceiros, transferem pacotes de software e atualizações, e enviam notificações push para pontos finais de webhook na Internet.

Para a conetividade de saída, pode usar as Google Cloud opções incorporadas, conforme descrito em Alternativas à utilização de um endereço IP externo. Em alternativa, pode usar NVAs NGFW centrais, conforme descrito em Segurança de rede.

O caminho principal para fornecer conetividade à Internet de saída é o destino do gateway de Internet predefinido na tabela de encaminhamento da VPC, que é frequentemente a rota predefinida nas VPCs da Google. Os IPs externos e o Cloud NAT (serviço NAT gerido) requerem uma rota que aponte para o gateway de Internet predefinido da VPC.Google CloudPor conseguinte, os designs de encaminhamento de VPC que substituem o trajeto predefinido têm de fornecer conetividade de saída por outros meios. Para ver detalhes, consulte a vista geral do Cloud Router.

Para proteger a conetividade de saída, Google Cloud oferece a aplicação da firewall de nova geração da nuvem e o proxy Web seguro para fornecer uma filtragem mais detalhada nos URLs HTTP e HTTPS. No entanto, em todos os casos, o tráfego segue a rota predefinida para o gateway de Internet predefinido ou através de uma rota predefinida personalizada na tabela de encaminhamento da VPC.

Usar os seus próprios IPs

Pode usar endereços IPv4 pertencentes à Google para a conetividade à Internet ou pode usar a funcionalidade Traga os seus próprios endereços IP (BYOIP) para usar um espaço IPv4 que a sua organização possua. A maioria dos Google Cloud produtos que requerem um endereço IP encaminhável pela Internet suportam a utilização de intervalos BYOIP em alternativa.

Também pode controlar a reputação do espaço de IP através da respetiva utilização exclusiva. O BYOIP ajuda na portabilidade da conetividade e pode poupar custos de endereços IP.

Conetividade interna e rede da VPC

Com o serviço de conetividade externa e híbrida configurado, os recursos na VPC de trânsito podem alcançar as redes externas. O passo seguinte é disponibilizar esta conetividade aos recursos alojados noutras redes VPC.

O diagrama seguinte mostra a estrutura geral da VPC, independentemente de como ativou a conetividade externa. Mostra uma VPC de trânsito que termina as ligações externas e aloja um Cloud Router em todas as regiões. Cada Cloud Router recebe rotas dos respetivos pares externos através das NNIs em cada região. As VPCs de aplicações estão ligadas à VPC de trânsito para poderem partilhar a conetividade externa. Além disso, a VPC de trânsito funciona como um hub para as VPCs spoke. As VPCs de raio podem alojar aplicações, serviços ou uma combinação de ambos.

Estrutura geral da rede entre nuvens

Para um desempenho e uma escalabilidade ideais com os serviços de rede na nuvem incorporados, as VPCs devem ser ligadas através do Network Connectivity Center, conforme descrito no artigo Conetividade entre VPCs com o Network Connectivity Center. O Network Connectivity Center oferece o seguinte:

  • Acesso transitivo aos pontos finais L4 e L7 do Private Service Connect e aos respetivos serviços associados
  • Acesso transitivo a redes nas instalações aprendidas através do BGP
  • Escala da rede da VPC de 250 redes por hub

Se quiser inserir dispositivos virtuais de rede (NVAs) para firewalls ou outras funções de rede, tem de usar o peering de redes VPC. As firewalls de perímetro podem permanecer em redes externas. Se a inserção de NVAs for um requisito, use o padrão de conetividade entre VPCs com interligação de redes VPC para interligar as suas VPCs.

Configure o encaminhamento e a interligação de DNS na VPC de trânsito também. Para obter detalhes, consulte a secção de design da infraestrutura de DNS.

As secções seguintes abordam os possíveis designs para a conetividade híbrida que suportam a conetividade IP base, bem como implementações de pontos de acesso à API.

Conetividade entre VPCs com o Network Connectivity Center

Recomendamos que as VPCs de aplicação, as VPCs de trânsito e as VPCs de acesso aos serviços se liguem todas através de raios da VPC do Network Connectivity Center.

Os pontos de acesso do consumidor de serviços são implementados em VPCs services-access quando precisam de ser acessíveis a partir de outras redes (outras VPCs ou redes externas). Pode implementar pontos de acesso do consumidor de serviços em VPCs de aplicações se estes pontos de acesso precisarem de ser alcançados apenas a partir da VPC de aplicações

Se precisar de fornecer acesso a serviços protegidos pelo acesso a serviços privados, crie uma VPC de acesso a serviços que esteja ligada a uma VPC de trânsito através de uma VPN de alta disponibilidade. Em seguida, associe a VPC de serviços geridos à VPC de acesso aos serviços. A VPN de alta disponibilidade permite o encaminhamento transitivo a partir de outras redes.

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

  • Centro de conetividade de rede: oferece conetividade entre VPCs de trânsito, VPCs de aplicações e VPCs de acesso a serviços que alojam pontos finais do Private Service Connect.
  • Ligações entre VPCs de VPN de alta disponibilidade: oferecem conetividade transitiva para sub-redes de acesso a serviços privados alojadas em VPCs de acesso a serviços. Estes VPCs de acesso a serviços não devem ser adicionados como um spoke do hub do Network Connectivity Center.

Quando combina estes tipos de conetividade, planeie as seguintes considerações:

  • Redistribuição do intercâmbio de redes da VPC e das sub-redes de pares do Network Connectivity Center no encaminhamento dinâmico (para a VPC de acesso aos serviços através da VPN de alta disponibilidade e para redes externas através de interconexões híbridas)
  • Considerações sobre o encaminhamento multirregional
  • Propagação de rotas dinâmicas para o intercâmbio da rede da VPC e o intercâmbio do Network Connectivity Center (a partir da VPC de acesso aos serviços através da VPN de alta disponibilidade e a partir de redes externas através de interconexões híbridas)

O diagrama seguinte mostra uma VPC de acesso aos serviços que aloja sub-redes de acesso aos serviços privados ligadas à VPC de trânsito com a VPN de alta disponibilidade. O diagrama também mostra as VPCs de aplicações, as VPCs de trânsito e as VPCs de acesso a serviços que alojam pontos finais do consumidor do Private Service Connect ligados através do Network Connectivity Center:

Estrutura geral da rede entre nuvens com raios de VPC do Centro de conectividade de rede

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

  • Rede externa: um centro de dados ou um escritório remoto onde tem equipamento de rede. Este exemplo parte do princípio de que os locais estão ligados entre si através de uma rede externa.
  • Rede VPC de trânsito: uma rede VPC no projeto do hub que recebe ligações de instalações e outros CSPs e, em seguida, serve como um caminho de trânsito de outras VPCs para redes de instalações e CSPs.
  • VPCs de apps: projetos e redes VPC que alojam várias aplicações.
  • VPC do consumidor para acesso a serviços privados: uma rede VPC que aloja o acesso centralizado através do acesso a serviços privados aos serviços necessários pelas aplicações noutras redes.
  • VPC de serviços geridos: serviços fornecidos e geridos por outras entidades, mas tornados acessíveis a aplicações executadas em redes VPC.
  • VPC do consumidor para o Private Service Connect: uma rede VPC que aloja pontos de acesso do Private Service Connect a serviços alojados noutras redes.

Use o Centro de conectividade de rede para ligar as VPCs de aplicações aos anexos de VLAN do Cloud Interconnect e às instâncias de VPN de alta disponibilidade nas VPCs de trânsito. Transforme todas as VPCs em raios do hub do Network Connectivity Center e transforme as associações de VLANs e as VPNs de HA em raios híbridos do mesmo hub do Network Connectivity Center. Use a topologia de malha predefinida do Network Connectivity Center para ativar a comunicação entre todos os spokes (VPC e híbridos). Esta topologia também permite a comunicação entre as VPCs de aplicações sujeitas a políticas da NGFW na nuvem. Todas as VPCs de serviços de consumo ligadas através da VPN de alta disponibilidade não podem ser raios do hub do Centro de conectividade de rede. Os pontos finais do Private Service Connect podem ser implementados em spokes da VPC do Network Connectivity Center e não requerem uma ligação VPN de alta disponibilidade para a transitividade entre VPCs quando usam o Network Connectivity Center.

Conetividade entre VPCs com o intercâmbio da rede da VPC

Quando os pontos de acesso do consumidor de serviços publicados são implementados numa VPC de acesso aos serviços, recomendamos que as VPCs de aplicações se liguem através do intercâmbio de redes VPC à VPC de trânsito e que as VPCs de acesso aos serviços se liguem à VPC de trânsito através da VPN de alta disponibilidade.

Neste design, a VPC de trânsito é o hub e implementa os pontos de acesso do consumidor para pontos finais de serviços privados numa VPC de acesso a serviços.

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

  • Intercâmbio da rede da VPC: oferece conetividade entre a VPC de trânsito e as VPCs de aplicações.
  • Ligações entre VPCs de VPN de HA: oferecem conetividade transitiva entre as VPCs de acesso aos serviços e a VPC de trânsito.

Quando combina estas arquiteturas, planeie as seguintes considerações:

  • Redistribuição de sub-redes de pares da VPC no encaminhamento dinâmico (para a VPC de acesso aos serviços através da VPN de alta disponibilidade e para redes externas através de ligações híbridas)
  • Considerações sobre o encaminhamento multirregional
  • Propagação de rotas dinâmicas para o intercâmbio de VPCs (a partir da VPC de acesso aos serviços através da VPN de alta disponibilidade e a partir de redes externas através de ligações híbridas)

O diagrama seguinte mostra uma VPC de acesso a serviços, que está ligada à VPC de trânsito com VPN de HA e às VPCs de aplicações, que estão ligadas à VPC de trânsito com intercâmbio da rede da VPC:

VPC de serviços centrais ligada à VPC de trânsito com VPN de HA e as VPCs de aplicações ligadas à VPC de trânsito com intercâmbio de rede VPC

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

  • Localização do cliente: um centro de dados ou um escritório remoto onde tem equipamento de rede. Este exemplo pressupõe que os locais estão ligados entre si através de uma rede externa.
  • Metro: uma área metropolitana que contém um ou mais domínios de disponibilidade de limite do Cloud Interconnect. O Cloud Interconnect estabelece ligação a outras redes nessas áreas metropolitanas.
  • Projeto do hub: um projeto que aloja, pelo menos, uma rede VPC que serve de hub para outras redes VPC.
  • VPC de trânsito: uma rede VPC no projeto do hub que recebe ligações de ambientes nas instalações e outros CSPs e, em seguida, serve como um caminho de trânsito de outras VPCs para redes nas instalações e de CSPs.
  • Projetos e VPCs de anfitriões de apps: projetos e redes VPC que alojam várias aplicações.
  • VPC de acesso aos serviços: uma rede VPC que aloja o acesso centralizado aos serviços necessários pelas aplicações nas redes VPC de aplicações.
  • VPC de serviços geridos: serviços fornecidos e geridos por outras entidades, mas tornados acessíveis a aplicações executadas em redes VPC.

Para o design do intercâmbio da rede da VPC, quando as VPCs de aplicações precisam de comunicar entre si, pode ligar as VPCs de aplicações a um hub do Network Connectivity Center como raios da VPC. Esta abordagem oferece conectividade entre todas as VPCs no hub do Network Connectivity Center. Os subgrupos de comunicação podem ser criados através da utilização de vários hubs do Centro de conetividade de rede. As restrições de comunicação necessárias entre os pontos finais num hub específico podem ser alcançadas através de políticas de firewall.

A segurança da carga de trabalho para ligações east-west entre VPCs de aplicações pode usar o Cloud Next Generation Firewall.

Para ver orientações detalhadas e planos de configuração para implementar estes tipos de conetividade, consulte o artigo Arquitetura de rede centralizada.

Design da infraestrutura de DNS

Num ambiente híbrido, o Cloud DNS ou um fornecedor externo (nas instalações ou CSP) pode processar uma procura de DNS. Os servidores DNS externos são autoritários para zonas DNS externas e o Cloud DNS é autoritário para Google Cloud zonas. O encaminhamento de DNS tem de estar ativado bidirecionalmente entre Google Cloud e as redes externas, e as firewalls têm de estar definidas para permitir o tráfego de resolução de DNS.

Se usar uma VPC partilhada para a sua VPC de acesso aos serviços, na qual os administradores de diferentes projetos de serviços de aplicações podem instanciar os seus próprios serviços, use a associação entre projetos de zonas DNS. A associação entre projetos permite a segmentação e a delegação do espaço de nomes DNS aos administradores do projeto de serviço.

No caso de trânsito, em que as redes externas estão a comunicar com outras redes externas através de Google Cloud, as zonas DNS externas devem ser configuradas para encaminhar pedidos diretamente umas para as outras. A rede multicloud forneceria conetividade para que os pedidos e as respostas de DNS fossem concluídos, 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 têm de permitir o tráfego de resolução de DNS entre as redes externas.

O diagrama seguinte mostra que um design de DNS pode ser usado com qualquer uma das configurações de conetividade de VPC de hub e raio propostas neste guia de design:

Design de DNS que pode ser usado com padrões de conetividade de hub e raio

O diagrama anterior mostra os seguintes passos no fluxo de design:

  1. DNS no local
    Configure os seus servidores DNS no local para serem autoritários para zonas DNS no local. 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 através da configuração da política do servidor de entrada na VPC do hub. Esta configuração permite que a rede no local resolva os nomes do Google Cloud DNS.
  2. VPC de trânsito – Proxy de saída de DNS
    Anuncie o intervalo do proxy de saída de DNS da Google 35.199.192.0/19 à rede local através dos Cloud Routers. Os pedidos DNS de saída do Google para o local são provenientes deste intervalo de endereços IP.
  3. Transit VPC - Cloud DNS
    1. Configure uma política de servidor de entrada para pedidos DNS de entrada a partir de local.
    2. Configurar uma zona de encaminhamento do Cloud DNS (para nomes DNS no local) que segmenta servidores DNS no local.
  4. VPC de acesso a serviços – Cloud DNS
    1. Configure a zona de peering do DNS de serviços (para nomes DNS no local) definindo a VPC do hub como a rede de peering. A resolução de DNS para recursos no local e de serviço passa pela VPC do hub.
    2. Configure as zonas privadas de DNS dos serviços no projeto anfitrião dos serviços e anexe a VPC partilhada dos serviços, a VPC partilhada da aplicação e a VPC do hub à zona. Isto permite que todos os anfitriões (no local e em todos os projetos de serviço) resolvam os nomes DNS dos serviços.
  5. Projeto do anfitrião da app – Cloud DNS
    1. Configure uma zona de peering de DNS de apps para a definição de nomes de DNS no local, definindo a VPC do hub como a rede de pares. A resolução de DNS para anfitriões no local passa pela VPC do hub.
    2. Configure zonas privadas de DNS da app no projeto anfitrião da app e anexe a VPC da aplicação, a VPC partilhada de serviços e a VPC do hub à zona. Esta configuração permite que todos os anfitriões (no local e em todos os projetos de serviço) resolvam os nomes de DNS da app.

Para mais informações, consulte o artigo Arquitetura híbrida com uma rede VPC de hub ligada a redes VPC spoke.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: