HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

フラッシュ・キャッシングについて知っておかなければならないこと(後編)

George Crump
Storage Magazine 2014年7月号より

VMマイグレーションとサーバーサイド・キャッシング

事が仮想マシンのマイグレーションとなると、ファイルレベル・キャッシング製品、ブロックレベル・キャッシング製品ともに仮想化環境における真価が問われることになる。VMが1台の物理サーバーから別な物理サーバーに移される時、キャッシング・ソフトウェアはマイグレーションを一時中断し、実際にマイグレーションが始まる前にキャッシュを無効化しなければならない。（キャッシュの無効化とは、キャッシュの中身を空にする処理である。）

現在市場にある製品の大半は、最低限VMマイグレーション開始前に必ずキャッシュを無効化する機能を持っている。しかし、VMが移行先のサーバーに移った時、キャッシュがどのように再構築されるのか、というのが気がかりだ。ここがまさにファイルレベル・キャッシングが際立った長所を発揮するところだ。キャッシング・ソフトウェアがゲストOSにインストールされているため、高速化すべきファイルを定義したポリシーはVMとともに移動し、これらのファイルはVMが移行された後、迅速にキャッシュにリロードされる。

ブロックレベルのキャッシュの場合、VMが移行先のホストサーバーに移った時、キャッシュ分析を一からやり直さなければならない。これはすなわち、データのキャッシュ価値を再査定するのに使われるパフォーマンスは、ハードディスク（HDD)の速度の制約をうける、ということを意味する。場合によっては、新しいサーバー上でキャッシュに正しくデータが置かれるまでに、何日もかかることがある。

いくつかのブロックレベル・ソリューションは、マイグレーションが発生した時に、移行先ホストにキャッシュ分析情報を送ることができる。この場合明らかに、同じキャッシング・ソフトウェアが両方のホストに入っていなければならないことになるが、これが一般的な方式のようだ。移行の際、キャッシュ分析情報をVMと共に転送することで、受け手側のホストで稼動しているキャッシング・ソフトウェアは、そのVMにおける最適なブロックを、即座にキャッシュエリアにコピーすることができる。この処理が発生している時でも、パフォーマンスはHDDの制約をうけるものの、処理自体は非常に高速で、通常数分で終わる。

集約型キャッシング・ソリューション

フラッシュ・キャッシングの第3の選択肢は、集約型キャッシング・ソリューションである。これらの製品は、サーバー内部のフラッシュ・リソースを組み合わせて、仮想でありながら共有プールとなるストレージを作ることによって、マイグレーション問題を解決している。また、これらの製品は、RAIDと同様のデータ保護の仕組みを実装できるので、より優れたレジリエンス（弾力性）も提供する。マイグレーション対応に優れ、レジリエンスも高いことから、集約型ソリューションはリードにとってもライトにとっても理想的なソリューションとなっている。これらの製品は仮想クラスター内の全ホストに、キャッシング集約ソフトがインストールされ、二つの機能を実行する。一つはフラッシュ・リソースを集約すること。もうひとつは、集約したフラッシュをキャッシュとして最も有効に使うノウハウが入ったインテリジェンスを各ホストに提供することである。このインテリジェンスは、ファイルレベルやブロックレベル・キャッシング・ソリューションで使われているキャッシング・アルゴリズムと同様のものだ。

クラスター内では少なくとも３つの（通常はもっと多い）ホストがフラッシュ・リソースを提供する必要がある。フラッシュ・リソースは、フラッシュストレージの仮想プールへと集約され、レガシーなストレージレイヤーに対するキャッシュレイヤーとして動作する。ここで重要なことは、最少3台のホストが参加しなければならないものの、全ホストがフラッシュ容量を提供するとは限らない、ということだ。これらキャッシュ集約型ソフトウェアのほとんどが、クラスターに接続しているどのホストからでもフラッシュのプールにアクセスできるようになっている。

一度、フラッシュの集約型プールが完成すれば、フラッシュキャッシュ・ソフトウェアは、各ホストが最もアクティブなデータをフラッシュ・ティアに移動するように、キャッシング・インテリジェンスを各ホストに供給する。集約型キャッシュの優れた可用性のおかげで、ほとんどの場合、ライトI/Oは最初から直接フラッシュ・ティアに書かれるようになる。しかし、他の二つのキャッシュタイプと異なり、マイグレーションが発生しても、共有プールを使っているためキャッシュ分析を再構築する必要が無い。移行先のホストは、移行前のホストが残していったものをそのまま使うだけでよい。

集約型方式の欠点は、フラッシュ・ティアへのアクセスによってネットワーク上のデータ移動が発生してしまうことだ。パフォーマンスを一定に保つために、このタイプの製品ベンダーの多くは、キャッシュ・ティア専用のネットワークを使うことを勧めている。集約型キャッシング・ソリューションにおける効果を最大限に上げるためには、巧みに設計されたサーバー間ネットワークが必須である。他の二つのキャッシング・ソリューション（訳註：前編で述べた、ファイルレベル・キャッシング・ソリューションとブロックレベル・キャッシング・ソリューション）は、通常サーバー内にインストールされたフラッシュからのキャッシュ・リクエストに対応している。

フラッシュキャッシュの中でどれが最善の選択か？

あなたの会社にとって最善のキャッシング・ソリューションは、あなたの会社の環境によって変わってくる。例えば、サーバー間ネットワークが既に構築されており更新も行われているのであれば、集約型キャッシング・ソリューションには良いところが多くあり、キャッシュデータに優れたレジリエンスを提供してくれることだろう。しかし、あなたのサーバー間ネットワークが、高い作業負荷に耐えられないのであれば、サーバー内にインストールされたファイルレベルかブロックレベルのキャッシング・ソリューションが最善の選択になるだろう。これらのソリューションはネットワークをいじらなくても、相当なパフォーマンス向上をもたらしてくれる。ほとんどのストレージ管理者は、サーバーネットワークの更新や変更をする権限を持っていないため、この点は重要である。

著者略歴：George Crumpは、ストレージと仮想化を専門とするITアナリスト企業Storage Switzerlandの社長である。