アカウント名:
パスワード:
今まで２回泣きました。一回は、８台で組んだRAIDのHDD１台がクラッシュして、再構築中にもう一台が昇天。もう一回は、定期停電の後の復帰作業中のオペレーターの操作ミスでマウントに失敗後、読めなくなった。 物理的・地理的に離れたところにバックアップをするのが一番。そのためには、RAID5を組んで大容量ボリュームをつくると、かえって不便、と思うようになりました。
それにしてもこの開き直り方には、あきれを通り越して、ネット貧民の有象無象は相手にしないという覚悟に清々しさを感じる。
ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
RAIDに限らず、壊れちゃったデータはまず「まるっとコピーを取って」そのコピー相手にいろいろやるのが鉄則ですな。
RAIDは信頼性がそこそこのディスクを束ねて使うときの気休めなので、理解しないとハマりがち1. 複数台のHDDを使うんだから、システム全体としての故障発生率はあがる2. どのRAIDを使っても、復旧時は基本的にシステムダウンする3. オペレーションミスには対応できない4. RAID1以外は基本的に実装依存
# 何を求めてるか忘れて設計すると悲惨なことになるのはいつものことですが:p
一般的にどうやるのかは分からないけど、ホットスペアでリビルドまでは自動化して、そこで問題があればやっと人間のお出ましなんじゃないの。消耗品故障くらいで、いちいちシステム止めるなんて許されんのかな？社内blogならサービスレベルとしては問題ない様な気もするけど。適正にバックアップ取ってれば、ディスクコピー＋リビルドの時間と比較して、どっちがダウンタイムが短いのか明らかじゃない？？
それにしてもストレージも守れないなんて、システム屋としてはクリティカルだよね。その点では、Doblogは知見と交換に失う物は大きかった。
一般化できないのでアレですが、RAIDは「止めてはならないシステム」では「ちょっと良いケーブル」程度の扱いだと思います。大抵は、ロードバランサ組んでおいて、どこぞが壊れたら「死んだサーバ」扱いして人間がでてって修復します。（その中でホットスペアでリビルドまで自動化とか、人間がやるのはHDD入れ替えるだけって話になると思います）どの程度止めてよいサービスかにもよりますけど、単一故障点をできるだけ作らないようにシステムを構築するのが原則です。（もちろんコストとの兼ね合いになるので、重要視するところを守るように作るわけです）
システム止めるのが許されない or ダウンタイムを短くするのがキモの場合には、RAID5を選択すること自体が間違っています。RAID5は「容量を多く使いたい」時に使うものであって、「ディスクを保護する」時に使うものではありませんしね。
バックアップやダウンタイムの最小化も、「何を守りたいのか」によって異なります。例えば・前日までのデータに戻ってしまっても、半日で復旧できることを目指す・システムは１日止まるが、１時間前までのデータに戻る・システムは止めずに、応答速度が落ちる・止まらない
どういう保護を求めるかによって異なりますが、そこそこの看板しょってる場合は「データは最悪でも前々日、復旧まで３日」ってとこでしょう。別紙１をみる限りでは、ちょっと詳しい人が内々で進めたプロジェクトって感じなので社内blogなみの扱いじゃないかな。痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
RAID5 は鬼門 (スコア:5, 興味深い)
今まで２回泣きました。一回は、８台で組んだRAIDのHDD１台がクラッシュして、再構築中にもう一台が昇天。もう一回は、定期停電の後の復帰作業中のオペレーターの操作ミスでマウントに失敗後、読めなくなった。
物理的・地理的に離れたところにバックアップをするのが一番。そのためには、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は「容量を多く使いたい」時に使うものであって、「ディスクを保護する」時に使うものではありませんしね。
バックアップやダウンタイムの最小化も、「何を守りたいのか」によって異なります。例えば
・前日までのデータに戻ってしまっても、半日で復旧できることを目指す
・システムは１日止まるが、１時間前までのデータに戻る
・システムは止めずに、応答速度が落ちる
・止まらない
どういう保護を求めるかによって異なりますが、そこそこの看板しょってる場合は「データは最悪でも前々日、復旧まで３日」ってとこでしょう。
別紙１をみる限りでは、ちょっと詳しい人が内々で進めたプロジェクトって感じなので社内blogなみの扱いじゃないかな。
痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。