アカウント名:
パスワード:
blockの回復が終わって落ち着いていますか?
落ち着いていない場合、まれに zero fill block を返してくる悪い子がいるのは聞いたことがあります。
blockの回復というのは、後からRAID5に追加した欠落分のHDDにデータの同期が完了していたかという意味ですよね？
記憶としては曖昧ですが、md5を取得した時点では完了していたと思います。
また本日MD5が異なる事に気がついた時点で上記の二つのファイルのmd5を再取得しています。
なるほど…だとすると事態はもう少し深刻かもしれません。
判ると思いますが、Raid5は1stripe中、最大1stride 破損していても、他の stride 情報からデータを回復、stripeを復元します。で、1HDDが丸ごとぶっ飛んだ場合はそのHDDが持っている stride が全滅するので、新しいHDDを指してやると 他の stride からそのHDDのイメージを回復します。
ところが。
じゃぁ、HDD中の 1sector とかが壊れた場合（代替セクターに移行しようとしたが元データが読めなかった場合）、で、年中(その 1sectorを含む) Stripe へアクセスしていない場合、 Raidコントローラーは stride 破損に気がつきません。この状態で 1sector壊れたのとは別の HDD がぶっ飛ぶと stripe は永久に復旧不能に陥ります。
こうなった場合に 1stripe 全滅で返すとそれはそれで被害甚大なので、stripe 的には返しておいて、ioctlでエラーが判るようにする…という機種は多いです。
1sector 破損状態を回避するには、ようするにHDD破損時に「そのHDD以外に問題児がいない」状態にしておけばよい。
1) Raid6 を使う2) Raid5 でもいいけど、月1回ぐらいのペースで全Volumeの全領域を read アクセスする(dd とかで読んで、読んだ内容は読み捨てる)。おかしな stripe が見つかったら、Raidコントローラーが裏で自動復旧してくれるはずです。3) /dev/sg* で各HDDにアクセスできる場合は、それを通じて smartctl とかで disk の状態を監視、代替セクタへ移動したsectorの数を調べる (だいたい10個ぐらいになったら、交換の準備を始めるとよい。まぁ、実際には「増加速度」との御相談ですが)。
の3つがよくある解決策です。
高いRaidには2番を自動的にやってくれるものもあります。当たり前ですが、安物との差別化ポイントの１つ。# どれも確率を下げてるだけですけどね。
RAID6までいくとちょっとコストが上がりますので、今回はRAID５のままで定期的にデータ読み出しをやってみます。
ちなみにLinuxのソフトウエアRAIDで構築してみます。
とりあえあず現在のままでは何かおかしいみたいなので、片輪状態でのデータコピーはやめて、きちんとRAID5を組み直して、RAID５のHDD間の同期がおちついた後に、データの再コピーを行ってみます。
（今回異常が出ているのばバックアップデータの方なので同じデータが別サーバに有ります。なのであまりコストをかけたくないというのもありまして。）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
Raid5は落ち着いたか? (スコア:1)
blockの回復が終わって落ち着いていますか?
落ち着いていない場合、まれに zero fill block を返してくる悪い子がいるのは聞いたことがあります。
fjの教祖様
Re: (スコア:1)
blockの回復というのは、後からRAID5に追加した欠落分のHDDにデータの同期が完了していたかという意味ですよね？
記憶としては曖昧ですが、md5を取得した時点では完了していたと思います。
また本日MD5が異なる事に気がついた時点で上記の二つのファイルのmd5を再取得しています。
Re:Raid5は落ち着いたか? (スコア:1)
なるほど…だとすると事態はもう少し深刻かもしれません。
判ると思いますが、Raid5は1stripe中、最大1stride 破損していても、他の stride 情報からデータを回復、stripeを復元します。
で、1HDDが丸ごとぶっ飛んだ場合はそのHDDが持っている stride が全滅するので、新しいHDDを指してやると 他の stride からそのHDDのイメージを回復します。
ところが。
じゃぁ、HDD中の 1sector とかが壊れた場合（代替セクターに移行しようとしたが元データが読めなかった場合）、で、年中(その 1sectorを含む) Stripe へアクセスしていない場合、 Raidコントローラーは stride 破損に気がつきません。
この状態で 1sector壊れたのとは別の HDD がぶっ飛ぶと stripe は永久に復旧不能に陥ります。
こうなった場合に 1stripe 全滅で返すとそれはそれで被害甚大なので、stripe 的には返しておいて、ioctlでエラーが判るようにする…という機種は多いです。
1sector 破損状態を回避するには、ようするにHDD破損時に「そのHDD以外に問題児がいない」状態にしておけばよい。
1) Raid6 を使う
2) Raid5 でもいいけど、月1回ぐらいのペースで全Volumeの全領域を read アクセスする(dd とかで読んで、読んだ内容は読み捨てる)。おかしな stripe が見つかったら、Raidコントローラーが裏で自動復旧してくれるはずです。
3) /dev/sg* で各HDDにアクセスできる場合は、それを通じて smartctl とかで disk の状態を監視、代替セクタへ移動したsectorの数を調べる
(だいたい10個ぐらいになったら、交換の準備を始めるとよい。まぁ、実際には「増加速度」との御相談ですが)。
の3つがよくある解決策です。
高いRaidには2番を自動的にやってくれるものもあります。当たり前ですが、安物との差別化ポイントの１つ。
# どれも確率を下げてるだけですけどね。
fjの教祖様
Re:Raid5は落ち着いたか? (スコア:1)
RAID6までいくとちょっとコストが上がります
ので、今回はRAID５のままで定期的にデータ
読み出しをやってみます。
ちなみにLinuxのソフトウエアRAIDで構築してみます。
とりあえあず現在のままでは何かおかしいみたい
なので、片輪状態でのデータコピーはやめて、
きちんとRAID5を組み直して、RAID５のHDD間の
同期がおちついた後に、データの再コピーを行って
みます。
（今回異常が出ているのばバックアップデータの方
なので同じデータが別サーバに有ります。なので
あまりコストをかけたくないというのもありまして。）