本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。
本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。
原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 6 – Performanceをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
性能についてお話をする際に、4KのI/Oベンチマークを使うなど、非現実的なスピードを比較対象として並べていくのは非常に容易いことです。ですが、すべての本当のデータセンタの技術のエキスパートが知っているとおり、IOPSはパズルの本の小さなピースでしかないのです。私の意見では、IOPSはこれほどまでに注目をあびるべきではないほどの注目を浴びています。これについてはこちらの記事でお話をしています。ピークパフォーマンス vs 実際の世界のパフォーマンス。
性能についてお話をする際に、私は管理コンポーネント、アプリケーション/仮想マシン、分析、データの信頼性などのすべてとその間のものも含めてお話をしていきます。
さて、AHV(旧称: Acropolis Hypervisor)を動作させているNutanix XCPが全てのコンポーネントにおいて一貫した高いパフォーマンスを保証している幾つかの例を見ていきましょう:
管理の性能:
Acropolisの管理レイヤにはAcropolis Operating System(以前のNOS)、Prism (HTML5のGUI)、そしてAHVの管理スタックが含まれており、｢マスタ｣と｢スレーブ｣のインスタンスからなっています。
このアーキテクチャは全てのCVMが動作し、各々平等にプラットフォームの全てのエリアで継続的にスムースに動作することができるように、保証しています。つまり、中心となるアプリケーションやデータベースやコンポーネントは存在せず、それがボトルネックになることもないのです。完全に分散させることこそがウェブスケールプラットフォームを提供する鍵です。
おのののコントローラー仮想マシン(CVM)はローカルノードの管理に必要なコンポーネントと分散ストレージファブリックと管理タスクに貢献するためのコンポーネントを動作させています。
例 : 1つのAcropolis｢マスタ｣が居ますが、これは単一障害点でもパフォーマンスのボトルネックでもありません。
Acropolis マスタ は以下のタスクを担当します:
各々のAcropolis スレーブ は以下のタスクを担当します:
マスタであるか、スレーブであるかにかかわらず、各々のCVMは2つの最も重たいタスクを実行しています。ハイパーバイザーからのローカルの統計を収集/提出と利用している場合は仮想マシンのコンソールの接続です。
初めから分散して設計されているため、XCPのプラットフォームは一貫した高いパフォーマンスを達成できています。中央の、例えば中心となる管理仮想マシンとそれに紐付いたデータベースサーバへ統計情報を送信することはボトルネックになりえますが、何らかの形でのアプリケーションレベルのHA(例 : SQL Aways on Availability Group)が導入されていない場合、これは単一障害点にもなりうるため、殆どのお客様でこれは受け入れがたい状態です。
Acropolisマスタが行っている役割はHAのスケジューラーやネットワークコントローラー、IPアドレス管理、タスク実行者など、全て軽量なタスクです。
HAスケジューラータスクはノード障害時にしかアクティブにならないタスクで、マスタにとってのオーバーヘッドは非常に小さいものです。ネットワークコントローラーのタスクは新たなVLANを構成する際などにしか利用されません。タスクの実行は全てのCVMで実行されている分散されたすべてのタスクを継続的に監視するシンプルなものです。IPアドレスの管理は基本的にはDHCPのサービスで、これも非常に小さなオーバーヘッドです。
パート8で、Acropolis Analyticsについて更に詳しくお話します。
データローカリティ
データローカリティはXCPの他にはない機能で、新しいI/Oは仮想マシンが動作しているローカルノードとクラスタ内の他のノードにレプリケーションされて書き込まれるというものです。データローカリティは次回以降のReadのI/Oがネットワークを経由して転送され、リモートのコントローラーを利用するという必要性を排除します。
仮想マシンがクラスタ内を移動する場合には、WriteのI/Oは常にローカルに書き込まれるため、リモートからのリードはリモートデータのReadが必要な場合にのみ発生します。もしもデータがリモートに有り、その先アクセスされないのであればリモートのI/Oは発生しません。結果として大抵の場合、90%以上のI/Oがローカルから提供されることになります。
現在、うまく設計された10Gbのネットワークでは帯域とレイテンシの問題はさほど問題にならないかもしれませんが、フラッシュのパフォーマンスが幾何級数的に向上していくにつれ、ネットワークは非常に高価な40Gb(もしくはそれ以上の)のネットワークへの移行なくしては簡単に大きなボトルネックとなります。データローカリティは大部分のRead I/Oをローカルから提供し、Writeのコピーのうちの一つをローカルでさばくことによってWrite I/Oからのネットワークのオーバーヘッドを減らすことでネットワークへの依存関係を最小化することに役立ちます。ですから、ローカリティはお客様がパフォーマンスに妥協すること無くより低コストなネットワークを利用することを可能にするのです。
データローカリティはサポートされている全てのハイパーバイザーで動作しますが、AHVは他にはないデータアウェアな仮想マシンの配置をサポートしています : 仮想マシンは障害時やメンテナンス時に仮想マシンのデータのローカルデータの割合が最も高いノードで、つまりリモートのI/Oの可能性が最も低くなるノードで電源が入りそれぞれの仮想マシンのI/Oのオーバーヘッドが低くなります。
さらに、データローカリティはハイパーバイザーや仮想マシンの統計データなどの分析のためのデータの収集についても適用されます。結果として統計データはローカルに書き込まれ2つ目(もしくはRF3が設定されている場合には3番目も)はリモートに書き込まれます。これはつまり、統計データ、非常に膨大にもなりうるデータが分散ファイルシステムとクラスタに有りうる限りの最小限の影響しか与えないということも意味しています。
まとめ:
- クラスタとともに管理コンポーネントも拡張され、一貫したパフォーマンスを保証する
- データローカリティがデータがコンピューティング(仮想マシン)とデータを可能な限り近くにあることを保証する
- データの場所をベースとしたインテリジェントな仮想マシンの配置
- 全てのNutanixコントローラー仮想マシンはチーム(ペアではない)で動作し、クラスタ内のすべてのコンポーネントとワークロード(仮想マシン)に適切なパフォーマンスを保障
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
さて、皆様の大好きなパフォーマンスに関連する記事になりました。XCPという名前が多用されているとおり、記事が古いので現在のAHVはこれはさらに先を行っています。
仮想マシンの配置はよりインテリジェントなものとなり、vSphereでいうDRSに相当する動的なものになっていますし、AHV Turboモードによって、ハイパーバイザーを通過する際に発生するオーバーヘッドもNutanixにとっては過去のものになりつつ有ります。
常に進化を続け、購入したノードの性能もソフトウェアで向上していく･･･そうしたNutanixの魅力の一つで外せないのが、この性能で、その中心にあるのがAHVなのです。
