本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はFault Tolerant Write Accelerationで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
最高のパフォーマンスを得るためには、読み取りと書き込みの操作両方を高速化することが必須要件です。しかしながら、読み取りの高速化だけを提供しようとする場合と比べ、読み取りと書き込みの両方を高速化しようとする場合、プラットフォームの設計の根本が異なっています。
読み取り操作を高速化することは「直接的」な手順です。データストアから読み取ったデータをフラッシュレイヤ内にコピーし、2度目以降の読み取り操作に対してはフラッシュデバイスからデータを提供します。冗長性の必要は一切ありません。フラッシュデバイス上のデータはデータストア上のデータをコピーしただけのヴァージョンです。データに対しての変更は必ずデータが置かれているデータストアのレイヤで行われます。このため、パフォーマンスが劣化する以外にはフラッシュデバイスが故障した際にもアプリケーションは何ら影響をうけることはありません。書き込みの高速化を提供している場合にはこうは行きません。書き込み操作を高速化する際にはデータはフラッシュデバイスに最初に書き込まれ、その後、バックグラウンドでストレージにコピーされていきます。この時間に差が生じるため、ホスト障害やコンポーネントの故障によってコミットされていないデータが失われてしまう可能性があります。
データロスはあらゆる場合において避けなくてはなりません。このため、FVPプラットフォームはデータの一貫性と可用性を提供するための基盤から設計されています。書き込まれたデータを別のホストのフラッシュデバイスにレプリケーションすることで、ホストやコンポーネントの障害によって引き起こされるデータロスを防いでいるのです。FVPはクラスタとして設計されているため、当然ながら書き込まれた元のデータとレプリカが一貫性を持った状態に保つことが出来、ネットワーク接続の帯域を圧迫することなく必要なスペースを最小に保ち続けます。それではFVPがどのようにフォルトトレラントライトアクセラレーション(冗長性付きの書き込み高速化)を提供しているかを詳しく見て行きましょう。
ハイパーバイザー拡張でのFVPの統合
フォルトトレラントライトアクセラレーションの基盤はVMカーネルを拡張することで提供されています。非常に安定したESXiコアと密に統合されることによって、FVPは最適なスケジューリングとリソースの可用性を安全に、そして確実に利用することが出来ます。FVPのカーネルモジュールはカーネルのコードを拡張します。これは万が一にも停止したり、電源が落ちてしまう可能性のある仮想マシンや仮想アプライアンスで「サービス」が動作することが全くないということです。また、VMカーネルと同様にFVPはあらゆるCPU上で動作可能であるということも意味します。つまり、FVPはワークロードとともに拡張することが出来、カーネルが動作している限りFVPも動作し続けるということです。カーネルモジュールと仮想アプライアンスの比較については詳しくはこちらを参照してください。: フラッシュ仮想化プラットフォームの基本要素 パート1
書き込みの冗長化
フラッシュクラスタに仮想マシンを追加した際、適切な書き込みポリシーを選択可能です。Write-ThroughとWrite-Backの違いについて、詳しくは以下の記事を参照してください。「FVPのWrite-BackとWrite-Throughポリシー」Write-Backのポリシーは3つのオプションから選択できます。「Local flash only」、「Local flash and 1 network flash device」、「Local flash with 2 network flash devices」
Local flash only
「Local flash only(ローカルフラッシュのみ利用)」のWrite-Backポリシーはアプリケーションにとっての最高のパフォーマンスを提供するために作成されていますが、そのアプリケーションはノン・パーシステントのVDIデスクトップやキオスクアプリケーションなどの、追加での障害回避機構が必要ないアプリケーションに限定されます。フラッシュリソース(不揮発性のリソース)を利用するため、デバイス自身の障害でない場合にはフラッシュ内にはデータが残っており、利用可能なことは気に留めておいてください。例えば、もしもホストに障害があり、再起動した場合にはフラッシュデバイス上にはまだデータが残っているということです。もしホストレベルで恒久的なハードウェア障害が発生した場合でも、フラッシュデバイスを取り出して、フラッシュクラスタに参加している別のホストへ取り付ければ、FVPはフラッシュデバイスを検出し、必要であればデータのデータストアへのデステージを実施します。
Local flash with network flash devices
1つもしくは2つのネットワークデバイスをもつWrite-Backポリシーを選択した場合、全ての書き込みデータは適切な数のネットワーク越しの別ホストのフラッシュデバイスへと送られます。データの書き込みに引き続き、同期レプリケーションが実施されます。つまり、転送元のフラッシュデバイスと同様にリモートフラッシュデバイスの書き込みが完了するまで、仮想マシンに対して書き込み操作の完了を通知しなくてはなりません。
1. 仮想マシンが書き込み操作を開始
2. FVPはローカルフラッシュデバイスとリモートフラッシュデバイスの両方にI/Oを同時に送る
3. リモートフラッシュデバイス(もしくはローカルフラッシュデバイス)が書き込みの完了を通知する
4. FVPが仮想マシンに対して書き込みの完了を通知する
このステージでI/Oは完了し、アプリケーションは次の操作へ進むことが出来ます。FVPは非同期でI/Oをストレージシステムに書き込みます。この処理は完全にアプリケーションに対して透過的です。
5. FVPはストレージシステムにデステージを実施する
デステージの頻度
データが安全に複数のデバイスに保存されているとはいえ、FVPは可能な限り早くデータをストレージシステムにデステージしようと試みます。フラッシュデバイスへの書き込みを通知した後、FVPはストレージシステムが許容する限り速くデータのデステージを実施します。FVPはソースとレプリカのホストのデータの状態を同期し、データが安全にストレージ・システムに格納された後、FVPはレプリカホストに、データをいつでも破棄して良いことを通知します。このようにしてレプリカホストはフラッシュデバイスへのプログラムと消去のサイクルを悪戯に消費することなく、スペースを再利用することが可能です。この方法でフラッシュキャッシュでオーバーヘットが生じるのを最低限にすることが出来ます。
このUIはそれぞれのデバイスでの仮想マシンのキャッシュを表しています。この場合、仮想マシン1は「Local flash and 1 network flash device」のWrite-Backポリシーが適用されています。ローカルフラッシュ上のキャッシュは現在208.5MBもあるのに対し、レプリケーションによるリモートフラッシュへの書き込みデータは512KBだけ利用されています。
障害への対応
ところで、アーキテクチャ上のコンポーネントの障害が起きた場合、何が起こるのでしょうか？仮想マシンが動作しているホスト内のコンポーネントで障害が起きることも有りますが、書き込みのレプリカを保持しているホストで障害が起きることも有ります。FVPはソースホストでの障害時と同じようにレプリカホストでの障害も同様に対応できるよう設計されています。
ソースホストでの障害への対応
ソースホストで問題が起こった瞬間、FVPは書き込みデータを保持しているレプリカホストのうち1つに対して、そのデータをアレイに対して書き込みを行う責任を持つように、保証します。障害はフラッシュデバイスの障害と完全なホストの障害の場合のいずれの可能性にも対応できます。もしソースホストのフラッシュデバイスに障害が起きた場合、仮想マシンは動作し続けますが、性能加速は失われます。これはフラッシュデバイスの障害はパフォーマンスへは影響しますが、アプリケーション自身の可用性には影響しないということを意味します。レプリカデータを保持したホストが残った書き込みデータのデステージを担当します。
ソースホスト自身の障害の場合の動作も同様です。レプリカホストのうちいずれかが残った書き込みデータのデステージを担当します。HAによって仮想マシンが稼働中のホスト上に再起動すると、アプリケーションは一切のデータロスなく、機能を継続できます。
レプリカホストでの障害への対応
もしレプリカの書き込みデータを保持したホスト上のフラッシュデバイス、もしくはホスト自身が障害になったとしたら？この場合、FVPは2つの別々の手続きを開始します。まず最初に、仮想マシンの書き込みポリシーが一時的にWrite-Throughモードに設定されます。これはFVPは基本的にデータを失わないことを重視しており、レプリカホストの障害が起きると、現在のホストの組み合わせでは要求されている書き込みの冗長化が継続できないからです。
Write-BackからWrite-Throughに移行する最中、ソースホストではすべての残りの書き込みのでステージがすぐに実行されます。
PernixDataの分散リソースマネージャーがフラッシュクラスタ内の代替のレプリケーションホストとして利用可能な別のホストを選択します。この選択が完了すると仮想マシンの書き込みポリシーはWrite-Backモードに戻されます。この手順は自動的に、管理者から一切の操作を必要とせずに実行されます。FVPはデータを再優先で保護し、環境が再度加速できる状態あれば再度、加速環境へ切り替えます。
レプリカホストでのデータストア接続の障害の場合も、PernixData分散リソースマネージャーはホストをレプリカホストのリストから削除し、Write-BackポリシーをWrite-Throughモードへ切り替えます。
vMotion ネットワーク障害への対応
もし、ソースホストとレプリカホスト間を接続するvMotion ネットワークの障害が起きた場合はどうなるでしょうか？FVPはレプリカホストの障害と同様の手順に従います。
仮想マシンの書き込みポリシーがWrite-Throughに設定され、PernixData分散リソースマネージャーが新しいレプリケーションホストを選択し、再レプリケーションを実施します。新しいレプリケーションホストが選択されると、書き込みポリシーは要求されているものへ戻ります。
フォルトトレラントライトアクセラレーション(冗長性つき書き込み高速化)
vSphereは実証された記録を持つ、非常に安定したハイパーバイザーです。FVPはESXiのコアと密に連携することにより、堅牢な書き込み高速化のサービスの基盤を構成しています。クラスタ化テクノロジを利用し、FVPは書き込みのデータを別のホストのデバイスへ複製することで、単一障害点を排除しています。プラットフォームの重要なポイントはオーバーヘッドを最小にした上で、あらゆる場合で想定されるリスクを避けるということです。デステージのスピードとレプリカデータの管理の2つだけをとってみても、このテクノロジーがエンタープライズクラスのストレージのパフォーマンスを保証するものであることを確認できるでしょう。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
