トップページ»1.お知らせ»サーバー障害復旧連絡

1.お知らせ



サーバー障害復旧連絡

1週間ちょっとのご無沙汰です。 サーバーに障害が発生してまして、回復に思いの他時間がかかってしまいました。 この間来てくださった方には申し訳なかったです。

障害はCentOSに切り替えたことが原因(とはいってもCentOSが悪いって事じゃないです。詳細は追記を参照してください。)なのですが、ある程度時間が経過するとおもむろにフリーズしてしまうというものでした。 フリーズするまでの間はサイトを公開しておくこともできたのですが、あまりにも状況が酷かったので思い切って完全に直るまでは公開しない方針で進めていました。

結果的にはどうにかほぼ元の状態に戻せたのですが、またちょこちょこメンテすると思います。 今回のような長期間にわたることは無いと思いますが、たまに見れなくなることがあるかもしれませんのでご了承下さい。




VIA C3ユーザーは注意したほうが良いです…

今回の障害はVIA C3に由来する障害でした。 CentOSに関わらず他のLinuxをお使いの方も関係するかもしれません。 あまり該当する人はいないかもしれませんが、参考までに書きます。

結論的に言うとVIA C3が載っているPCでcpuspeedを起動していると、突然フリーズしてしまう障害に見舞われる可能性があります。 特にCPUの負荷が高くなっているときに起きやすいみたいです。 ちなみに私が本現象を確認した環境は、

Linux public.local 2.6.9-34.EL #1 Wed Mar 8 00:07:35 CST 2006 i686 i686 i386 GNU/Linux
cpuspeed v1.2.1

です。 これはCentOSの現在の最新版です。

対策ですが、cpuspeedを無効にすれば回避できます。 CentOSを含むRedhat系の場合ですと

chkconfig --level 12345 cpuspeed off
/etc/rc.d/init.d/cpuspeed stop

で良いと思います。 cpuspeedはシングルユーザーモードでも生きていますのでご注意。(これにもやられました…)

ちなみにCentOS Bug Trackerでも話題になってました。(後になって気がつきました。 最初に見ていればもっと早く復旧できたろうに。)

経緯

4月28日にメンテ完了後、通常運用に戻ったわけですが、その後頻繁にサーバーが固まる現象にでくわしていました。 シェルに対してタイプしても完全に無反応。 Linuxを使ってきた上で、ここまでガッチリと固まった事はあまり記憶に無く、まず今回の移行に際して新調したハードディスクを疑いました。(HDD障害でここまで固まるか?という疑問はありましたが。SMARTの情報を見てエラーが見つかりませんし。) 

とりあえずシングルユーザーモードに落ちた上でDATに現状のバックアップを取り、旧HDDでも試してみました。 しかし状況は変わらず。 と、簡単に書いていますが、この時も別の問題が出ちゃいまして。 SCSIがいうことをきかず、まともにバックアップが取れない。 おまけにシングルユーザーモードにも関わらずフリーズする問題は変わらず発生。 今思えばこれもcpuspeedのせいですね。 シングルでも再現したので完璧にハードウェアの問題だと思ってしまいました。 あとシングルでは全てのサービスが死んでいるものという思い込みも原因ですね。

knoppixを使おうにもLVMのパーティションはいじれないので、何度もリトライしてようやく(まぐれ的に)バックアップすることができました。 20ギガ程度のテープへのバックアップ、しかも何回もリトライ。 泣きそうでした。(^^;)

次にメモリを疑いました。 memtest86+を入れてメモリチェックを実行。 ついでに書きますと、CentOSの場合、

yum install memtest86+
memtest-setup

でgrubのメニューに載るので、リセットして選択するだけで実行されます。

で、結果。 約6時間経過したところで中断。 4周とちょっと、その間エラーなし。

次にLVMを疑いました。 tarやdumpで固まるのでディスクの障害という線が拭えなかったからです。 fdisk後シンプルにext3でフォーマットし、新規でCentOSをインストール。 tar tvfしてみました。 しかし再現します。

あと残るはマザーボードかkernelの問題くらいです。 でもCentOSはノーサポートのOSとはいえ、RHELのソースをリコンパイルしたというのがベースのOSです。 そんなに信用がないものとは思えないし、M/Bを変えようにも入れ替え前までは正常に運用できていたわけだし、そんなに簡単に壊れるとは思えないし。 いよいよ八方塞がりっぽくなってきました。

だめもとでディストリビューションを変えてみることにしました。 CentOSと同じRHELクローンのWhite Box Enterprise Linux 4を入れてみました。 但し古いカーネルで試してみたいと思ったのでrespin1はやめておきました。 結果。 現象再現せず。

というわけで原因はkernelっぽくなってきたわけですが、楽をするためにディストリビューションを選んでいる訳で、kernelのコンパイルとかはしたくありません。 このままWBELで行こうか… それともFedoraに戻るか… でもWBELもFedoraもkernel上げたら再発する可能性高いし…

というところまでが昨日の時点です。 kernelのせいだとしたらどこかに情報があるかもしれないとようやく探し始めました。 で、先ほどのページに行き着いたわけです。

とりあえずCentOSに戻して試してみたらビンゴ。 今のところ(あくまで今のところ)再現していません。

経験的にハードウェアを疑ってかかってしまったのが今回の失敗です。 かなり遠回りになってしまいましたが、おかげで良いお勉強になりました。

C3のlonghaul関係はFedora Core 2の時も調子悪かったのですが、今でもまだ問題が残っているのかもしれません。 もう少しcpuspeedはお預けってところでしょうか。 でもcpuspeed使いたいなぁ。 結構効果があるのは知っているので。


投稿日 : 2006年5月11日

この記事に関する言及

このエントリーのトラックバックURL:
http://akionweb.com/mt-tb.cgi/290

コメント

このページに対する感想、意見をお寄せ下さい。




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)

おことわり

当サイトに掲載している全ての情報は、全て当サイト管理者が個人的、実験的に試した事、又は独自に調査したものです。 従ってその情報に誤りがある可能性も多分にあります。 当サイトの情報をそのまま鵜呑みにされませんようお願い申し上げます。 また当サイトの情報を元に作業されたりする場合はそれをご理解頂いた上で、あくまで自己責任の元で行ってください。

トップページ»1.お知らせ»サーバー障害復旧連絡