多数のクライアントがアクセスするような負荷の高いサービスや停止させられないサービスを運用する場合、複数のサーバーを使ってサービスの負荷分散や冗長化を行うのが一般的だ。本記事では、「Linux Virtual Server(LVS)」を使ってこのような構成を実現する方法について紹介する。
Linuxサーバーをロードバランサにする「Linux Virtual Server」(LVS)
最近では多数のCPUコアを持つサーバーが安価で利用できるようになり、サーバー1台の処理能力は飛躍的に向上している。しかし、リクエストの処理に多くのリソースを使用するようなサービスや、短時間に多数のリクエストを処理する必要があるサービスでは、1台のサーバーだけでは処理能力が不足する場合がある。このような場合、複数台のサーバーで同じサービスを運用し、ロードバランサを使ってリクエストを振り分けることで負荷の分散を図ることが多い。
ロードバランサは通常サーバーとクライアントの間に設置され、クライアントからのリクエストを受け取って一定のルールの下サーバーに振り分ける、という処理を行う。設置方法はネットワーク環境によって異なるが、ロードバランサ自体にクライアントからアクセスできるIPアドレスが与えられ、あたかもロードバランサがサービスを提供しているように見せる構成を取ることが多い(図1)。

ロードバランサは専用のハードウェア製品として提供されるほか、ロードバランサ機能が搭載されたルーター製品もある。しかし、専用ハードウェアは比較的高価であるため、安価なLinuxサーバーをロードバランサとして利用する例も多い。Linuxサーバーをロードバランサとして使用するためのソフトウェアとして有名なのが、今回紹介する「Linux Virtual Server(LVS)」だ。
ロードバランサを提供するLinux Virtual Serverと冗長化機能を提供するKeepalived
LVSはあらかじめ指定された条件に基づいてリクエストをサーバーに振り分けるという動作を行うソフトウェアだ。Linuxカーネルに組み込んで使用するカーネルモジュールと設定や管理を行うためのipvsadmコマンドから構成されており、Red Hat Enterprise Linuxやその互換ディストリビューションであるCentOSなどでは標準でカーネルにLVS機能が組み込まれている。
また、LVSは「Keepalived」と呼ばれるソフトウェアと組み合わせて利用されることが多い。LVSにはロードバランス対象を監視する仕組みが用意されていないため、もしサービスを提供するサーバー群の一部がトラブルで停止した場合でも、それらのサーバーに対しリクエストを振り分けてしまう可能性がある。Keepalivedはサービスの稼働状態を監視するソフトウェアで、サービスが停止していたらそのサーバーへのリクエストの振り分けをやめるようLVSの設定を変更する、という機能を持っている。
Keepalivedにはロードバランサ自体の稼働状況を監視し、ロードバランサが停止していたら自動的にバックアップとして用意しておいたロードバランサに切り替える機能も用意されている。ロードバランサを使っている場合、サービスを提供するサーバーが稼働していたとしても、ロードバランサ自体が停止してしまったら外部からサービスへのアクセスができなくなってしまう。keepalibedを使ってLVS自体を冗長化することで、サービスの冗長化をより完全なものとすることが可能となる。
以下ではRed Hat Enterprise Linux(RHEL) 6.3互換のCentOS 6.3を使用し、まずLVSを使った基本的なロードバランサ設定について紹介する。続けてKeepalivedを用いたサービスの稼働状態の監視、そして最後にKeepalivedによるロードバランサの冗長化について解説していく。
LVS環境の構築とロードバランシング設定
LVSを使ってロードバランサを構築するには、ロードバランサとして使用するサーバー側のLinuxカーネルにLVSをあらかじめ組み込んでおく必要がある。RHELおよびその互換OSでは、デフォルトでカーネルモジュール(ip_vsモジュール)としてLVSを組み込めるようになっているので、特別な設定は不要だ。ただし、カーネルのカスタマイズなどを行っている場合は、LVSを有効にできるように設定してカーネルをビルドしておく必要がある。
LVSでは「ipvsadm」というコマンドを使用してロードバランサの設定を行う。RHELやその互換環境では同名のパッケージでこのコマンドが提供されているので、あらかじめインストールを行っておく。
# yum install ipvsadm
LVSを使ったロードバランサを実現するためのネットワーク構成
ロードバランサはサーバーの代わりにクライアントからリクエストを受け取り、そのリクエストを一定のルールでサーバーに転送する処理を行う。LVSではTCP/IPレベルでパケットを転送する「レイヤ4スイッチング」という方式でこれを実現している。パケットの転送方式としてはNATおよびダイレクトルーティング、トンネリングという3つが用意されている(表1)。
転送方式 | 説明 |
---|---|
NAT | IPパケットに対しロードバランサでNATを行ってパケットをサーバーに転送する |
ダイレクトルーティング | IPパケットを書き換えずにパケットをサーバーに転送する |
トンネリング | IPパケットをカプセル化した上でサーバーに転送する |
NAT方式はロードバランサでNATを行ってパケットを転送する方式で、ロードバランサはローカルネットワークとWANの接続部分に設置する。この方式はサーバーがローカルネットワーク内にある場合など、サーバーとクライアントが直接接続できない場合でも利用できるのが特徴だ。いっぽう、ダイレクトルーティング方式やトンネリング方式はクライアントからサーバーへの通信についてはロードバランサを経由するが、サーバーからクライアントへの通信についてはロードバランサを経由しないのが特徴となる。さらにトンネリング方式ではロードバランサとサーバー間の通信にカプセル化されたIPパケットが利用されるため、ロードバランサとサーバーが別のネットワーク上にあっても利用できるのが特徴だ。
LVSではネットワーク構成に応じたパケット転送方式を選択できるが、もっとも一般的なのNATを利用する構成だ。その理由として、よりセキュリティを向上させることが可能である点が挙げられる。サーバーをインターネットから直接アクセスできないローカルネットワーク内に設置し、ロードバランサーに対してのみインターネットからのアクセスが可能な構成にすることで、サーバーを狙った攻撃をブロックすることができる。また、もしロードバランサが攻撃された場合でも、ロードバランサ上ではサービスは運用されていないため、サービスへの被害を最小限に抑えることができる。
NATによるパケット転送を使ったロードバランサ環境の構築
以下ではNATによるパケット転送を使ったロードバランサ環境の構築について紹介していく。今回使用するネットワーク構成は、次の図2のようになる。

