アプリケーションロードバランサ って知ってる?
本日の障害は、ロードバランサ(LB)です。
LBがロードバランスするのって、こんな感じ
client⇒ 仮想IP ［LB］→ リアルサーバ1のリアルIP
＋ → リアルサーバ2のリアルIP
1.Clientは、仮想IPに対し、なにがしかのリクエストをします。(HTTP通信等)
2.そうすると[LB]左側に書いてある、仮想IPのところに通信がきます。
3.LBは、仮想IPに対応するリアルサーバ1,2の内、暇そうなやつに、トラフィックを流してやります。
これは、ラウンドロビンや、リーストコネクション等々という方式があります。
ラウンドロビン、順番に1.→2.→1.→2.といった感じ
リーストコネクション=コネクション数が少ないほうにトラフィックを流します。
4.リアルサーバから、応答があった場合、クライアントに応答を返します。
この時に、どちらのサーバーからの応答かを覚えるために、工夫をしています。うちの場合、Cookie-Insertを利用しています。
Cookie-Insertは、たとえば、リアルサーバ1なら、xxxaというIDをつけて、リアルサーバ2ならxxxbをつけてあげる。ということです。
次に再リクエストが来たら、同じサーバーに流してやればよいわけですね。
5.再度Cilentから、リクエストがきます。このとき、4.でつけたCookie値をLBが見つけたら、今回のリクエストも同じサーバに流してあげる。
という動きをします。 パーシステンスと言いますね。
これがうまくできていないと、LBした時に不都合が起こりますね。ほとんどのWebアプリでは不都合が発生するはずです。
･･･これが起こっているんです。
リアルサーバ1.のWebアクセスログを見ると、あり得ないCookie値を含んだHTTPヘッダー情報が記載されている。
ここには、リアルサーバ1.のログなので、xxxaの値しかないはずなのに、xxxbの値が紛れ込んでいる。
案の定、その後の処理が止まってしまっている。つまり、サイトが正常に動作していない。ということが判明。
これが、お客さんからの問い合わせだと、何かホームページが見れない。と言ってこられるわけです。
ホームページが見れない???また、ものすごい漠然としてますね、、、、、、。
ここから、ヒヤリングと、障害切り分けを始めていくわけです、、、、、。 長くなってしまったので、続きは次回で