カテゴリー別アーカイブ: Linux

TeraStationのRAID5で2本HDDが壊れた際のデータ復旧に関して。

会社でバッファロー製の安物NAS : TeraStation (TS-XLシリーズ:1.5TB x 4本モデル)を使っていました。RAID5構成(実質1.5×3 = 4.5TB : スペアなし)で使っていましたが、この度4本の内2本のHDDが故障するというトラブルが発生しました。その過程と復旧までの流れを紹介。

その前に・・・・。

TeraStationなんぞ使ってはいけません。今使っている人は使用をやめるべきだと個人的には思います。

・TeraStationで検索すれば、公式サイトの他に、データ復旧+データサルベージ業者がSEOを競って掲載しています。異常な数です。これは一般的なHDDの故障率から考えても普通ではないことが予想されます。使うべきではないと思います。
・TeraStationの公式ページのファームウェアの更新履歴をみてみてください。過去から読み進んでいくと如何にこの製品が世に出て良いクオリティに”達していない”かが理解できると思います。
・そもそも基本的なSMART情報すらGUIインターフェイスから取得できないんですけども。

こんな論外な製品ではありますが、使い続けてしまったのがまずの失敗でした。考えてみればこのTeraStationは買って約3年で、今回は通算HDD3本目のトラブルです。HDDの一般的な故障率から考えても故障が多すぎます。つまりTeraStaiton自体のハードウェアに問題があるのです。綺麗すっぱりHDDが故障するだけならここまでサルベージ業者が氾濫しないはずであり、私がこうやって書くのも気合いで何とかなるケースが多いからだと思われます。

******************** さて、本題 *****************

・RAIDの基本的な知識は、wikipediaのRAIDの記事などを参考されたし。

<環境>
・TeraStation 1 (今回壊れた物、今後TS1と略す):TS-XLシリーズ。1.5TB HDD x4, RAID5。社内のそれほど重要ではないファイルを保存するためのNAS。HDDの4本を上からHDD1, HDD2, HDD3, HDD4と略す。
・TeraStation 2 (今回は壊れていない。今後TS2と略す):1.5TB HDD x4 Raid5。別プログラムにより、毎朝4時にTS1 -> TS2に同期コピー(クローン化)。社員はアクセスできず、基本的にTS1のバックアップとして保持。ポリシとしてはTS1が故障し、復旧出来なかったときの”1日”遅れのバックアップの為に設置。

<経緯>
7/16 正午頃:TS1のHDD4が故障と判断されアラームが鳴る。RAID5なのでこのタイミングでデグレードモード(縮退モード)に入る。その後の調査で、このHDD4は数百ブロック単位のセクタエラーが発生していた。Tera StationのOS(ソフトウェアRAID機能)が、そのセクタエラーに突入し一定時間アクセスできないため、HDD4を異常と判断し、デグレードモードに入ったと思われる。新規の1.5TBのHDDを購入しておいてので、この時点でHDD4を新HDD4に入れ替えて、RAID5のリビルドを開始した。

*留意1)本来ならこのデグレードモードに入った時点で、ネットワークから切り離し(社員にアクセスをやめさせるため)、リビルドではなく、データのバックアップ(別のHDDにTS1のデータをコピーさせる)べきであった。RAID5の復旧作業では、ここでバックアップをとるのが、セオリーかと思われます。これは私のミスだと思っています。しかしNASがどんどん容量が肥大化し、すぐに4.5TBの外部HDDを用意するのも面倒だと思ってしまったのです。TS2のバックアップもあるしと当時考えました。

* 留意2)RAID5の構成上(当たり前であるが)デグレード状態からのリビルドは非常に時間がかかる。しかも最近の1.5TBなり2TBなりの大きさが当たり前の時代でのリビルドはもう10時間程度では終わらないことを覚えておくべきである。

7/17 朝3時頃:TS1のリビルドが完了していない状態で、HDD3が故障。RAID5のデグレード中のリビルド状態で2本目のHDDが死亡した。つまりRAID5の理論通りであればこの時点でこのNASのデータは復旧不可能であり終了のお知らせである。深夜でありもちろんオフィスには社員が誰も居ない状況。

* 留意3)本来この時点でこのTS1はRAID5で2本HDD故障なので、本来アクセスできないはずである。しかし、出社直後の朝の状態でLAN内からは見えており、何となくアクセスできる状態であった。

* 留意4)冷静に考えれば1.5TB級のRAID5のリビルドは非常に時間がかかり、しかもその間4つのHDDがフル稼働になり相当熱も出る。その間にもう一本のHDDが死ぬことは、HDDの故障率より大幅にあがると考えるべきである。しかもHDDは同一ロットで、Tera Stationに使われているHDDは常時稼働を想定していない普通のHDD(エンタープライズHDDではない)であり、故障しやすいものを使っている。

7/17 朝4時:TS1 -> TS2のデータバックアップ(クローン同期)バッチが動作。

* 留意5)これは完全に私のミス。TS1がデグレードし、リビルドなどの緊急自体になっている以上、TS1 -> TS2のバックアップクローンバッチは停止すべきであった。1日前のデータは完全にTS2に保持されているため、7/16日のNASへのアクセス分だけ無効になるだけで済むからである。

