小型/堅牢/メンテナンスフリー OpenBlockS 600の限界に挑戦

第3回 LVSによる堅牢で安価なロードバランサ(後編)

この記事を読むのに必要な時間:およそ 6 分

LVSの設定とパフォーマンス

前回の前編では,WebサーバのLVS(Linux Virtual Server)をめざして,仮想サーバのロードバランサとリアルサーバ,接続確認用のクライアントを用意しました。ロードバランサとなるOpenBlockS 600には,Debianをインストールして,ipvsadmとkeepalivedパッケージを追加インストールしました。リアルサーバにはApacheをインストールして,Webサーバとして動作させています。LVSの設定はしないままで,クライアントからリアルサーバへの接続を確認して,おしまいとなりました。

今回の後編では,LVSの設定を手動と自動の二通り説明します。まず,IPVSの設定をipvsadmコマンドで手動で行い,負荷分散の様子を見てみます。それから,Keepalivedを設定,動作させ,リアルサーバのダウンと復旧に対処しながらWebサービスが続けられることを確認します。

最後に,どの程度の負荷分散の効果があるのか,ベンチマークをとってみます。

IPVSの構築

OpenBlockS 600でipvsadmコマンドをオプションなしで実行してください。図1のとおり表示されるはずです。

図1 ipvsadmコマンドの実行結果

obs600# ipvsadmIP Virtual Server version 1.2.1 (size 4096)
Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConnInActConn

もし,図2のようにip_vsモジュールがみつからないというエラーが出たら,カーネルモジュールの依存性リストを更新します図3)⁠

図2 ip_vsモジュールがみつからない

obs600# ipvsadmFATAL: Module ip_vs not found.
Can t initialize ipvs: Protocol not availableAre you sure that IP Virtual Server is built inthe kernel or as module?

図3 カーネルモジュールの依存性リストの更新

obs600# depmod -a

LVS-NAT

それではIPVSの設定をしていきましょう。これは,Linuxカーネル内の仮想サーバテーブルをipvsadmコマンドで編集します。以下,用語はipvsadmコマンドのマニュアルページにしたがいます。

仮想サーバテーブルの消去

まだIPVSの設定はしていませんが,図4のとおり,仮想サーバテーブルを消去するコマンドを実行しておきましょう。

図4 仮想サーバテーブルの消去

obs600# ipvsadm -C
仮想サービスの追加

仮想サービスを図5のとおり追加します。オプション-A は,仮想サービスの追加を示します。

図5 仮想サービスの追加

obs600# ipvsadm -A -t 192.168.253.120:80 -s rr

オプション-tは,TCPサービスを使用することを指定します。その値として,仮想IPアドレス192.168.253.120とWebサービスを意味するポート番号80を指定しました。

オプション-sで,リアルサーバへのスケジューリングアルゴリズム(振り分け方)を指定します。ここでは,ラウンドロビンrrを指定しました。接続要求をリアルサーバに均等に振り分けます。

スケジューリングアルゴリズムは全部で10個あります。OpenBlockS 600のカーネルでは,モジュールとしてすべて有効にしてあるので,rrの他に,wrr,lc,wlc,lblc,lblcr,dh,sh,sed,nqが指定できます。それぞれの意味は,ipvsadmコマンドのマニュアルページなどをご覧ください。

仮想サービスへのリアルサーバの追加

仮想サービスへリアルサーバを追加します図6)⁠

図6 仮想サービスへのリアルサーバの追加

obs600# ipvsadm -a -t 192.168.253.120:80 -r 172.16.14.121:80 -m 
obs600# ipvsadm -a -t 192.168.253.120:80 -r 172.16.14.122:80 -m 
obs600# ipvsadm -a -t 192.168.253.120:80 -r 172.16.14.123:80 -m

オプション-aは,仮想サービスへのリアルサーバの追加を示します。オプション-tとその値は,仮想サービス追加と同じです。オプション-rで,リアルサーバのIPアドレスとポート番号を指定します。オプション-mは,パケットフォワーディング方法がNATであることを示します。

