Padrões de rede híbrida do Google Cloud - Parte 2

Introdução

As empresas não vão migrar todas as suas cargas de trabalho no local para a nuvem de uma só vez. Faz mais sentido migrar partes de cargas de trabalho de cada vez para a nuvem, sempre que for possível obter o máximo de benefícios da migração para a nuvem. Como tal, continuará a precisar de uma forma de os seus sistemas no local comunicarem com os seus recursos de nuvem recentemente implementados.

Existem vários padrões de rede que podem ser aproveitados para conceber a conetividade híbrida no Google Cloud. A conceção da conetividade híbrida depende de factores como:

• O número de redes VPC utilizadas para as cargas de trabalho
• A necessidade de inspeção do tráfego de nível 7 utilizando dispositivos virtuais de rede (NVA)
• Acesso aos serviços geridos pela Google que utilizam o Acesso aos serviços privados

Esta será uma série de blogues com várias partes, em que abordarei diferentes topologias de rede disponíveis no Google Cloud, que se adequam a vários casos de utilização de conetividade híbrida. Este primeiro blogue centrar-se-á na conetividade híbrida a uma VPC única ou partilhada no Google Cloud. Nos blogues seguintes, abordarei a conetividade híbrida a várias redes VPC (ou VPC partilhada) no Google Cloud e a conetividade híbrida utilizando dispositivos.

Quando existe um grande número de redes VPC de carga de trabalho, poderá ser necessária uma arquitetura hub-and-spoke que suporte um grande número de redes VPC. Isso envolve a conexão de várias redes VPC de carga de trabalho a uma VPC de hub de trânsito que tem conetividade com ambientes locais e outras nuvens. Abordarei o Hub-and-Spoke com emparelhamento VPC para Spokes, Hub-and-Spoke com HA-VPN para Spokes e conetividade híbrida utilizando dispositivos e emparelhamento VPC para Spokes.

 

Conectividade híbrida para VPC única (ou VPC partilhada)

1. Interligação a instalações locais

a) Interligação em nuvem

Configure a Interligação Dedicada ou a Interligação de Parceiro para a nuvem do Google. Ligue-se a dois Edge Availability Domains (EAD) no mesmo Metro para obter um SLA de 99,99%. Pode ligar os seus Cloud Interconnects a várias regiões dentro da mesma VPC partilhada.

2) Anexação de VLAN

Um anexo de VLAN conecta sua interconexão em um ponto de presença (PoP) do Google a um roteador de nuvem em uma região especificada do Google Cloud.

3) Router em nuvem

Um Cloud Router troca rotas dinâmicas (BGP) entre as suas redes VPC e os routers locais. Pode configurar o encaminhamento dinâmico entre os seus routers no local e um Cloud Router numa determinada região. Cada Cloud Router é implementado por duas tarefas de software que fornecem duas interfaces para alta disponibilidade. Configure o roteamento BGP para cada uma das interfaces do Cloud Router.

4) Encaminhamento dinâmico global da VPC

Configurar o encaminhamento dinâmico global na VPC partilhada para permitir a troca de rotas dinâmicas entre todas as regiões.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

2. HA-VPN para o local

1. Nuvem HA-VPN

O gateway Cloud HA-VPN é utilizado para estabelecer túneis IPsec para o gateway VPN no local através da Internet. O HA-VPN oferece um SLA de 99,99%. É possível ter vários túneis HA-VPN em diferentes regiões dentro da VPC compartilhada.

2. Routers na nuvem

Configure o roteamento dinâmico entre os roteadores locais e um Cloud Router em cada região. Cada Cloud Router é implementado por duas tarefas de software que fornecem duas interfaces para alta disponibilidade. Configure o roteamento BGP para cada uma das interfaces do Cloud Router.

3. Encaminhamento dinâmico global da VPC

Configurar o encaminhamento dinâmico global na VPC partilhada para permitir a troca de rotas dinâmicas entre todas as regiões.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3. DNS

Visão geral

Em um ambiente híbrido, a resolução de DNS pode ser feita no Google Cloud ou no local. Vamos considerar um caso de uso de DNS híbrido em que os servidores DNS locais são autoritativos para zonas DNS locais e o Cloud DNS é autoritativo para zonas do Google Cloud.

1) DNS no local

Configure seus servidores DNS locais para serem autoritativos para zonas DNS locais. Configure o encaminhamento de DNS (para nomes DNS do Google Cloud) visando o endereço IP de encaminhamento de entrada do Cloud DNS, que é criado por meio da política de servidor de entrada na VPC compartilhada Prod. Isso permite que a rede local resolva nomes DNS do Google Cloud.

2) VPC partilhada Prod - proxy de saída DNS

Anuncie o intervalo de proxy de saída do Google DNS 35.199.192.0/19 para a rede local através dos routers da nuvem. Os pedidos de DNS de saída do Google Cloud para o local são originados a partir deste intervalo de endereços IP.