7/17 朝4時:TS1 -> TS2のデータバックアップでファイルの消失が多数発生。先述の通り2本目のHDD3が死んだ時点でTS1へのアクセスが完全に遮断される仕組みであれば問題はなかったし。しかしTS1はHDD1, HDD2だけの不安定な状態でもネットワークに参加し続けていた。RAID5は3本以上のHDDでファイルの管理を分散管理しているが、そのフォルダ構造のみはHDD1, HDD2で保持できていたらしい。つまり朝出社してTS1のネットワーク共有フォルダにアクセスするとアクセルは出来るのにフォルダの中身が入っていないという箇所が見られた。つまり、HDD3に所属していたファイルが見えなくなっているという状態である。この状態で、朝4時にTS1 -> TS2のバックアップクローン同期バッチが動いたため、TS1のファイルが無くなったのをバックアップソフトがファイルが無くなったと判断しTS2のファイルを削除するという現象が発生した。これはやばすぎた。 これにより1日遅れたでもデータの大方を保持していたバックアップ用TS2のデータは完全ではなくなってしまった。

7/17 朝9時出社:HDD3も死んでリビルドが停止しているのを知る。TS2があるのでまだ冷静(笑)。自分のPCからそのTS1にアクセスしたところ、あれ?HDD1, HDD2しかないのにアクセスできるぞ?と疑問に思う。朝4時に働くバックアップバッチを停止していないことに気がつく。早速TS2を起動し(朝4時にバックアップが終わったら勝手に切れる)、中身を確認したところ、やはり一部のデータが失われている。この時点で血の気が引く(笑)。社員にTS2のデータを確認し失われたデータがクリティカルか確認したところ、大方問題はないが、やはり一部復旧できればありがたいという事。そこで、このTS1が復旧できないか可能性を探ることにした。

 

***************** 以上、トラブルの経緯。以下、復旧の過程 ***************

RAID5 = 2本以上HDDが壊れたら終了。それは基本である。どのTera Station 復旧・サルベージ業者もそう書いてあると思われる。しかしそこであきらめたら試合終了ですよ、である。そもそもHDDが2本連続で壊れるってなんだ?HDDの故障というのを、TeraStationのOS(ソフトウェアRAID機能)はどうやって判断しているのだろうか?

・TS1をとりあえず再起動してみた。するとmd2 (RAID5のデータパーティション)がマウント出来ないというエラーがでた。HDD1, HDD2しかないので、マウントできないのはあたりまえ。出社時にTS1にアクセスできていたのは、HDD3が死んでも、TeraStationとしてはmd2をマウントできていると錯覚しネットワーク上に共有フォルダを公開し続けていた(実際にはHDD3が死んでいるので、ファイルの一部にアクセスできなくなっていた)。Tera Station利用者は、RAIDが崩壊した際に、このような不安定な状態で稼働しつづけるという現象をよく覚えておくと良いであろう。不安定になったときにネットワークから自分で切り離す機能などはない。

・ここで、故障したHDD3(TS1に刺さったまま)をよく見てみるともちろんHDDのエラーとしてはでているが、触ってみるとモータは回っている。つまり最悪のHDDのモーター故障によるHDD死亡ではないことがわかる。実際にHDDのモーターが壊れるなんていうエラーは少ないのではと考えている。結果として、SMARTでチェックしたところHDD3, (取り外した)HDD4はセクタエラーによるリードエラーが発生している状態であり、まだ何とかアクセスはできそうな様相であることが分かった。ちなみに後で分かったことであるが、正常と思っていたHDD2もセクタエラーが発生しており、結果としてHDD2, HDD3, (取り外した)HDD4が同時期にセクターエラーを起こしていたことになる。恐ろしい・・・。何か他の要因があるとしか考えられないんだけども。あ、ちなみに熱環境ですが、特別ホコリに被っている状態でもなく、極度に暑い部屋に置いていたわけでもない。

・ここで冷静に考えると、HDD4が壊れてRAID5がデグレードモードに入ったわけである。リビルドという作業は、HDD1, HDD2, HDD3から(入れ替えた新しい)HDD4に復旧(再パリティ)する作業であり、HDD3の故障直前までは、HDD1, HDD2, HDD3が正常で、HDD4がリビルド途中による不安定な状態であると判断できる。つまり、HDD4は今回完全に無視し、HDD1, HDD2, HDD3で何とかRAID5のデグレードモードでマウントさせてデータを吸い出せないか考えた。というのは前述の通りHDD3はセクターエラーは発生しているが、何とかアクセスできるような状態であったためである。

<以下、TeraStationからHDDを番号を間違えないように管理した上で取り外し、別のデスクトップPCで作業をした>

