本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はReal World Data Reduction from Hybrid SSD + HDD Storageをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
オールフラッシュベンダーからそして、別のタイプのハイパーコンバージド(ストレージとサーバをハイパーバイザと1つのパッケージにした)ベンダーからも多くの話が出てきていますが、常に湧き上がる疑問はどのタイプのシステムがより多くのデータ削減を行うことが出来るのか、というものです。残念ながら、殆どの場合、例に上がるのは現実からある程度簡略化されたものばかりです。
ある人はオールフラッシュでなければデータ削減機能は意味が無いと言いますし、別の人はハードウェアカードがなければデータ削減機能は意味がないと言います、また別の方は従来型のSANが必要だと言うでしょう。様々な技術と様々な異なるシステムを組み合わせ、より良いデータ削減率を得ることも出来ます。じゃあ一体何が正しいと言うんだい?真実はデータ削減率は保存されているデータのタイプに大きく依存し、逆に、どのようにデータ削減を行うかにはさほど依存しないということです。既に圧縮されているイメージデータや暗号化されたデータベースシステムに対してはどうやったとしても非常に小さな削減効果しか得られません。重複排除が簡単なVDIのイメージのようなデータを保存しているのであれば、もしくはテキストのような圧縮可能なデータを保存しているのであれば、その効果は非常に良いものになります。
あるベンダーはこの数字を例えばスナップショットは重複排除される、であるとか、テンプレートから展開されたデータは重複排除される、など巧みに操作していますが、いずれも誤解を招くことになります。スナップショットを取るということはデータを削減することにはつながりません(そしてバックアップでもありません)、しかしながら、テンプレートからの展開をスマートなメタデータ操作で実行することはデータの削減になります、ですが、これは重複排除ではありません。重複排除は流入してくるデータが新しいパターンであるということが認識されて初めて適応されるもので、過去にすでにパターンがシステム内に保存されている際には必要が無いものなのです。重複排除は特定のタイプのアプリケーションでは非常に効果が高く、逆に他ではさほどでもありません。これは圧縮が特定のものにはうまくいくし、別のものではうまくいかないということと全く同じです。
もっとも最低の議論というのはオールフラッシュを使えば良いデータ削減率が得られる、であるとか、それがパフォーマンスに影響を及ぼすであるとか、であり、これはベンダーのプラットフォームの設計を理解していない場合には全くの間違いです。これを示すために、ハイブリッドのソフトウェア定義のシステムでSSDとHDDを搭載しているものでも優れたデータ削減率とパフォーマンスへの問題がないことをお見せいたしましょう。では実際のお客様のホンモノの環境の結果について見ていきます。
私がこれから共有するすべての結果は私自身、もしくは私のNutanixの同僚へと送られてきたものので、その環境はすべて標準のハイブリッドシステムのものであり、そのユースケースは様々に異なったものです。私はNutanixのデータしか持ち合わせていないので、結果はNutanixを利用した場合のものですが、他のシステムでも似たような結果が得られるか、その結果が異なる場合もあるでしょう。これは動作させているシステムが異なれば結果も様々だからです。
以下の結果はサーバーワークロードのもので、簡単に圧縮できるデータを多く保持している場合のものです。ですから、非常に良いデータ削減率を示しています:
このケースではデータはExchangeのJetStressテストを用いたものです。JetStressのデータは容易に圧縮ができるもの(メールデータ)ですから、圧縮にチューニングされたあらゆるシステムにおいて不適切な(以上に高い圧縮率)な結果を提示することになります。ですから、JetStressでテストを行う場合には圧縮をオフにするのが良いと思います。もしもストレージシステムが圧縮をオフに出来ないような場合には、実環境での結果を得ることはできません(JetStressの結果ではなく、実際の場合の結果です)。
次なる結果はOracle RACデータベースのものです。データベースはTPCCのようなトランザクショナルデータを格納しています。ですから、非常に良いデータ削減率を得られます。しかし、単なるテキストほどではありません。
次の例はVMware環境のための管理クラスタのものです。ここにはvCenter、vCenterデータベース、VMwareの管理ツール、Microsoft AD、DNS、そしてSQLサーバやPostgreSQLデータベースのような他のシステムのバックアップコピーがおかれています。
既に圧縮されているバイナリデータが多くあり、上記の結果となります。データ削減の効果としてはわずかです。
では、実際に本稼働しているExchangeシステムの環境ではどうでしょうか? ここにはExchange環境をNutanixで運用されているお客様の例を持ってきました。20,000以上のメールボックスの環境です。あらゆるタイプのメールデータが含まれています。
eメールのデータと言うものは環境によっては他の環境と全く異なるデータになりがちです。ここには別のeメールのサンプルがありますが、今回はEnronのEmailデータベースのデータになります。Enronは上場倒産をしてしまった会社で、その後、負のバランスシート遺産や借金を抱えていました。eメールデータベースは裁判所の処理のために公開されることになったのです。ですから、データ削減技術のためのテストにはまたとないデータです。
今回は圧縮を利用しています。圧縮はデータに共通部分が見つからないようなデータの場合には良い選択です。しかし、重複排除、圧縮、そしてイレイジャーコーディングのような他の削減技術を同時に利用して、できうる最高の削減率を得ることも出来ます。そもそもプラットフォームは実際のデータを下にして、最高の技術を提供すべきです。
VDI環境を含む特定のタイプのワークロードはフルクローンでも、リンククローンでもいずれの場合も重複排除から非常に良いデータ削減結果を得ることが出来ます。フルクローンの環境ではほとんどすべてのデータを重複排除できるため、重複排除で最高の削減結果を得ることが出来ます。重複排除と圧縮の療法を使って、可能な限りのデータの削減を行うことも出来ます。しかし、ここでは2つのVDI環境の例を挙げましょう。
上の2つの例は2つの異なるVDI環境で少しだけ異なるワークロードを動作させた結果の例です。しかし、圧縮と重複排除の技術の組み合わせによって、非常に大きな削減を実現していることがわかります。ですが、これらの環境は殆どがリンククローンの環境です。フルクローンのデスクトップではないのです。以下にフルクローンのVDIの環境における重複排除でのデータ削減の結果を示します:
見て明らかな通り、別々のワークロードのデータでの共通事項がほとんどであれば、極端なほどのデータ削減率を期待することが出来、こうしたワークロードのための物理的なスペースは非常に小さくて済むのです。
今までのところ、さほど異なるタイプのワークロードをのみしかカバーできていませんし、比較的小さな規模のものです。では、大きな環境へとスケールアップして、更にエンタープライズで利用されるようなタイプのワークロードになるとどうでしょうか?
上のイメージは10ホスト、70台の大きい仮想マシンを運用しているやや大きな環境からのもので、大きなIOを多く行っています。この例では、削減されたデータサイズは175TBです。ですが、私はこれ以上の値も実現出来ると考えています。さぁ、もうちょっとだけ大きな本か同環境を見ていきましょう。
上の例はSQLサーバとアーカイブデータを含む混在ワークロード環境となっている大きなNutanixからの例です。今回は全体としてのデータ削減は570TBです。
上の2つのサンプルはそれぞれ32ノードのNutanixからなる2つのクラスタの例です。ワークロードは一般的なサーバ仮想化で、一方はマイクロソフトのアプリケーション、もう一方ではLinuxベースのアプリケーションが動作しています。
上の例はLenovo HXアプライアンスで動作している4台のオールフラッシュノードからなるクラスタものです。データはOracleとSQLサーバデータベース、それから僅かなVDIデスクトップの混在環境です。
上のイメージは26ノードのハイブリッドクラスタで様々なノードが混在しており、20TB以上のデータベースと他のアプリケーションがまたがったものです。
終わりに
オールフラッシュはデータ削減に必要不可欠なものではありません。上で見てきたように、大きなデータ削減とそれなりのパフォーマンスを得るためにオールフラッシュを使う必要はないのです。ハイブリッドストレージ環境でも優れた削減効果を得ることが出来ますし、オールフラッシュにしたいということであれば、そこでも同じような優れたデータ削減効果を得ることが出来ます。ですが、ハイブリッド化、オールフラッシュか、という事を決めるのはあなた自身です。いずれのタイプの環境でも同じ削減効果を得ることが出来ます。理由はこれは保存されているデータそのもので決まるからです。
特殊なハードウェアを用いなければ優れた削減効果とパフォーマンスを彫らないとうこともありません。上のすべての結果はソフトウェアのみで得られる結果で、特殊なハードウェアは必要としません。パフォーマンスと削減効果はデータのタイプに依存します。パブリッククラウドは特殊なハードウェアには依存しません、どうしてプライベートクラウドでだけ、それが必要なのでしょうか?
データ削減結果をきめるもっとも大きな要素は保存されているデータのタイプです。もちろん、データ削減の技術はベンダー毎に異なります、ですが、もっともデータ削減効果を決める最も大きな要素は保存されているデータのタイプです。スナップショットを利用してそうでもないのにそれを重複排除であると呼ぶようなおかしな比較はスルーして下さい。暗号化されたデータ、画像のような既に圧縮されているデータのような上手く削減ができないデータのタイプであればとても貧相な結果になってしまいます。同じOSや同じアプリケーション、ドキュメントとして保存されているデータ、テキストやデータベースのようなテキストタイプの削減のよく効くデータでは非常に優れた結果を得ることが出来ます。この結果から、システムは複数のデータ削減施術を利用できるということが重要な事になります。これによって実際に存在するデータに対して最高の削減効果を得ることが出来るからです。
圧縮が有効になっている場合、幾つかのベンチマークテストでは正しい結果が得られない場合があります。圧縮や重複排除をオフにすることが出来ないシステムの場合、Exchange JetStressのようなタイプのベンチマークテストでは正しい結果を得ることが出来ません。これはこうした結果を本稼働環境を選定する際には利用ができないということです。
スナップショットとクローンは上の結果には含めていません!スナップショットとクローンはメタデータ操作のみを利用し、データを増加させることはありません、ですから、データ削減の結果には含めておらず、Nutanixのプラットフォームではレポートしません。こうした操作では新しいデータを新しいWriteを受信するまではストレージの利用を増やすことはありません。ですから、いくらでもクローンやスナップショットを好きなだけ作ることが出来ますし、利用可能なストレージ容量に影響はありません。他のベンダーはデータ削減にこうしたデータを含めるという選択をしていることが有ります、しかしNutanixは実際のデータパターンに対しての現実の圧縮またはデータ重複排除の結果のみをレポートしています。
これらを全て加味してみてください。データ削減は保存しているデータ以外の何物にも依存しません。これによってご自身の環境での結果は様々になります。現実環境のデータと現実のワークロードで事前に検証をしてみる事をオススメ致します。そうでなければご自身の環境、ワークロードでの実際の削減効果を知ることは出来ません。記事内で匿名でイメージを送ってくださり、記事内での利用を許可してくださったお客様に大変感謝致します。
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
本記事は実は、これから翻訳しようとしている記事からも引用されているのと、いよいよオールフラッシュの時代が到来しようとしている今だからこそ、読んでいただきたい内容です。オールフラッシュだから｢重複排除や圧縮をやってもパフォーマンス的にOK!｣という理論はこれは一見その通りに見えるのですが、実は非常に危険な誤解をはらんでいます。
上で述べられているとおり、削減効果はデータ次第なのですから、｢オールフラッシュだから｣というのはまったくもってナンセンスなのです。仮想マシンのためのIO(フロントエンド)さえ処理できてしまえば、後から遅延実行可能な重複排除や圧縮をおこなえますし、遅延実行しなくてはならないタスクが増えてきた場合でも、Nutanixのような分散アーキテクチャであれば、忙しいノードとは別のノードがその処理を行えばよいのです。(RF-2で冗長化している場合でも、データは仮想マシンが稼働しているホスト以外のノードにも必ず存在しますので、フロントエンド処理とバックエンド処理を分散できます。)
オールフラッシュなら重複排除や圧縮も可能! というのは何でもかんでも単一筐体の中で処理をしている従来型SANの理論で、逆を返すとオールフラッシュでないと重複排除や圧縮が間に合わない、ということになります。
どうでしょう? 実は、この話はPernixDataのストレージの｢パフォーマンス｣と｢キャパシティ｣と｢データサービス｣を分離すべきであるという思想と完全に一致します。しばらくオールフラッシュ系の翻訳を続けます。次回も乞うご期待!
