ごまめの遠足。

やっぱりハングアップ

帰ったら、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）

11月の危機

サーバのディスクアクセスランプが点きっぱなしになる。

とりあえずハードウェアリセットから再起動はできたので、生きているうちにデータドライブのバックアップを取って(たぶん成功)、MySQLのデータを含む/varのアーカイブを取って(たぶん成功)、/etcのアーカイブを取ろうとしたところで再びアクセスランプが点いたままになる。

今回は、ディスクアクセスに関するエラーらしき表示をコンソールに出す余裕!?があるので、とりあえずPSUとかメモリとかは直接の原因ではなさそうだ。というわけで、システムドライブか、データドライブミラー(ARAID99-2000)か、マザーボードのいずれかでほぼ決まりだが(範囲広すぎ)、理想的な復旧シナリオとしては、

• 原因はシステムドライブの寿命で
• TrueImageでイメージを吸い出す間もちこたえて
• イメージ移植した新ドライブに入れ替えると復旧する

であったが、取り出した時点で過去何週間かのバックアップファイルが入ったままになっていて、本来2GBそこそこのバックアップイメージのはずが80GBを超える。わざわざシステムとデータを別ドライブに分けた意味を忘れて、システムドライブのサイズをいたずらに大きくしてしまったのは大不覚。強引にバックアップしようとしたが、80GBの空きのあるフリーのHDDがなく途方に暮れる。悪いことにメインPCの調子も悪いので、共有ディレクトリにアップロードすることもできない。

一応バックアップ保存先のパーティションを除外すれば、短時間でコンパクトなバックアップは取れた。あとは別ドライブに領域残して復元して、復旧後バックアップ保存用のパーティションを改めて作り直すという手順だが、TrueImageが想定している可能性が(フルバックアップよりは)低いイレギュラーな手順なので、いまいち不安は残る。というか最も理想的なシナリオにしてこのややこしさ(汗)。

でもって、ARAID2000のアクセスランプも点きっぱなしになったというところに、システムドライブはシロかなという予感も感じる。

ちなみに、ARAID2000の故障であれば、元手はかかるけど別のミラーユニットを買って、同じSATAポートに繋げれば、引き続きそのまま使える(はず)。

USBとかだと、lvmの再マウントという未経験な手順が必要だが、まあOSもそのぐらいのことは想定しているであろう。

最悪なのはマザーボードの交換が必要なケースだ。CPU/マザー/メモリの3点セットが必要なうえ、おそらくOSやらサービスやらの再セットアップが必要だ。

将来計算機ごと交換しなければならない場合でもスムーズに復旧できるように、仮想化でも導入するべきかもしれない。

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

TrackballWorks v. Firefox

Kasperskyが出す窓については、TrackballWorksを一旦終了すれば、トラックボールでも一応操作はできるので、まあOKだ。プロテクションのレポートには、KTBWORKS.EXEがKasperskyのプロセスavp.exeにアクセスしようとして突っぱねたと記録されている。

セキュリティソフトが(勝手に動いている)他のプロセスを監視するのはわかるが、入力デバイスがセキュリティソフトのプロセスをつつく(すくなくともそう判断される)って、どういう状況なのか!? まさか「何者かが自分の出した窓にあるボタンを押そうとしている」とかいう判断だったりして!? だとしたら「あんたら押してもらうためにボタン表示しとるんやろ!?」とツッこまねばならない。やっぱり、トラックボールを操作して、それが思いどおりに画面やらプロセスやらに反映するまでには、想像を絶する過程があるらしい。

TrackballWorksとKasperskyの抗争は一段落したが、今度はいつの間にかFirefoxだけがスクロールしない症状に見舞われた。Kasperskyのプロテクションを一時的に切ったり、TrackballWorksを入れ直したりしても改善せず。昨日は確かに動いていたので、心当たりがあるとすれば、Kasperskyの定義ファイルが更新されたとか、スタンバイに落として復帰したとかぐらい。前者なら最悪セキュリティソフトを乗り換えればすむが、後者だと少し厄介だ(いやブラウザ乗り換えたらいいのか)。

それより、なにゆえFirefoxだけというのが気になる。Firefoxのスクロールは、独自の処理をしとるのか? と設定見たら、果たして『自動スクロール機能』『スムーズスクロール機能』とかいうのが見つかる。それぞれの意味するところは不明だが(ウソですちょっと調べたらわかります)、とりあえず両方外してFirefoxを再起動すると、見事に復活!!

というわけで、あとはどちらが悪さをしているのか確かめるため『スムーズスクロール機能』をONに戻して再起動。うまく動く。それなら『自動スクロール機能』か? と、これもONに戻して再起動。やっぱりうまく動く(アレ?)。

…まあ動けばそれ以上の詮索はする気もないが、ムリヤリ推理すると、プロファイルに不整合が出たのを、オプション設定の変更を通して修正した、というところかな? Firefox1から、PC何台も受け継いできたプロファイルなので、何が起こっても不思議ではない!? やっぱり思いどおりにPCが動くというのは、けっこう奇蹟的なのかも(こればっかり)。

2011/09/26 22:10 | カテゴリー：Windows | コメント（0）