本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はWrite-Back and Write-Through policies in FVPで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
フォールトトレラントライトアクセラレーション(冗長化された書き込みの高速化)はFVPの重要な機能の一つです。FVPで加速させる仮想マシンを選択した後に、Write-Through、または必要なレプリカ数とともにWrite-Backポリシー適用する事が可能です。レプリカについて詳しく語る前に、まず、Write-BackとWrite-Throughポリシーの基本を復習しましょう。
書き込みポリシー
まず、フラッシュデバイス自身が永続的なデータストアではなく、アクティブなIOの収納場所である事にご留意ください。従って、アプリケーションが書き込みのIOを発行した場合、データはフラッシュデバイスに一時的に格納されるものの、データは何時かはストレージシステムに書き込まれなければいけません。ストレージシステムへの書き込み操作のタイミングは書き込みポリシーによってコントロールされています。
Write-Throughポリシー
仮想マシンがI/O操作を発行する時、FVPはそれがフラッシュから行えるか判断します。書き込みI/O操作の場合、書き込みは直接ストレージシステムに行き、データはフラッシュデバイスへとコピーされます。FVPはストレージシステムが書き込み操作の終了を確認してから操作の終了を確認します。
このポリシーでは書き込みのI/O操作はフラッシュデバイスによって加速されませんが、2回目以降のデータの読み込み操作はフラッシュから行われます。読み込みの操作がフラッシュ上のキャッシュで完了し、ネットワーク経由でのストレージのアクセスではなくなるため、この場合でも、書き込みの操作はわずかながらではありますがメリットをうけることが出来ます。これはストレージシステムへのリクエスト数を減らし、必要な帯域を減らすことで、仮想インフラ内の遅延を下げることに繋がります。ですが主として書き込みに重きが置かれるアプリケーションが実行されている場合には大きな効果は見込めません。
最初の読み込み / 余計な書き込み
読み込まれる前に全てのデータが仮想マシンから書き込まれている訳ではありませんので、書き込み操作の前に読み込み操作が必要なケースが有ります。例えば、OSを読み込んだり、ファイルを開く様な操作です。この操作を余計な書き込み(False write)といいます。False writeそのものはどちらのポリシーでも加速させる事はできませんので、最初の読み込みのアクセス時間はストレージシステムの性能次第です。けれども、FVPはストレージシステムから読み取った全I/Oをフラッシュデバイスへとコピーするので、2回目以降の読み込みは加速されます。
Write-Backポリシー
Write-Backポリシーは書き込みと読み込み操作を両方とも加速させます。アプリケーションが入出力の書き込み操作を発行した場合、FVPはそのコマンドをフラッシュデバイスへと送ります。フラッシュデバイスはまずアプリケーションへの書き込みを最初に確認し、ストレージシステムへの書き込みはバックグラウンドで行われます。結果として、FVPはストレージシステムの遅延とスループット性能で動作しますが、アプリケーションはフラッシュ並みの(低)レイテンシで動作することになります。
遅延する書き込みをフラッシュ上のレプリカで保護
Write-Backポリシーでは書き込みの遅延が伴います。遅延する書き込みとはフラッシュ上には存在しているが、まだストレージシステムへと書き込みが行われていないデータの事を示しています。データをフラッシュに格納する操作とストレージシステムに書き込む操作の間にESXiホストがダウンしたり、フラッシュデバイスが故障したりする恐れがあります。問題となるのは仮想マシンが違うホストで再起動した時に、クラッシュ以前に起動していたホストで行った全ての書き込みについての確認がとれていることです。
こういった問題からデータを保護し、全てのデータが整合性を持った環境にするため、FVPはフラッシュ上のレプリカを提供します。Write-Backポリシーは一つの仮想マシンについてレプリカを二つまで作る事が選択可能です。ここで、FVPは一つ一つの仮想マシンを異なる書き込みポリシーで構成できる事を忘れないでください。つまり環境によっては、ある仮想マシンはライトスルー設定で実行され、別の仮想マシンは二つのレプリカを持つある場合もあります。
仮想マシンがWrite-Backポリシーと一つのレプリカで構成された場合、FVPは書き込みをローカルフラッシュデバイスとリモートフラッシュデバイスの両方に送ります。ローカルフラッシュとリモートフラッシュの双方が書き込みの確認を返した後、FVPはアプリケーションに書き込みの完了を通知します。
遅延した書き込みをアレイへと送るのは仮想マシンが実行されている書き込み元ホストの責任です。もしもフラッシュデバイス、データストアへの接続、または、書き込み元ホストがダウンした場合、レプリカが収容されているホストの一つが遅延した書き込みを再送する作業に取り掛かります。気になっている人もいると思いますので言っておきますが、FVPはレプリカホストにデータを転送するのにvMotionネットワークを利用しています。
クラスタ技術は必須
ぱっと見ではわかりにくいかもしれませんが、仮想インフラ内の書き込みを加速するのは非常に難しい事です。ソリューションは仮想マシンが格納されている、複数のホストから変更される可能性のあるクラスタ化されたファイルシステムよりも前の段階でデータの高速化を提供することです。それに加え、vMotionのようにデータが常に正確、且つ利用できる状態でクラスタ化されていなくてはなりません。これを解決するため、FVPは仮想マシンのフラッシュ上のキャッシュに関連する全てのホストからデータが利用できるような完全にクラスタ化されたソリューションとなっています。次回の記事の焦点はリモートのフラッシュ上のキャッシュとFVPのクラスタ技術についてです。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