・ここで、HDD3をセクター単位でコピーできるソフトを使ってまた別の新規HDD(2TB)にコピーすることにした。HDD3は1.5TBであったが、メーカーによってサイズが若干異なるため、明らかに大きなHDDにセクターコピーしたほうが良いためである。EASEUS Disk Copy Homeという無料でダウンロードできるソフトを用いてこの作業を行った。EASEUS Disk Copy Homeは、.iso形式でブータブルCD(DVD)を作成できる。そのCDでブートし、HDDをセクタ単位で丸ごとコピーできる。けっしてWindowsなどでHDDを無理矢理マウントしてはいけない。データが書き換わってしまっては終了のお知らせである。セクタ単位でコピーしたのは、HDD3にセクターエラーが出ているのは分かっていたので、人間の癌と同様にアクセスすればどんどんブロックが拡大していくセクタエラーを最小限に食い止めるためである。結果として新HDD3にセクタコピーが完了した。途中予想通り8ブロックでセクタエラーが発生していた。このブロックは何ともならんので、無視して飛ばしてコピーを続行した。この作業もあ1.5TBあるので8時間くらい掛かった。

*懸念:(この時点ではHDD2にセクタエラーが発生していることを知らなかったが)HDD3にセクタエラーが8ブロック発生したことで、ここに所属しているはずのファイルがどの程度影響するのか心配ではあった。

・この時点で、正常なHDD1, HDD2 (後にセクタエラーがあることが分かる。しかも200ブロック程度。HDD3よりも悪い状態であった)、コピーした新HDD3の3本でRAID5をマウントする作業を開始した。TeraStationは、何のことはないLinux + LinuxのソフトウェアRAID機能MDでRAIDを管理している。つまりLinuxのソフトウェアRAIDを使った方ならある程度扱うことができると思われる。私もRAID1はよく使っているし、最低限の知識はあった。

・今回はDVDブート(LIVE起動)のLinuxを用いて作業した。3本のHDDは、USB -> SATA変換(裸族とかいう製品)を用いてUSB経由で接続した。後から分かったことであるが、HDD1, HDD2, HDD3, HDD4は、それぞれTeraStation内で、/dev/sda, /dev/sdb, /dev/sdc, /dev/sddのデバイスファイルが割り当てられたことが分かった。LIVEのDVD Linuxで作業したのは、何かのHDD起動のLinuxだとそのOSが入っているHDDが/dev/sdaを取っている可能性が高く、いろいろ面倒かなと思ったからである。(結果としては得策だと思う)

・今回のデータボリューム(約4.5TB程度)のmd2パーティションは、それぞれ /dev/sda6, /dev/sdb6, /dev/sdc6で構成されていることが分かった。

・mdadm –examineコマンドで、各パーティションのMDスーパーブロックを確認してみる。MDのスーパーブロックというのは非常にキーになる項目であり、いろいろ調べていただきたいが、RAIDを構成しているパーティション(この場合は3つ:/dev/sda6, /dev/sdb6, /dev/sdc6)の後半部に、”そのパーティションは他のHDDとこのような状態でRAIDが組まれている”というような情報を保持しているデータ領域である。LinuxのソフトウェアRAIDが、このMDのスーパーブロックという仕組みを採用している理由は、たとえばあるLinuxサーバーにRAIDが組まれている時に、そのサーバのマザーボードが壊れるなり、RAIDとは関係のないOSが入っているHDDが壊れた場合などに、そのマザーボードなりOSを別の環境として構築した際にも、RAIDを構成している複数のHDDを持ってくれば、それぞれのHDDのパーティションのスーパーブロックの情報を読み出せば、このHDD同士でRAIDを組まれていたことが判定できてマウントすることができ、ある意味環境から独立していて障害に強いからである(らしい)。

<以下に3つのパーティションのスーパーブロック情報をペーストする>

>
> # mdadm –examine /dev/sdc6
> mdadm: No md superblock detected on /dev/sdc6.

