こんにちは、
SB C&S プリセールスエンジニアの戸高です。

私は、これまで約7年間、インフラエンジニアとしてVMware、Nutanixなどの仮想化基盤に携わり、設計・構築から運用保守まで一通り経験してきました。

そんなVMwareとNutanixの両方に携わってきたエンジニアの視点から、今回は「VMwareからNutanixへ移行すると、インフラエンジニアの設計や運用はどう変わるのか？」をテーマにお話ししたいと思います。

本記事は、「VMwareからNutanixへ ― インフラエンジニアが実際に感じた設計・運用の違い」中編です。

前編では「設計」「管理」「アップデート」を中心にご紹介しました。

中編では、障害対応・可用性・ネットワークなど、より実際の運用に近い部分について、私自身の経験も交えながらご紹介していきます。

今回も、単純な機能比較ではなく、

「VMwareではこうしていたけれど、Nutanixではどうする？」

というエンジニア目線で見ていきたいと思います。

---

目次（中編：障害対応・可用性・ネットワーク）

1. 前編のおさらい
2. 【障害対応】Pulse・NCCを使った障害対応はどう変わる？
3. 【可用性】VMの移行やHAの考え方はどう変わる？
4. 【ネットワーク】vSphereのネットワーク設計から何が変わる？
5. 【まとめ】障害対応・可用性・ネットワークから見えた違い

---

1．前編のおさらい

前編では、VMwareからNutanixへ移行すると、インフラエンジニアの設計や日々の運用がどのように変わるのかについて、まずは「設計」「管理」「アップデート」の3つの観点からご紹介しました。

簡単におさらいしてみましょう。

◆ 設計 ― VMwareの構成をそのまま置き換えない

設計では、単純に「ESXiをAHVへ置き換える」と考えるのではなく、Nutanixのアーキテクチャや実現したい要件に合わせて基盤全体を考えることが重要だとお伝えしました。

例えば、

• ESXiを継続するのか、AHVへ移行するのか
• 何ノード構成にするのか
• 障害時の縮退運転をどこまで考慮するのか
• RFやストレージ容量をどう設計するのか
• ネットワークをどう構成するのか
• 既存の周辺製品を継続して利用できるのか

など、現在のVMware環境のスペックや構成をそのままNutanixへ当てはめるのではなく、

「なぜ現在この構成になっているのか？」

という要件まで戻って考えることがポイントでした。

◆ 管理 ― Prismを起点にNutanix基盤全体を見る

日々の管理では、vSphere Client / vCenter ServerからPrismへ管理インターフェースが変わります。

VMの作成や電源操作、Live Migrationなどの基本的なVM操作だけでなく、Prismではクラスタ、AHVホスト、CVM、ストレージ、ハードウェアの状態、アラートなど、Nutanix基盤全体の状態を確認できます。

一方で、Prismだけですべての管理が完結するわけではありません。

物理サーバーそのものの状態確認や操作が必要な場合には、BMCなどのハードウェア管理インターフェースを利用するなど、目的に応じた使い分けも必要になります。

◆ アップデート ― LCMで便利になるが、事前確認は変わらず重要

アップデートでは、LCM（Life Cycle Manager）を利用することで、AOSやAHVなどのソフトウェアだけでなく、対応するハードウェアのファームウェアなども含めてライフサイクルを管理できる点をご紹介しました。

Inventoryや事前チェック、依存関係の確認などによってアップデート作業を効率化できますが、

「1クリックでアップデートできる＝何も確認しなくてよい」

というわけではありません。

リリースノートや既知の問題、互換性、アップグレードパス、周辺製品への影響などを事前に確認したうえで、計画的にアップデートすることが重要です。

◆ では、実際の運用ではどう変わる？

前編を通してお伝えしたかったのは、VMwareで培ったインフラエンジニアとしての考え方は、Nutanixでも活かせるということです。

一方で、製品や機能の名称、操作方法、アーキテクチャには違いがあります。

そのため、

「VMwareの○○はNutanixの何？」

と単純に機能を置き換えるのではなく、

「現在その機能を何のために利用しているのか？」
「その要件をNutanixではどのように実現するのか？」

という視点で考えることが重要です。

では、実際にNutanixを運用していくとどうでしょうか。

中編では、

• 障害が発生したとき、どのように切り分け・サポート連携を行うのか
• vMotionやvSphere HAで行っていた運用はAHVではどうなるのか
• vDSやNSXを利用していたネットワークはどう考えるのか

