Traffic Director com grupos de endpoints de rede de conectividade híbrida

O Traffic Director é compatível com ambientes que vão além do Google Cloud, incluindo data centers locais e outras nuvens públicas que podem ser alcançadas com o uso da conectividade híbrida.

Configure o Traffic Director para que a malha de serviço possa enviar tráfego a endpoints que estejam fora do Google Cloud. Esses endpoints incluem o seguinte:

  • Balanceadores de carga locais.
  • Aplicativos de servidor em uma instância de máquina virtual (VM) em outra nuvem.
  • Qualquer outro destino com acesso por meio da conectividade híbrida e com um endereço IP e uma porta.

Basta adicionar o endereço IP e a porta de cada endpoint a um grupo de endpoints de rede (NEG, na sigla em inglês) de conectividade híbrida. Os NEGs de conectividade híbrida são do tipo NON_GCP_PRIVATE_IP_PORT.

O suporte do Traffic Director para serviços locais e de várias nuvens permite fazer o seguinte:

  • Rotear o tráfego globalmente, incluindo os endpoints de serviços locais e de várias nuvens.
  • Levar os benefícios do Traffic Director e da malha de serviço, incluindo recursos como descoberta de serviços e gerenciamento avançado de tráfego, aos serviços em execução na infraestrutura atual fora do Google Cloud.
  • Combine os recursos do Traffic Director com o Cloud Load Balancing para levar os serviços de rede do Google Cloud a vários ambientes.

Os NEGs de conectividade híbrida (NEGs NON_GCP_PRIVATE_IP_PORT) não são compatíveis com clientes gRPC sem proxy.

Casos de uso

O Traffic Director pode configurar redes em serviços baseados em VM e em contêineres em vários ambientes, incluindo:

  • Google Cloud
  • Data centers locais.
  • Outras nuvens públicas

Rotear o tráfego da malha para um local ou outra nuvem

O caso de uso mais simples deste recurso é o roteamento de tráfego. Seu aplicativo está executando um proxy Envoy do Traffic Director. O Traffic Director informa o cliente sobre seus serviços e os endpoints de cada serviço.

Como rotear o tráfego da malha para um local ou outra nuvem.
Como rotear o tráfego da malha para um local ou outra nuvem (clique para ampliar)

No diagrama anterior, quando seu aplicativo envia uma solicitação para o serviço on-prem, o cliente do Traffic Director inspeciona a solicitação de saída e atualiza o destino dela. O destino é definido como um endpoint associado ao serviço on-prem (neste caso, 10.2.0.1). A solicitação passa pelo Cloud VPN ou pelo Cloud Interconnect em direção ao destino pretendido.

Caso precise adicionar mais endpoints, atualize o Traffic Director para adicioná-los ao serviço. Não é necessário alterar o código do aplicativo.

Migrar um serviço local atual para o Google Cloud

O envio de tráfego para um endpoint que não seja do Google Cloud permite rotear o tráfego para outros ambientes. É possível combinar esse recurso com o gerenciamento de tráfego avançado para migrar serviços entre ambientes.

Como migrar de um local para o Google Cloud.
Como migrar de um local para o Google Cloud (clique para ampliar)

O diagrama anterior estende o padrão anterior. Em vez de configurar o Traffic Director para enviar todo o tráfego ao serviço on-prem, configure-o para usar a divisão de tráfego baseada no peso para dividir o tráfego em dois serviços.

A divisão de tráfego permite que você comece enviando 0% para o serviço cloud e 100% para o serviço on-prem. Em seguida, é possível aumentar gradualmente a proporção do tráfego enviado para o serviço cloud. Ao final, você terá enviado 100% do tráfego para o serviço cloud e poderá desativar o serviço on-prem.

Serviços do Edge de rede do Google Cloud para implantações no local e em várias nuvens

Por fim, é possível combinar essa funcionalidade com as soluções de rede atuais do Google Cloud. O Google Cloud oferece uma ampla variedade de serviços de rede, como o balanceamento de carga externo global com o Google Cloud Armor para proteção contra ataque distribuído de negação de serviço (DDoS, na sigla em inglês), que pode ser usado com o Traffic Director para trazer novos recursos aos serviços locais ou com várias nuvens. O melhor de tudo é que você não precisa expor esses serviços no local ou em várias nuvens à Internet pública.

Implantações que abrangem vários ambientes.
Implantações abrangendo vários ambientes (clique para ampliar)

