皆さんこんにちは！アナサピです。
今回は自分が実務で最近学んだ、さくらのクラウドにあるGSLBについて、負荷分散やフェイルオーバーの挙動をdigコマンドを利用しながら検証していきます！
1.そもそもGSLBとは？
システムの可用性向上や災害対策の手段として、複数拠点へサービスを配置する構成が広く利用されています。その際、利用者を適切な拠点へ振り分ける仕組みとして利用されるのがGSLB（Global Server Load Balancing）です。
GSLBが一般的なロードバランサと大きく異なるのが、『DNS応答を制御することでアクセス先を振り分けるという事』です。そのため、障害発生時の切り替えや負荷分散がどのように行われているのかは、実際にDNS応答を確認することである程度把握できます。
今回検証する、さくらのクラウドのGSLBには「重み値」というものが設定出来ます。
こちらは最小 1 から最大 10000 まで設定でき、その数字にしたがってサーバの割り振りが決まります。
例えば2台のサーバそれぞれに重み値を1ずつで設定し100回アクセスした場合、それぞれ約50回ずつ各サーバへ振り分けられるという感じです。
また、さくらのクラウドGSLBには「ソーリーサーバ」という機能があります。これは通常の実サーバがすべて利用できなくなった場合に、利用者をあらかじめ指定したサーバへ誘導する仕組みです。メンテナンスページや障害案内ページを表示することで、利用者に対して状況を案内できます。
今回は、さくらのクラウドが提供するGSLBアプライアンスを利用し、以下の項目について検証を行いました。
- 負荷分散時のDNS応答
- 重み値による振り分け比率の変化
- 障害発生時のフェイルオーバー動作
- ソーリーサーバへの切り替え動作
検証環境
今回はGSLBの挙動を確認するため、GSLBに加えて以下の3台のサーバを用意しました。
| サーバ名 | 用途 |
|---|---|
| Web-01 | 実サーバ① |
| Web-02 | 実サーバ② |
| Sorry | ソーリーサーバ |
構成イメージは以下の通りです。
- Web-01、Web-02をGSLBの実サーバとして登録
- 通常時はGSLBによってWeb-01とWeb-02へ振り分け
- 片方のサーバに障害が発生した場合は正常なサーバへフェイルオーバー
- 両方の実サーバに障害が発生した場合はソーリーサーバへ切り替え
また、今回の検証では、以下の4つの動作を確認します。
- 実サーバ2台への対等な負荷分散
- 重み値による振り分け比率の変化
- 実サーバ障害時のフェイルオーバー
- 全実サーバ停止時のソーリーサーバへの切り替え
先の項目でも触れましたが、GSLBはDNS応答から振り分けされているため、digコマンドにて結果を確認していきます。
実際のサービスアクセス結果だけでは振り分けの状況が分かりにくいため、DNS応答を直接確認することで、GSLBがどのサーバを選択しているのかを観察します。
実際に確認してみた
①重み値を1:1で確認
まずは、実サーバ2台の重み値を同じ値に設定し、どのように振り分けられるか確認します。
GSLB設定
| サーバ | 重み値 |
|---|---|
| Web-01 | 1 |
| Web-02 | 1 |
確認結果
何度か問い合わせを実施すると、以下のようにWeb-01とWeb-02の両方のIPアドレスが返却されることを確認できました。
[root@kakunin-kun ~]# dig +noall +ans gslb-test.example.com
gslb-test.example.com. 3600 IN CNAME site-113801242256.gslb11.sakura.ne.jp.
site-113801242256.gslb11.sakura.ne.jp. 10 IN A "Web-01のIP"
[root@kakunin-kun ~]# dig +noall +ans gslb-test.example.com
gslb-test.example.com. 3573 IN CNAME site-113801242256.gslb11.sakura.ne.jp.
site-113801242256.gslb11.sakura.ne.jp. 10 IN A "Web-02のIP"さらに、100回連続で問い合わせを実施した結果がこちらです。
[root@kakunin-kun ~]# for i in {1..100}; do dig +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
47 "Web-02のIP"
53 "Web-01のIP"
[root@kakunin-kun ~]# for i in {1..100}; do dig +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
50 "Web-02のIP"
50 "Web-01のIP"00回の問い合わせ結果では、両サーバともほぼ50%ずつの割合で返却されました。
完全に同数になるとは限りませんが、重み値を同一に設定した場合は概ね均等に負荷分散されることが確認できました。
また、GSLBはDNS応答によってアクセス先を決定しているため、一般的なロードバランサのような仮想IP方式とは異なる仕組みで負荷分散を実現していることが分かるかと思います。
② 重み値を8:2に変更して確認
次に、GSLBの重み付け機能がどの程度反映されるか確認するため、重み値を変更して検証を行います。
GSLB設定
| サーバ | 重み値 |
| Web-01 | 8 |
| Web-02 | 2 |
確認結果
100回問い合わせを実施した結果は以下の通りです。
[root@kakunin-kun ~]# for i in {1..100}; do dig @153.120.86.87 +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
20 "Web-02のIP"
80 "Web-01のIP"
[root@kakunin-kun ~]# for i in {1..100}; do dig @153.120.86.87 +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
21 "Web-02のIP"
79 "Web-01のIP"上記のように、重み値を8:2に設定した結果、DNS応答も概ね8:2の割合で返却されることを確認できました。
1:1設定時にはほぼ均等な割合で応答が返却されていましたが、重み値を変更することで特定のサーバへより多くのアクセスを誘導できることが分かります。
③ フェイルオーバーの確認
次に、実サーバの片方が停止した場合の挙動を確認します。
今回は先ほど②で、重み値を8に設定していたWeb-01のNginxサービスを停止し、GSLBがどのような応答を返すか確認しました。
サービス停止詳細
[root@Web-01 ~]# systemctl is-active nginx
active
[root@Web-01 ~]# systemctl stop nginx
[root@Web-01 ~]# systemctl is-active nginx
inactive
[root@Web-01 ~]#その後コントロールパネル上にて、GSLBの実サーバである、Web-01のステータスが『DOWN』になりました。
サービス停止後に100回問い合わせを実施した結果がこちらです。
[root@kakunin-kun ~]# for i in {1..100}; do dig @153.120.86.87 +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
100 "Web-02のIP"Web-01停止後は、すべてのDNS応答がWeb-02のIPアドレスとなりました。
重み値の設定に関係なく、ヘルスチェックによって異常と判定されたサーバは振り分け対象から除外されていることが分かります。
また、利用者から見るとアクセス先が自動的にWeb-02へ切り替わっており、サービスは継続して利用できる状態となっています。
④ ソーリーサーバへの切り替え確認
最後に、実サーバがすべて利用できなくなった場合の挙動を確認します。
今回は残っているWeb-02のNginxサービスを停止し、GSLBがソーリーサーバへ切り替わるか確認しました。
サービス停止詳細
[root@Web-02 ~]# systemctl is-active nginx
active
[root@Web-02 ~]# systemctl stop nginx
[root@Web-02 ~]# systemctl is-active nginx
inactiveこちらもコントロールパネル上にてWeb-02サーバのステータスが『DOWN』になりました。
停止後に100回問い合わせを実施した結果がこちらです。
[root@kakunin-kun ~]# for i in {1..100}; do dig @153.120.86.87 +short site-113801242256.gslb11.sakura.ne.jp; done | sort | uniq -c
100 "ソーリーサーバIP"実サーバがすべて停止した状態では、ソーリーサーバとして設定していた “ソーリーサーバIP” のみが返却されました。通常のフェイルオーバーでは正常な実サーバへ振り分けが行われますが、すべての実サーバが利用できない状態ではソーリーサーバへ切り替わることが確認できました。
これにより、障害発生時でも利用者へメンテナンス画面や障害案内画面を表示できるため、単純な接続エラーを表示する場合と比較して、利用者への案内を行いやすくなります。
まとめ
今回は、さくらのクラウドGSLBを利用して負荷分散およびフェイルオーバーの動作を検証しました。
GSLBは一般的なロードバランサのように単一の仮想IPアドレスへ集約する仕組みではなく、DNS応答を制御することでアクセス先を振り分けるサービスです。そのため、複数拠点への振り分けやDR（災害対策）構成、ソーリーサーバによる案内ページの表示など、さまざまな用途で活用できます。
冗長化構成につきましては、以下の記事で今回紹介したGSLBも含めて説明しております！ご検討の際は是非一度ご覧ください。
ネットアシストでは、お客様のシステム構成や要件に応じて、GSLBやロードバランサを活用した可用性向上構成のご提案から設計・構築・運用まで幅広く対応しております。負荷分散やBCP対策をご検討の際は、お気軽にご相談ください！