> # mdadm –examine /dev/sdb6
> /dev/sdb6:
> Magic : a92b4efc
> Version : 00.90.00
> UUID : 16b11c01:a0a9825e:0470c5b9:91c14a48
> Creation Time : Sat Apr 18 04:53:29 2009
> Raid Level : raid5
> Used Dev Size : 1450031168 (1382.86 GiB 1484.83 GB)
> Array Size : 4350093504 (4148.57 GiB 4454.50 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 2
>
> Update Time : Tue Jul 17 06:38:03 2012
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 2
> Spare Devices : 1
> Checksum : e715a8a3 – correct
> Events : 18023
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 0 8 6 0 active sync /dev/sda6
>
> 0 0 8 6 0 active sync /dev/sda6
> 1 1 8 22 1 active sync /dev/sdb6
> 2 2 0 0 2 faulty removed
> 3 3 0 0 3 faulty removed
> 4 4 8 54 4 spare

> # mdadm –examine /dev/sda6
> /dev/sda6:
> Magic : a92b4efc
> Version : 00.90.00
> UUID : 16b11c01:a0a9825e:0470c5b9:91c14a48
> Creation Time : Sat Apr 18 04:53:29 2009
> Raid Level : raid5
> Used Dev Size : 1450031168 (1382.86 GiB 1484.83 GB)
> Array Size : 4350093504 (4148.57 GiB 4454.50 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 2
>
> Update Time : Tue Jul 17 06:38:03 2012
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 2
> Spare Devices : 1
> Checksum : e715a8b5 – correct
> Events : 18023
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 1 8 22 1 active sync /dev/sdb6
>
> 0 0 8 6 0 active sync /dev/sda6
> 1 1 8 22 1 active sync /dev/sdb6
> 2 2 0 0 2 faulty removed
> 3 3 0 0 3 faulty removed
> 4 4 8 54 4 spare

 

・上記でわかりますでしょうか?新HDD3 (/dev/sdc6)のスーパーブロックがないのです!!故障HDD3 -> 新HDD3はセクタ単位でコピーしているため、パーティションの最後にちょこっと付いているスーパーブロックの領域もまとめてコピーされるはずです。それが何の原因か無くなっていました。デグレート状態のリビルド中にHDD3が死ぬとHDD3のスーパーブロックは削除されるのでしょうか?この辺は意味不明です。このあたりでだいぶやっかいな状態だと分かりました。個人的には、HDD1, HDD2, 新HDD3の3本でそのままmd2(RAID5)パーティションとしてマウントしちゃえば普通にアクセスできると思っていたので、まさかの状態。

・とりあえずHDD1 (/dev/sda6), HDD2 (/dev/sdb6)のスーパーブロックの状態を見てみます。この情報によると、以下のようなことが読み取れます。

1)RAIDのレベルは5である。
2)RAIDディスクは4本。トータルのディスクの数は3本。アクティブなディスクは2本。トラブっているディスクは2本。スペアのドライブは1本。なんだこれ・・。めちゃくちゃだ。スペアが1本ってなんぞやと。
3)MagicナンバーやUUIDなどもここでわかります。/dev/sda6と/dev/sdb6は同一なので、これはRAIDパーティションで共通なのがわかります。HDD3にもこの値が書かれていたはずでしょう。
4)RAID5の1番目のHDDは、/dev/sda6パーティションであり、”Active”で”Sync”している状態。Major = 8, Minor = 6であることが分かります。この情報からHDD1は、TeraStationで、/dev/sda6でマウントされていたことが読み取れました。
5)RAID5の2番目のHDDは、/dev/sdb6パーティションであり、”Active”で”Sync”している状態。Major = 8, Minor = 22であることが分かります。

留意)ここで各HDDのMajor, Minorという数字は最初わからなかったのですが、Linuxのソースコードを読んで分かりました。この2つの数字で、/dev/sdb6などのマウントポイントをしめしていることがわかりました。Major=8, Minor=6だと、/dev/sda6となります。Minorが、22だと/dev/sdb6になります。勘の良い人なら予想が付くでしょう。HDD3は、/dev/sdc6に割り当てないといけないので、Major=8, Minor=38だと予想できます。

・こんな感じでスーパーブロックが読み取ることができました。スーパーブロックは、上記の内容よりRAID5の構成、状態、各HDDの情報、そして自分はそのHDDのどれか?などの情報が含まれています。またRAID5でHDD4が死んでデグレード状態に入り、リビルド中にHDD3が死んだので、HDD3, HDD4がfaultyになり、HDD1, HDD2だけがActive Syncになっていてニッチサッチもいかない状況であることもここで分かりますね。

・さて、新HDD3は、MDスーパーブロック情報が欠落しているため、RAID5に参加できません。マウント(アセンブリマウント)させようとしても、RAID5なので最低3本ないとマウントできないため、”not enouigh to start the array.”というエラーが発生し、マウントできませんでした。HDD3を見つけられないのですね。

・そこで、HDD3(正確には/dev/sdc6パーティション)にスーパーブロックを手動で無理矢理付けてLinux側をだましてマウントできないか検討しました。

・スーパーブロックの直接の編集には、以下のサイトが非常に参考になりました。多謝。

”無理やりのRAID復旧” | おごちゃんの雑文

・ここで公開されているソースコードを改変し(内容を理解しないと使えない)、HDD3に無理矢理スーパーブロックを付与することにしました。スーパーブロックをちゃんと理解するためには、おごちゃんの雑文のソースコードおよび、linuxのソフトウェアraidのソースコード(md_p.h)のmdp_superblock_s構造体に定義されているのでまずこれを読むと良いでしょう。というより、ここをちゃんと理解できないのであれば触るのは厳禁である。危なすぎて復旧できるものもできなくしてしまう可能性が高い。

例えば:http://lxr.free-electrons.com/source/include/linux/raid/md_p.h
などで。

・新HDD3のスーパーブロックの付与。設定したところを下記にちょいと解説。ウチの固有の情報なので参考程度に。間違えると失敗しますよ。あと、おごちゃんの雑文のコードは、あくまで書き込まれているスーパーブロックの変更・修正するプログラムであり、今回の様にスーパーブロックが消失しているパーティションに付与するには一部”おごちゃんの雑文”のコードを改変する必要があります。まぁその辺りを理解できていないとその後の作業が危ないので自分で考えてみて下さい。

nr_disks = 4;
raid_disks = 4;
active_disks = 3;
working_disks = 3;
failed_disks = 1;
spare_disks = 0;
state = 1;
events_loとevents_hiはHDD1, HDD2と同じ値を入れる必要がある(同じRAIDとして扱われない)
mdp_disk_tは適切に。mdp_device_descriptor_sに記述されている。配列になっていて、3番目のHDD3なのでdisk[2]が、HDD3相当になりますね。
number = 3;
major = 8;
minor = 38; // major = 8, minor = 38で、/dev/sdc6となる。
raid_disk = 3;
state = 6; // state = 6は、SA = Sync Active (つまりHDD3は問題なし設定する)

