Connect :
Uptime :
Secondary
9 Days
14 Hour
36 Min.
Googleから発表のあったCPU脆弱性に対応する為、連休を使って自鯖のアップデートを順次行っていた。
本番系はkernelをパッケージ管理システムで管理しているので、そのままアップデートで問題ないのだが、
テスト鯖はkernelもビルドして構築しているので、対応に合わせてkernelを入れなおす必要があった。
という事で、2018/02/11時点の最新kernelである4.15.2を使ったのだが、
kernelを入れ替えた後、画面がブラックアウトして起動しなくなった… _(:3」∠)_
テスト環境と言っても、キャッシュDNSサーバを兼用していたり、
監視システムの一部を担っているので直さないと不味く、徹夜してなんとか原因っぽい所まで突き止めた。
という事で、今回はハマりかけた事の顛末などを時系列ベースで書いてみようと思う。
免責事項：英文など解釈を間違っていたらゴメンナサイ
自宅WEB鯖をActive/Active構成に変更した際、
WebRootの保存先として検証していたGlusterFS。
当時は自鯖スペック・利用用途・ディスクI/Oの関係でパフォーマンスが出ず、
本番導入を断念して放置していた。
今回、CloudGarageに新メール自鯖を構築するにあたり、
メールの保存領域も冗長化したかった。
普通のメール冗長化ならActive/Standbyでレプリケーションをかけるか、
rsysnc辺りでデータをコピーするのが常套手段だと思われる。
業務利用なら安定性重視にすべきだが、
「自宅サーバで常套手段を取ってもつまらないな～」と思いつつ構築を進めている昨今だが、
ふと、以前は断念したGlusterFSを活用出来ないかと思い立ち、リトライしてみる事にした。
wiki：GlusterFS
まだ構築を進めている最中なのでどれだけの性能が出るか未知数ではあるが、
SSDを使ったVPS上に構築している事もあり、それなりの性能が出た。
ただ、詳しいベンチマークまでは取っていないので、
サーバの基礎構築とチューニングが終わり次第取ってみようと思う。
次期ns-labメール鯖をどうしようかと、色々なVPSを巡り歩いていたのだが、
twitterで偶然流れてきたCloudGarageが面白そうだったので仮契約をしたのが昨年。
機能は必要十分、標準でLSLBを使えるのが今回の利用用途とも合致していたので申し込みを行い、
在庫補充を待つ事数週間、遂にインスタンスを購入出来たので使ってみた。
ひとまず、cpuinfoとmeminfo見てみた。
仮契約時はOpenStackで隠蔽されていたのだが、
本契約した後、放置してたらいつの間にか表示されるようになっていた。
まだ使い倒していないのでなんとも言えないが、負荷を掛けてもそれなりの応答を保っている。
ディスクは基盤側でSSDを採用しているだけあって、I/Oはそれなりに良かった。
今後、メール自鯖をVPSに移す課程で色々と動作テストが必要になるので、
気付いた点があったら、都度レポートにしていこうと思う。
