UbuntuでProxyサーバロードバランス(3)

これまで(UbuntuでProxyサーバロードバランス(1)UbuntuでProxyサーバロードバランス(2))構築したとおり、Ubuntu Server 12.04LTSを使ってロードバランサーを構築し、Proxyサーバの負荷分散、障害検知と自動での切り離し、組み込みを動作させるところまで構築しました。

残った問題である、ロードバランサーがダウンしたときに結局システムが止まってしまうという問題に対処するため、ロードバランサーをクラスタ構成してみようと思います。

クラスタ構成と言っても色々ありますが、今回はkeepalivedのVRRPをそのまま使ってロードバランサーをActive / Standby型のクラスタにしてしまいます。


LB-2.jpg

単純にロードバランサー2を追加します。そしてProxyサーバの仮想IPアドレス(192.168.100.10)をVRRPによるフローティングアドレスにしてしまいます。

まずは前回作成したロードバランサー1にVRRPの設定を行います。

  • VRRPのフローティングアドレスはkeepalivedが設定するようになるので、eth0:1に設定した仮想アドレスが不要になります。


ロードバランサー1の設定

サブインターフェース(仮想IPアドレス)の削除
$ sudo ifconfig eth0:1 down $ sudo vi /etc/network/interfaces #auto eth0:1 #iface eth0:1 inet static # address 192.168.100.10 # netmask 255.255.255.0
※/etc/network/interfacesの設定は上記のようにコメントアウトするか、行ごと消してしまう。