*こんな感じかな。あくまで私の環境なので参考程度に。

・さて、次はHDD1, HDD2のスーパーブロックを修正。上のmdadm –examineでHDD1(/dev/sda6), HDD2(/dev/sdb6)を見ても分かるように、2つHDDがfailed diskになっているなど、HDD3, HDD4が死んでいるRAID5崩壊の状態になっている。そこで、上記のHDD3に付与したスーパーブロックと同様に、

nr_disks = 4;
raid_disks = 4;
active_disks = 3;
working_disks = 3;
failed_disks = 1;
spare_disks = 0;
state = 1;
以上で、RAIDの故障本数などの情報をHDD1,2,3で揃える。
そして、HDD3が故障という状態であるのそSync / Activeの状態に変更する。同じくdisk[2]に対して
number = 3;
major = 8;
minor = 38; // major = 8, minor = 38で、/dev/sdc6となる。
raid_disk = 3;
state = 6; // state = 6は、SA = Sync Active (つまりHDD3は問題なし設定する)

という感じでHDD1(/dev/sda6), HDD2(/dev/sdb6)に修正を施す。

・この時点では、もう一度mdadm –examineを/dev/sda6, /dev/sdb6, /dev/sdc6に掛けて、3つがRAIDの情報・構成が一緒で、各HDDの情報などが一緒であることを確認する。RAID5の4本構成で1本死んでいて、HDD1, HDD2, HDD3のデグレード状態であることを確認する。コツとしては、event, stateなどを3本揃えないとraidとして一つとして認識されないこと。またstate = 0になるとraidとして健全(active)になりうまくいかない。あくまで4本RAID5の1本死んでいる3本でのデグレード状態なので、RAIDとしては状態はactiveではない。その為super->state = 1;になる。

・さて、この状態でmdadmで3つのHDDをアセンブリしmd2をマウントし成功しました

************** マウント後 ******************

・マウントに無事成功し、各ファイルは大方問題なくアクセスできることが分かりました。直ぐにネットワーク経由で別のNASにコピーしました。
・その際に、HDD2のセクタエラーの問題か、またはHDD3にセクタコピーした際に8ブロックほど無視して進めたのが問題か、コピー中に突然エラーが起こりファイルにアクセスできませんというエラーが発生しました。そうなるとまた直ぐにRAIDが崩壊してしまいHDD1, HDD2, HDD3のスーパーブロックが壊れてしまいました。なのでまた上記の方法で、スーパーブロックを書き直して、再マウントしました。これを繰り返し、大方のデータをコピーすることに成功しました。

 

************* まとめ ******************

・繰り返しになりますがTera Stationの使用は再度Googleなどで検索してもらい、そのトラブルの数を確認してもらい、継続して利用するが良いか検討するべきだと思います。私は使いません。やはりデータは宝なので初期投資が大きくてもちゃんとしたNAS (特にHDDはちゃんとエンタープライズ向けのHDDを使うのが良いのかな?)
・今回はRAID5(4本構成)で2本トラブってもデータが復旧できましたという紹介ですが、これはあくまでHDDの壊れ方が、モーターの停止などではなくセクタエラー程度で、何とかアクセスできる状態であったというのが大きいです。どんなものでも2本壊れて復旧できるもではありません
・Tera Stationは単純にLinuxのソフトウェアRAID MDを使ったものだけですのでその構造・仕様が分かっていれば今回のように無理矢理マウントなどの可能性があります。おそらくTera Stationの復旧・サルベージ業者は同等の事までやってデータを復旧してくれる業者もあると思います。1TBで10万円とか、かなり高額を要求される可能性がありますが。かなり業者が乱立しているのでまた価格競争も始まっているようです。実際には私のケースでもHDD3にスーパーブロックが消失するというトラブルさえなければ、比較的簡単にマウントできるので、その程度でビジネスをやっている業者も多いでしょう。少し出来る会社なら、スーパーブロックまで調整してアクセスしてくれる業者もあるかもしれません。私もこの程度なら今回かなり内容が理解できたので仕事を始められますね(やりませんが(笑))
・この記事の手法は、私が扱ったTeraStation TS-XLシリーズに関してです。最近は、Windows Storage Server版のNASもバッファローは扱っているようです。Windowsで管理されていたら、今回のようにLinuxのソースコードを読んで対応とかできないので手に負えないですね。LinuxのソフトウェアRAIDベースで動いているTeraStationの情報でした。
・個人的にはRAID5, RAID6ってどうなのかなと思いました。なにせ再構築が時間が掛かりすぎてその間にもう一本以上壊れる可能性って結構あると思うんですよね。その際にファイルが3本以上のHDDに分散管理されているってサルベージも複雑ですし面倒だなと。これだけ大容量HDDが安い時代なのでやっぱりRAID1(ミラーリング)か、非RAIDで、時間差バックアップでやるとかそっちの方が復旧も楽な気がします。どうなんでしょうね。
・当たり前過ぎますが、RAIDはバックアップではないので留意が必要です。私もその認識でTS2を用意してTS1を毎日1回クローンを掛けてバックアップを取っていましたが、今回のトラブルの様にRAID5が不安定に崩壊するとそのファイル欠損がそのままTS2にコピー(同期)されます。はっきりいって怖すぎます。やはり大切なデータは電気が要らない不揮発メディア(=今はBlu-Rayでしょうか)に焼き込むのが良いですね。別のHDD(群)でコピーしていくってやはり通電が前提で、何があってもおかしくないなと個人的には思います。これだけ写真・動画でデータ量が増えていますので全部をメディアに落とすのは現実的ではないかもしれません。しかしドキュメントファイル、各種設計データなどはそれほど大きくないのでは?最低限そういうデータは定期的なメディアへの焼き込みが必須だなと痛感しました。はい。基本ですね。
・結果的にHDD2, HDD3, HDD4がセクタエラーを起こしていました。実はこのNASは今回のトラブルまでに2回HDDを交換しています。使用約3年でHDD5本がエラーを起こすってちょっと普通じゃない気がします。HDDだけの問題ではない気が・・・。
・そもそもTeraStationにおいてHDDの故障診断がどうなっているか非常に気になります。というのはHDD2,3,4がその後調査でセクタエラーが発生したことが分かっていますが、不良ブロックは正常と判断されていたHDD2はエラーとして認識しませんでした。これはその不良ブロックにアクセスしたときにリードエラーが発生しトラブルと認識されるのかと思いますが、これが非常に判定が難しそうですよね。別Linuxに接続しSMARTを掛けたら直ぐにエラーが検出できたので、TeraStationお使いの方はウェブ管理画面からSMARTの情報(見られるんでしたっけ?)で定期的に確認した方がいいですね。

