株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

PernixData FVPのクラスタ化リードキャッシュ機能を理解する

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第7弾です。

本記事の原文はUnderstanding PernixData FVP’s clustered read caching functionalityで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

2013年の8月、PernixDataがFVPをデビューさせた時に戻りますが、私にとっては何者にも代えがたいイノベーションがありました。サーバサイドでWriteを高速化させる能力(「Write Back」キャッシングとして知られています)と、そしてそれを耐障害性のあるやり方で実現できたことです。サーバサイドの高速なメディアを活用し、VMwareクラスタリング(vMotion, HA, DRS等)のメリットをすべてそのままに、仮想マシンにマイクロ秒のレイテンシを提供します。すぐ近くで完了通知を返すことによる物理的な優位性を仮想マシンに提供しながら、コンピューティングとストレージのレイヤを別々にするというメリットを提供するのです。

しかし、このイノベーションの有効性によって、見落とされてしまいがちなのが、FVPがどのように高速化デバイスクラスタ化し、Readのキャッシング(FVPの「Write Through」キャッシングとして知られています)のためのリソースのプールを作るのか、です。新規のそして既存のFVPのユーザーにとって、クラスタ化されたReadキャッシングの効率性を理解しておくことは非常に重要です。これは環境を改善していく非常に良い機会となるでしょう。そのようなために今後リリースされる予定のFVP Freedomエディションを利用していただきたいです。これは非常に優れた監視と表示の機能を持ち合わせています。Virtualization Field Day 5でアナウンスされたとおり、FreedomエディションはFVPのフリーエディションであり、Readのキャッシングのみと、最大で128GBまでのメモリ(RAM)しか使えないといった、ちょっとした制限がかかっています。

適切なやり方でのReadキャッシングの力

Readキャッシング自体は有効なパフォーマンス改善の方法と理解されていますが、一過性のものであり、I/Oの対話の1方向しか解決をしてくれないと見られています。残念ながら、この見方では話の半分も理解していないことになります。よく悪く言われがちですが、このタイプのキャッシングはほとんど誰もが、そしていたるところで利用しています。あらゆるタイプのストレージ、ハイパーコンバージドソリューション、そしてDASに至るまでです。ちょっと掘り下げると、安直なソリューションだと気が付くでしょうし、どのようにそれが実装されているのか気になることでしょう。ですから私は以下のようにお話しています:

  • ストレージやハイパーコンバージド環境内のキャッシュサイズの調整ができない制限
  • 単一ホストのサーバサイドソリューション(vMotionのような操作で有効性を失う)
  • 仮想マシンやワークロードを理解できない

既存のソリューションは上のような安直さを抱えています。しかし、上記の3つを欠いては本当に効率的にはReadキャッシュを提供できません。FVPのアーキテクチャはこの3つ全てを解決しています。中央のストレージが最も得意なこと、つまりデータの保管に集中させながら、パフォーマンスの層を素早く適応させていく事ができるのです。

FVPは高速化層のサイズを自由に選ぶことができます。これだけで非常に大きな結果につながります。例えば、現在のNVMeベースのフラッシュカードは2TBの大きさです。そして、近い将来劇的に大きくなる予定です。10ノードのクラスタが20~40TBもの高速化層でたった50TBもの永続ストレージを高速化できることになるのです。ハイブリッドストレージは数百GBのフラッシュで同じ50TBのストレージと相対しなくてはなりません。そして、アレイコントローラーにはこれが一気に注ぎ込まれることになります。ネットワークやストレージスタックをへて流れてきたI/Oがようやくキャッシュデータになり、新しいブロックが入ってくるとすぐにフラッシュから廃棄されてしまうのです。

他のホストサイドのキャッシュソリューションとはことなり、FVPはそれぞれのホスト上の高速化デバイスを集約し、プールのように扱うことができます。ワークロードは積極的にvSphereクラスタ上のホストを移動します。それらのワークロードは軽量なプロトコルを用いてプールから(ネットワーク越しに)キャッシュの内容を取得することができます。従来、vMotionのようなイベントが発生すると、ホストベースのキャッシュはデータを再度バックエンドのストレージから、従来のプロトコルを用いてストレージスタック全体からキャッシュを再構成する必要がありました。

