Rede para cargas de trabalho híbridas e em várias nuvens: arquiteturas de referência

Last reviewed 2023-11-13 UTC

Este documento faz parte de uma série que descreve arquiteturas de rede e segurança para empresas que estão migrando cargas de trabalho de data center para o Google Cloud.

A série inclui os documentos a seguir:

Neste documento, falamos sobre a rede para um cenário em que as cargas de trabalho são executadas em mais de um lugar, como no local e na nuvem ou em vários ambientes de nuvem.

Arquitetura de migração lift-and-shift

O primeiro cenário de acesso da carga de trabalho híbrida é uma arquitetura de migração lift-and-shift.

Estabelecer conectividade particular

É possível estabelecer conectividade a redes locais usando a Interconexão dedicada ou a Interconexão por parceiro. A topologia ilustrada na figura 1 mostra como é possível usar quatro conexões de interconexão em duas áreas metropolitanas distintas e diferentes domínios de disponibilidade de borda para alcançar a disponibilidade de 99,99% usando a Interconexão dedicada. Para mais informações e recomendações detalhadas, consulte Conectividade híbrida entre um ambiente local e o Google Cloud no blueprint de bases empresariais.

Configuração de conexões redundantes do Cloud Interconnect para disponibilidade de 99,99%.

Figura 1. Configuração de conexões redundantes do Cloud Interconnect para disponibilidade de 99,99%.

O Network Connectivity Center permite usar a rede do Google para transferir dados entre vários locais hospedados na nuvem ou no local. Com essa abordagem, você aproveita o alcance e a confiabilidade da rede do Google quando precisa mover dados. É possível usar os dispositivos de roteador atuais do Cloud VPN, do Cloud Interconnect e de SD-WAN como spokes do Network Connectivity Center para oferecer suporte à transferência de dados entre as redes locais e as filiais, como mostrado na figura 2.

Configuração do Network Connectivity Center que conecta diferentes redes empresariais locais fora do Google Cloud usando a rede de backbone do Google.

Figura 2. Configuração do Network Connectivity Center que conecta diferentes redes locais e de nuvem fora do Google Cloud usando a rede de backbone do Google.

Para mais informações sobre como configurar o Network Connectivity Center, consulte Considerações na documentação do Network Connectivity Center.

Dispositivos SD-WAN

O Network Connectivity Center permite que você use um dispositivo virtual de rede de terceiros como um spoke do Network Connectivity Center para estabelecer conectividade entre um site externo e seus recursos de rede VPC. Um dispositivo roteador pode ser um roteador SD-WAN de terceiros compatível com um dos nossos parceiros ou outro dispositivo virtual que permita a troca de rotas com a a instância do Cloud Router. Essas soluções baseadas em dispositivos são complementares às opções de conectividade atuais de site para nuvem disponíveis com o Cloud VPN e o Cloud Interconnect, como spokes. A Figura 3 mostra uma topologia que usa dispositivos SD-WAN.

Configuração do Network Connectivity Center usando um roteador para integrar sua implementação de SD-WAN à rede do Google.

Figura 3. Configuração do Network Connectivity Center usando um roteador para integrar sua implementação de SD-WAN à rede do Google.

Você pode usar dispositivos de terceiros para executar funções de segurança. Os recursos de segurança do dispositivo podem ser integrados ao dispositivo roteador, como mostrado na Figura 3. Também é um padrão comum usar um dispositivo virtual de rede, em que o tráfego do local chega a uma rede VPC de trânsito e o dispositivo estabelece a conectividade com a rede VPC da carga de trabalho, como mostrado na figura 4.

Para mais informações sobre como configurar o Network Connectivity Center, consulte Considerações na documentação do Network Connectivity Center.

Arquitetura de serviços híbridos

Como no caso de uso de várias nuvens abordado em Rede para acesso seguro na nuvem: arquiteturas de referência, o Network Connectivity Center permite a conectividade entre suas redes locais e sites de filiais no Google Cloud. O Private Service Connect fornece acesso particular a serviços gerenciados pelo Google ou permite que você consuma outros serviços criados e implantados na nuvem.

Também é possível implementar a segurança de rede usando uma combinação de VPC Service Controls, firewalls do Google Cloud e dispositivos de rede virtuais da rede, como mostrado na figura 4.

Redes com uma arquitetura que usa um padrão de migração lift-and-shift e um padrão de design de serviços híbridos, projetadas para fornecer um plano de dados seguro.

