Neste documento, descrevemos como combinar vários balanceadores de carga regionais com as políticas de roteamento de DNS do Google para criar arquiteturas globais de balanceamento de carga. Ele é destinado a engenheiros de rede, arquitetos de soluções e profissionais de operações. Ele pressupõe que você tenha conhecimentos básicos do Google Compute Engine e esteja familiarizado com conceitos de rede, como balanceadores de carga e buscas DNS.
Introdução
Ao criar um serviço global que é implementado como um aplicativo em execução em várias regiões, é possível usar políticas de roteamento de DNS de geolocalização para ter um endpoint de DNS global para sua balanceadores de carga Nessa abordagem, você cria um endpoint global que encaminha o tráfego para o serviço local mais próximo.
Dependendo do tipo de balanceador de carga que você está usando, é possível conseguir esse cenário com opções globais de balanceamento de carga baseadas em proxy. No entanto, em alguns casos de uso, você precisará usar produtos de balanceamento de carga regionais, por exemplo, se o serviço estiver exibindo tráfego UDP. As políticas de roteamento de DNS de geolocalização também podem ajudar a fornecer um único endpoint de DNS para aplicativos híbridos que usam o Google Cloud com outros provedores de serviços de nuvem ou com uma implantação no local.
Arquitetura
O diagrama a seguir mostra uma arquitetura de amostra que usa três balanceadores de carga regionais em três regiões diferentes. As regiões são combinadas usando políticas de roteamento de DNS.
O diagrama anterior mostra como os clientes no Oregon, na Alemanha e em Singapura fazem buscas
DNS no Cloud DNS para www.example.com. As solicitações são encaminhadas
para balanceadores de carga regionais próximos a cada cliente para
alcançar um aplicativo hospedado em três regiões diferentes.
Casos de uso para políticas de roteamento de DNS de geolocalização
Nesta seção, discutiremos os seguintes casos de uso para usar políticas de roteamento de DNS de geolocalização para criar um serviço global a partir de vários balanceadores de carga regionais:
- Um serviço interno de acesso e distribuição global
- Um endpoint DNS global para um serviço externo compatível com TCP e UDP
- Um endpoint DNS global para um serviço híbrido
Um serviço interno de acesso e distribuição global
É possível criar um serviço interno globalmente acessível e distribuído globalmente combinando vários balanceadores de carga internos regionais usando políticas de roteamento de DNS de geolocalização. É possível usar um balanceador de carga de rede de passagem interna ou um balanceador de carga de aplicativo interno. Sem as políticas de roteamento de DNS, um balanceador de carga interno do aplicativo só pode usar endpoints regionais. Com um balanceador de carga de rede de passagem interno que usa acesso global, o serviço pode ser disponibilizado em todo o mundo. Nesse caso, os back-ends podem estar apenas em uma única região. No entanto, ao usar políticas de roteamento de DNS, é possível ter back-ends em várias regiões.
O diagrama a seguir mostra essa arquitetura:
O diagrama anterior mostra como os clientes internos em várias regiões resolvem
service.corp.example.com usando o Cloud DNS. Os clientes sempre recebem uma
resposta com um endereço IP que pertence a um balanceador de carga de rede de passagem interno na
região do cliente. O balanceador de carga aponta para um aplicativo que está na
mesma região. Neste exemplo, o aplicativo é executado no Google Kubernetes Engine (GKE),
mas essa não é uma condição necessária. Os clientes enviam
o tráfego do aplicativo para uma instância local do aplicativo, mas todos usam o
mesmo endpoint DNS service.corp.example.com.
É possível criar essa configuração seguindo estas etapas:
- Crie os balanceadores de carga internos em cada região. Se você usar um balanceador de carga de rede de passagem interna, será necessário ativar o acesso global para garantir que os clientes de outras regiões possam se conectar ao serviço.
Crie uma política de roteamento de DNS. Na política, defina o tipo como
GEOe defina o valor--routing-policy-datacomo uma lista de regiões de destino mapeadas para o balanceador de carga interno correspondente. É possível criar a configuração ilustrada no diagrama usando o seguinte comando:gcloud beta dns record-sets create service.corp.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \ --enable-health-checking
No exemplo, um registro é criado com um valor de TTL de 30 segundos para garantir que os clientes atualizem os registros DNS com frequência caso a política seja alterada.
Quando você usa políticas de roteamento de DNS, cada cliente recebe uma resposta DNS que contém o endereço IP do balanceador de carga interno na região. Se o cliente estiver fora de uma região em que os balanceadores de carga internos estão definidos, ele receberá o endereço IP do balanceador de carga interno que está na região mais próxima.
As políticas de roteamento de DNS encaminham o tráfego com base na região do balanceador de carga interno mais próximo. Se mais de 80% dos back-ends nessa região não forem íntegros e você estiver usando o recurso de verificação de integridade com políticas de roteamento de DNS geográfico, o tráfego fará failover entre regiões.
Se você não precisar de failover entre regiões, altere o comando da seguinte maneira:
- Remova a sinalização
--enable-health-checking. - Substitua o nome de cada regra de encaminhamento do balanceador de carga interno pelo endereço IP.
Um endpoint global para um serviço externo compatível com TCP e UDP
Também é possível criar um endpoint de DNS global para um serviço externo combinando vários balanceadores de carga externos regionais usando políticas de roteamento de DNS de geolocalização. O caso de uso mais comum é usar um balanceador de carga de rede de passagem externa para qualquer aplicativo baseado em TCP ou UDP. Essa abordagem é útil principalmente para aplicativos que usam UDP, porque nenhuma opção de balanceamento de carga global está disponível no Google Cloud para UDP.
Para aplicativos que usam tráfego TCP que é suportado pelo balanceador de carga de rede proxy externo ou pelo balanceador de carga de aplicativo externo, use instâncias desses balanceadores de carga globais em vez de usar um endpoint DNS. Esses balanceadores fornecem balanceamento de carga entre regiões usando anycast, que fornece um único endereço IP como front-end para todas as instâncias de back-end.
As vantagens de usar opções de balanceamento de carga global no endpoint do DNS são as seguintes:
- O failover é imediato. O failover ocorre sem alterações visíveis no fluxo de tráfego do lado do usuário.
- O roteamento da Internet determina o destino do balanceamento de carga. Os protocolos de roteamento da Internet encaminham o tráfego com base no caminho mais curto, em vez do Cloud DNS escolher um local de destino.
- Balanceamento de carga entre regiões: O balanceamento de carga global do Google é compatível com failover entre regiões. Por outro lado, não há verificação de integridade com políticas de roteamento de DNS quando você usa um balanceador de carga de rede de passagem externa.
Portanto, recomendamos que você use a opção de balanceamento de carga global do Google quando seu aplicativo for baseado em TCP e for compatível com esses produtos.
O diagrama a seguir mostra a arquitetura usando um endpoint DNS global:
O diagrama anterior mostra como clientes externos em várias regiões resolvem
www.example.com usando o Cloud DNS. Os clientes recebem uma resposta com um endereço
IP que pertence a um balanceador de carga TCP/UDP de rede na região
do cliente. O cliente pode se conectar a um aplicativo em execução nessa
mesma região. Cada cliente envia tráfego de aplicativo para uma instância local do
serviço, mas todos usam o mesmo endpoint DNS www.example.com.
É possível criar essa configuração seguindo estas etapas:
- Crie os balanceadores de carga TCP/UDP de rede em cada região.
Crie uma política de roteamento de DNS. Na política, defina o tipo como
GEOe o valor--routing-policy-datacomo uma lista de regiões de destino que são mapeadas para o balanceador de carga TCP/UDP de rede correspondente. É possível criar a configuração ilustrada no diagrama usando o seguinte comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Depois de aplicar essa política, quando os clientes fazem solicitações DNS, cada cliente recebe uma resposta DNS com o endereço IP do balanceador de carga da rede de passagem externa que está na região mais próxima desse cliente.
O endpoint global www.example.com não pode ser usado para executar automaticamente
o failover do tráfego entre regiões, porque quando você usa um balanceamento de carga de rede de passagem externa,
não há verificação de integridade. É sua
responsabilidade acionar manualmente o failover alterando os registros DNS.
Outro caso de uso que pode ser usado com essa abordagem é que você tem um aplicativo usando HTTP(S) com requisitos de região para os dados, mas ainda quer exibir dados usando um endpoint global. É possível implementar esse cenário combinando várias instâncias de balanceador de carga de aplicativo externo regional usando políticas de roteamento de DNS de geolocalização. Se você não tiver requisitos de regionalidade, use um balanceador de carga de aplicativo externo global.
Um endpoint DNS global para um serviço híbrido
Em alguns casos, é possível fornecer um único endpoint para um aplicativo híbrido usando políticas de roteamento de DNS de geolocalização.
O diagrama a seguir mostra essa arquitetura:
O diagrama anterior mostra como clientes externos em várias regiões resolvem
www.example.com usando o Cloud DNS. O Cloud DNS aponta usuários
da Internet na Ásia e nos EUA para um endereço IP que pertence a um balanceador de carga TCP/UDP
de rede que está em uma região próxima a eles. O aplicativo para o qual o balanceador de carga
aponta está sendo executado no GKE na mesma região. Para usuários da Internet na Europa, o Cloud DNS retorna um endereço IP que aponta para um balanceador de carga em um data center local europeu, com o aplicativo hospedado no GKE no VMware. Neste exemplo, os aplicativos são executados no GKE no VMware e no GKE, mas essa não é uma condição necessária.
É possível criar essa configuração seguindo estas etapas:
- Crie os balanceadores de carga TCP/UDP de rede e o balanceador de carga local em cada região.
Crie uma política de roteamento de DNS. Na política, defina o tipo como
GEOe o valor--routing-policy-datacomo uma lista de regiões de destino que são mapeadas para o balanceador de carga TCP/UDP de rede correspondente. É possível criar a configuração ilustrada no diagrama usando o seguinte comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Ao definir a sinalização --routing-policy-data, é possível fazer com que o Cloud
DNS retorne diferentes endereços IP com base na região mais próxima do Google Cloud.
No entanto, não é possível rotear o tráfego com base no país ou na região
geográfica exata do cliente. No exemplo anterior, a maioria dos usuários é enviada para uma
região ou para o data center local que está no continente deles. No entanto, o
algoritmo que o Cloud DNS usa para determinar a região
mais próxima do Google Cloud pode não estar alinhado a limites de país ou
geografia específicos. Portanto, não é possível usar políticas de roteamento de DNS de geolocalização
para casos de uso de conformidade.
Outros casos de uso que exigem mais granularidade do que a granularidade no nível do continente mostrada neste exemplo não são possíveis com essa abordagem híbrida. Por exemplo, nos casos em que você tem um data center local em um país onde não há nenhuma região do Google Cloud, não é possível enviar tráfego no local para usuários desse país ou região. Só é possível configurar o balanceador de carga para retornar endereços IP com base na região mais próxima do Google Cloud. Se você quiser restringir ou rotear o tráfego com base em local geográfico ou país exato, use um provedor de terceiros que ofereça um serviço de balanceamento de carga de servidor global (GSLB, na sigla em inglês) baseado em DNS.
A seguir
- Gerenciar políticas de roteamento DNS.
- Práticas recomendadas de DNS.
- Recursos do balanceador de carga.
- Como otimizar a latência do aplicativo com balanceamento de carga
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.