FVPは仮想マシンが見えています。これはそれぞれのキャッシュブロックがどの仮想マシンのものなのかーどこから来て、どこへ行くのかーを理解しているという意味です。そして、数多くのキャッシュの一貫性を保持する方法を備えています。(詳しくはFrank Dennemanの記事 キャッシュの汚染の解消) 従来のやり方でのキャッシュ層の提供は全くと言っていいほどそのブロックが何に紐付けられたものなのかということを理解せずに行っています。必要な情報はブロックがホスト上のHBAを通り抜けた瞬間に消え失せます。このような構成は最も広く利用されているものですが、実際の環境でのシナリオを見落としているのです。1台、もしくは複数のやかましいご近所仮想マシンが簡単に汚染してしまい、キャッシュ内の他の仮想マシンが利用すべきホットブロックを強制的に廃棄してしまうのです。結果として自然に導き出されるのは従来のアプローチではパフォーマンスの予測はできないということです。

どのように動作しているか?

FVPのクラスタ化Readキャッシュアプローチの背景にあるロジックは非常にしっかりしており、効率的です。仮想マシンのキャッシュされたReadはクラスタに参加しているどのホストからでも習得が可能です。これによってクラスタ内のどこに仮想マシンがいたとしても関係なくキャッシュを活用できるのです。Frank DennemanのFVPのリモートキャッシュアクセスという記事がこの詳細を解説しています。

チャートの調整

今回はReadキャッシュのメリットをFVPのチャートから理解しようとしていますので、カスタムビューを作成しましょう。これによってRead I/Oに完全にフォーカスし、並行して発生しているWriteのI/O活動に惑わされることはなくなります。

Fig282

「Custom Breakdown」を利用した際に、標準の「Storage Type」の表示でReadとWriteに利用されているのと同じ色が利用されますが、今回はリソースタイプを指定したReadのみを選択します。標準の「Storage Type」表示とカスタム表示で気持ちを切り替えてください。

Fig283オフロードを見る

よく設計されたあらゆるストレージシステムの目的は適切なパフォーマンスをアプリケーションに提供することです。FVPを利用していると、I/Oはストレージからサーバサイドの高速化層にオフロードされます。Readのリクエストは仮想マシンに高速に提供され、レイテンシが削減され、アプリケーションのスピードが上がります。

財政的な投資の観点からはI/Oの「オフロード」のメリットを忘れてはいけません。もしくは、言葉を変えると高速化層から提供されるReadのリクエストです。FVPを利用すると最終的なストレージ層であるストレージ装置、アレイコントローラー、ファブリック、そしてHBAからオフロードされるのです。つまり、もっと現実的なバックエンドストレージを選ぶことができます。ヒーローナンバーのショーケースはこのオフロードをうまく集計してくれます。

Fig284

Network acceleration Readを見る

他のホストベースのソリューションとは異なり、FVPはvMotionやDRS、そしてHAのような活動と共生することができ、バックエンドのストレージからキャッシュを再構成するようなことを強要することなくシームレスに動作します。以下は3つの本番環境の仮想マシンからくるReadのI/Oの例です。キャッシュされたReadについてリモートホスト上の高速化デバイスへアクセスしています。

Fig285レイテンシがリモート高速化デバイス(グリーンのライン)から提供されることによって、低く保たれていることを確認して下さい。

リードのキャッシュがどのぐらいうまく動作しているか?

FVPで設定されているWriteポリシー(Write Through または Write Back)によらず、キャッシュは同じ方法で行われます。

  • すべてのバックエンドのストレージへReadリクエストはデータがストレージから取得されたタイミングで高速化層に配置される
  • すべてのWrite I/Oはストレージに書き込まれたタイミングでキャッシュに配置される

