本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はWhat’s new in PernixData FVP 2.0 – Adaptive network compressionで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
FVPは高速な2点間通信であるクロスバーアーキテクチャのネットワークに依存しています。我々はいくつかの場合において、ネットワークのパフォーマンスがストレージのパフォーマンスへ影響を与える場合があることに気が付きました。これはWrite-Backで多くの仮想マシンが2つのレプリカを生成している場合などに顕著です。特に1Gのネットワークは多くのレプリケーショントラフィックが生成している場合にこのようなことに陥りやすくなります。
この表はPete Koehler氏(vmpete.com)からもらったものですが、まさにこの症状を表しています。左では仮想マシンはフラッシュデバイスの能力を活用しています。アプリケーションは5000 IOPS以上のワークロードを生成しており、フラッシュデバイス(オレンジの折れ線)はアプリケーションに喜んでストレージのパフォーマンスを提供しています。そこで、耐障害性を有効にしました。リモートフラッシュデバイスへ書き込むためのネットワークがボトルネックになることが有ります。グリーンの折れ線はネットワークパフォーマンスですが、オレンジ(フラッシュ)の折れ線を上書きしてしまっており、IOパフォーマンスに影響を与えてしまっています。
調整型ネットワーク圧縮(Adaptive Network Compression)の登場
我々が成し得たいのはストレージからネットワークにボトルネックが移動しないようにすることです。そこで我々はネットワーク圧縮を開発しました。リモートフラッシュデバイスへ書き込みの冗長化データを送信する前に圧縮する機能です。FVPは圧縮しない大きなブロックを送る場合と、圧縮によるレイテンシの低下を比較することで最低限の帯域のみを使うようになっています。
圧縮がCPUのコストになることがすぐに思い出されることでしょう。データを圧縮するためのCPUのコストとピア側でのデータの展開のためのCPUのコストがあります。さて、CPUのコストとネットワーク帯域のコスト、どちらがパフォーマンスの劣化につながるか、考えてみましょう。このグラフはFVPの調整型ネットワーク圧縮(Adaptive Network Compresssion)のりようによる圧縮のCPUコストを表しています。見て頂いて分かる通りCPUのコストは最小限です。これはCPUのコストがない中で、ネットワーク帯域を節約できるということで、とても素晴らしいことです。
ブルーの折れ線はWrite-Backをレプリケーション無しで実行している仮想マシンのCPUコストです。オレンジの折れ線は圧縮が有効になっている仮想マシンのCPUコストです。見ていただいたとおり、ブルーとオレンジの折れ線は非常に近い値を示しており、CPUのコストが殆ど無いことを表しています。
ソースホストのCPU負荷を可能な限り低く保つためには調整型のアルゴリズムを利用し、コストとメリットを計測しています。調整型ネットワーク圧縮はデータが圧縮されることと、圧縮のためのコストが帯域の節約以上にならないことを保証します。面白いことに、小さなブロックを圧縮するとサイズが大きくなることが有ります、そういうこともあるのですべてのデータのビットを確認して仮想化データセンタにとってその圧縮が意味があるかを確認しているのです。
もう一つ興味深い点はリモートフラッシュデバイスへ書き込まれたデータは展開しないでおくということです。これは2つの面でメリットが有ります。CPUのオーバーヘッドが気にならないという点と、リモートフラッシュへのフットプリントを削減できるという点です。圧縮した状態のままにしておくという理由はとても単純です。大抵の場合環境はうまく稼働しています、ほとんどの場合、環境は起動して正常に動作しているということです。障害はさほど頻繁に起こるわけではありません。障害が起きて、初めてピアホストが書き込みデータをストレージアレイに書き込むタスクが回ってて、展開のためのCPUコストが初めて生まれます。通常の運用中は、書き込みの冗長化データが圧縮状態でフラッシュデバイスに届き、データがストレージアレイに書き込まれるとフラッシュデバイスから押し出されていきます。この手順はピアホスト側では最小限になるべきで、そのために圧縮されたままになっているのです。
この上の表は1GbEの接続を利用してのレプリケーションを開始前と、後の様子を表しています。左側は平均2700 IOPSのパフォーマンスが出ていますが、レプリケーションが始まるとパフォーマンスは毎秒 1700 書き込みにまで低下しています。平坦な線がボトルネックがネットワークの制限からくるものであることを完全に示しています。同じワークロードを10GbEのネットワークで走らせると、ネットワークは十分なスピードと帯域を提供していることがわかります。
同じワークロード検証を1GbEのネットワークと圧縮を有効にして行ってみました。圧縮によってパフォーマンスはフラッシュだけのパフォーマンスとほぼ同等になっています。
調整型ネットワーク圧縮のメリットを診てもらうために、エンジニアはこの機能を無効、有効にしています。調整型ネットワーク圧縮はFVP 2.0では1GbEネットワーク接続を検出した場合に自動的に有効になります。ユーザーの操作は必要ありません、それどころか、有効/無効にするU.I.やPowershellオプションなども提供されません。調整型は自然に最小限のオーバーヘッドで最高のパフォーマンスを提供するのです。
役立つ情報としてFVPクラスタのサマリ内に、英雄の数字(ヒーローナンバー)があります。個々にストレージアレイから節約されたデータや、ストレージエリアネットワークから節約された帯域などが表示されます。そしてFVP 2.0からは調整型ネットワーク圧縮によって節約された帯域も確認することができるようになります。このスクリーンショットを作るために、私はFVPのネットワーク構成を10GbEのネットワークから1GbEのネットワークに変えなくてはなりませんでした。FVPではこの変更はホストや仮想マシンの稼働に全く影響を与えずに実行可能です。そして1GbE全体を超える負荷を与える検証を行いました。実際に1GbEのネットワークを使っている場合には、実アプリケーションは非常に感動的な数字を示すことでしょう。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
