ごまめの遠足。

サーバトラブル後、最初の週末

最後の歯医者と、床屋と、年賀切手を買いに出かける。PCとサーバ復旧関連では、とりあえず外付RAIDケースだけ買いにいく。

USB3.0でいいなら、RAIDケースの選択肢はたくさんある。ということで、一番ファンの大きい(8cm!)SA-DK2-U3Rを購入。8cmなら、サーミスタつきだろうが何だろうが、交換ファンには事欠かない。まあ、素の状態でも充分静かと期待する。

あと考えるべき問題は、アレイごと1TBぐらいの仮想OSにするか、アレイを仮想OSの外付ストレージにするか。

前者は、もしハードウェアに障害が発生しても、稼働可能なPCをダブルNICにして仮想化アプリを入れれば、まず30分かからず再起動はできるようになるが、何かの拍子で仮想OSイメージが壊れるとデータが巻き添えになるのが心配。あとせっかくLVMの使用サイズを実物以下にしても、ディスクイメージが最適化されずにサイズが実サイズを超えるおそれがある。

後者は、リアルOSにも接続できるぶん、取り回しの幅は広いが、仮想USBホスト経由でデータをやりとりする形になるのが(安定性と速度の両面で)気になる。というか、これならリアルOSで動かした方がよかったりして!? サーバごとに手間はかかるものの、バックアップサーバをいつでも使える状態に仕上げておきさえすれば、少なくとも障害時の引継はすぐできるから。

VMwareでUSB3.0が使えるようになるのはまだ先の話みたいだし、こりゃ仮想化はやっぱり見送りかもしれん。

…帰ったらサーバが、やっぱりアクセスランプが点きっぱなしになっていた(汗)。ただ外からSSHでは入れたので、安全に(この状態で安全もくそもない)シャットダウンを実行。どうやらメモリでもない。前回より長く走っていたのは、ダウンしたせいで被アクセス頻度が低下したせいだったのかも。

2011/11/19 23:00 | カテゴリー：Fedora | コメント（0）

みたびサーバ調査中

しかしメインマシンもブート用の外付光学ドライブも使えない中、夜半回ってから2～3時間ぐらいしか作業できないことで、復旧は遅々として進まない。

とりあえずHDDを換えても改善しなかったので、HDDの故障の可能性はほぼ消え。突然電源が落ちるわけではないのでPSUの線もやや消え。もっともPSUって、+5Vが5.6V(テスター表示)になるという、いろんな意味で危険な壊れ方もあるので、決めてかかるのは危険ではある。

CPUは、全体がやばい状態でもまじめにログを出している雰囲気なので(ここまできたらもはや雰囲気)、これで実はCPUが原因でした、なんてことになっても仕方ないと割り切って、マザーボードかメモリに絞り込む。

このフィフティフィフティと言われたら、電解コンデンサを持っている分だけマザーが不利だが、しかし(壊れるとしたら一気だと思い込んでいた)メモリがじわじわ壊れるという事例は見たので、今回は期待は持てる。メモリの交換ですめば、OS再インストールは回避できる可能性が高くなる。

外付光学ドライブを探すor内蔵光学ドライブを外してくる手間を惜しんで、メモリを交換したそばからランレベル1で動かすと、データドライブのバックアップ完走までこぎ着けた。

となれば、今はこれ以上何もできないので、ランレベル3で起動。起動プロセスの一番難しいところは切り抜けたようだ。

しかし、システムドライブを交換した直後のトライでも、翌日午後までは走ったので油断はできない。

蛇足だが、5.6Vが出るPSUを分別廃棄のため開けてみたら、電子部品サイズのコンデンサが2個ほど爆発していた。いっそのこと乾電池ぐらいなコンデンサの方が爆発してくれていれば捨てるのも惜しくないんだけど、と、縁起でもないことを言ってみる。

2011/11/17 23:00 | カテゴリー：Fedora | コメント（0）

やっぱりハングアップ

帰ったら、14時台でログが停まって、やっぱりアクセスランプが点きっぱなしなサーバがお出迎え(汗)。どうやらシステムドライブではなかったようだ。

となるとマザーかメモリかCPUか、とりあえずランレベル1でデータドライブのバックアップを取ろうと思ったら、FatalErrorが出て完走しない。事態が悪化した。というか前記のいずれかが壊れているなら、だましだまし動かせると考える方が甘い。

OSの再セットアップが不可避なマザー交換だけは避けたい。できればCPUかメモリの交換で解決できれば、というのも甘いだろうか(苦笑)。

システムはTrueImageで静的にイメージ取って、データはRAID1+dump取って、と、障害に強いとまでは言わないけど復旧作業がそれほどストレッサーにならない態勢を作ってきたが、マザー交換だけが弱点になっている。メモリは当面大丈夫な気がするが、CPUは、LGA775が手に入らなくなったら、確実にマザー交換を巻き込むであろう。

