負け組アーキテクトの憂鬱 : mod_proxy_balancerのstickysessionは大文字小文字を区別する
2007年06月04日22:49 カテゴリApache httpd mod_proxy_balancerのstickysessionは大文字小文字を区別する 何事もなかったように記事再開。 で、何が困ったかというと、apache httpd-2.2.4に添付のmod_proxy_balancerの挙動。 mod_proxy_balancerについてはこちら。要はmod_proxy系の各種モジュールでproxy先をバランシングできるわけですな。mod_proxy_balancer自体はかなり汎用性のあるモジュールなんだけど、今回困った用途はmod_proxy_ajpとの組み合わせ、つまりmod_jk(2)の代用として使ったときのこと。 たとえばweb層をapache(+mod_ajp +mod_proxy_balancer)の1台、ap層をtomcatの2台構成にしたとき、かつstatefu
Tomcat > クラスタ構成の Tomcat をApacheでロードバランスする
動作環境 このページでは以下の環境での動作を説明しています。 Debian Linux Etch Apache2.2.3 Tomcat5.5 J2SDK 5.0 Update10 ロードバランサの必要性 Tomcatでクラスタリングを行うことで、セッション情報の共有が行われます。これによって使用中のTomcatがダウンしても、別のTomcatに接続することでセッションを継続することができるはずです。 しかし、これは現実的でありません。使用中のTomcatが動作を停止したとき、ユーザーはブラウザのURLを手で書き換えて稼働中のTomcatに明示的につなぎに行く必要があります。しかも、通常セッションIDはcookieに格納されています。これではURLが変更した場合セッションIDが取得できません。つまり、cookieが無効になっていてURLにセッションIDが組み込まれているときに、手作
[ThinkIT] 第1回：Tomcatによるクラスタリングの実現 (1/4)
現在、エンタープライズ環境で動作するアプリケーションサーバには様々なものがありますが、どれもデフォルトでクラスタリングの機能を搭載しているものがほとんどです。 クラスタリングを行う目的としては主に2つあげられます。1つはパフォーマンスの向上で、もう1つは可用性の向上です。まずは、これらの機能について解説していきます。 開発したアプリケーションに対して非常に多数のアクセスがあった場合、1台のサーバでは処理がまかないきれなくなります。 そういった場合には、前段にロードバランサを配置することで複数台に処理を振り分ければよいのですが、ECサイトなどでログインユーザのセッション情報などを保持しているアプリケーションが動作している場合、最初にログインしたサーバとは違うサーバに処理が移った場合セッション情報が共有されていないと継続して処理を行うことができなくなってしまいます。 こういった場合でもクラスタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