Figura 4. Redes com uma arquitetura que usa um padrão de migração lift-and-shift e um padrão de design de serviços híbridos, projetadas para fornecer um plano de dados seguro.

Arquitetura distribuída de confiança zero

Em um ambiente híbrido, os microsserviços são executados em malhas de serviço implantadas em diferentes provedores de nuvem e ambientes locais. É possível proteger a comunicação entre os microsserviços usando mTLS e políticas de autorização. É uma prática comum as empresas criarem malhas de serviço na nuvem e estenderem as malhas para o local. Na Figura 5, mostramos um exemplo em que os serviços implantados no local acessam os serviços na nuvem. A mTLS de ponta a ponta entre os serviços é ativada usando o gateway leste-oeste e o roteamento baseado em SNI. O Cloud Service Mesh ajuda a proteger as comunicações entre serviços, permitindo configurar políticas de autorização para os serviços e implantar certificados e chaves fornecidos por uma autoridade certificadora gerenciada.

Os ambientes híbridos geralmente apresentam várias implantações de malha, como vários clusters do GKE. Um componente importante nesse fluxo é o roteamento de SNI, usado no gateway leste-oeste do GKE para cada cluster. Essa configuração permite o roteamento de mTLS direto para a carga de trabalho pelo gateway, preservando a conectividade de mTLS de ponta a ponta.

Malha de serviço de confiança zero implantada em um ambiente local e no Google Cloud.

Figura 5. Malha de serviço de confiança zero implantada em um ambiente local e no Google Cloud.

As empresas podem usar o Cloud Service Mesh para implantar em nuvens. Para lidar com desafios no gerenciamento de identidade e certificados entre provedores de nuvem, o Cloud Service Mesh fornece identidade da carga de trabalho e uma autoridade de certificação (CA) intermediária no cluster usando Serviço de CA (serviço de CA). A CA intermediária pode ser encadeada a uma CA externa ou pode ser hospedada no Google. É possível personalizar os atributos de CA, como região e algoritmo de assinatura, usando HSMs da empresa e o Cloud HSM.

A identidade da carga de trabalho permite atribuir identidades distintas e refinadas, bem como autorização para cada microsserviço no seu cluster. O Cloud Service Mesh gerencia o processo de emissão de certificados e de chaves e certificados de rotação automática, sem interromper as comunicações. Ele também fornece uma única raiz de confiança nos clusters do GKE.

A Figura 6 mostra uma arquitetura que usa o Cloud Service Mesh para gerenciar identidade e autorização.

Os serviços na malha podem acessar os serviços do Google Cloud usando a federação de Identidade da carga de trabalho. Esse recurso permite que os serviços atuem com a autoridade de uma conta de serviço do Google quando invocam as APIs do Google Cloud. A federação de Identidade da carga de trabalho também permite que a malha de serviço instalada em outros provedores de nuvem acesse as APIs do Google Cloud.

Malha de serviço de confiança zero implantada em nuvens.

Figura 6. Malha de serviço de confiança zero implantada em nuvens.

É possível usar o Cloud Service Mesh para rotear o tráfego da malha para ambientes para qualquer outra nuvem.

Por exemplo, é possível criar serviços no Cloud Service Mesh chamados on-prem-service e other-cloud-service e adicionar rede de conectividade híbrida grupos de endpoints (NEGs) que têm endpoints 10.1.0.1:80 e 10.2.0.1:80. Depois, o Cloud Service Mesh envia o tráfego para os clientes, que são arquivos secundários da malha. proxies que são executados junto com os aplicativos. Assim, quando seu aplicativo envia uma solicitação para o serviço on-prem-service, o cliente do Cloud Service Mesh inspeciona a solicitação e a direciona para o endpoint 10.0.0.1:80. A Figura 7 ilustra essa configuração.

Tráfego direcionado de uma malha de serviço usando o Cloud Service Mesh.

Figura 7. Tráfego direcionado de uma malha de serviço usando o Cloud Service Mesh.

Você também pode incorporar funcionalidades avançadas, como direcionamento de tráfego baseado em ponderação, como mostrado na figura 8. Esse recurso permite que você ative necessidades empresariais críticas, como a migração para a nuvem. O Cloud Service Mesh serve como plano de controle versátil e globalmente gerenciado para suas malhas de serviço.

Tráfego ponderado direcionado usando o Cloud Service Mesh.

Figura 8. Tráfego ponderado direcionado usando o Cloud Service Mesh.

A seguir