Como configurar o balanceamento de carga HTTP(S)

Este documento é a primeira etapa na configuração de um balanceador de carga HTTP(S). Antes de começar, familiarize-se com os conceitos gerais de balanceamento de carga HTTP(S).

O balanceamento de carga HTTP(S) do Google Cloud Platform (GCP) fornece balanceamento global para solicitações HTTP(S) destinadas às suas instâncias.

O balanceamento de carga global exige que você use o nível Premium dos Níveis de serviço de rede.

É possível configurar regras de URL que direcionem alguns URLs para um conjunto de instâncias e outros URLs para outras instâncias. As solicitações são sempre direcionadas para o grupo de instâncias mais próximo do usuário, desde que o grupo tenha capacidade suficiente e seja apropriado para a solicitação. Se o grupo mais próximo não tiver capacidade suficiente, a solicitação será enviada ao grupo mais próximo que tiver capacidade.

O balanceamento de carga HTTP(S) é compatível com endereços IPv4 e IPv6 para o tráfego do cliente. As solicitações IPv6 do cliente são encerradas na camada de balanceamento de carga e encaminhadas por proxy via IPv4 para seus back-ends.

O balanceamento de carga das solicitações HTTP pode ser feito com base na porta 80 ou 8080. O balanceamento de carga das solicitações HTTPS pode ser feito na porta 443.

O balanceador de carga atua como uma camada de conversão de HTTP/2 para HTTP/1.1. Isso significa que os servidores da Web sempre consultam e respondem às solicitações HTTP/1.1, mas as solicitações do navegador podem ser HTTP/1.0, HTTP/1.1 ou HTTP/2. O push do servidor HTTP/2 não é compatível.

Antes de começar

O balanceamento de carga HTTP(S) usa grupos de instâncias para organizar as instâncias. Familiarize-se com os grupos de instâncias antes de usar o balanceamento de carga.

Exemplo de configuração

Se você quiser entrar em ação e criar um balanceador de carga ativo para teste, os diagramas a seguir demonstrarão três cenários diferentes usando o serviço Balanceamento de carga HTTP(S). Nesses cenários, há um contexto prático para balanceamento de carga HTTP(S) e demonstrações de como é possível configurar o balanceamento de carga de acordo com suas necessidades específicas.

No restante desta página, apresentamos mais detalhes sobre como os balanceadores de carga são construídos e como eles funcionam.

Balanceamento de carga entre regiões

Representação de balanceamento de carga entre regiões

É possível usar um endereço IP global que possa direcionar os usuários de modo inteligente com base na proximidade. Por exemplo, se você configurar instâncias na América do Norte, na Europa e na Ásia, usuários em todo o mundo serão automaticamente enviados aos back-ends mais próximos, supondo que aquelas instâncias tenham capacidade suficiente. Se as instâncias mais próximas não tiverem capacidade suficiente, o balanceamento de carga entre regiões encaminhará automaticamente os usuários para a região mais próxima seguinte.


Balanceamento de carga baseado em conteúdo

Representação de balanceamento de carga baseado em conteúdo

O balanceamento de carga baseado em conteúdo ou com reconhecimento de conteúdo usa balanceamento de carga HTTP(S) para distribuir o tráfego para instâncias diferentes de acordo com o URL HTTP(S) de entrada. Por exemplo, configure algumas instâncias para processar seu conteúdo de vídeo e outro conjunto para processar o restante. Configure o balanceador de carga para direcionar o tráfego para example.com/video aos servidores de vídeo e example.com/ aos servidores padrão.

É possível também usar o balanceamento de carga HTTP(S) com intervalos do Google Cloud Storage. Depois de configurar o balanceador de carga, é possível adicionar intervalos do Cloud Storage a ele.


Como criar um balanceador de carga combinado

Representação de balanceamento de carga baseado em conteúdo e entre regiões

O balanceamento de carga baseado em conteúdo e o balanceamento de carga entre regiões podem funcionar juntos usando vários serviços de back-end e várias regiões. É possível usar os cenários acima como base para definir uma configuração de balanceamento de carga própria que atenda às suas necessidades. O tutorial de balanceamento de carga HTTP(S) mostra como gerar uma configuração de balanceamento de carga baseado em conteúdo e entre regiões.


Interfaces

Seu serviço de balanceamento de carga HTTP(S) pode ser configurado e atualizado por meio das seguintes interfaces:

  • Ferramenta de linha de comando gcloud: incluída no SDK do Cloud. Na documentação do balanceamento de carga HTTP(S), essa ferramenta é frequentemente usada para a realização de tarefas. Para uma visão geral completa da ferramenta, consulte o Guia da ferramenta gcloud. Encontre comandos relacionados ao balanceamento de carga no grupo de comandos gcloud compute.

    Também é possível acessar a ajuda detalhada de qualquer comando gcloud usando a sinalização --help:

    gcloud compute http-health-checks create --help
    
  • Console do Google Cloud Platform: as tarefas de balanceamento de carga podem ser realizadas por meio do Console do Google Cloud Platform.

  • API REST: todas as tarefas de balanceamento de carga podem ser realizadas com a API Google Cloud Load Balancing. Os documentos de referência da API descrevem os recursos e métodos disponíveis para você.

Observações e restrições

  • O balanceamento de carga HTTP(S) é compatível com a resposta HTTP/1.1 100 Continue.
  • Se as instâncias de balanceamento de carga estiverem executando uma imagem pública do sistema operacional fornecida pelo Google Cloud Platform, as regras de firewall no sistema operacional serão configuradas automaticamente para permitir o tráfego com carga balanceada. Se você usar uma imagem personalizada, será preciso configurar manualmente o firewall do sistema operacional. Isso é feito separadamente da regra de firewall do GCP, que é preciso criar como parte da configuração de um balanceador de carga HTTP(S).
  • O balanceamento de carga não mantém as instâncias em sincronização. É preciso configurar seus próprios mecanismos, como usar o Deployment Manager, para garantir que suas instâncias tenham configurações e dados consistentes.

