nkjmkzk.net

サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在の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によってストライピングすることでより厳しい性能要件に対応させる

• 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の寿命などかわいいもの、と思う。

前のエントリで予告したDeduplication, 圧縮, スナップショットの違いについて簡潔にまとめておきます。

Deduplicationと圧縮

例えば10Gbyteの仮想マシンイメージをgzipのようなアルゴリズムで圧縮した場合、10Gbyteのイメージにどれだけ空きスペースが含まれているかによりますが、もし空きスペースがほとんどなければあまり大きな圧縮効果は望めないでしょう。逆にもし10Gbyte中の4Gbyteが空きスペースであったなら、その部分はほとんど圧縮されるので最悪でも6Gbyte程度までは圧縮できるでしょう。ただしこの仮想マシンを10個クローンしたらどうでしょうか。ストレージは6Gbyte x 10 = 60Gbyteの容量を消費してしまいます。実際は同じデータであるにも関わらず、です。このストレージでDeduplication（重複排除）が有効であればどうでしょうか。10Gbyteの仮想マシンイメージを10個作成しても消費する容量は10Gbyteです。先ほどのgzip圧縮と比較するとトータルでこ重複排除の方が容量を節約できています。

ただしここで注意したいのはケースバイケースだということです。前述の仮想マシンイメージのような例は、特にDeduplicationが効果を発揮する環境です。Jeff Bonwick氏も自身のBlogエントリで度々仮想マシンイメージの例を引き合いに出しています。

そしてDeduplicationと圧縮は排他的な関係ではありません。補完し得る関係です。前述のシチューエーションをそれぞれのパターンでまとめてみます。

命題：10Gbyte （空き容量4Gbyte）の仮想マシンイメージを10個クローンする

gzip圧縮のみ

10Gbyteを圧縮して6Gbyteに。6Gbyteを10個クローンして最終的に60Gbyte消費

Deduplicationのみ

10Gbyteを10個クローンするが、10個のクローンはすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に10Gbyte消費

gzip圧縮 + Deduplication

まず10Gbyteを圧縮して6Gbyteに。それを10個クローンするがすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に6Gbyte消費

実際にテストしていませんが、理論的には上記のようになり得ます。要件によっては圧縮とDeduplicationを組み合わせたら最もディスク領域を節約できるケースがあることがわかります。

Deduplicationとスナップショット

Deduplicationとスナップショットは非常に近しい技術だと思います。どちらのコンセプトも「重複するデータの実体は一つしか保持しない」がベースになっています。僕は大きな違いは次の2点だと思っています。

主従関係

スナップショットでは主従関係が存在します。ほとんどのスナップショットの実装ではマスターのイメージがあり、スナップショットとはそのイメージのスレーブとして作成されます。なのでマスターとスレーブは対等な関係ではありません。スレーブは維持するけれどもマスターを削除する、という操作は行うことができません。ZFSのスナップショットでも同様です。

＊ZFSでマスターを削除するにはマスターとスレーブの主従関係を逆転させるという選択肢はあります

これはDeduplicationの仕様とは明らかにことなります。前述の仮想マシンイメージの例で言えば、Deduplicationを使って10個の仮想マシンをクローンしてもそのオリジナルとクローンとの間には主従関係はありません。あるのはディスクに格納されているブロックの実体と、それを参照しているカウンタです。どの仮想マシンを削除するのも自由です。例えば大本の仮想マシンイメージを削除するにしてもそのブロックへの参照カウンタが一つ減るだけでスナップショットのように依存関係には縛られません。

コピー速度

ほとんどの実装においてスナップショットの作成は一瞬です。オリジナルイメージのスキャンが行われることもなければ新たなブロックが確保されてデータがコピーされることもありません。これはそもそもストレージ（あるいはボリュームマネージャ）にコピーではなくスナップショットという命令が明示されているからロジックを分けることができます。これはDeduplicationとは異なります。Decuplicationではコピー（あるいはクローン）する際、ユーザからの特別な命令はありません。通常通りファイルのコピーが命ぜられ、ストレージ側は粛々とファイルの構成要素となっているブロックについて一つ一つハッシュをチェックし、重複判定を行って重複していればデータのコピーは行わず参照カウンタをインクリメントして次のブロックに処理を移します。なのでスナップショットのようにどれだけコピー元のサイズが大きくても一瞬で処理を完了させれるような仕組みではなく、サイズが大きければ大きい程、例えば最終的にデータは複製しないにしろ、コピー処理には時間がかかるのが道理です。

ということでそれぞれの技術には得意不得意があり、ケースバイケースで適切な技術を選ぶ必要があると考えられます。

僕が開発しているovmzfsというツールの現在の仕様は、ZFSのスナップショット／クローンを使用して仮想マシンを高速に作成し、圧縮を使用してテンプレートのサイズ削減を行っています。これは検証環境では作業の高速化とストレージリソースの削減に大きく寄与しますが、今回Deduplicationが出てきたことで実装を少し見直さなければと思っています。現在の仕様では仮想マシンはテンプレートをスナップショット／クローンすることで作成しているため、高速に作成できるものの元のテンプレートと依存関係が発生します。すぐに問題とはなりませんが、より複雑な運用、大規模な環境ではもしかすると問題がでてくる可能性もなきにしもあらずです。まだDeduplicationを含むベストプラクティスを確立するには至っていませんが、最終的には適材適所でZFSのDeduplication、圧縮、スナップショットを採用してユーザからは透過的にストレージを最適に利用するツールにできればと思っています。