No diagrama anterior, o tráfego de clientes na Internet pública entra na rede do Google Cloud de um balanceador de carga do Google Cloud, como nosso balanceador de carga de aplicativo externo global. Quando o tráfego chega ao balanceador de carga, é possível aplicar serviços de borda de rede, como a proteção contra DDoS do Google Cloud Armor ou a autenticação do usuário do Identity-Aware Proxy (IAP). Para mais informações, consulte Serviços de borda de rede para implantações em vários ambientes.

Depois de aplicar esses serviços, o tráfego faz uma breve parada no Google Cloud, em que um aplicativo ou proxy independente (configurado pelo Traffic Director) encaminha o tráfego pelo Cloud VPN ou Cloud Interconnect para seus serviços locais.

Recursos e arquitetura do Google Cloud

Nesta seção, apresentamos informações básicas sobre os recursos do Google Cloud que podem ser usados para fornecer a malha de serviço gerenciada pelo Traffic Director a ambientes locais e de várias nuvens.

No diagrama a seguir, veja os recursos do Google Cloud que possibilitam o suporte local e em várias nuvens para o Traffic Director. O principal recurso é o NEG e os endpoints da rede dele. Os outros recursos são aqueles configurados como parte de uma configuração padrão do Traffic Director. Para simplificar, o diagrama não mostra opções como vários serviços de back-end globais.

Recursos do Compute Engine para serviços locais e em várias nuvens.
Recursos do Compute Engine para serviços locais e com várias nuvens (clique para ampliar)

Ao configurar o Traffic Director, você usa o recurso da API de serviços de back-end globais para criar serviços. Um serviço é uma construção lógica com a seguinte combinação:

  1. Políticas a serem aplicadas quando um cliente tenta enviar tráfego para o serviço.
  2. Um ou mais back-ends ou endpoints que processam o tráfego destinado ao serviço.

Serviços locais e em várias nuvens são como qualquer outro serviço que o Traffic Director configura. A principal diferença é que você usa um NEG de conectividade híbrida para configurar os endpoints desses serviços. Esses NEGs têm o tipo de endpoint da rede definido como NON_GCP_PRIVATE_IP_PORT. Os endpoints adicionados a NEGs de conectividade híbrida precisam ser combinações IP:port válidas que seus clientes podem alcançar, por exemplo, por meio de conectividade híbrida, como o Cloud VPN ou o Cloud Interconnect.

Cada NEG tem um tipo de endpoint de rede e só pode conter endpoints de rede do mesmo tipo. Esse tipo determina o seguinte:

  • O destino a que seus serviços podem enviar tráfego.
  • Comportamento de verificação de integridade.

Ao criar o NEG, configure-o da seguinte maneira para que seja possível enviar tráfego a um destino local ou de várias nuvens.

  • Defina o tipo de endpoint da rede como NON_GCP_PRIVATE_IP_PORT. Isso representa um endereço IP acessível. Se esse endereço IP for local ou em outro provedor de nuvem, será preciso que ele possa ser acessado pelo Google Cloud usando conectividade híbrida, como a conectividade fornecida pelo Cloud VPN ou pelo Cloud Interconnect.
  • Especifique uma zona do Google Cloud que minimize a distância geográfica entre o Google Cloud e seu ambiente local ou de várias nuvens. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, será possível especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

O comportamento de verificação de integridade para endpoints da rede desse tipo é diferente do comportamento de outros tipos de endpoints de rede. Enquanto outros tipos de endpoints de rede usam o sistema de verificação de integridade centralizado do Google Cloud, os endpoints de rede NON_GCP_PRIVATE_IP_PORT usam o mecanismo de verificação de integridade distribuída do Envoy. Para mais detalhes, consulte a seção Limitações e outras considerações.

Considerações sobre conectividade e rede

Seus clientes do Traffic Director, como os proxies do Envoy, precisam estar conectados ao Traffic Director em trafficdirector.googleapis.com:443. Se você perder a conectividade com o plano de controle do Traffic Director, acontecerá o seguinte:

  • Os clientes atuais do Traffic Director não podem receber atualizações de configuração do Traffic Director. A empresa continua a operar com base na configuração atual.
  • Não será possível conectar novos clientes do Traffic Director. Eles não poderão usar a malha de serviço até que a conectividade seja restabelecida.

Se você quiser enviar tráfego entre o Google Cloud e os ambientes locais ou de várias nuvens, será preciso que eles estejam conectados por meio da conectividade híbrida. Recomendamos uma conexão de alta disponibilidade, ativada pelo Cloud VPN ou pelo Cloud Interconnect.

Os endereços IP locais, de outra nuvem e de sub-rede do Google Cloud e os intervalos de endereços IP não devem se sobrepor.

Limitações e outras considerações

Veja a seguir as limitações do uso de NEGs de conectividade híbrida.