といった、より実際の運用に近い部分について、私自身の経験も交えながら見ていきたいと思います。

UPS・バックアップ・DRなどの周辺運用については、後編で実際の経験談も交えながらご紹介します。

2.【障害対応】Pulse・NCCを使った障害対応はどう変わる？

ここまではPrismやNCCを使った日常的な管理について紹介しました。

では、実際にNutanix環境で障害が発生した場合、どのように切り分けを行い、Nutanixサポートへ問い合わせるのでしょうか。

ここでは機能の紹介だけではなく、障害を検知してからNutanixサポートへケースを発行するまでを、実際の運用をイメージしながら見ていきます。

① まずはPrismで障害・アラートを確認する

例えば、日々の運用中にPrismでアラートを検知したとします。

まず確認したいのは、

• いつ発生したのか

• どのノード・VM・ディスクなどで発生しているのか

• Critical / Warningなどの重要度

• 現在も事象が継続しているのか

• VMやサービスへの影響があるのか

といった情報です。

いきなり再起動などの対処を行うのではなく、まずは「何が起きていて、どこまで影響しているのか」を確認します。

---

② NCCでクラスタの健全性を確認する

次に、必要に応じてNCC（Nutanix Cluster Check）を使用してクラスタの健全性を確認します。

NCCではNutanixクラスタに対して複数のチェックを実行できるため、障害発生時の切り分けだけでなく、日常的なヘルスチェックにも利用できます。

例えばアラートが発生している場合、

Prismで事象を確認
↓
NCCを実行
↓
PASS / WARN / FAILなどの結果を確認
↓
該当するチェック項目を確認

という流れで切り分けていきます。

ここで重要なのが、NCCの結果だけで障害原因を決めつけないことです。

NCCで問題が検出された場合は、そのチェック内容を確認し、必要に応じてNutanix KBなどから原因や推奨される対応方法を調べます。

③ KBを確認して、自分で対応できる事象か判断する

NCCの結果やPrismのアラートから関連するNutanix KBを確認します。

公開されているKBから、

• 事象の内容

• 発生条件

• 影響

• 確認方法

• 対処方法

などを確認し、自分たちで対応可能な事象なのか、サポートへ問い合わせるべき事象なのかを判断します。

ただし、すべての情報が一般公開されているとは限りません。

また、KBに手順が記載されていたとしても、本番環境で影響が判断できない操作を自己判断で実施するのは避けた方がよいケースもあります。

その場合は、Nutanixサポートへ問い合わせます。

④ サポートへ問い合わせる前に情報を整理する

サポートへケースを発行する前に、まず事象について整理しておきます。

例えば、

• 事象が発生した日時

• 対象クラスタ / ノード / VM

• Prismに表示されたアラート

• ユーザーやVMへの影響

• 事象が現在も継続しているか

• NCCの実行結果

• 確認したKB

• すでに実施した切り分け・対処

などです。

ここはVMwareサポートへ問い合わせる場合と大きく変わらず、「何が起きたのか」「何を確認したのか」「何をしてほしいのか」を整理しておくことで、その後の調査が進みやすくなります。

Point. ログバンドルも準備しておく

障害調査ではログの確認が必要になるケースが多いため、必要に応じてログバンドルを取得しておきます。

ケース発行時に必要な情報やログを準備しておくことで、サポートとの最初のやり取りを減らし、調査をスムーズに進めやすくなります。

ただし、事象によって必要となるログは異なるため、判断が難しい場合はサポートの案内に従います。

⑤ Pulseを有効化している環境ではどう変わる？

ここでNutanixならではの機能として紹介したいのがPulseです。

Pulseを利用すると、Nutanix環境の診断情報などをNutanix側へ送信し、プロアクティブなサポートやトラブルシューティングに活用できます。

そのため、サポートへ問い合わせる際にも、環境の情報をサポート側と連携しやすくなるメリットがあります。

私自身、運用という観点では、このような「障害が起きてから情報を集め始める」のではなく、サポートとの連携を考慮した仕組みがあらかじめ用意されている点は便利だと感じています。

また、24時間365日対応のサポートをご契約されている場合もあると思います。

その際、1次対応をNutanix側へ依頼できるため、常に自社のオペレーターを常駐させたり担当者が携帯を待機させたりしなくともよく、運用体制の代替策（負担軽減策）としても有効です。