Solução de problemas

Tráfego com carga balanceada não tem endereço de origem do cliente original

O tráfego do balanceador de carga para suas instâncias tem um endereço IP nos intervalos de 130.211.0.0/22 e 35.191.0.0/16. Ao visualizar registros em suas instâncias de cargas balanceadas, não é possível ver o endereço de origem do cliente original. Em vez disso, você verá os endereços de origem desse intervalo.

Erro de permissão ao tentar visualizar um objeto em meu intervalo do Cloud Storage

Para veicular objetos pelo balanceamento de carga, os objetos do Cloud Storage precisam ser publicamente acessíveis. Não se esqueça de atualizar as permissões dos objetos veiculados para que a leitura pública seja possível.

O URL não veicula o objeto do Cloud Storage esperado

O objeto do Cloud Storage a ser veiculado é determinado com base no mapa de URL e no URL solicitado. Quando o caminho da solicitação aponta para um intervalo de back-ends no mapa de URL, esse objeto é definido pelo acréscimo do caminho completo da solicitação ao intervalo do Cloud Storage especificado no mapa.

Por exemplo, se você mapear /static/* para gs://[EXAMPLE_BUCKET], a solicitação para https://<GCLB IP or Host>/static/path/to/content.jpg tentará veicular gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se esse objeto não existir, em vez dele, você receberá a mensagem de erro a seguir:


NoSuchKey
The specified key does not exist.

A compactação não está funcionando

O balanceamento de carga HTTP(S) não compacta nem descompacta as respostas, mas pode veicular as respostas geradas pelo serviço de back-end que foram compactadas usando ferramentas como gzip ou DEFLATE.

Se as respostas fornecidas pelo balanceamento de carga HTTP(S) não estiverem compactadas, mas deveriam estar, verifique se o software servidor da Web em execução nas instâncias está configurado para compactar as respostas. Por padrão, alguns softwares servidor da Web desativam automaticamente a compactação de solicitações que incluem um cabeçalho Via, que indica que a solicitação foi encaminhada por um proxy. Como se trata de um proxy, o balanceamento de carga HTTP(S) adiciona um cabeçalho Via a cada solicitação conforme exigido pela especificação HTTP. Para ativar a compactação, talvez seja necessário substituir a configuração padrão do seu servidor da Web para que ele compacte as respostas mesmo se a solicitação tiver um cabeçalho Via.

Se você estiver usando o software servidor da Web nginx, modifique o arquivo de configuração nginx.conf para ativar a compactação. O local desse arquivo depende de onde o nginx está instalado. Em muitas distribuições Linux, o arquivo é armazenado em /etc/nginx/nginx.conf. Para permitir que a compactação nginx funcione com o balanceamento de carga HTTP(S), adicione as duas linhas a seguir à seção http do arquivo nginx.conf:

gzip_proxied any;
gzip_vary on;

A primeira linha ativa a compactação até mesmo para solicitações encaminhadas por um proxy como o balanceamento de carga HTTP(S). A segunda linha adiciona um cabeçalho Vary: Accept-Encoding às respostas. O cabeçalho Vary: Accept-Encoding notifica aos proxies de armazenamento em cache, como o Cloud CDN, que eles devem manter as entradas de cache separadas das variantes compactadas e não compactadas dos recursos compactáveis.

Após modificar o nginx.conf, você precisará reiniciar o nginx antes que ele use a nova configuração. Em muitas distribuições Linux, o nginx pode ser reiniciado executando sudo service nginx restart ou /etc/init.d/nginx restart.

Solução de problemas com HTTP/2 para back-ends

Valor inválido para o campo resource.loadBalancingScheme: "EXTERNAL"

O balanceamento de carga da rede baseado em serviço de back-end ainda não é compatível.

Isso pode acontecer se você criar um serviço de back-end sem selecionar a opção global. Ao emitir um comando gcloud da maneira a seguir, é solicitado que você designe uma região ou determine o balanceador de carga como global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \
    --protocol=http2

Para este serviço de back-end:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
....
Please enter your numeric choice:

Para o balanceador de carga HTTP(S), os serviços de back-end precisam ser globais. Portanto, é necessário escolher a opção 1 ou emitir o comando gcloud com a opção --global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \
    --global

Erros 502 inexplicáveis

Verifique se a instância de back-end está íntegra e aceita o protocolo HTTP/2. Para isso, teste a conectividade com a instância de back-end usando HTTP/2. Confira se a VM usa pacotes de criptografia compatíveis com a especificação HTTP/2. Por exemplo, determinados pacotes de criptografia do TLS 1.2 não são permitidos pelo HTTP/2. Consulte a Lista negra de pacotes de criptografia do TLS 1.2 (em inglês).

Depois de verificar que a VM usa o protocolo HTTP/2, confira se a configuração do firewall permite a passagem do verificador de integridade e do balanceador de carga.

Se não houver problemas com a configuração do firewall, verifique se o balanceador de carga está configurado para se comunicar com a porta correta na VM.

Limitações do HTTP/2

  • O HTTP/2 entre o balanceador de carga e a instância pode exigir muito mais conexões TCP com a instância do que o HTTP(S). O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP(S), não está disponível atualmente com o HTTP/2.
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com:
    • push de servidor
    • WebSockets

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…