次に壊れるのがCPUと決まっていれば、今のうちにLGA775を買っておくところなんだけど(笑)。

まあダウンした時に、原因究明を後回しにしてすぐに、とは言わないまでも2時間ぐらいで予備に切り替えることができるなら、サーバダウンの怖さもさらに低減するというものである。というわけで、サーバの仮想化が、おそらく鯖管としての最後の仕事になりそうだ。いや時間的な最後ではなくて、これさえやっとけば精神的な負荷の大きい仕事はないという意味で(^^;

2011/11/16 23:00 | カテゴリー：Fedora | コメント（0）

おそるおそる運転再開

この機会にデータドライブも1TBに増強するかと思ったら、ARAIDのカギが見つからん(汗)。どうやら半年前の地デジ化工事の際に、どこかに整理したままと思われる。あそこにあるとばっかり思っていたのが実は無かったというのが一番タチが悪い。

仕方ないので、今回のところは従来の320GBで復旧。結果的にデータ引っ越しの目的でのバックアップは、無駄に時間を使っただけに終わった。

さて、ランレベル3にすると、RAID1の/dev/sdb絡みでやたらエラーが出まくる。

kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
kernel: ata2.00: BMDMA stat 0x24
kernel: ata2.00: cmd c8/00:20:4f:3e:8c/00:00:00:00:00/ee tag 0 dma 16384 in
kernel: res 51/05:20:4f:3e:8c/05:00:1e:00:00/ee Emask 0x1 (device error)
kernel: ata2.00: status: { DRDY ERR }
kernel: ata2.00: error: { ABRT }
kernel: ata2.00: configured for UDMA/100
kernel: ata2: EH complete
kernel: sd 1:0:0:0: [sdb] 625140335 512-byte hardware sectors (320072 MB)
kernel: sd 1:0:0:0: [sdb] Write Protect is off
kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA

このエラー自体は、実は以前から出ていて、私としては「SATA1.5G固定のARAID99-2000にSATA3.0で読みにいってフラれた(のでUDMA100にした)」というのを想像している。

最後のWrite cache: disabedが気になる人もおられるようだが、HDDになりすましているRAIDBOXが、本物のHDD同様のキャッシュメモリを持っているとは考えにくいし(狭義のキャッシュというのは、SATA端子とプラッタの間にあるからこそ意味がある)、OS側で書き出し用のバッファをうまく管理すれば、少なくとも猛烈に遅いということにはならないと個人的に考える。

まあえらそうに書いたが、実はあっさりキャッシュ有効にできる方法があったりして(笑)。

世間でも、カーネルのカン違い?ということで、ちゃんと動いているようなら特に気にする必要はないという見解が大勢だが、なんかやたら頻発するようになったのが気になるのだ。

次回のメンテナンスでケーブルでも換えてみることにするが、ひとまずこのまま走らせて出勤。ただ、もしマザーボードよりもARAIDが早死にしたというのなら、あえてチップセットや拡張SATAボードのRAIDを使わず専用のハードを買った意味がないやんけ。

2011/11/15 23:00 | カテゴリー：Fedora | コメント（0）

とりあえずオフラインで

サーバの病因調査開始

シングルユーザモードで確かめるには、DSUBミニ15のモニタが必要になるが、フライトシミュレータのサブモニタ兼用で買った10インチが、こういう時に限って出てこない。先代のDELL24インチはまだアパートにあるが、ACアダプタが行方不明(汗)。いっそのことHDMI出力の計算機を1台組むかとも思ったが、電機屋は軒並み私の営業時間よりも早く閉店してくれるので、週末まではどうしようもない。

結局27時過ぎに探し当てる(^^;;

早速Fedora8をランレベル1で起動したところ、/sda3がないと怒られる。そりゃバックアップ保存用パーティション抜いてリストアしたから。

復旧モードからfdiskとmkfs.ext3で、システムドライブの残りをext3で仕立てる。なかなかトリッキーな手順だったがうまくいったらしい。

あとは引き続きランレベル1で、/etcをtarしたり、データドライブをfsckしたりしてみたが、とりあえずアクセスランプ点きっぱなしという事態にはならない。システムドライブ交換でうまくいったか!?

まだ12時間以上目を離せるまでの自信はないので、ランレベル3で起動するのは今晩まで持ち越し。システムドライブ交換で解決する程度のトラブル(ただし未確定)にしては、えらく時間がかかっているぞ!?

素早い復旧のための教訓

• システムドライブは身軽にしておく
• モニタはいつでも使える状態にしておく(オイ)
• 早く帰る(それができればっ)

2011/11/14 23:00 | カテゴリー：Fedora | コメント（0）