NutanixからNutanixへの移行考慮点（その4・既存クラスターと異なるメディア構成）

前回は、5年を超える古いクラスターからのNutanix to Nutanixの移行方法をご紹介しました。今回はまた別のケースの移行パターンをご紹介します。

移行課題その4 / 既存クラスターと異なるメディアのクラスターへリプレース

5年前は、SSD+HDDのハイブリッドクラスターが非常に多く採用されていました。これは、まだフラッシュメディアが高価であったことが要因であると思います。

2025年現在では、フラッシュの単価も5年前に比べ安くなったことからオールSSD構成やオールNVMeモデルの構成もあたり前に検討・導入される時代になってきました。
Nutanixにおける異なるメディアで構成されたクラスター間での移行方法についてご紹介します。

方法1.Expand Cluster + Remove Hostによるリプレース

Nutanixの最もメリットの出るリプレース方法なのですが、違うメディアで構成されたノードをExpand Clusterを行うためには、条件があります。

まず、既存の構成と新しく追加するノードの混在条件です

構成種別	既存クラスターの構成	ノード追加がサポートされる構成
ハイブリッド構成	SSD+HDD	SSD+HDD NVMe+HDD All SSD
	SSD+HDDとAll SSDの混在	All SSD
	SSD+HDDとNVMe+HDDの混在	NVMe+HDD
	NVMe+HDD	NVMe+HDD
オールフラッシュ構成	All SSD SSD+NVMeハイブリッド All NVMe	All SSD SSD+NVMeハイブリッド All NVMe

上記表に記載される構成がサポートされる構成です。例えば、既存はSSD+HDDのハイブリッド環境で、新しくリプレースするノードがAll NVMeモデルである場合、Expand Clusterによるノード追加によるリプレース作業はサポートされないということになります。

既存のSSD+HDD構成のクラスターにAll SSDノードを追加する場合、Expand Clusterによる移行方法がサポートされます。

メディアの種別が異なる場合は、上記表を元にノード追加がサポートされる構成かを事前に確認しておく必要があります。

（参考）Mixing Nutanix Nodes in a Cluster

▼条件を満たしていれば、Expand Cluster + Remove Hostをサポート

方法2.Async DRの利用

Async DRであれば、メディアの制限を受けることはありません。そのため、SSD+HDDの環境から、All NVMeのクラスターにレプリケーションし仮想マシンを移行する方法が利用可能です。

▼メディアに関係なくAsync DRは移行可能

方法3.Nutanix Moveを利用した仮想マシン移行

Nutanix Moveは、ハイパーバイザーの種別にもハードウェアのメディア構成にも影響を受けません。そのためMoveでの移行は、サポートされます。（MoveがサポートしているAOSバージョンであれば、バージョンに関係なく利用可能です）

方法4.Cross Cluster Live Migration

AOSやAHVのバージョンが同一であることが条件ですが、この条件に適合している場合は、Cross Cluster Live Migrationによる無停止移行が可能です。

既存クラスターと異なる環境の場合、Expand Clusterによる1クラスターに統合した移行を行う場合、1クラスターに混在できるハードウェアの種別に制限があります。1クラスターでメディア混在ノードの継続運用ではなく、一時的な移行であってもメディア混在のノードを拡張する場合は、注意を行ってください。

NutanixからNutanixへの移行考慮点（その3・5年を超える古いクラスターからの移行）

前回は、別のハードウェアメーカーへのリプレースを行う際の移行方法をご紹介しました。今回は、また別のケースをご紹介します。

移行課題その3/ 古いハードウェアからのリプレース

日本文化においては、7年保守での利用が見受けられます。一方で海外では3年保守、長くても5年の保守が一般的で、技術進化の観点からも、ソフトウェアも5年サイクルでの互換性を重視して設計されています。Nutanixにおいても同様で、5年を過ぎたソフトウェアからの移行に関しては、ダイレクトに移行できることが考慮されていないケースがあります。

たとえば、Nutanix NXモデルにおいては、1クラスターにおいて4世代までの混在がサポートされるというルールになっています。

