本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。
原文を参照したい方はWhat is the performance impact & overheads of Inline Compression on Nutanix?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
よくNutanixのデータ削減機能、例えば重複排除、イレイジャーコーディング、そして圧縮などについて聞かれることがよくありますが、もっとも（そして、特に競合している状況において）よく聞かれるご質問の一つは：
「Nutanixのインライン圧縮のパフォーマンスへの影響とオーバーヘッドは？」
と言うものです。短い回答をすれば、私がNutanixプラットフォームに関して、覚えている限りではメリットがデメリットを上回ります、ということになります。
過去に様々なアプリケーション、ノードの種類、クラスタのサイズそして構成を検証してきました。そしてNutanix（と私）がOracleやMS SQL、そしてMS Exchangeなどのビジネスクリティカルアプリケーションを含む殆どの環境においてインライン圧縮のオーバーヘッドとパフォーマンスへの影響について共有しておくほうが良いと思い当たりました。
今回、MS Exchangeのためのストレージパフォーマンスの検証にはJetstressを利用しています。
（競合によるFUDを避けるため）特段環境に追加の設定を施すことなく、検証はシンプルに行われています。Windows 2012の仮想マシンを1台とJetstressの構成を行いました。そして、3 回、15分で完了するデータベースのチェックサムを取る動作を実施しました。
その3回の検証のあと、インライン圧縮を有効にし、同じテストを3回繰り返しました。
以下の図はNutanix PRISM HTML 5 ユーザーインターフェースがクラスタ全体のIOPS、レイテンシ、そしてスループットをコントローラー仮想マシンのCPU利用率とともに表示したもののスクリーンショットです。
見ていただいて分かる通り、6つのテストでのパフォーマンスはCVMのCPU利用率を含め、ほとんど同じです。以下のテーブルはそれぞれのテストでのMS ExchangeのJetstress検証における2つのキー要素であるデータベースのReadのレイテンシとログのWriteのレイテンシを含めたものです。
注意 : 上記の数字はNutanixが提供できるピークでも最高の性能でもありません、単に私が走らせた多くの検証シナリオの中の一つに過ぎません。
圧縮なしとインライン圧縮の間の際はほとんどゼロだとわかります。この検証はインラインデータ削減にはI/Oパスにおけるオーバーヘッドがつきものだとみんなが知っているとおりですが、それがアプリケーションのパフォーマンスの低下に影響を与えるというほど重要ではないということを表しています。
今回の場合、Nutanixのインライン圧縮は非常に効率的で、MS Exchangeのようなアプリケーションにおいては素晴らしいデータ効率化を利用しながら、その実、パフォーマンスやCVM上のCPUの追加オーバーヘッドは殆ど無いということです。
おっと、今回、すべてのパフォーマンスはAcropolis Hypervisor(AHV)のものです！
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
今回はインライン圧縮についての記事です。いろいろな会社がインライン圧縮をいかに効率的に行うか、パフォーマンスへの影響がない理由はどうしたアーキテクチャだからだ、という話をお話していますが、Nutanixの実装はこちらをご参照ください。Nutanixのインライン圧縮(Delayなし)では大きな(64K以上)シーケンシャルなWriteデータのみを圧縮し、ランダムWriteは圧縮を行いません(AOS 5.0以降は4K以上のブロックのみ圧縮)。ネットワーク越しにWriteを冗長化する必要が有るため、インライン圧縮を行ったほうがデータを高速に転送できるデータのみを圧縮し、そうでないものはそのままデータを圧縮せずに転送します。とすると、全然データが圧縮されないんじゃないか？という不安が出てくるかもしれませんが、残りのデータの圧縮はあとから(Delayで)実施され、データ永続領域へ書き出される際に実施されます(AOS 5.0では4Kを展開し、64K単位で再圧縮)。
つまりI/Oパスには影響のないところで実施されるので、パフォーマンスへ影響を心配することなく利用できるということになります。このあたり、現在は4Kや64Kという固定長での実施のようですが、買収した会社の特許などを見ていると更にいろんなチューニングが今後出てくる可能性があると思います！