VRRPの設定
※/etc/keepalived/keepalived.confの設定を行うが、前回設定したvirtual_server {}の設定を{}で包む形になるので注意。
$ sudo vi /etc/keepalived/keepalived.conf global_defs { # 変更なし notification_email { postmaster } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VProxy { # VRRP instance declaration state MASTER # 起動直後のステータスをどうするか設定 interface eth0 # フローティングアドレスを割り当てるインターフェース virtual_router_id 100 # VRRPのVRIDを設定(Master/Slaveで一致させる) priority 100 # プライオリティはMaster/Slaveで差をつける advert_int 1 # VRRP Advert interval (use default) authentication { # Authentication block auth_type PASS # プレーンテキスト認証ですが、、、 auth_pass 任意のパスワード # 念のため設定 } virtual_ipaddress { # VRRPのフローティングアドレスを指定する 192.168.100.10 dev eth0 } virtual_server 192.168.100.10 8080 { # VS IP/PORT declaration delay_loop 3 lb_algo lc lb_kind DR protocol TCP real_server 192.168.100.11 8080 { # RS declaration weight 1 # weight to use (default: 1) inhibit_on_failure # Set weight to 0 on healtchecker TCP_CHECK { # TCP healthchecker connect_port 8080 # TCP port to connect connect_timeout 2 # Timeout connection } } real_server 192.168.100.12 8080 { # RS declaration weight 1 # weight to use (default: 1) inhibit_on_failure # Set weight to 0 on healtchecker TCP_CHECK { # TCP healthchecker connect_port 8080 # TCP port to connect connect_timeout 2 # Timeout connection } } } }

ロードバランサー1の再起動、動作確認
※VRRPの設定を行ったため異常なく動作する事を確認する
$ sudo service keepalived restart $ watch -n1 sudo ipvsadm -Ln

ロードバランサー1がフローティングアドレスを持っていることを確認する
$ ip addr 1: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <broadcast,multicast,up,lower_up /> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.100.1/24 brd 192.168.100.255 scope global eth0 inet 192.168.100.10/32 scope global eth0
  ★フローティングアドレス(192.168.100.10)が割り当てられている inet6 fe80:::xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever

ロードバランサー1のVRRPがMASTERになっていることをログから確認する
$ sudo cat /var/log/syslog *** ** **:**:** loadbalancer1 Keepalived_vrrp: VRRP_Instance
(VProxy) Transition to MASTER STATE *** ** **:**:** loadbalancer1 Keepalived_vrrp: VRRP_Instance
(VProxy) Entering MASTER STATE ★VRRP MASTERになった
ロードバランサー2を作成する

※ロードバランサー1とロードバランサー2はホスト名、IPアドレスを除いてほぼ同じ構成になるため、ロードバランサー1をイメージで複製した状態から変更点のみ記載する
※ESXi上の作業では一旦、VMware vCenter Converter Standaloneを使い、ロードバランサー1の仮想環境をローカルに保存して、再度VMware vCenter Converter StandaloneでESXiにホスト名を変更して読み込ませると簡単

IPアドレスを変更する
$ sudo ifconfig eth0 192.168.100.2 $ sudo route add -net 0.0.0.0/0 gw 192.168.100.254 ★環境にあわせて設定 $ sudo vi /etc/network/interfaces auto eth0 iface eth0 inet static address 192.168.100.2 netmask 255.255.255.0 network 192.168.100.0 broadcast 192.168.10.255 gateway 192.168.100.254 ★環境に合わせて設定 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.100.201 192.168.10.202 ★環境に合わせて設定 dns-search hogehoge.local

ホスト名を変更する
$ sudo vi /etc/hostname loadbalancer2 ★環境に合わせて設定

hostsファイルも直す
$ sudo vi /etc/hosts 192.168.100.2 loadbalancer2.hogehoge.local loadbalancer2

VRRPの設定も直す
※変更点のみ抜き出して記載します。
vrrp_instance VProxy { # VRRP instance declaration state SLAVE # 起動直後のステータスをどうするか設定 priority 90 # プライオリティはMaster/Slaveで差をつける

ロードバランサー2の再起動
※色々設定を変えているので、システムごと再起動する
$ sudo reboot

ロードバランサー2のVRRPがBACKUPになっていることをログから確認する
$ sudo cat /var/log/syslog *** ** **:**:** loadbalancer2 Keepalived_vrrp: VRRP_Instance
(VProxy) Entering BACKUP STATE ★VRRP BACKUPになった

動作確認
ロードバランサーを1台ずつシャットダウンさせて、ip addrとログ(syslog)のメッセージからVRRPが正常に切り替わることを確認する。


ここまでの構築(Proxyサーバ2台、ロードバランサー2台)を行って、Proxyサーバが完全な冗長構成になります。DNS RRによる構成と比較したときには、構成がやや複雑にはなりますが、Proxyサーバがダウンしたときにそのサーバを切り離してくれることで、動作が続行出来る事が大きなメリットです。

今回は仮想環境(ESXi)での構築だったのですが、本来であれば、物理的な故障に備えるために物理的に別のサーバで構築すべき内容でしょう。そうなると、仮想化したとしても、物理サーバも最低限2台必要になってきますし、現実的に小規模な環境ではProxyサーバ1台で運用する方がシンプルで良いでしょう。Proxyサーバを複数で分散することは、同時にProxyサーバのアクセスログが複数台に分散する事も意味します。つまり、ログの解析が面倒になるというデメリットが出てきます。
Proxyサーバの台数は2台構成で構築しましたが、ロードバランサーの設定でリアルサーバの定義を増やすだけで簡単にProxyサーバを増やすことが出来ますので中規模〜大規模のシステムでは10台以上のProxyサーバによる負荷分散をさせるケースも多いかと思います。
※ そんな環境なら、普通にロードバランサー買うか。。。

余談ですが、DSR方式(MAT = Mac Address Translation)によるロードバランサーは、ロードバランサーのスペックがかなり低くてもそれなりの速度が出ます。ロードバランサーはリクエスト側のパケット(一般的にリプライのパケットと比較してパケットサイズが1/100以下)しか処理しないためです。また二次的なメリットですが、クライアントのIPアドレスがそのままリアルサーバに届くため、アクセスログやサーバファイアウォールの設定が簡単に行えることもメリットです。