Como definir proxyBind

Só é possível definir o valor de proxyBind quando você cria um targetHttpProxy. Não é possível atualizar um targetHttpProxy existente.

Conectividade e interrupção na conectividade

Para detalhes sobre os requisitos e limitações de conectividade, consulte a seção Considerações sobre conectividade e rede.

Tipos de back-end mistos

Um serviço de back-end pode ter back-ends de VM ou NEG. Se um serviço de back-end tiver back-ends de NEG, todos eles precisarão conter o mesmo tipo de endpoint da rede. Não é possível ter um serviço de back-end com vários NEGs, cada um com diferentes tipos de endpoint.

Um mapa de URL pode ter regras de host que são resolvidas para serviços de back-end diferentes. É possível ter um serviço de back-end somente com NEGs de conectividade híbrida (com endpoints locais) e um serviço de back-end com NEGs independentes (com endpoints do GKE). O mapa de URL pode conter regras, por exemplo, divisão de tráfego baseada em peso, que divide o tráfego em cada um desses serviços de back-end.

Como usar um NEG com endpoints do tipo NON_GCP_PRIVATE_IP_PORT com back-ends do Google Cloud

É possível criar um serviço de back-end com um NEG de conectividade híbrida que aponta para back-ends no Google Cloud. No entanto, não recomendamos esse padrão porque os NEGs de conectividade híbrida não se beneficiam da verificação de integridade centralizada. Para uma explicação sobre a verificação de integridade centralizada e a verificação de integridade distribuída, consulte a seção Verificação de integridade.

Registro do endpoint

Se você quiser adicionar um endpoint a um NEG, será necessário atualizar o NEG. Isso pode ser feito manualmente ou pode ser automatizado usando as APIs NEG REST do Google Cloud ou a CLI do Google Cloud.

Quando uma nova instância de um serviço é iniciada, é possível usar as APIs do Google Cloud para registrar a instância com o NEG configurado. Ao usar grupos de instâncias gerenciadas do Compute Engine (MIGs) ou GKE (no Google Cloud), o controlador de MIG ou NEG processa automaticamente o registro de endpoints, respectivamente.

Verificação de integridade

Quando você usa NEGs de conectividade híbrida, o comportamento da verificação de integridade é diferente do comportamento padrão de verificação de integridade centralizada das seguintes maneiras:

  • Para endpoints de rede do tipo NON_GCP_PRIVATE_IP_PORT, o Traffic Director configura os clientes dele para usar o plano de dados no processo de verificação de integridade. Para evitar o envio de solicitações para back-ends não íntegros, as instâncias do Envoy executam as próprias verificações de integridade e usam os próprios mecanismos.
  • Como o plano de dados gerencia as verificações de integridade, não é possível usar o Console do Google Cloud, a API ou a Google Cloud CLI para recuperar o status da verificação de integridade.

Na prática, usar NON_GCP_PRIVATE_IP_PORT significa o seguinte:

  • Uma vez que os clientes do Traffic Director processam a verificação de integridade de maneira distribuída, é possível ver um aumento no tráfego de rede devido à verificação de integridade. O aumento depende do número de clientes do Traffic Director e do número de endpoints necessário a cada cliente para que seja feita a verificação de integridade. Por exemplo:
    • Quando você adiciona outro endpoint a um NEG de conectividade híbrida, os clientes do Traffic Director podem começar a verificar a integridade dos endpoints em NEGs de conectividade híbrida.
    • Quando você adiciona outra instância à malha de serviço, como uma instância de VM que executa o código do aplicativo e um cliente Traffic Director, a nova instância pode começar a verificar a integridade dos endpoints em NEGs de conectividade híbrida.
    • Por causa das verificações de integridade, o tráfego de rede aumenta a uma taxa quadrática (O(n^2)).

Rede VPC

Uma malha de serviço é identificada pelo respectivo nome de rede de nuvem privada virtual (VPC). Os clientes do Traffic Director recebem a configuração do Traffic Director com base na rede VPC especificada na configuração de bootstrap. Consequentemente, mesmo que sua malha esteja completamente fora de um data center do Google Cloud, você precisa fornecer um nome de rede VPC válido na sua configuração de inicialização.

Conta de serviço

No Google Cloud, o bootstrap padrão do Envoy é configurado para ler informações da conta de serviço de um dos ambientes de implantação do Compute Engine e do GKE. Ao executar fora do Google Cloud, você precisa especificar explicitamente uma conta de serviço, um nome de rede e um número de projeto em sua inicialização do Envoy. Esta conta de serviço precisa ter permissões suficientes para se conectar à API Traffic Director.

A seguir