2010年12月20日月曜日

サーバ仮想化環境でのお薦めストレージ構成

中嶋氏の「サーバ仮想化環境でのお薦めストレージ構成」を読んだところ
自分の考えていた構成がこれほどまともにまとめられてることに感心した。
ダイジェストしておこう。

しかし、これから如何にさらにコストを削減することも、検討の一環として進むべきではないか。


http://nkjmkzk.net/?p=946


Author


中嶋　一樹

本サイトにおいて示されている見解は私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。

サーバ仮想化環境でのお薦めストレージ構成


サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではこれまでの何倍ものI/O性能が必要という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥ります。これはIT関連予算を大きく圧迫することでしょう。

そこで、これまでのストレージ構成を見直し、以下の要件を敷いて仮想化環境でのお薦めストレージ構成を考案してみました。キメの部分にOracleのストレージ管理機構を適用しています。

  • コスト意識をもつ
  • ユニバーサルに使用可能なこと
  • スケーラビリティ- 要求に応じてキャパシティ（I/O性能、容量）の拡張が可能であること
  • シンプル – OS、ソフトウェア側ではスケールアウトのためのパーティション設計が不要なこと
  • 可用性 – SPOFを排除。ディスク、コントローラ、ストレージ筺体のどれが壊れてもデータ保全とオンラインを維持すること

＊以下ではストレージにI/Aサーバを採用していますが、応用としてローエンドなストレージ専用機という選択肢もあると思っています。

解は、コモディティなH/Wを並べる、そして高性能・高可用性・高管理性を達成するというStorage GRIDの思想に基づいた構成です。


多数のディスクを搭載できるI/Aサーバをストレージに採用


  • ストレージ専用機と比較してI/Aサーバは圧倒的に安価。
  • しかもカスタマイズ可能なので必要に応じて大容量のメモリ、10GbEの搭載もできる。（詳しくは後述）
  • コントローラの冗長化を行うことは難しいが、それはASMの筺体間ミラーで代用できるため不要。（詳しくは後述）
  • OSにはSolarisを採用。ZFS iSCSIを使ってボリュームをエクスポート。これはZFSが多様なRAIDを構成可能なこと、チェックサムによるエンドツーエンドのブロック整合性チェックが可能性でデータの一貫性維持機構が強力なこと、ファイルシステムとボリュームマネージャ、iSCSIがZFSに集約されており管理が用意なことが採用理由。


READはすべてキャッシュで捌くことを前提に大量のDRAMを搭載


  • ディスクアクセスは物理的移動がともなうため絶対的に遅い。数年後には「円盤回したりヘッド動かしたりとか有り得ないっスよね」となるかも。
  • メモリは数十ナノセカンドでアクセス可能。ディスクは数ミリセカンド。比較にならない。
  • I/Aサーバだと構成を自由にカスタマイズできるのでDRAMを大量に搭載することができる。ZFSではDRAMをARCというReadキャッシュにすることができる。これはRead用のキャッシュをストレージ専用機の何倍も搭載できることを意味する。最近の1U, 2Uの一般的なI/Aサーバでは100GBを超えるDRAMを搭載可能。一筺体でも100GBのデータベースをすべてキャッシュすることが可能。
  • サーバではなくストレージ側にReadキャッシュを持たせることにより、複数サーバ構成時のサーバ間でのキャッシュコンテンツ重複を排除することができる。
  • サーバ再起動時にもキャッシュの内容がクリアされない。
  • ただしウォームアップ時間には注意。キャッシュされたことを前提でサイジングを行うことになるが、もしストレージを再起動したときにはキャッシュを温めるために相当な時間がかかることになりその間の性能は劣悪になる。したがってストレージ再起動時にはサービスをオンラインにする前にデータを強制的にキャッシュに載せるようなロジックを組み込むことが望ましい。


SSDでさらなるキャッシュ容量を、より安価に


  • もし、コスト的にそれほどのDRAMを購入することはできないという場合、SSDで代用させることができる。
  • SSDはDRAMの延長線上に存在するようなRead用キャッシュとなり、DRAMから溢れるデータを受け止める役割を果たす。結果、DRAMと比べて安価に大容量のReadキャッシュを構築できる。


ランダムな同期書き込みをキャッシュで受け止めるためにBBWC（Battery-Backed Write Cache）を装備


  • DRAM（ARC）によるキャッシュはRead用。書き込みには利用することができない（させてはならない）。
  • 特にRandom Writeが発生するデータベースではREDOログの同期書き込みに要するコストは大きい。そのような環境ではBBWCの効果は絶大。ディスクへの同期書き込みを防ぎ、しかるべきタイミングでまとめてFlushするため大幅な性能向上が約束される。当然BBWC上のデータは突然のシステムダウン時も保護される。（ただしバッテリーが切れる前に起動すること）
  • BBWCはRAIDコントローラ依存となるためDRAMのように大量に積むことはできないが、Readキャッシュと比較して少量でも効果が大きく、さらに後述のASMによって増設もできる。


この筺体を複数並べて、ASMによってストライピングすることでより厳しい性能要件に対応させる


Storage GRID recommend.001

  • ASMとは「Grid Infrastructure」というOracleが提供するクラスタソフトウェアに付属するストレージ管理モジュール。
  • ASMは並べたストレージをOS、データベースに対して「DISKGROUP」として結果的に一つに見せることが可能。