3) Projeto de anfitrião de produção - Cloud DNS

• Configurar uma política de servidor de entrada para pedidos de DNS de entrada a partir do local.
• b. Configure uma zona de encaminhamento do Cloud DNS (para nomes DNS locais) visando resolvedores DNS locais.

 

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

4. Private Service Connect (PSC) para APIs do Google (acesso a todas as APIs e serviços suportados)

Visão geral

Pode utilizar o Private Service Connect (PSC) para aceder a todas as APIs e serviços Google suportados a partir de anfitriões do Google Compute Engine (GCE) e anfitriões locais utilizando o endereço IP interno de um ponto de extremidade PSC num VPC partilhado. Consideremos o acesso do PSC a um serviço no Projeto de Serviço 4 através da VPC Partilhada.

Criar um ponto de extremidade PSC

1.  Escolha um endereço de ponto de extremidade PSC (por exemplo, 10.2.2.2) e crie um ponto de extremidade PSC na VPC partilhada Prod com um destino de "all-apis", que dá acesso a todas as APIs e serviços Google suportados. O Diretório de Serviços cria automaticamente um registo DNS (com o nome DNS de p.googleapis.com) associado ao endereço IP do ponto final do PSC.

2) Acesso à API a partir de anfitriões GCE

Os anfitriões GCE podem aceder a todas as APIs e serviços Google suportados através do ponto de extremidade PSC na VPC partilhada Prod.

2. Active o Private Google Access em todas as sub-redes com instâncias de computação que requerem acesso às APIs do Google através do PSC.

3. 3. Se os seus clientes GCE puderem utilizar nomes DNS personalizados (por exemplo, storage-xyz.p.googleapis.com), pode utilizar o nome DNS p.googleapis.com criado automaticamente.

6. Se os seus clientes locais não puderem utilizar nomes DNS personalizados, pode criar registos A que mapeiem os nomes DNS predefinidos (por exemplo, storage.googleapis.com) para o endereço do ponto final do PSC.

 

Acesso a partir de anfitriões no local

Os anfitriões no local podem aceder a todas as APIs e serviços Google suportados através do ponto de extremidade PSC no VPC partilhado Prod.

5. No roteador de nuvem, anuncie o endereço do ponto de extremidade do PSC para a rede local.

6. 5. Se os seus clientes no local puderem utilizar nomes DNS personalizados (por exemplo, storage-xyz.p.googleapis.com), pode criar registos A que mapeiem os nomes DNS personalizados para o endereço do ponto final do PSC.

7. 6. Se os seus clientes locais não puderem utilizar nomes DNS personalizados, pode criar registos A que mapeiem os nomes DNS predefinidos (por exemplo, storage.googleapis.com) para o endereço do ponto final do PSC.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Private Service Connect (PSC) para APIs do Google (acesso a APIs e serviços suportados pelo Controlo de Serviços VPC)

Visão geral

Pode utilizar o Private Service Connect (PSC) para aceder a todas as APIs e serviços Google suportados a partir de anfitriões do Google Compute Engine (GCE) e anfitriões locais utilizando o endereço IP interno de um ponto de extremidade PSC num VPC partilhado. Consideremos o acesso do PSC a um serviço no Projeto de Serviço 4 através da VPC Partilhada.

Criar um ponto de extremidade PSC

1.Escolha um endereço de ponto de extremidade PSC (por exemplo, 10.2.2.2) e crie um ponto de extremidade PSC na VPC partilhada Prod com um destino de "vpc-sc", que dá acesso a APIs e serviços Google suportados pelo Controlo de Serviços VPC. O Diretório de Serviços cria automaticamente um registo DNS (com o nome DNS de p.googleapis.com) associado ao endereço IP do ponto final do PSC.

 

2) Acesso à API a partir de anfitriões GCE

Os anfitriões GCE podem aceder a APIs e serviços Google suportados pelo Controlo de Serviços VPC através do ponto de extremidade PSC na VPC partilhada Prod.

2. 2. Active o Private Google Access em todas as sub-redes com instâncias de computação que requerem acesso às APIs do Google através do PSC.

3. Se os seus clientes GCE puderem utilizar nomes DNS personalizados (por exemplo, storage-xyz.p.googleapis.com), pode utilizar o nome DNS p.googleapis.com criado automaticamente.

4. 4. Se os seus clientes GCE não puderem utilizar nomes DNS personalizados, pode criar registos Cloud DNS utilizando os nomes DNS predefinidos (por exemplo, storage.googleapis.com).

Acesso a partir de anfitriões no local

Os anfitriões no local podem aceder a todas as APIs e serviços seguros do Google através do ponto de extremidade PSC na VPC partilhada Prod.

5. No roteador de nuvem, anuncie o endereço do ponto de extremidade do PSC para a rede local.

