本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。
本記事の原文はPart 5 - Solving Cache pollutionで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
｢従来型共有ストレージでの仮想化データセンターの拡張性についての問題｣シリーズではなぜ、相互接続された(ストレージの)各コンポーネントがうまく強調せず、一環したパフォーマンスを提供することが難しいのかの詳細をお話しています。根本的な問題としてはグローバルなコントロールプレーンが存在しないということがあげられます。消費者(仮想マシン)とその分散の具合、そして優先順位に基づいたリソースの配分を決定づけるための共通言語が存在しないということです。
すべてのものを織り込めるユニバーサルな言語の登場を待つ代わりに、業界はソフトウェアのコントロールプレーンのトレンドに湧いています。インテリジェンスをアーキテクチャの境界部分へと動かし、そしてリソースはコモディティ化されていきます。ストレージリロースを直接コンピューティングレイヤーに入れることは素晴らしいコントロール性を実現するだけでなく、リソースの消費と分散についての優れた洞察を行えるようにもします。このモデルが業界をキャッシュの汚染問題などの解決が難しい問題を解決に導いてくれます。
キャッシュの汚染
一般的に、ストレージコントローラー内のキャッシュはReadとWriteのために利用されています。Writeキャッシュはストレージに対して発行されたWrite操作のレイテンシの低減に役立ちます。
Readキャッシュはストレージのデータに対するRead操作のレイテンシの低減に役立ちます。データへのアクセススピードはもしもデータがキャッシュに乗っている場合、スピンドル上からそれを取得する場合に比べ著しく向上します。アクセスパターンについてやキャッシュの保持に関してはものすごい量の研究がこれまでになされています。アプリケーションは短時間内に何度も同じデータにアクセスする傾向があります。アプリケーションはデータをWriteしますが、直前に参照されたデータの近くのデータへアクセスするということもあります。このことをキャッシュ保持の連続性と呼ぶこともあります。ですのでReadキャッシュはアクセスされたデータを保持し、リクエストされたデータと連続したブロックを事前取得して、将来的に行われる可能性のあるI/Oのリクエストをより高速に処理しようとする傾向があります。
しかし、一部のアプリケーションとその先読みの操作は必ずしも、ストレージが実装しているブロックのレイヤーで連続しているとは限りません。加えて、ストレージスケジューラーの平等性のポリシーによって、大抵大きな連続したReadのアクセスパターンは小さな連続したReadのパターンに変換されるか、どのI/Oがどの仮想マシンによるものなのかが無視されてしまい、ランダムなRead I/Oに変換されてしまいます。さらに、ストレージコントローラーはポリシーの平等性をすべての消費者に適応するために、共有キャッシュを多くの接続された別のシステムへも提供しなくてはなりません。
一部のバックグラウンドプロセスも、フロントエンドで動作しているアプリケーションへのReadキャッシュの提供能力に影響を及ぼします。バックアップやウィルススキャンなどのバックグラウンドプロセスは仮想ディスクの全体を、シーケンシャルに読み込みます。しかし、バックアップやウィルススキャンの操作はデータの一時的な保持を必要とはしません。プロセスの最中にデータを再度参照するようなことはほとんど起こりません。
キャッシュの容量は有限です、結果としてキャッシュ容量を超えたデータは廃棄されます。バックアップジョブやアンチウィルススキャンによって読み込まれたデータはキャッシュの容量を超えてしまうことも度々です。これは現在キャッシュ内に保持されているデータが、バックアップジョブやアンチウィルススキャンでリクエストされたデータで置き換えられてしまうということで、再利用されることのないデータでコントローラーのキャッシュが汚染されてしまうということです。もしこのデータがキャッシュの容量を超えた場合、ReadとWriteの廃棄サイクルは何度も繰り返されてしまいます。これは処理の最中ストレージに接続されたすべてのシステムのストレージのパフォーマンスに影響します。こうしたバックアップやアンチウィルススキャンの最中はアプリケーションはデータをスピンドルから取得しなくてはならず、レイテンシーが高くなってしまいます。しかし、こうした仮想マシンが行っているバックアップやアンチウィルスの操作に対してストレージのキャッシュ操作を統合するようなものはありません。
状況を把握した(Context-aware)環境
新しいストレージのアーキテクチャでは、ハイパーバイザー内にストレージリソースを移動させています。ハイパーバイザーは多くの情報を持ち、ワークロード個々を把握しながら、さらにリソーススケジューラーでリソースを管理しています。ハイパーバイザーをリソースと要求の両方を管理できるコントロールプレーンに変えることで、アプリケーションのサービス品質のレベルに適切に答えられる一体化した自動化操作を行える構造にすることができるのです。
仮想マシンの状況を把握した(VM-aware)スケジューリングと自動化の良い例がFVPのI/Oプロファイリング機能です。VSANとハイパーコンバージドシステムも同様のアプローチでこの問題を解決しています。私はPernixDataで働いていますので、FVPがどのようにしてバックアップやアンチウィルススキャンによるキャッシュの汚染問題を解決しているのかを詳しくお話します。
I/O プロファイリング
アプリケーションがFVPによって高速化されている際、仮想マシンの高速化リソース上のキャッシュデータも同じ問題にさらされる可能性があります。Read操作が発生すると、FVPはデータがホスト内(キャッシュ)から提供できるか、それともストレージから取得するかを判断します。キャッシュにデータがない(キャッシュミス)場合(2)、データはストレージから取得されます(3)。データをアプリケーションに提供しながら、パフォーマンスの改善のためにデータはローカルの高速化リソースにコピーされます(4)。この手順はフォールスライト(false write)と呼ばれます。
バックアップジョブの最中、FVPはアプリケーションのホットデータをバックアップジョブによって取得したフォールスライトのデータによって置き換えてしまいます。同じようなことがアンチウィルスの最中にも起こります。VM-awareであるFVPは管理者がI/Oプロファイルをインテリジェントに管理することができるようになっています。
FVPはpower-cliコマンドを提供し、管理者が仮想マシンのRead もしくは/または Writeの操作を一時的にキャッシュしないようにすることができます。これによってFVPはフロントエンドプロセスが頻繁にアクセスするデータを高速化リソース上に保ちながら、ストレージアレイに対して直接Writeを継続することができます。PowerCLIコマンドが発行されると、FVPはストレージアレイからキャッシュミスで取得されたデータを無視し、バックアップジョブやアンチウィルススキャンで要求されたデータによってホットデータが上書きされることを防ぎます。バックアップ操作が完了すれば、PowerCLIコマンドを発行し、すべてのデータの高速化を再度スタートさせます。PowerCLIコマンドについての記事はすぐに公開します。
仮想マシンのフォールスライトやトゥルーライト(True Write=仮想マシンからの直接の書き込み)をキャッシュしないようにしても、FVPは仮想マシンからのすべての操作を実行できます。例えば、｢Suspend- PrnxReadDataPopulation｣をアクティブにすると、すべてのReadのI/Oのうち、高速化リソース上にデータが有る場合には高速化されて提供されます。
ほとんどすべてのバックアップソリューションはPre-およびPost-コマンドを設定することができるようになっています。これらのコマンドを利用して、アプリケーションから頻繁にアクセスされるデータを残しながら、フラッシュデバイス上にバックアップによって発生する不必要な消耗や劣化を発生させないことができるようになっています。状況が把握できる環境とサーバサイドリソースを活用することで、アプリケーションの処理に応じたインテリジェントなリソースの管理を実現するアーキテクチャが構成できるのです。アプリケーションのパフォーマンスを犠牲にせず、同時にバックグラウンドのプロセスもしっかりと継続して動作できるようになるのです。
本シリーズの他の記事:
Part 1: イントロ
Part 2: ネットワークトポロジー
Part 3: データパスはクラスタリソースとして管理されていない
Part 4: ストレージコントローラーのアーキテクチャ
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
