PernixData FVPでWrite-Backキャッシュを有効にした時の効果

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

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

本記事の原文はEffects of introducing write-back caching with PernixData FVPで閲覧可能です。

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

実施に発生している問題を解決する新しいテクノロジーを実装するというのは素晴らしいことです。エキサイティングですし、それはソリューションを夢に描く少ない人々の肩にかかっています。しかし、この栄光は新しい設計と運用の基盤を求めてくることがあります。コレは悪いことではありません。ただ、違うということなのです。仮想化の魔法は新しいパラダイムにおける設計や運用の考慮点を理解し直すということを強いてくることはしませんでした。仮想環境にホストベースのキャッシュを実装することも同じです。

FVPを実装するのはとてもシンプルで、結果は非常に素晴らしい物になります。他の多くのものはそれを導入するということだけで非常に多くの努力を必要とします。その上で設計は投資が最大になってしまい、印象は悪くったり、ミスを増やすことにもなってしまいます。私はわたしの実際のワークロードから学んだことを共有したいと思います。そうすることで探しているもの、おそらく投資を避ける事ができるものを理解できると思うからです。FVPはReadとWriteの両方を高速化しますが、後者がほとんどの検討の中心です。ですからこの記事はそこにフォーカスします。

ストレージをFVPを使って高速化する際に私が気がついたのはどれだけのストレージI/Oが高速化されるのか?ということが最も大きな影響を持つということです。

プール化されたフラッシュとホスト間の相互接続速度
フラッシュ層とストレージ層のパフォーマンスの差
データのワーキングセットのサイズ
仮想マシンのWriteのI/Oのプロファイルの定期サイクル(Writeのピークや間隔を含む)
WriteのI/Oサイズ (それぞれのワークロードで異なる)
DRSや手動でのvMotionの実効頻度
フラッシュの素の性能や一貫性(フラッシュ自身やバスのスピード)
フラッシュの容量(Readキャッシュに大きな影響を及ぼすが、Writeへも影響する)

Write-Back キャッシュ & vMotion

今では殆どの人が知っているように、ホスト障害イベント時にデータを失う可能性を排除するため、FVPは1つもしくは複数のピア接続を通してWrite-Backキャッシュに冗長性を提供しています。相互接続にはvMotion networkを利用します。FVPが仮想マシンが後ろのデータストアを待つ必要性を分離してくれるため、冗長性のあるWrite-Backに構成された場合、WriteのI/Oの完了通知をローカルフラッシュと、1つもしくは複数のピアすべてから受け取って、その後、仮想マシンに完了通知が返されます。

これは環境にとってどんな意味を持つのでしょう? vMotionネットワークには今までよりも多くのトラフィックが流れることになります。以下のイメージを見てください。FVPで高速化されていないクラスタでは、ホストのvMotionネットワークのアップリンクのトラフィックは少ないですが、vMotionを実行している際にはトラフィックがバーストしています。FVPのWrite-Backをピア接続なし(WB+0)で利用している時も同じようになります。この下のイメージは仮想マシンを1つの接続で冗長化したWrite-Backに設定(WB+1)した後のvMotionネットワークの活動を表しています。この場合、平均して12MBpsのWriteのためのトラフィックがvMotionネットワークを流れています。スパイクのタイミングはvMotionが実行されたタイミングです。このスパイクは1GbEインターフェイスを使いきってしまうほどです。だいたい125MBpsです。

vMotionネットワークでこのようなトラフィックが流れるのは悪いことでしょうか?いいえ、そうとも言い切れません。結局はどこかでは流さないといけないのです。しかし、このことを知っていれば、サーバー間の接続の帯域が今まで以上に重要になることは簡単にわかります。vMotionネットワークが担う新しい役割を勘定に入れてインフラストラクチャの設計を調整すればいいのです。

サーバー間の通信で1GbEの接続を利用することをやめられますか?やめられるかもしれません。それは上で述べた要素次第ですが、時には簡単には判断しづらいことです。このようなことを考慮しながら、これまでに我々が得た知見も利用してみてください。

