本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
非常に良い記事がたくさんあるので引き続き翻訳に加えていきたいと思います。
本記事の原文はA look at FVP 2.0’s new features in a production environmentで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
私は隣に座っている人と同じぐらい、いいベンチマークが大好きです。けれどもデータセンターにおいてもそれがうまくいくかどうかは人工的なベンチマークの結果だけでは予測することができません。特にベンチマークが実際のワークロードとは異なる負荷を生成している場合はこれが顕著です。これが主な理由で私は本稼働環境のFVPを2.0にできるだけすぐにアップグレードすることにしました。ラボ環境でいくつかのテストをしたあとに、本稼働環境のワークロードをFVP 2.0の新しく、そして改善された機能がどのように影響するのかを見たくなったわけです。最も簡単な方法は座って、よく見て、そしていくつかのスクリーンショットを共有することです。
以下のすべてのイメージは私の本稼働環境のコードのコンパイル用のマシンで、一日のランダムな時間に動作をはじめます。ワークロードはいつもどこかしら変化していきます。なのでベンチマークの結果と比べると｢見た目ではっきり違う｣振る舞いをします。さらに、これらの仮想マシンが普通の仮想マシンよりは負荷が高い仮想マシンであることを付け加えておきます。コードをコンパイルする仮想マシンは組織の中で｢設計が難しい｣仮想マシンの三冠王になることもしばしばです。
- I/Oサイズが大きい(訳注:リンク先は英語、後日翻訳予定) (32K～512K、大体は256K当たり)
- 書き込みが多い (フルコンパイル時には95%～100%がWrite)
- コンパイルの最中はコンピューティング、ネットワーク、ストレージリソースを使い続ける
このような状況下で利用するフラッシュの特性には色々と驚かされることになります。大きなI/Oでの多くの書き込みはフラッシュをハチミツにします。レイテンシがバラバラと偏在し、50ms以上になる(訳注:リンク先は英語、後日翻訳予定)こともまれなことではありません。業界においてフラッシュはブームであり、ほとんどすべてのものを改善してくれます。しかし、一般的に言われることとは異なり、万能薬ではないのです。フラッシュの特性を勘定に入れておく必要があり、高速化リソースに利用するのか、それとも永続的なデータのストレージとして利用するのかによってその期待値を調整する必要があるのです。もしも大きなI/Oサイズがあなたの環境で当てはまらない場合、ファイルサーバーに何かのファイルをコピーするときの平均的なI/Oサイズだと思ってください。
もう一つ重要なことは比較の最中に私はインフラストラクチャを物理的に一切変更していないということです。残念なことに、私のレプリカトラフィックのための接続はまだ1GbEで、ブレードはIntel S3700のSSDのをSAS/SATAコントローラーに埋め込んでのみ、活用できる状態です。仮想マシンは未だに終息直前の1GbEベースのストレージアレイに置かれています。
もう一つ述べておくべき内容としては私の環境での数値は最も悪いシナリオだろうということです。あなたの環境では私の環境よりも劇的にレイテンシが低いはずです。この点において、FVPが適切に私の環境を高速化できたとしたら、改善率はあなたの環境よりも良くなっているはずです。さぁ、結果をみていきましょう。
調整型ネットワーク圧縮(Adaptive Network Compresssion)
1GbEのネットワーク接続を利用している顧客向けに、FVP 2.0はちょっとした救済として調整型ネットワーク圧縮(Adaptive Network Compression)を提供しています。この機能をオン/オフ切り替える方法はないのですが、以前どうだったのかをお見せすることができます。
FVP 1.x
これはコンパイル中のビルドマシンの古いイメージです。WB+1モード(1つの接続でレプリケーション)で設定されていました。見て分かる通りブルーのライン(VMから見たレイテンシ)は大きなWriteを1GbEのパイプを通して押し込もうとして、詰まってしまっています(訳注:パープルのライン=ストレージの性能とほぼ同等になっている箇所があります)。SATA/SASベースのフラッシュデバイスは機体ほどは良い結果を出せていません。フラッシュ自身の特性に加えて、1GbEの制限と相まって、高速化を難しくしているのです。
調整型ネットワーク圧縮(Adptive Network Compression)をFVP 2.0で利用
1.xと2.0の実際のレイテンシの比較を提示する前にもっとワークロードを見やすくします。以下はコンパイルジョブ実行中の単独の仮想マシンのスループットの表示をズームし(大体20分ぐらいの間隔)たものです。ひと目で分かる通り、ほとんどがWriteです。
以下は対応するIOPSの値を表示しています。ほとんどがWriteのIOPSです。そして繰り返しになりますが、大きなI/Oサイズのためにスループットに対してIOPS値が低くなっています。512KのI/Oサイズであればものの百ちょっとのIOPSでも1GbEの接続を食いつぶしてしまうのです。この場合、フラッシュに問題があるとは思えません。
今度は同じ仮想マシンの同じ時間軸でのレイテンシを見てみましょう。以下のイメージでは、ブルーのラインの仮想マシンからみたレイテンシは多くのWriteを行っている時も6～8ミリ秒程度に改善されています(左のスパイクは別のReadなので無視してください)。6～8ミリ秒のレイテンシはWB+0、つまりローカルフラッシュデバイスのみを使う場合の構成でのレイテンシと非常に近しい値です。
同じ高速化デバイス(Patsburgのコントローラーが埋め込まれたIntel S3700)を1.xで利用した時と比べると、その効果は劇的です。冗長化のための｢ペナルティ｣は大きく削減され、こうなってくると後ろのフラッシュがレイテンシーを大きな影響力を及ぼします。よく見て欲しいのがどのぐらい圧縮が効果を出しているかという結果です。ものの3営業日でピア接続ネットワークを流れるデータを1.5TB削減したのです。(表示していませんが、もう一つのFVPクラスタでも 350GB削減されました)
分散冗長性メモリ(Distributed Fault Tolerant Memory)
もし、もう一つフラッシュがうまくいかない理由があるとすればそれは大きなI/OサイズでのWriteによるものです。フラッシュにまつわる様々なオーバーヘッド(ガーベージコレクション、ライトアンプリフィケーション、等)すべてを考えてみてください。私のケースの場合、それに加えてギリギリのストレージコントローラーに注ぎ込まれるのです。この点が分散冗長性メモリ(DFTM)によって私の環境がどれぐらいのパフォーマンスの影響があるか知りたかった点です。このテストでは私はDFTMクラスタ用に各々のホストから96GB(全体で384GB)切り出しました。
さぁ、同じようなビルドをWrite-backで走らせてみましょう。違うのは今回はDFTMということです。このVMはWB+1で構成されています、つまり、DFTMを利用してはいるものの、まだ1GbEのパイプをレプリケーショントラフィックが押し通る必要があります。以下のイメージはDFTMでWB+1構成を組んだ際の実効レイテンシを表示しています。
上のDFTMでWB+1モードでの様子を表したイメージはフラッシュから継承されたいくつかのオーバーヘッドがなくなっており、1GbEのリンク1本でレイテンシを4ミリ秒未満に抑えることに成功しています。繰り返しになりますが、256Kや512Kの巨大なI/Oが飛び交っています。10GbEになるとどうなるのかをとても知りたいのですが、残念ながら私の本稼働環境にはそれがありません。
では、DFTMをWB+0モードで動作させてみましょう。この構成ではピアリング用のトラフィックを送らない設定です。同じ時間軸でのレイテンシはどうなるでしょうか?
(仮想マシンから見た)実効レイテンシを表すブルーのラインが見えないとしたら、それはすべての計測時間軸において、0に近いところを推移しているからです。ローカルアクセラレーションは0.10ミリ秒、仮想マシンがもっとも激しいWriteを行っている際でもたったの0.33ミリ秒です。これは素晴らしい。
ここにもう一枚、DFTMで高速化されているVMをWB+1からWB+0に切り替えたイメージが有ります。レイテンシに何が起こったかを見ることができます。
上で示した高速化されたパフォーマンスがとても古いDell EqualLogic PS6000e上に置かれている仮想マシンからのものであることをご留意ください。14本の7,200 RPMのSATAドライブしか搭載されておらず、良くても700 IOPSしか出ません。
意図したものではありませんが、DFTMはレプリカトラフィックが予想以上に大きなレイテンシを示した際のトラブルシューティングに最適です。WB+1構成でのDFTMはフラッシュデバイスによって、もしくはコントローラによってもたらされているのかという可能性を否定し、ホスト上のNICもしくはスイッチである可能性に限定することができるのです。これは別のvSphereクラスタで有効であることを確認しました。
単純に言えば、DFTMは絶対的な強者です。フラッシュがうまくできなかったすべてのことをやってのけます。ストレージのバスもドライブのコントローラーもNANDのオーバーヘッドも避ける事ができますし、消耗することもありません。CPUの近くに存在し、これ以上の帯域幅を持つものは他にありません。しかし、間違わないでください。メモリは揮発性です。ノンパーシステントのVDIや短命なデータのみを扱う特別な例外を除き、DFTMの｢FT｣の良さを活用すべきです。1つもしくはそれ以上のピア接続を設定してください。少しばかりレイテンシに影響が出ますが、それでも優れたパフォーマンスはミッションクリティカルなワークロードに充分です。
FVPクラスタを構成する際に、現状では各ホストから同じタイプの高速化リソースしか選択できないように制限されています。ですので、もしもフラッシュがすでにサーバにインストールされており、いくつかの仮想マシンにだけRAMを使いたいとしたらどうすればよいでしょうか?...別のFVPクラスタを作りましょう。Frank Denneman氏の記事:FVPで複数のクラスタを利用 - RAMとフラッシュを同じvSphereクラスタで使う では同じvSphereクラスタ上の仮想マシンを別々の高速化リソースで利用する方法が記載されています。これらのヒントを利用して、組み上げた私のvSphereクラスタ内のFVPクラスタがこちらです。
Writeバッファとデステージングのメカニズム
改善された項目のリストには載っていない機能ですが、言及すべきポイントです。Storage Field Day 5において、Satyam Vaghani氏はデステージングメカニズムの改善について言及しています。PernixData社のメンバーに詳細の提供を求めました。しかし、仮想マシンがデステージャーのいくつかの制限に引っかかるケースは殆ど無いようです。殆ど無いとはいえ、私の環境ではこれが起こっています。今のところ、改善しているといえる状態です。
デステージングに関する可視性も向上されています。以前の1.0以前のベータ期間から、私はずっとデステージングバッファについての情報を見たいと思っていました。結局のところ、すべてのWriteはすぐに後ろの物理データストアへと送られます(詳しくはEffects of introducing write-back caching with PernixData FVP(訳注 :リンク先は英語、後日翻訳予定)をご参照ください)。これは設計に組み入れるべきです。FVP 2.0は2つのキーメトリックを提供します。デステージし無くてはならないWrite(MB単位)と、後ろのデータストアに書き込まれるまでの時間です。これによって後ろのデータストアが定常的なWriteに耐えられるか、そうでないのかを判断することができます。今のところ、現在のメカニズムでは私の好みの頻度でデータを取得出来ていないのですが、可視性が上がったという意味ではスタートは悪くありません。
誇るべき内容
NFSのサポートは素晴らしい改善点です。残念ながら私の本稼働環境にはありませんが、将来にわたってそれがないと言い切れるわけでもありません。ほとんどの組織では利用していますし、非常に好まれています。そして、古い家のラボでは好んで利用しています。もう一つ細かいことを言わせてください。嬉しい改善点の1つとして、8時間の時間幅でパフォーマンスデータを見ることができるようになりました。｢1日では長すぎるが、1時間では短すぎる｣ということわざの通りです。
結論
同じワークロードについて、ほとんどすべての機能を網羅してきました。私がお見せしたものは人工的なベンチマークワークロードではほとんど見ることはできません。FVP 2.0は実データ環境において非常に適切な改善がなされています。10GbEが理想的には推奨されていますが、調整型ネットワーク圧縮(Adaptive Network Compression)は従来からの1GbEのネットワークにおいては非常に｢買い｣です。DFTMは最高!
FVP 2.0の機能改善は素晴らしいものです。私のインフラストラクチャを入れ替えなくてもいいぐらいの素晴らしさです。実際の物理的なストレージを新しい観点で見ることができます。新しい大量のPCIeベースのフラッシュやRAMを搭載したコンピューティングノードは必要かもしれません。その場合でも後ろのストレージは容量的には、そしてちょっとしたデータサービスやちょっとした定常的なWriteのためのパフォーマンスの要件には十分答えてくれます。
ソフトウェア企業に務めるものとして、良いソフトウェアは｢出来上がる｣ことは無いということを知っています。ですが、FVP 2.0はPernixDataの顧客にとって素晴らしい躍進になるでしょう。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
