Verificações de integridade do CLB - Server Load Balancer: Central de Documentação do Alibaba Cloud

O CLB utiliza verificações de integridade para determinar a disponibilidade dos servidores de back-end. Quando um servidor de back-end se torna não íntegro, o CLB deixa de enviar solicitações a ele e as distribui para servidores íntegros. Após a recuperação do servidor, o CLB retoma o encaminhamento de tráfego para ele. Esse mecanismo de verificação de integridade melhora a disponibilidade geral do serviço, evitando que falhas em servidores individuais afetem sua aplicação.

null

Se o seu serviço é sensível a carga, verificações de integridade frequentes podem afetar o tráfego normal. Para reduzir esse impacto, diminua a frequência das verificações, aumente o intervalo entre elas ou alterne de verificações de integridade de Camada 7 para Camada 4. No entanto, para garantir a disponibilidade contínua do serviço, recomenda-se não desativar as verificações de integridade.

Processo de verificação de integridade

As verificações de integridade confirmam o status dos servidores enviando solicitações periódicas.

O CLB é implantado em um cluster. Os nós desse cluster realizam tanto o encaminhamento de dados quanto as verificações de integridade. Quando um servidor de back-end falha em uma verificação de integridade, o CLB deixa de distribuir novas solicitações de clientes para esse servidor não íntegro.

O CLB utiliza o bloco CIDR 100.64.0.0/10 para verificações de integridade. Os servidores de back-end não devem bloquear o tráfego proveniente desse intervalo de endereços. Não é necessário adicionar uma regra de permissão no grupo de segurança do ECS, mas, caso existam outras políticas de segurança configuradas, como iptables, é preciso permitir o tráfego desse bloco CIDR. O intervalo 100.64.0.0/10 é um espaço de endereço reservado da Alibaba Cloud e não apresenta risco de segurança.

null

Práticas recomendadas para proteção do grupo de segurança do ECS de back-end

Para evitar que invasores contornem o CLB e acessem diretamente o IP público de uma instância ECS de back-end, recomenda-se configurar regras de entrada no grupo de segurança do ECS. Essas regras devem permitir tráfego nas portas do serviço apenas a partir de blocos CIDR necessários e rejeitar solicitações diretas da internet. A configuração recomendada é a seguinte:

O bloco CIDR 100.64.0.0/10, usado para verificações de integridade e encaminhamento de tráfego do CLB, não é restrito pelas regras de entrada do grupo de segurança do ECS de back-end. Não é necessário adicionar uma regra de permissão específica para esse bloco CIDR, pois o tráfego do CLB para as instâncias ECS de back-end é sempre permitido.
Nas regras de entrada do grupo de segurança do ECS, permita o acesso às portas do serviço (como 80 e 443) apenas a partir do bloco CIDR da VPC. Não permita o acesso às portas do serviço a partir da internet (0.0.0.0/0).
Após concluir essa configuração, o grupo de segurança bloqueia solicitações diretas da internet às portas do serviço da instância ECS. O tráfego normal encaminhado pelo CLB não é afetado.

Verificações de integridade HTTP e HTTPS

Listeners de Camada 7 (HTTP/HTTPS) realizam verificações de integridade por meio de solicitações HEAD ou GET.

Para listeners HTTPS, os certificados são gerenciados pelo CLB. O CLB utiliza HTTP para a troca de dados com os servidores de back-end, a fim de melhorar o desempenho.

A verificação de integridade de um listener de Camada 7 funciona da seguinte forma:

O CLB envia uma solicitação HTTP HEAD ao servidor de back-end.
O servidor de back-end retorna um código de status HTTP.
Se o CLB não receber uma resposta dentro do tempo limite, a verificação de integridade falha.
Se o CLB receber uma resposta dentro do tempo limite, ele compara o código de status com os códigos de status íntegros configurados. Se o código corresponder, a verificação é bem-sucedida. Caso contrário, ela falha.

null

