こんにちは、
SB C&S プリセールスエンジニアの戸高です。
私は、これまで約7年間、インフラエンジニアとしてVMware、Nutanixなどの仮想化基盤に携わり、設計・構築から運用保守まで一通り経験してきました。
そんなVMwareとNutanixの両方に携わってきたエンジニアの視点から、今回は「VMwareからNutanixへ移行すると、インフラエンジニアの設計や運用はどう変わるのか？」をテーマにお話ししたいと思います。
本記事は、「VMwareからNutanixへ ― インフラエンジニアが実際に感じた設計・運用の違い」後編です。
中編では「障害対応」「可用性」「ネットワーク」を中心にご紹介しました。
後編では、UPS・バックアップ・DRなど、より実際の運用に近い部分について、私自身の経験も交えながらご紹介していきます。
今回も、単純な機能比較ではなく、
「VMwareではこうしていたけれど、Nutanixではどうする？」
というエンジニア目線で見ていきたいと思います。
目次（後編：UPS・バックアップ・DRなどの周辺運用）
1．中編のおさらい
中編では、VMwareからNutanixへ移行した際の違いについて、「障害対応」「可用性」「ネットワーク」の3つの観点からご紹介しました。
障害対応では、Prismでのアラート確認からNCCによる健全性チェック、Nutanix KBの確認、サポートへの問い合わせといった一連の流れに加え、Pulseを活用した障害対応やサポート連携についてご紹介しました。
可用性では、VMwareのvMotionやvSphere HA、DRSに対して、Nutanix AHVではLive MigrationやHA、ADSなどを利用します。名称や仕組みには違いがありますが、「VMを停止せずに移行したい」「ホスト障害時にVMを復旧させたい」といった、実現したいこと自体は大きく変わらないという点についてお伝えしました。
ネットワークでは、vSS・vDS・NSXなどをNutanixの機能へ単純に置き換えるのではなく、
「現在その機能で何を実現しているのか？」
という要件から、AHVではどのように実現するのかを考えることが重要だとご紹介しました。
では、仮想化基盤そのものだけではなく、その周辺で動いている仕組みや製品についてはどうでしょうか。
実際の環境では、UPSによる停電時のシャットダウン、バックアップ、DRなど、仮想化基盤と連携するさまざまな仕組みがあります。
後編では、こうした「UPS・バックアップ・DRなどの周辺運用」に焦点を当て、私自身が設計・構築で経験した事例も交えながら、VMwareからNutanixへ移行する際に確認しておきたいポイントをご紹介します。
2.【その他の運用】UPS・バックアップ・DRなど、移行前に確認しておきたいこと
ここまで、設計、日々の管理、アップデート、障害対応、可用性、ネットワークといった観点から、VMwareからNutanixへ移行した場合の違いについて見てきました。
ただし、実際に仮想化基盤を運用するうえでは、これら以外にも考えておかなければならないことがあります。
例えば、
-
UPSを利用した停電時の自動シャットダウン
-
バックアップ
-
DR（災害対策）
などです。
VMwareからNutanixへ移行する際には、仮想化基盤だけを見るのではなく、現在VMware環境と連携している周辺製品や運用についても、Nutanix/AHVへの移行後に継続できるのかを確認しておくことが重要です。
今回は、それぞれ簡単に触れておきたいと思います。
① UPS ― 停電時のシャットダウンはどうする？
データセンターやサーバールームなどのオンプレミス環境では、UPSを利用している環境も多いと思います。
VMware環境では、オムロンやSchneider ElectricなどのUPSと連携し、停電を検知した際にVMやESXiホストを安全にシャットダウンする仕組みを構築しているケースがあります。
Nutanix環境でもUPSを利用することはできますが、ここで重要なのがNutanixクラスタをどのような手順で安全にシャットダウンするのかという点です。
Nutanixでは各ノード上にAHVだけでなくCVM（Controller VM）も稼働しており、クラスタとして動作しています。
そのため、単純に、
「VMを停止 → AHVホストを停止」
だけを考えるのではなく、Nutanixとして推奨されるクラスタの停止手順を考慮してUPSとの連携方法を設計する必要があります。
Point. VMwareで使っていたUPSだから、そのまま使えるとは限らない
既存のUPSを継続して利用する場合は、UPS本体だけでなく、シャットダウンソフトウェアなどがNutanix/AHVに対応しているのか確認しておくことが重要です。
オムロンやSchneider Electricなど、利用する製品によって対応方法や構成が異なるため、製品・バージョン・構成を含めてメーカーの対応状況を確認することをおすすめします。
💡 実体験から学んだポイント
UPS連携は「対応製品だから大丈夫」ではなかった
ここでは、私自身がインフラエンジニアとしてUPS連携を設計・構築した際の経験から、注意しておきたいポイントをご紹介します。
過去に、複数のNutanixクラスタをUPSと連携させ、自動的にシャットダウンさせる構成を担当したことがあります。
当初は、電源管理製品の標準機能を利用して複数のクラスタを制御する想定で設計していました。
しかし、実際に構築を進めていく中で、採用した製品のライセンスや構成上の制約により、当初想定していた方法ではすべてのクラスタを制御できないことが分かりました。
そのため、一部のシャットダウン処理については、別の方法を組み合わせて補完する構成へ変更することになりました。
もちろん、シャットダウン処理を別途用意すれば終わり、というわけではありません。
停電を検知したら、どの順番でVMを停止するのか？
CVMやクラスタはどのタイミングで停止するのか？
途中で処理が失敗した場合はどうするのか？
実際に想定した順番で安全に停止できるのか？
など、追加で確認・検証しなければならないことが増え、特に結合テストではかなり苦労した記憶があります。
Point. UPS連携は構築段階ではなく、製品選定の段階から確認しておく
この経験から私自身が感じたのは、UPSについては単純に、
「このUPSや電源管理製品はNutanix/AHVに対応しているか？」
だけを確認するのでは不十分だということです。
例えば、
-
管理対象となるクラスタ数
-
電源管理サーバーの構成
-
必要となるライセンス
-
複数クラスタの制御可否
-
VM・クラスタ・物理サーバーの停止順序
-
製品の標準機能でどこまで自動化できるのか
-
標準機能で実現できない場合の補完方法
-
異常終了した場合のリカバリ方法
といったところまで、製品選定・要件定義の段階で確認しておくことをおすすめします。
私自身、この経験では構築段階で制約が分かったため、後から運用を補完する仕組みの設計と追加の検証が必要になりました。
UPSは仮想化基盤そのものと比べると、設計時に後回しになってしまうこともあるかもしれません。
しかし、停電時にインフラ全体を安全に停止させるという重要な役割を担っています。
だからこそ、Nutanix本体だけではなく、UPS、電源管理ソフトウェア、ライセンス、実際のシャットダウンフローまで含めて、早い段階から設計しておくことが重要だと、実際に苦労した経験から感じています。
参考blog:
Nutanix × オムロンUPS VirtuAttendant バージョン2.1.0
② バックアップ ― Veeamなどの既存製品はそのまま使える？
VMware環境では、Veeamをはじめとしたバックアップ製品を利用している環境も多いと思います。
AHVへ移行する場合、
「現在利用しているバックアップ製品がAHVに対応しているか？」
は必ず確認しておきたいポイントです。
例えばVeeamにもNutanix AHV環境を保護するための仕組みがありますが、VMware環境とAHV環境ではバックアップの仕組みや構成、利用できる機能などが同じとは限りません。
そのため、
「Veeamを使っているからNutanixへ移行してもそのまま大丈夫」
と考えるのではなく、
-
利用しているVeeam製品・エディション
-
Nutanix AHVへの対応状況
-
AOS / AHVとの互換性
-
必要となるライセンス
-
バックアップ・リストア要件
-
既存のバックアップデータをどう扱うか
などを事前に確認します。
Point. バックアップ製品名ではなく「現在何を実現しているか」を確認する
例えば現在のVMware環境で、
「VM全体をバックアップしている」
だけではなく、
「どのくらいのRPO/RTOが必要なのか」
「ファイル単位でリストアする必要があるのか」
「アプリケーション整合性が必要なのか」
「バックアップデータをどこに、どのくらい保存するのか」
といった要件まで整理しておくことが重要です。
💡 実体験から学んだポイント
「AHV対応」と「やりたいバックアップ構成ができる」は別だった
ここでも、私自身がバックアップ設計で経験した失敗談を一つご紹介します。
過去に担当した設計で、D2D2T（Disk to Disk to Tape）構成によるバックアップを設計したことがあります。
この環境では、メインクラスタとは別にバックアップ用のクラスタがあり、NutanixのDR機能を利用してバックアップ側へデータを複製していました。
当初の想定では、
メインクラスタ
↓
NutanixのDR機能で別クラスタ／複製先へ複製
↓
別クラスタ／複製先側のデータをバックアップ製品から取得
↓
最終的にテープへ保存
という構成を考えていました。
ところが導入を進めていく中で、選定していたバックアップ製品では、想定していた方法で別クラスタ／複製先側のデータをバックアップ元として利用できないことが分かりました。
そのため、当初想定していたD2D2T構成をそのまま実現することができず、構成を見直すことになりました。
最終的には、バックアップ製品用のバックアップサーバーへ別途データを取得し、そこからテープへバックアップする構成としました。
結果として、
メインクラスタ
↓
NutanixのDR機能による別クラスタ／複製先への複製
とは別に、
バックアップ対象
↓
バックアップ製品によるバックアップサーバーへのデータ取得
↓
テープへのバックアップ
という形になり、当初の想定よりもバックアップデータを重複して保持する構成となってしまいました。
Point. 「AHV対応」だけではなく、実現したいバックアップ方式まで確認する
この経験から感じたのは、バックアップ製品を選定する際に、
「Nutanix AHVに対応しているか？」
だけを確認するのでは不十分だということです。
例えば、
- どこからバックアップを取得するのか
- どこへバックアップを保存するのか
- Async DRと組み合わせるのか
- バックアップ側のクラスタからデータを取得できるのか
- D2D2Tをどのような構成で実現するのか
- テープへのバックアップに対応しているのか
- リストア時にはどこから、どのような手順で復旧するのか
- 必要となるライセンスやバージョンに制約はないか
といった、実際のバックアップ・リストア運用まで含めて確認しておくことが重要です。
私のケースでは、導入段階で想定していたバックアップ方式が実現できないことが分かり、後から構成を変更することになりました。
バックアップ製品についても、単純な「対応／非対応」だけではなく、「自分たちが実現したいバックアップ構成を、その製品で本当に実現できるのか？」まで製品選定・設計の段階で確認することをおすすめします。
関連blog:
Veeam Backup & Replication v13 Nutanix AHV保護をさらにシンプルに！
関連サイト：
③ DR ― NutanixのAsync DRという選択肢
最後にDR（Disaster Recovery）です。
VMware環境でも、災害やサイト障害に備えて別拠点へVMやデータを複製している環境があると思います。
NutanixにもDRを実現するための機能があり、その一つがAsync DR（非同期レプリケーション）です。
Async DRを利用することで、Nutanixクラスタ間でデータを非同期にレプリケーションし、障害や災害が発生した場合に別サイトで復旧するための構成を検討できます。
ただし、DRを考える際に重要なのは、
「Async DRが使えるからDR対策は完了」
ではないということです。
例えば、
-
どのVMをDR対象にするのか
-
RPO（目標復旧時点）はどの程度必要なのか
-
RTO（目標復旧時間）はどの程度必要なのか
-
拠点間のネットワーク帯域は十分か
-
DR先に必要なリソースがあるか
-
障害時に誰がどのように切り替えるのか
-
切り替え後のネットワークをどうするのか
-
復旧後に元のサイトへどう戻すのか
など、運用を含めた設計が必要です。
Point. DRは「レプリケーションできるか」だけで考えない
VMやデータを別拠点へ複製できても、実際の災害時にシステムを復旧できなければDRとして機能しません。
そのため、レプリケーション方式だけではなく、障害発生から復旧までの運用フローを含めて設計することが重要です。
◆周辺製品も「VMwareで使えているから大丈夫」と考えない
UPS、バックアップ、DRのいずれにも共通して言えるのは、仮想化基盤だけをNutanixへ置き換えて終わりではないということです。
VMware環境を長く運用していると、その周辺にはバックアップ、監視、UPS、DR、セキュリティなど、さまざまな製品や運用が組み合わさっています。
Nutanixへ移行する際には、それらについても、
「現在何を使っているのか？」
↓
「何のために使っているのか？」
↓
「Nutanix/AHVでも利用できるのか？」
↓
「利用できない場合は何で補うのか？」
という順番で整理していくことが重要です。
特に周辺製品については、単純な対応有無だけでなく、AOS/AHVや周辺製品のバージョン、ライセンス、サポート条件まで含めて互換性を確認することをおすすめします。
今回は概要のみの紹介となりましたが、UPS連携やVeeamによるバックアップ、NutanixのAsync DRについても、それぞれ奥が深い内容になります。
機会があれば、実際の構成や運用方法について今後の記事で詳しくご紹介できればと思います。
参考blog：
3.【まとめ】Nutanixへの移行でエンジニアの仕事はどう変わる？
後編では、VMwareからNutanixへ移行する際に見落としやすい「UPS・バックアップ・DRなどの周辺運用」を中心にご紹介しました。
今回の内容を簡単に振り返ってみます。
| 項目 | VMwareからNutanixへ移行する際に押さえておきたいこと |
|---|---|
| UPS | AHV対応だけでなく、ライセンスや管理対象数、実際のシャットダウンフローまで確認する |
| バックアップ | AHV対応だけでなく、実現したいバックアップ・リストア方式に対応できるか確認する |
| DR | データを複製できることだけでなく、RPO/RTOや実際の復旧運用まで含めて設計する |
◆ 基本的な運用の考え方は大きく変わらない
私自身、VMwareとNutanixの両方の基盤を運用してきましたが、Nutanixへ移行したからといって、インフラ運用の基本的な考え方がまったく別物になるわけではないと感じています。
例えば、
- 障害が発生したら影響範囲を確認して切り分ける
- ホスト障害を想定して可用性を設計する
- メンテナンス時にはVMへの影響を考えて退避する
- ネットワークは物理・仮想の両方を考えて冗長化する
- バックアップは取得するだけでなくリストアまで考える
- 災害時にどのようにシステムを復旧するのか決めておく
といった基本的な考え方は、VMwareでもNutanixでも共通しています。
変わるのは、それを実現するために利用する機能や製品、操作方法、そして一部のアーキテクチャや考え方です。
そのため、VMwareで培った設計・構築・運用の経験は、Nutanixでも十分に活かせると感じています。
◆ Nutanixならではの機能をうまく運用に取り入れる
一方で、NutanixにはNCCやPulseなど、日々の運用や障害対応を支援する仕組みがあります。
例えばNCCを利用してクラスタ全体の健全性を確認したり、Pulseを利用して障害検知からNutanix Supportへの連携を効率化したりすることができます。
こうした機能をうまく活用することで、これまで人が行っていた確認やサポート連携の一部を効率化できる点は、Nutanixを運用するうえでのメリットの一つだと感じています。
ただし、
「便利な機能がある＝すべて任せてよい」
というわけではありません。
障害時に誰が対応するのか、Pulseを利用できない環境ではどうするのか、Prismへアクセスできない場合はどこから確認するのかなど、機能が利用できないケースまで含めて運用を設計しておくことが重要です。
◆ 「VMwareの○○はNutanixの何？」だけで考えない
今回、可用性やネットワークについてもご紹介しました。
VMwareからNutanixへ移行すると、
「vMotionの代わりは何？」
「DRSの代わりは？」
「vDSは？」
「NSXはFlowに置き換えればいい？」
と考えたくなると思います。
もちろん、移行を検討するうえで機能比較は必要です。
しかし、単純に機能を1対1で置き換えるのではなく、
「現在、その機能で何を実現しているのか？」
まで戻って考えることが重要です。
例えば、
「vMotionを使っている」
ではなく、
「ホストメンテナンス時にVMを停止せず別ホストへ退避したい」
という要件に戻して考える。
NSXについても、
「NSXを使っている」
ではなく、
「VM間の通信を制御するためにマイクロセグメンテーションを利用している」
という要件まで整理する。
そのうえで、「その要件をNutanixではどのように実現するのか？」を考えることが、移行時の重要なポイントだと思います。
◆ 「対応している」と「やりたいことができる」は同じではない
そして今回、私自身の過去の経験から、UPSとバックアップについて注意しておきたいポイントもご紹介しました。
ここは、今回の記事の中でも特にお伝えしたいところです。
製品選定時に、
「Nutanix対応」
「AHV対応」
と記載されていると、つい「これなら利用できる」と考えてしまいます。
しかし、
「製品としてNutanix/AHVに対応していること」と、「自分たちが実現したい構成・運用に対応していること」は必ずしも同じではありません。
UPSであれば、
「複数のクラスタをどのように安全に停止するのか？」
バックアップであれば、
「DR機能と組み合わせた場合でも、想定しているバックアップ方式を実現できるのか？」
といったところまで確認する必要があります。
私自身、構築を進めてから製品やライセンス、構成上の制約が分かり、後から設計変更や追加検証が必要になった経験があります。
だからこそ、これからNutanixを設計する方には、
「対応しているか？」だけではなく、「自分たちがやりたいことを本当に実現できるか？」
まで、製品選定・要件定義の段階で確認することをおすすめしたいです。
◆ VMwareで培った経験を活かしながら、Nutanixの考え方を理解する
前編・中編・後編を通して、VMwareからNutanixへの移行について、単純な機能比較ではなく、実際に設計・構築・運用するエンジニアの目線からご紹介してきました。
私自身の経験としては、VMwareで培ったインフラの知識や経験は、Nutanixでも十分に活かせると感じています。
一方で、VMwareとまったく同じものとして考えてしまうと、機能やアーキテクチャの違いから戸惑う部分もあります。
そのため、
VMwareの経験を捨てるのではなく、その経験をベースにNutanixの考え方を理解していく。
そして、
「このVMware機能の代わりは何？」ではなく、「この要件をNutanixならどう実現する？」と考える。
この視点が、VMwareからNutanixへの移行を検討するうえで大切なのではないかと思います。
◆ 最後に
今回、前編・中編・後編の3回にわたって、VMwareからNutanixへ移行した際の設計・運用の違いについてご紹介しました。
前編では「設計・管理・アップデート」、中編では「障害対応・可用性・ネットワーク」、そして後編では「UPS・バックアップ・DRなどの周辺運用」について取り上げました。
3回を通してお伝えしたかったのは、VMwareからNutanixへ移行したからといって、これまで培ってきたインフラエンジニアとしての経験が使えなくなるわけではない、ということです。
製品や機能、操作方法は変わっても、
「何を実現したいのか？」
「その要件をどのように設計・運用するのか？」
という基本的な考え方は変わりません。
また、今回ご紹介した内容以外にも、
- LCMを使った実際のアップデート
- PrismやNCCを使った障害調査
- NSX経験者から見たNutanix Flow
- バックアップ・リストア
- UPSとの連携
- Async DRを使ったDR設計
など、それぞれ一つの記事にできるくらい奥が深いテーマがあります。
今後も、私自身がVMwareとNutanixの両方を設計・構築・運用してきた経験を交えながら、
「実際に触ると何が違うのか？」
「設計するときに何に気を付ければよいのか？」
「運用してみるとどこで困るのか？」
といった、カタログや機能比較だけでは分かりにくい部分についてご紹介していければと思います。
最後までお読みいただき、ありがとうございました。
著者紹介
SB C&S株式会社
ICT事業本部 技術本部 第1技術統括部 ソリューション技術部 2課
戸高 翔太 -Shota Todaka-
