みなさん、こんにちわ。本記事は前回の｢実況中継!? VSAN 6.2 中の人によるふかーい話 (容量効率化編)｣の続編にあたります。
本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。
実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる～い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。
検証環境
今回の検証結果は全てこの4台のクラスタにおける結果を利用しています。
パフォーマンスの劣化はありません。
6.1から6.2になりましたが、チェックサムの機能を有効にしてもパフォーマンスの劣化はありません。6.2で一部のデータパスを最適化したため、むしろレイテンシが良くなっている場合もあります。
新しいデータサービスによるパフォーマンスへの影響は?
容量効率化の機能はどのようにパフォーマンスへ影響するかです。レイテンシやIOPSはもちろん、CPUの利用率も見ていきます。統合率への影響がもっとも重要ですからね。
サマリとしては以下のことがいえます :
重複排除によってTCOを劇的に削減しながら･･･
- 高いIOPSと低レイテンシーを維持している
- CPUのオーバヘッドを最小限に保っている(オンデマンドでのみ利用する)
- 重複排除は非常に効率的である
ではVDIのケースを見ていきましょう
6.1はベースラインです。6.2はチェックサム機能が追加されています。6.2+R5はイレイジャーコーディングを利用し、6.2+Dは重複排除と圧縮を有効にしています。そしてすべての機能をOnにした場合の値も表示しています。
グラフは短いほうがパフォーマンスが良いということです。これはレイテンシを表示しており、実際のユーザーが体感した時間を表しています。View Plannerを利用していますのでファイルを保存したり、なにか書き込んだりということをやっています。グループA(青い棒グラフ)はさほどI/Oを利用しない作業を行っている想定です。こちらではほとんど差がでません。もっとI/Oを利用するグループBにおいては4.3秒だったレイテンシが5.1秒までしか上昇していません。すべての機能がOnになってですよ!!
さて、これはCPUにどのような影響を及ぼしているでしょうか?
VDIの場合、サーバには詰め込める限りの数の仮想マシンを詰め込みます。今回の場合、1ホストあたり145台の仮想マシンが動作しています。青の棒グラフはホスト全体のCPUの利用率を表しています。見ての通りほぼ全てを使いきっています。
そしてVSAN 6.1ではわずか0.5%のCPUを利用しているに過ぎません。チェックサムやそれ以外の6.2の機能を全て利用してもこの値は1.4%程度になるだけです。
会場から: ほとんど3倍になっているじゃないか!!(笑)
重要なのはVDIを利用する際に(他のソリューションのように)サーバの能力のうち4分の1を割り当てるなどする必要はないということです。仮想マシンの統合率に全く影響がないというのは重要な事です。
これには私もびっくりでした!
こんなにも効果があると思っていなかったのでテストを3回もやらせたぐらいです。これはリンククローンでの結果です。145台の4倍の数の仮想マシンが動作しています。この青い棒グラフは物理的な容量を表しています。
重複排除は非常に有効です。そしてRAID-5でもう少し効率化がなされます。面白いことにベースディスクが1つで後はデルタ(差分)なのですが、デルタ内に多くの重複があるということです。
会場より : パッチの火曜日の後は、すごいだろうね。
もちろんです、それから今回はView Plannerを利用していますので各々の仮想マシン内では同じようなデータの更新が行われているという点もあると思います。
こういうデータを出してしまうと過剰に反応してしまう人もいますし、業界はこうした結果であふれています。実際にはコミュニティの紡ぎだした数字を使うのが良いでしょう。
中編に続きます。次回はトランザクショナルなワークロードについてのパフォーマンスについての内容です。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