6. 5. Se os seus clientes no local puderem utilizar nomes DNS personalizados (por exemplo, storage-xyz.p.googleapis.com), pode criar registos A que mapeiem os nomes DNS personalizados para o endereço do ponto final do PSC.

7. 6. Se os seus clientes locais não puderem utilizar nomes DNS personalizados, pode criar registos A que mapeiem os nomes DNS predefinidos (por exemplo, storage.googleapis.com) para o endereço do ponto final do PSC.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

6. Controlo do serviço VPC

Visão geral

O Controlo de Serviços VPC utiliza regras de entrada e saída para controlar o acesso de e para um perímetro. As regras especificam a direção do acesso permitido de e para diferentes identidades e recursos.

Vamos considerar um caso de utilização específico em que é necessário o acesso a um serviço protegido no Projeto de Serviço 4 através da VPC partilhada Prod. Segue-se uma descrição das acções do Controlo de Serviços VPC para este cenário.

1. Perímetro - projeto de serviço

O perímetro contém um projeto de serviço (Projeto de serviço 4) e inclui APIs e serviços do Google a serem protegidos no projeto de serviço.

2. 2) Acesso à API a partir de anfitriões GCE

Uma instância GCE pode aceder a APIs seguras através de um ponto de extremidade PSC na VPC partilhada. Considerando o perímetro à volta do Projeto de Serviço 4, a interface de rede da instância de computação GCE-4 está na VPC partilhada Prod do projeto anfitrião Prod. As chamadas de API da instância GCE-4 para um serviço (por exemplo, storage.googleapis.com) no Projeto de Serviço 4 parecem ter origem no projeto anfitrião Prod, onde a interface da instância e o ponto final PSC estão localizados.

3.3) Regra de entrada - Projeto de anfitrião Prod no perímetro

Configure uma regra de entrada que permita chamadas de API do Google do projeto de anfitrião Prod para os serviços protegidos dentro do perímetro do Projeto de Serviço 4. Esta regra permite chamadas API das instâncias GCE (por exemplo, GCE-4) para o perímetro.

Eis uma configuração pormenorizada:

1. Aceder à política de firewall de perímetro:

• Navegue até o Projeto de serviço 4 no Console do Google Cloud.
• Aceda a Rede VPC > Políticas de firewall.
• Clique na política de firewall predefinida.

2. Criar uma nova regra de entrada:

• Clique no botão Adicionar regra.
• Definir a ação para Permitir.
• Selecione TCP como protocolo.
• Para a Fonte, selecione o intervalo de IP.
• Introduza o intervalo de IP das suas instâncias GCE em Host Project. Pode encontrar esta informação nos detalhes da instância GCE. Por exemplo, se o intervalo de IP for 10.0.0.0/8, introduza-o aqui.
• Para o Destino, selecione Intervalo de IP e introduza o intervalo de IP dos serviços protegidos no Projeto de Serviço 4. Este pode ser o intervalo de IP interno da sua rede VPC ou endereços IP específicos dos serviços.
• Na secção Destino, selecione Todos.
• Para a Prioridade, escolha um valor adequado (por exemplo, 1000).
• Clique em Adicionar regra.

3. Verificar a regra:

• Assim que a regra for criada, verifique os seus detalhes para garantir que está corretamente configurada.
• Teste a regra fazendo uma chamada de API de uma instância GCE no Projeto Anfitrião para um serviço protegido no Projeto Serviço 4.
• Considerações adicionais:
• Se tiver várias instâncias GCE ou quiser permitir tráfego de sub-redes específicas, ajuste o intervalo de IP de origem em conformidade.
• Para um controlo mais granular, considere a utilização de etiquetas de origem ou regras de firewall baseadas em portas ou protocolos específicos.
• Se precisar de permitir o tráfego de outros projectos ou endereços IP externos, modifique a fonte em conformidade.

4. Acesso a partir de anfitriões no local

4) Acesso à API para anfitriões no local Os anfitriões no local podem aceder a APIs seguras no Projeto de Serviço 4 através do ponto final PSC na VPC partilhada Prod. As chamadas de API do local para os serviços no Projeto de Serviço 4 parecem ter origem no projeto de anfitrião Prod, onde a Interligação (ou VPN) e o ponto final PSC estão localizados. A regra de entrada (mencionada no passo 3) permite chamadas de API do local para o perímetro do Projeto de Serviço 4 através do projeto de anfitrião Prod. O diagrama abaixo é um exemplo.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

 

À medida que as empresas migram cargas de trabalho para a nuvem, elas devem entender os vários padrões de rede híbrida para garantir a conetividade perfeita entre ambientes locais e de nuvem. Este blogue descreve as principais configurações que o ajudarão a atingir este objetivo. Em publicações futuras, iremos aprofundar os padrões avançados para o ajudar a otimizar a sua estratégia de nuvem híbrida no Google Cloud. Fique atento à próxima parte, pois exploraremos soluções de conetividade baseadas em appliance e multi-VPC.