Verificação de integridade do Apache mod_proxy_balancer

Question

Eu tenho 3 servidores web Apache instalados atrás de outro servidor Apache executando o mod_proxy_balancer.

Durante hoje, um dos servidores da web foi reinicializado. Demorou cerca de 16 minutos para reiniciar.

Durante esse tempo, posso ver a seguinte linha de log a cada 30 segundos no log de erros do meu servidor mod_proxy_balancer do Apache

[Tue Sep 30 07:04:42 2014] [error] ap_proxy_connect_backend disabling worker for (s1-sc1-c-use)

Isso é registrado 32 vezes durante a interrupção de 16 minutos

Estou tentando descobrir o que está acontecendo aqui. Minha preocupação é que, devido a deficiências na configuração do meu balanceador, o balanceador está repetidamente tentando enviar solicitações para o servidor de reinicialização (e, portanto, retornando erros para o usuário).

Por que o Apache está me dizendo repetidamente que está "desativando o trabalhador"? O módulo do balanceador envia intermitentemente solicitações do usuário ao nó com falha, para tentar determinar se ele está de volta ou possui seu próprio mecanismo interno de verificação de integridade que é invisível para o usuário?

    

Answer 1

OK. Eu posso explicar isso.

O mod_proxy_balancer do Apache não possui seu próprio mecanismo independente de verificação de integridade. O estado dos Membros do Balanceador (trabalhadores) é determinado com base no resultado de solicitações reais de usuários encaminhados.

A sequência é a seguinte:

1. O http do Apache envia uma solicitação ao trabalhador
2. O trabalhador não responde ou responde com o status HTTP que aciona o failover e coloca o membro no estado ERR
3. O http do Apache inicia o contador de novas tentativas (padrão 60 segundos) e não envia mais solicitações até que o tempo de repetição da tentativa expira
4. Quando o tempo de repetição expirar, volte para o Passo 1 em sequência

Meu valor de repetição é de 60 segundos (padrão).

O motivo pelo qual estou vendo várias entradas de log é que meu Balancer httpd do Apache está configurado com vários balanceadores, cada um com seu próprio temporizador de novas tentativas independentes.

Assim, dependendo da atividade do aplicativo, os timers de nova tentativa estão sendo redefinidos arbitrariamente e sendo testados arbitrariamente, o que explica a distribuição não uniforme das atualizações de status do trabalhador no log.