株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

VMwareさん、ご冗談でしょう?(FUDだ!) : Nutanix CVM/AHV と vSphere/VSANのオーバーヘッド

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はVMware you’re full of it (FUD) : Nutanix CVM/AHV & vSphere/VSAN overheadsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

訳注: 少々刺激的な表現が多用されますが、原文はもっと酷いです(笑) 真実は人と立場によって異なります。決して何かを煽るつもりもありませんし、そうならないように(特にインカーネルストレージIOパスPVSCSI)技術的な裏取りの記事をいくつも翻訳してきました。ぜひ、合わせてこの壮絶な宗教(?)争いの結果に生まれたとんでもない記事をお楽しみください。

長きに渡って、VMwareとEMCは他のベンダーとともにNutanixのコントローラーVM(CVM)についてのFUD(訳注:ネガティブキャンペーンFear-恐れ、Uncertainty-不安、Doubt-疑念を煽るような競合に対するマーケティング戦略のこと)を流し続けてきました。すなわち、CVMはI/Oを行うために多くのリソースを利用する、ですから仮想マシン(つまり、仮想化ストレージアプライアンス/VSA)はインカーネルで動作するのよりも効率が悪く、遅いと。

最近のFUDの例を挙げると、VCEの社長、Chad Sakac氏自らが書いた記事があるので引用します。

それ(VxRail)は完全に統合されたSDSスタックをカーネルに埋め込んだ唯一のHCIA(ハイパーコンバージドインフラストラクチャアプライアンス)です。VSANを利用するためにVxRailはvSphereを利用します。8vCPU、16GB以上のメモリをストレージスタックに利用するようなおかしなことはしません(これは他のHCIAを選んだ場合の「ストレージコントローラ」毎の値、もしくはノードあたりの値ですよ!)。

ですから、私は過去に書き連ねてきたNutanix CVMの提供する機能と、Chad氏のいう完全にSDSが統合されたスタックを並べて比較の記事を書いてみました。

さぁ、Acropolis分散ストレージファブリック(ADFS)とAcropolisハイパーバイザ(AHV)からなるNutanix Suiteに必要とされるリソースと、VMware社のvCenter、ESXi、VSANそして関連コンポーネントからなるVMwareのSuiteに必要とされるリソースの比較をしていきましょう。

こうすることで、Nutanixのプラットフォームをあまりご存知でない方がその機能とCVMが提供する価値を理解する事もできますし、様々な競合他社によって流されているFUDは正しくはどういうものかという事を理解することも出来ます。

初める前に、Nutanix CVMの標準のサイズを確認しておきましょう。

本日の時点ではCVMは標準で8vCPU、16GBのメモリを利用します。

CPUリソースについては当たり前のことですが、お客様のユースケースによって異なります。もしもI/O要件が低い場合には、CVMは8vCPUどころか、4vCPUも利用することはありません、ですが8vCPUが割り当てられています。

何年もの間に渡ってESXiのCPUスケジューリングは改善され、必要以上のvCPUを環境内の限られた数の仮想マシン(例えばCVM)に割り当てるという影響は無視できるほどになっています。でうが、CVMはしっかりとサイジングされているべきだということも常識です。

メモリの割当は重複排除を利用する場合には24GBが推奨です、そしてワークロードが大きくReadに偏っているような場合、メモリを増やすことで更に大きなReadキャッシュとして利用できます。

しかし、CVMのメモリをReadキャッシュ(拡張キャッシュ)として増やすのは今では昔の推奨事項とされています。これはAcropolisオペレーティングシステム(AOS)4.6のリリースでReadキャッシュを有効にしなくても優れたパフォーマンスが出るような改善がなされたからです。

実際のところ、AOS 4.6において4KのランダムのReadで 150K(15万)IOPS以上を記録したNX-9040-G4のノードはインメモリReadキャッシュを利用せずに開発チームがSSDの性能がどのぐらいのものなのかを示すために行ったテストでのものです。結果として、極端なほどのパフォーマンスであってもCVMのメモリをReadキャッシュとして増やすということはもはや必要ありません。ですから殆どのワークロードでは24GBのメモリで充分であり、メモリの要件を減らすということも可能なのです。