⑥ ただし、Pulseを使うための前提も考えておく

Pulseは便利な機能ですが、導入時に考えておきたいのが外部接続です。

セキュリティ要件などによってインターネットへ接続できない環境では、Connected環境と同じようにPulseを利用できるとは限りません。

そのため、設計段階で、

「この環境ではPulseを利用できるのか？」

「利用できない場合、障害発生時にどのようにログや情報をサポートへ渡すのか？」

まで考えておくことが重要です。

Point. 障害が起きてからサポート方法を考えない

障害発生時は、できるだけ早く原因を特定して復旧したいものです。

そのタイミングになって初めて、

「Pulseは使える？」

「ログはどう取得する？」

「サポートサイトへ誰がケースを発行する？」

と確認していると、初動が遅れてしまいます。

そのため、障害対応の方法やサポートへの問い合わせフローについても、構築時や運用設計の段階で決めておくことをおすすめします。

▼実際の障害対応フローをまとめると

Nutanix環境での障害対応をシンプルにまとめると、例えば次のようになります。

① Prismで障害を検知
↓
② 事象・影響範囲を確認
↓
③ 必要に応じてNCCを実行
↓
④ NCCの結果・Nutanix KBを確認
↓
⑤ 自分たちで対応可能か判断
↓
⑥ 必要な情報・ログを準備
↓
⑦ Nutanix Supportへケースを発行
↓
⑧ サポートと連携して調査・復旧

VMware環境でも「アラートを確認して、ログを調査し、必要に応じてサポートへ問い合わせる」という基本的な考え方は変わりません。

NutanixではそこにPrism、NCC、Pulseといった仕組みをどのように組み合わせて運用するかがポイントになります。

※画像は、イメージです。実際の画面と異なります。

Point. Pulseを利用するためのネットワーク要件も事前に確認する

Pulseを利用するためには、Nutanix環境から必要な宛先へ通信できることが前提となります。

インターネットへ直接接続できる環境だけでなく、プロキシサーバーを経由する環境では、Nutanix側にプロキシを設定して通信させる構成も可能です。

また、セキュリティ要件によってインターネットへの通信が制限されている環境でも、Nutanixが指定する宛先URLやポートへの通信を許可することで、Pulseを利用できる構成があります。

そのため、設計段階で、

• インターネットへ直接通信できるのか

• プロキシサーバーを経由する必要があるのか

• ファイアウォールで必要な宛先・ポートへの通信を許可できるのか

といった点も、ネットワーク・セキュリティ担当者と確認しておくことをおすすめします。

特に閉域環境や外部通信が厳しく制限されている環境では、「Pulseを使いたいが必要な通信を許可できない」とならないよう、構築前に通信要件まで確認しておくことが重要です。

参考KB：

Insights Portal - Pulse Status and Troubleshooting

▼実際の障害ケースで比較してみる

では、実際に私が経験したケースを例に、障害発生からサポートへ問い合わせるまでの流れを見てみたいと思います。

今回は、「ある1ノードの1ディスクに異常が発生した」ケースを想定します。

Pulseを設定していない場合と、設定している場合で、運用がどのように変わるのか比較してみます。

▼ Pulseを設定していない場合

あるノードのディスクで障害が発生したとします。

ディスク障害が発生
↓
Prismにディスク関連のCriticalアラートが表示される
↓
アラートメールや監視オペレーターからの連絡、定期点検などで障害に気付く
↓
Prismから対象ノード・ディスクを確認
↓
VMやクラスタへの影響を確認
↓
必要に応じてNCCを実行し、クラスタの健全性を確認
↓
NCCの結果や関連するKBを確認
↓
自己判断でディスクを抜いたり交換したりせず、Nutanixサポートへケースを発行
↓
必要なログを取得・提供
↓
サポートによる調査
↓
交換が必要な場合は、配送先や担当者、交換作業の日程などを調整
↓
サポートの案内に従ってディスクを交換

このように、障害そのものを検知できたとしても、そこから「確認 → 切り分け → ケース発行 → ログ提供 → 交換調整」と、運用担当者が対応する作業が発生します。

また、アラートメールや監視システムなどを用意していない環境では、定期点検でPrismを確認した際に初めて障害に気付く、といったことも考えられます。