▼Nutanix NXモデルの場合の世代混在ルール

この図で行くと、NX G5で構成されたクラスターにG9のモデルを混在させることは、原則できません。原則というのは、例外的にAOSが、G5とG9のモデルで同じバージョンがサポートされている場合は、例外的に同一クラスターに混在できる許可を盛られる場合もあります。（詳細は、Nutanixの営業に相談してください）

このような場合の移行についてもご紹介します。

方法1.Async DRの利用

この選択は、既存クラスターと新規クラスター（リプレース先）がメーカーサポート期間であるバージョンであれば、利用が可能です。

方法2.Nutanix Moveの利用

Nutanix Moveが一番柔軟性の高い移行方法かもしれません。こちらであれば、Async DRのレプリケーションが可能なAOSのコンパチビリティを気にすることなく移行することができます。

今回のケースでは、G5のモデルで対応するAOSでは、Cross Cluster Live Migrationに対応していないので、以上の2つが選択肢となります。今後のモデルで上記4世代ルールであったとしても、同一のAHVバージョンで双方のクラスターが稼働している条件があるため、1つのクラスターに混在ができない古いノードで構成されているクラスターとの間では、クラスター間でのライブマイグレーションは厳しい可能性が高いです。

（参考）Product Mixing Restrictions

NutanixからNutanixへの移行考慮点（その2・既存クラスターと異なるハードメーカーへのリプレース）

前回は、ESXiが導入されたNutanixクラスターからAHVのNutanixクラスターへの移行方法をご紹介しました。今回は、別のケースでの移行方法をご紹介します。

移行課題その2 / ハードウェアメーカーの変更

方法1.Async DRの利用

Nutanixは、1つのクラスター内には、1社のハードウェアメーカーで固定するルールがあります。例えばExpand Clusterで、既存Nutanix NXで構成されたクラスターにDELL XC Coreのモデルを追加しようとしても、エラーが発生しノード追加ができない仕様になっています。

そのため、ハードウェアメーカーを変更する場合同じハイパーバイザーであったとしても

この場合、Async DRを使った移行が最もメリットが高い移行方法になると思います。

AHV to AHVなので仮想マシンの変換も特に行うことなく移行を行うことができます。
スケジュール設定で定期的にスナップショットを転送しておくことと、Migrate機能を利用することで、データ差分を生まず簡単に移行ができます。また、移行切替えにおける時間も短い時間で行うことができます。

▼Async DRを使った移行

方法2.Nutanix Moveを使った移行

Nutanix Moveは、最新版のVer 6.0で確認する限り、AHV to AHVでの移行もサポートされています。（サポートされたのはMove 4.x時代だったと思いますが..）元々は、異種ハイパーバイザーからAHVへの移行ツールとして作られた製品ですが、移行環境が様々出てきたことからいろんなシーンでの移行に対応出来るように進化しています。

Moveを利用すれば、定期的なスナップショット差分を利用した移行で、移行元の仮想マシンを稼働させたまま移行データを新クラスターに配置し、最終のCutoverで切替えを行うため、短い停止時間で切替えを行うことができます。

▼Nutanix Moveを使った移行

方法3.Cross Cluster Live Migration

仮想マシンを停止せずに移行する方法としては、唯一の方法としてCross Cluster Live Migration機能があります。この機能を利用すれば、クラスター間で、仮想マシンを停止せずライブマイグレーションを利用して仮想マシンを移行することができます。

但し以下の条件があります。

• AOS 6.7以降が必要（vTPM要件がある場合は、AOS 6.8以降）
• Prism Central 2023.3以降（vTPM要件がある場合は、Prism Central 2024.1以降）が必要です。
• 2つのクラスターで物理CPUが異なる場合（リプレースは大半そうだと思いますが）、AOS 6.8以降が必要です。
• 2つのクラスターのAHVバージョンが同じである必要があります。
• 移行元と移行先で同じ名前のストレージコンテナが存在する必要があります。
• Volume Groupが接続された仮想マシンは、移行できません。
• メモリーオーバーコミットが有効化された仮想マシンは、移行できません。
• vNUMAが構成された仮想マシンは、移行できません。
• 双方のクラスターにNCI-Pro以上ライセンスが必要です

