アカウント名:
パスワード:
今まで２回泣きました。一回は、８台で組んだRAIDのHDD１台がクラッシュして、再構築中にもう一台が昇天。もう一回は、定期停電の後の復帰作業中のオペレーターの操作ミスでマウントに失敗後、読めなくなった。 物理的・地理的に離れたところにバックアップをするのが一番。そのためには、RAID5を組んで大容量ボリュームをつくると、かえって不便、と思うようになりました。
それにしてもこの開き直り方には、あきれを通り越して、ネット貧民の有象無象は相手にしないという覚悟に清々しさを感じる。
ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
RAIDに限らず、壊れちゃったデータはまず「まるっとコピーを取って」そのコピー相手にいろいろやるのが鉄則ですな。
RAIDは信頼性がそこそこのディスクを束ねて使うときの気休めなので、理解しないとハマりがち1. 複数台のHDDを使うんだから、システム全体としての故障発生率はあがる2. どのRAIDを使っても、復旧時は基本的にシステムダウンする3. オペレーションミスには対応できない4. RAID1以外は基本的に実装依存
# 何を求めてるか忘れて設計すると悲惨なことになるのはいつものことですが:p
一般的にどうやるのかは分からないけど、ホットスペアでリビルドまでは自動化して、そこで問題があればやっと人間のお出ましなんじゃないの。消耗品故障くらいで、いちいちシステム止めるなんて許されんのかな？社内blogならサービスレベルとしては問題ない様な気もするけど。適正にバックアップ取ってれば、ディスクコピー＋リビルドの時間と比較して、どっちがダウンタイムが短いのか明らかじゃない？？
それにしてもストレージも守れないなんて、システム屋としてはクリティカルだよね。その点では、Doblogは知見と交換に失う物は大きかった。
一般化できないのでアレですが、RAIDは「止めてはならないシステム」では「ちょっと良いケーブル」程度の扱いだと思います。大抵は、ロードバランサ組んでおいて、どこぞが壊れたら「死んだサーバ」扱いして人間がでてって修復します。（その中でホットスペアでリビルドまで自動化とか、人間がやるのはHDD入れ替えるだけって話になると思います）どの程度止めてよいサービスかにもよりますけど、単一故障点をできるだけ作らないようにシステムを構築するのが原則です。（もちろんコストとの兼ね合いになるので、重要視するところを守るように作るわけです）
システム止めるのが許されない or ダウンタイムを短くするのがキモの場合には、RAID5を選択すること自体が間違っています。RAID5は「容量を多く使いたい」時に使うものであって、「ディスクを保護する」時に使うものではありませんしね。
バックアップやダウンタイムの最小化も、「何を守りたいのか」によって異なります。例えば・前日までのデータに戻ってしまっても、半日で復旧できることを目指す・システムは１日止まるが、１時間前までのデータに戻る・システムは止めずに、応答速度が落ちる・止まらない
どういう保護を求めるかによって異なりますが、そこそこの看板しょってる場合は「データは最悪でも前々日、復旧まで３日」ってとこでしょう。別紙１をみる限りでは、ちょっと詳しい人が内々で進めたプロジェクトって感じなので社内blogなみの扱いじゃないかな。痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。
＞サーバでは、システムを止めてから再構築なんてことはありません。＞そんなことを許してくれるユーザーさんはいませんね。
うちの家庭内写真サーバは、別に夜中止めても誰も文句言いませんが。
私も金融機関向けシステムとかやってたから、言いたいことはわかりますが、そういう業界の人は、「この水準があたりまえ、他は存在しない」みたいな態度は取らないほうがいいと思います。
ちょっとしたサーバだってサーバだし、追加空調が必要なくらいのどでかいやつもサーバで、その間は連続していて、はっきりした境界があるわけではないのです。そして、ブレイクスルーは、おもちゃみたいな世界から現れたりするのです。Google のサーバなんて、まさにそんな感じのものでしょう。
＞ちゃんとした使い方分かってない奴が設計・構築・運用して痛い目にあってるだけ
つまり「NTTデータに大規模システムの設計・構築・運用なんてさせちゃ駄目」ってことですね、分かります。
この(スコア:1, おもしろおかしい)って、少数の例を過剰に一般化するボケについてるって理解で合ってますよね？ ;-)# とっても無粋
＞延髄反射コメントはジョークにはなっても、事業判断にはならん。
イノキですね、分かります！
＃そこは”脊髄”反射だと思う。
＞少数の例を過剰に一般化ここは「氷山の一角」の間違いに一票。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
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なみの扱いじゃないかな。
痛みを伴う教訓は記憶に残るでしょうし、他山の石にしたいところ。
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.
（余計なもの：－１００）Re:鬼門はデータの方だよ (スコア:1)
＞延髄反射コメントはジョークにはなっても、事業判断にはならん。
イノキですね、分かります！
＃そこは”脊髄”反射だと思う。
Re:（余計なもの：－１００）Re:鬼門はデータの方だよ (スコア:1)
みごとに、自分がジョーク化してるし。
自分で二段落ちしてどうする。落語家か :^)
はい、脊髄の間違いです。(^^;;;;;;;;;;;;;;;
# 延髄で反射したら、どうなるんだろう...。
# 無知の知 (主張のみでは、対象を決定できない。) ATLANTiS.
Re: (スコア:0)
＞少数の例を過剰に一般化
ここは「氷山の一角」の間違いに一票。