Por padrão, as verificações de integridade do CLB consideram íntegros apenas os códigos de status HTTP 2xx e 3xx. Se um servidor de back-end retornar um código de status 4xx (como 400, 403, 404 ou 429) ou 5xx (como 500, 502 ou 503), a verificação de integridade falha.

Recomenda-se criar um endpoint dedicado para verificação de integridade, como /health, que retorne um código de status HTTP 200, em vez de adicionar códigos 4xx ou 5xx à lista de códigos de status íntegros.

Verificações de integridade TCP

Para listeners TCP de Camada 4, o CLB utiliza sondas TCP personalizadas para verificar o status dos servidores, conforme ilustrado na figura a seguir.

A verificação de integridade de um listener TCP funciona da seguinte forma:

Um nó do cluster de Camada 4 envia um pacote TCP SYN para o IP interno e a porta de verificação de integridade do servidor de back-end.
Após receber a solicitação, se o servidor estiver escutando corretamente na porta, ele retorna um pacote SYN+ACK.
Se o nó do cluster de Camada 4 não receber resposta do servidor de back-end dentro do tempo limite, a verificação de integridade falha. O nó então envia um pacote RST para encerrar a conexão TCP.
Se o nó do cluster de Camada 4 receber uma resposta do servidor de back-end dentro do tempo limite, a verificação de integridade é bem-sucedida. O nó então envia um pacote RST para encerrar a conexão TCP.

null

Esse mecanismo pode fazer com que o servidor de back-end considere as conexões TCP anormais e registre erros, como Connection reset by peer, nos logs da aplicação.

Soluções alternativas:

Para listeners TCP, use verificações de integridade baseadas em HTTP.
Após configurar o servidor de back-end para obter o IP real do cliente, ignore erros de conexão provenientes do bloco de endereços do serviço CLB.

Verificações de integridade UDP

Para listeners UDP de Camada 4, as verificações de integridade utilizam sondas de pacote UDP para verificar o status dos servidores, conforme ilustrado na figura a seguir.

A verificação de integridade de um listener UDP funciona da seguinte forma:

Um nó do cluster de Camada 4 envia um pacote UDP para o IP interno e a porta de verificação de integridade do servidor de back-end.
Se o servidor de back-end não estiver escutando na porta, o sistema operacional retorna uma mensagem de erro ICMP, como port XX unreachable. Caso contrário, o servidor não responde.
Se o nó do cluster de Camada 4 receber essa mensagem de erro do servidor de back-end dentro do tempo limite, a verificação de integridade falha.
Se o nó do cluster de Camada 4 não receber nenhuma resposta do servidor de back-end dentro do tempo limite, a verificação de integridade é bem-sucedida.

null

Para serviços UDP, o status da verificação de integridade pode nem sempre corresponder ao status real do serviço.

Se o servidor de back-end for um servidor Linux, cenários de alta concorrência podem acionar o mecanismo de proteção contra flood ICMP do Linux, que limita a taxa de envio de mensagens ICMP pelo servidor. Nesse caso, mesmo que o serviço esteja inativo, o servidor pode ser incapaz de retornar um erro ICMP port XX unreachable. Como resultado, quando o CLB não recebe uma resposta ICMP, ele marca incorretamente a verificação de integridade como bem-sucedida, causando uma divergência entre o status de integridade reportado e o status real do serviço.

Solução alternativa:

Configure o balanceador de carga para enviar uma string específica ao servidor de back-end e considere a verificação bem-sucedida somente após receber uma resposta específica. Esse mecanismo requer suporte da aplicação de back-end.

Janela de tempo da verificação de integridade

O mecanismo de verificação de integridade melhora a disponibilidade do serviço. No entanto, para evitar instabilidade no sistema decorrente de mudanças frequentes de status, o CLB altera o status de um servidor somente após ele ser aprovado ou reprovado em um número específico de verificações de integridade consecutivas dentro de uma janela de tempo. Essa janela de tempo é determinada pelos três fatores a seguir:

intervalo de verificação de integridade (frequência com que a verificação é realizada)
tempo limite de resposta (tempo de espera pela resposta do servidor à verificação de integridade)
limiar de verificação (número de verificações consecutivas bem-sucedidas ou com falha necessárias para uma mudança de status)

A janela de tempo da verificação de integridade é calculada da seguinte forma:

Janela de falha da verificação de integridade = tempo limite de resposta × limiar de não integridade + intervalo de verificação de integridade × (limiar de não integridade - 1)
Janela de sucesso da verificação de integridade = (tempo de resposta bem-sucedida da verificação × limiar de integridade) + intervalo de verificação de integridade × (limiar de integridade - 1)

null
O tempo de resposta bem-sucedida da verificação de integridade é a duração entre o envio de uma solicitação de verificação de integridade e o recebimento de uma resposta. Para verificações TCP, esse tempo é negligenciável. Para verificações HTTP, esse tempo depende do desempenho e da carga do servidor, mas normalmente fica dentro de um segundo.

O status da verificação de integridade afeta o encaminhamento de solicitações da seguinte forma:

Se um servidor de back-end de destino falhar em uma verificação de integridade, novas solicitações deixam de ser distribuídas a ele. Esse redirecionamento é transparente para novos clientes.
Se um servidor de back-end de destino for aprovado em uma verificação de integridade, novas solicitações são distribuídas a ele e o acesso do cliente funciona normalmente.
Se um servidor de back-end estiver falhando nas verificações de integridade, mas ainda não tiver atingido o limiar de não integridade (três falhas consecutivas, por padrão), o CLB continua a enviar solicitações a ele. Isso pode causar falha nas solicitações dos clientes.

Exemplo de configuração de verificação de integridade

Este exemplo utiliza a seguinte configuração de verificação de integridade:

response timeout: 5 seconds
health check interval: 2 seconds
healthy threshold: 3
unhealthy threshold: 3

A janela de falha da verificação de integridade é calculada assim: tempo limite de resposta × limiar de não integridade + intervalo de verificação de integridade × (limiar de não integridade - 1). Com os valores fornecidos, o resultado é 5 × 3 + 2 × (3 - 1) = 19 segundos. Esse é o tempo total desde o início da primeira verificação de integridade com falha até o servidor ser marcado como não íntegro.

A janela de sucesso da verificação de integridade é calculada assim: (tempo de resposta bem-sucedida da verificação × limiar de integridade) + intervalo de verificação de integridade × (limiar de integridade - 1). Considerando um tempo de resposta bem-sucedida de 1 segundo, o resultado é (1 × 3) + 2 × (3 - 1) = 7 segundos. Esse é o tempo total desde o início da primeira verificação de integridade bem-sucedida até o servidor ser marcado como íntegro.

null

O tempo de resposta bem-sucedida da verificação de integridade é a duração entre o envio de uma solicitação de verificação de integridade e o recebimento de uma resposta. Para verificações TCP, esse tempo é negligenciável, pois apenas verificam se uma porta está ativa. Para verificações HTTP, esse tempo depende do desempenho e da carga do servidor de aplicação, mas normalmente fica dentro de um segundo.

Nomes de domínio em verificações de integridade HTTP

Ao configurar uma verificação de integridade HTTP, é possível especificar um nome de domínio. Alguns servidores de aplicação exigem que o cabeçalho host esteja presente nas solicitações. Se o servidor tiver essa exigência, configure um nome de domínio. O CLB adiciona esse nome de domínio ao cabeçalho host da solicitação de verificação de integridade. Se esse cabeçalho estiver ausente, o servidor pode rejeitar a solicitação, causando falha na verificação de integridade.

Portanto, se o servidor de aplicação valida o campo host, configure o nome de domínio para garantir que as verificações de integridade sejam aprovadas.

Referências

Configure verificações de integridade ao adicionar um listener. Para obter os passos específicos, consulte Configurar e gerenciar verificações de integridade do CLB.
Para dúvidas comuns sobre verificações de integridade, consulte Perguntas frequentes sobre verificação de integridade do CLB.