アカウント名:
パスワード:
RAID5ならパティディスクは分散だろ
で、バックアップサーバの障害詳細が書いてない事から、リカバリ方法を確認しておらず、リカバリを失敗して全部壊したのでは…… 放置プレイとか復旧できずとか、「技術的知見・運営ノウハウの蓄積は達成」っていうのは、笑うところだよね！
えー、パリティとスペアは別物です。
5D データディスク５台(分)1P パリティディスク１台(分)の６台１セットのRAID5となっていたようですが、障害発生時にまずもう一台の破損による復旧不可能に対応するため、(ホット)スペアとして１台以上ないというサービスは変だろというのが親コメの意味ではないかなと。
# とはいえ、運用ルールとの兼ね合いで、いきなり復旧させないとか、ホットじゃないスペアだったりとかはアリだし、そもそもRAID6じゃないのかとか、いろいろ異論はありそうですが。
個人的には * RAIDと
RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。
この「発見されないエラー」というのは、メディアエラーのことでしょうか。 今回の件に関しては、縮退状態で稼働させていたRAID5ボリュームでHDD交換前に2点同時故障(切り離し)が発生し閉塞してしまったのか、それとも、HDDを交換し再同期中にメディアエラーを検出して「何か」がおきてしまったのか(閉塞やデータ不整合・破壊など、これはコントローラ次第)、そこまで具体的には発表されていないので、「何とも言えない」かと考えます。 一般論としてはメディアエラーの扱いによる問題というのは考えられると思います。 特に、ショボいRAIDコントローラ/ソフトウェアだと、何がおきても不思議ではないかと、、、
非RAID 5なディスクで表面検査をしないと発見できないようなエラーは、当然RAID5でも表面検査しないと発見できないでしょう。RAID 5の要件に「表面検査をすること」が含まれていないのだから当然ですね。ただ、それまで問題なく読み書きできていたRAID 5ディスクアレイであれば、そういった「発見されないエラー」が発見されたとしても、データ保全は可能じゃないでしょうかね。だって、その部分はそれまで読み書きしてなかったんでしょうから。もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。まあ、そういうエラーをレポートしないRAIDコントローラってのもあるのかも知れませんが…
定期的な全セクタのスキャンを行っていない限り、各ディスク上に「たまたまずーーーっとアクセスが行っていなかったブロック」はどうしても存在しちゃいます。で、そこのデータが読み出せない状態になっていると、ディスクが1台failしたあとに再構成をかけて初めて気付き、アレイ全体がfailしてしまう、ということで。
> もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。
ディスク上には長期間読み書きされないブロックがどうしてもできてしまう、というのが親コメの「詳しい人」が言ってることかと思います。全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
>全セクタのスキャン機能を持っているようなRAIDコントローラは意外に少ないんですよねえ。
逃げ方。システム負荷の低い時間帯に cron でcat /dev/ad0 > /dev/nullする。
#まあRAID5ってこわいよねRAID6のほうがいいよねという話でもある
background media scanぐらいはHDD単体で勝手にやってくれるものかと思ってましたが。まさかやってくれないの？
勝手にやるなよ。
# せめて設定させてくれ
> 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
ただ、それまで問題なく読み書きできていたRAID 5ディスクアレイであれば、そういった「発見されないエラー」が発見されたとしても、データ保全は可能じゃないでしょうかね。だって、その部分はそれまで読み書きしてなかったんでしょうから。 もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。
それまで当該セクタに読み書きできていても、突然読めなくなる(書き込みは成功する)のが、メディアエラーの怖さです。 リビルド中にメディアエラーを検出したセクタに、上位レイヤ(たとえばFS)から見て「有効」なデータが載っていないとは限りません。 RAID5ボリュームが縮退状態で運転していて、復帰動作(リビルド)中にメディアエラーを検出したときには、当該セクタのデータは復元できません。 予防保全はこれを防ぐための機能で、縮退状態で気づく(当該セクタを復元できなくなる)前にメディアエラーを潰しておくというものです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
スペアディスクなし (スコア:1)
スペアディスクなしというのが驚きです。「ディスクアレイが12ベイなので、
スペアディスクを設けると2グループ格納できない」というオチかもしれませんが。
Re: (スコア:0)
RAID5ならパティディスクは分散だろ
で、バックアップサーバの障害詳細が書いてない事から、リカバリ方法を確認しておらず、リカバリを失敗して全部壊したのでは……
放置プレイとか復旧できずとか、「技術的知見・運営ノウハウの蓄積は達成」っていうのは、笑うところだよね！
Re: (スコア:2, 興味深い)
えー、パリティとスペアは別物です。
5D データディスク５台(分)
1P パリティディスク１台(分)
の６台１セットのRAID5となっていたようですが、障害発生時にまずもう一台の破損による復旧不可能に対応するため、(ホット)スペアとして１台以上ないというサービスは変だろというのが親コメの意味ではないかなと。
# とはいえ、運用ルールとの兼ね合いで、いきなり復旧させないとか、ホットじゃないスペアだったりとかはアリだし、そもそもRAID6じゃないのかとか、いろいろ異論はありそうですが。
個人的には
* RAIDと
M-FalconSky (暑いか寒い)
Re:スペアディスクなし (スコア:2, 興味深い)
RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。
そういうものなんでしょう?(と詳しい人に聞いた)
Re:スペアディスクなし (スコア:1)
この「発見されないエラー」というのは、メディアエラーのことでしょうか。
今回の件に関しては、縮退状態で稼働させていたRAID5ボリュームでHDD交換前に2点同時故障(切り離し)が発生し閉塞してしまったのか、それとも、HDDを交換し再同期中にメディアエラーを検出して「何か」がおきてしまったのか(閉塞やデータ不整合・破壊など、これはコントローラ次第)、そこまで具体的には発表されていないので、「何とも言えない」かと考えます。
一般論としてはメディアエラーの扱いによる問題というのは考えられると思います。
特に、ショボいRAIDコントローラ/ソフトウェアだと、何がおきても不思議ではないかと、、、
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: (スコア:0)
background media scanぐらいはHDD単体で勝手にやってくれるものかと思ってましたが。
まさかやってくれないの？
Re: (スコア:0)
background media scanぐらいはHDD単体で勝手にやってくれるものかと思ってましたが。
まさかやってくれないの？
勝手にやるなよ。
# せめて設定させてくれ
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
Re:スペアディスクなし (スコア:1)
それまで当該セクタに読み書きできていても、突然読めなくなる(書き込みは成功する)のが、メディアエラーの怖さです。
リビルド中にメディアエラーを検出したセクタに、上位レイヤ(たとえばFS)から見て「有効」なデータが載っていないとは限りません。
RAID5ボリュームが縮退状態で運転していて、復帰動作(リビルド)中にメディアエラーを検出したときには、当該セクタのデータは復元できません。
予防保全はこれを防ぐための機能で、縮退状態で気づく(当該セクタを復元できなくなる)前にメディアエラーを潰しておくというものです。