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:
- Como projetar redes para migrar cargas de trabalho empresariais: abordagens de arquitetura
- Rede para acesso intranuvem seguro: arquiteturas de referência
- Rede para entrega de aplicativos voltados à Internet: arquiteturas de referência
- Rede para cargas de trabalho híbridas e em várias nuvens: arquiteturas de referência (este documento)
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.
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.
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.
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.
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 Anthos 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.
Figura 5. Malha de serviço de confiança zero implantada em um ambiente local e no Google Cloud.
As empresas podem usar o Anthos Service Mesh para implantar em nuvens. Para lidar com desafios no gerenciamento de identidade e certificados entre provedores de nuvem, o Anthos 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 Anthos 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 Anthos 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.
Figura 6. Malha de serviço de confiança zero implantada em nuvens.
É possível usar o Traffic Director para encaminhar o tráfego da malha para o local ou para qualquer outra nuvem.
Por exemplo, é possível criar serviços no Traffic Director chamados
on-prem-service e other-cloud-service e adicionar grupos de endpoints de rede de conectividade
híbrida (NEGs, na sigla em inglês) que têm endpoints 10.1.0.1:80 e 10.2.0.1:80.
Depois, o Traffic Director envia o tráfego para os clientes, que são proxies sidecar
de malha executados com seus aplicativos. Assim, quando o aplicativo enviar
uma solicitação para o serviço on-prem-service, o cliente do Traffic Director
inspecionará a solicitação e a encaminhará para o endpoint 10.0.0.1:80. A Figura 7
ilustra essa configuração.
Figura 7. Tráfego direcionado de uma malha de serviço usando o Traffic Director.
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 Traffic Director funciona como um plano de controle versátil e gerenciado globalmente para suas malhas de serviços.
Figura 8. Tráfego ponderado direcionado usando o Traffic Director.
A seguir
- Rede para acesso intranuvem seguro: arquiteturas de referência.
- Rede para entrega de aplicativos voltados à Internet: arquiteturas de referência
- A migração para o Google Cloud pode ajudar você a planejar, projetar e implementar o processo de migração das suas cargas de trabalho para o Google Cloud.
- O design da zona de destino no Google Cloud tem orientações para criar uma rede de zona de destino.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.