GMOアドマーケティングのインフラエンジニア うたです。
サーバを冗長化させたい時によく利用するkeepalivedですが、弊社でもソフトウェアロードバランサやProxyサーバを冗長化させたりするのに使用しています。
よく見るmaster/slave構成は
のようなアクティブ/スタンバイ構成ですが、
使用するVIPの倍のサーバを用意しておかないといけなくて、ムダがありそうです。
アクティブ/スタンバイ設定例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
global_defs { notification_email { xxx@xxxx.jp } notification_email_from xxxx smtp_server localhost smtp_connect_timeout 30 router_id test } vrrp_instance VI_1 { state interface eth1 virtual_router_id 51 priority {{ 任意の値 }} advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 } virtual_ipaddress { 192.168.0.101 } } |
そこでスタンバイ機にもVIPを振り、常時2台をアクティブにする構成してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
vrrp_instance VI_1 { state interface eth1 virtual_router_id 51 priority {{ 任意の値 }} # server1 > server2 advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 } virtual_ipaddress { 192.168.0.101 } } vrrp_instance VI_2 { state interface eth1 virtual_router_id 52 priority {{ 任意の値 }} # server2 > server1 advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 } virtual_ipaddress { 192.168.0.102 } } |
priorityをserver1と2で逆転させることで、master stateを2台に分散可能です。
この状態で、どちからのサーバがダウンすると、片方のserverに2つのVIPが寄せられることになります。
当然3台以上でもリング構成が可能になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
vrrp_instance VI_1 { state interface eth1 virtual_router_id 51 priority {{ 任意の値 }} # server1 > server2 > server3 advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 } virtual_ipaddress { 192.168.0.101 } } vrrp_instance VI_2 { state interface eth1 virtual_router_id 52 priority {{ 任意の値 }} # server2 > server3 > server1 advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 } virtual_ipaddress { 192.168.0.102 } } vrrp_instance VI_3 { state interface eth1 virtual_router_id 53 priority {{ 任意の値 }} # server3 > server1 > server2 advert_int 1 authentication { auth_type PASS auth_pass 1111 } unicast_peer { 192.168.0.1 192.168.0.2 192.168.0.3 } virtual_ipaddress { 192.168.0.103 } } |
server2がダウンすると次のpriortiyの高いノードにVIPが引き継がれます。
この仕組を利用して、IPを引き継ぎながらサーバ冗長化をできるので色々な利用方法が考えられます。
今後ともこのような小ネタがあればご紹介していきたいと思います。
