NutanixのVMの種類、推奨設計と注意事項を解説(regular VM, agent VM, vUMA VM, vNUMA VM)

はじめに

Nutanixで作成可能な仮想マシン(VM)、実はいろんな種類があります。

この記事ではNutanixの仮想マシンのそれぞれの特徴について紹介します。

そして、推奨設計や注意事項についても整理しました。

前提

この記事はNutanix AHV BestPracticeに基づいた内容としております。

本当に記事の内容が正しいかを確認する癖をつけるためにも、記事の最後にリンクを載せておりますのでそちらも併せて参照してください。

Regular VM

GUIでVMを作成するなど、特別な設定を入れない場合に作成される仮想マシンのことを指します。可能な限り、仮想マシンで使用するvCPUとメモリがAHVホストのNUMAノードに収まるようにリソースの配置が行われます。

Regular VMの推奨設計

• コア数を増やす場合は、vCPU毎のコア数を増やすべきではありません。つまり、16コアが必要となるVMを構築する場合、1vCPU&16コアとするのではなく、2vCPU&8コア、4vCPU×4コアのようにするべきです。
• 物理コア数を超えたCPUを1つのVMに対して設定することは非推奨となります。
• VMが動作するCPUソケットで使用可能なメモリ容量でVMのメモリサイズを決めます。
• 1つのAHVのNUMAノードに収まるサイズに維持することが推奨されます。つまり、2CPU、物理コアはCPUにつき16コア、ハイパースレッディング有効、メモリは1CPUにつき128GBあるサーバの場合、最大でもvCPUは16コア、メモリは128GBのスペックとなるように設計するのが望ましいです。
• メモリーオーバーコミット(メモリが余っているVMからメモリを借用する機能)を使用する場合は、バルーンドライバーがインストールされている必要があります。Linuxでは「lsmod | grep virtio-balloon」でモジュールの確認が可能です。Windowsの場合、NGTのバージョン2.1.1以降をインストールしなけらばballoonドライバーはインストールされていません。
• このメモリーオーバーコミットはHA有効時は使用不可となります。HAを有効化すると、AHVホストに障害が発生した場合に備えてメモリを予約することを踏まえると納得ですね。メモリを予約することで、他のAHVホストで必ずVMが再起動します。デフォルトはベストエフォートです。
• また、Failoverやマイグレーションが発生した場合、対象のVMのメモリーオーバーコミット機能は無効化されます。MOVEでVMを移行した場合も無効化されます。以下のコマンドで有効化できます。

nutanix@CVM：acli vm.update VMNAME memory_overcommit=true

参考となりますが、NGT(Nutanix Guest Tool)の状態を確認する場合は下記のコマンドとなります。

nutanix@CVM：ncli ngt get vm-id=UUID

Agent VM

GUIでVMを作成する時にゲストVMの設定をするためのチェックボックスがあると思います。この設定を有効化すると、VMが稼働しているAHVノードがダウンした場合、他のノードで再起動されません。ダウンしたAHVノードがUPすると、agent VMはそのノード上で再度稼働し始めます。

注意事項

• agent VMはADSによるリソース状況を踏まえたライブマイグレーションは行われません。
• (関連)CPU passthroughを有効化したVMもADSによるリソース状況を踏まえたライブマイグレーションは行われません。割と使用する頻度の多いこの機能は以下のコマンドで設定可能です。

nutanix@CVM：acli vm.update VMNAME cpu_passthrough=true

#確認は以下の方法で
nutanix@CVM：acli vm.get VMNAME or UUID

vUMA VM

仮想マシンで使用されるCPUやメモリが必ずNUMAノードに収まるように設定された仮想マシンのことを指します。高い性能が求められる仮想マシンでは、設定をするか検討するべきでしょう。virshコマンドでCVMの仮想マシンイメージの定義ファイルを確認することができます。

root@AHV：virsh dumpxml CVM-name

それを見ていただくと分かる通り、vUMAとなっております。

高度な設定とはなりますが、既存の仮想マシンをどうしても特定のNUMAノードに配置したい場合は下記コマンドを使用します。

nutanix@CVM：acli vm.update VMのUUID extra_flags=numa_pinning= 0 or 1

ただし、NUMAノードが2つある場合しか設定できません。

詳しい設定例や実行結果については以下のドキュメントを確認ください。非常に良いドキュメントです。

Nutanix Support & Insights

portal.nutanix.com

vUMAの推奨設計

• vUMA  VMでは、物理メモリの半分のメモリを使用するならば、CPUのコア数もそのAHVホストのCPUの物理コア数の半分を使用することが推奨されています。
• vUMAを使用するならば、全てのクラスターで同じCPU、メモリサイズで構成することが推奨されています。ただし、これはVM-Host affinityを設定してCPUやメモリが少ないノードで動作させないようにすれば回避可能です。

vNUMA VM

vNUMAとは、物理ノードのNUMAノードの構成を仮想マシンに認識させる機能です。

NUMAノードが2つ以上あることが前提となりますが、1NUMAノードでCPUもしくはメモリが収まりきらない場合(一般的にはモンスターVMやWide VMと呼ばれます）には、vNUMAを仮想マシンに設定することで、CPUがinterconenctを経由してメモリにアクセスさせないことを保証します。ただし、仮想マシンのOSとミドルウェアがvNUMAを認識できないと意味がありません。認識可能な場合も、個別に設定を入れる必要がある場合が多いです。対象製品の公式ドキュメントを参照して対応可否と有効化方法などを確認してください。

vNUMA VMを新規に作成するコマンドは以下の通りです。引数に注意してください。

nutanix@CVM：acli vm.create <VMname> num_vcpus=<X> num_cores_per_vcpu=<X> memory=<X>G num_vnuma_nodes=<X>

vNUMAの推奨設計

• vNUMAを使用するならば、全てのクラスターで同じCPU、メモリサイズで構成することが推奨されています。ただし、これはVM-Host affinityを設定してCPUやメモリが少ないノードで動作させないようにすれば回避可能です。

注意点

vUMAやvNUMAを設定したVMは以下の仕様や推奨事項があります。

• 手動でライブマイグレーションを行うことができません。
• メンテナンスやHA発動時はライブマイグレーションされます。
• ADSの対象外となります。つまり、リソース状況を踏まえながら自動でVMを他のノードに移動させることはありません。
• vNUMA VMはCVMとは別に、1つのAHVホストで動作させるべきです。つまり、vNUMA VMとCVMのみが1つのノードに存在する構成が推奨されます。
• 1つのNUMAノードで利用可能なメモリサイズを超えたVMを作成することは不可です(作成はできます）。vNUMAやvUMAは1つのNUMAノード内のメモリが足りない場合は起動しません。
• 1つのNUMAノードで利用可能なCPU数を超えたVMは作成可能で起動も可能です。ただし、推奨されません。
• vNUMA VMではメモリオーバーコミットを有効化することができません。

参考

Nutanix Support & Insights

portal.nutanix.com