« Nutanix .NEXT Washington D.C. 速報 その4 ~One More Thing - Xi Cloud編~ | メイン | NutanixはGoogle Cloud社と提携しエンタープライズアプリケーションのためのクラウド環境を統合 »

2017/07/03

.NEXT 2017情報 / AHV ターボモード

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

原文を参照したい方はWhat’s .NEXT 2017 – AHV Turbo Modeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

また、今回の記事の内容も踏まえて、.NEXT報告会セミナーを開催予定です。ぜひお申込みをお願い致します。

2015年に遡ることになりますが、私は「なぜNutanixのAcropolis Hypervisor(AHV)は次世代のハイパーバイザーなのか」という名前のシリーズを描き下ろしました。この中ではなぜAHVが改めて検討に値するのかというその理由を多くカバーしています。(※訳注このシリーズについては今後翻訳する可能性はありますが、現時点では英語のままです。)

このシリーズをまとめると、AHVは唯一ハイパーコンバージドインフラストラクチャ(HCI)向けに作られたハイパーバイザーであり、機能面でも成熟面でも継続して進化しています。そしてその一方で多くのお客様で利用されるようになってきました。

どのぐらい使われているの?という疑問はもちろんです。Nutanixは我々が最近公開した会計年度2017年の第3四半期の会計レポートのハイライトでオフィシャルに出荷したノードのうち23%がAHVであるとしています。

この数年私は個人的に多くのAHVを利用するお客様、特にそれがMS SQLやMS Exchangeなどのビジネスクリティカルアプリケーションである場合にご一緒させていただいてきました。

その一つの例が流通大手の新世界がハイパーバイザーとしてAHVを利用するNutanix上で50,000にもおよぶMS Exchangeのメールボックスを稼働です。新世界は現在ではMS SQLのワークロードも同じプラットフォーム上で動作させており、すべてのワークロードの標準プラットフォームになりつつあります。

これはAHVが実際のフィールドで機能面でも、信頼性面からも、そしてパフォーマンス面からもビジネスクリティカルワークロードを稼働させるに足るだけの拡張性があるということの証明の一つにしか過ぎません。

ですが、Nutanixで我々はいつもお客様により多くの価値をご提供したいと奮闘しています。そのなかで多くの混乱と誤った情報が見られるエリアがNutanixのストレージI/Oパスの効率性の関連の分野です。

NutanixのコントローラーVM(CVM)は複数のハイパーバイザー上で動作し、優れたパフォーマンスを提供しています、ですが、常に改善の余地はあるものです。我々のインカーネルおよび仮想マシンベースのストレージソリューションに対する深い経験から、我々は最も大きなボトルネックはハイパーバイザー自身であるということに気が付きました。

Fig240

NVMeなどのテクノロジーがメインストリームとなり、3D XPointなども後に控えています。こうしたプレミアムなストレジテクノロジーの価値をお客様に最も良い形でご提供できる方法を模索しています。

この結果生まれたのがAHV ターボモードです。

Fig241

AHVターボモードはユーザーの仮想マシン(UVM)とNutanix スターゲート(I/Oエンジン)の間のI/Oパスを高度に最適化(短縮化、広帯域化)します。

これらの最適化はI/Oパスをインカーネルに移動させることで実現されたのです。

V

V

V

V

V

V

V

V

V

V

V

うそでーす!! インカーネルがパフォーマンスに優れるというのは単なる幻想であり、NutanixはユーザースペースでのI/Oデータパスを徹底的に改善することで、大規模なパフォーマンスの改善を実現することに成功しました。これは「インカーネル」でくくられるアプローチとはほとんど真逆です。

以下のダイアグラムはUVMのI/Oパスが今回はユーザースペース(インカーネルではありません)で動作しているFrodo(別名 ターボモード)とコントローラVM内で動作するスターゲートへと送られていることを顕しています。

Fig242

AHVとターボモードのもう一つのメリットは複数のPVSCSIアダプターと仮想化ディスクをこうしたコントローラーを跨ぎながら構成するという管理者の手間を削減することができるということです。AHVの仮想マシンへ仮想ディスクを追加した際に、そのディスクは自動的にNutanixのSCSIとブロックのマルチキューの恩恵を受け、改善されたI/OパフォーマンスをReadでもWriteでも利用できるということが保証されます。

