[ThinkIT] 第5回：サーバの追加とロードバランシング (1/2)
さて、サービスがオープンしてしばらく経ってくるとトラフィックも増えて、アプリケーションサーバーの負荷が高くなってくることでしょう。そこで、アプリケーションサーバーを増やすことになります。同じ構成のアプリケーションサーバーをもう一台作って対応します。 ここでふと気づくわけですが、Webサーバーがproxy×1＋mod_perl×1の場合は、クライアントから受け付けたリクエストを振り分けて処理するといったことは意識する必要がありませんでした。 しかし、proxy×1＋mod_perl×2になると、リクエストを受け取ったリバースproxy側では、どちらのアプリケーションサーバーにリクエストを転送するかを考慮する、つまりロードバランシングをする必要が出てきます。 結論から言うと、ロードバランシングもリバースproxyでやってしまうことができます。 Apache 2.2にはmod_proxy_bal
mod_proxy_balancerとSet-CookieヘッダのPath属性 - Do You PHP はてブロ
ちょっと調べてみたら、書き換えるためのディレクティブが用意されてました。同様にProxyPassReverseCookieDomainディレクティブもあります。 ProxyPassReverseCookiePath ディレクティブ 使用法は基本的に ProxyPassReverse と同じですが、ヘッダの URL の代わりに Set-Cookie ヘッダの path 文字列を書き換えます。 たとえば、 フロント：Apache2.2（mod_proxy＋mod_proxy_http＋mod_proxy_balancer） バックエンド：Apache2.2（PHP） のような構成でバランシングしている場合で、バランシングの設定が LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/m
Apache 2.2でWebサイトをパフォーマンスアップ！（3/3） － ＠IT
Apache 2.2でWebサイトをパフォーマンスアップ！ － 最新Apacheの機能と設定方法教えます － 鶴長 鎮一（book@tsurunaga.jp） 2006/3/14 ロードバランスクラスタを使う Apacheには、レスポンスの遅いサーバの代わりに応答するプロキシ機能が提供されています。Apache 2.0でも、通常のフォワードプロキシおよびWebサーバの負荷分散を可能にするリバースプロキシに対応していました。 Apache 2.2ではリバースプロキシ機能をさらに高め、トラフィック量やリクエスト回数に応じたロードバランシングが可能になっています。ロードバランスされるバックエンドサーバは、Apacheを再起動することなくオン／オフラインにできます。バックエンドサーバがダウンした場合は、自動的にそのサーバを切り離し、復旧後自動的に復帰させるといったことも可能です。 ■ロードバランス
YappoLogs: Apache 2.2.0 のロードバランス機能(mod_proxy_balancer)を使いこなす
Apache 2.2.0 のロードバランス機能(mod_proxy_balancer)を使いこなす Apache 2.2がでました。 mod_dbdとか、mod_proxy_balancerとか気になる新機能てんこ盛りです。 ひげぽんさんの所に 誰か入れてみた人いますか？ と有ったのでmod_proxy_balancerを試してみました。 超簡単でした mod_proxyとmod_proxy_balancerを参考にしました。 既に日本語ドキュメント完備！ 以下から駆け足で、またセキュリティ的によろしくない設定例が多々あります。 とりあえずこんな設定を仕込んでみました ProxyPass /lb balancer://TEST stickysession=sesid <Proxy balancer://TEST> #1 BalancerMember http://i.yappo.jp lo
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 今回は、ProxyPassディレクテ
GIGAZINEが20日（土）から21日（日）にかけて新サーバに移転します
サーバのカスタマイズで乗り切る限界を突破してしまったため、GIGAZINEは今から新サーバに移転します。新サーバ移転後、何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向けです。 まず旧サーバは「Dell PowerEdge 850」を利用しており、以下のようなスペックです。よくありがちな構成。 ◆旧GIGAZINE.NETサーバ CPU：Intel PentiumD 930 HDD：73GB(SCSI RAID1) メモリ：2GB ネットワーク：2Mbps OS：Red Hat Enterprise Linux ES3 これが以下のようなスペックの「NEC Express5800 120GR-1c」になります。これもありがちな構成。 ◆新GIGAZINE
selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理
404 Blog Not Found:perl - BSD::getloadavg
2006年10月26日20:30 カテゴリLightweight Languages perl - BSD::getloadavg レポートを受け追記; BSD::Sysctlのことも追記 この部分がなんとも惜しいような気がしたので書きました。 Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする my ($ldavg1, $ldavg2, $ldavg3) = `uptime` =~ /load average:\s+([.0-9]+),\s+([.0-9]+),\s+([.0-9]+)/; BSD::getloadavg CPAN http://www.dan.co.jp/~dankogai/cpan/BSD-getloadavg-0.01.tar.gz これで当該部分は、 #!/usr/bin/perl use strict; use
mod_proxy_balancerのretry : blog.nomadscafe.jp
mod_proxy_balancerのretry mod_proxy_balancer(mod_proxy)のretry設定は、 コネクションをプーリングするための、リトライのタイムアウトを秒で 指定します。バックエンドサーバへのコネクションプーリングが失敗した場合は、 タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。 というもので、 BalancerMember http://1.2.3.6:8000 retry=60 loadfactor=10 こんなように書ける。 アプリケーションサーバにデプロイするときに、 httpdの停止 rsync httpdの開始 という順番で行うのが通常だと思うけど、デフォルトのretry間隔が60秒になっているため、httpdを開始してからアクセスがバックエンドに届くには、最大1分間待たなければならない。 バックエンドのサーバ
mod_perl 2.0.2 へのマイグレーション - naoyaのはてなダイアリー
mod_perl 2 が Stable リリースになって気がつけば半年以上経った様子。はてなではこれまで mod_perl 2 は mod_perl 2.0RC-4 (1.99) とかを使ってましたが、ぼちぼち 2.0 にちゃんと移行した方がいいかなと、重い腰を上げつつ作業してます。 現在、mod_perl には互換性のない三つのバージョンが存在してます。 mod_perl 1.0 (1.29) mod_perl 1.99 mod_perl 2.0 (2.0.2) 1.0 は Apache 1.3 の API に対応している mod_perl、1.99 と 2.0 は Apache 2.0 API に対応している mod_perl です。Apache 2.0 がそれまでのバージョンとの API の互換性を捨ててアーキテクチャの見直しが行われたのをきっかけに、mod_perl も後方互換性を
10分で完了、mod_perl 2.0 で Hello, World! - naoyaのはてなダイアリー
10分で、といいながらたぶん mod_perl と Apache2 をビルドするのに 10 分以上かかるという罠。まあいいや。以下のやり方で Linux、MacOSX どちらでもちゃんと動くと思われます。 まず、mod_perl 2.0 のインストール。DSO でもいいけど、ここでは Apache にスタティックに組み込みます。 インストールディレクトリは /usr/local/httpd_mp2 に。 MPM は prefork。perl を thread 有効でビルドしてるなら mpm=worker でもいいと思います。 $ wget http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz $ wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz $ tar zxvf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
井上の日誌 -Apacheの話-(2006-07-13) - Apacheソースコード概論
Скачать лучшие программы и приложения для Windows, Android, iOS и MacOS — бесплатно с сайта MyDiv