ですから、ReadのI/Oが高速化層から提供されない場合、以下のうちの3つのどれかであると簡単に結論付けられます。

  • これまでに一度もリクエストされたことのないブロックのデータ
  • FVP導入前に書き込まれたデータで、キャッシュにのっていなかった
  • 一度はキャッシュに保持された(ReadまたはWrite経由で)がキャッシュサイズの問題で廃棄された

最初の2つの場合、ワークロードの特性を反映することになりますが、最後のものは設計上の決断ーキャッシュのサイズーによるものです。FVPでは、キャッシュ層を構成するためにどのぐらいの大きさのデバイスにするかを選ぶことになります。ですから、どのぐらいのメリットを得るのかということを決めることになります。キャッシュのサイズはパフォーマンスに大きく影響します。以前のデータを廃棄して新しいデータのためのキャッシュの容量を確保するというプレッシャーが小さくなるからです。

Readキャッシュの利用量を可視化する

FVPのメトリック計測がモノを言う部分です。記事の前の部分で「Custom Breakdown」表示を見た際、簡単にどれだけのReadが高速化層から提供されたのかということを見ることができます。ほとんどのRead(3500IOPS以上が継続)がこのフレーム(1週間)ではバックエンドのデータストアから提供されています。

Fig286

さて、別の環境のべつのワークロードと比較してみましょう。以下のイメージは1日のうち、大部分のデータが高速化層から供給されていることを表しています。60MBpsものスループットのRead I/Oのうちほとんどはストレージ装置に一度も触れません。

Fig287

Readキャッシュサイズを評価する際に、私が「Custom Breakdown」を利用するのがとても大好きな理由がこちらです。FVPがReadをオフロードどれ位しているかということがわかるだけではなく、すべてのストレージからオフロードできた"かもしれない"Readも見つけることができるのです。どのぐらいのオフロードが発生するかということをみることができ、それによってどのぐらいの層のサイズが必要か、どのぐらいの仮想マシンがその層を利用できるかということがわかるのです。

ヒット率もあらゆる時系列上のポイントでどのぐらいのReadが高速化層から供給されているのかということを%で表します。これもキャッシュのヒット率が低い場合には非常に有効な方法ですが、もっとよく見てみたい場合、「Custom Breakdown」を利用し、さらなる文脈やどれだけのデータがキャッシュとバックエンドのデータストアから来ているかを調べます。廃棄率も廃棄率が継続的に高いようであれば重要な情報です。しかし、廃棄率が低くても何度もキャッシュデータを廃棄しており、影響がある場合もあります。ですから、「Custom Breakdown」がReadを評価する際のお気に入りのツールなのです。

多くのReadがバックエンドのデータストアから来ており、キャッシュからではない場合、どのようにすればよいのでしょうか? 例えば500の仮想マシンがほんの数GBの高速化層で動作していることをイメージしてください。キャッシュはすぐに流れ去ってしまい、メリットを出せる喉の効果はありません。高速化リソースとしてとても少ない総量のメモリ(RAM)でFVPを利用しようとしているときには2つの効果的な方法があります。1.) キャッシュのサイズを増やす 2.) 高速化に参加させる仮想マシンの数を減らす。いずれの方法も同じことをやろうとしています。高速化した仮想マシンにもっと大きなキャッシュサイズを割り当てようとしているのです。キャッシングのレイヤがアクティブなデータ(「ワーキングセット」とも)のうちほとんどを格納できるように私用という考えです。FVPではサイズの調整や仮想マシンの追加は非常に簡単に行えます。

ワーキングセットのサイズがわからないって? PernixData Architectをお待ちください!

まとめ

FVPでReadキャッシングを計画しているとしたら、そして最大限のオフロードを実現しようとしているのなら、クラスタ化されたReadキャッシングによって最高のパフォーマンスを得られます。FVPに実装されているクラスタ化されたReadキャッシュはアーキテクチャ上からどのように設計するかという議論や、どれだけのコストがかかるのかという議論を変えてしまいます。Writeのバッファリングを行える完全版のFVPと一緒にゲームを完全に変えてしまいます。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)