マルチキューのI/Oフローは複数のfrodoスレッド(ターボモードスレッド)によって取り扱われ、スターゲートへと渡されます。

Fig243

上のダイアグラムが顕しているようにターボモードのNutanixでは例えばVMFSデータストアのようにデータストア内の仮想マシン数が増えてきた時(例 25以上)のロック機構の影響を最小化するためにVAAI Atomic Test and Set(ATS)を利用するような、古くからあるハイパーバイザーに紐づくボトルネックを解消できます。AHVをターボモードで利用すれば、すべてのvDiskは常に(データストアやコンテナ単位で共有はなく)独自のキューを利用することになります。しかし、frodoはこれを仮想化コントローラーレベルでvCPUごとのキューを渡すことで実現します。

どのぐらいパフォーマンスが良くなるの?という疑問が出てくるでしょう。私の方でちょっとした検証を行ってみましたが、結果としては素晴らしいパフォーマンスの改善がもう4年歳以上となってしまう古いIvy Bridge の NX3460上で確認できました。このハードウェアはSATAのSSDを各ノードに2本搭載しており、メモリのReadキャッシュは向こうにしてあります(つまり、RAMからのReadは発生しません)。

今回の結果を簡単にまとめると:

  1. 同程度のシーケンシャルWriteパフォーマンスにおいてCPUの利用率は25%低減(2929MBps vs 2964MBps)
  2. シーケンシャル Read のパフォーマンスは27.5%向上 (9512MBps vs 7207MBps)
  3. ランダム Read の IOPSは62.52%改善 (510121 vs 261265)
  4. ランダム Write の IOPSは33.75%改善 (336326 vs 239193)

ですから、ターボモードを利用すればNutanixはより少ないCPUとRAMでより高いIOPSとスループットをユーザースペースでありながら実現できるということになります。

インテルが公開した“Code Sample: Hello World with Storage Performance Development Kit and NVMe Driver(コード例 : ストレージパフォーマンス開発キットとNVMeドライバーによるハローワールド)” には「SPDK(ストレージパフォーマンス開発キット)を利用したユーザースペースのNVMeドライバーのアプローチはLinuxカーネルを利用したものに比べオーバーヘッドが最高で10倍低かった。」と記載されています。

これは「インカーネル」が早いと主張したい様々な人々やベンダーが言うようにユーザースペースがボトルネックにはならないという明らかな、そして多くある例のうちの一つにしか過ぎません。このあたりの話は以前にも記事を書いています

ターボモードで、AHVは最も高いパフォーマンス(スループット / IOPS)ともっと低いレイテンシを備え、Nutanixによってサポートされるハイパーバイザーとなりました!

ですが、まだこれだけではありません! AHVは今は最も高いパフォーマンスを提供できるハイパーバイザーであるというだけではなく、我々の最も大きなお客様で1750ノードを動作させているお客様はなんと100% AHVのみを利用しておられます。

Fig244

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

Ntc2017_2

速報記事ではありませんが、.NEXTからの情報をお伝えします。最も皆様の期待の大きかったAHV Turbo mode(ターボモード)についての情報です。上のダイアグラムだけでは理解し難いと思いますので、こちらの通常のI/Oパスと比較して御覧ください。

と言ってもまだわかりにくいと思いますが、QEMUを通り抜けた後にiSCSI(およびTCP)でカプセル化されていたI/OパスがQEMU内から呼び出されるfrodoと呼ばれるプロセスに置き換わるということです。これによって多くのI/Oキューを利用できるようになり、さらにI/O処理にvCPUを多く割り当てることができるようです。ユーザースペースといえばユーザースペースですが、ハイパーバイザー内のプロセスをいじっているという意味ではハイパーバイザーを開発しているベンダーだからこそのチューニングと言えるでしょう。しかもVMwareやMicrosoftやCitrixとは異なり、HCIしかやっていないNutanixだからこその思い切ったチューニングだと思います。

PernixDataから来たメンバーが開発しているとのことですが、当然ながらPernixData社製品(vSphereカーネル内で動作する製品)とコードを共有しているということはなく、完全に新しい実装とのことです。

さて、来週からはまた来週水曜日9:00の更新に戻りたいと思います、引き続きよろしくお願い致します!