ネットワークの設定
ロードバランサとして使用するマシンには2つのネットワークインターフェイス(NIC)を搭載しており、eth0はWAN(インターネット)に、eth1はLANに接続されている。また、サービスを運用するサーバーは2台で、LAN経由でロードバランサに接続されている。なお、ロードバランサとして使用するマシンにはLVSが使用する専用のIPアドレス(仮想IPアドレス)を用意しておく必要がある。このIPアドレスがクライアントに向けて公開するIPアドレスとなり、クライアントはこのIPアドレスに向けてリクエストを送信する。Linuxには「IPエイリアス」という、1つのNICに2つ以上のIPアドレスを割り当てる機能があり、これを利用してWAN側のNICに対しLVS用のIPアドレスを割り当てておく。今回の構成ではeth0がWAN側のNICになっているので、これに対し203.0.113.100というIPアドレスをLVSに割り当てている。
eth0にIPエイリアスを利用して203.0.113.100というIPアドレスを付与するには、まず/etc/sysconfig/network-scripts/ディレクトリ内にifcfg-eth0:0というファイルを作成し、次のようにIPアドレスやネットマスクなどの情報を記述しておく。
DEVICE=eth0:0
ONBOOT=yes
NETMASK=255.255.255.0
TYPE=Ethernet
IPADDR=203.0.113.100
続いてserviceコマンドでネットワークを再起動すると、eth0:0というデバイスに203.0.113.100というIPアドレスが割り当てられ利用できるようになる。eth0:0というのは「eth0の1つめのエイリアス」を意味している。
# sevice network restart
ネットワークを再起動したら、ifconfigコマンドでeth0:0デバイスが有効になっていることを確認しておこう。
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:22:4D:67:EA:B2
inet addr:203.0.113.1 Bcast:133.242.98.143 Mask:255.255.255.240
:
:
eth0:1 Link encap:Ethernet HWaddr 00:22:4D:67:EA:B2
inet addr:203.0.113.100 Bcast:133.242.98.143 Mask:255.255.255.240
:
:
また、IPパケット転送を有効にするようシステム設定の変更も行っておく。具体的には/etc/sysctl.confをエディタで開き、以下のように「net.ipv4.ip_forward」の値を「1」に変更する。
# vi /etc/sysctl.conf
:
:
# Controls IP packet forwarding
net.ipv4.ip_forward = 1 ←値を「1」に変更して有効にする
/etc/sysctl.confファイルの変更後、syscrl -pコマンドを実行すると変更が反映される。
# /sbin/sysctl -p
ロードバランサの設定
次に、ipvsadmコマンドを使ってロードバランシング設定を行っていく。まず、念のためipvsadm -CコマンドでLVSの設定をクリアしておく。
# ipvsadm -C
LVSでは、ロードバランシングするIPアドレスおよびポートの組み合わせを「仮想サービス」と呼び、これがクライアントの接続先となる。仮想サービスは「ipvsadm -A」コマンドで登録できる。今回はeth0:0に割り当てられた203.0.113.2というIPアドレスが仮想サービスのIPアドレスとなり、このIPアドレスと利用するポート番号の組み合わせを仮想サービスとして登録しておく。たとえば80番ポートへのリクエストをロードバランシング対象とするには以下のようにする。
# ipvsadm -A -t 203.0.113.100:80
続いて、「ipvsadm -a」コマンドで仮想サービスに対しパケットの転送先を登録する。たとえば192.168.100.21の80番ポートと、192.168.100.22の80番ポートを転送先とするには以下のようにする。
ipvsadm -a -t 203.0.113.100:80 -r 192.168.100.21:80 -m
ipvsadm -a -t 203.0.113.100:80 -r 192.168.100.22:80 -m
以上でLVSの設定は完了だ。最後に、ipvsadm -lコマンドでロードバランシング設定を確認しておこう。
# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 203.0.113.100:http wlc
-> 192.168.100.21:http Masq 1 0 0
-> 192.168.100.22:http Masq 1 0 0
サーバー側の設定
NATによるパケット転送を利用する場合、ロードバランサがサーバーのネットワークゲートウェイとして設定されている必要がある。サービスを提供する(ロードバランスされる)サーバー側でsystem-config-networkコマンドの実行、もしくは/etc/sysconfig/network-scripts/ifcfg-eth*ファイルの編集などを行い、設定を変更しておこう。今回の例の場合、ロードバランサのLAN側IPアドレスである192.168.100.1をデフォルトゲートウェイに指定する。
以上の設定が完了したら、クライアントから仮想サービスに接続を行い、正しくサーバーに接続できるかテストしてみよう。また、どのサーバーにリクエストが振り分けられているかは、ipvsadm -lコマンドの出力中「ActiveConn」および「InActConn」項目で確認できる。たとえば以下のように出力された場合、192.168.100.21に対し3つ、192.168.100.22に対し4つの接続が行われていることになる。
# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 203.0.113.100:http wlc
-> 192.168.100.21:http Masq 1 3 2
-> 192.168.100.22:http Masq 1 4 1
LVS設定の保存と復元
ipvsadmコマンドで行ったLVSの設定は、そのままではロードバランサとして使用しているLinuxマシンを再起動するとリセットされてしまう。そのため、RHELやその互換環境では設定をファイルに保存しておき、再起動時に自動的に設定を復元する機能が用意されている。設定をファイルに保存するには、以下のように「ipvsadm save」引数付きでserviceコマンドを使用する。
# service ipvsadm save
ipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm: [ OK ]
すると、「/etc/sysconfig/ipvsadm」ファイルにその時点での設定が保存され、ipvsadmサービスの起動時に自動的に復元される。再起動時に自動的にipvsadmサービスが起動するようにするには、以下のようにchkconfigコマンドでipvsadmサービスを有効にしておけばよい。
# chkconfig ipvsadm on
Keepalivedを使ったサーバーの監視
以上の設定を行うことで、仮想サービスとして定義したIPアドレスおよびポート宛てのリクエストをサーバーに転送し、負荷分散を行う環境を構築できる。しかし、この場合サーバーが何らかの原因でサービスを提供できなくなっても、そのサーバーにはリクエストが転送される可能性がある。つまり、サービスの冗長化は厳密には行えていない。そこで、続いてはKeepalivedを使ってサービスの稼働状態を監視し、サービスが停止しているサーバーに対してはリクエストの転送を行わない、という設定を行ってみよう。
Keepalivedは以下のような機能を持つルーティング管理ソフトウェアだ。
- パケット転送先サービスの死活監視
- LVS自体の死活監視
- LVS設定の動的変更
Keepalivedは、大きく分けて2つの目的で利用される。まず一つは、サービスの稼働状況に応じてロードバランサの設定を変更し、停止しているサービスに対してリクエストが振り分けられないようにすることだ。これは、KeepalivedがLVSの設定を監視結果に応じて動的に変更することで実現される。そしてもう一つは、ロードバランサ自体の冗長化だ。ロードバランサが1台しかない場合、ロードバランサ自体に障害が発生するとリクエストの振り分け先となるサービスが稼働していたとしてもリクエストを処理できなくなる。そのため、冗長性をより向上させたい場合はロードバランサを複数用意した構成を取るのが一般的だ。この場合、1つのロードバランサが停止した場合は別のロードバランサがその処理を肩代わりすることでサービスを継続させることができる。
以下では、まずサービスが停止しているサーバーにリクエストを送信しないようにするための設定方法を説明する。続いて、複数のロードバランサを使用した冗長構成の構築方法を説明する。
なお、Keepalivedを使用する場合LVSやIPエイリアスの設定はKeepalived経由で行われるため、これらの設定はすべて一度リセットしておく必要がある。
Keepalivedのインストールと基本的な設定
Keepalivedは、RHELおよびその互換環境では「keepalived」パッケージとして提供されている。まずはこのパッケージをインストールしておく。
# yum install keepalived
Keepalivedの設定は/etc/keepalived/keepalived.confファイルで行う。この設定ファイル内の設定項目については、/usr/share/doc/keepalived-<バージョン番号>/keepalived.conf.SYNOPSISファイルに記載されている。keepalived.confのmanページ(「man keepalived.conf」で参照できる)も用意されているが、こちらは情報がやや古いようなので、keepalived.conf.SYNOPSISファイルのほうを参照することをおすすめする。
keepalived.confファイルにはデフォルトでいくつかの設定が記述されているのだが、環境に応じてそのほぼすべてを書き換えることになる。そのため、オリジナルのファイルはバックアップしておくことをおすすめする。
Keepalivedではサーバーの障害を検知したり、なんらかの構成変更が行われた場合、メールでその旨を管理者に通知する。keepalived.confでは、まずglobal_defs内でこのような通知メールの送信先や使用するSMTPサーバーなどを設定する。下記で太字で示している部分が変更すべき項目だ。
! Configuration File for keepalived
global_defs {
notification_email {
admin@example.org ←通知メールの送信先メールアドレスを指定
}
notification_email_from admin@example.org ←通知メールの送信元メールアドレスを指定
smtp_server 203.0.113.200 ←メール送信に使用するSMTPサーバーのIPアドレスを指定
smtp_connect_timeout 30
router_id LVS_DEVEL ←ロードバランサを識別するための名前を指定
}
続いて、仮想サービスおよび仮想サービスに対応するサーバーの設定を行う。設定内容は以下のようになる。
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
}
}
}
Keepalivedでは、指定した間隔でサーバーに対しポーリングを行い、もし応答が帰ってこない、もしくは指定したレスポンスが帰ってこなかった場合にそのサービスが停止していると判断する。たとえばこの設定例では、/というパスに対しHTTPでGETリクエストを行い、レスポンスとして200以外のステータスコードが帰ってきた場合、もしくは5秒以内にレスポンスが帰って来なかった場合サービスに異常が発生していると判断する。これを3回繰り返し、3回とも失敗した場合はそのサーバーの負荷分散のための重みを0に設定することで、サーバーにリクエストが転送されないようにしている。
また、すべてのサーバーにおいて異常が発生した場合は、「sorry_server」で指定したサーバーおよびポートにリクエストを転送する。この設定は、すべてのサーバーにおいてサービスが停止してしまった場合などにサービスが利用できない旨をユーザーに表示する、といった目的で利用できる。
さて、設定が完了したら、次のようにしてKeepalivedを起動する。
# service keepalived start
すると、自動的にeth0に対しIPエイリアスの設定が行われ、またLVSによるロードバランス設定も行われる。IPエイリアスの設定についてはifconfigコマンドでは確認できないが、代わりにipコマンドで確認できる。たとえばeth0に付加されたIPアドレスを確認したい場合は、以下のようにする。
# ip addr show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:22:4d:67:ea:b2 brd ff:ff:ff:ff:ff:ff
inet 203.0.113.1/24 brd 133.242.98.143 scope global eth0
inet 203.0.113.100/32 scope global eth0
:
:
ここで、「inet」行が2つ表示され、IPアドレスが2つ割り当てられていることが分かる。また、サーバーを停止させると、そのサーバーの重みが0になることも確認しておこう。たとえば192.168.100.22というIPアドレスを持つサーバーを停止させた場合、ipvsadm -lコマンドでLVSの設定を確認すると、次のように「Weight」が0になっていることが確認できる。
# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 203.0.113.100:http rr
-> 192.168.100.21:http Masq 1 3 1
-> 192.168.100.22:http Masq 0 0 0
ロードバランサの冗長化
最後に、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も多くの設定項目を用意しており、必要に応じてさまざまな構成を実現できる。本記事を参考に、それぞれのドキュメントを参照して目的に応じた構成を検討してほしい。
この記事についてコメントする