この記事は私が遭遇したトラブルと対処した防備録であり、皆様の環境とは大きく異なる可能性が高いです。この情報を元にデータが壊れても一切責任を負いませんので、ちゃんと理解して行動してください。サルベージ会社に頼むのもありだと思います。業者選びも大変ですが。また、あくまでこの方法は私が採った手法であり、HDD3のスーパーブロックが欠落していてもmdadmの–forceスイッチあたりで無理矢理認識?とかできるような気もしますがどうなんでしょうか。調べてみると無理矢理認識させると”自動で再構築が始まる”とかいう情報が多くて、そもそも3本のHDDのデグレード状態で無理矢理マウントしてデータを引っこ抜くという方針だったので、今更RAID5を正常な状態にするつもりはありませんでした。そのあたりで挙動が読めないmdadmにより強制アセンブリなどはちょいと避けました(スーパーブロックを直接編集するのもイレギュラーだとは思いますが)

Core i3-2100T + SSD + Scientific Linux6サーバに変更

このブログなどを管理しているサーバのハードウェアを更新しました。

更新理由は2つ
1)熱い:部屋の中で24時間稼働なのですが、何せ旧サーバーは電力食い虫で、電気代的にも節電的にも部屋の温度上昇面でも問題がありました。
2)うるさい:旧サーバーのストレージがHDDでしたので、24時間カラカラ言っていました。おかげさまで結構なアクセス数がある関係で部屋に居るとき常時カラカラ。この音をなくしたいなと。

そこで新サーバー構成は以下の通り。

CPU: Intel Core i3-2100T (Sandybridge)
M/B : GIGABYTE GA-H67MA-SUB3-B3 (rev.1.0) : H67チップセット
Mem : CORSAIR CMX8GX3M2A1600C9 : PC3-12800(DDR3-1600MHz) 4G x2枚セットを1枚だけ使用。1枚は不使用。
SSD (Main): Intel SSDSC2MH120A2K5 : 510シリーズ 6Gb/s MLC 120GB 2.5インチ @ EXT4 (discard)
SSD (Sub) : Intel SSDSA2MH080G2K5 : X-25M G2 3Gb/s MLC 80GB 2.5インチ @ EXT4 (discard)
DVD/CDドライブ:なし。USBドライブをインストール時のみ利用
CPUクーラー:XIGMATEK GAIA SD1283 : ファンは、Scythe 鎌FLOW2 12cm SP1225FDB12Lに換装。
ケース(超格安ケース・・・):GIGABYTE GZ-X1SPD-100
ケースファン:フロント、リア共に、Scythe 鎌FLOW2 12cm SP1225FDB12L
電源:Huntkey 絢風(AYAKAZE300) : 300W 80Plus GOLD
NIC : Intel PRO/1000 PT Server Adapter (EXPI9400PT)
OS : SL6 = Scientific Linux6 (RHEL6クローン) : 現状カーネル 2.6.32-71.29.1.el6.x86_64

消費電力測定(CPU, PCH, MEMあたり約0.1V程度電圧を下げるようにBIOSで設定。あまりちゃんと追い込んでいない)
1)SL6(Run mode3 : CUI))ログイン+アイドル時:28W (httpd,mysqld, qmail, 最低限必要なデーモン)
2)While(1)ループ1個:34W
3)While(1)ループ2個(Core i3-2100Tは2コアであるため2つループを回せばCPUは100%テンぱる):38W

というわけでアイドルは20W前後かなと予想しておりましたが意外と高かったです・・・。

