web-dev-qa-db-ja.com

httpd：プロキシへのリクエスト転送を動的に遅らせる方法は？

Apache httpd（2.2.22）をリバースプロキシとして構成しています。

Webサーバー（プロキシされたリクエストの受信者）を数ミリ秒間オフラインにする必要がある状況があります。この間、Webサーバーはリクエストを受信しないはずですが、リクエストを拒否したくありません。

私がやりたいのは、どういうわけかhttpdにその期間のすべてのリクエストを遅らせることです。ステップで：

  1. 追って通知があるまですべてのリクエストを遅らせるようにhttpdに指示します
  2. webサーバーを停止します
  3. webサーバーを起動します
  4. httpdからのリクエスト転送を続行します

固定の遅延でもうまくいきますが、Webサーバーがオフラインになる実際の時間（1秒未満になることを除いて）を予測できないため、動的なアプローチの方が適しています。

Mod_proxyまたはmod_balancerがどのように役立つかを見てきましたが、明白な解決策は見つかりませんでした。

私はあなたが私に与えることができるどんなポインタについても幸せになります。

編集：

静的なアプローチで十分なようです。いくつかの役立つリソース：

代替ソリューション：

systemd をサーバーにデプロイします。 systemdは、一方の端が閉じているソケットでリクエストを保持できるため、私の問題を解決します。つまり、バックエンドサーバーを短時間停止すると、サーバーを再起動してソケットに接続するまで、すべてのリクエストがキューに入れられます。それは私がエレガントと呼んでいるものです:)

apache-2.2proxyhttpdmod-proxysystemd
2
Max Leske

ProxyPass ディレクティブは、バックエンドサーバーでの接続の処理方法を構成するための多くのパラメーターを受け入れます。

これらのパラメータの中で、次のことに興味があるかもしれません。

  • connectiontimeout <n>：バックエンドへの接続の作成が完了するのをApacheが待機する秒数。
  • timeout <n>：Apacheがバックエンドとの間で送受信されるデータを待機する秒数。
  • ttl <n>：非アクティブな接続および関連する接続プールエントリの存続時間（秒単位）。

より良い解決策は、複数のバックエンドサーバーを用意し、 members で負荷を分散し、pingparameterを使用してオフラインサーバーを検出することです。したがって、バックエンドサーバーを再起動すると、別のサーバーがリレーを使用する可能性があります。

2
Spack

Apacheの代わりに、WebサーバーでIptablesを使用して、次の方法でこれを取得できます。

  1. 新しい接続（tcp-SYN）をWebサーバーにドロップします
  2. webサーバーを再起動します
  3. すべての接続を再承認します

新しい接続がファイアウォールによってサイレントにドロップされると、リバースプロキシはtcp-synをWebサーバーに再送信し続けます。確立された接続は影響を受けません。

サイクルが1秒未満で完了すると、新しいクライアントには、最初のSYN再試行までの遅延に等しい（正確に）1秒の遅延が表示されます。

Iptables configの例（INPUTチェーンに空のACCEPTポリシーがあるとします）：

/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

webサーバーを再起動した後：

/sbin/iptables -F

リバースプロキシのOUTPUTチェーンにポリシーを適用することもできますが、アクションの迅速な同期はより困難な場合があります。

1
Zabuzzman

Iptablesの提案に似ていますが、クライアントに対して完全に透過的なローテクアプローチ：Apacheをkill -stopで停止し、kill -contで再起動するだけです。着信パケットの量に応じて、カーネルはこの短時間の間すべてをバッファリングする必要があります。おそらく、このバッファリングを構成することもできます。

0
Hauke Laging

数ミリ秒間だけ停滞することを意図している場合は、Apacheの正常な再起動を使用してください。それはすでにこれらの特性を持っています

  • 1つの既存の接続が完了できる進行中のリクエスト
  • 新しい接続は、1秒ほどリッスンバックログに残ります
0
covener