考察 : インカーネルのソリューションが優れたストレージパフォーマンスを提供できるということが事実であったとしても(今回はそういう話はしませんが)、これは全体からするととても小さな部分にしか過ぎません。管理についてはどうですか? VSANの管理はvSphere Web Client経由で行われますが、その仮想マシンはユーザースペース(空間)で動作しています(つまり、「インカーネル」ではない)し、更に同じくユーザー空間で動作している仮想マシンで動作しているvCenterに接続を行います、さらにvCenterはSQLOracleデータベースを利用しており、これもユーザー空間で動作しています。

さて、続いてレプリケーションについて見ていきましょう。VSANはvSphere Replicationを利用します、これもご承知のとおり、ユーザー空間で動作している仮想マシンで動作します。キャパシティ/パフォーマンス管理において、VSANはvRealize Operations Manager(vROM)を利用しており、これもユーザースペースで動作しています。バックアップは? vSphere Data Protectionアプライアンスはこれもまた、ユーザー空間で動作している仮想マシン上のサービスです。

これらの全ての製品はデータをカーネル空間からユーザー空間へと取り出す必要があります。現時点では仮想マシンの基本的なI/Oを除くとすべての機能でVSANはユーザー空間で動作しているコンポーネントに依存していることになります(つまり、インカーネルではない)。

さぁ、VSAN自身の要件を見ていきましょう。

VSAN design and sizing guide(ページ56)によるとVSANはVSANのすべての機能を利用する場合には最大でホストのCPUの10%までと32GBのメモリを必要とすると有ります。もちろん、VSANが32GB全てを利用するということではなく、必要でなければNutanixのCVMが割り当てられたメモリを全て利用するということはないということと同じです。ですが、Nutanixでは最低推奨サイズの12GBまで減らすことができますし、16GBが今日では小さい方だと言わざるをえない192GBのメモリを搭載したノードにおいても標準的です。16GBというのはVSANであってもNutanixのCVMであっても10%未満で最小限のオーバーヘッドと言えるでしょう。

私が検証した結果によるとVSANのCPU利用率のオーバーヘッドは10%に制限されているようではないようです。これはVMware社自身が行ったSQLでの検証「VMware Virtual SAN™ Performance with Microsoft SQL Server」で確認が可能です。

かいつまんで説明をすると、検証は4vCPUで構成された3つの仮想マシンで実施され、デュアルソケットのIntel Xeon プロセッサE5-2650 v2(16コア、32スレッド@2.6GHz)を搭載したホストで動作しています。

仮想マシンが100%の利用率だと仮定しても、コア全体の75%(16のうちの12)しか利用しないはずです。ですから、以下のグラフを見ると仮想マシン以外の何者かがCPUを利用しているということがわかります。最低でもハイパーバイザが5%を利用するとして、VSANは20%ほどのCPUを利用していることになります。実際には仮想マシンは100%の利用率になることはありませんので、VSANは20%よりも多くオーバーヘッドがある事になります。

Fig032さて、I/OのためのCPU要件はわかりました。VSANが20%かそれよりも多くCPUを利用するとしても別段問題はありません。問題だと思うのはVMwareがお客様に10%しか利用しないというご案内をして、更にNutanixのような仮想アプライアンスを利用する他の仮想アプライアンスベンダーはリソースの大食漢だというFUDを撒き散らしていることです。

私の言葉をそのまま信じるのではなく、ご自身で検証したり、上で挙げられているようなドキュメントを読んでみてください。簡単な算数だけで、最大10%と言うのは神話であるということがわかると思います。

ここから、大体4vCPU(大抵のデュアルソケットの8コアのシステム上で)と最大で32GBのメモリがVSANに必要になるということがわかります。ですが、今回は平均的に16GBということにしておきましょう。殆どのシステムはディスクグループが5以上になることはありません。

