どさにっき 3D 〜2011年7月中旬〜

by やまや
<< = >>

2011年7月15日(金)

DNS ラウンドロビンの実際

_ 先日、2台のホストを DNS ラウンドロビンで並行運用している POP サーバでホストの再起動をともなうメンテナンスをおこなったときのメモ。

_ 簡単なタイムチャート。

  1. 作業開始。片系を DNS ラウンドロビンの対象からはずす
  2. 10分後。キャッシュから消えて完全に片方に寄る(はず)。
  3. 3時間後。ホスト停止。
  4. 1時間後。ホスト起動。
  5. 14時間後。ふたたび両系を使うように DNS をいじる。
  6. 10分後。片系のみをキャッシュしている DNS がなくなる(はず)。
停止したのは片方のみ。再起動後14時間も片系のまま放置していたのは単なる横着。

_ 2台の IP アドレスは末尾が 1 違うだけで、 RFC3484の宛先選択アルゴリズムの rule 9 (longest match)が適用されても違いは生じない。

_ ちなみに作業は MX なメールサーバ、submission なメールサーバでもおこなっているが、今回は POP サーバのみ注目する。POP サーバはメーラーが起動しているかぎり数分ごとに定期的にアクセスする設定になっていることが多いので影響がわかりやすい。

_ まず、作業前の状況。再起動しない方のホスト(以下 A)と再起動する方のホスト(以下 B)では、だいたい 5% ほど A の方がアクセス数が多い。つまり、定常状態ですでに負荷が平均化されていない。IP アドレス順に並べると A の方が IP アドレスが小さいため、ラウンドロビンに従わずソートしていちばん小さいものを使う実装(Windows Vista など)の影響が出ているものと思われる。

_ ラウンドロビンを解除して片系に寄せると B へのアクセスは徐々に減るが、TTL が過ぎてもかなりの数が B にアクセスを続けている。ラウンドロビン解除後2時間後からホスト停止までの1時間のアクセス数の比は 85:15。すでに DNS のキャッシュから名前は消えているはずなので、正しく名前解決しているのであれば B へのアクセスはすでになくなっているはずなのだが。POP サーバにアクセスするたびに名前解決をするのではなく、メーラー起動時に得た名前解決の結果をずっと使い続けているためと思われる。

_ B を再起動すると、それ以後 B へのアクセスはほとんどなくなる。それまで B へのアクセスを続けていたクライアントも、B の停止によりアクセスが失敗したことにより、名前解決を再度おこなったのではないかと思われる。ただ、それでも B へのアクセスはなくならず、全体の 1% 強が再起動後も B にアクセスを続けている。この 1% はクライアントが参照してる DNS キャッシュがかなり腐ってる?

_ B を DNS に戻して2台体制に復帰させる。ある程度は B へのアクセスが戻ってくるが、B を DNS からはずしたときに B へのアクセスが止まらなかったように、B を戻しても A へのアクセスが集中したままになる。A と B でだいたい 5:3 ぐらいの比率。

_ その後ゆっくりと B のアクセスが増え、5日ほどかかってようやく A と B のアクセス数の比率がほぼメンテ前の水準に戻る。みなさんメーラーを再起動したんでしょう。念のため書いておくと TTL は10分なので、TTL に正しく従っているなら10分後には元に戻っているはず。

_ DNS ラウンドロビンをやる場合、メンテや障害で片側に寄せたときに速やかに切り替わるように TTL を短めにしましょう、というのが定説ではあるけれど、以上のように TTL なんか無関係に止めたホストへのアクセスが続く。ちゃんと DNS にしたがって寄せた側にアクセスするクライアントも多いのでまったく効果がないとは言わないけれど、止めた側にアクセスするクライアントの数も無視できないぐらい多いので、TTL で解決しようというのは無理。

_ web ブラウザだと DNS rebinding attack 対策で短すぎる TTL を無視することはあるけど、問題になるのは「短すぎる TTL」であって、ある程度以上の大きさであればちゃんと TTL に従って問題ないはず。Firefox だと network.dnsCacheExpiration のデフォルトは60秒で、つまりその程度で DNS rebinding attack 対策には十分だと考えられているようなのだが、その10倍の TTL で、そして rebinding attack を気にしなくていい POP で TTL を無視して数時間以上キャッシュする必要はないはずなんだけど、実際はこのとおり、無視されまくり。

_ これもある意味 DNS の「浸透」問題。キャッシュに残っている情報を制御しようにも、看過できないほど無視されている。ぶっちゃけ、DNS ラウンドロビンで可用性を高めようというのは幻想と言ってしまっていいと思う。


2011年7月17日(日)

燕岳

_ 登ってきた。つばめじゃなくて「つばくろだけ」と読むらしいよ。

_ さすがに標高差 1400m を1日で登って下りるのはキツいわ。北アルプス三大急登のひとつらしいけど、それほど斜度があったわけでもなく整備も行き届いてるのでわりとすいすい登れてしまう。が、登っても登っても展望のない樹林帯でめげそうになる。

_ しかし苦労して稜線まで上がってくると、そこから見える景色はいやほんと素晴しい。登ってる途中はわりと雲が見えてて心配してたんだけど、槍穂高から野口五郎さん方面はほとんど雲にさえぎられることなくはっきりと稜線が見える。これは凄いわ。

_ 十分余裕を見て多めにラーメン1袋、おにぎり3個、薄皮つぶあんぱん5個パック、バナナ1本、水2.5l を持っていって、下山したときに残ってたのはあんぱん2個だけだった。それ以外に途中の売店でスイカ食ってるし、下山早々すぐ売店でかき氷食って車に残してきたおにぎり1個とサンドイッチ2個食って、さらにその1時間後に早めの晩飯食ってるし。いったいどんだけ食ってんだよ。

_ で、その後は例によって美ヶ原の道の駅まで。やっぱり夏の車中泊は高いところじゃないとね。標高 2000m はさすがに高すぎるけど(真夏でも防寒具が必要)。

_ 燕岳
燕岳
通称イルカ岩と、その奥に聳える槍ヶ岳
イルカ岩
北燕岳からの燕岳。今まさに雲が越えようとしている尾根は槍ヶ岳方面への縦走路
北燕岳から


2011年7月18日(月) 海の日

車山

_ うーん。車山のニッコウキスゲは去年より咲いてると聞いていたし、実際見た感じでも今がたぶんピークだと思うんだけど、ぜんぜんダメだなぁ。シカの食害にやられたそうで、電気柵の内側のほんの狭い範囲だけで群生していて、その外側ではちらほらとしか見かけない。6年前に見た斜面全体が山吹色に輝いていた風景とは比べるべくもない。こりゃ再生するには当分かかりそうな。

_ まあそんなわけで霧ヶ峰の周辺をぶらぶらと 歩いてみたり。ここにはもう何度も来てるけど、ちゃんと歩いたのは初めてだな。わりと平坦に見えるけど、実際歩いてみたらけっこうな山でした。

_ 車中泊した美ヶ原の道の駅から。曇ってて山なみははっきりとは見えないけどこれはこれで。

車山のニッコウキスゲ。群生してるように見えるけど、こんなに密集してる場所はひじょーに狭い範囲でしかない。


<< = >>
やまや