Traffic Director para implantações de vários ambientes

O Traffic Director é compatível com ambientes que se estendem além do Google Cloud, incluindo data centers locais e outras nuvens públicas acessíveis usando 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 podem ser balanceadores de carga locais, aplicativos de servidor em uma máquina virtual em outra nuvem ou qualquer outro destino acessível usando conectividade híbrida e podem ser representados por 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.

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

  • Rotear o tráfego globalmente, incluindo os endpoints de serviços locais e de várias nuvens.
  • Leve 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.

Casos de uso

O Traffic Director pode configurar redes em serviços baseados em VM e 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 cliente do Traffic Director (proxy Envoy ou gRPC sem gRPC). O Traffic Director informa o cliente sobre seus serviços e os endpoints de cada serviço.

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

No diagrama acima, 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. 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 para o destino pretendido.

Se você precisar adicionar mais endpoints, basta adicioná-los ao serviço atualizando o Traffic Director. Não será necessário fazer nenhuma alteração no 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 e outros casos de uso.

Como migrar de um local para o Google Cloud (clique para ampliar)
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 dividir o tráfego em dois serviços usando a divisão de tráfego baseada em peso.

A divisão de tráfego permite que você comece enviando 0% do tráfegor 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. Em algum momento, você enviará 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 balanceamento de carga externo global com o Google Cloud Armor para proteção contra DDoS, que agora podem ser usados em conjunto com o Traffic Director para disponibilizar novos recursos para seu serviços locais ou em 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 (clique para ampliar)
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 HTTP(S) externo global. É possível aplicar serviços de borda de rede, por exemplo, proteção contra DDoS do Google Cloud Armor ou a autenticação de usuário do Identity-Aware Proxy quando o tráfego chega ao balanceador de carga. 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 fará uma breve parada no Google Cloud, onde um aplicativo ou proxy autônomo (configurado pelo Traffic Director) encaminha o tráfego pelo Cloud VPN ou Cloud Interconnect para seu serviço local.

Arquitetura e recursos

Nesta seção, você verá informações básicas sobre os recursos do Google Cloud usados para fornecer uma malha de serviço gerenciada pelo Traffic Director para ambientes locais e de várias nuvens.

Recursos do Google Cloud

No diagrama a seguir, veja os recursos do Google Cloud que permitem o suporte local e em várias nuvens para o Traffic Director. Observe que o recurso de chave é o NEG (e os endpoints da rede dele). Os outros recursos são aqueles que você configuraria como parte da configuração padrão do Traffic Director.

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

Para simplificar, opções como vários serviços de back-end globais não são mostradas no diagrama.

Ao configurar o Traffic Director, você cria serviços usando o recurso da API de serviços de back-end globais. Um serviço é apenas uma construção lógica que combina:

  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 configurado com o Traffic Director. A principal diferença é que você configura os endpoints desses serviços usando um NEG de conectividade híbrida. Eles são NEGs que têm o tipo de endpoint de 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 possam ser acessadas pelos clientes (por exemplo, por meio de conectividade híbrida, como Cloud VPN ou Cloud Interconnect).

O NEG tem um tipo de endpoint de rede, e cada NEG só pode conter endpoints de rede do mesmo tipo. Esse tipo determina:

  • O destino para o qual seus serviços podem enviar tráfego
  • Comportamento de verificação de integridade

Ao criar o NEG, configure-o da seguinte maneira para que ele possa ser enviado 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 estiver em outro provedor de nuvem, ele precisará ser acessível no 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, poderá 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. Consulte Limitações e outras considerações para mais detalhes.

Considerações sobre conectividade e rede

  • Seus clientes do Traffic Director, como proxies Envoy e bibliotecas gRPC sem proxy, precisam ser conectados ao Traffic Director em trafficdirector.googleapis.com:443. Se você perder a conectividade com o plano de controle do Traffic Director:
    • 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 é 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, eles precisam estar conectados por meio da conectividade híbrida. Recomendamos uma conexão de alta disponibilidade ativada pelo Cloud Interconnect ou Cloud VPN.
  • 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

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 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.

Observe que 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 também 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 mais informações sobre a verificação de integridade centralizada e a verificação de integridade distribuída, consulte a 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 REST do grupo de endpoints da rede do Google Cloud ou a ferramenta de linha de comando gcloud. 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 que você configurou. Observe que, ao usar MIGs do Compute Engine ou GKE (no Google Cloud), o registro do endpoint é processado automaticamente pelo controlador do MIG ou NEG, respectivamente.

Verificação de integridade

O comportamento da verificação de integridade é diferente do comportamento de verificação de integridade centralizado padrão quando você usa NEGs de conectividade híbrida:

  • Para endpoints de rede do tipo gce-vm-ip-port, o Traffic Director recebe informações de integridade do endpoint do sistema de verificação de integridade centralizado do Google Cloud. O Traffic Director fornece essas informações aos clientes do Traffic Director, eliminando a necessidade de verificações de integridade potencialmente baseadas em um plano de dados.
  • Para endpoints de rede do tipo non-gcp-private-ip-port, o Traffic Director configura seus clientes para lidar com a verificação de integridade usando o plano de dados. As instâncias do Envoy executam as próprias verificações de integridade e usam os próprios mecanismos para evitar o envio de solicitações para back-ends não íntegros.
  • Como o plano de dados gerencia as verificações de integridade, não é possível recuperar o status da verificação de integridade usando o Console do Google Cloud, a API ou gcloud.

Na prática, usar non-gcp-private-ip-port significa:

  • Somente as verificações de integridade HTTP e TCP são compatíveis.
  • Como 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 que cada cliente precisa para 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 (por exemplo, uma instância de máquina virtual que executa o código do aplicativo e um cliente do 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 de nuvem privada virtual

Uma malha de serviço é identificada exclusivamente pelo nome da rede 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 bootstrap.

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

Para instruções sobre como configurar o Traffic Director para implantações no local e em várias nuvens, consulte Serviços Edge de rede para implantações em vários ambientes (no local, em várias nuvens).