正確にはストレージでエクスポートしている論理ボリュームはOSにそのまま個別のブロックデバイスとして認識される。しかしOSはそのままそのブロックデバイスを使用するのではなく、汎用ファイルシステムとして利用する場合はASMがそのブロックデバイスから作成するファイルシステム（ACFS）をマウントして使うことになる。このファイルシステムに対して行われるI/Oは複数のブロックデバイスに分散して実行され、ストレージが複数台で構成されている場合にはデータは複数ストレージに分散される。つまり、複数台のストレージのDISK, DRAM, BBWCをフル活用できることになる。一瞬、LVMとの違いが気になるかもしれないが、まずASMはデータの「リバランス」をおこなうところが違う。ディスク／ストレージの追加／削除はオンラインで行える上、データのリバランスが自動的に行われる。また、ASMは完全にクラスターアウェアだ。LVMでも別途クラスターLVMのデーモンを設定することでクラスター化（共有）は可能だが、ASMはクラスター機構をはじめから組み込んでいる。

  • DISKGROUPに対して発行した書き込みは並べた複数のストレージに対して分散して書き込まれる。DISKGROUPに対して発行した読み込みは、並べた複数のストレージから分割して読み込まれる。
  • 結果、並べた複数のストレージは仮想的に一つの大きなストレージ筺体となり、（ストレージあたりのI/O性能、ディスク容量） x ストレージ台数分のキャパシティ提供することができる。これは、ストレージH/Wに依存せずI/O性能と容量を必要に応じてスケールアウト可能であることを意味する。
  • また、連結されるのはディスクだけでなく、DRAM, BBWCも同様。結果、100GBのDRAMを積んだストレージを3台並べれば300GBのキャッシュグリッドが出来上がる。


ASMのストライピングモードを「2重化モード」にすることで筺体障害に対応する


  • ASMはデータを分散させるだけでなく、複製しながら分散させることが可能。いわゆるネットワークRAID、筺体間ミラーの構成。
  • このとき、ストレージAにあるデータはかならずストレージB（またはC）にも存在するようになるため、万一ストレージ筺体がまるごと故障／RAIDが破壊されたとしてもデータは保全される。
  • それだけでなく、ストレージ筺体が故障してもオンラインで処理を継続することが可能。（ただし最低ストレージ3台必要）


圧縮でH/W投資を必要最低限に「圧縮」


  • さらに圧縮機能を活用することで、必要なH/W（ストレージ筺体、DISK、DRAM、BBWC)をまさに必要最低限にできる。
  • 「圧縮はオーバーヘッドがあるのでは？」と思われるかもしれなが、そもそも現在の性能課題はストレージI/Oにあることを思い出して欲しい。つまりストレージI/Oがボトルネックになれば結果としてCPU性能はあまることになる。重要なのはオーバーヘッドがあるかないかではなく、最終的にバランスのとれたシステムを構成すること。バランスがとれたときにシステムの集約密度は最大になる。そのためにはあまっているリソースは積極的に活用すべき。


FAQ. RAIDとASMの双方でデータを二重化するのは実効容量が無駄では？


  • 実効容量がどうしても気になる場合は、H/W RAIDをRAID5, 6, 50等比較的容量を確保できるモードとすればよい。しかし（あくまで一般的にだが）「容量」はそれほどコストの高いリソースではない。コストが高く、実現が難しいのは高いI/O性能。繰り返しになるがCPUと同様、余っているリソースはより重要な課題（ここでは可用性）のために積極的に利用すべき。


FAQ. それほどI/O性能が気になるならDISKでなくすべてSSDにしたらどうか？


  • 今回の構成は「コスト意識を持ったユニバーサルなストレージ基盤。その前提でスケーラビリティと可用性を実現する。」というもの。
  • そのテーマにおいて、すべてをSSDにすることは少なくとも現時点（2010年2月）ではコストと容量の面でオールマイティとは言えない。
  • 逆に「SSDは実績が乏しく、寿命や信頼性に懸念がある」という人もいるが個人的にはそうは思わない。可動部があり故障確率の高いHDDよりSSDの方がよっぽど安心だ。寿命に対する懸念も実際にその仕組を理解しないで懸念だけをうたっていることが少なくない。現時点では寿命があるのは事実だが、SLCでは素子あたり5万回の更新が可能な製品が一般的で、一部では50万回という製品もある。そして寿命については事前に知ることができるので計画的にパーツ交換すればよい。SSDに故障がないわけではないが、より故障確率が高いことが想定されるHDDの「いつ壊れるかわからない不安」に比べればSSDの寿命などかわいいもの、と思う。

with 5 comments

Written by nkjm

February 7th, 2010 at 12:12 pm

Posted in Storage,Virtualization

Tagged with asm, compression, storagegrid

« XXXよりOracle VMが優れているところはどこですか？
OpenSolaris b133をOracle VM上でPVMとして作成する »

5 Responses to 'サーバ仮想化環境でのお薦めストレージ構成'


Subscribe to comments with RSS or TrackBack to 'サーバ仮想化環境でのお薦めストレージ構成'.



2.     

3.     

    少し訂正です(何か違和感があると思ったら).
    s/ZLOG/ZIL(ZFS Intent Log)/です。
    SSDのランダムWRITE性能はHDDみたいにシーケンシャルと比べてガクンと落ちるようなことはありません。またZILは名前のとおりの動きをするとするとシーケンシャルWRITE＋シーケンシャルREADになると予想されます。
    実際にどれくらい性能が出るのかは私はZFSをデスクトップでしか使っていないのでわかりませんが、fsync(2)を頻繁に行うアプリケーションを動かしたときにZILにHDDを持ってくるだけでディスクアクセスがかなり静かになります。

     http://0.gravatar.com/avatar/2c3b0fe171e61c76244da14a93cdb99d?s=32&d=http%3A%2F%2F0.gravatar.com%2Favatar%2Fad516503a11cd5ca435acc9bb6523536%3Fs%3D32&r=G

    koie

    7 Feb 10 at 10:28 pm

4.     

5.     

時刻:

0 件のコメント:

コメントを投稿