その場合、障害が発生してから実際に対応を開始するまでに時間が空いてしまう可能性があります。

ハードウェア交換が必要になれば、その後も交換部品の配送先や作業日時などについて、サポートとのやり取りが発生する場合があります。

▼ Pulseを設定している場合

では、Pulseを有効にしている場合はどうでしょうか。

Pulseを有効にすると、クラスタの構成情報や診断情報などがNutanixへ送信され、Nutanix Insightsによる分析やプロアクティブなサポートに活用されます。

また、対象となる障害アラートについては、Nutanix側で自動的にサポートケースが作成される仕組みがあります。

例えば今回のような対象となるディスク障害であれば、イメージとしては、

ディスク障害が発生
↓
Prismでアラートを検知
↓
障害情報がNutanix側へ連携
↓
対象となるアラートの場合、サポートケースを自動作成
↓
必要な診断情報・ログを利用してNutanix Supportが調査
↓
登録されているサポートコンタクトへ連絡
↓
必要に応じて交換部品の手配・交換対応

という流れになります。

つまり、運用担当者が、

「障害に気付く」
「サポートサイトへログインする」
「ケースを作成する」
「最初の切り分け情報を一から説明する」

といった作業の一部を減らせる可能性があります。

Nutanixの公式資料でも、PulseとInsightsによって重要な問題を検知した場合、サポートケースの自動作成や関連ログの収集が行われ、必要に応じて交換部品の手配につながる仕組みが紹介されています。

Point. Pulseを有効にしたら、すべての障害対応が自動化されるわけではない

ここは注意したいポイントです。

すべてのアラートで自動的にサポートケースが作成されるわけではなく、対象となるアラートについて自動ケース作成が行われます。

また、実際の交換作業や日程調整、障害による業務影響の判断など、人が対応・判断しなければならない部分は残ります。

そのため、

「Pulseを有効にすれば運用担当者が不要になる」

ということではなく、

「障害検知からサポートへつなぐまでの初動を自動化・効率化できる」

という捉え方がよいと思います。

▼24時間365日の運用を考えると？

個人的にPulseのメリットを感じるのは、24時間365日の運用を考えた場合です。

例えば深夜にハードウェア障害が発生した場合、従来の運用では、

監視で検知 → オペレーターから担当者へ連絡 → 担当者が状況確認 → サポートへ問い合わせ

といった運用を組むことがあります。

Pulseを有効にし、自動ケース作成の対象となる障害であれば、Nutanix側へ障害情報を連携してサポート対応につなげられるため、障害検知からサポートへの連携を補完する仕組みの一つとして活用できます。

もちろん、システムの重要度によっては24時間365日の監視体制やオンコール体制そのものが必要です。

そのためPulseを監視の完全な代替として考えるのではなく、既存の監視・運用体制と組み合わせて、障害対応の初動を効率化する仕組みとして考えるのがよいと思います。

特定通信をファイアウォールで許可するなど、環境に応じた設定が必要です。

詳細については下記blogをご参考いただければと思います。

参考blog:

Nutanixを裏から支えるInsightsとPulseのご紹介

Nutanixの自動通報サービスについてのご紹介

3.【可用性】VMの移行やHAの考え方はどう変わる？

VMwareからNutanix AHVへ移行する際、

「vMotionはどうなる？」
「vSphere HAと同じようなことはできる？」
「DRSで行っていたVMの配置はどうなる？」

といった点が気になる方も多いのではないでしょうか。

名称や仕組みには違いがありますが、「VMを停止せずに別ホストへ移動したい」「ホスト障害時にVMを復旧させたい」「クラスタ内のリソースを効率よく利用したい」といった、インフラエンジニアが実現したいこと自体は大きく変わりません。

ここでは、VMの移行やHAなど、可用性に関する違いを見ていきます。

① vMotionに相当するVM移行はどうする？

VMwareではvMotionを利用して、稼働中のVMを別のESXiホストへ移行できます。

AHVでもLive Migrationを利用することで、稼働中のVMをクラスタ内の別AHVホストへ移行できます。

そのため、ホストのメンテナンスなどで、

「VMを停止せずに別ホストへ退避させたい」

という基本的な運用の考え方は、VMware環境と大きく変わりません。

vSphere Clientに慣れていると最初は操作方法の違いに戸惑うかもしれませんが、Prismから対象のVMを選択してLive Migrationを実施できます。

