O Application Load Balancer (ALB) monitora continuamente os servidores de back-end por meio de verificações de integridade e redireciona automaticamente o tráfego para longe de servidores não íntegros.
As verificações de integridade estão ativadas por padrão para todos os grupos de servidores e podem ser configuradas independentemente para cada grupo.
Como funciona
O ALB envia periodicamente solicitações de sondagem a cada servidor de back-end e avalia a resposta. Um servidor precisa passar por um número consecutivo de verificações — o Limiar de Integridade — antes que o ALB o marque como íntegro. Isso evita que instabilidades momentâneas da rede acionem falsos positivos.
Quando um servidor falha nas verificações consecutivamente além do Limiar de Não Integridade, o ALB para de rotear novas solicitações para ele e as redireciona para servidores íntegros. Quando o servidor se recupera, o ALB o adiciona novamente de forma automática.
As verificações de integridade usam conexões de curta duração fechadas imediatamente após a conclusão de cada sondagem.
Comportamento fail-open: Se todos os servidores de um grupo falharem simultaneamente nas verificações de integridade, o ALB ainda assim roteará as solicitações para todos eles com base no algoritmo de agendamento, em vez de descartar totalmente o tráfego. Esse mecanismo limita a interrupção do service quando ocorre uma falha generalizada.
Servidores de back-end com peso 0 não participam das verificações de integridade.
Endereços IP de source
O ALB sonda os servidores de back-end a partir de endereços IP específicos. Certifique-se de que os servidores permitam tráfego desses endereços — inclusive em regras do iptables, softwares de segurança de terceiros ou ACLs de rede da VPC. Se você bloquear esses IPs, as sondagens de verificação de integridade não conseguirão alcançar os servidores, o ALB os marcará como não íntegros e eles serão removidos do rodízio de balanceamento de carga.
|
Tipo de instância ALB |
Faixa de IP de source |
|
Instância ALB atualizada |
Endereços IP privados do bloco CIDR do vSwitch (IP local). Visualize esses endereços na página de detalhes da instância. |
|
Instância ALB não atualizada |
|
Crie uma verificação de integridade
Console
Acesse a página Health Check no console do ALB.
Selecione a região de destino e clique em Create Health Check.
Configure os parâmetros a seguir e clique em Create.
Configurações básicas
|
Parâmetro |
Descrição |
|
Health Check Name |
Nome deste modelo de verificação de integridade. |
|
Protocol |
Protocolo da sondagem. Consulte Protocolos para obter detalhes. |
|
Health Check Method |
Método HTTP da solicitação de sondagem. Aplica-se apenas a HTTP, HTTPS e gRPC. |
|
HTTP Version |
HTTP1.0 ou HTTP1.1. Aplica-se apenas a HTTP e HTTPS. |
|
Port |
Porta a ser sondada. Deixe em branco para usar a porta de cada servidor de back-end. Valores válidos: 1–65535. |
|
Path |
Caminho da URL a ser sondado, como |
|
Domain Name |
Valor do cabeçalho |
Determinação de integridade
|
Parâmetro |
Padrão |
Valores válidos |
Descrição |
|
Health Check Status Codes |
|
Consulte Health check status codes |
Códigos de status HTTP que indicam um servidor íntegro. Aplica-se apenas a HTTP, HTTPS e gRPC. |
|
Health Check Response Timeout |
5 segundos |
1–300 segundos |
Se o servidor não responder dentro desse tempo, a verificação será contada como falha. |
|
Health Check Interval |
2 segundos |
1–50 segundos |
Tempo entre verificações consecutivas. Intervalos maiores resultam em detecção mais lenta de servidores não íntegros. |
|
Healthy Threshold |
3 |
2–10 |
Número de verificações bem-sucedidas consecutivas necessárias para marcar um servidor como íntegro. |
|
Unhealthy Threshold |
3 |
2–10 |
Número de verificações com falha consecutivas necessárias para marcar um servidor como não íntegro. |
Tags e grupo de recursos
|
Parâmetro |
Descrição |
|
Tag Key / Tag Value |
Tags de chave-valor para filtragem e gerenciamento de modelos de verificação de integridade. |
|
Resource Group |
O resource group ao qual esta verificação de integridade pertence. |
Após criar a verificação de integridade, selecione-a na seção Health Check Settings ao criar um grupo de servidores.
Você também pode configure verificações de integridade ao creating a server group e salve a configuração como um modelo selecionando Save the health check configurations as a template .
API
Chame CreateHealthCheckTemplate para crie um modelo de verificação de integridade.
Chame ApplyHealthCheckTemplateToServerGroup para aplicá-lo a um grupo de servidores.
Protocolos
Métodos de verificação de integridade (HTTP, HTTPS, gRPC)
|
Método |
Padrão para |
Comportamento |
|
HEAD |
HTTP, HTTPS |
Solicita apenas cabeçalhos. Certifique-se de que o back-end suporte solicitações HEAD; caso contrário, use GET. |
|
POST |
gRPC |
Certifique-se de que o back-end suporte solicitações POST; caso contrário, use GET. |
|
GET |
— |
Respostas maiores que 8 KB são truncadas, mas isso não afeta o resultado da verificação de integridade. |
Detalhes dos protocolos
|
Protocolo |
Mecanismo |
|
HTTP |
O ALB envia solicitações HEAD ou GET para verificar se a aplicação do servidor de back-end está íntegra. |
|
HTTPS |
O ALB envia solicitações HEAD ou GET para verificar se a aplicação do servidor de back-end está íntegra. Suportado para instâncias ALB Standard e WAF-enhanced. Não suportado para instâncias ALB Basic. |
|
TCP |
O ALB envia pacotes de handshake SYN para verificar se a porta do servidor de back-end está disponível. |
|
gRPC |
O ALB envia solicitações POST ou GET para verificar se a aplicação do servidor de back-end está íntegra. |
O ALB Extensible Edition suporta apenas os protocolos de verificação de integridade HTTP e TCP.
Códigos de status de verificação de integridade (HTTP, HTTPS, gRPC)
O ALB declara um servidor como íntegro somente quando a sondagem retorna um dos códigos de status configurados.
HTTP/HTTPS: Escolha entre
http_2xx,http_3xx,http_4xxehttp_5xx. Padrão:http_2xxehttp_3xx.gRPC: Os códigos válidos são 0–99. Especifique até 20 faixas de valores, separadas por vírgulas.
Incluir http_4xx ou http_5xx na lista de códigos de status atrasa a detecção de servidores não íntegros. Mantenha a lista restrita a http_2xx e http_3xx e corrija problemas no back-end que causem respostas 4XX ou 5XX.
Modifique uma verificação de integridade
Desativar as verificações de integridade impede que o ALB detecte servidores não íntegros. Se um servidor ficar inativo, o tráfego não será redirecionado automaticamente para servidores íntegros.
Ao especificar um intervalo maior de verificação de integridade, o ALB levará mais tempo para detectar servidores de back-end não íntegros.
Console
Acesse a página Health Check no console do ALB.
Localize a verificação de integridade desejada e clique em Modify na coluna Actions.
Atualize as configurações na caixa de diálogo Modify Health Check Settings e clique em Save.
Você também pode edit health checks on the Server Groups page .
API
Chame UpdateHealthCheckTemplateAttribute para atualize um modelo de verificação de integridade.
Visualize o status da verificação de integridade
Se a instância ALB tiver listeners e as verificações de integridade estiverem ativadas, visualize o status de integridade dos servidores de back-end na aba Listener. O status de verificação de integridade de um listener é agregado a partir de todos os grupos de servidores associados. Se qualquer servidor de back-end em um grupo estiver não íntegro, o grupo de servidores será considerado não íntegro. Caso algum grupo de servidores associado a um listener esteja não íntegro, o status de verificação de integridade do listener será exibido como não íntegro.
Console
API
Chame GetListenerHealthStatus para consultar o status da verificação de integridade de um listener.
Exclua uma verificação de integridade
Console
Acesse a página Health Check no console do ALB.
Localize a verificação de integridade desejada e clique em Delete na coluna Actions.
Confirme a exclusão e clique em OK.
API
Chame DeleteHealthCheckTemplates para exclua um modelo de verificação de integridade.
Aplicar em produção
Crie um endpoint dedicado para verificação de integridade. Adicione uma rota específica — como /health — que sempre retorne HTTP 200. Evite usar caminhos de negócio: eles podem retornar 4XX devido a autenticação ou recursos ausentes, causando falhas falsas.
Corrija problemas no back-end em vez de flexibilizar os códigos de status. Quando as verificações de integridade falharem, investigue e corrija a causa raiz para que o endpoint retorne 2XX ou 3XX. Não adicione 4XX ou 5XX à lista de códigos de status aceitos como solução alternativa.
Ajuste os parâmetros para o seu ambiente. As configurações padrão funcionam para a maioria dos cenários. Para services com inicialização lenta, aumente o Health Check Interval ou o Unhealthy Threshold para evitar que um servidor em fase de inicialização seja marcado prematuramente como não íntegro. Em redes com alta latência, aumente o Health Check Response Timeout.
Simule verificações de integridade com curl. Durante a solução de problemas, use o comando a seguir para replicar o comportamento de sondagem do ALB. Substitua o método, domínio, IP, porta e caminho para corresponder à sua configuração:
curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://backend_ip:port/health_pathFaturamento
As verificações de integridade não geram cobranças adicionais. Para detalhes sobre preços do ALB, consulte ALB billing information.
Cota
É possível crie até 50 modelos de verificação de integridade por região. Essa cota não pode ser aumentada.