O NLB usa verificações de integridade para determinar a disponibilidade dos servidores de back-end. Quando um servidor falha nas verificações, o NLB para de encaminhar novas solicitações a ele e redistribui o tráfego para servidores íntegros. Quando o servidor se recupera, o NLB retoma o encaminhamento automaticamente. As verificações de integridade melhoram a disponibilidade do serviço e previnem pontos únicos de falha (SPOFs).
Processo de verificação de integridade
As instâncias do NLB operam em clusters. Os nós do cluster encaminham o tráfego e executam verificações de integridade.
Os nós do cluster operam de forma independente, encaminhando tráfego e executando verificações de integridade em paralelo.
-
Se o NLB detectar um servidor de back-end não íntegro com a drenagem de conexão desativada, as sessões existentes serão concluídas antes do fechamento das conexões. Novas solicitações deixam de ser encaminhadas ao servidor.
-
Se o NLB detectar um servidor de back-end não íntegro com a drenagem de conexão ativada, as sessões existentes continuam até o timeout de drenagem expirar. Novas solicitações deixam de ser encaminhadas ao servidor.
-
O NLB usa seu endereço IP local para verificações de integridade. Certifique-se de que esse endereço IP não esteja bloqueado pelos servidores de back-end. Não é necessária nenhuma regra de grupo de segurança do ECS, mas se outras políticas de segurança estiverem em vigor (como iptables), permita o endereço IP.
-
Quando todos os servidores de back-end falham nas verificações de integridade, o NLB entra no modo de melhor esforço e encaminha as solicitações para todos os servidores a fim de manter a disponibilidade.
Como funciona
Verificações de integridade TCP
O NLB envia sondagens TCP personalizadas para testar a disponibilidade dos servidores de back-end.
Processo de verificação de integridade TCP:
-
O NLB envia pacotes TCP SYN para o endereço IP interno e a porta de verificação de integridade de cada servidor de back-end.
-
Se a porta estiver escutando, o servidor de back-end retorna um pacote SYN-ACK.
-
Se nenhum SYN-ACK for recebido antes do timeout de resposta, o servidor é declarado não íntegro. O NLB envia um pacote RST para fechar a conexão.
-
Se um SYN-ACK for recebido antes do timeout, o servidor é aprovado na verificação de integridade. O NLB envia um ACK seguido imediatamente por um RST para fechar a conexão.
Durante as verificações de integridade, o NLB conclui o handshake de três vias e envia imediatamente um RST para fechar a conexão. Isso pode causar erros falsos de conexão TCP nos servidores de back-end, que podem registrar erros Connection reset by peer nos logs de software, como logs de pool de conexões Java.
Soluções:
-
Configure verificações de integridade HTTP para listeners TCP.
-
Ative a preservação do IP do cliente nos servidores de back-end e ignore erros de redefinição de conexão dos blocos CIDR do NLB.
Verificações de integridade UDP
As verificações de integridade UDP suportam dois métodos:
Método 1: verificações de integridade em portas
A figura a seguir mostra como as verificações de integridade são realizadas.
Processo de verificação de integridade UDP em portas:
-
O NLB envia uma solicitação ICMP para o endereço IP interno do servidor de back-end.
-
O NLB envia um pacote de sondagem UDP para o endereço IP interno e a porta de verificação de integridade do servidor de back-end.
-
Se o servidor de back-end retornar uma resposta ICMP antes do timeout e não retornar uma mensagem
Port XX Unreachable, o servidor é aprovado. Caso contrário, ele falha.
Método 2: verificações de integridade personalizadas
A figura a seguir mostra como as verificações de integridade são realizadas.
Processo de verificação de integridade UDP personalizada:
-
O NLB envia um pacote de sondagem UDP com conteúdo especificado para o endereço IP interno e a porta de verificação de integridade do servidor de back-end.
-
Se o NLB receber a resposta esperada antes do timeout, o servidor é aprovado. Caso contrário, ele falha.
Verificações de integridade HTTP
Para listeners de Camada 4 (TCP ou UDP), você pode configurar verificações de integridade HTTP que enviam solicitações HEAD ou GET para verificar a disponibilidade dos servidores de back-end.
Processo de verificação de integridade HTTP:
-
O NLB envia uma solicitação HTTP HEAD ou GET com o nome de domínio especificado para o endereço IP interno e o caminho de verificação de integridade do servidor de back-end.
-
O servidor de back-end retorna um código de status HTTP com base em seu estado.
-
Se nenhuma resposta for recebida antes do timeout, o servidor falha na verificação de integridade.
-
Se uma resposta for recebida antes do timeout, o NLB compara o código de status HTTP retornado com os códigos especificados nas configurações de verificação de integridade. Um código correspondente indica que o servidor está íntegro; caso contrário, ele é considerado não íntegro.
Casos de uso
Verificações de integridade TCP
-
Serviços FTP: verifique se os servidores FTP aceitam e respondem a solicitações de conexão.
-
Serviços de e-mail: verifique se os servidores de e-mail enviam e recebem mensagens.
-
Transações financeiras: detecte falhas nos servidores de transações prontamente para evitar interrupções.
-
Login remoto: monitore a disponibilidade e o desempenho dos serviços de login remoto.
Verificações de integridade UDP
Setores tradicionais
-
Serviços DNS: verifique se os servidores DNS respondem às consultas corretamente.
-
Serviços VoIP: monitore a latência, perda de pacotes e jitter em aplicações VoIP, como Skype e sistemas de telefonia IP.
-
Jogos online: monitore o tempo de resposta e a disponibilidade dos servidores de jogos.
-
Mídia de streaming: avalie a disponibilidade e a qualidade do stream para videoconferências e serviços de vídeo em tempo real.
-
Mensagens instantâneas: monitore a estabilidade da conexão e a latência para entrega de mensagens em tempo real.
Setores emergentes
-
QUIC: verifique o status da conexão QUIC para transmissão de dados eficiente e em tempo real.
-
IoT: verifique o status dos dispositivos sensores com baixa latência, adequado para dispositivos sensíveis a energia ou custo.
-
V2X: garanta a troca de dados em tempo real e a confiabilidade da comunicação entre veículos e infraestrutura.
-
VR e AR: garanta a transmissão rápida de dados visuais e de interação.
-
Cloud gaming: monitore a latência para garantir jogabilidade fluida.
Verificações de integridade HTTP
-
Serviços web: envie solicitações HTTP GET ou HEAD para um caminho especificado (como
/health) para verificar se o servidor processa solicitações HTTP. -
Verificações de integridade personalizadas para aplicações: use lógica personalizada para verificar pools de conexão de banco de dados, status de cache ou outras métricas específicas da aplicação.
-
Microsserviços: detecte erros na camada de aplicação em instâncias de microsserviços. As respostas das verificações de integridade fornecem informações detalhadas de diagnóstico.
-
Gateways de API e proxies reversos: monitore a integridade de gateways de API ou proxies reversos, como NGINX e HAProxy, por meio de suas interfaces HTTP.
Nomes de domínio para verificações de integridade HTTP
Opcionalmente, você pode especificar um nome de domínio para verificações de integridade HTTP. Alguns servidores de aplicação verificam o cabeçalho Host antes de aceitar solicitações. Se você especificar um nome de domínio nas configurações de verificação de integridade, o NLB o adiciona ao cabeçalho Host. Caso contrário, o NLB omite o cabeçalho Host, o que pode causar falhas nas verificações de integridade se o servidor de back-end o exigir.
Se o seu servidor de aplicação verifica o cabeçalho Host, configure um nome de domínio para as verificações de integridade.
Referências
-
Para obter mais informações sobre como configurar verificações de integridade, consulte Grupos de servidores do NLB.
-
Para obter mais informações sobre como solucionar problemas de verificação de integridade, consulte Solucionar falhas de verificação de integridade do NLB.