案件・業務の進捗記録と備忘録

以前にこのエントリに記述したサーバ交換ですが、その後、１ヶ月くらいの稼動中に、突然ファイルシステムが崩壊(？)しました。ftpとsshを接続して操作中に、ふとデータベースが停止していることに気づいて調べると、データベースファイルが消えていました。理由がわからず、ディレクトリを見ていると、一部のファイルの日付と内容が、古いものに巻き戻っているのを発見。さらに色々なディレクトリを調べていると、そのうちにサーバからの応答がなくなりました。

なにが起きたのかさっぱりわからなかったのですが、原因がわからないとこの先困るので、それなりに思い当たる点を考えてみました。

ハードウェアが対応していなかった

もしそうなら、１ヶ月間も稼動できないはず。/var/dmesg を見てもおかしなエラーはありません。なので、これは考えづらい。

ハードウェアが故障した

トラブル後にチェックしたところ、全て正常のようです。

電源容量が足りなかった

これはまるっきり無関係とは言い切れません。AC電源を84w出力の製品に変更したのですが、アイドル時こそ消費電力が少ないものの、フル稼働状態ではギリギリだったのかもしれません。しかし、可能性としては低いような。

SSDのパーティショニングに失敗した

SSDはブロック単位でアラインメントをあわせないと遅いので、fdiskでそのようにパーティションを作成した後にRAIDに参加させましたが、この過程でパーティションサイズとか何らかの間違いがあったなど。しかし、ハードもOSもLBAでアクセスするはずなので、ジオメトリ(シリンダ境界の無視)が障害になるとも考えづらい。

resize2fsの操作やRAIDの再構成に失敗した

ファイルシステムの壊れ方から見て、この可能性が一番高いように思えます。resize2fsの過程で何らかの操作を間違ったか、その後fsckでチェックをかけるときに、ぼーっとしてマウント状態にもかかわらず修復オプションを切らなかったとか。この可能性が最も高いように思います。

サーバが止まった時点では、これらの原因を特定することは出来なかったので、想定できる上記のトラブル要因を切り離して再構成することにしました。ハードウェアには、世代が古くCentOS5の運用で実績のあるLGA775マザーとCPUを使用、HDD*2のRAID1にファイルシステムをバックアップから戻し、再度サーバーを構成しました。sataコントローラは以前のサーバで使用していたPCIカードをそのまま使用、電源についてはstressで負荷を目いっぱい掛けた状態の最大消費電力が45w程度であることを確認してAC電源84wを使用、ファイルシステムにはパーティション拡大などの余計なことはしないことにしました。その結果、現在ようやく１ヶ月くらいの安定稼動が続いています。

自分でサーバを作ると、いざおかしくなったときに問題の切り分けが難しく、再稼動にも時間がかかるので、クリティカル業務に使用するサーバは、やはりメーカー量産品のほうが安心ではありますね。それほど大規模ではない企業やセクションにおいて、PCの操作が出来る人が自前でサーバを立てて運用するような話も聞きますが、こういう場合の負担やロスも、危機管理として予め考慮しておく必要があるでしょう。詳しい人が、業務命令や好きだからという理由でサーバの構築や運用を行ったとしても、その後にどれだけの負担があるかまでは、初期段階ではなかなか想像できないものですから、組織内での自作サーバ運用は、やっぱりお勧めできないですね。何とでも出来る人がいれば何とでもなるでしょうけれど、トラブル時の負担はかなり重いです。

--

以下が、昨年11月に構成したときの記事です。おそらくハードやOSの動作には問題が無いと思うので、再び構成を戻したいのですが、現状うまく動いているので、今の機器構成でいこうかと思います。※ちなみに、このときに交換したコンデンサが膨れた古いマザーは、コンデンサ交換をしたのですが、今となってはなかなか使い道が無いですね。一応、保守部品として保存することにしました。

--

秋の気配も深まったある夜、これまで使用していたサーバのファンから異音がしているのに気づきました。ファンがダメになってきているなと思いつつも暫く放置していたのですが、以前からsmartdが報告しているハードディスクのsmart値が気になっていたこともあって、サーバを開けてみることにしました。

どのファンだろうと思って調べたところ、電源ユニット(SeaSonic SS-300SFD Super Versatile Plus)のファンが壊れかけているようです。いったんサーバを停止してファンを交換しようと分解したところ、なんと・大きめの電解コンデンサ全部の頭がぽっこりしているのを発見。

こりゃ電源交換か、とにかく気づいてよかったわいと思いつつ、マザーボードを見ると…これまた、CPU脇の大きい電解コンデンサの頭が何本かぽっこりとしています。