雑感は、
・CPU/ケースファンは800rpmの物ですし、SSDになりましたので音はほぼ無音になりました。相当耳を近づけないとわかりませんので相当快適です。
・SandyBridgeはやはり良いチップセットですね。30W弱なので少し高めではありますが、もう少しCPUの電圧下げるなり(サーバとしての安定度とのトレードオフ)工夫してみようかなと。
・最大でも38W(電源ロス込み)なわけですから、もう少し低容量高効率の電源が出てくれば良いのですが・・。
・目につかないところに置くので格安のケースを用いましたが、やはり雑な作りでした。一方でHDDもないので多少雑なケースでも共振することはありませんし、問題ないでしょう。
・SSDを用いますので、WindowsでいうTrim機能を使うためにEXT4ファイルシステムは必須でした。そのためにもCentOS6がいつまで経ってもでない現状ではSL6の選択となりました。SL6で全く問題ありません。fstabにdiscardを指定。ちゃんと機能しているかはわからんのですが・・・。
・SSD mainとsubはsoftware raid0などを組んでいるわけではありません。SSDにraidはなんか違和感があるので。独立してマウントさせており、mainの重要なファイルをsubにsyncさせるバックアップ方式を取りました。その為、mainが故障した際に、前回syncまでの情報が失われる可能性と、復旧までにサーバーはダウンタイムがあることになりますが、個人サーバーですし、そもそもSSDが壊れる気がしませんし、良いのかなと。
・メモリは、4GBx2を買いましたが消費電力を下げる為、そもそもそんなにメモリは必要ない為1枚だけさしてあります。
・オンボードのわけわからんNICは使わずに、ここはちゃんとIntelのサーバー用Gigabit Ether (PCIx1)を使っています。

<SSDに関して>
・hdparmにてデバイス情報を取得しました。
SSD(Main):20110520_ssd510_hdparm : Intel 510 120G
SSD(Sub):20110520_ssdx25mg2_hdparm : Intel X-25M G2 80G

SSD(Main)がSATA3.0対応ですし、Windows下でのベンチマークも優れているはずです。
そこで、ベンチマークを計測してみました。

SSD(Main) 510シリーズ
# hdparm -ft /dev/sda

/dev/sda:
 Timing buffered disk reads:  558 MB in  3.01 seconds = 185.43 MB/sec

SSD(Sub) X-25G2シリーズ
# hdparm -ft /dev/sdb

/dev/sdb:
 Timing buffered disk reads:  798 MB in  3.00 seconds = 265.88 MB/sec

結果としては、SSD(Main)の方が遅い・・・。この点今調査中です。なんでだろう・・。何か情報をお持ちの方は教えて下さい。
* 参考:http://journal.mycom.co.jp/articles/2011/02/28/ssd510/index.html このあたりをみてもウチの510シリーズは遅すぎる・・・。

追記:CPU/Memのパワーまで加味されちゃうみたいですが、Bonnie++で計測したところ、いろいろな点で510シリーズの方が上回っていました。
まぁ、とりあえずこれで使ってみよう。

Lenovo G560eにLinux(Scientific Linux6)を入れて低消費電力GPS+センサーロガーを構築。

2011/06/13追記:このシステムを使って、福島まで放射線を計測に言ってきました→”東京日本橋から福島第一原発周辺まで車で放射線計測をしてきた(その1)”

************ 以下本分 *************

ちょっとした計測実験を予定しています。車にGPSを載せて走った位置のロギング(logging = 保存)+あるセンサーの値をその時間・位置をタグつけて保存する実験です。
ある程度長時間実験が想定されるため、車のシガーライターからDC/ACインバーターを介してACにして、そのACからその実験装置を動かさなければなりません。
そうなると、システム全体の消費電力を極力下げる必要があります。(使用予定のDC/ACインバーターは最大200W, 定格100W)。持っているSony Vaio Type Zは強烈なCPUのため、ノートの癖に最大100W越えという大電力でこれはパス。そこで、低消費電力ノートパソコン+計測システムを構築することにしました。

GPSは、秋月のGPSモジュールを購入。便利な時代になりました。
・GPSモジュール:RS232Cレベルコンバータ内蔵GPSモジュールGT-720F | 3200円
・RS232C – USBコンバータ:GPS用USB変換ケーブル | 1200円

4400円でGPS位置計測が出来てしまうという恐ろしい時代。USB変換ケーブルを通して、Baudrate 9600bpsで接続すれば、NMEAフォーマットで吐き出します。なんて簡単。
上記のGPSセットのUSBコンバータは、内部チップがProlific PL2303なのでLinuxでも認識可能だと判断し、計測PCは、Linuxにすることにしました。

さて、Linuxが動きそうなノートPCで消費電力が少ない物・・。とういうことでIntel Atom搭載のネットブックを探し始めました。
ネットブック向けのAtomも、N550というデュアルコア(TDP 8.5W)がリリースされているのでそれが搭載されているネットブックを物色。
一番安くて35000円位。価格コムで値段の安い順でソートを掛けると、その隣にLenovo G560eというノートPCを発見。

公式サイト:Lenovo エッセンシャルノートパソコン G560e

Thinkpadという名前は付けてもらえなかった格安シリーズのGシリーズ。その中でも最も安いノートPC

