httpd: como atrasar dinamicamente o reencaminhamento de pedidos para o proxy?

Question

Eu tenho o Apache httpd (2.2.22) configurado como proxy reverso.

Existe uma situação na qual eu preciso colocar meu servidor da web (o receptor das solicitações de proxy) offline por alguns milissegundos. Durante esse período, o servidor da Web não deve receber solicitações, mas também não quero rejeitar solicitações.

O que eu gostaria de fazer é conseguir que o httpd atrase todas as solicitações para esse período de tempo. Nas etapas:

1. diga ao httpd para atrasar todos os pedidos até novo aviso
2. pare o servidor da web
3. inicie o servidor da web
4. continuar o encaminhamento de solicitações do httpd

Um atraso fixo também faria o truque, mas como não posso prever a quantidade real de tempo que o servidor da Web ficará off-line (além de menos de um segundo), uma abordagem dinâmica seria mais adequada.

Eu olhei como mod_proxy ou mod_balancer poderia me ajudar, mas não encontrei uma solução óbvia.

Ficarei feliz com qualquer indicação que você possa me dar.

Editar:

Parece que uma abordagem estática é suficiente. Alguns recursos úteis:

• link
• link
• ProxyPass com mod_rewrite (não é necessário usar ProxyPass explicitamente; não é necessário usar ProxyPassInterpolateEnv)
• Veja também este post para uma discussão sobre o httpd retornando 503 imediatamente (proxy e balanceador).

Solução alternativa:

Nós estaremos implantando systemd em nossos servidores. O systemd resolverá meu problema porque ele pode reter solicitações em soquetes que estão fechados em uma extremidade. Isso significa que, quando eu parar o servidor de back-end por um curto período de tempo, todos os pedidos serão enfileirados até eu iniciá-lo novamente e conectar-me ao soquete. Isso é o que eu chamo de elegante:)

    

Answer 1

A diretiva ProxyPass aceita muitos parâmetros para configurar como a conexão é tratada com o servidor backend.

Entre esses parâmetros, você pode se interessar por:

• connectiontimeout <n> : O número de segundos que o Apache espera pela criação de uma conexão com o backend para ser concluída.
• timeout <n> : O número de segundos que o Apache espera por dados enviados por / para o backend.
• ttl <n> : Tempo para viver para conexões inativas e entradas do conjunto de conexões associadas, em segundos.

Uma solução melhor seria ter vários servidores de back-end e equilibrar a carga nos membros e detecta servidores offline usando o parâmetro ping . Então, quando você reinicia um servidor backend, outro pode fazer o relay.

    

Answer 2

Em vez do Apache, você pode usar o Iptables em seu servidor da Web para obter isso da seguinte maneira:

1. descartar novas conexões (tcp-SYNs) para o servidor da Web
2. reiniciar servidor da web
3. aceitar novamente todas as conexões

Como as novas conexões são silenciosamente descartadas pelo firewall, o proxy reverso continuará a enviar novamente o tcp-syn para o servidor web. Conexões estabelecidas não serão afetadas.

Se o ciclo for concluído em menos de um segundo, os novos clientes verão um atraso de (exatamente) 1 segundo, igual ao atraso da primeira tentativa de SYN

Exemplo de configuração do iptables (diga que a cadeia INPUT tem uma política ACCEPT vazia):

/sbin/iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 80 -j DROP

depois de reiniciar o servidor da Web:

/sbin/iptables -F

Você também pode aplicar a política na cadeia OUTPUT do proxy reverso, mas a sincronização rápida das ações pode ser mais desafiadora.

    

Answer 3

Uma abordagem de baixa tecnologia, semelhante à proposta do iptables, mas completamente transparente para os clientes: basta interromper o apache com kill -stop e reiniciá-lo com kill -cont . Dependendo da quantidade de pacotes recebidos, o kernel deve armazenar em buffer tudo por este curto período de tempo. Provavelmente este buffer pode até ser configurado.

    

Answer 4

Se for apenas para ficar em stasis por alguns milissegundos, basta usar um reinício do Apache. Já tem essas propriedades

• solicitações em andamento que uma das conexões existentes pode concluir
• novas conexões ficarão no backlog de escuta por um segundo ou mais