O que é balanceamento global de carga de servidores?

O balanceamento global de carga de servidores direciona clientes entre endpoints em diferentes regiões geográficas. As decisões podem levar em conta a integridade dos endpoints, a latência, a capacidade, as políticas ou a localização do usuário.

Como funciona o balanceamento global de carga de servidores

Balanceamento global de carga de servidores (GSLB) é um termo usado por fornecedores, e não um protocolo. A RFC 3568 descreve a mesma função como roteamento de requisições e classifica os mecanismos conhecidos em técnicas de DNS, de camada de transporte e de camada de aplicação. A forma baseada em DNS é comum porque todo cliente já faz resolução de nomes: um servidor de nomes autoritativo responde ao mesmo nome com endereços diferentes de acordo com políticas, medições ou ambos, e o endereço retornado costuma ser um IP virtual à frente de um grupo regional que faz seu próprio balanceamento local de carga. As outras formas atuam depois. O anycast anuncia um endereço a partir de várias localidades e deixa a escolha da localidade para o roteamento de rede. Um balanceador de camada de aplicação redireciona o cliente, por exemplo, com uma resposta HTTP 302, ou atua como proxy das requisições e escolhe uma região para cada uma. Os balanceadores baseados em DNS e os de camada de aplicação podem ponderar proximidade de rede ou latência, carga e capacidade, resultados de verificações de integridade e regras como geografia ou pesos. Por si só, o anycast segue apenas o roteamento de rede: a RFC 3568 observa que os protocolos de roteamento geralmente não levam a carga em conta e que a carga do servidor não é considerada, e uma localidade continua recebendo tráfego enquanto sua rota estiver sendo anunciada, motivo pelo qual a RFC 4786 considera desejável vincular o anúncio à disponibilidade do serviço.

Informações essenciais

  1. Com que rapidez o GSLB baseado em DNS desvia o tráfego de uma região com falha? Gradualmente, não de uma só vez. A detecção vem primeiro e depende do intervalo entre as verificações e de quantas verificações consecutivas malsucedidas o balanceador exige (o Route 53 chama isso de limiar de falha). Depois que a resposta autoritativa muda, as consultas que não são atendidas pelo cache recebem a nova resposta, enquanto um resolvedor que armazenou a resposta antiga em cache pode continuar usando essa resposta pelo restante do TTL. A nova resposta indica uma região que passa nas verificações, se houver alguma; quando nenhuma passa, aplica-se a regra de fallback do balanceador, e o Route 53, por exemplo, retorna o registro primário quando os dois registros de um par de failover não estão íntegros. O TTL é o tempo durante o qual um resolvedor pode usar uma resposta em cache antes de precisar consultar novamente, e o balanceador não pode revogar uma resposta que já forneceu. Um TTL mais curto reduz essa janela e aumenta o volume de consultas aos servidores DNS. Uma resposta ainda pode continuar em uso após o TTL: a RFC 3568 observa que muitas implementações de DNS não respeitam o TTL, e a RFC 8767 permite que um resolvedor continue fornecendo uma resposta expirada quando a tentativa de atualizá-la falha. O projeto k8gb relata um tempo de indisponibilidade aproximadamente igual ao TTL do DNS quando um serviço por trás de seu GSLB falha; essa é a observação de um projeto, não um limite máximo. Alterar a resposta DNS também não transfere conexões que já estão abertas: na documentação de seu failover entre regiões baseado em DNS, a AWS observa que as conexões existentes levam tempo para terminar, dependendo do comportamento do cliente e da reutilização das conexões. A Cloudflare lista o failover mais lento como uma limitação de seu balanceamento de carga somente por DNS em comparação com o modo com proxy.
  2. De quem é a localização usada em uma decisão baseada em DNS? Do resolvedor recursivo, a menos que ele envie a opção EDNS Client Subnet. O Amazon Route 53 documenta os dois casos: usa o endereço IP de origem do resolvedor quando ele não oferece suporte à opção e uma forma abreviada do endereço do usuário quando oferece. A RFC 7871, que descreve a opção, recomenda que ela fique desativada por padrão por motivos de privacidade. Já um balanceador que atua como proxy determina a localização do cliente a partir da conexão do próprio cliente.
  3. O que uma verificação de integridade bem-sucedida comprova? Apenas o que a verificação solicita. No Route 53, uma verificação de integridade TCP é bem-sucedida assim que uma conexão é estabelecida, uma verificação HTTP ou HTTPS exige um código de status 2xx ou 3xx, e uma verificação por correspondência de texto também exige um texto específico no corpo da resposta; as verificações HTTPS do serviço não validam o certificado. Uma região cujo front-end aceita conexões enquanto a aplicação por trás dele falha passa em uma verificação TCP. Apontar a verificação para uma URL que aciona as dependências necessárias aos seus usuários é uma escolha de projeto que você faz, não algo que o balanceador deduz.
  4. Anycast ou direcionamento por DNS? Com anycast, o sistema de roteamento escolhe o local, então a escolha não depende de respostas DNS em cache, mas o operador tem controle limitado: a RFC 4786 descreve a distribuição de carga entre nós anycast como geralmente desequilibrada e afirma que a decisão de roteamento precisa permanecer estável por mais tempo que uma transação, porque uma interação entre cliente e servidor geralmente precisa permanecer no mesmo nó do início ao fim. Isso importa para fluxos de longa duração, como downloads em grande volume e streaming de mídia. O GSLB por DNS pode retornar endereços diferentes conforme a política e herda as limitações de cache descritas acima. Os dois também podem ser combinados, por exemplo, atribuindo um endereço anycast aos próprios servidores DNS de roteamento de solicitações.

Quando o balanceamento global de carga de servidores é importante

O GSLB é importante quando um serviço opera em mais de uma região e precisa de uma regra que determine qual região cada cliente usa e o que acontece quando uma região falha. O mecanismo escolhido define a rapidez com que o tráfego é redirecionado e a precisão com que a localização dos clientes é determinada: as respostas DNS são armazenadas em cache, e as políticas de DNS baseadas em localização usam o endereço do resolvedor, a menos que ele repasse parte do endereço do cliente, enquanto um balanceador que atua como proxy decide a cada solicitação, mas exige que todas as solicitações passem por ele.

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional

Conecte uploads, processamento, IA, armazenamento e entrega por meio de uma única API declarativa, com o stack de codificação, o ajuste de escala e as constantes mudanças de formatos gerenciados para você.

Experimente a Transloadit gratuitamente