はじめに
あけましておめでとうございます。
2025年もよろしくお願いします。
早速ですが、2025年に”おそらく”リリースされるであろう、EVS（Elastic VMware Service）に備えるというシリーズです。
Elastic VMware Serviceはまだリリースされていないため、GAのタイミングで変わる可能性があります。
本BlogはEVSのSelf Managedの部分に備え、NSXのアップグレードを行う手順を簡単にまとめたものです。
本番で適用される場合はしかるべき有識者がきちんと評価をした上で行ってください。
ちなみに、Previewは申し込んでみました・・・（当たるかは分からない）
EVSとは（ちょっとおさらい）
- 2025年11月末（re:Inventの前）に突然発表される
- AWSが提供するVCFベースのVMware基盤サービス
- ユーザVPCの内部でデプロイされる
- フル権限をユーザに渡す。（administrator@vsphere.localとか、ESXiのrootとか）
- セルフマネージドとパートナーマネージドが選択可能
- i4i.metal x 4ホスト構成からスタート
- オンデマンド・1年RI・3年RIで利用可能
- ライセンスはBYOSかインクルードされた状態で提供される
- 東京でリリースがいつになるかは不明
- Previewを開始している（USで提供されるらしい）
このうち、VMware Cloud on AWS（VMC）を利用しているユーザが気にしているは赤線の部分
（カスタマー or パートナーマネージドという部分）
VMCを利用しているユーザがEVSで意識すること
VMwareとAWSが共同で開発を行ったVMware Cloud on AWSはフルマネージドのサービスとなります。
VMware ManagedのVPCにデプロイされ、特殊なENI経由でSDDCに接続されますが、最大のメリットは
- NSX-Tを知らなくても触れる
- フルマネージドのためパッチ運用やアップグレードなどを考える必要がない
- 基盤の監視運用は不要
VMware Cloud on AWSは、Cloud Service Consoleからセグメントの作成や分散FWの変更ができるため、NSXのコンソールに触らなくても利用することが可能です。（ネットワーク周りはNSXのUIに抜粋ですが・・・）
フルマネージドのため、vCenter、ESXi、NSXのパッチ導入やアップグレードはサービスが実施します。（HCXだけユーザが実施する必要はあります。）
基盤監視もユーザが意識する必要はありません。
逆にElastic VMware Service（EVS）は、上記の通りカスタマーまたはパートナーマネージドのため、NSXを触る必要があることと、パッチ導入やアップグレードをユーザまたはパートナーが実施する必要があります。
NSXのアップグレードを意識する必要がある。
VMware Cloud on AWSもElastic VMware ServiceもオンプレミスでVMware基盤を利用しているユーザが利用する前提のサービスです。オンプレミスの場合、基盤のパッチ導入などもユーザが行っており、vCenterやESXiのパッチ導入は慣れているユーザも多いと思いますが、NSXのアップグレードはほとんどのユーザが行っていないと思いますがEVSを利用するにあたり、NSXのアップグレードは意識しておく必要があります。
NSXのアップグレードを実際の作業中の画面を使って紹介
ようやく本題です。EVSを利用する時に必要なナレッジであるNSXのアップグレードを実施していきます。
NSXは仮想ネットワークのサービスで、失敗するとネットワークが止まってしまうため、慎重に実施する必要があります。今回はオンプレミスで動いているNSXのパッチ導入を行った画面をベースに、作業中の画面を用いて紹介していきます。
EVSはGAしていないため、現時点でどのようにUIが提供されるかは明らかになっていません。
NSXのコンポーネントについて
NSXの機能や詳細はこちらをご参考ください。NSX-TではなくNSX-Vの頃の本ですが基本機能はこちらが一番わかりやすいと思います。（私も実は持っていて読みました）
https://amzn.asia/d/6LguOO7
NSX自体は非常に多くの機能を保有しており、Blogですべて説明するのは不可能です。
ここでは、VMCやEVSを利用するにあたり意識する必要があるところを、本当に簡単に書いておきます。
NSX Manager
NSX ManagerはNSXを管理するコントローラです。
1台でも動作しますが、本番環境は3台で動かすのが必須です。
3台のうちの1台が代表で仮想IPをもちますが、どこにログインしても操作可能です。
（こちらはラボ環境のため1台のみ稼働しています。本番だと横に3セット並んでいます）
Edgeトランスポートノード
仮想基盤上で稼働するネットワークアプライアンスです。2台1ペアのクラスタで動作します。Edgeトランスポートノードは外部ネットワークと接続するインターフェースを保有します。大規模な環境だと物理サーバでEdgeトランスポートノードを動かす事も可能です。
なお、Edgeクラスタ＝テナント（トランスポートノード）という考え方が一番理解しやすいです。VMCやEVSは専用利用のため、Edgeクラスタは”おそらく”1つのみになると想定します。オンプレだと複数のEdgeクラスタを用いてマルチテナント的な利用もできます。
（こちらは2つEdgeクラスタが動いています）
ESXi
NSXが有効化されたESXiは分散仮想スイッチ上にUSXセグメントも表示されます。
ユーザがNSXを意識することはありません。他のVDSのVLANセグメントと同様、透過的な扱いが可能となります。
（vCenterのネットワークタブのNSXが有効化されたVDSの画面です）
なお通常のVLAN作成はvCenter側のUIで可能ですが、NSXのセグメントはNSX Managerで実施します。
NSXをアップグレードする
事前準備
NSXのアップグレードはこちらのガイドを見ながら進めることが可能です。
https://docs.vmware.com/en/VMware-NSX/4.2/upgrade/GUID-E04242D7-EF09-4601-8906-3FA77FBB06BD.html
アップグレードパスはこちらになります（NSXで検索しています）
https://interopmatrix.broadcom.com/Upgrade?productId=912
パッチの入手はBroadcomのSupport Portalから（ログインが必要です）
Precheck BundleとUpgrade Bundleの2つの入手が必要です。
アップグレード画面へのアクセス
こちらの画面はオンプレで動くNSXの画面です。
NSX Managerの管理画面からアップグレードにアクセスします。
PreCheck Bundleをアップロードし、Precheckを実施します。
PreCheck Bundleは拡張子がpubのファイルです。
Upgrade Bundleをアップロードし、アップグレードを実施します。
Upgrade Bundleは拡張子がmubのファイルです。
実際のアップグレード
アップグレードは、Edge → ホスト（ESXi）→ NSX Managerの順番に進んでいきます。
Edgeは冗長構成が組まれている場合は片方ずつローリングアップデートされます。（ネットワークは瞬断レベル）
ホストはDRSが有効な場合は、アップグレード対象のホストで稼働しているVMを自動的にvMotionで移動した上で、メンテナンスウインドとなりアップグレードが実行されます。
NSX Managerは3台稼働している場合は1台ずつアップグレードされます。こちらも自動的に1台ずつ停止しながらアップグレードが実施されます。
アップグレード開始画面
Edgeアップグレード画面
アップグレード開始ボタンでEdgeのアップグレードが開始されます。
Edgeアップグレード完了
ホストアップグレード開始
ホストアップグレード完了
今回のアップグレードで、ホストのメンテナンスモードから抜けるところでタイムアウトがすべてのホストで発生してしまったので、アラート解除→リトライで対応完了しています。（画面は完了後）
From-version: 4.2.1.0.0.24302016
To-version: 4.2.1.1.0.24405896
NSX-Managerアップグレード開始
NSX-Managerアップグレード完了
まとめ
- NSXのアップグレードはコンポーネントの数も多いためファイルが別れている
- Edge -> Hosts -> NSX-Managerの順番にアップグレードされる
- 途中でエラーがでると停止する。トラブルシューティングが必要
- トラブルシューティング時にAPIを利用するケースがある（curlなりapidogなり必要）
- ワークロードは原則停止しない。（vMotionなどで回避できる）
まだEVSがGAされていませんが、GAしたらぜいこのあたりも評価出来たらと思います。