Point. vMotionとLive Migrationを完全に同じものとして考えない

vMotionとLive Migrationは、稼働中のVMを別ホストへ移行するという目的は似ていますが、仕組みや要件、制約までまったく同じというわけではありません。

そのため、

「vMotionに相当する機能があるか？」

だけではなく、

「現在vMotionを何のために利用していて、その要件をAHVではどのように実現するのか？」

という視点で確認することが重要です。

ライブマイグレーションの概要、操作方法については、下記blogをご参照ください。

参考blog:

若手SEと学ぶ！Nutanixの基本機能 ライブマイグレーション

---

② ホストが突然停止したらVMはどうなる？ ― HA

Live Migrationは計画的にVMを別ホストへ移行する場合に利用できます。

では、Live Migrationする余裕もなく、AHVホストが突然停止した場合はどうなるのでしょうか。

VMwareではvSphere HAによって、障害が発生したESXiホスト上で稼働していたVMを、クラスタ内の正常なESXiホストで再起動させることができます。

AHVにもHAの仕組みがあり、ホスト障害が発生した場合、影響を受けたVMをクラスタ内の正常なホストで再起動させることができます。

ここで押さえておきたいのが、Live MigrationとHAでは利用する場面が異なるという点です。

計画的なホスト停止・メンテナンス
→ Live Migrationなどを利用してVMを別ホストへ退避

予期しないホスト障害
→ HAによって別ホスト上でVMを再起動

というように考えると分かりやすいと思います。

Point. HAがあるからリソース設計を考えなくてよいわけではない

HAによって別ホストでVMを再起動するとしても、残りのホスト側にVMを稼働させるためのCPUやメモリなどのリソースが必要になります。

そのため、設計時には通常時に必要なリソースだけではなく、1ノード障害時などの縮退運転でも必要なVMを稼働できるかを考慮してサイジングしておくことが重要です。

これは前編の「2.【設計】基盤設計の考え方はどう変わる？」でも触れた、ノード構成を検討する際のポイントにつながります。

---

③ DRSに慣れているとAHVではどう考える？

VMware環境では、vSphere DRSを利用してクラスタ内のリソース状況を確認し、VMの配置や移行によってリソース利用を最適化している環境もあると思います。

Nutanix AHVにも、VMの配置やリソース競合を管理する仕組みとしてAcropolis Dynamic Scheduling（ADS）があります。

ただし、

「DRS ＝ ADS」

と単純に置き換えて考えない方がよいでしょう。

ADSでは、クラスタ内のリソース状況を継続的に監視し、CPUやストレージI/Oなどで持続的なリソース競合（ホットスポット）が発生している場合に、VMを別のAHVホストへ移動するなどして競合の解消を図ります。

そのため、クラスタ内の各ノードが安定して稼働している状態であれば、単純に各ノードの使用率を均等にすることを目的としてVMを移動させるわけではありません。

例えば、特定のAHVホストでCPU負荷が継続的に高くなり、そのホスト上で稼働しているVMのパフォーマンスへ影響する可能性がある場合には、ADSがリソース状況を確認し、ホットスポットを解消できると判断すればVMの移動を行います。

Point. 「きれいに均等化する」よりも「リソース競合を回避する」という考え方

VMware環境でDRSを利用している場合は、単純に「DRSの代わりとしてADSがある」と考えるのではなく、現在DRSでどのような運用を実現しているのかを整理したうえで、ADSとの動作や考え方の違いを確認しておくことが重要です。

参考：

AHV 管理ガイド:AHV における Acropolis ダイナミックスケジューリング

AHV 11.2のドキュメントでは、CPUホットスポットについて、過去10分間の平均ホストCPU使用率を確認し、その期間中85%を超えた状態が継続した場合（一定期間継続した高負荷を見て判断）に、ADSがホットスポット解消のための移行タスクをトリガーすると説明されています。

※詳細な仕様や動作については、ご利用のバージョンに対応する最新のNutanix公式ドキュメントをご確認ください。

---

④ ホストをメンテナンスするときはどうする？

日々の運用では、ハードウェア交換やメンテナンスなどで、特定のホストを計画的に停止することがあります。

VMware環境では、

ESXiホストをメンテナンスモードへ移行
↓
必要に応じてVMを他のESXiホストへ移行
↓
ホストのメンテナンスを実施
↓
メンテナンス完了後に通常運用へ戻す

