アカウント名:
パスワード:
RAID5ならパティディスクは分散だろ
で、バックアップサーバの障害詳細が書いてない事から、リカバリ方法を確認しておらず、リカバリを失敗して全部壊したのでは…… 放置プレイとか復旧できずとか、「技術的知見・運営ノウハウの蓄積は達成」っていうのは、笑うところだよね！
えー、パリティとスペアは別物です。
5D データディスク５台(分)1P パリティディスク１台(分)の６台１セットのRAID5となっていたようですが、障害発生時にまずもう一台の破損による復旧不可能に対応するため、(ホット)スペアとして１台以上ないというサービスは変だろというのが親コメの意味ではないかなと。
# とはいえ、運用ルールとの兼ね合いで、いきなり復旧させないとか、ホットじゃないスペアだったりとかはアリだし、そもそもRAID6じゃないのかとか、いろいろ異論はありそうですが。
個人的には * RAIDと
RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。
非RAID 5なディスクで表面検査をしないと発見できないようなエラーは、当然RAID5でも表面検査しないと発見できないでしょう。RAID 5の要件に「表面検査をすること」が含まれていないのだから当然ですね。ただ、それまで問題なく読み書きできていたRAID 5ディスクアレイであれば、そういった「発見されないエラー」が発見されたとしても、データ保全は可能じゃないでしょうかね。だって、その部分はそれまで読み書きしてなかったんでしょうから。もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。まあ、そういうエラーをレポートしないRAIDコントローラってのもあるのかも知れませんが…
定期的な全セクタのスキャンを行っていない限り、各ディスク上に「たまたまずーーーっとアクセスが行っていなかったブロック」はどうしても存在しちゃいます。で、そこのデータが読み出せない状態になっていると、ディスクが1台failしたあとに再構成をかけて初めて気付き、アレイ全体がfailしてしまう、ということで。
> もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。
ディスク上には長期間読み書きされないブロックがどうしてもできてしまう、というのが親コメの「詳しい人」が言ってることかと思います。全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
>全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
逃げ方。システム負荷の低い時間帯に cron でcat /dev/ad0 > /dev/nullする。
#まあRAID5ってこわいよねRAID6のほうがいいよねという話でもある
> cat /dev/ad0 > /dev/null
それだとRAID5のパリティやRAID1のどちらか片方など、確率的に読まれないディスク/セクタができちゃうと思います。まあ確率の問題だし、やらないよりやった方がいいけど。
例えばLinuxのSoftware RAIDなら以下のコマンドでパリティ再計算をやってくれます。> echo "check" > /sys/block/$TARGET_MD/md/sync_action
お高いRAIDコントローラを使っているなら、スケジュール化したチェック機能を持っているものがあるので、そういうのを使いましょう。
# データの人って妙にRAID5とかRAID-1+0が好きでRAID-6が普及しなうわなにをす(ry
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
スペアディスクなし (スコア:1)
スペアディスクなしというのが驚きです。「ディスクアレイが12ベイなので、
スペアディスクを設けると2グループ格納できない」というオチかもしれませんが。
Re: (スコア:0)
RAID5ならパティディスクは分散だろ
で、バックアップサーバの障害詳細が書いてない事から、リカバリ方法を確認しておらず、リカバリを失敗して全部壊したのでは……
放置プレイとか復旧できずとか、「技術的知見・運営ノウハウの蓄積は達成」っていうのは、笑うところだよね！
Re: (スコア:2, 興味深い)
えー、パリティとスペアは別物です。
5D データディスク５台(分)
1P パリティディスク１台(分)
の６台１セットのRAID5となっていたようですが、障害発生時にまずもう一台の破損による復旧不可能に対応するため、(ホット)スペアとして１台以上ないというサービスは変だろというのが親コメの意味ではないかなと。
# とはいえ、運用ルールとの兼ね合いで、いきなり復旧させないとか、ホットじゃないスペアだったりとかはアリだし、そもそもRAID6じゃないのかとか、いろいろ異論はありそうですが。
個人的には
* RAIDと
M-FalconSky (暑いか寒い)
Re: (スコア:2, 興味深い)
RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。
そういうものなんでしょう?(と詳しい人に聞いた)
Re: (スコア:1)
RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。
非RAID 5なディスクで表面検査をしないと発見できないようなエラーは、当然RAID5でも表面検査しないと発見できないでしょう。RAID 5の要件に「表面検査をすること」が含まれていないのだから当然ですね。
ただ、それまで問題なく読み書きできていたRAID 5ディスクアレイであれば、そういった「発見されないエラー」が発見されたとしても、データ保全は可能じゃないでしょうかね。だって、その部分はそれまで読み書きしてなかったんでしょうから。
もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。
まあ、そういうエラーをレポートしないRAIDコントローラってのもあるのかも知れませんが…
Re: (スコア:1)
定期的な全セクタのスキャンを行っていない限り、各ディスク上に「たまたまずーーーっとアクセスが行っていなかったブロック」はどうしても存在しちゃいます。
で、そこのデータが読み出せない状態になっていると、ディスクが1台failしたあとに再構成をかけて初めて気付き、アレイ全体がfailしてしまう、ということで。
> もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。
ディスク上には長期間読み書きされないブロックがどうしてもできてしまう、というのが親コメの「詳しい人」が言ってることかと思います。
全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
Re:スペアディスクなし (スコア:0)
>全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
逃げ方。
システム負荷の低い時間帯に cron で
cat /dev/ad0 > /dev/null
する。
#まあRAID5ってこわいよねRAID6のほうがいいよねという話でもある
Re:スペアディスクなし (スコア:1)
> cat /dev/ad0 > /dev/null
それだとRAID5のパリティやRAID1のどちらか片方など、確率的に読まれないディスク/セクタができちゃうと思います。まあ確率の問題だし、やらないよりやった方がいいけど。
例えばLinuxのSoftware RAIDなら以下のコマンドでパリティ再計算をやってくれます。
> echo "check" > /sys/block/$TARGET_MD/md/sync_action
お高いRAIDコントローラを使っているなら、スケジュール化したチェック機能を持っているものがあるので、そういうのを使いましょう。
# データの人って妙にRAID5とかRAID-1+0が好きでRAID-6が普及しなうわなにをす(ry