Diary/2010-05-19 のバックアップ差分(No.2)

• バックアップ一覧
• 現在との差分 を表示
• 現在との差分 - Visual を表示
• ソース を表示
• バックアップ を表示
• Diary/2010-05-19 へ行く。
  • 1 (2010-05-20 (木) 05:45:26)
  • 2 (2010-05-20 (木) 05:55:34)
  • 3 (2010-05-21 (金) 03:20:58)
  • 4 (2010-05-23 (日) 22:19:17)
  • 5 (2010-05-24 (月) 18:13:57)

• 追加された行はこの色です。
• 削除された行はこの色です。

** サーバ、ロックダウン [#kca6ccb1]
#ref(../rural_sy00f.png,nolink,ムッ！)

日付変わった 0:01 、サーバの回線が切れた。&br;
これの原因は実は解っていて、前々から時々起きていた。理由は Firewall による回線切断である。&br;
これの原因は実は解っていて、前々から時々起きていた（今回で 3 回目）。理由は Firewall による回線切断である。&br;
0:01 になると amatsukami.jp サーバはログの解析を始める。&br;
また、夜の 22 時頃から AM2 時頃というのはウチのサーバがもっとも混む時間帯である。&br;
また、夜の 22 時頃～ 26 時（AM2:00）頃というのはウチのサーバがもっとも混む時間帯である。&br;
以上の二つの条件が重なるため、0 時というのはサーバの HDD にもっともアクセスが集中する時間帯なのである。すると何が起きるかというと、Gateway サーバのログの書き込み遅延が発生してしまうのである。そしてこれが発生すると、Firewall が何らかの Attack の症状と見なし、回線を切断してしまうのである。これをロックダウンという。&br;
しかも Gateway サーバは仮想マシンで実行されている。これがまたさらに HDD アクセスを遅くさせているのよね。

もちろん、何らかの攻撃（DDoS など）を食らってもこの現象は起きる。

そして今日はボクは AM2:30 まで出かけていたので、その間サーバは回線が切れっぱなしになってしまったと……そう言うワケなのである。

さて、どうやって回避するかなぁ。一番確実なのは Gateway サーバを物理的な別マシンにやらせること。でも正直、24H 稼働するマシンを 2 台なんて電気代的にもそして熱対策的にもやりたくない。5 インチベイに入りきる Atom マシンとかを一応考えてはいるんだけど……。&br;
で、とりあえず付け焼き刃なんだけど、仮想マシンの場所を現在のシステム・ドライブから別のデータ・ドライブに移した。システム・ドライブにはウェブのデータも入っているし、サーバのログも保存され、ある意味一番ビジーに稼働している HDD である。一方のデータ・ドライブはそんなに頻繁にアクセスはされないし、物理的にも違う HDD だし、S-ATA のチャンネルも違う。&br;
これで少しは良くなってくれるといいんだけど……次の日付が変わったときがどうなるか、心配だなぁ。

#article