2018年03月24日(土) - 19:52 | カテゴリ:
Linux
ロードバランサには大きく分けて2種類ある。
1つ目がロードバランサの代名詞であるLSLB(LocalServer Load Blancing)で、
アプライアンスだとF5社のBIG-IP、A10社のThunder/AXなどの負荷分散目的を差す事が多い。
LSLBに対応したOSSも多く、ns-lab BBでも利用しているHAProxyとかが該当する。
2つ目が広域負荷分散と言われるGSLB(GlobalServer Load Blancing)で、
F5社のBIG-IP、Citrix社のNetScaler等が該当しコチラもそれなりに種別が多い。
ただ、OSSでGSLB動作に対応している物は少なく、
探した限りだと企業レベルでの採用事例は無く、殆どが自作GSLBだった。
というのも、OSSで自前構築するよりAWSのRoute53を使うか、
仕組みは簡単なので企業レベルならフルスクラッチした方が楽だからだと思う。
………
今回ひょんな事からGSLBの仕組みを把握しつつフル活用する必要が出てきたのだが、
自前で環境を持っていない事もあり技術検証が出来ていなかった。
さらに、その中でUDPリバースプロキシを動かす必要も出てきてしまった為、
ns-lab BBのバックボーンサーバとして、
gdnsdでGSLB(権威DNS)、nginxでUDPリバースプロキシを連携させつつGSLBを構築してみた。
- 構築手順
nowsky system-lab memo > gdnsd
nowsky system-lab memo > NGINX
GLSBはDNSキャッシュとレコード応答を利用して接続先サーバを切り替える。
切り替えルーチンは様々な物があるが、
ラウンドロビン・ジオグラフィー・グローバルアベイラビリティの採用例が多い様に思う。
今回構築したGSLBでは、広域負荷分散する程の自鯖台数もないので基本はラウンドロビンで設定しておき、
セッション維持が必要な用途(FQDN)は、ソーリーサーバ形式で拠点切り替えを行う様にしてみた。
という事で、ns-lab BBで実際に使っているGSLBの構成がこちら。
自鯖と言いつつサーバはCloudGarage上に構築したので、VPS仕様によりNATが必須となってしまった。
また、UDPリバプロを使いたかった為、gdnsdの前段にnginxを配置してみた。
この構成だとgdnsdで取得するIPアドレスが、ローカルIP(nginx)になってしまうが、
gdnsdで接続元IPが必要になるのはジオグラフィーロードラバンス(GdnsdPluginGeoip)する時なので、
今回は使わない機能と割り切った。
前段にUDPリバプロを配置した事でメリットもあった。
gdnsdはDNSクエリログを記録する機能が無いのだが、
UDPリバプロを配置した事で、接続元IPなどをnginxで取得する事が可能になった。
iptablesを透過モードで全クエリ取得する事も可能だが、
他の遮断ログと混在すると解析するのが大変なので、今回はリバプロ取得の方が合致した。
構成図を見るとわかる通り、nginx配下でもたすき掛けに分散させておき、
1台のプログラム・サーバがダウンしても、稼働し続けるようにしてある。
サーバスペックは低いのでDDoSレベルには耐えられないが…
………
本稼働しだしてから日が浅いのと、
gdnsdのヘルスチェックも一部しか使っていないので未知数な所もあるが、
負荷テスト・障害テストなどを色々やってみた所では特に問題は無かった。
業務レベルでGSLBを扱う時はRoute53を採用した方が楽だが、
GSLBの概念を把握していないと障害時にハマるので、
自鯖で検証しつつ検証利用しながら使い倒すのが良いかもしれない。
………
後日談 ＞ 【DigiLoog】：gdnsdとdnsdistでGSLB構築
« 続きを隠す