上での検証は最新のVSAN 6.2でのものではありません。ですから、これは今では変わっている可能性があります。こうしたVSANの変更の中にソフトウェアのチェックサムがあります。これは実際にパフォーマンスを劣化させます(皆さんのご想像の通り)、というのもこの機能は全てのI/Oについてのデータの一貫性を提供するものであるため、上で述べてきたパフォーマンスの比較をNutanixと行うという意味ではこれを加えるほうがフェアになります。というのも、本稼働系のストレージソリューションとしてこの機能は必須の機能なため、Nutanixは常にソフトウェアでチェックサムを取得しているからです。

そして、思い出してください、VSANはストレージスタックの部分しか提供していないのです。ですから20%までのCPUの高負荷は単なるストレージスタックだけからのものです。NutanixのCVMではそれに加えて高可用性をもつ管理レイヤーも提供しており、比較をするのであれば(殆どの場合、それ以上の機能、可用性、拡張性を提供していますが)vCenter、VUM、vROM、vSphere Replication、vSphere Data Protection、vSphere Web Client、Platform Services Controller(PSC)そしてそれを支えるデータベースプラットフォーム(SQL/Oracle/Postgres)までをも提供しています。

ですから、VSANのCPU利用率とNutanixのCVMを正味で比較というのとは程遠いわけです。正味の比較を行うために、全てのvSphereの管理コンポーネントのリソース要件を見て、平等な比較を行いましょう。

vCenter Server

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 24GB | 32GB RAM

参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

Platform Services Controller

リソース要件:

2vCPUs
2GB RAM
参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

vCenter Heartbeat (今では非推奨)

もしも正味で比較しようとするとvCenterに完全な分散と高可用性が必要になりますが、これは出来ません。vCenter Heatbeatは今では非推奨ですが、何かしらを加えなければなりません。vCenterやVUMなどのリソースを2倍することになるでしょう。非推奨ということですし、今回はVMwareさんの仰るとおり、管理コンポーネントの高可用性のためのリソースを勘定に入れないことにします。

vCenterのリンクモードについては?

これに関するドキュメントを見つけることは出来ませんでした。ですからVMwareさんのおっしゃるとおり、オーバーヘッドは一切ないということで行きたいと思います。ですが、オーバーヘッドはさておき、別製品としてインストール、検証、維持管理しなくてはなりません。

vSphere Web Client

完全なVSANの管理、昨日を利用するためにはWeb Clientが必要になりますが、これはそれ自身のリソース要件があります:

4vCPUs

2GB RAM (最低要件)
参照:https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.install.doc_50/GUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html

vSphere Update Manager (VUM)

VUMはvCenterサーバ上にインストールすることも出来ます(これはWindowsへのインストールを行っている場合)、これは管理仮想マシンやOSの管理の削減になりますが、もしも仮想アプライアンス版を利用している場合には別のWindowsインスタンスが必要となります。

リソース要件:

2vCPUs
2GB

NutanixのCVMはメジャー、マイナーのAHVはもちろんのことESXiのパッチアップデートの機能を有しています。

vRealize Operations Manager (vROM)

NutanixはPRISM Element内にvROMが提供しているような分析の機能を組み込みで提供しており、キャパシティ計画/管理を一元的に行うことが出来、「what if」シナリオによってノードのクラスタへの追加の機能を提供しています。ですから、正味で比較するためにはvROMを加えて比較するのが正しいと思います。

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 32GB | 48GB
14GB ストレージ

リモートコレクタ Standard | Large

2vCPUs | 4vCPUs

4GB | 16GB
参照:https://pubs.vmware.com/vrealizeoperationsmanager-62/index.jsp#com.vmware.vcom.core.doc/GUID-071E3259-625A-437B-AB34-E6A58B87C65B.html

vSphere Data protection

