本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。
原文を参照したい方はNutanix AOS 5.5 delivers 1M IOPS from a single VM, but what happens when you vMotion?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
Nutanixは単一仮想マシンで100万IOPSを達成 - HCIでは世界初!もご参照下さい。
長年に渡ってNutanixは複数のハイパーバイザーに対して優れたパフォーマンスを提供してきましたし、同様にネイティブのNXシリーズ、OEM(Dell XCとLenovo HX)、そして直近ではソフトウェアオンリーの選択肢としてCiscoとHPEというハードウェアプラットフォームでも同様です。
直近のTweet(下)で、単独の仮想マシンで8KのランダムReadで100万IOPSと、8GBps以上のスループットが次世代ハイパーバイザーであるAHVで実現できることを示しました。
#Nutanix delivering 1 million IOPS in a single VM at 8k block size and only 0.11ms latency puts to bed the In-kernel vs Controller VM debate.#VSAN #VMware #HCI pic.twitter.com/afkq1cC0e3
— Josh Odgers (@josh_odgers) November 9, 2017
殆どの反応はポジティブなものでしたが、いつものように幾つかの競合のベンダーがパフォーマンスに関しての恐怖や不確実さや嘘(FUD Fear, Uncertainty, Doubt)を広めようとやってきました。その中にはライブマイグレーション(vMotion)の最中やその後はパフォーマンスが継続しないというもので、これはIOパスのパフォーマンスを示していないというものです。
インカーネルとコントローラー仮想マシンの対立(翻訳予定なし)に関するIOパスの議論についてちょっと復習しましょう。
IOパスを検証するために、Nutanixの場合はコントローラー仮想マシンを経由します。そのため、ここでの様々な変動要素やボトルネックを可能な限り排除したいと考えるはずです。これはread/writeの検証はwriteがネットワークのような要素に依存してしまうため、適切には行えないということを意味します。ここではNVMeを搭載しているノードを利用しているため、ボトルネックはとっくにネットワーク部分になってしまい、ユーザー仮想マシンとコントローラー仮想マシンの間のパスではなくなっているのです。
以前のツイート(下)でSATA SSD、NVMe、そして3DxPointのスループット性能を例に上げて、次世代フラッシュにおいてはネットワークが明らかにボトルネックになるということを示しました。
Does anyone see a problem with this?
— Josh Odgers (@josh_odgers) June 19, 2016
Hint: Its the network!
(Unless you have #Nutanix data locality!)#HCI #NEXTConf pic.twitter.com/NXcgFyL5gP
サードパーティによるNutanixのデータローカリティについてのFUDに対して、Nutanixのオリジナルで他にはないデータローカリティの実装(翻訳予定なし)という記事を書いています。ここにはNutanixが優れたパフォーマンスを提供するためにネットワークへの依存度を可能な限り小さくしているということが書かれています。
ですから、我々がやるべきことはRead IOの検証を行い、ユーザー仮想マシンとソフトウェアディファインドストレージの間のIOパスに可能な限りの負荷をかけることです。インカーネルの部分もありますし、NutanixのCVMが動作しているユーザースペースの部分もあります。
Tweetは8KのランダムReadが100万IOPS、8GBpsのスループットがNutanixのIOパスにあるということを示しており、110マイクロ(ミリではありません)秒のレイテンシを実現できるほど効率的であるということも示しています。
次なる疑問は、Nutanixや一般的なHCIにおいてvMotionの後に何が起こるか、という誤解を解いていくということでしょう。
この疑問は適切なものですということこから初めましょう。ですが、vMotionの最中や後にパフォーマンスが落ちたとして、それは大きな問題なのでしょうか?
ビジネスアプリケーションにとって、ベンダーに共通する事項としてDRSのShould(あるべき)/Must(必ず)のルールでvMotionをメンテナンス時や障害時以外にはvMotionを発生させないようにするということが、従来型/古くからのNAS/SAN、もしくはHCIであっても、インフラストラクチャに関係なく推奨されています。
NAS/SANにあっては最良のシナリオでも100%リモートのIOですが、Nutanixにおいてはこれは最悪のシナリオです。Nutanixは通常時、100万IOPSであり、ライブマイグレーションとその後の数分間パフォーマンスが20%落ちると考えてみましょう。
それでもまだ80万IOPSです。これでも殆どのNAS/SANのソリューションが提供する性能よりも高いのです。
しかし、実際のところは以下のリアルタムに録画されたビデオが示すとおり、ライブマイグレーションの最中やNutanixは優れたパフォーマンスを継続的に提供しています。ヒント: puttyのセッション(左側のコンソール内)の数字へご注目下さい。最終的な結果につながるゲストレベルでのパフォーマンスを示しています。
YouTube: 1M IOPS Live Migration
私の友人で同僚のMichael “Webscale” Webster (VCDX#66 & NPX#007)氏のビデオであるということをお伝えしておきます。
IOはライブマイグレーション中に3秒ほど100万IOPSを下回り、最低では95万6千 IOPSであるということが記録されています。つまり10%程度の低下が3秒ほどであればこれは非常に価値のあるものと言えるでしょう。というのも、パフォーマンスの低下は移行に伴う仮想マシンのスタン(静止)が原因であり、その下のストレージによるものではないからです。
我々の｢オトモダチ｣である古くからのストレージベンダーもそれぞれの巨大で最悪なストレージ装置で同じテストを繰り返し行なっています。
あまり面白くありませんか? では 70/30の read/writeワークロードがどう動くか見ていきましょう!
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
AHVのパフォーマンスに関する記事ですが、未だに続く、ローカリティとライブマイグレーションの相性の悪さの問題に答えるものとなっています。昨年の記事にもある通り、そもそもライブマイグレーション自身がリソースを多く消費するため、ライブマイグレーションは頻繁に行うべきものではありませんし、ライブマイグレーション後もリモートからのReadは"オンデマンド"にローカルへのコピーが行われるため、急速にリモートに対するReadの割合は低下します。また今回Joshさん(とそのお友達のMichaelさん)が示したとおり、(ワークロードが非常に大きなものであったとしても!)大きな影響は発生しないのです。(ネットワークもRDMAを使っているということもあるでしょう!)
AHVは常に進化を続けますが、その進化はHCIインフラの中だけに最適化されたものです。万能を切り捨てたゆえの思い切ったアーキテクチャに今後も注目です。来週もJoshさんの記事をお送りします。