パケットフォワーディング方法は,NATの他にダイレクトルーティング(-g)とトンネリング(-i)があります。ここでは,ネットワーク構成をNATに合わせたので,他の方法は指定できません。

仮想サーバテーブルの表示

IPVSの設定が図7のとおりになっているか確認してください。

図7 仮想サーバテーブルの表示

obs600# ipvsadm
IP Virtual Server version 1.2.1 (size 4096)
Prot LocalAddress:Port Scheduler Flags 
-> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.253.120:www rr
-> 172.16.14.123:www Masq 1 0 0 
-> 172.16.14.122:www Masq 1 0 0 
-> 172.16.14.121:www Masq 1 0 0
接続の確認

クライアントからcurlコマンドで仮想IPアドレスに接続してみてください。仮想サーバから図8のように応答があれば成功です。

図8 接続の確認

client$ curl http://192.168.253.120/
realserver3 
client$ curl http://192.168.253.120/
realserver2 
client$ curl http://192.168.253.120/
realserver1

ここでは,応答のあったリアルサーバを区別するためにコンテンツを違うものとしておきました。コンテンツを同じものにしておけば,どのリアルサーバから応答があったのか,クライアントからはわかりません。これで,Webサービスを3台のリアルサーバに負荷分散させることができました。

リアルサーバがダウンした場合

ところで,リアルサーバがダウンした場合はどうなるでしょうか。リアルサーバrealserver3のhttpdを停止して,クライアントから接続してみましょう。curlコマンドの実行結果のうちには,図9に示したとおり,リアルサーバrealserver1とrealserver2からの応答の他に,接続ができないと表示されています。これでは,クライアントが仮想サーバに接続したときに,Webサービスが受けられない場合があることになってしまいます。

図9 リアルサーバrealserver3がダウンした場合の応答

client$ curl http://192.168.253.120/
curl: (7) couldn t connect to host
client$ curl http://192.168.253.120/
realserver2 
client$ curl http://192.168.253.120/
realserver1
リアルサーバの重みを0にする

そのような場合に対処するために,仮想サービス中のリアルサーバrealserver3を図10のとおり編集してみましょう。オプション-eは,仮想サービスのリアルサーバの編集を示します。オプション-wで,重み(Weight)を指定します。リアルサーバrealserver3の重みを0にしました。

図10 リアルサーバの重みを0にする

obs600# ipvsadm -e -t 192.168.253.120:80 -r 172.16.14.123:80 -m -w 0
obs600# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.253.120:www rr
-> 172.16.14.123:www Masq 0 0 0
-> 172.16.14.122:www Masq 1 0 0

curlコマンドでの接続結果は,図11のようになります。今度は,リアルサーバrealserver1とrealserver2から応答があり,接続ができないという表示はありません。したがって,クライアントが仮想サーバに接続したときに,Webサービスが受けられないということはなくなりました。

図11 リアルサーバrealserver3がダウンした場合の応答(重み0)

client$ curl http://192.168.253.120/
realserver2 
client$ curl http://192.168.253.120/
realserver1 
client$ curl http://192.168.253.120/
realserver2

リアルサーバが復旧した場合

それでは,リアルサーバが復旧した場合はどうなるでしょうか。リアルサーバrealserver3のhttpdを開始して,クライアントから接続してみましょう。curlコマンドでの接続結果は,やはり図11のようになり,リアルサーバrealserver3からの応答がないままです。これは,リアルサーバrealserver3の重みが0のままだからです。

リアルサーバの重みを1にする

仮想サービス中のリアルサーバrealserver3を図12のとおり編集してみましょう。リアルサーバrealserver3の重みを1にしました。

図12 リアルサーバの重みを1にする

obs600# ipvsadm -e -t 192.168.253.120:80 -r 172.16.14.123:80 -m -w 1
obs600# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.253.120:www rr
-> 172.16.14.123:www Masq 1 0 0
-> 172.16.14.122:www Masq 1 0 0

curlコマンドでの接続結果は図8のようになり,すべてのリアルサーバから応答が確認できました。

コメント

コメントの記入