本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はPernixData FVP Remote Flash Accessで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
FVPデモを行う際、多くの人が最初に注目が集まるのがWrite-Back機能です。この機能を搭載している高速化プラットフォームが現在他に存在しない以上、これは当然の反応です。しかしながら、リモートフラッシュアクセスの機能の話を詳しく説明し始めると注目は俄然この話題へ向いてきます。という事で、そろそろこれについて記事を投稿するタイミングだと考えています。
リモートフラッシュアクセスとは何か？
リモートフラッシュアクセスは、仮想マシンとフラッシュ上のキャッシュの所在にかかわらず、仮想マシンにvMotion実行前のフラッシュクラスタ内のホストのフラッシュ上のキャッシュにアクセスする事ができるようにすることです。もし仮想マシンがホストAからホストBへと移行し、ホストAのローカルフラッシュデバイスに保管されているデータを(ホストB上にいる)仮想マシンがリクエストした場合、FVPはそのデータを(ホストAのフラッシュ上のキャッシュから)読み込めるという事です。
理由は至って単純です。データの取得のためにわざわざストレージアレイまで行って、共有ストレージを叩くより、別のホストのフラッシュデバイスのデータにアクセスする方が遥かに速いからです。しかしこの機能を提供ことは単純な事ではありません。 仮想マシンがアチラコチラへ動き回ることができる分散システムに対応しなくてはいけないということと、その対応をフラッシュリソース上で行わないといけないという2つの難問を抱えています。
以前私の記事 “フラッシュ仮想化プラットフォームの基本要素 パート2 ～独自プラットフォーム対既存のファイルシステム～”でフラッシュを利用する上での課題について触れました。その中でフラッシュデバイスの寿命を保ち、予測可能で一貫した、安定的パフォーマンスを提供するために、プログラムが避けるべき書き込みや消去のサイクルについて解説しています。これは一つのフラッシュデバイスに同じデータブロックの複数のバージョンが格納されているかもしれないということを意味します。ローカルデバイス内で有効なブロックが一つあり、他は無効なブロックである事を把握するだけでも困難ですが、それを大規模になったとしたら!? DRSは一つのクラスタ内で32ホストまでの規模になることも有ります、そして、いつの間にか仮想マシンをあるホストから違うホストへと移動させてしまうかもしれません。
仮想マシンは移行後、新しいキャッシュをそのホスト上のフラッシュデバイスへ作成します。仮想マシンはこの間、このホストに移行後にリクエストしてはいないが、移行前のホストでリクエストした事のあるブロックのを転送をリクエストする事が可能です。どのブロックを転送必要があるのでしょう？FVPのキャッシュコヒーレンスプロトコル(訳註:キャッシュ内の最新データを常に監視するプロトコル)はどのブロックが一番新しいかを理解し、無効なブロックを無視した上で仮想マシンに取り込みます。分散アルゴリズムに関心がある者として、FVPがこの魔法を実行するのをまのあたりにした後、私はアゴがはずれて床に落ちてしまい、あとで拾い上げることになりました。
オーバーヘッドを避ける
オンデマンドにデータを取り出す機能によって、アプリケーションからデータがリクエストされたタイミングでデータを取り込みます。これによって多くのオーバーヘッドを避ける事が可能です。しばしばフラッシュ上のキャッシュは数十ギガ単位にまでなる事があります。DRSによって移動されてから間もないSharePointを実行しているVMのフラッシュの利用量のスクリーンショットを撮ってみました。フラッシュクラスタ内にVMは合計91 GBちょっとのフラッシュフットプリントがあった事が分かります。
VMが移動後ののホストのローカルフラッシュデバイスには1 GBちょっとあり、リモートフラッシュデバイスには90 GB程ありました。本当にこのデータを新しいホストへとすべてコピーしなくてはならないでしょうか?それともリソースの無駄でしょうか？これだけのデータをネットワーク上で送信するのはネットワーク上のオーバーヘッドの原因となるだけでなく、フラッシュの寿命を縮め、CPU・メモリレベルでのオーバーヘッドにも繋がります。
フラッシュウェア(ウェアレベリング)
ウェアレベリングを避けるため、フラッシュリソースがよほど逼迫しない限りデータを削除しません。つまり、容量を空けるためだけにFVPは無効なデータを削除しないという事です。容量を空ける必要がなければ、FVPは有効なデータに触れません。フラッシュのブロックを消すのにかかる手間が非常に大きいからです。詳しくは「FVPの基本要素 ～ 独自プラットフォーム対既存のファイルシステム～」を参考に。これは、有効なデータがあっても、アプリケーションがそれを実際には利用しておらず、今後も利用しないかもしれないということです。仮想マシンを別のホストへと移動している時にキャッシュを一緒にコピーした場合、フラッシュリソースを多く消耗する事になります。まず、すべてのデータがローカルフラッシュデバイスに書き込まれ、フラッシュの書き込み限度数を消費します。このデータの移動で生じる空き容量不足で、別のマシンための重要なデータが重要でないかもしれないデータのためにローカルフラッシュデバイス上から消去されてしまう可能性もあります。
ネットワークとCPUオーバーヘッド
無駄に利用されてしまう帯域幅とそれに伴って長くなってしまう移動時間について考えてみましょう。たまに仮想マシンを一つ移すのであれば、さほど気にならないかもしれませんが、DRSは5分ごとに最適な負荷分散を計算しています。もし移行量が非常に多く、この時間内に終わらなければどうなるでしょう？短い期間と長い期間の両方にわたって負荷分散の状況はどの様に影響をうけるでしょうか？メンテナンスモードを利用する場合はどうでしょう？企業によってはメンテナンスを実行するのにあまり時間の猶予がない場合もあります。多数の状況ではメンテナンス作業自身に長くなってしまった移行時間を足した場合、ホストをメンテナンスモードにするのがやっとで、時間内でできる事はメンテナンスモードを終了する事ぐらいでしょう。メンテナンスモードでホストを新しいソフトウェアにアップグレードしたり、設定の変更を加えるのに、古い無駄なデータのコピーに長い時間を費やすのは、単に時間の無駄で、俊敏なもしくは効率的なリソースの利用とは言えません。
そして、当然ながらデータをあるホストから別のホストにコピーするのに無駄遣いされるCPUサイクルのために、他のアプリケーションに割り当てられるCPUリソースが減ってしまう事になります。
30分が経過した頃、転送されたデータ量を確かめるため私達は再びSharePointサーバを確認しました。ローカルフラッシュフットプリントは1.15GBから2.97GBに増えた模様です。この測定はこのアプリケーションが利用されるピーク時間に行いました。結果として90GBものデータを2つのESXiホスト間で転送することがリソースの無駄以外の何物でもないことの証明になっています。
さて、ここで貴方は90GBの方はどうなってしまうのかと疑問に思ったかもしれません。FVP内のリソース管理機構がデータの利用を監視し、時間が経つにつれデータをキャッシュ上から開放し、新しいデータのためにスペースが必要になるタイミングで譲っていくことになります。データをフラッシュデバイス上で保持しておく事は悪い事ではありません。FVPはデータを賢く分類するよう設計されており、フラッシュデバイスの管理タスクを最適な方法で行うことが出来ます。新しいデータのためにスペースを空けなればいけない場合、FVPは無効なデータを最適な方法で消去し、ライトアンプリフィケーションを回避する事で、フラッシュの書き込み限界数の消費を減らします。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
