Connect :
Uptime :
Secondary
2 Days
5 Hour
12 Min.
今まで自鯖を色々と拡張しつつ、システムリプレースし続けてきたのだが、
稼働歴が長いけれど手を付けられていないのがメール鯖だった。
当初はスキル修得目的でとりあえず構築したメール鯖だが、
昨今だとスマホのメイン用途で使う事もあり重要度が上がっていた。
という事で「メール鯖の刷新をやるか～」と構想を練りつつ早1年。
粗方の構成が決まった後、必要なシステムを次々を構築してはメモを作りと繰り返し、
海の日含めた3連休を使って、ns-labの全メール鯖リプレースが完了した。
という事で、今回は新ns-labメールサーバがどんな構成で動いているのか紹介しようと思う。
ns-lab BBのサーバ群は基本的に仮想サーバで構築しており、
ハイパーバイザーはKVM・Hyper-Vが主に、VPSを借りたりもしている。
その時微妙に問題になるのが深夜のスクリプト処理でCPUが奪い合いになる事と、
/dev/randomのエントロピー不足によるReadLockであったりする。
今までは表面化していなかったのだが、kernel 4.16辺りで導入された、
“crng_init” の初期化仕様変更に伴い、起動直後から/dev/randomを直参照する必要が出てきた。
ただ、起動直後は乱数の元となるエントロピーが溜まっていない為、
ReadLockが発生してしまいOSの起動が止まってしまった。
この問題に行き着く迄に1週間を費やし、kernelリビルドを10回程実行 ﾍ(ﾟ∀ﾟﾍ)
LKML.ORGを見るとこの問題の対応方針がまだ決まっていない見たいだが、
CVE-2018-1108の脆弱性対応も含まれているらしく、仕様がひっくり返る事は無さそう。
「だったら起動直後からエントロピーを蓄積出来る方法が無い物か」と、
/dev/randomエントロピー蓄積に使えそうな物を探してみた。
ロードバランサには大きく分けて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を構築してみた。