危険を感じて、2台のRAID1構成のハードディスクの一つを外してバックアップを行った後に、なんと不良セクタ発生。

当ブログの過去のエントリを見ると、このサーバを立てたのが2008年の1月。ということは、4年半以上の間、ほぼ連続稼動していたわけで、ディスクのsmart値をみると、通電時間が43,000時間以上・ロード/アンロードサイクルは838万回を超えておりました。ある意味、どの部品も非常に良く持ったというべきでしょう。

そこで部品の全交換となるわけですが、こういう場合、通常はOSを新規インストールするのが常道だと思われます。が、なんとかそのままディスクの内容を生かして新しい構成に移行できないかと考えました(※新規インストールして4年以上にわたる環境構築の再現が非常に面倒だったことと、果たしてそれが出来るのか？という興味がありました)。

元のサーバーは、SiS 741GX チップセットにMobile Athlon XP 2100+を搭載したマザーに、PCIでSATA1のディスクを繋げていたという、今時ありえない古さを誇るマシンで、ディスクには、カーネルのアップデートを重ねたCentOS5.8が入っています。ということは、そこそこ新しいチップセットやCPUでも動く可能性がある。そこで、新規インストールも覚悟の上、どうせやるなら今年の夏に発売された最新のチップセットに現在のディスク内容をそのまま載せて使ってみようと考えました。

いきなり闇雲にパーツを買ってきて組み立てて、ディスクをつなげて起動させるのではなく、調査や検証も念のために行いました。検証には、ディスクをそのままVMware Playerに繋げてみたり、Intel LGA775のPCに繋げて動作させてみました。いずれもうまく動作したので、最新のCPU＋チップセットでもいけそうだという勘が強くなりました。

いよいよパーツの選定と購入ですが、後継に選んだパーツ構成は、以下の通りです。

1. CPU: Celeron G550
   安価かつ必要十分なパワー



2. Mother: MSI B75MA-E33
   最新のIvy Bridgeに対応する今夏にリリースされたチップセット。サーバに使うにもってこいといえる、無駄な機能が無い上に32bit PCI がネイティブで接続されている優れもの。安価なのにオール固体コンデンサの製品です。同価格帯のASRockのB75マザーと最後まで迷ったのですが、ASRockの方にはASmedia?外部SATA3が付いているなど、なんかごてごてした感じがありましたので、シンプルな方を選びました



3. Memory: ADATA DDR3 XPG Gaming series 4GBx2
   別にオーバークロックするつもりも無いですが、安かったので購入



4. SSD: ADATA SP900
   ADATAのSSDを使ったことがなかったので、それだけを理由に購入



5. Power supply: AC150-AP04AA
   WIndows98の頃、電源の背面からぶしゅーと煙を吹いたことがありました。その記憶もあり、今回もコンデンサの劣化を目の当たりにしたので、固体コンデンサ＋ハイブリッドアルミ電解コンデンサ(多分)を使用したこの電源に決定

そして今回、これまた実験のような感じですが、SSDとHDDでソフトウェアRAID1を構成してみました。しかも、sda=SATA3(6.0Gbps)とsdb=SATA1(1.5Gbps)との組み合わせです。これ、予想通りというか、RAIDの再構築の様子を見ていると、やっぱり遅い方に足を引っ張られますね。RAIDメンバーからHDDを外してSSD単騎で起動すると、凄まじい速さで起動します。

ただ、RAID1では、読み出しには最初のメンバー(例えばsda)を使うという情報もあり、もしかしたら、現在の環境で読み出しは少し早いかもしれないです。体感が出来たわけではありませんが。

ワットチェッカーで電力使用量を計測して見たら、アイドルで23W。Sandy Bridge のセレロンは優秀ですね。予想以上に省電力な構成となりました。

ということで、何世代も前に構築したCentOS5環境を、そっくりそのまま最新のチップセットに持ってくることが出来ました。RHELのロードマップによれば、5シリーズは10年のサポート期間を設け、来年？にリリースされる5.9は、Sandy Bridgeへの更なる対応強化・Ivy Bridgeへの対応等を含むらしいです。

昨年の夏くらいに、安かったのでOCZ Agility3(64GB)を買いました。安価だったので買ってみたものの、ネット上であまり評判が良くないようなので、サブPCのシステムとして使用していました。現在600時間くらい通電しているようですが、先日、Crystal Disk Infoをみたら、不良ブロックが増えていました。購入時には不良セクタはゼロだったのに大丈夫かな…と思いHDTuneで不良セクタの走査チェックをしてみたところ、赤いブロックが転々と…読めないセクタが出るわ出るわ。ハッシュチェックで全ファイルをチェックしたところ、何度リトライしても読めないファイルがあります。

