VMware NSX 4.1 Upgrade Coordinator によるアップグレード手順と通信への影響について

企業ICT環境におけるネットワーク仮想化基盤 VMware NSX® の運用について

企業ICT環境において、仮想環境のセキュリティを含めたネットワーク仮想化基盤として導入が大きく伸長している VMware NSX® となりますが、運用の観点で重要な項目としては、基盤のセキュア化やライフサイクル管理の観点で、適切なタイミングでのアップグレードの必要性が挙げられます。
NSXには Upgrade Coordinatorという VMware NSX^® Manager™ に内蔵されたアップグレード用ツールがあり、こちらを利用して VMware NSX^® Edge™、VMware ESXi™ホスト及び NSX Manager をアップグレードする事が可能です。今回は VMware NSX 4.1 におけるアップグレードの手順と、アップグレード時における仮想マシン トラフィックへの影響を、検証にて確認しましたのでご紹介させていただきます。

Upgrade Coordinator によるVMware NSX® のアップグレード手順

VMware NSX 4.1 における Upgrade Coordinator によるアップグレードの手順 は以下の順番になります。

• 事前チェック用アップグレードバンドル（.pubファイル）のダウンロードと実行
• アップグレードバンドル（.mubファイル）のダウンロードと、Upgrade Coordinator のアップグレード
• NSX Edge のアップグレード
• ESXi ホストのアップグレード
• NSX Manager のアップグレード

まず事前チェックにより、システムがアップグレードの前提条件を満たしている事を確認します。続いてアップグレードバンドルをダウンロードの上、Upgrade Coordinator 自体のアップグレードを実施し、次に NSX Edge のアップグレード、ESXi ホストのアップグレード、NSX Manager のアップグレードの順で実行し、アップグレードを完了します。

なお本記事においては NSX 4.1.1 からNSX 4.1.2.1 へのアップグレードの実施手順と、各作業の所要時間及び仮想マシントラフィックへの影響についてご紹介いたします。

また、仮想マシントラフィックへの影響に関する検証構成は下記の通りとなります。Tier-0 ゲートウェイ 配下の仮想マシンから外部ルータへの通信確認により North-South 通信（L3通信、以下 N-S通信 と表記）への影響を確認します。また、Tier-0ゲートウェイ 配下の同一セグメントに接続された仮想マシン間における通信確認により、 East-West 通信（L2通信、以下 E-W通信 と表記）への影響を確認します。なお通信影響に関しては、それぞれ100 msec 間隔の Ping における応答速度を確認するものとします。

Upgrade Coordinator によるNSXのアップグレード

• NSX Manager 管理UI の [システム] > [アップグレード]から、アップグレード対象のバージョン（4.1.2.1）を選択の上、 事前チェック用のアップグレードバンドル を VMwareポータル よりダウンロードもしくは、ローカル環境にダウンロードしたものをアップロードします。

• 事前チェックを実行し、Edge、ESXiホスト、NSX Manager において成功する事を確認し、次に進みます。（事前チェックの要件には、DRSが完全自動化である事や、直近2日以内の NSX Manager のバックアップの取得等が含まれます）

• アップグレードバンドルをダウンロードします。

• Upgrade Coordinator のアップグレード を実施します。

• Edgeのアップグレード を実施します。Edgeクラスタ が複数ある場合は、Edgeクラスタ のグループ間で並行してのアップグレードもしくは、順番でのアップグレードを選択可能です。今回は Edgeクラスタ は1つの為、デフォルトの [並行] でも[連続] でも実施時間に差はありません。

• 完了後 [次へ] でホストのアップグレードに進みます。

• ホストのアップグレード を実施します。ホストのアップグレード には以下の2種類があります。
  • メンテナンスモード：ホストをメンテナンスモードに切り替え、アップグレードを実施します。仮想マシンは VMware vSphere^® Distributed Resource Scheduler™ (DRS) によりVMware vSphere^® vMotion^® で移行されます。
  • インプレースモード：ホストはメンテナンスモードに切り替わらずアップグレードを実施し、アップグレード後の切り替えに短時間のパケットロスが発生します。複数のホストで並行したアップグレードが可能となり、アップグレード作業時間の短縮が見込めます。インプレースモードでの実行には、vSphereクラスタが VMware vSphere^® vSphere Lifecycle Manager クラスタではない事と、その他に前提条件があります。

• NSX Manager のアップグレード を実施します。

• NSX Manager のアップグレードが終了し、NSX のアップグレード作業が完了します。

アップグレードにおける所要時間と、N-S通信 及び E-W通信 への影響について

Upgrade Coordinator の各作業における所要時間と、N-S通信 及びE-W通信 への通信影響（100msec間隔のPingにおける応答速度を計測）については下記の通りとなります。

なお、事前チェックとUpgrade Coordinator 及び NSX Manager のアップグレードに関しては、NSX Manager の1台構成に加えて、NSX Manager の3台クラスタ構成についても検証を実施しました。NSX Edgeに関しては前述の構成図の通り、Edgeノード1台におけるTier-0 A/A 構成と、Edgeノード2台における Tier-0 A/S HA VIP構成、及び Tier-0 A/A 構成の3パターンについて確認し、ホストに関してはインプレースモード 及び メンテナンスモード について確認しています。

• アップグレード時のダウンタイムに関する考察：

事前チェック及び Upgrade Coordinator のアップグレード作業においては、仮想マシンの通信には影響はありません。

Edgeノードのアップグレードにおいては、Edgeノードが1台で冗長構成が無い場合に、検証環境におけるN-S通信 においては10分程度の断時間が発生しています。Tier-0 A/S 及び Tier-0 A/A構成 の場合は、アップグレード対象のEdgeノードの切り替え時に、ミリ秒単位の遅延が発生しています。

ホストのアップグレードにおいては、インプレースモードにおいて、ホストのアップグレード後の切り替えのタイミングで1秒程度の断時間が発生し、メンテナンスモードにおいては、vMotion 後の切り替えのタイミングでミリ秒単位の遅延が発生しています。また、検証構成はホストが2台と少数である為、インプレースモードによる作業時間の短縮効果は確認出来ておりません。

NSX Manager のアップグレード時のダウンタイムについては、仮想マシンの通信はNSX Manager を経由しない為、影響を受けていない様子が確認出来ます。

まとめ

今回は VMware NSX® の運用関連のツールとして、Upgrade Coordinator によるアップグレード機能とトラフィックへの影響についてご紹介させていただきました。本機能をご利用いただく事で、Edgeノードに冗長構成が無い場合を除いて、NSX内部の通信及び外部との通信に大きな影響が無く、アップグレードを実施いただく事が可能となります。
弊社では今後も、VMware NSX® を始めとしたクラウド環境における最適なインフラ基盤の構築、運用をご支援させていただきます。

VMware社 製品担当者様から、本記事へのコメント

旧バージョンと比べて、メンテナンスモードとインプレースアップグレードの差分が縮まってきていることにお気づきかと思います。大規模環境ではメンテナスウィンドウを縮める有効な手立てとなりますので、NSX版ISSUとしてのインプレースアップグレード、今後もご期待ください。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。