mod_proxy_balancerで特定のレスポンスコードを検知させる方法
お久しぶりです！田中です。 今回は自分が関わっている件で少し調査を行う必要があった件を紹介します。具体的には、mod_proxy_balancerでワーカーから特定のレスポンスコードが帰ってきた際、バランサーからワーカーを外す方法です。 Apache 2.2になりmod_proxy_balancerを使うと簡単にリバースプロキシを介した負荷分散＋冗長化が行えるようになりました。ワーカーサーバーが停止した（応答が返ってこない）場合には自動的に分散先から外すなど便利な機能も有しており、便利に使いこなしている方も多いことでしょう。 一応mod_proxy_balancerの紹介を行っておくと、mod_proxyおよびmod_proxy_httpを利用したリバースプロキシ構成に対し、ロードバランサー機能を提供するものです。実績も豊富にあり、簡単な構成ならApacheの設定ディレクティブも最小限の追
mod_proxy_balancerとmod_rewriteでバランシング - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年11月27日23:58 Apache mod_proxy_balancerとmod_rewriteでバランシング Apache を使って条件付きでバランシングしたいときー。mod_proxy_balancer と mod_rewrite を使ってこんな風にしてあげればいいのかなぁ。(oﾟωﾟo) RewriteEngine on RewriteRule ^/hoge(.*)$ balancer://balancer_1$1 [P,QSA] RewriteRule ^/fuga(.*)$ balancer://balancer_2$1 [P,QSA] <Proxy balancer://balancer_1> BalancerMember http://192.168.0.100:4000 loadfactor=10 BalancerMember http://192.168.0.
眠る開発屋blog » Blog Archive » mod_proxy_balancerに独自振り分けロジックを追加できる気がする
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 まず、mod_proxy_balancerの
[ThinkIT] 第5回：サーバの追加とロードバランシング (1/2)
さて、サービスがオープンしてしばらく経ってくるとトラフィックも増えて、アプリケーションサーバーの負荷が高くなってくることでしょう。そこで、アプリケーションサーバーを増やすことになります。同じ構成のアプリケーションサーバーをもう一台作って対応します。 ここでふと気づくわけですが、Webサーバーがproxy×1＋mod_perl×1の場合は、クライアントから受け付けたリクエストを振り分けて処理するといったことは意識する必要がありませんでした。 しかし、proxy×1＋mod_perl×2になると、リクエストを受け取ったリバースproxy側では、どちらのアプリケーションサーバーにリクエストを転送するかを考慮する、つまりロードバランシングをする必要が出てきます。 結論から言うと、ロードバランシングもリバースproxyでやってしまうことができます。 Apache 2.2にはmod_proxy_bal
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mod_proxy_balancer - Apache-2.2
http://www.res-system.com/weblog/item/618