といった運用をしていた方も多いと思います。

Nutanix AHVでも、ホストをメンテナンスする際には、稼働しているVMへの影響を考慮して別ホストへ退避させるなど、安全にメンテナンスを実施するための手順があります。

Nutanixの場合は各ノード上でCVM（Controller VM）も稼働しているため、VMだけではなくNutanixクラスタ全体への影響を考えながらメンテナンスを実施する必要があります。

Point. メンテナンスだからといって、いきなりホストを停止しない

VMwareでもNutanixでも、計画停止の基本的な考え方は変わりません。

事前にVMやクラスタの状態を確認し、必要なワークロードを退避させたうえで、安全にホストを停止・メンテナンスすることが重要です。

◆VMwareからNutanixへ移行して、可用性の考え方は大きく変わる？

ここまで見てきた内容を簡単に整理すると、以下のようになります。

やりたいこと	VMware	Nutanix AHV
稼働中VMを別ホストへ移行	vMotion	Live Migration
ホスト障害時にVMを復旧	vSphere HA	AHVのHA
VM配置・リソースの最適化	DRS	ADS
ホストの計画メンテナンス	Maintenance Mode	AHVでもメンテナンス時の退避を考慮

名称や実装方法、操作方法には違いがありますが、インフラエンジニアが実現したいこと自体は意外と大きく変わりません。

VMwareからNutanixへ移行する際に重要なのは、

「vMotionの代わりは何？」
「DRSの代わりは何？」

と、VMwareの機能とNutanixの機能を1対1で置き換えて考えることではないと思います。

私自身、VMwareとNutanixの両方の基盤を運用してきましたが、日常的な運用における可用性という観点では、「VMwareではできていたのに、Nutanixではこの機能がなくて困った」と感じる場面は、これまであまりなかったと記憶しています。

もちろん、VMwareとNutanixでは機能の名称や仕組み、細かな仕様には違いがあります。

そのため、単純に機能の有無だけを比較するのではなく、「現在のVMware環境で何を実現しているのか」「その要件をNutanixではどのように実現するのか」という視点で比較することが重要だと感じています。

4.【ネットワーク】vSphereのネットワーク設計から何が変わる？

VMwareからNutanix AHVへ移行する際、個人的に確認しておきたいポイントの一つがネットワークです。

VMware環境では、vSphere Standard Switch（vSS）やvSphere Distributed Switch（vDS）を利用し、VLANやNIC Teamingなどを設計している環境も多いと思います。

また、環境によってはNSXを利用して、マイクロセグメンテーションなどを実装しているケースもあります。

では、AHVへ移行した場合、これまでvSphereで実現していたネットワークをどのように考えればよいのでしょうか。

今回はネットワークの詳細なアーキテクチャには踏み込まず、VMware環境から移行する際に押さえておきたいポイントを見ていきます。

① 仮想スイッチはどうなる？

VMwareでは、vSSやvDSを利用してESXiホストとVMのネットワークを構成します。

AHVにも仮想スイッチがあり、物理NICと仮想マシンのネットワークを接続する役割を持っています。

そのため、

VM → 仮想スイッチ → 物理NIC → 物理スイッチ

という基本的な考え方は、VMware環境を経験しているエンジニアであればイメージしやすいと思います。

一方で、VMwareのvSS/vDSとAHVの仮想スイッチでは、設定方法や管理方法、利用できる機能などに違いがあります。

そのため、単純に、

「vDSをAHVの仮想スイッチに置き換えればよい」

と考えるのではなく、現在vDSでどのような機能を利用しているのかを整理することが重要です。

Point. まずは「vDSを使っている」ではなく「vDSで何をしているか」を確認する

既存環境を確認するときには、

• VLAN

• NIC Teaming

• MTU

• Link Aggregation

• ポートグループ

• トラフィック制御

など、現在どのような設定・機能を利用しているのかを確認します。

そのうえで、それぞれの要件をAHVではどのように実現するのかを考えていきます。

---

② VLANの考え方は大きく変わる？

VMware環境では、Port GroupなどにVLAN IDを設定し、VMを目的のネットワークへ接続しているケースが多いと思います。

AHVでも、VMを接続するネットワークを作成し、VLANを利用してネットワークを分離できます。

そのため、VLANを利用した基本的なネットワーク分離という考え方自体は、VMware環境から大きく変わるものではありません。

