UltraMonkey-L7でロードバランサー構築 その４
UltraMonkey-L7(以下UM-l7)構築の続き第４弾。前回は起動までできたので
今回はバランシングがされているのか確認。
とりあえず毎度の構成図を。
まずは、設定ファイル(/etc/ha.d/conf/l7directord.cf)のvirtualの項目を変更。
# diff l7directord.cf.20091115 l7directord.cf 32c32 < virtual = 127.0.0.1:80 --- > virtual = 192.168.100.204:80 |
最初はlookbackのIPを指定していましたが、これだと外部サーバからHTTPリクエストを
受け付けてくれなかったので、UM-L7をインストールしているサーバのIPに変更。
(hostA,Bには、静的なページでそれぞれHostA,HostBと文字列を記述しています)
複数回hostA,Bにtelnetしてみる。
# telnet 192.168.100.204 80 Trying 192.168.100.204... Connected to 192.168.100.204 (192.168.100.204). Escape character is '^]'. GET / HTTP1.0 HTTP/1.1 200 OK Date: Sat, 14 Nov 2009 16:27:20 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 Last-Modified: Sat, 07 Nov 2009 16:59:14 GMT ETag: "4e08650-33-477cae14f1c80" Accept-Ranges: bytes Content-Length: 51 Connection: close Content-Type: text/html <html><body><h1>It works! HostB</h1></body></html> Connection closed by foreign host. # telnet 192.168.100.204 80 Trying 192.168.100.204... Connected to 192.168.100.204 (192.168.100.204). Escape character is '^]'. GET / HTTP1.0 HTTP/1.1 200 OK Date: Sat, 14 Nov 2009 16:30:49 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 Last-Modified: Sat, 07 Nov 2009 16:58:41 GMT ETag: "4e00607-33-477cadf579240" Accept-Ranges: bytes Content-Length: 51 Connection: close Content-Type: text/html <html><body><h1>It works! HostA</h1></body></html> Connection closed by foreign host. |
それぞれバランシングされているようです。どのようにバランシングされているかは
l7vsadmコマンドで確認することができます。
# l7vsadm -l Layer-7 Virtual Server version 2.1.3-0 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.100.204:http sessionless rr -> 192.168.100.102:http Masq 1 0 3 -> 192.168.100.103:http Masq 2 0 2 |
バランシングされるメンバーの状態が確認できます。LVSでみれるやつと一緒ですね。
バランシングの重みや現在の接続状況、何回リクエストがあったかが確認できます。
現在の詳細設定を見る場合は
# l7vsadm -V Layer-7 Virtual Server version 2.1.3-0 L7vsd Log Level: Category Level l7vsd_network warn l7vsd_network.bandwidth warn l7vsd_network.num_connection warn l7vsd_network.qos warn l7vsd_virtual_service warn l7vsd_real_server warn l7vsd_sorry_server warn l7vsd_real_server.balancing warn l7vsd_replication warn l7vsd_start_stop warn l7vsd_system warn l7vsd_system.memory warn l7vsd_system.socket warn l7vsd_system.signal warn l7vsd_environment warn l7vsd_environment.parameter warn l7vsd_logger warn l7vsd_parameter warn l7vsd_event warn l7vsd_schedule warn l7vsd_program warn l7vsd_protocol warn l7vsd_module warn Replication Mode: SINGLE SNMPAgent Connection Status: non-connecting SNMPAgent Log Level: Category Level snmpagent_start_stop warn snmpagent_manager_receive warn snmpagent_manager_send warn snmpagent_l7vsd_receive warn snmpagent_l7vsd_send warn snmpagent_logger warn snmpagent_parameter warn Prot LocalAddress:Port ProtoMod Scheduler Reschedule Protomod_opt_string SorryAddress:Port Sorry_cc Sorry_flag QoS-up Throughput-up QoS-down Throughput-down -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.100.204:http sessionless rr 1 192.168.100.102:http 1000 0 100000000 0 100000000 0 -> 192.168.100.102:http Masq 1 0 3 -> 192.168.100.103:http Masq 2 0 2 |
こんな感じで設定内容が見れます。
次に、hostBのApacheを停止してメンバーの確認をしてみました。
# l7vsadm -l Layer-7 Virtual Server version 2.1.3-0 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.100.204:http sessionless rr -> 192.168.100.102:http Masq 1 0 3 |
メンバーからちゃんといなくなってます。この後hostBのapacheを再度あげてみたら
数秒でメンバーとして復帰しました。じゃあ同時に２つのapacheを停止したら？
# l7vsadm -l Layer-7 Virtual Server version 2.1.3-0 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.100.204:http sessionless rr |
はい、誰もいなくなりましたw当たり前w
もしかしたらl7directord.cfの項目で、sorryserverはメンバーがいなくなったときに
どこか別サーバに繋ぐのか？ってのを設定できるのかも？
と、思ったら管理ドキュメントに
(4) sorryserver
VirtualService が sorry 状態になった際に振り分けられる Sorry サー
バの IP アドレス、ポート番号を指定する
(例: sorryserver = 192.168.1.101:80)
と、書いてあるので当たりですね。試しにここを変更(sorryserver = 192.168.100.101)して試してみた。
ESXi VM# l7vsadm -l Layer-7 Virtual Server version 2.1.3-0 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.100.204:http sessionless rr # telnet 192.168.100.204 80 Trying 192.168.100.204... Connected to 192.168.100.204 (192.168.100.204). Escape character is '^]'. GET / HTTP1.0 HTTP/1.1 200 OK Date: Sat, 14 Nov 2009 16:54:17 GMT Server: Apache/2.2.14 (Unix) Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT ETag: "4d48020-2c-3e9564c23b600" Accept-Ranges: bytes Content-Length: 44 Connection: close Content-Type: text/html <html><body><h1>It works!</h1></body></html>Connection closed by foreign host. |
ちゃんと動作しているみたい。ふむふむこれを使えば最悪の障害時にでもなんとかページを表示できるなぁ。
今回は実際の動作を超簡単に確認してみました。ほぼデフォルト設定でここまでできるとは
正直思ってもいませんでしたw簡単だこれ。
それにしてもLB(Webサーバと同一セグメント上に配置)を使ったシステムだと
サーバのGWをLBに指定していたりしないと、レスポンスを返せなかったけど
UM-l7はそれが必要ない。。。あれ？なんでだ？同一セグメントからやってるからかな。。。
さて、次回はちょっと今の状態で負荷テストでもしてみようと思います。
2009/11/16 月曜日 at 00:12
お猿の中の人です．実際に使っていただいているのをみると，嬉しくなりますね．
リアルサーバのゲートウェイに LB を指定しなくても良いのはなぜか，といった質問にたいしてお答えします．
UM-L7 の場合，実装上の仕様で TCP セッションが下記の通り 2 つに分かれます．
(Client) (LB) (RealServer)
＃ Apache のアクセスログをみてみると，クライアントの IP アドレスが
＃ LB の IP アドレスになっているはずです．
つまり，UM-L7 の場合は
○ クライアントと LB の間
○ リアルサーバから LB まで間
の 2 点がそれぞれ到達できることが保証されれば良いので，リアルサーバのデフォルトゲートウェイとして必ずしも LB を指定する必要がないのです．
リアルサーバのデフォルトゲートウェイに LB を指定する必要があるのは，LB とリアルサーバが別セグメントのネットワークにいるときくらいでしょうか．
2009/11/16 月曜日 at 00:20
すみません，間違えました．
＞ リアルサーバのデフォルトゲートウェイに LB を指定する必要があるのは，LB とリアルサーバが別セグメントのネットワークにいるときくらいでしょうか．
これ，言っている意味が訳分かりませんね（汗
とにかく，リアルサーバから LB に到達できれば OK なのです．
2009/11/16 月曜日 at 21:46
コメントありがとうございます。
中の方にコメントを頂けるなんてとてもとても光栄です。
大したエンジニアでもないのでお恥ずかしい限りですw
Apacheのログを確認してみたところ、確かにUM-L7をインストールしているサーバのIPでした。
なるほど、Client-LB間とLB-RealServer間はコネクションを張り直している感じなのかな。
（感覚なのでうまく説明ができませんがw）
BIG-IP等を構築・運用で携わっていますが、この辺の違いを見直してみるいい機会になりそうです。
今後ともアドバイスよろしくお願いします。