はじめに
Nutanixへの移行や新規導入を検討する際、特に気になるのは「どの程度のパフォーマンスが出るのか」という点ではないでしょうか。
NutanixはHCI（Hyper-Converged Infrastructure）というアーキテクチャーの特性上、CPU、ディスク、ネットワーク、CVM（Controller VM）など、複数の構成要素がパフォーマンスに影響します。
本記事では、Nutanixのパフォーマンスに影響する要素と、設計・構築時に考慮すべきポイントについて、これまでの経験を踏まえてナレッジを整理します。
お断り
本記事は、あくまでも一個人の見解と経験に基づくものです。
パフォーマンスに関する設定を変更する場合は、必ず事前検証を実施し、各個人・組織の責任において評価・判断してください。
また、Nutanix AOS、AHVのバージョンやハードウェア構成によって、推奨設定やサポート要件が異なる場合があります。実際の設計・設定変更にあたっては、Nutanixの公式ドキュメントやハードウェアベンダーの推奨事項を確認してください。
CPU
CPUの性能は、CVMを含むすべてのVMのパフォーマンスに影響します。
一般的には、動作周波数が高いCPUを選択することで、シングルスレッド性能やレイテンシーの改善が期待できます。
しかし、CPUはコア数が増えるほど動作周波数が低くなる製品も多く、単純に周波数だけで選定することはできません。
また、CPUの性能は動作周波数だけではなく、アーキテクチャー、IPC（Instructions Per Cycle）、キャッシュ容量、メモリ帯域幅などにも左右されます。
さらに、CPUコア数の増加はライセンス費用の増加にもつながります。
Nutanix Cloud Infrastructure（NCI）は原則として物理CPUコア数単位でライセンス費用が発生します。Nutanix Cloud Manager（NCM）についても、オンプレミス向けライセンスはコア単位で課金されます。
ただし、Prism Centralの基本的な管理機能を利用するために、NCMライセンスが必須というわけではありません。利用する機能によって必要なライセンスが異なります。
したがって、CPU選定では性能とライセンス費用のバランスを考慮する必要があります。
CPU間の性能比較には、以下のベンチマークサイトも参考になります。
ただし、ベンチマークスコアは実際のNutanix環境における性能を保証するものではありません。Nutanix Sizerによるサイジングと、実ワークロードに基づく検証を併用することが重要です。
なお、後述するCVMのvCPU数についても、物理CPUのコア数やNUMA構成、プラットフォームの要件が関係するため、この点も考慮する必要があります。
参考資料
ディスクタイプ
高いI/O性能や低レイテンシーが要求される環境では、NVMe SSDを使用することが有効です。
一般的なSATA/SAS SSDと比較して、NVMe SSDは高いスループットやIOPSを実現できる場合があります。
一方、製品や容量によっては費用が高くなるため、コストパフォーマンスを考慮した選定が必要です。
ディスク単体のIOPSやスループットは、各ベンダーが仕様を公開しています。現在のワークロードのI/O特性を把握したうえで、適切なディスクを選定するとよいでしょう。
特に、以下の項目を確認することを推奨します。
- ランダムRead/WriteのIOPS
- シーケンシャルRead/Writeのスループット
- I/Oレイテンシー
- Read/Write比率
- 書き込み耐久性（DWPDなど）
ただし、ディスク単体の性能がそのままNutanixクラスタ全体の性能になるわけではありません。
CVMの処理能力、ネットワーク帯域、データ保護方式などもパフォーマンスに影響します。
また、Disaster Recovery（DR）機能を利用する場合は、レプリケーション方式やRPO（Recovery Point Objective）などによって、ノードのストレージ容量やCVMリソースに関する要件が異なる場合があります。
詳細については、利用するバージョンの公式ドキュメントを確認してください。
なお、以前Nutanix CommunityでNVMe SSDとSATA/SAS SSDのI/O性能を比較した記事を見かけた記憶がありますが、現在見つけられていません。見つかり次第、追記する予定です。
ディスク本数
ディスクの本数もパフォーマンスに影響する重要な要素です。
Nutanixのストレージアーキテクチャーには、ランダム書き込みを一時的に受け付けるOpLogという仕組みがあります。
Nutanix Cloud Bibleでは、OpLogはノード内の最大12本のSSDに分散して配置されると説明されています。
ディスク本数が増えることでI/Oを複数のデバイスに分散できるため、特にランダムWriteのパフォーマンス向上が期待できます。
ただし、ディスク本数を増やせば必ず性能が向上するわけではありません。
ストレージデバイスの種類、AOSのバージョン、Blockstoreなどの実装方式、ワークロードの特性によって効果は異なります。
参考資料
ノード数
Nutanixでは、各ノードにストレージコントローラーの役割を担うCVMが配置されます。
ノード数を増やすことで、クラスタ全体で利用可能なCPU、メモリ、ストレージデバイス、およびCVMによるI/O処理能力を拡張できます。
このため、ノード数の増加によってクラスタ全体のパフォーマンス向上が期待できます。
Nutanixの分散アーキテクチャーはスケールアウトを前提としており、ノード追加によって処理能力を段階的に拡張できる点が特徴です。
ただし、実際の性能向上率はワークロードや構成によって異なり、ノード数に完全比例するとは限りません。
特に、以下の要因がボトルネックとなる可能性があります。
- ノード間ネットワークの帯域やレイテンシー
- CVMのCPU・メモリリソース
- I/Oの並列度
- データローカリティ
- ストレージデバイス自体の性能
ノード追加前後の性能比較では、クラスタ全体のIOPSだけでなく、個々のVMが得られる性能も確認することが重要です。
参考資料
※以前、Nutanix Communityまたはネットワールド様の技術ブログで、ノード数の増加に伴うIOPSのスケーラビリティを示した記事を見かけましたが、現在見つけられていません。見つかり次第、追記します。
NICカード
NICの帯域幅は、Nutanixのパフォーマンスを考えるうえで、特に注意すべき要素の一つです。
一般的な本番環境では10GbE以上を基本として検討しますが、高負荷のワークロードを扱う場合は25GbE以上の構成も積極的に検討すべきでしょう。
特に、データベースなど大量のI/Oを発生させるアプリケーションを稼働させる場合には注意が必要です。
NutanixはHCIの特性上、データの冗長化やリモートReadなどでノード間通信が発生します。
そのため、NICの帯域が不足すると、ネットワークがボトルネックとなり、ストレージ性能を十分に引き出せなくなる可能性があります。
個人的には、新規にハードウェアを調達する場合、10GbEだけでなく25GbEの採用も検討する価値が高いと考えています。
10GbEと25GbEのNICカード自体の価格差は、製品や調達条件によっては比較的小さい場合があります。
ただし、NICカードだけでなく、以下の費用も考慮する必要があります。
- SFP+/SFP28などの光トランシーバー
- DACケーブルや光ファイバーケーブル
- ToR（Top of Rack）スイッチ
- スイッチ側の光トランシーバー
- 保守費用および消費電力
また、NICのポート速度だけでなく、冗長化構成やBonding方式も実効帯域に影響するため注意が必要です。
SR-IOVについて
近年では、SR-IOV（Single Root I/O Virtualization）に対応したNICも広く利用されています。
Nutanix AHVでも、対応する環境ではSR-IOVを利用できます。
SR-IOVは、仮想マシンから物理NICの機能に効率的にアクセスすることで、ネットワーク処理のオーバーヘッドを削減する技術です。
Prism CentralのNICプロファイルなど、対応する機能や構成を確認する必要があります。
ただし、SR-IOVは主にゲストVMのネットワーク性能を改善する技術であり、NutanixのストレージI/O性能を直接向上させるものではありません。
また、ライブマイグレーションなど一部機能との互換性や制約についても確認が必要です。
参考資料
CVMのvCPU数
CVMはNutanixのストレージI/O処理を担う重要なコンポーネントです。
そのため、CVMに割り当てられるvCPU数は、ストレージ性能に大きく影響する場合があります。
特に、CVM側のCPUリソースが不足している環境では、vCPU数の増加によってI/O性能が改善する可能性があります。
I/Oのワークロードは、大きく次の4種類に分類できます。
- ランダムRead
- ランダムWrite
- シーケンシャルRead
- シーケンシャルWrite
私の経験では、特にランダムWriteのパフォーマンスに対して、CVMのvCPU数が大きく影響するケースがありました。
ただし、これは個人の経験則に基づくものであり、すべての環境に当てはまるわけではありません。
また、CVMのvCPU数を増やすと、ゲストVMが利用できるCPUリソースとの競合が発生する可能性があります。
したがって、vCPU数は多ければ多いほどよいというものではありません。
All-NVMe構成など、高いI/O性能が求められる環境では、CVMに比較的多くのvCPUが割り当てられる場合があります。
ただし、必要なvCPU数はAOSのバージョン、物理CPUのコア数、NUMA構成、NVMe容量、SPDKの使用有無などによって異なります。
一律に16 vCPU以上を推奨値とするのではなく、公式のサイジング要件を確認することが重要です。
参考資料
CVMのメモリサイズ
CVMのメモリサイズもストレージ性能に影響します。
Nutanixには、Unified Cacheと呼ばれるReadキャッシュの仕組みがあります。
Unified CacheはCVMのメモリを使用してデータやメタデータなどをキャッシュするため、CVMのメモリ容量がキャッシュの利用可能量に影響します。
適切なメモリ容量を確保することで、Readキャッシュのヒット率向上や、ディスクへのアクセス回数の削減が期待できます。
ただし、CVMのメモリを増やせば必ずRead性能が向上するわけではありません。
例えば、以下のような条件によって効果が変わります。
- ワーキングセットのサイズ
- Readアクセスの局所性
- キャッシュヒット率
- データローカリティ
- メモリを使用する他のCVMサービス
また、CVMのメモリ容量は重複排除やその他のストレージ機能の要件にも関係します。
そのため、利用する機能と公式のサイジング要件を確認したうえで設定する必要があります。
参考資料
ToRスイッチのパケット転送方式
複数ノードでクラスタを構成するNutanixでは、ToRスイッチの性能も重要です。
Nutanixではノード間でストレージ関連の通信が発生するため、スイッチの遅延やパケットロスがクラスタ全体の性能に影響します。
そのため、データセンター向けの高性能なスイッチを使用することが望ましいと考えています。
特に、以下の仕様を確認しておくとよいでしょう。
- ラインレートでのパケット転送性能
- ノンブロッキング構成
- 十分なパケットバッファ
- 低いポート間レイテンシー
- 冗長化への対応
また、L2スイッチのパケット転送方式には、代表的なものとして以下の2種類があります。
Store-and-Forward方式
フレーム全体を受信してから転送する方式です。エラーチェックを行えるほか、バッファを活用した転送が可能です。
Cut-Through方式
フレーム全体の受信を待たずに転送を開始する方式で、低遅延を実現しやすい特徴があります。
ただし、データセンター向けスイッチがすべてCut-Through方式というわけではありません。
Nutanixの公式ドキュメントでも、ネットワークのオーバーサブスクリプションやポート速度の違いなどに応じて、適切なスイッチを選択することが推奨されています。
単純にCut-Through方式を選べばよいわけではなく、ネットワーク全体の構成に応じた選定が重要です。
参考資料
BIOS
サーバのBIOS設定も、パフォーマンスに影響する重要な要素です。
特に、CPUの省電力制御に関する設定は、処理性能やレイテンシーに影響する場合があります。
代表的な設定項目として、C-stateやP-stateなどがあります。
C-stateはCPUのアイドル状態における電力制御、P-stateは動作周波数や電圧などの性能状態を制御する仕組みです。
一般論として、省電力機能によって負荷変動時の応答性能に影響が生じる場合があります。
ただし、Nutanix環境では、パフォーマンスを優先するためにC-stateなどの省電力機能をすべて無効化すればよい、というわけではありません。
Nutanixやサーバベンダーは、ハードウェア構成に応じた推奨BIOS設定を提供している場合があります。
特に、Nutanix純正アプライアンスでは、標準の電力管理設定が最適化されており、独自の設定変更がサポート上の問題につながる可能性もあります。
そのため、まずはベンダーの推奨設定を確認し、変更が認められる項目についてのみ検証を実施することを推奨します。
BIOSには非常に多くの設定項目がありますが、一つひとつ確認することで、CPUやメモリ、PCIeなどのハードウェアアーキテクチャーについて理解を深めることができます。
参考資料
熱管理
Nutanixを導入する場合、データセンターやコロケーション施設にサーバを設置するケースが多いため、空調設備そのものを個別に検討する機会は少ないかもしれません。
しかし、サーバ内部の冷却制御については確認しておく価値があります。
サーバのファン制御は通常、自動設定となっていることが多く、必ずしも常時最大回転数で動作するわけではありません。
冷却能力が不足すると、CPUやその他のコンポーネントでサーマルスロットリングが発生し、動作周波数が低下する可能性があります。
結果として、ゲストVMやCVMのパフォーマンスにも影響します。
特に、高負荷状態が長時間続く環境では、CPU温度やファン回転数などの監視が重要です。
ただし、ファンを常時最大回転数に設定することが最適とは限りません。
騒音、消費電力、ハードウェアの推奨設定なども考慮しながら、適切な冷却ポリシーを選択する必要があります。
個人的には、パフォーマンスを重視する場合、CPU使用率だけでなく、温度や動作周波数も確認することを推奨します。
参考資料
Volume Groupの使用
データベースなどのワークロードでは、Volume Groupの利用が選択肢となる場合があります。
ただし、Volume Groupの利用方法によってI/Oの処理経路が異なるため、事前の確認が必要です。
AHV上のVMにVolume Groupを直接アタッチする場合、通常はVMが稼働するノードのローカルCVMがI/Oを処理します。
そのため、Volume Groupを使用したからといって、必ずリモートノードへのネットワークアクセスが発生するわけではありません。
一方、Volume Group Load Balancerなどを使用すると、複数のCVMにI/O処理を分散させることができます。
この場合、処理能力の向上が期待できる一方で、ノード間通信も考慮する必要があります。
また、外部ホストからNutanix Volumesとして接続する場合には、iSCSI通信を含むネットワーク設計が重要になります。
データベース向けのベストプラクティスではVolume Groupが利用されるケースもありますが、必ずしもすべての環境において最適とは限りません。
ワークロードの特性、ディスクサイズ、I/Oの並列度、ネットワーク帯域などを考慮し、通常の仮想ディスク構成と比較検証することを推奨します。
参考資料
virtio-net Multi-Queue
AHVでは、ゲストVMの仮想NIC（vNIC）に対して、virtio-net Multi-Queueを利用できます。
これは、ネットワークトラフィックを処理するキュー数を増やすことで、複数のvCPUを活用してネットワーク処理を並列化する仕組みです。
特に、大量のネットワークトラフィックや複数の通信フローを扱うVMでは、パフォーマンス向上が期待できます。
ただし、キュー数を増やせば必ず性能が向上するわけではありません。
ゲストOSの対応状況、vCPU数、通信フロー数などによって効果が変わります。
また、キュー数の増加によりCPU負荷が増える場合もあるため、設定変更後の評価が必要です。
参考資料
ハードウェア購入後からサービス提供までに実施しておくべきこと
費用やスケジュールの制約によって難しい場合もありますが、ハードウェアの導入後、本番サービスの提供開始前にパフォーマンスを測定しておくことを推奨します。
Nutanixでは、X-Rayと呼ばれるパフォーマンス評価ツールが提供されています。
X-Rayは仮想アプライアンスとして提供されており、HCI環境のパフォーマンス、耐障害性、スケーラビリティなどを評価できます。
例えば、以下のような項目を測定できます。
- ランダムRead/WriteのIOPS
- シーケンシャルRead/Writeのスループット
- I/Oレイテンシー
- 高負荷時の性能変化
- ノード障害時の性能変化
- VMのライブマイグレーションに伴う性能への影響
また、CPU、CVMのvCPU・メモリ、ネットワーク構成などの条件を変更した場合に、どの程度パフォーマンスが変化するのかを比較することも可能です。
ただし、X-Rayにはノード障害などを伴うテストシナリオがあるため、原則として専用の検証クラスタを使用する必要があります。
可能であれば、X-Ray自体もテスト対象クラスタとは別の環境に配置することが推奨されています。
測定結果は、後から比較できるように以下の情報とともに記録しておくとよいでしょう。
- ハードウェア構成
- AOS・AHVのバージョン
- CVMのvCPU数・メモリサイズ
- ネットワーク構成
- I/Oのブロックサイズ
- Read/Write比率
- Queue Depth
- IOPS・スループット・レイテンシー
本番稼働後にパフォーマンス問題が発生した場合でも、導入時のベースラインがあれば、問題の切り分けに大いに役立ちます。
参考資料
まとめ
Nutanixのパフォーマンスは、CPUやディスクといった単一のハードウェアスペックだけで決まるものではありません。
CVMのリソース配分、ネットワーク帯域、ノード数、データローカリティなど、多くの要素が複合的に影響します。
また、性能向上を目的とした設定変更であっても、構成によっては逆効果になる可能性があります。
そのため、まずはベンダーが推奨する構成を基本とし、実際のワークロードに基づいた検証を行うことが重要だと考えています。
個人的には、導入前にベンチマークを取得し、構成変更による性能差を定量的に評価することが、最も確実なアプローチだと考えています。