ただし、設定する場所や操作方法は異なるため、vSphere Clientでの操作に慣れている場合は、Prism上でどのようにネットワークを作成し、VMへ割り当てるのかを確認しておく必要があります。

Point. Nutanixだけを見ず、物理スイッチ側の設計も確認する

仮想基盤側でVLANを設定しただけでは通信できません。

ToRスイッチなどの物理ネットワーク側でも、必要なVLANやMTU、物理ポートなどが正しく設定されている必要があります。

これはVMwareでもNutanixでも基本的には同じです。

---

③ 物理NICの冗長化はどう考える？

Nutanix AHVでは、複数の物理NICを利用してネットワークを冗長化できます。

AHVのデフォルト仮想スイッチ（vs0）は、Active-Backupのアップリンクボンドタイプがデフォルトで設定されており、Nutanixのドキュメントでも推奨構成とされています。

例えば10GbE NICを2本利用するActive-Backup構成の場合、通常時は1本のActive NICで通信し、NICや接続先に障害が発生した場合には、もう一方のNICへ切り替えることで通信を継続します。

この場合、ホストとして利用できる最大帯域は10Gbpsとなります。

一方、より多くの帯域が必要となる環境では、Active-Activeを利用する選択肢もあります。

AHVでは、主に以下のようなBond Typeを選択できます。

Bond Type	特徴
Active-Backup	デフォルト・推奨構成、通常時は1つのActive NICを利用
Active-Active（MAC Pinning）	VM NICを複数の物理NICへ分散し、ホスト全体として帯域を活用
Active-Active（LACP）	LACP/LAGを利用してTCP/UDPセッションを物理NIC間で負荷分散

Point. 「NICが2本あるからLACP」ではなく、本当に必要かを考える

Nutanixではデータローカリティ（できるだけネットワークを利用しない設計）の考え方があり、可能な場合にはVMが稼働するノード上のデータをローカルで処理することで、不要なクラスタ間通信を抑える仕組みになっています。

そのため、

「NICが2本あるからLACPにして、両方の帯域を使おう」

と最初から決めるのではなく、

• VMが必要とするネットワーク帯域
• ノード間通信
• Live Migration時の通信
• バックアップ・レプリケーション通信
• 障害時の通信量
• 将来的なワークロード増加

などを踏まえ、Active-Backupで要件を満たせるのか、Active-Activeが必要なのかを判断することが重要です。

◆Active-Active / LACPを利用する場合の注意点

Active-Active / LACPを採用する場合は、AHV側だけで設定が完結するわけではありません。

AHV側でLACPを設定するとともに、各ノードに接続されているToRスイッチ側でもLAG/LACPを設定する必要があります。

また、LACPフォールバックやLACPタイマーなどについても考慮する必要があります。

つまり、LACPを利用することで帯域を有効活用できる一方で、Active-Backupと比較すると物理スイッチを含めて考慮すべき設計・設定項目が増えることになります。

そのため、

「LACPを構成した方が高性能だから採用する」

ではなく、

「この環境で必要となる帯域と冗長性を満たすために、本当にLACPが必要なのか？」

という要件から判断することをおすすめします。

参考：

AHV 管理ガイド:仮想スイッチ ワークフロー

---

④ NSXを利用している場合はどうする？

VMware環境によっては、NSXを利用しているケースもあると思います。

例えば、

• マイクロセグメンテーション

• 分散ファイアウォール

• ネットワーク仮想化

• セキュリティポリシー

などです。

AHVへ移行する場合、ここは特に注意して確認したいポイントです。

NutanixにもFlow Network Securityなど、ネットワークセキュリティを実現するための機能があります。

ただし、

「NSX ＝ Flow」

と単純に置き換えて考えるべきではありません。

NSXにはさまざまな機能があるため、現在のVMware環境でNSXのどの機能を利用しているのかを整理し、その要件をNutanix環境ではどのように実現するのかを確認する必要があります。

例えば、

「NSXを導入しています」

だけではなく、

「NSXの分散ファイアウォールを利用して、VM間のEast-West通信を制御しています」

というところまで要件を整理します。

そのうえで、Nutanix側の機能で実現するのか、物理ネットワークや外部のネットワーク・セキュリティ製品と組み合わせるのかを検討します。

Point. 製品名ではなく、現在実現している要件から考える

これはネットワークに限った話ではありませんが、VMwareからNutanixへ移行する際には特に重要だと感じています。