FVPのWrite-Backの冗長性ではネットワーク接続(vMotionネットワーク)を高速化された仮想マシンがWriteを発行するたびに利用します。
Write-Backキャッシュの冗長化されたWriteは高速化する仮想マシンの設定でピア接続するホストが増えると倍増します。
I/Oの完了までの時間(レイテンシ)を高速化されたWriteは最も遅い接続と同じ程度です。vMotionネットワークがローカルのバスよりも大抵の場合は遅いからです。品質の良くないSSDや、古い世代のバスがボトルネックになることもあります。
vMotionでは利用できる帯域をほとんど全て使い切ってしまいます。
たくさんのWriteを発行している仮想マシンは当然CPUリソース側にも負荷がかかっています。これによってDRSのルールで検出され、負荷のリバランスが行われることもありえます。つまり、vMotionの帯域をもっと使うことになるのです。このような忙しい仮想マシンはアクティブなメモリページを多く使っているケースが多く、vMotionの最中により多くのデータを動かすことになります。

複数階層での冗長性

vMotionネットワークが受けるWrite-Backキャッシュの冗長化の影響をよく理解するために、簡単なシナリオを考えてみましょう。この例ではWriteのみを実行します。

4つのホストがそれぞれ6仮想マシンのグループを動作させており、仮想マシンごとに5MBpsの定常的なWriteを発行しています。結果的にこれらの24のVMで合計120MBpsが後ろの物理ストレージに送られます。
Write-Backがまったく冗長性なしで有効になった場合(WB+0)、後ろのストレージは全く同じ総量のWriteがコミットされます。しかし、ちょっと違う部分があります。シーケンシャルで、スムースにデータが後ろの物理ストレージに書きだされていきます。
Write-Backが1つの冗長化を伴って有効にされた時(WB+1)、後ろのストレージは同じく120MBpsになります。しかし、同時に120MBpsのデータが接続されたホストへvMotionネットワークを通じて流れます。
Write-Backが2つの冗長化を伴って有効にされた時(WB+2)、後ろのストレージは同じく120MBpsですが、vMotionネットワークを流れる帯域は240MBpsになります。

Write-Backの冗長性の設定は仮想マシン単位の設定です。ですから、すべての仮想マシンを同じ設定にする必要はありません。仮想マシンはすべて同じWriteのワークロードを示すわけでもありません。しかし、このサンプルのイラストで示したように、1GbEのインターフェイスを使いきってしまうのはさほど難しいことではありません。1GbEのインターフェイスを1つがきっかり125MBpsだとして、この記載の配置に仮想マシンが配置されて、1接続で冗長化されたWrite-Back(WB+1)に設定されると、帯域の逼迫がおります。この状態ではvMotionやハートビートなどの他の帯域のための領域がほとんどない状態になってしまいます。(※訳注 : 本記事の原文の公開時はFVP 2.0のリリース前のため、調整型ネットワークの機能でこれが改善したという記載が後日掲載されています。)

いいことには、FVPはスマートに設計されており、vMotionのアクティビティを保証し、Write-Backのキャッシュのための通信を後回しにします。しかし、この問題については否定出来ない物理の限界があります。Writeをたくさん利用しており、FVPの能力を完全に活用したいと考えている場合には、ホスト間の接続は高速であるべきであるということです。より多くのパフォーマンスを得るための価格は小さくなりつつあります。FVPは1GbEでは、環境を高速化するのには理想的とは言いがたいという事実が明るみになりました。しかし、この数年で他に変わったものを考えてみてください。仮想マシンに割り当てられる標準のメモリサイズは大きく変わりました。(vOpenData Public Dashboard(訳注:リンク先は英語)で確認ができます。) 1GbEのvMotionネットワークは仮想マシンが512MBのRAMしか搭載していない時には十分でしたが、4、8、そして12GBのRAMになったとしたらどうでしょうか? 1GbEのvMotionネットワークは当初設計された時からすると時代遅れのものになりつつあるのです。

デステージング

Write-Backキャッシングで何よりも特徴的でユニークなのは、データが後ろの物理データストアに対してすぐさまでステージされるべきとしていることでしょう。サーバサイドフラッシュが後ろのストレージから分離され、多くのI/Oを最短のレイテンシで実行できるようになっています。多くのWrite I/Oが終わるまで、耐えうるだけのスピンドルが後ろにあるか、ないか、もしくはWrite I/Oを後ろの物理ストレージに送るに十分な帯域があるか? FVPのような構成もしくはフロントにI/Oパフォーマンスのためにフラッシュを配置し、遅いスピンドルにデータを送り込むストレージアレイやDAS構成の場合にデステージングの問題が発生します。

