DigiLoog

前回：ns-labのMTA鯖を拠点冗長化してみた

今までは↑の構成で問題無かったのだが、
昨日S氏とプライベートの待ち合わせをしている時に、

　S氏「(自鯖に)メール送ったんだけど、届いていないっぽい」
　自分「スパムフィルターで除外されたかな? もう一度送っておくれ」
　S氏「送った。 どうよ?」
　自分「届かぬ…」

というやり取りがあり、色々と原因をシミュレートしていた所、
修正前の構成ではVPNが切断された場合、メール配送が著しく遅延する事に行き着いた。

というのも、ConoHa側に着地したメールは固定配送(DNS指定)を切って、
ドメイン毎にVPNを通過させつつ、SpamFilterへ着地されている。
その為、VPN接続断の状態だとConoHaから先が無くて、ConnectionTimeoutになってしまっていた。

ちなみに、今までは固定配送先のDNSレコードを自動切り替えして対応していたのだが、
ここの所プライベートでも自鯖メールを使う様になり、
このままじゃマズイという事で、良い機会だと思って配送経路も冗長化してみた。

という事で配送経路を修正した結果がこちら。
経路上では難しい事はせずに、普通に迂回させる方針にしてみた。

通常配送	VPN障害時

普通の設計なら、VPNを安定化させて接続断を極力起こさないようにしたり、
そもそもVPNを経由させずにInternetで配送させる筈。
しかし、ns-labの場合はVPN-GWで少し細工したり、VPN接続性の実験を常にしている為、
通常のメールについても出来る限りVPNを通したい経緯があった。

………

試行錯誤している中で、固定配送を冗長化する設定で大きな問題が起きた。
それは、Postfixではmailertableの様に固定配送先を複数設定するのが普通は出来ないという事。

厳密には固定配送先が1つまでなら、"transfer_maps"のみで出来るけれど、
似たような事をするには、master.cfを弄ったりと面倒臭い事がわかった。

最終的にはmailertable相当の事が実現出来たのだが、
何故Postfixでtransfer_mapsを書く時に複数の配送先を指摘出来ないのが、
今回の設定を作る上でハマる要因の一つだった(´・ω:;.:…

………

メールとDNSは昔からある仕組みだからこそ、複雑だしいたる所にハマる要因があるのが怖い。
ns-labのメールサーバは特殊な構成だし、シンプル構成への組み替えを考える頃合いなのかもしれない。
…と言いつつ、複雑だからこそ判る事もあるので、このまま突っ走る予定ではありますが ﾍ(ﾟ∀ﾟﾍ)

« 続きを隠す

ns-labのメイン監視にはzabbixを利用しているのだが、
ここの所、監視対象が増えてきてしまい、合わせてDBへの書き込み負荷が課題になっていた。
という事でInooDBの領域を圧縮して、DB書き込み負荷をCPU負荷に転換してみた。

↑の写真は、DB圧縮してから1ヶ月程様子見した状態のステータス。
突発的にiowaitが食っているが、仮想環境の都合上致し方ない(´・ω:;.:…

本当は、半年前のデータと比較したかったのだが、
既にローテートされた後だった為グラフを取得出来なかった。

そろそろ、ns-labのDB設計からやり直すべきなのだろうが、
数ギガレベルでDBがあるし、面倒臭くてやる気が出ない c(・Д・と⌒ｃ)つ彡

仮想環境のゲストを作成した後に、ホストのディスク容量が足りなくなってしまい
ゲストイメージを縮小させたい事が稀に発生する。
イメージの記録方法が可変容量の場合は、ブランク領域の圧縮で乗り切る事も出来るが、
根本解決にはならないので、ゲストイメージの縮小方法を調べ実践してみた。

という事で、試行錯誤した成果とメモがコチラ

↑のメモでは、KVMホストでqemu-imgを使っているが、
Hyper-VやVirtualBOXとかでも同じ方法でゲストの容量縮小が出来た。

容量拡張は楽に実現出来るし、仮想HDDを追加する事でも対応出来るが、
縮小についてはデフォルトでは対応していない事が多いので、
Live CD Linuxからパーティションを操作したり、ddする事でなんとかなった。

ddコマンドでHDDを丸ごとコピーする事はよくやっていたが、
仮想イメージでも通用するとは思っていなかった。
さすが、ブロックレベルで書き出すだけの事はあった。