「NSXを使っているからFlowへ移行する」のではなく、

「なぜNSXを導入したのか？」
「現在どの機能を利用しているのか？」
「その機能によって何を実現しているのか？」

まで整理したうえで、Nutanix環境での実現方法を検討することが重要です。

私自身、VMware NSXの設計・構築に携わってきました。

NSX経験者の目線でAHVやNutanix Flowを触ってみると、考え方や操作方法、実現方法など、「ここはNSXと違うな」と感じるポイントもあります。

今回はネットワーク全体の概要に留めますが、NSX経験者から見たAHVのネットワークやNutanix Flowとの違いについては、今後の記事で実際の操作や構成も交えながらご紹介できればと思います。

参考blog:

Nutanix Flowによるマイクロセグメンテーションとは

Flowで不労で振り切ろう！Flow Network Securityでマルウエアを隔離せよ！！【NTCセミナー #2】（2022/8/25配信）

---

⑤ ネットワーク移行で事前に確認しておきたいこと

VMwareからNutanixへ移行する際には、既存環境のネットワーク設定を一度棚卸ししておくことをおすすめします。

例えば、

• 現在使用しているVLAN

• vSS / vDSの構成

• Port Group

• MTU

• NIC Teaming

• 物理NICの構成

• ToRスイッチの構成

• Link Aggregationの利用有無

• NSXの利用有無

• NSXで利用している具体的な機能

• 外部ファイアウォールやLoad Balancerなどとの接続

などです。

既存環境の設定をそのままNutanixへコピーするのではなく、「この設定は何のために存在しているのか？」を確認しながら整理すると、Nutanix環境で本当に必要なネットワーク設計が見えてきます。

◆VMwareからNutanixへ移行して、ネットワーク設計は大きく変わる？

VMwareからNutanix AHVへ移行すると、仮想スイッチの名称や設定方法、管理画面などは変わります。

一方で、

「VLANでネットワークを分離する」
「物理NICやスイッチを冗長化する」
「VMを必要なネットワークへ接続する」

といった、インフラエンジニアとして考える基本的なネットワーク設計がまったく別物になるわけではありません。

私自身もVMwareとNutanixの両方を触る中で、基本的なネットワークの考え方については、VMwareで培った知識をNutanixでも活かせる部分が多いと感じています。

ただし、vDS固有の機能やNSXなどを利用している環境については注意が必要です。

「VMwareで使っている製品・機能をNutanixの何に置き換えるか」ではなく、「その機能で何を実現しているのか」を確認し、Nutanixではどう実現するのかを考える。

ネットワークについても、この考え方が移行時の重要なポイントになると思います。

5.【まとめ】障害対応・可用性・ネットワークから見えた違い

今回は中編として、VMwareからNutanixへ移行した際の違いについて、「障害対応」「可用性」「ネットワーク」の3つの観点からご紹介しました。

障害対応では、Prismでのアラート確認からNCCによる健全性チェック、KBの確認、Nutanix Supportへの問い合わせといった基本的な流れに加え、Pulseを活用することで障害検知からサポート連携までの初動を効率化できることをご紹介しました。

可用性については、vMotionとLive Migration、vSphere HAとAHVのHA、DRSとADSなど、名称や仕組みに違いはあるものの、「VMを停止せずに移行したい」「ホスト障害時にVMを復旧させたい」「リソースを効率よく利用したい」といった、エンジニアが実現したいこと自体は大きく変わりません。

ネットワークについても、vSS・vDS・NSXなどをNutanixの機能へ単純に置き換えるのではなく、「現在その機能で何を実現しているのか？」という要件から考えることが重要です。

私自身、VMwareとNutanixの両方を経験して感じているのは、製品や機能、操作方法は変わっても、インフラエンジニアとして考える基本的な部分は大きく変わらないということです。

VMwareで培った知識をベースに、

「VMwareのこの機能はNutanixの何？」ではなく、「この要件をNutanixではどう実現する？」

という視点で考えることが、移行するうえで重要なポイントだと思います。

次回の後編では、UPS・バックアップ・DRなど、仮想基盤だけでは完結しない周辺運用について取り上げます。

また、私自身が過去の設計・構築で経験した事例も交えながら、「Nutanix/AHVに対応している」だけでは分からない、製品選定や設計時に注意したいポイントについてもご紹介したいと思います。