CPU : Intel Celeron T3500 2.1GHz (2Core/HTなし)
Mem : 2GB(PC3-8500 DDR2 SDRAM) : 最大8GB, 1スロット空き
HDD : 320GB(5400rpm) @ 2.5inch
DVD : DVDスーパーマルチドライブ
OS : Win7 Home Premium (6t4bit)
Video : GM45 統合4500MHD : 1366×768 px
Wireless 802.11b/g/n
Wired Ethernet : Atheros AR81 : 10BASE-T / 100BASE-T (Gigabitに対応していないのに注意)
内蔵カメラ:30万画素
カードスロット:5 in 1
質量:2.6kg
寸法:376x249x17.3-34.9mm

という仕様で34000円。同価格のAtom N550機よりも圧倒的に魅力でした。
といういわけでノートPCは、このLenovo G560eに決定。即納で次の日到着@NTT-X購入


こんな外装。


うん。安っぽい。がまぁ十分でしょう。ACアダプタも小さい!


なんとテンキー付き。Atom機ネットブックに比べたらかなりデカイです。


Windows7がプリインストールされています。最初で最後の起動なので記念撮影(笑
リカバリー領域(専用パーティション)にこのWin7が入っていて、メディアによるリカバリーDVDなどは付属していません。
付属ソフトにてこのリカバリー領域をDVDブランクメディアに落とせますが、2~3時間掛かりそうだったので面倒なので却下。
というわけでこのPCに付属していたWin7のライセンスはなくなりました・・。


Linuxは、RHEL6 (RedHat Enterprise Linux6)クローンのScientific Linux6(以下SL6)です。今注目のディストリビューションですね。
Centos6がいつまで経っても出ないので、私はこの2ヶ月くらい前からこのSL6に移行しています。使い勝手はCentosと一緒(当たり前か・・・)

・Win7などの最初のパーティションは全て破棄してフォーマット
・Ext4パーティションとswapを切り出してBase + Development Toolインストール(X環境は入れず:消費電力低減の為)
・つまりCUIベースLinuxとして使います。起動プロセスが少なくて極めて快適です。Celeronでも全く問題なし。


消費電力を測って見ました。

・起動中22W (最大ピーク27W)
・ログイン画面待機:17W (ランモード3 : X/GNOMEなど起動なし。CUIベース)
・While(1) :デッドロックプログラムを実行:1個 : 21W
・While(1) : デッドロックプログラムを実行:2個 : 26W *Dual Core CPUなので2つ実行させればCPUが完全テンパっている状態です。
*留意:バッテリー満タンのため、バッテリー充電は止まっています。よって充電中であればもっと上がるでしょう。

なかなか低消費電力でした。

あとは色々な雑感を。

・GPSセットのUSB変換(Prolific PL2303)は、何のドライバも入れずにそのまま認識(デバイスファイル/dev/ttyUSB0に現れる)。
・uucpパッケージに入っているはずのシリアルターミナルソフトcuがなぜかuucpを入れてもインストールされない。その為、cuをソースコードで拾ってきて手動インストールした。# cu -l /dev/ttyUSB0 -s 9600で、GPSは取得可能。なんて簡単。
・今回の計測システムは、cuで取得される全GPSログをまずファイルにそのままダンプ保存。そのファイルに対してtailとgrepを使って最新のGAGGA列を抜き出す。phpのスクリプトでGAGGA列カンマ区切り取得をして、経度・緯度・高度・時間を取得。その数値をSL6内に立ちあげたmysqlサーバにinsert。このPHPスクリプトをcron + sleepを使って約15秒に1回立ちあげてGPSデータをmysqlサーバに保存してゆきます。なんて簡単。phpのコードを書いただけなので、ここまで作業時間約1時間。なんて単純なGPSロギングシステム。自転車で使っているGarminとか使えば良いじゃんとかのツッコミはなしで(Mysqlに入っていないと、もう一つのセンサーとの時間同期処理が後で面倒なので)
・Scientifix Linux6インストーラーは無駄にマウスを使うのですが、付属のトラックパッドマウスはドライバーがなく動きませんでした。USBの普通のマウスをさして対応可能です。もともとCUIインストールなので、インストール終了後は不要ですし。
・デフォルト起動状態では、NIC Atheros AR81は認識しません。moogme開発記録さんのブログ:Atherosのネットワークドライバをインストールなどを参考に(ドライババージョンが上がっているので適時読み替えて)対応。インストールはすんなり行ったけど認識しない。あれれ?と思ったけど、ifcfg-eth0のスクリプトが無かった。適当に書いて/etc/init.d/network restartで認識。Ethernetも問題なし。
・XウィンドウなしのCUIモード(ランモード:3)は不便と思われるかもしれませんが、ALT+F1,F2,F3でターミナルも切り替えられるのでマルチタスクも可能です。データのロギング程度はこれで十分かなと。

というわけで、GPSなどのセンサーを併せて常時約20W程度のロギングシステムが出来ました。なかなか良い感じです。

* /proc/cpuinfoを一応アップしておきました。興味があれば。cpuinfo

追記:こんなの組み込みでやれば10W以下は余裕とツッコミを受けましたが、もちろんそれはその通りですが、まぁ使い勝手や開発のし易さから今回はPC + Linuxベースで。