Storage GRIDセミナー終了。有難うございました！
今日は遅い時間にも関わらずかなり多くの方々にお越しいただけ、感謝、感謝です、有難うございました！
今日の資料、というか投影していたスライドをUPしました。残念ながらココが味噌、の性能部分についてはご案内させていただいた通り、公開できないため間引きさせていただきました。ごめんなさい。
Virtualization, Operating System, Storage, Cloud Computing
今日は遅い時間にも関わらずかなり多くの方々にお越しいただけ、感謝、感謝です、有難うございました！
今日の資料、というか投影していたスライドをUPしました。残念ながらココが味噌、の性能部分についてはご案内させていただいた通り、公開できないため間引きさせていただきました。ごめんなさい。
先日は興味深いセミナーありがとうございました。
一点気になったのは、StorageGRIDでの冗長性担保のお話です。
ご提示の方法では、HDD領域（玉レベル）、ネットワーク帯域
（必ず2組に書き出す必要があるため）ともに2重の投資が
必要となってしまいます。
ストレージ側のコントローラ２重化のほうが合理的な
気がします。
＃コントローラ２重化の機器より、（２重化されていない）
一般の機器を２組購入した方が安いというのであれば
話が別ですが。
ストレージを追加したさいのリバランスはメリットと
感じますが、ちょっと冗長性が大きすぎる気がします。
いかがでしょうか？
TT
25 Jan 10 at 4:09 pm
ご来場有難うございました。
ご指摘の点ですが、まずプロジェクトの要件として「ストレージ筺体故障を想定する」かどうかが一つの分岐点だと思います。筺体障害を加味しないのであればASMでの冗長化はやや過剰な実装になると思います。ただ後一点、ブロック破損への対応があります。ASMは何らかの影響でディスク上のブロックが壊れてしまった場合に、正常なミラーデータから壊れたブロックを復旧することができます。これはH/Wのミラーでは実現できず、同様のことが起こった場合はバックアップからのリカバリとなります。ASMでミラーしていればオンラインのまま修復することができます。
また、投資対効果の問題ですが、「容量はあまる傾向にある、ストレージ帯域の大部分はReadが占有している」という前提であればASMミラーは妥当な選択ですが、実効容量が足りない、大量の書き込みが頻発する、というような環境では適さないこともあると思います。一般的には前者のような環境が多いと認識していますが、もちろん環境は様々だと思います。要件によってASMミラーを含め構成を柔軟に変更することは必要だと考えています。
nkjm
25 Jan 10 at 4:52 pm
早速のリプライありがとうございました。
ベアHDD容量がじゃぶじゃぶ＋Read負荷が支配的であれば
ASMが妥当というご意見はなるほどと思いました。
筐体障害は、コントローラ２重化で防げない障害と
理解しましたが、物理的な破損、電源障害にともなう
過大電圧等くらいしか想定がつきません。そのほかに
何かあるでしょうか？
ブロック破損の件は内容がよくわからないので補足
いただければと思います。
TT
25 Jan 10 at 5:14 pm
筺体障害で最も発生する恐れがあるのはRAID障害だと思います。これは厳密には筺体とは切り離して考えるべきですが、もし1筺体のディスク全体をRAIDで構成している場合に、ディスクが複数同時故障すればRAIDは壊れます。また、ディスクは同時障害の可能性が高いパーツです。そこを厚く保護するべきという考えです。いずれにせよ、お客様がそれをリスクとして考慮されるかどうか、がポイントだと思います。
また、ブロック障害については繰り返しになりますが何らかの理由は発生するものです。それはソフトウェアのバグであったり、H/Wのファームウェアのバグであったり、ディスクの劣化であったり、です。
nkjm
25 Jan 10 at 5:21 pm