Nutanixは組み込みのバックアップ/リカバリ/スナップショットの機能をVSSによるアプリケーションとの整合性をもって提供しています。vROMと同様にNutanixのCVMとの比較にはvSphere Dta Protectionを加えるべきです。

vSphere Data Protectionは以下の様に0.5TBから8TBにて展開されます:

Fig033

参照: http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vmware-data-protection-administration-guide-61.pdf

最小で4vCPUと4GBのメモリを利用しますが、それでは0.5TBしかサポートされません。平均的な4TBを利用しようとすると4vCPUと8GBのメモリが必要になります。

VDPアプライアンス1台あたりではもっとも良くても8TBであり、これはNutanixの(もしくはVSAN Ready)ノードの幾つかよりも小さい値です(例 : NX6035/NX8035/NX8150)。ですからVSANを利用している場合にはVDPアプライアンスを各ノードに一つずつ展開するという可能性も出てきます。これはNutanixのようにVSANにはバックアップの機能が組み込まれていないからです。

さて仮想マシンレプリケーションをしたい場合や、Site Recovery Manager(SRM)を利用したいという場合はどうなるでしょうか?

vSphere Replication

vROMとvSphere Data Protectionと同じようにvSphere RepliactionはVSANにNutanixではCVMに組み込まれている機能を提供します。正味の比較のためにはvSphere Replicationも含める必要があります。

vSphere Replicationのリソース要件はかなり軽いものでは有りますが、もしも全てのレプリケーションがこのアプライアンス経由になるとするとそのVSANノードはストレージとネットワークのトラフィックホットスポットになり、ネットワークとノードを逼迫させたり、ノード上のすべての仮想マシンにとってのノイジーネイバー(やかましいご近所さん)になってしまう可能性もあります。

リソース要件:

2vCPUs
4GB RAM
14GB Storage
制限:

vCenterあたり1つのvSphere replicationアプライアンス
2000仮想マシンが上限
参照: http://pubs.vmware.com/vsphere-replication-61/index.jsp?topic=%2Fcom.vmware.vsphere.replication-admin.doc%2FGUID-E114BAB8-F423-45D4-B029-91A5D551AC47.html

ですから2000仮想マシンを超えて拡張しようとした場合、別のvCenterが必要になり、それはまた、別のVUM、Heatbeat(もしもまだあったとしたら)、そして更にSQLOracle上の別のデータベースが必要ということになります。

Nutanixはこうした制限はありませんが、VMwareがおっしゃる通りでの比較にしたいと思います。

サポートするデータベース

小さなSQLサーバであったとしても大抵は最低2vCPUと8GB以上のメモリになり、完全な正味の比較をしようとするとバックエンドのデータベースサーバもNutanix AHV/CVMがそうであるように高可用性のサポートを加味しなくてはなりません。

ですから、小さな環境であったとしても2vCPUと8GB以上のメモリの仮想マシンが2つ必要で、それは単にvCenter、VUM、SRMなどのバックエンドのデータベースの要件だけです。

環境が大きくなるにつれ、vCPU/vRAMとしてストレージ(キャパシティやIOPS)要件も大きくなることを覚えておいてください。

さて、VSANの小さな4ノードのクラスタのオーバーヘッドとして何が適切か?

以下のテーブルは上で述べてきたそれぞれのコンポーネントの最低要件を元にVSAN(完全に等価ではありませんが)とNutanix CVMの提供している機能を比較したものです。

Fig034

上は小さな、例えば4ノードの環境での最低要件しか採用していません。vSphere Data Protectionは複数インスタンス必要になるでしょうし、SQLは高可用性を実現するために常時稼働可用性グループ(AAG-always on availability Group)を利用しすべきで、2つ目のSQLサーバが必要になります。そして環境が大きくなればvCenter、vRealize Operations Manager、SQLのvCPU/vRAM要件も高くなります。

一方でNutanix AHV環境は以下のようになります:

Fig035

