本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はBasic elements of the flash virtualization platform – Part 1で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
最近 PernixData のオフィスを訪問した際、Satyam Vaghani 氏と主要なエンジニアの数人と話をする機会を作ることができました。その中でPernixData FVP が完成するまでの過程で技術的にどの様な設計上の課題にぶつかったかを知ることが出来ました。フラッシュの様に遅延時間が非常に短い（マイクロ秒単位）技術を扱う中で、最も避けるべき事は開発したソフトウェアそのものが遅延時間を延ばしてしまわないようにすることです。アプリケーションを正常に動作させると同時に、効率的、かつ効果的なプラットフォームを構成することにおいて極めて重要なのは、数ある選択肢の中から最適な選択肢を選び続ける事だと言えるでしょう。以後掲載する記事は FVPを開発する中で、選択肢の中から何を選び、なぜ選んだのかを詳しく述べていこうと考えています。それでは今回は、なぜ仮想アプライアンスではなく、カーネルモジュールを選択したかに触れたいと思います。
カーネルモジュール vs 仮想アプライアンス
最初に解決しなければならない課題の一つが入出力のパスです。フラッシュの性能特性を活かすため、いかに入出力のパスを短くする事ができるかが鍵となります。ローカルフラッシュリソースを利用する仮想アプライアンスを用いる事が一般的な解決法ですが、仮想マシンの入出力のパスを分析すればこの解決法がパスを短く保つ事を考慮していないのは一目瞭然です。次の図は入出力のパスが多くの段階を踏んで成り立っている事を表しています。段階を増す度にデータパスは長くなり、様々なポイントで遅延を発生させるきっかけとなってしまいます。
仮想アプライアンスのリソース管理に纏わる問題点
入出力のパスが長くなってしまうという事を差し置いたとしても、仮想アプライアンスのリソース管理は困難です。原則として仮想アプライアンスは ESX スケジューラに制御されています。カーネルからしてみれば仮想アプライアンスは他の仮想マシンと変わらず、区別する事ができません。つまり、仮想アプライアンスは他の仮想マシンと同様に CPU キューで処理されるのを待つしかないのです。
ですが仮想アプライアンスでの処理がスケジュールされる頻度が十分ではない可能性も考える必要があります。この場合の入出力は仮想アプライアンス（図の第3ステージ）、またはVMカーネル（第2ステージ）で処理される前にカーネルストレージの待ち行列に移動され、処理されるのを待機しなければなりません。入出力パスの仕上げの段階でも似た様な問題が生じます。フラッシュから出た入出力パスは仮想アプライアンス（第5ステージ）で最終段階を迎えますが、それが完全に処理されるまで幾つか段階があります。まず、仮想アプライアンスが最終処理を行うための処理のスケジュールが待ち行列内に組まれていなければいけません。次に、最終段階だという通知（第6ステージ）が、VMカーネルを通し、仮想マシン（第7ステージ）に通知される必要があります。そして最後に、仮想マシンがその完成された入出力パスを受け取るスケジュール（第8ステージ）が組まれてなければいけません。負荷の高くないシステムの場合、この問題はなかなか顕在化しないかもしれませんが、仮想マシンが増え、拡大を続けているシステムの場合は、仮想マシンが増える度に入出力処理速度は急激に減速します。
CPU の予約を適用すればいいじゃないか！と言う声もあるでしょう。ですが仮想マシン一つ一つに予約を適用する事は、クラスタ全体の HA-フェイルオーバーポリシー構成にまで影響を及ぼす事になります。その上、CPU 予約を適用するからといって必ずしも仮想アプライアンスが CPU にすぐにアクセスできるという訳ではありません。もし違う仮想マシンの処理がスケジュールされている場合、その仮想マシンの処理が優先され、仮想アプライアンス内での入出力処理に遅れが生じます。
もう一つの問題点は仮想アプライアンスの処理がトラフィックと比例してスケジュールされない事です。トラフィックに対応するには仮想インフラの増大に合わせた仮想アプライアンスのリソースの規模を正確に判断する必要があります。リソースを割り当て過ぎた仮想マシンも上手く性能を発揮しませんが、リソースの割り当てが不足した仮想マシンでは目も当てられません。CPUだけ の問題ではありません。仮想アプライアンスの入出力パス処理時に複製されるメモリー量によっても処理時間は増していきます。特にフラッシュは入出力を取り回すためのハードウェアコマンド数が多いために、処理される情報量が多い場合には処理時間が長くなってしまいます。VMware は仮想マシン間のやりとりで発生するオーバーヘッドを下げる術を提供していますが (VMCI:http://www.vmware.com/support/developer/vmci-sdk/)、この技術は ESXi ハイパーバイザー・カーネルと仮想マシンの間では利用できません。
これら全ての要素を踏まえると、仮想アプライアンスでの実装が最も効率的、且つ効果的にフラッシュの短い遅延時間技術を活用するのに最適な選択肢でない事は一目瞭然です。
FVP はカーネルモジュールを使用
結果として、FVPの開発チームは仮想アプライアンスの代わりにカーネルモジュールとしての実装を選択しました。フラッシュ仮想プラットフォーム (FVP) はカーネルモジュールをVMカーネルにインストールする事によって、ハイパーバイザーを拡張できるのです。簡単に説明しますと、仮想マシンからハイパーバイザーに向かう入出力パスを”ハイジャック”する様な仕組みです。入出力がストレージシステム内に入る前に FVP はそれがフラッシュによって処理されるべきか、外部ストレージシステムによって処理されるべきかを判断します。FVP はハイパーバイザーの一部なので、入出力の処理と言う面では最速のスピードです。その上カーネルモジュールであるという事は、メモリーやCPU設定を調整する必要がなく、仮想アプライアンスの電源を誤って落とす心配もありません。
仮想アプライアンスは駄目なのか？
駄目という訳ではありません。ですが、サーバサイドフラッシュやメモリースロット内のフラッシュを扱う場合の問題はデータパスを通る最中で積み重なってゆくオーバーヘッドが処理時間の中で無視できない程増していくことです。メモリー内のデータアクセスはナノ秒単位の処理。フラッシュの遅延時間はマイクロ秒単位。スピンドルや仮想アプライアンスはミリ秒単位の処理です。したがって、もし目的がパフォーマンス層をキャパシティ層から分離させる事なのであれば、二つの層に適した別々のアーキテクチャを使う事が合理的でしょう。最終的に、好ましいアーキテクチャは両方適用する事です。パフォーマンス層には FVP を、キャパシティ層には仮想アプライアンスを適用するという事です。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
