本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はBasic elements of FVP – Part 2 – Using own platform versus in-place file systemで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
Satyam Vaghani 氏と Murali Vilayannur 氏との話し合いの中で話題の一つとしてのぼったのは、フラッシュデバイスにデータを保存する為に使うファイルシステムについてです。実を言うと VMFS3 開発したのは Vaghani 氏で、Vilayannur 氏は VMFS5 開発チームのリードエンジニアでした。そういう事もあるので、使用しているファイルシステムは当然 VMFS だろうと予想していたので、 VMFS を使用していないと言われた時には驚きました。ですが、それ以上にファイルシステム自体無いと言われた時には唖然として言葉も出ませんでした。
この記事を読まれる前に考慮していただきたいのは、設計について詳しい事はFVPが一般公開された後にまた記事を掲載しますので、ご了承ください。(※訳註 本記事の原文は2013年7月2日公開です。)
なぜ VMFS を使用しないのか？
一般的にファイルシステムというものには様々な冗長な機能が付いてきます。そのため時にはプラットフォームが正常にフラッシュの入出力処理を行うのを邪魔してしまう事もあります。 VMFS の様なファイルシステムをフラッシュ環境で使うにおいて、大きな問題点は従来の SANのための記憶装置用に最適化されている事です。この事については、Vaghani 氏がVMware時代に ACMへ論文を投稿しています。残念なことに、VMFSはFVP には不適合なのです。
ファイルシステムを使用するとフラッシュデバイスに余計な負担をかけ、寿命を縮める傾向があります。入出力処理機能を低下させ、ガーベージコレクションで負荷をかけるだけでなく、仮想マシン毎の性能の向上やQoS管理等、FVP の根本的な機能にVMFSのオブジェクト自体は適していません。次項ではフラッシュデバイスのデータ管理の課題について更に詳しく述べますが、結論から言いますと、フラッシュデバイスを傷つけたくないのであれば、ファイルシステムを使用しない事です。
ファイルシステムの機能の中にはFVP にとって無駄な処理時間でしかない物もあります。一例として、ディスクロッキングが挙げられます。VMFSには強力な分散型のロック管理機能が搭載されていますが、FVP はローカルディスクをホスト単位で管理し、ホスト間でロック競合が起こる事はありません。つまり、FVPにとっては全く無意味な機能なのです。他に例として、POSIX 互換性や分散処理等、多々あります。
低レベルフラッシュメモリ作業
フラッシュデバイスへの書き込みの原理はなぜスピンドルとはかけ離れているのか。その理由の一つは、フラッシュはデータの上書きができないのです。フラッシュ上のデータは空のページにしか書き込めません。フラッシュを使うにおいて一番の注意点は、書き込みはページ単位で行えますが、消すのはブロック単位であるという事です。ページとブロックとは何か？フラッシュはデータをセルに保存し、そのセルがページ(4KB)単位に纏められ、ページはブロックへと纏められます。128ページを一つのブロックに纏めるのが一般的です。ページを削除しなければいけない場合、そのブロックを消さなければいけません。無論、有効なデータは他の場所に保存しなければいけません。フラッシュ機器の編集・修正回数が限られているのは常識です。
したがって、無作為に入出力を書き込むのは思う以上に大きな影響を及ぼします。問題なのはファイルシステムの大半は80～90年代に開発され、それ以来進歩していないことです。磁気ディスク向きの低レベル作業をフラッシュ上で行う事がどれ程パフォーマンスの低下に繋がっているか、ファイルシステムは理解できません。そもそもなぜパフォーマンスの低下に繋がるのでしょうか？図形を通し、断片化の仕組みとフラッシュを妨げる理由を説明しましょう。
ウェアレべリング
予め解りやすいようにブロック一つを、128ではなく、9ページで表しました。
まずウェアレべリングの過程を見てみましょう。この例は既にアプリケーションがデータを作成し、A ブロックのページA、B、とCに書き込んだ状態で始まります(第一段階)。新しいデータが読み込まれ(第二)、ページD、E、とFに書き込まれます。アプリケーションは最初のデータ(A～C)の更新に取り掛かりますが、フラッシュは元のページに上書きするのではなく、新しいページに書き込み続けます。この新たなデータをA-1、B-1、C-1と表記します。この成るべく均等にブロック内に書き込む行為をウェアレべリングといいます。尚、更新前のデータは無効とマークします。
ガーベージコレクションとライトアンプリフィケーション
この例ではA-ブロックは容量の限界に達しています。では、もしこの状態で新しいデータが現れたらどうなるでしょう？
まず新しいデータは空のセルにコピーされます。ブロック内の有効なデータは読み込まれ、フラッシュリソースにコピーされます。無効とされたデータはそのまま手を付けず、ブロックと共に削除します。この作業をガーベージコレクションといいます。
ガーベージコレクションは良いのですが、フラッシュ機器に面倒なのはライトアンプリフィケーションの方です。新しいデータを3ページ書き込むためにフラッシュ機器は6ページ読み込み、その6ページを違う場所に書き込まなければいけませんでした。削除の処理も忘れてはいけません。ではこの工程でデータを一時的に違う場所に移す時、どこに移されるのでしょう？私の図形では、都合よくB-ブロックを足しました。実際にフラッシュシステムで行う場合は、フラッシュストレージコントローラのための容量を余分に確保しておかなければなりません。
オーバープロビジョン
フラッシュ容量はフラッシュストレージコントローラのための処理のために確保しておく事が可能です。これはフラッシュ機器のメーカー、または、ユーザーによって設定できます。例えば、160GBのFusion IO カードを購入した場合、カードの実際の容量は192GBなのです。160GBはユーザーが使用できる容量で、余分の32GBはガーベージコレクションや、エラー修正、コントローラファームウェアの様な、フラッシュコントローラのために確保されています。一般用のSSDは大抵最低限のスペースしか確保されていません。なので、フラッシュデバイスをフラッシュシステム用にフォーマットする時はこの性質を踏まえ、ユーザーに与えられた容量以外のスペースを確保しておく必要性があります。確保する容量の基準は定められていないので、それは個人の自由です。最悪の場合、新しいデータのためにSSDが断片された状態で常にデータを移し続け、削除を繰り返さなければいけない状態に直面します。
フラッシュデバイスのデータ管理を再考
PernixDataのエンジニア達はFVPのために、フラッシュデバイスの新しいデータ管理の仕方を考案しました。詳しい事は後の記事で説明しますが、今回は考慮された項目の一部を紹介させていただきます。
フラッシュ用に最適化
目的はまず一時的な入出力を最小限のメタデータで保存し、フラッシュデバイスをできるだけ最大限のパフォーマンスで動作させる事です。成るべくランダムな書き込みをシーケンシャルな書き込みに変換する事で、フラッシュの優れたシーケンシャル書き込み時のパフォーマンスを活用できます。
変換する事は、不必要なライトアンプリフィケーションやガーベージコレクションを減らすことにも繋がります。更に、ファイルシステムに付きまとう大きいブロックサイズやディレクトリ構造、ファイル、重い処理、ロック管理等の問題を取り除き、改善しました。
仮想マシン毎の動的な容量設定
VMカーネルとの密な関係により、FVPはブロックを探知し、仮想マシンによって読み込まれた、または、書き込まれたかを判断できます。読み込みと書き込みを別々に追跡する事で、FVPは仮想マシンに割り当てられた容量の読み込み部分と書き込みバッファ部分を動的に拡大・縮小させる事ができます。FVPのフォーマットは仮想マシンのあらゆるフラッシュへのアクセスを足したり、消したりする事ができます。反対に従来のファイルシステムのキャッシュ廃棄ポリシーは最善とはいえず、ファイルシステムはファイルを大きくするために末尾へ追記するか、末尾のブロックを削除する必要があり、ライトアンプリフィケーションを引き起こしてしまうことになります。
さらに、これは従来のファイルシステムでは仮想マシン各々に固定に構成しなくてはならなかったキャッシュ容量がいらなくなった事を意味します。ユーザーの体験が可能な限りシームレスであるべきと考える私達にとってこれは重要な点でした。私達のプロダクトマネージャーのBalaはこう述べています：
“The elegance of the product, in my mind, is that it supports the common operational tasks by NOT requiring the user to do anything new or different”
“プロダクトの素晴らしさは、ユーザーにいつもと違うもしくは新しいタスクをしてもらうことなく、業務の手助けができる事にあると私は思います”
仮想マシン一つ一つのキャッシュサイズを予め設定しなくてよいのは運用上非常に大きいポイントです。フラッシュの利用量を把握、または、事前に検討しないで済む事を意味します。なぜなら全てFVPが管理し、処理を行うからです。リソースをきっちりとパーティション分割する必要があるという心配が無いので、フラッシュリソースがアイドル状態の仮想マシンに無駄遣いされず、小さ過ぎるキャッシュサイズの所為で無駄なキャッシュ廃棄サイクルが発生する心配もありません。これにより、ライトアンプリフィケーションに関連する問題を最小限に抑えられ、堅牢なフラッシュリソースであると同時に高パフォーマンスを保証できます。
フラッシュ仮想化プラットホームの基本要素 関連記事：フラッシュ仮想化プラットフォームの基本要素 パート1
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
