アカウント名:
パスワード:
今まで2回泣きました。一回は、8台で組んだRAIDのHDD1台がクラッシュして、再構築中にもう一台が昇天。もう一回は、定期停電の後の復帰作業中のオペレーターの操作ミスでマウントに失敗後、読めなくなった。 物理的・地理的に離れたところにバックアップをするのが一番。そのためには、RAID5を組んで大容量ボリュームをつくると、かえって不便、と思うようになりました。
それにしてもこの開き直り方には、あきれを通り越して、ネット貧民の有象無象は相手にしないという覚悟に清々しさを感じる。
ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
RAIDに限らず、壊れちゃったデータはまず「まるっとコピーを取って」そのコピー相手にいろいろやるのが鉄則ですな。
RAIDは信頼性がそこそこのディスクを束ねて使うときの気休めなので、理解しないとハマりがち1. 複数台のHDDを使うんだから、システム全体としての故障発生率はあがる2. どのRAIDを使っても、復旧時は基本的にシステムダウンする3. オペレーションミスには対応できない4. RAID1以外は基本的に実装依存
# 何を求めてるか忘れて設計すると悲惨なことになるのはいつものことですが:p
一般的にどうやるのかは分からないけど、ホットスペアでリビルドまでは自動化して、そこで問題があればやっと人間のお出ましなんじゃないの。消耗品故障くらいで、いちいちシステム止めるなんて許されんのかな?社内blogならサービスレベルとしては問題ない様な気もするけど。適正にバックアップ取ってれば、ディスクコピー+リビルドの時間と比較して、どっちがダウンタイムが短いのか明らかじゃない??
それにしてもストレージも守れないなんて、システム屋としてはクリティカルだよね。その点では、Doblogは知見と交換に失う物は大きかった。
一般化できないのでアレですが、RAIDは「止めてはならないシステム」では「ちょっと良いケーブル」程度の扱いだと思います。大抵は、ロードバランサ組んでおいて、どこぞが壊れたら「死んだサーバ」扱いして人間がでてって修復します。(その中でホットスペアでリビルドまで自動化とか、人間がやるのはHDD入れ替えるだけって話になると思います)どの程度止めてよいサービスかにもよりますけど、単一故障点をできるだけ作らないようにシステムを構築するのが原則です。(もちろんコストとの兼ね合いになるので、重要視するところを守るように作るわけです)
システム止めるのが許されない or ダウンタイムを短くするのがキモの場合には、RAID5を選択すること自体が間違っています。RAID5は「容量を多く使いたい」時に使うものであって、「ディスクを保護する」時に使うものではありませんしね。
バックアップやダウンタイムの最小化も、「何を守りたいのか」によって異なります。例えば・前日までのデータに戻ってしまっても、半日で復旧できることを目指す・システムは1日止まるが、1時間前までのデータに戻る・システムは止めずに、応答速度が落ちる・止まらない
どういう保護を求めるかによって異なりますが、そこそこの看板しょってる場合は「データは最悪でも前々日、復旧まで3日」ってとこでしょう。別紙1をみる限りでは、ちょっと詳しい人が内々で進めたプロジェクトって感じなので社内blogなみの扱いじゃないかな。痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。
>サーバでは、システムを止めてから再構築なんてことはありません。>そんなことを許してくれるユーザーさんはいませんね。
うちの家庭内写真サーバは、別に夜中止めても誰も文句言いませんが。
私も金融機関向けシステムとかやってたから、言いたいことはわかりますが、そういう業界の人は、「この水準があたりまえ、他は存在しない」みたいな態度は取らないほうがいいと思います。
ちょっとしたサーバだってサーバだし、追加空調が必要なくらいのどでかいやつもサーバで、その間は連続していて、はっきりした境界があるわけではないのです。そして、ブレイクスルーは、おもちゃみたいな世界から現れたりするのです。Google のサーバなんて、まさにそんな感じのものでしょう。
>ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
つまり「NTTデータに大規模システムの設計・構築・運用なんてさせちゃ駄目」ってことですね、分かります。
この(スコア:1, おもしろおかしい)って、少数の例を過剰に一般化するボケについてるって理解で合ってますよね? ;-)# とっても無粋
>延髄反射コメントはジョークにはなっても、事業判断にはならん。
イノキですね、分かります!
#そこは”脊髄”反射だと思う。
>少数の例を過剰に一般化ここは「氷山の一角」の間違いに一票。
>ってのは、同時期導入のディスク使ってると起こりがちですし。
「同一ロットのドライブは故障するときには同時に故障する」って話はよく聞きますが、それって実際どうなんでしょ?経験則としてもあまり信用できない気がするのですが…(すくなくとも私は経験したことがない)
体験ある方はどれくらいいらっしゃいます?
> 「同一ロットのドライブは故障するときには同時に故障する」> って話はよく聞きますが、それって実際どうなんでしょ?
PC内のドライブが次々とクラッシュ、またはエラーを吐くってのはありますよ。電源がヘタってたりとかの周辺部品の劣化です。ディスクアレイでは経験はないけれど、同時クラッシュの原因のひとつにはマシン側の問題もあるやもしれません。あるいは突発的パルスノイズとか。同一ロットの可能性あるでしょうけど、むしろ同一環境である事の方が可能性が高いような気がします。いくら同一ロットと言っても100,000時間以上の性能をうたってるものが数十時間の差で寿命を迎えるというのは、にわかに信じがたいような。
4台のPCに導入したIBMの40GBのHDDのうち、3台がほぼ同時期に故障したことはあります。購入が9年ぐらい前で、壊れたのが5年ぐらい前のことだったかな。で、残りの1台は今でもノートラブルで元気だったり…
#私は、同一メーカーで構成してるRAIDで故障交換するときに#「間違えて生きてるHDDを抜く」ってポカをやったことがあり、#それ以来「判別のため」RAIDはできるだけ別メーカーのHDDで構成するようにしてます。
私はメーカーの保守員にそれをやられました。マジで殴ってやろうかと思った。幸い完全にクラッシュする前の予防交換だったのでデータは事なきを得ましたが・・・。あいつは馬鹿か、本当に。
#当然AC
>「同一ロットのドライブは故障するときには同時に故障する」
一度あります。この時は直近の前日バックアップまでしか戻せませんでしたね。まあ、インフラ設計をした時点でこのリスクはわかっていて、顧客も納得済みでしたが。
そういうことを織り込んだ上で顧客と契約することが重要なんですけどね。可用性と信頼性を追求するならそれなりのお金が掛かるわけで。
最近、エンタープライズ級のストレージを扱っているところにHDDの同一ロトを載せないなどの対策をしているのか?と聞いたことがあるのですが、特にそういうことはしていないとの返答でした。
まあ、実際は60本くらい載せたストレージが納品されてもHDDが全部同じ会社の製品で構成されていることは少ないですね。現場で判断しているのかも知れません。#とはいえ、RAIDグループ毎に違うくらいなんですけど。
>まあ、実際は60本くらい載せたストレージが納品されてもHDDが>全部同じ会社の製品で構成されていることは少ないですね。
「調達の都合」だそうです。同じときもあるしバラのときもある。
エンタープライズクラスでも、玉レベルでの機種は管理してなくて精精キャッシュ・容量・回転数程度の分類だそうで。
さすがに日立SUNRISEはHGSTだけで組んでるとは思いますが。
>この時は直近の前日バックアップまでしか戻せませんでしたね。>まあ、インフラ設計をした時点でこのリスクはわかっていて、>顧客も納得済みでしたが。
Doblogはこの例には当てはまらないかな。なにしろ数ヶ月分まとめて吹っ飛んでますから。
まあ「NTTデータはそういう会社なんだ」と言われればそれまでですが。w
同一ロットだったせいだとは思いませんが、以前いた大学のシステムはRAID6(でしたっけ?パリティ2個分記録するやつ)で組んでいたにも関わらず、1台すっ飛んだ時のリビルド中にもう一台が飛んで、さらに換えのディスクを持ってくるまでの間にもう一台すっ飛んで結局死亡した素敵な奴でした。さすがに3台飛ぶのは予想外だったらしく、各パーツの検証やらバックアップからの書き戻しで大変そうでした。#結局、どこかのパーツが悪いとかではなく、単純にものすごく運が悪かったんだろうと。
ただ、物理的/ファームウェア的なロット不良を避けるために違うロットを組み合わせるってのはありなのかなあとは思います。
そんなにいっぺんに壊れるってことは、外的環境の変化とかはなかったでしょうか?例えばすぐ近くで塗装工事を行っていたりとか、エアコンが壊れたとか。
>「同一ロットのドライブは故障するときには同時に故障する」
実際、数の上での話になれば「10年後でも故障してないHDD」の方が圧倒的に多いわけで、普通に考えたらあまりそういうことはないんですけどね。故障する=運が悪いということなので、悪い運がそうそう訪れても困ります。
ただ、何らかの不良ロット(もしくは設計不良)が疑われるケースではそういうことがあります。メーカー名を挙げるのもどうかと思うのですが、Maxtorの80GB~120GB世代がまさにそうでした。電源入れっぱなしで長らく正常に動いているように見
>8台で組んだRAID
そこはデータの重要度にもよるけど、4台のRAID5+1あるいはRAID6という構成にすべきだったのでは。RAID5は性質上、二台同時に故障したら駄目なのはHDDの数が増えても同じなので、そう考えると3台以上はHDDの台数が増えるたびに故障率が上がってしまいます。
ある程度台数のまとまったRAIDの場合は、RAID10(1+0って書くのかな?)にしています。
これだと運が良ければ、半分壊れても動きます。
リビルドに関しては、上記方々の言うとおりバックアップ+書込み禁止にしてからが理想ですが、実運用はそうも行かなかったり。
> これだと運が良ければ、半分壊れても動きます。
分かってると思うけど、運が悪いと2台故障で全滅ですな
ご参考までに。
【ATA RAID5の落し穴】http://knowledge.ontrack-japan.com/ontrack_now/20060515_mamechisiki.html [ontrack-japan.com]
>① 現在正常に動作しているからといって、他のHDDに障害がないという保証はない。
>② RAID再構築に当たっては、他のHDDの全てのセクタ・アクセスが行われるため、> 後発リードエラーが表に出る確率が上がる。
>《ATA RAIDと、SCSI RAIDの信頼度差》
こういったデメリットとメリット(主にコスト)を把握した上で、用途に合わせて使い分ける事が重要かと。
最近2-4台構成が多くて考える余地もないですが(T▽T
今時だとこんな感じですかね?RAID6(4台) OS領域 兼 backup (2台まで)RAID10(4台) データ領域 (1台運がよければ2台)
アクセス頻度や致命的な障害時の復旧まで考えるとこっちのが好きかなRAID1(2台) OS領域(ログ含む)(1台まで)RAID10(4台) データ領域 (1台運がよければ2台)RAID1(2台) backup領域 (1台まで)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
RAID5 は鬼門 (スコア:5, 興味深い)
今まで2回泣きました。一回は、8台で組んだRAIDのHDD1台がクラッシュして、再構築中にもう一台が昇天。もう一回は、定期停電の後の復帰作業中のオペレーターの操作ミスでマウントに失敗後、読めなくなった。
物理的・地理的に離れたところにバックアップをするのが一番。そのためには、RAID5を組んで大容量ボリュームをつくると、かえって不便、と思うようになりました。
それにしてもこの開き直り方には、あきれを通り越して、ネット貧民の有象無象は相手にしないという覚悟に清々しさを感じる。
別に鬼門じゃねーよ (スコア:2, すばらしい洞察)
ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
Re:別に鬼門じゃねーよ (スコア:3, 興味深い)
「まず、バックアップして」
それから、故障ディスクを入れ換えて rebuild 。
いきなり rebuild なんてありえないです。90年代後半の「ディスク逝かれまくり」を体験した世代では身にしみているとは思うけどね。
Re:別に鬼門じゃねーよ (スコア:5, 興味深い)
RAIDに限らず、壊れちゃったデータはまず「まるっとコピーを取って」そのコピー相手にいろいろやるのが鉄則ですな。
RAIDは信頼性がそこそこのディスクを束ねて使うときの気休めなので、理解しないとハマりがち
1. 複数台のHDDを使うんだから、システム全体としての故障発生率はあがる
2. どのRAIDを使っても、復旧時は基本的にシステムダウンする
3. オペレーションミスには対応できない
4. RAID1以外は基本的に実装依存
# 何を求めてるか忘れて設計すると悲惨なことになるのはいつものことですが:p
Re: (スコア:0)
一般的にどうやるのかは分からないけど、ホットスペアでリビルドまでは自動化して、そこで問題があればやっと人間のお出ましなんじゃないの。
消耗品故障くらいで、いちいちシステム止めるなんて許されんのかな?
社内blogならサービスレベルとしては問題ない様な気もするけど。
適正にバックアップ取ってれば、ディスクコピー+リビルドの時間と比較して、どっちがダウンタイムが短いのか明らかじゃない??
それにしてもストレージも守れないなんて、システム屋としてはクリティカルだよね。
その点では、Doblogは知見と交換に失う物は大きかった。
Re:別に鬼門じゃねーよ (スコア:1)
一般化できないのでアレですが、RAIDは「止めてはならないシステム」では「ちょっと良いケーブル」程度の扱いだと思います。
大抵は、ロードバランサ組んでおいて、どこぞが壊れたら「死んだサーバ」扱いして人間がでてって修復します。
(その中でホットスペアでリビルドまで自動化とか、人間がやるのはHDD入れ替えるだけって話になると思います)
どの程度止めてよいサービスかにもよりますけど、単一故障点をできるだけ作らないようにシステムを構築するのが原則です。
(もちろんコストとの兼ね合いになるので、重要視するところを守るように作るわけです)
システム止めるのが許されない or ダウンタイムを短くするのがキモの場合には、RAID5を選択すること自体が間違っています。
RAID5は「容量を多く使いたい」時に使うものであって、「ディスクを保護する」時に使うものではありませんしね。
バックアップやダウンタイムの最小化も、「何を守りたいのか」によって異なります。例えば
・前日までのデータに戻ってしまっても、半日で復旧できることを目指す
・システムは1日止まるが、1時間前までのデータに戻る
・システムは止めずに、応答速度が落ちる
・止まらない
どういう保護を求めるかによって異なりますが、そこそこの看板しょってる場合は「データは最悪でも前々日、復旧まで3日」ってとこでしょう。
別紙1をみる限りでは、ちょっと詳しい人が内々で進めたプロジェクトって感じなので社内blogなみの扱いじゃないかな。
痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。
Re:別に鬼門じゃねーよ (スコア:1, 興味深い)
そんなことを許してくれるユーザーさんはいませんね。
そもそもスペアディスクが設定されていれば、自動的に再構築されてしまいます。
また、アクセスしていない時はディスクのバッドブロックチェックを随時行っています。
これによりRAID再構築中のディスク障害率を下げるようにしています。
メーカーの中の人
Re:別に鬼門じゃねーよ (スコア:1)
>サーバでは、システムを止めてから再構築なんてことはありません。
>そんなことを許してくれるユーザーさんはいませんね。
うちの家庭内写真サーバは、別に夜中止めても誰も文句言いませんが。
私も金融機関向けシステムとかやってたから、言いたいことはわかりますが、
そういう業界の人は、「この水準があたりまえ、他は存在しない」みたいな
態度は取らないほうがいいと思います。
ちょっとしたサーバだってサーバだし、追加空調が必要なくらいのどでかいやつも
サーバで、その間は連続していて、はっきりした境界があるわけではないのです。
そして、ブレイクスルーは、おもちゃみたいな世界から現れたりするのです。
Google のサーバなんて、まさにそんな感じのものでしょう。
Re: (スコア:0)
ブレイクしてスルーはしてみたものの
Re: (スコア:0)
>いきなり rebuild なんてありえないです。
どこが? そもそもサポートに聞いてくる時点で技術力が無いという前提ですから
その対応は現実的で、不思議でも何でもないと思いますが。
#書かれている内容だけで判断するとそう思う。
Re:別に鬼門じゃねーよ (スコア:2, 興味深い)
など状況によって担える役割が異なります。
単に本で読んだ知識だけでは対応しきれないところもあり、経験がものを言う部分も
多いと思います。これは一例ですが、ここ最近の人手(人材)不足でそういったことを
知らずにアサインされている若手技術者も多い。
鬼門かどうかはおいておいても難しいと思います。
これは愚痴ですが、(暇な人は読んでください。)
リストア手順が紛失しているところとか、RAID5でバックアップOKと
勘違いしているところや、リストアテストしていないようなところなど、
バックアップ構築に不備のあるシステムを良く見かけました。
システム構築作業中の中だるみ間で作業がいい加減になるのではとか、
金のかかる作業なのに客は事が起きてから出ないとその危険性に疎く予算が出ないことも
多いのではと考えています。
データの持ち方が多様化しているし、パッケージも種類が多すぎて選定が難しい。
バックアップ構築はしんどいな~
鬼門はデータの方だよ (スコア:1, おもしろおかしい)
>ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
つまり
「NTTデータに大規模システムの設計・構築・運用なんてさせちゃ駄目」
ってことですね、分かります。
Re:鬼門はデータの方だよ (スコア:1)
この(スコア:1, おもしろおかしい)って、少数の例を過剰に一般化するボケについてるって理解で合ってますよね? ;-)
# とっても無粋
Re:鬼門はデータの方だよ (スコア:1)
Livedoor の Blog もそうだけど、
早すぎる一般化の詭弁、ってすごく使いがちなブービートラップだと思いますよ。
自己の反省も踏まえてだけど、NTT データの事業は、Blog に関しては、これ一例しか見てないし、私の結論は「わからん」に過ぎない。
ただ、微妙に身内のコメントがあったので、どうなんだろうかなあ?と分析モードが少しはいったけどね。:-)
# いわゆる、延髄反射コメントはジョークにはなっても、事業判断にはならん。
# 無知の知 (主張のみでは、対象を決定できない。) ATLANTiS.
(余計なもの:-100)Re:鬼門はデータの方だよ (スコア:1)
>延髄反射コメントはジョークにはなっても、事業判断にはならん。
イノキですね、分かります!
#そこは”脊髄”反射だと思う。
Re:(余計なもの:-100)Re:鬼門はデータの方だよ (スコア:1)
みごとに、自分がジョーク化してるし。
自分で二段落ちしてどうする。落語家か :^)
はい、脊髄の間違いです。(^^;;;;;;;;;;;;;;;
# 延髄で反射したら、どうなるんだろう...。
# 無知の知 (主張のみでは、対象を決定できない。) ATLANTiS.
Re: (スコア:0)
>少数の例を過剰に一般化
ここは「氷山の一角」の間違いに一票。
Re: (スコア:0)
やはりダブルパリティは欲しいところですね。
ホットスペアがあっても、
1玉コケる→スペアリング発生→アクセスで負荷が増大→もう1玉コケる
ってのは、同時期導入のディスク使ってると起こりがちですし。
NTTデータの言い訳は見苦しいですが、不安定な状態でもめ続けるよりも
すっぱり手を引くのは利用者にとってもいいのかも知れない。
ちゃんとケアをすれば、ですが。
今後NTTデータがブログサービスに再参入することがあるなら、その利用約款は
見てみたい気がする。
Re: (スコア:0)
>ってのは、同時期導入のディスク使ってると起こりがちですし。
「同一ロットのドライブは故障するときには同時に故障する」
って話はよく聞きますが、それって実際どうなんでしょ?
経験則としてもあまり信用できない気がするのですが…
(すくなくとも私は経験したことがない)
体験ある方はどれくらいいらっしゃいます?
Re:RAID5 は鬼門 (スコア:3, 興味深い)
> 「同一ロットのドライブは故障するときには同時に故障する」
> って話はよく聞きますが、それって実際どうなんでしょ?
PC内のドライブが次々とクラッシュ、またはエラーを吐くってのはありますよ。
電源がヘタってたりとかの周辺部品の劣化です。
ディスクアレイでは経験はないけれど、同時クラッシュの原因のひとつにはマシン側の問題も
あるやもしれません。あるいは突発的パルスノイズとか。
同一ロットの可能性あるでしょうけど、むしろ同一環境である事の方が可能性が高いような気がします。
いくら同一ロットと言っても100,000時間以上の性能をうたってるものが数十時間の差で
寿命を迎えるというのは、にわかに信じがたいような。
〜◍
Re:RAID5 は鬼門 (スコア:2, 興味深い)
4台のPCに導入したIBMの40GBのHDDのうち、3台がほぼ同時期に故障したことはあります。
購入が9年ぐらい前で、壊れたのが5年ぐらい前のことだったかな。
で、残りの1台は今でもノートラブルで元気だったり…
#私は、同一メーカーで構成してるRAIDで故障交換するときに
#「間違えて生きてるHDDを抜く」ってポカをやったことがあり、
#それ以来「判別のため」RAIDはできるだけ別メーカーのHDDで構成するようにしてます。
Re: (スコア:0)
私はメーカーの保守員にそれをやられました。
マジで殴ってやろうかと思った。
幸い完全にクラッシュする前の予防交換だったので
データは事なきを得ましたが・・・。
あいつは馬鹿か、本当に。
#当然AC
Re:RAID5 は鬼門 (スコア:2, 興味深い)
>「同一ロットのドライブは故障するときには同時に故障する」
一度あります。
この時は直近の前日バックアップまでしか戻せませんでしたね。
まあ、インフラ設計をした時点でこのリスクはわかっていて、
顧客も納得済みでしたが。
そういうことを織り込んだ上で顧客と契約することが重要なんです
けどね。可用性と信頼性を追求するならそれなりのお金が掛かるわけで。
最近、エンタープライズ級のストレージを扱っているところに
HDDの同一ロトを載せないなどの対策をしているのか?と聞いたことが
あるのですが、特にそういうことはしていないとの返答でした。
まあ、実際は60本くらい載せたストレージが納品されてもHDDが
全部同じ会社の製品で構成されていることは少ないですね。現場で
判断しているのかも知れません。
#とはいえ、RAIDグループ毎に違うくらいなんですけど。
Re:RAID5 は鬼門 (スコア:1)
>まあ、実際は60本くらい載せたストレージが納品されてもHDDが
>全部同じ会社の製品で構成されていることは少ないですね。
「調達の都合」だそうです。同じときもあるしバラのときもある。
エンタープライズクラスでも、玉レベルでの機種は管理してなくて
精精キャッシュ・容量・回転数程度の分類だそうで。
さすがに日立SUNRISEはHGSTだけで組んでるとは思いますが。
Re: (スコア:0)
>この時は直近の前日バックアップまでしか戻せませんでしたね。
>まあ、インフラ設計をした時点でこのリスクはわかっていて、
>顧客も納得済みでしたが。
Doblogはこの例には当てはまらないかな。
なにしろ数ヶ月分まとめて吹っ飛んでますから。
まあ「NTTデータはそういう会社なんだ」と言われればそれまでですが。w
Re:RAID5 は鬼門 (スコア:1, 参考になる)
同一ロットだったせいだとは思いませんが、以前いた大学のシステムはRAID6(でしたっけ?パリティ2個分記録するやつ)で組んでいたにも関わらず、1台すっ飛んだ時のリビルド中にもう一台が飛んで、さらに換えのディスクを持ってくるまでの間にもう一台すっ飛んで結局死亡した素敵な奴でした。さすがに3台飛ぶのは予想外だったらしく、各パーツの検証やらバックアップからの書き戻しで大変そうでした。
#結局、どこかのパーツが悪いとかではなく、単純にものすごく運が悪かったんだろうと。
ただ、物理的/ファームウェア的なロット不良を避けるために違うロットを組み合わせるってのはありなのかなあとは思います。
Re:RAID5 は鬼門 (スコア:2)
そんなにいっぺんに壊れるってことは、外的環境の変化とかはなかったでしょうか?
例えばすぐ近くで塗装工事を行っていたりとか、エアコンが壊れたとか。
Re: (スコア:0)
復旧会社のコラムとかでも書かれているパターンでは、その手の話。
アクセスされないデータの箇所が壊れていても運用中は正常に見える。
なのでリビルドする前のバックアップは必須。
Re:RAID5 は鬼門 (スコア:1, おもしろおかしい)
俺ならせめて場所を移したい。地縛霊とか。
Re: (スコア:0)
ありますよ。
自宅のファイル鯖で250GBのディスク7台でRAID5を組んで、
他1台をスペアとして使ってたのですが、
1台が故障して再構成中にもう1台が故障しちゃってましたね。
RAIDカードによってはそんな状況下でも強制リビルドという手段で、
一部データの復旧ができることもあるみたいですが、
自分の場合2台目の故障後にKernel Panicが発生して自動再起動がかかってしまい、
そういった対応もできなくなりました。
システム領域とデータ領域は別々のRAIDカードにしてたんだけど、
なかなか思ったとおりの結果にはならないですね。
Re: (スコア:0)
>「同一ロットのドライブは故障するときには同時に故障する」
実際、数の上での話になれば「10年後でも故障してないHDD」の方が圧倒的に多いわけで、
普通に考えたらあまりそういうことはないんですけどね。
故障する=運が悪いということなので、悪い運がそうそう訪れても困ります。
ただ、何らかの不良ロット(もしくは設計不良)が疑われるケースではそういうことがあります。
メーカー名を挙げるのもどうかと思うのですが、Maxtorの80GB~120GB世代がまさにそうでした。
電源入れっぱなしで長らく正常に動いているように見
Re: (スコア:0)
稼動6年目くらいで1ヶ月ほどの間に立て続けに3台壊れました。
SunのマルチパックをソフトウェアでRAIDにしていたのですが、
それを機に外付RAID装置に入れ替えました。
Re: (スコア:0)
>8台で組んだRAID
そこはデータの重要度にもよるけど、4台のRAID5+1あるいはRAID6という構成にすべきだったのでは。
RAID5は性質上、二台同時に故障したら駄目なのはHDDの数が増えても同じなので、そう考えると3台以上はHDDの台数が増えるたびに故障率が上がってしまいます。
Re: (スコア:0)
なぜならばコンピュータは人が困るという状況を感知して、自動的に壊れるメカニズムを持っているのである。なぜならば、初期故障は別として、似たような環境におかれている似たようなハードウェア(機械)は、似たような頃に似たような理由が原因で故障する、というのはありがちだからだ。もちろんHDDだけが特別ということはないはずである。Re: (スコア:0)
ある程度台数のまとまったRAIDの場合は、
RAID10(1+0って書くのかな?)にしています。
これだと運が良ければ、半分壊れても動きます。
リビルドに関しては、上記方々の言うとおり
バックアップ+書込み禁止にしてからが理想ですが、
実運用はそうも行かなかったり。
Re: (スコア:0)
> これだと運が良ければ、半分壊れても動きます。
分かってると思うけど、運が悪いと2台故障で全滅ですな
Re: (スコア:0)
京大KUINS (スコア:0)
Active!Mailのとき。
日立か富士通の担当者と延々とデータ復旧法について会議したけど、結局最後は
「復旧不能」の結論でしたっけ。
#いやまあ被害食らったのは殆ど学生なんで、あまり実害無かったという話もあったけど
Re: (スコア:0)
日立がかなり真剣にサルベージしたとも聞きました。
Re: (スコア:0)
ご参考までに。
【ATA RAID5の落し穴】
http://knowledge.ontrack-japan.com/ontrack_now/20060515_mamechisiki.html [ontrack-japan.com]
>① 現在正常に動作しているからといって、他のHDDに障害がないという保証はない。
>② RAID再構築に当たっては、他のHDDの全てのセクタ・アクセスが行われるため、
> 後発リードエラーが表に出る確率が上がる。
>《ATA RAIDと、SCSI RAIDの信頼度差》
こういったデメリットとメリット(主にコスト)を把握した上で、用途に
合わせて使い分ける事が重要かと。
あなたならどうする?(HDD8台でRAID) (スコア:0)
最近2-4台構成が多くて考える余地もないですが(T▽T
今時だとこんな感じですかね?
RAID6(4台) OS領域 兼 backup (2台まで)
RAID10(4台) データ領域 (1台運がよければ2台)
アクセス頻度や致命的な障害時の復旧まで考えるとこっちのが好きかな
RAID1(2台) OS領域(ログ含む)(1台まで)
RAID10(4台) データ領域 (1台運がよければ2台)
RAID1(2台) backup領域 (1台まで)