「Linux Virtual Server」と「Keepalived」で作る冗長化ロードバランサ
ロードバランサの冗長化
最後に、2台のロードバランサを使用してロードバランサ自体の冗長化を行う設定について説明しておこう。この場合、ネットワーク構成は次の図3のようになる。
ここで注目したいのが、こちらの構成の場合、ロードバランサ1のLAN側NICであるeth1にも2つのIPアドレスが割り振られている点だ。Keepalivedを使用したロードバランサの冗長化では、IPアドレスの付け替えによって通信経路を確保する仕組みになっている。この構成では、ロードバランサ1が何らかの原因で停止した場合、ロードバランサ2のeth0に203.0.113.100、eth1に192.168.100.100というIPアドレスが割り振られるよう設定が変更される。クライアントは203.0.113.100に対してリクエストを送信するため、IPアドレスが移動するとともに、リクエストは稼働しているロードバランサ2に向けて送信されるようになる。また、サーバー側はデフォルトゲートウェイとして192.168.100.100を利用するよう設定しておくことで、サーバーからクライアントへの通信もロードバランサ2を経由して行われるようになる。
なお、ロードバランサの死活監視には、VRRPと呼ばれるプロトコルが使用される。詳細については割愛するが、VRRPでは一定間隔でネットワークにロードバランサが稼働していることを示すパケットを送信することでロードバランサの死活監視を行う。待機しているバックアップ用のロードバランサは、もし一定時間内にこのパケットを受信できなければマスター側のロードバランサが停止したと判断、自分がロードバランス処理を行うようNICに対しIPアドレスの割り振りを実行する。
Keepalived.confの設定
それでは、このようなロードバランサの冗長化を行うためのKeepalivedの設定について見ていこう。まず、ロードバランサとして使用するすべてのマシンにKeepalivedをインストールし、LVSによるロードバランシングが行えるように適切にネットワークの設定を行っておく。次に、各マシンのKeepalived.confを次のように設定する。
! Configuration File for Keepalived
global_defs {
notification_email {
hirom@example.org ←通知メールの送信先メールアドレスを指定
}
notification_email_from hirom@example.org ←通知メールの送信元メールアドレスを指定
smtp_server 203.0.113.200 ←メール送信に使用するSMTPサーバーのIPアドレスを指定
smtp_connect_timeout 30
router_id LVS_DEVEL ←ロードバランサを識別するための名前を指定
}
vrrp_instance Sakura { ←VRRP設定名を指定
state BACKUP ←「BACKUP」もしくは「MASTER」を指定
interface eth0 ←クライアントが接続する側のNICを指定
garp_master_delay 5 ←バックアップがマスターに昇格後、Gratuitous ARPパケットを送信するまでの待機時間を秒で指定
virtual_router_id 1 ←仮想ルーターIDを指定
priority 100 ←優先度を指定
nopreempt ←停止していたマスターが復帰した際にマスターを譲らない
advert_int 3 ←VRRP広告パケットの送信間隔を秒で指定
authentication { ←認証に関する設定
auth_type AH ←認証タイプとしてIPsec AHを使用
auth_pass sfjpvrrp ←認証用のパスワード文字列
}
virtual_ipaddress { ←使用する仮想IPアドレスを指定
133.242.98.142 dev eth0 ←eth0側のIPアドレスを指定
192.168.100.100/24 dev eth1 ←eth1側のIPアドレスを指定
}
}
virtual_server 203.0.113.100 80 { ←対象とする仮想サービスを指定
delay_loop 5 ←死活監視のためのポーリング間隔を秒で指定
lvs_sched rr ←負荷分散方式を指定
lvs_method NAT ←パケットの転送方式を指定
protocol TCP ←対象とするプロトコルを指定
sorry_server 192.168.100.20 80 ←サーバーがすべて停止した場合のパケット転送先を指定
real_server 192.168.100.21 80 { ←仮想サービスに対応するサーバーを指定
weight 1 ←負荷分散の重みを指定
inhibit_on_failure ←サービスが停止した場合には重みを0にする
HTTP_GET { ←ポーリングに使用するプロトコルを指定
url {
path / ←ポーリング先URLを指定
status_code 200 ←正常な場合に返されるステータスコードを指定
}
connect_timeout 5 ←ポーリングのタイムアウト時間を秒で指定
nb_get_retry 3 ←リトライ回数を指定
delay_before_retry 3 ←リトライ時に待機する時間を秒で指定
}
}
real_server 192.168.100.22 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 5
nb_get_retry 3
delay_before_retry 3
}
}
}
ここで、ロードバランサの冗長化を行うための設定項目が「vrrp_instance」だ。これ以外の部分は、先のロードバランサを冗長化しない場合の設定と同一になっている。原則としてどのロードバランサでも同一の値を指定するが、「state」および「priority」の値についてのみ、ロードバランサごとに異なる値を指定する。まずstateの値だが、これは初期状態でマスタとして使用するロードバランサを指定するものだ。基本的には、ローバランサのうち1台のみがMASTERに指定され、それ以外はすべてBACKUPを指定しておく。また、priorityはマスターとなっているロードバランサが停止した場合に、次にマスターとなるロードバランサを決定するための値だ。マスターの停止時、バックアップとして用意されたロードバランサのうちpriorityの値が高いものが優先的にマスターに昇格する仕組みだ。
設定変更を行ったら、Keepalivedを再起動して設定を反映させておく。
サーバー側の設定
サーバー側では、先に述べたとおりロードバランサに割り当てられた仮想IPアドレスをデフォルトゲートウェイとして使用するように設定を変更しておく。それ以外の設定は特に必要ない。
すべての設定が完了したら、クライアントから仮想IPアドレスに対してリクエストを送信し、正しく負荷分散が行えているか確認しておこう。また、マスターとして稼働しているロードバランサを停止させた場合に正しくバックアップ側のロードバランサに仮想IPアドレスが移っているかも確認しておく。
安価かつ柔軟なロードバランサ構築が可能
専用のハードウェアロードバランサは非常に高価であるが、LVSやKeepalivedを利用すれば、このように比較的容易に冗長性のあるロードバランサを構築できる。今回は代表的な設定例のみを解説したが、LVSもKeepalivedも多くの設定項目を用意しており、必要に応じてさまざまな構成を実現できる。本記事を参考に、それぞれのドキュメントを参照して目的に応じた構成を検討してほしい。
おしらせ