結果として4ノードクラスタのための32vCPUと64GBのメモリという値はvSphere/VSANの4ノードのソリューションに比べて8vCPUそして54GBも少ないということになります。

もしNutanixのスケールアウトファイルサーバ機能(オプションで有効にできます)を加えたとしても値は48vCPUと100GBのメモリで、vSphere/VSANと比べてvCPUが8つ多くなりますが、メモリは18GB少ないことになり、それでもNutanixはそれ以上の機能(例えばスケールアウトファイルサービス)を提供していますし、箱から取り出してたままで完全に分散された、高可用性のある、完全に統合された管理スタックを備えています。

NutanixのvCPUの数はすべてのvCPUを利用することを前提で数えており、これは殆どの場合起こりえません。ですからこの比較はNutanixと比べVSANを利用している際にvSphere/VSANに高いオーバーヘッドがあるということと、Nutanixは組み込まれた機能、例えばスケールアウトファイルサーバ(これもまた分散された高可用性のあるソリューションです)などの追加機能を提供しており、vSphere/VSANよりもちょっと多くのリソースを利用するだけで、vSphere/VSANの提供していないファイルサービス機能が利用できるということを上手く顕しています。

もし、こうしたvSphere/VSANのすべての機能を利用せず、つまりこれらの管理仮想マシンを展開しないとしたら、VSANのオーバーヘッドは低いというのは正しいのか?

すべてのvSphere/VSANの機能を利用しないので、展開する必要がないという議論もあると思います。それではそれによってvSphere/VSANの要件(やオーバーヘッド)は小さくなるのでしょうか?

同じ仮定はNutanixのコントローラVMについても同様のことが言えます。

お客様がすべての機能を利用する必要がなく、I/O要件も軽いという場合にはCVMを6vCPUにダウンサイズするということも少なくありません。私自身、今週とあるSQL/Exchangeを動作させているお客様でこれを実施しました。インライン圧縮を行いながら、ビジネスクリティカルアプリケーションを動作させている際にCVMは75%あたりで動作しており、これは大体4vCPUでした。

結局のところ、オーバーヘッドはワークロード次第で、標準のサイズはvSphere/VSANコンポーネントでもNutanix CVMでも変動するのです。

さて、インカーネルのくだらない話へと戻りましょう。

VMwareは自分自身のハイパーバイザーが非常に大きなオーバーヘッドがあるので、ストレージをそれを通して動作させるのは難しいというFUDを広めるのが好きなようです。これを見るたびにVMwareはこれまで市場に対してハイパーバイザのオーバーヘッドは小さい(実際に小さい)と言い続けていたので、変だなと感じます。けれどもVMwareは自身の商品のためにお天気のように言葉を翻しました。

こうしたFUDの例はVMwareのチーフテクノロジストDuncan Eppingのツイートです:

Fig036

訳注: どうしてインカーネルがいいのか?と聞く前に 幾つかのステップを省略できる!

ツイートにはハイパーバイザを経由して別の仮想マシン(この場合、Nutanix CVM)へアクセスするのは効率的ではないという意図で書かれています。これはいくつかの理由で非常に興味深いものです:

  1. もしもそんなにもハイパーバイザを経由して仮想マシンから別の仮想マシンへと通信するオーバーヘッドが高いというのであれば、どうしてVMwareはビジネスクリティカルな、高いI/Oを要求するようなアプリケーションで、仮想マシン同士(そしてESXi同士)がデータアクセスを相互に行うようなアプリケーションをカーネル上で動作させることを推奨しているのでしょうか? 例: Webサーバ仮想マシンアプリケーションサーバ仮想マシンへアクセスし、さらにそこからデータベースへとアクセスするような構成、それぞれが各々仮想マシンカーネルを通じて別の仮想マシンへとアクセスする。
  2. VSANは以下に上げるような機能でそれを利用している:

VMwareのもう一つのFUDの例として今回はプリンシパルエンジニアである Jad Elzeinのもので、VSANはNutanix(BlockはNutanixの「Block」のことです)に比べてオーバーヘッドが小さいという事を意図したものです。

訳注: 10ブロック=40ノード = 40管理仮想マシン = 80vCPUと1TB以上のメモリが管理のためだけに! オーマイゴッド!

思うに、VSANの機能やvSphereの基本管理機能に必要な仮想マシンの数(とリソース)について忘れてしまったのだと思います。インカーネル(もしもまだ何らかの優位点があるということを信じているのであれば)の優位点の全てはハイパーバイザーとインカーネルではない管理仮想マシン間の恒常的なトラフィックによって以下の図のように殆ど消えてしまいます:

Fig038むしろ、#AHVisTheOnlyWay(AHVこそが進むべき道だ)そして#GoNutanix(Nutanixを使おう!)というのが正解です。AHVのオーバーヘッドはvSphere/VSANよりも小さいのですから!

まとめ:

  1. Nutanix CVMは完全に統合された、事前構成済みの、高可用性を備えた、自己修復管理スタックを提供します。vSphere/VSANは多くのアプライアンスやソフトウェアを追加でインストールする必要があります。
  2. Nutanix AHVの管理スタック(CVMによって提供される)は8vCPUと大抵は16GBのメモリのみで、その中で多くの場合vSphere/VSANを超える能力を提供します。vSphere/VSANは同等機能を提供しようとすると(実際には同等にならないことも多いですが)非常に多くのリソースを利用します。
  3. Nutanix CVMはこれらの機能を様々な多くの仮想アプライアンス仮想マシン、またはサードパーティのデータベース製品に頼るのではなく組み込みで提供します(PRISM Centralだけは別の仮想アプライアンスで例外ですが)。
  4. Nutanixの管理スタックは競合製品に比べより優れた堅牢性/高可用性を備え、しかもすぐにそれが利用できます。クラスタが拡張されるにつれAcropolis管理スタックが自動的に管理機能を拡張し続け、リニアな拡張性と一貫したパフォーマンスを保証します。
  5. 次にVMware/EMCがNutanix コントローラVMについて、リソースの大食漢であるとか、そのたぐいのFUDを広げようとしていたら、それはどの機能についての話なのか聞いてください。おそらくここで述べたようなポイントは考慮していませんでしょうから、お勉強として上の記事を読むようにさせてください。
  6. Nutanix AHV管理は完全に分散されており、高可用性を備えています。VMwareにvSphere/VSANの管理コンポーネントを完全に高可用性を備えた状態にする方法を聞いてみてください。ついでに、設計、インストール、検証、維持管理のためのプロフェッショナルサービスにいくらかかるかも。
  7. 次の会話は「Nutanixと比べてVSANはどれだけのコストがかかるの?」です。今回全てのリソースのオーバーヘッドとvSphere/VSAN環境の設計、実装、検証が複雑であるということを知りましたが、vSphere HA以外にほとんど管理コンポーネントを守るすべがないということまではお話しませんでした。しかし、コストの話はELAやライセンシングコストの話をしなくてはなりません。あまり興味わかないですよね。

VMware/EMCにいるお友達へ、Nutanix CVMはこう言っていますよ。

「あっちへ行って、見くびっていてください。」

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

どうでしょう(笑)!? そもそもかなり偏った角度からの記事です。どうしてもFUDを払拭したかったのでしょう(ありがたいことに、全部引用元を明らかにしてリンクがついている・・・)。今後はCalm.ioを買収したのでvRealize Automationも加えないといけないとか、NutanixがPernixDataを買収したのでやっぱりインカーネルが必要・・・と思ったりしている人もいるかもしれません。

今回、この記事を取り上げたのは最近の翻訳記事で繰り返しお伝えしているとおり、変な色眼鏡で技術を誤解してほしくないということをお伝えしたかったからです。Guidoさんや今回のJoshさんのようにしっかりと技術的に確認して、何が正しいのか見極めてください。