これ、書き込んでるときには正常書き込めたのだけれど、時間が経つうち(またはウェアレベリングの移動時などに)に、当該セクタ(ブロック)が壊れたっていうことですよね。SSDのセクタ管理の仕組みは良くわからないのですが、もしハードディスクのようにECC(エラー訂正)領域も連続しているならば、一緒に壊れてしまえばいかなる強固な訂正も無意味でしょうから、ファイルが読めなくなるのもわかります。

しかし、大して使ってもいないし、TempやPageFileはRAMディスクにしてあるので書き換えもしていないし、なんで不良ブロックが増えているのだろう？という疑問がありました。Waer Range Delta の値がゼロなので、ウェアレベリングの移動はまだ行われておらず、同じブロックに保持されたままでしょうから、そのブロックがいつのまにか壊れたのではないかと推測しました。

同時期に買ったCrucial M4(128MB)には、買ってきた当初から工場出荷時の不良ブロック数がある程度ありましたが、それ以降はまったく不良セクタは出ていません。Agility3とM4の品質が段違いという可能性もなくはないですが、M4には『工場出荷時の不良ブロック数』項目があるということは…と、少し考えてみました。

ここからは、もしかしたら・の話ですが、NAND型フラッシュメモリには、シリコンそもそもの品質や特徴・安い製品で使用するシリコン部位などの理由によって、トンネル酸化膜が劣化していくとかのレベル以前に、書き換えに何回も耐えられない・電荷が保てないなどの「歩留まりとしての不良」に相当する部分があるのではないだろうか…？と、考えてみました。技術的な裏づけも何も無いのですが、そこで思ったのが、

• Crucialは製品が完成した際に、何度かNAND型フラッシュメモリを走査して、弱い部分を予め洗い出してから出荷しているのではないだろうか？
• OCZは、もしかしたら製品完成時のチェックが少ない？ために、当方ではたいして使っていないうちに不良が出てきたのでは…

※この仮説は、あくまでも当方の思い付きにしか過ぎません。SSDの製造過程や技術とは関係ありません。

ということは、最初にがっつりと全体に負荷を掛けてみれば、もしかしたら読み書き保持に弱いブロックはさっさと代替され、その後しばらくは安心して使えるかも知れない…と、Agility3のファームウェアを2.25に更新するついでに、不良ブロックの代替と負荷を与えるために、QuickTest / ExtendTest/ ZeroFill を繰り返し掛け、全領域を何度か走査してみました。その過程で不良ブロックはそれ以上増加せず、HDTuneでチェックしても、不良ブロックが代替領域に置き換えられたようで、全てのセクタが緑色になりました。

CrucialのM4で工場出荷時の不良ブロック数が示されているのは、もしかしたら、Crucialは製造直後での不良部分はあって当然と認識していて、だからこそ品質管理で(何回か)全検査をして、その結果をS.M.A.R.T.に残しているのかな…とほのかに思いました。本当のところはわからないですが。

SSDは、出てきた当初に考えられていた以上に書き換え回数がタフだという話もありますので、SSDを買ってきてすぐにディスク検査を念入りにやるのも意味があるかもしれません。当方としては、今後もしSSDを買うことがあれば、購入後すぐにデータを移さず、自分だけのおまじないのつもりで、最初に念入りにテストをしようと思った次第です。なにしろ、買ってきて移動したデータがいつのまにか読めなくなってお手上げ・は困りますからね。どんなおまじないでもやりたくなります。

※再び繰り返しますが、実際に効果があるかどうかは証明できません。安心した次の日に読み込めなくなるブロックが出るかもしれないです。

SSDは高速でいいのですが、上のような経験をしてしまうと、データを安心して読み書き出来る「信頼性」に不安を持ってしまいますね。構造上いつかは壊れるのが当然としても、その「いつか」が今日明日だと厳しいです。SSDが販売され始めて何年か経ちますが、SSDでデータが読めなくなったケースはどのくらいあるのでしょうか。個人的には、エラー訂正の強化・内部での二重化・三重化のように進化する方向もあってもいいように思える経験でした。

--

にしても、SandForce SF-2281は不思議です。データを圧縮しているのですが、書き込みデータを減らして時間を短縮するためなんだろうけれど、速度にムラが出るのはわかりきっているし(実際に高速ではない)、圧縮前・伸長後のデータ化けチェックもしなきゃならないだろうし、圧縮したからと言っても使えるシリコン領域を稼げるわけでもないし。