O Load Balancer da GoCache é responsável por distribuir as requisições entre as origens configuradas, ajudando a melhorar a disponibilidade, a resiliência e a distribuição de tráfego entre diferentes servidores de origem.

Na GoCache, o balanceamento é realizado utilizando o algoritmo Round Robin com pesos. Isso significa que as requisições são distribuídas entre as origens de acordo com o peso/carga configurado para cada uma delas.

Como funciona o algoritmo Round Robin com pesos?

O Round Robin distribui as requisições de forma alternada entre as origens disponíveis.

Com o uso de pesos, é possível definir que uma origem receba mais ou menos tráfego em comparação com as demais. Por exemplo, uma origem com peso maior tende a receber uma quantidade maior de requisições.

Esse comportamento é útil quando uma origem possui maior capacidade de processamento do que outra.

O Load Balancer tem prioridade sobre a configuração de DNS?

Sim. Quando um subdomínio está vinculado a um Load Balancer, as origens configuradas nele passam a ter prioridade sobre a origem definida na aba DNS.

Ou seja, as requisições para aquele subdomínio serão encaminhadas conforme as origens configuradas no Load Balancer.

O que significam os status Online e Offline nas origens do Load Balancer?

Os status Online e Offline representam o resultado da validação realizada pelo Health Checker do Load Balancer.

A plataforma realiza verificações periódicas nas origens configuradas, utilizando o caminho definido no Health Check.

Quando a origem responde com um status HTTP 2xx, ela é considerada saudável e exibida como Online.

Caso a validação falhe, a origem pode ser marcada como Offline e removida temporariamente da lista de origens aptas a receber tráfego.

Uma origem Offline significa que o servidor está fora do ar?

Não necessariamente.

Uma origem marcada como Offline indica que ela não respondeu conforme o esperado à checagem realizada pela GoCache. Isso não significa, obrigatoriamente, que o servidor esteja totalmente indisponível.

O status Offline pode ocorrer, por exemplo, quando:

• O endpoint de Health Check retorna um status diferente de 2xx;
• A origem não responde dentro do tempo esperado;
• O caminho configurado no Health Check não existe;
• Há bloqueios de firewall ou regras de segurança;
• A aplicação exige headers específicos para responder corretamente;
• A origem depende do header Host para rotear a requisição.

O Health Checker envia o header Host?

Não. O Health Checker não envia o header Host na requisição.

Esse ponto é importante principalmente quando a origem está configurada por IP direto e o servidor utiliza Virtual Hosts, como em configurações de NGINX ou Apache.

Nesses casos, se o servidor depender do header Host para identificar qual aplicação deve responder, a requisição do Health Checker pode retornar 404 ou outro status não esperado, fazendo com que a origem seja marcada como Offline.

Qual é a recomendação para o endpoint de Health Check?

A recomendação é disponibilizar um endpoint específico para Health Check, que responda diretamente com HTTP 200/2xx e não dependa de regras específicas da aplicação.

Exemplos de endpoints recomendados:

/health
/status
/healthcheck

Esse endpoint deve, preferencialmente:

• Responder com HTTP 200 ou outro status 2xx;
• Não depender de autenticação;
• Não depender de redirecionamentos;
• Preferencialmente, não depender de Virtual Host;
• Não exigir headers específicos;
• Estar acessível diretamente pela origem configurada.

Como validar se o Load Balancer está corretamente configurado?

Para validar se um Load Balancer existente está corretamente aplicado e funcionando conforme esperado, recomendamos conferir os seguintes pontos:

1. Verificar se o domínio ou subdomínio correto está vinculado ao Load Balancer no painel;
2. Confirmar se as origens configuradas estão corretas, incluindo IP, hostname e porta, quando aplicável;
3. Validar se os pesos/cargas estão configurados conforme o comportamento esperado;
4. Confirmar se o caminho configurado no Health Check está acessível diretamente pela origem;
5. Testar se o endpoint de Health Check retorna HTTP 200/2xx;
6. Verificar se há origem de backup configurada, caso o objetivo seja fallback;
7. Realizar testes práticos de acesso ao domínio;
8. Validar nos logs das origens se as requisições estão chegando aos backends esperados.

Como testar o Health Check diretamente na origem?

Para validar o funcionamento do Health Check, recomenda-se realizar uma requisição diretamente para a origem configurada, utilizando o mesmo path definido no painel.

Exemplo:

curl -I http://IP_DA_ORIGEM/health

O retorno esperado deve ser um status HTTP 200 ou outro status 2xx.

Caso a origem dependa do header Host, o teste pode retornar comportamento diferente do esperado pelo Health Checker da GoCache, pois o Health Checker não envia esse header.

Posso usar o Load Balancer como fallback em vez de balanceamento ativo?

Sim. Em alguns cenários, o cliente pode utilizar o Load Balancer como um mecanismo de contingência/fallback, em vez de distribuir tráfego ativamente entre múltiplas origens.

Esse modelo pode ser útil em casos como:

• Alta disponibilidade;
• Manutenção programada;
• Estratégia de contingência;
• Origem secundária para cenários de falha.

Como configurar um cenário com uma origem principal e uma origem secundária?

Caso o objetivo seja manter uma origem principal e uma origem secundária para fallback, é possível utilizar algumas abordagens, como:

Múltiplas entradas DNS apontando para o mesmo IP

O cliente pode criar diferentes hostnames apontando para o mesmo IP de origem. Dessa forma, é possível cadastrar múltiplas origens no Load Balancer mesmo que, na prática, elas resolvam para o mesmo servidor.

Diferenciação por porta

Também é possível cadastrar a mesma origem diferenciando a porta utilizada, por exemplo:

Origem 1: IP
Origem 2: IP:3000

Essa abordagem pode ser utilizada quando a origem responde em portas específicas, como HTTP (80), HTTPS (443) ou outra.

O que acontece quando uma origem fica Offline?

Quando uma origem é marcada como Offline, ela deixa temporariamente de receber tráfego pelo Load Balancer, desde que existam outras origens saudáveis disponíveis.

Quando a origem volta a responder corretamente ao Health Check, ela pode voltar a ser considerada Online e retornar à lista de origens aptas a receber requisições.

Boas práticas para configuração do Load Balancer

Para garantir o funcionamento adequado do Load Balancer, recomendamos:

• Configurar corretamente todas as origens;
• Utilizar pesos compatíveis com a capacidade de cada backend;
• Criar um endpoint dedicado para Health Check;
• Garantir que o Health Check responda HTTP 200/2xx;
• Evitar que o endpoint de Health Check dependa de autenticação, header Host ou redirecionamentos;
• Validar os logs das origens após a configuração;
• Configurar origem de backup quando o objetivo for contingência;
• Realizar testes práticos após qualquer alteração na configuração.