ワークロードとそれを動かしている環境次第であるということを知っておいてください。

もし、物理ストレージのI/Oの制限以上のWriteのワークロードの頻度に、次のオーバーコミットが始まる前に十分なデステージするための｢休息時間｣(I/Oのすべてを送っても後ろの物理ストレージが100%未満である時間と定義します)があれば、効率的により多くのWrite I/Oを短いレイテンシで行うことができます。
もし、物理ストレージのI/Oの制限以上のWriteのワークロードが非常に長時間に渡ってかかった場合、その仮想マシンに与えられているデステージャーの容量が埋まってしまうことになり、デステージできる能力以上には高速化を行えなくなります。

え? そうですよね、言葉で言うよりも、画像を見ていただくほうがわかりやすいです。次の画像は2つのシナリオが描かれています。

このイメージでWriteのI/O発生頻度を見ると、最大Write I/Oを波の高さで表しており、振幅でオーバーコミットの間隔を表しています。環境を評価する際にはざっくりとこのようなsin波が見えることになります。このWriteのI/Oの発生頻度は物理コンポーネントと密接に結びついており、FVPで環境をどれだけ高速化できるかの肝となります。

デステージャーに対してのWriteが後ろのストレージのWriteの性能を超えた場合には何が起こるでしょうか? 仮想マシンに与えられたデステージャーが満タンになると、高速化性能を減少させてゆき、後ろのストレージへデータを廃棄することができるようにします。本稼働環境ではこの状態が見られないこともあると思いますが、起こりうる話です。この記事の最初のリストのように、全ては要素次第なのです。人工的に生成したベンチマークワークロードでははっきりと確認することができます。これは5回のWrite I/Oのバースト(ブルーのライン)を、デステージャーが後ろのストレージに落としきれない状態(パープルのライン)で前に次々と発生させたものです。

これは以下の様に、実効のレイテンシ(ブルーのライン)へも影響を与えます。デステージャーが満タンなので、フラッシュと同じような短いレイテンシでWriteを完了することができず、後ろのデータストアと近いレイテンシ(パープルのライン)になっています。

多くのワークロードではこのような振る舞いは生じませんが、非常にWriteに偏った(例えば私の)ワークロードでは発生することがあります。つまり、高速化層と後ろのストレージのデータの差分が大きい場合にこれが発生します。

いい話としてはバーストするような傾向のあるワークロードは高速化層に完全に向いているということです。クラスタ化構成ではこれを発生させるのはさらに難しく、バーストはすぐに定常状態に戻ってしまいます。これが示しているのはもし、高速化層とストレージ層との間にパフォーマンスの差が十分にあり、定常的な書き込みが行われる環境に置かれた場合には、高速化の能力を維持するためにWriteを書き出していく時間が十分に取れなかった場合に起こるということです。

推奨

FVPの実装に含めておくべき私の推奨は(明らかにしておきたいのはこれは私個人の意見だということです)

まず最初は仮想マシンをWrite-Throughモードにして動作させ、FVPの解析機能で自分のワークロードをよく理解する(発生頻度、Read/Writeの割合、仮想マシンの最大スループット、IOPS、レイテンシ等)
ワークロードの振る舞いがよくわかってくるに従ってWrite-Backキャッシュを導入し、それがシステムにどのように影響があるかを見る
vMotionネットワークをよく見ておく(特に、1GbEの環境や、物理ポートが限られている場合)、そして帯域を食いつぶさないように見ておく。他には高速化されたWriteのレイテンシが増えてこないことも注意しておいてください。
vMotionネットワーク用の10GbEのNICを走って買いに行く。SAN、vMotionネットワークがすべて1GbEの古いファブリックだった場合は。(ブレードのように)アップグレードが難しいような要件がある場合には後ろのストレージではなく、vMotionネットワークを10GbEにする投資を行います。Readキャッシュですでにある程度はI/Oのストレージの負荷が軽くなっており、サーバー間の帯域を解決するほうが圧倒的位に合理的で、簡単な仕事です。
可能であれば、1つ以上の接続を割り当て、マルチ-NIC vMotionにする。現時点ではFVPはこれを有効活用することはできませんが、vMotionが別の忙しくない方の接続を利用してくれるようになります。もう一つの可能性として考えられるのは複数の1GbE接続をボンディングしてvMotionに利用することです。これは環境に合わない場合もあると思います。