▼Cross-Cluster Live Migrationを利用した無停止移行

今回は、ハードウェアメーカーを変更したNutanixクラスターの移行についてご紹介しました。ハードウェアメーカーを変更すると、クラスター内でノードの追加・取り外しによるリプレースができませんので、違う方法を検討する必要があります。

 

NutanixからNutanixへの移行考慮点（その1・Nutanix+ESXiからNutanix+AHVへの移行）

2015年から本格的にNutanixが日本市場に浸透し、Nutanixを新規で導入するユーザーが爆発的に増えている最近ですが、一方でNutanixからNutanixへの移行というフェーズも多く見かけるようになりました。10年前と違いNutanixで選択できる幅が大きく増えていることから、改めてNutanixからNutanixへの移行について見ていきたいと思います。

移行課題その1
ESXiからAHVへのハイパーバイザー変更

方法1.Convert Clusterによる変換後のExpand Cluster+Remove Host

2020年前後までは、Nutanix+vSphere ESXi環境で稼働している環境も多かったのではないでしょうか？VMwareの買収もあり、vSphereからNutanix AHVへの移行を検討されている場合増えています。この場合、Nutanixの既存のクラスターに追加ノードでAHVのノードを追加し移行するという構成が組めません。

この場合2つの方法があります。

1つは、既存のNutanixクラスターをConvert ClusterでESXi上で稼働しているクラスターをAHVにハイパーバイザーを変更します。（仮想マシンは、NGTがインストールされていることが前提となりますが、そのままAHVで稼働する仮想マシンに変換されます）

コンバート完了後、AHVクラスターになった状態で新規ノードを追加し、リプレース対象のノードをRemoveすることで、リプレースを完了することができます。

この場合、ESXiからAHVにコンバートする際に、ハイパーバイザーの入れ替えやCVMの作り替えが行われるため、Foundationを行うのと変わらないぐらいの時間（3ノードであればおよそ1時間程度）かかります。さらに内部でVMDKをRAW形式に変換する動作を行いますので、それなりにクラスターの停止時間がかかってしまいます。

▼既存クラスターのハイパーバイザー変換

コンバートが変更した後、追加ノードを入れて1つのクラスターにします。

▼Expand ClusterでAHVクラスターとして6ノード構成にする

その後、古いノードをRemove Hostで外すことで、新しいノードのみで継続稼動させることができます。

▼Remove Hostで古いノードの切り離しを行う

方法2.Async DRの利用

こちらが移行としては、時間がかからない方法の1つであると思います。クラスター間のレプリケーションであるAsync DRを設定し仮想マシンの移行ができます。こちらを利用すれば、Prismの操作画面のみで簡単に仮想マシン単位で移行計画を作ることができます。

NGTがインストールされていない場合、Async DRのMigrate機能ボタンがPrism上では押せませんが、ncliで「skip-vm-mobility-check」パラメータを利用すれば、NGTのインストール有無に関係なく仮想マシンの移行ができます。（NGTをインストールしていない場合、ゲストOSにVirtIO Driverがインストールされていないため仮想マシンのOSが正しく起動できない可能性があります。その場合事前にVirtIO Driverのインストールを行ってください。）

方法3.Nutanix Moveを利用した仮想マシン移行

Nutanix to Nutanix移行であってもハイパーバイザーが異なる場合、Nutanix Moveを利用して移行することができます。

移行元のNutanixクラスターと移行先のNutanixクラスターを設定することで、Nutanix Moveのメリットを生かした仮想マシン単位かつ移行時間をカットオーバー機能で自由に制御できます。

▼Moveを使った仮想マシンの移行

今回は、Nutanix+ESXi環境からの移行についてご紹介しました。ハイパーバイザーが異なるからNutanixでも移行は無理みたいな印象がある方に出会うことがありますがそのようなことはなく、Nutanixの良さを生かした移行が可能です。

次はまた違う移行パターンについてご紹介します。