VCF5.x から VCF 9.0へのインプレースアップグレード(後編)

みなさま、こんにちは、VMware の知久です。

前回は VCF 5.x から VCF 9.0 へのインプレースアップグレードの前編ということで、VCF 環境をアップグレードする前の事前作業を中心にご紹介しましたが、今回の後編では実際に VCF 5.x の環境を VCF のライフサイクル管理機能を利用して VCF 9.0 へアップグレードする手順をご紹介したいと思います。

前編はこちら
VCF5.x から VCF 9.0へのインプレースアップグレード(前編)

1. SDDC Manager のアップグレード

前編では、SDDC Manager を VCF 9.0 へアップグレードするためのアップデートバンドルのダウンロードまでご紹介しましたが、そのアップデートバンドルを利用して、まずはSDDC Manager を 9.0 にアップグレードするのが最初の手順になります。

VCF Operations にログインし、SDDC Manager の項目を開くと、現在の SDDC Manager 5.x では管理機能が使えない画面と「今すぐアップグレード」ボタンが表示されていますので、こちらをクリックすると、SDDC Manager のライフサイクル管理画面に移動します。

VCF 9.0 へのインプレースアップグレードは VCF Operations から実施するのが原則ですが、対応しているのは、 SDDC Manager が 9.0 以上の場合となるため、SDDC Manager の 9.0 へのアップグレードのみ SDDC Manager の管理 UI を利用して実行します。

図1a： VCF Operations での SDDC Manager アップグレード実行画面

図1b： SDDC Manager での SDDC アップグレード実行画面

1-1. アップグレード事前チェックの実行

SDDC Managerの管理 UIに入り、「ライフサイクル」 → 「 SDDC Manager 」を選択すると、現在の SDDC Manager のバージョンと、アップグレード可能なバージョンの一覧が表示され、その中に “9.0.0.0” が存在しています。

アップデートバンドルのダウンロードが完了している場合、メニューに「今すぐ更新」と「事前チェックの実行」が表示されているので、「事前チェックの実行」をクリックして事前チェックを開始し、結果にエラーや警告が表示されないことを確認します。

エラーや警告、特にエラーが表示されている場合にはアップグレードが失敗する可能性が高くなるため、画面下部分のレポートの項目に発生しているエラー内容の詳細や修正方法が記載されていますので、必ず解消してからアップグレード作業を実施して下さい。

図1-1： SDDC Manager アップグレード事前チェック結果サマリ

1-2. SDDC Manager アップグレードの実行

事前チェックに問題がなければ、もう一つのメニューの[今すぐ更新]をクリックすると画面が切り替わり、SDDC Manager のアップグレードが開始されますので、正常に完了するのを待ちます。

SDDC Manager 自体の更新となるため、途中で画面が表示されなくなる場合がありますが、ある程度時間が経過してから再度ログインし直すと、アップグレードが完了して SDDC Manager が最新である旨が表示されれば、アップグレードは完了しています。

これで SDDC Manager がバージョン 9.0に更新されたので、この後のアップグレード作業は全て VCF Operations から実施することが出来ます。

図1-2： SDDC Manager アップグレード処理のステータス画面

2. VCF 9.0 アップデートバイナリのダウンロード

VCF 9.0 へのアップグレードを実施する前に SDDC Manager 以外の VCF のコアコンポーネントである NSX、vCenter、ESX を9.0にアップグレードするために、これらのコンポーネントのアップデートバイナリを入手する必要があります。

VCF Operations にログインし、「フリート管理」→「ライフサイクル」を開き、表示されたインベントリ内のVCF インスタンス名をクリックすると同インスタンスのライフサイクル管理メニューが表示されるので、バイナリ管理を選択します。

バイナリ管理のメニューでは、VCF のバージョン、バンドルの種類が選択出来ますので、バージョンに9.0、バイナリの種類にアップグレードバイナリを選択すると、対象のバイナリが表示されます。

SDDC Manager は既に前のタスクでダウンロード済みとなるため、残りの NSX、vCenter、ESX を選択してダウンロードを実行し、全てのコンポーネントがダウンロード済みになるのを待って作業が完了になります。

図2： VCF Operations ライフサイクル管理からのアップグレードバイナリのダウンロード

3. 事前チェックの実行

SDDC Manager のアップグレードでも記載しましたが、VCF ではアップグレードが正常に完了するかどうかの事前チェック機能が実装されており、アップグレードをする前にはこのチェックを必ず実施して、エラーや警告が表示されていないことを確認する必要があります。
このチェックでエラーが表示されている場合には、高い確率でアップグレードは失敗しますので、必ず表示されているエラーを解消してから先に進めるようにしてください。

事前チェックの実施手順は、インベントリの一覧からマネジメントドメインを選択すると、選択したドメインのライフサイクル管理のページが表示され、その中に「事前チェックの実行」ボタンがあるので、そちらをクリックします。

事前チェックではアップデートするターゲットバージョンの指定や、事前チェックをするコンポーネントを選択するメニューが表示され、コンポーネント単位で個別にチェックをすることも出来ますが、今回のアップグレードフェーズでは全てのコンポーネントをアップグレードするため、全てのコンポーネントを選択して進めます。
実行すると事前チェックが開始され、終了すると結果が表示されます。

結果には多くのケースで「ベースライン検証の制限」の警告が一件表示されると思います。
これは、VCF 9.0から vSphere Update Manager ( VUM ) をベースとしたライフサイクルポリシーがサポートされなくなり、対象のドメインのライフサイクルポリシーがベースライン管理になっている場合に表示されます。
こちらは vCenter を9.0にアップグレードした後に VUM をベースとしたベースラインから vSphere Lifecycle Manager ( vLCM )をベースとしたイメージベースに変換する作業が必要になりますので、現時点でこの警告は無視して進めて問題ありません。

図3a：アップグレード事前チェックの実行

図3b：アップグレード事前チェックの実行結果

4. アップグレード計画の選択

VCF のアップグレード計画には大きく二つのモードがあります。
一つは純粋なアップグレード計画で、例えば VCF9.0.0を VCF9.0.1や9.1.0の様な標準リリースにアップグレードするケースです。
これは VCF の中には vSphere や NSX など複数のコンポーネントが BOM リストと呼ばれるリストで中のバージョンが固定的に管理されており、アップグレードする際には各コンポーネントもその指定のバージョンにアップグレードされます。
こちらが VCF での一般的なアップグレードになります。

それに対してもう一つのアップグレード計画であるパッチ適用計画では、例えば個別の製品で不具合が見つかった場合、個別パッチが提供されますが、この個別パッチはいずれ時間が経過すれば、製品のマイナーリリースや VCF のリリースにも反映されるのですが、当然それまでのタイムラグが発生しますので、緊急を要する場合には製品個別にパッチを適用したいケースが発生します。

これらは VCF 5.x 以前のバージョンでは非同期パッチ（Async Patch）、フレキシブル BOM (Flexible BOM) などと呼ばれていた機能です。

昔の VCF では、この個別パッチの対応が難しく、その様な運用が必須なお客様の環境では運用が難しかったのですが、現在の VCF のライフサイクル管理機能ではこちらもサポートされていて、柔軟に個別パッチを適用することが可能になっています。

4-1. アップグレード計画の選択

対象のドメインのライフサイクル管理画面の中に対象ドメインのアップグレード計画に「アップグレードの計画」と「パッチ適用の計画」のどちらかを選択するメニューが表示されているので、まずこちらを選択するのですが、今回はメジャーバージョンアップになるため、「アップグレードの計画」を選択します。

画面を進めると次にターゲットバージョンを選択する項目が表示されるので、”9.0.0.0″ を選択します。

バージョンを選択して進めると、次に対象バージョンの各コンポーネントのバージョンが表示されます。

もしこのタイミングで製品個別パッチが提供されていて、そちらを含んだバージョンにしたいコンポーネントが存在すれば、「アップグレードのカスタマイズ」を選択して、任意のバージョンに変更することも可能です。

最後に選択したバージョンに応じたアップグレード計画の適用順番が表示されるので、確認して完了させます。

図4-1a： VCF アップグレードプランの選択

図4-1b：ターゲットバージョンの指定

図4-1c：アップグレードのカスタマイズ

図4-1d：シーケンスプレビューの更新

4-2. 利用可能な更新の適用

アップグレード計画を選択すると対象バージョンに伴う利用可能更新が存在する場合、その項目が表示されます。
こちらは対象の VCF バージョンにするための各コンポーネントの推奨構成的な位置付けになっており、全てのバージョンアップが完了するまでにどこかのタイミングで適用を完了させる必要があります。
手順としては「すべて適用」を実行すれば、即設定が実施されます。

図4-2：利用可能な更新の適用

5. NSX のアップグレード

ここからはいよいよメインのコンポーネントのアップグレードを行いますが、まずは NSX のアップグレードを実施する流れとなります。

5-1. NSX アップグレードの構成

NSX のアップグレード時には、NSX のアップデートエンジンである NSX Upgrade Coordinator、NSX Edge、NSX Manager のコンポーネントがアップグレードされますが、NSX Edge に関しては、アップグレード時に多少のダウンタイムを伴うため、NSX Edge のみで一旦作業を終わらせたり、特定の NSX Edge のみを選択出来たりと柔軟にメンテナンスウインドウを分けることが可能です。

NSX のアップグレード構成では、その辺りの設定を行ないます。

VCF Operations フリート管理のライフサイクルのマネジメントドメインのページに表示されているアップデートの構成を実施すると、ウィザードが表示され、進めて行くと NSX Edge クラスタの選択画面が表示されます。
本環境ではマネジメントドメインに NSX Edge が存在しないため、ここでは何も表示されませんが、上記でお伝えした項目をここで選択出来る仕組みになっています。

アップデートの構成を完了させると、NSX アップグレードに特化した事前チェックが自動的に実行されるので、完了するのを待ち、エラーが表示されないことを確認します。

図5-1a： NSX アップデート構成の開始

図5-1b： NSX アップグレード事前チェック概要

図5-1c：アップグレードする NSX Edge クラスタの選択

図5-1d： NSX アップデート構成の確認

図5-1e： NSX アップグレード事前チェックの実行結果

5-2. NSX アップグレードの実行

事前チェックが完了すると、更新スケジュールの設定が表示されるので、そちらを実行すると SDDC Manager の時と同様にアップグレードのスケジュール設定が行えます。

ちなみに NSX 4.x から NSX 9.0 にアップグレードする際に上記の事前チェックでいくつかの警告が表示されますが、こちらは環境に関わらず表示される内容になりますので、無視して継続する形になりますが、事前チェックにエラーや警告が表示されている場合には、それを了承した旨のチェックボックスにチェックをして進める形になります。

ウィザードを終了させると、選択したスケジュール設定に合わせてアップグレードが実行されますので、あとはアップグレードが正常に完了するのを待ちます。

図5-2a： NSX アップグレードスケジュールの設定

図5-2b： NSX アップグレード進捗状況

6. vCenter のアップグレード

NSX のアップグレードが完了したら、次のタスクとして vCenter のアップグレードを実施する流れになります。

VCF 5.x から VCF 9.0 へのアップグレードで vCenter をアップグレードする場合、vCenter の Reduced Downtime Upgrade (RDU)を利用します。
これは、一時的に新しい vCenterを展開しておき、展開が完了したタイミングで旧 vCenter からこちらにスイッチオーバーをする仕組みとなっており、vCenter のダウンタイムを大きく抑制することが可能になります。

vCenter RDU の詳細はこちらのブログを参照して下さい。

また、RDU を利用する場合には新規 vCenter Server Appliance を展開する際に仮の IP アドレスが必要になるため、vCenter のアップグレードの前にあらかじめ IPアドレスを確保しておきます。

6-1. vCenter アップグレードの構成

NSX と同様に VCF Operations フリート管理内のライフサイクルページに表示されているアップデートの構成を実施すると、今度は vCenter のアップグレードの構成ウィザードが表示されるので、進めていきます。

ここで入力するのは vCenter のバックアップの可否、RDU 用の仮 IP アドレス情報、アップグレードのスケジュールになりますが、vCenter のバックアップを取得していない場合には、事前にバックアップを取得しておくことを強く推奨します。
バックアップの手順についてはこちらを参照して下さい。

図6-1a： vCenter ダウンタイム短縮更新の説明

図6-1b： vCenter バックアップ取得確認

図6-1c： vCenter 一時ネットワーク情報の入力

図6-1d： vCenter アップグレードと切り替えスケジュールの設定

6-2. vCenter アップグレードの実行

vCenter のアップグレード構成ウィザードを完了させるとウィザード内で設定したスケジュールに合わせてアップグレード処理が実行されるので、アップグレードが正常に完了するのを待ちます。

図6-2： vCenter アップグレードの進捗と結果

7. vSphere Update Manager から vSphere Lifecycle Managerへの変換

従来の VCF では、vSphere Update Manager (VUM) をベースとしたベースライン管理か、 vSphere 7.0から実装された vSphere Lifecycle Manager (vLCM) をベースとしたイメージ管理のどちらかを ESX アップグレードのためのアップグレード管理エンジンとしてドメイン単位で選択することが可能でした。

しかし、SDDC Manager のアップグレードの項目でも記載しましたが、VUM は VCF 9.0 ではサポートが終了したため、既存で利用している場合には、vLCM ベースに変換をする必要があります。

既存のクラスタが既に vLCM である場合には、こちらの手順は不要になりますが、以前はマネジメントドメインの vLCM をサポートしておらず、新規作成に関しては VCF 5.1 からのサポート、VUM から vLCM への変換も従来はサポートされていなかったため、マネジメントドメインをアップグレードする場合には多くのケースでは、この作業が必要になります。

弊社では VUM から vLCM 変換をするためのスクリプトを提供していますので、今回のアップグレード作業においても、ESX を9.0にアップグレードする前にこちらの処理を実施します。

7-1. 既存環境のための vLCM イメージの作成

vLCM では、ESX のベースイメージ、ベンダーアドオン、ファームウェアとドライバのアドン、追加コンポーネントを組み合わせた専用のイメージを事前に作成し、それをベースにライフサイクル管理を実施します。

ここでは、既存の vSphere 8 環境を vLCM に変換するためのイメージを作成します。

対象のドメインの vCenter の Web Client にログインし、vSphere Client のメニューから「Lifecycle Manager」を選択します。
Lifecycle Manager の画面にある「イメージライブラリ」のタブを選択し、任意イメージ名を入力し、ベースとなる ESX バージョンを選択、ベンダーアドオンやファームウェアとドライバのアドオンを任意で選択します。

※ファームウェアとドライバのアドオンを利用する場合は、ハードウェア毎の Hardware Support Management ( HSM )を事前に設定しておく必要があります。

図7-1a： vLCM 新規イメージの作成

全ての選択が完了したら、検証ボタンを押して問題なければイメージを保存して完了します。

図7-1b： vLCM 作成イメージ詳細

7-2. vLCM 変換スクリプトの実行

イメージを作成したら、実際にスクリプトを使って既存のクラスタを VUM から vLCM へ変更していきます。
こちらのKB から対象の変換スクリプトをダウンロードし、スクリプトの実行条件である 1〜3 に対応している端末もしくはサーバ上に配置します。

【オンラインデポ変更スクリプトの実行条件】

PowerShell 7.2 以上
VCF.PowerCLI v9 以上 (従来の VMware.PowerCLI を利用している場合はアンインストールし、 VCF.PowerCLI を再インストールしてください)
マネジメントドメインの vCenter と SDDC Manager に HTTPS で通信可能

スクリプトの配置が完了したら、該当の端末で PowerShellを開き、スクリプトを実行すると対話形式のメニューが表示されるので、1-4 までを順番に実施していきます。

図7-2a： vLCM 変換スクリプト対話メニュー

「1」のメニューでは SDDC Manager への接続設定と対象の vCenter を選択する項目となっており、SDDC Manager への接続情報を入力し、接続が完了すると配下にいるvCenter が表示されるので、対象の vCenter を選択します。

図7-2b： vLCM 変換スクリプト SDDC Manager への接続と対象 vCenter の指定

「2」のメニューでは、今回適用するイメージを対象の vCenter で選択し、SDDC Manager のインベントリに登録する内容になっていますので、項目7-1で作成したイメージを選択します。

イメージが正常に SDDC Manager にインポートされたかを確認したい場合には、メニュー「11」を実行することで、SDDC Manager 内のイメージ一覧を確認することも可能です。

図7-2c： vLCM 変換スクリプト vLCM イメージの SDDC Manager へのインポート

「3」では、イメージを適用するクラスタを選択し、対象のクラスタが指定したイメージに対して構成に準拠しているかのコンプライアンスチェックを実施しますので、実行して正常にチェックが完了するのを確認します。

図7-2d： vLCM 変換スクリプトクラスタのイメージコンプライアンスチェック

コンプライアンスチェックに問題なければ、「4」のメニューにて、再度対象のクラスタを選択し、実際に変換処理を実施します。

図7-2e： vLCM 変換スクリプトクラスタの vLCM への変換

一通りスクリプトの実行が完了したら、対象のクラスタが正常に vLCM 構成に変更されているかを確認するため、マネジメントドメインの vCenter の Web Client にログインし、インベントリから対象のクラスタを選択し、「アップデート」→「イメージ」と進めていくと、適用されているイメージとイメージのクラスタへのコンプライアンス状況を確認することが出来ます。

図7-2f：変換したクラスタの vLCM ステータスの確認

8. ESX ホストのアップグレード実行

対象のクラスタの VUM から vLCM への変換が完了したら、いよいよ ESX を 8.x から 9.0 にアップグレードしていきますが、VCF での ESX ホストのアップグレードの基本的な流れは以下の通りとなります。

vCenter で ESX 9.0のイメージを作成
VCF Operations にて上記で作成したイメージのインポート
VCF Opperations から ESX のアップグレード実行

8-1. vLCM ESX 9.0イメージの作成

アップデートに指定するための ESX 9.0の vLCM イメージを上記の 7-1 と同様の手順で作成します。

※ vCenter 9.0 の既知の不具合として、vCenter 8からアップデートした環境では、データベースの不整合により、ESX 9.0 以上のベースイメージを正常にダウンロード出来ない現象が発生します。
詳細については、こちらのKB に記載されていますので、作業の前にKBに記載されている対処を実行する必要があります。

KB 402037 : Sync updates task fails on vCenter 9.0 after upgrading and ESX 9 image is not available in LCM.
https://knowledge.broadcom.com/external/article/402037

図8-1： vLCM ESX 9.0 イメージの新規作成

8-2. VCF Operations への ESX 9.0 vLCM イメージの登録

VCF Operations にログインし、「フリート管理」→「ライフサイクル」を開き、対象の VCF インスタンスを選択し、「イメージ管理」のタブを開きます。
「イメージのインポート」を実行し、「vCenter からのインポート」を選択し、対象のイメージを指定して、インポートを実行し、正常にイメージの一覧に新しいイメージが表示されることを確認します。

図8-2a： VCF Operations への vLCM ESX 9.0 イメージのインポート開始

図8-2b： ESX 9.0 イメージの指定

図8-2c：インポートイメージの確認

8-3. ESX ホストのアップデート実行

NSX や vCenter と同様に VCF Operations フリート管理のライフサイクルページに表示されているアップデートの構成を実施し、ウィザードを進めていきます。

ウィザード内では、対象のクラスタの選択と適用するイメージの指定、クイックブートの利用可否などのアップデートオプションの構成など任意の値を入力し、ウィザードを完了させると、クラスタと新しいイメージでのコンプライアンスチェックが実行されるので、エラーなどが表示されてないことを確認します。

図8-3a： ESX ホストアップグレードの構成(対象クラスタの選択)

図8-3b： ESX ホストアップグレードの構成(イメージの割り当て)

図8-3c： ESX ホストアップグレードの構成(イメージの指定)

図8-3d： ESX ホストアップグレードの構成(イメージの割り当て確認)

図8-3e： ESX ホストアップグレードの構成(アップグレードオプションの指定)

図8-3f： ESX ホストアップグレードイメージのコンプライアンスチェックの実行

図8-3g： ESX ホストアップグレードイメージのコンプライアンスチェック結果

※ 本環境はラボ内の Nested 環境でのイメージのため、複数のエラーが表示されていますが、実環境では、エラーは表示されないのが通常となりますので、もしエラーが表示されている場合には原因を特定し、解消してから進めることを推奨します。

コンプライアンスチェックが正常に完了したら、スケジュールの設定を実施し、完了するとスケジュール合わせた形で処理が開始されますので、対象のESX ホスト全てのアップグレードが完了するのを待ちます。

図8-3h： ESX ホストアップグレード進捗状況と結果

ESX のアップデートが完了すると全てのアップグレード作業が完了となりますので、
同インベントリから対象のクラスタを選択し、全てのコンポーネントが9.0になっていることを確認して終了となります。

図8-3i： VCF 9.0 全コンポーネントバージョンの確認

9. 分散仮想スイッチと vSAN ファイルシステムのアップグレード

製品の仕様として NSX の分散仮想スイッチ( VDS )や vSAN のファイルシステムは、アップグレードプロセスの中では、自動的にアップグレードされず、製品をアップグレードした後に vCenter から個別にアップグレードを実施します。
この二つのコンポーネントに関しては、アップグレードが必須ではありませんが、アップグレードをしない場合には、新しい機能の一部が利用出来ないため、このタイミングでのアップグレードが推奨になります。

10. ライセンスの更新

ライセンス管理の方式が VCF 9.0 から従来のライセンスキーベースでの管理ではなく、VCF Operations を弊社の管理ポータルである VCF Business Service Console (BSC) に登録し、ライセンス認証を行う方式になっています。

※ なお、今回の変更により、180日ごとにライセンスの使用状況を更新し、ライセンスを再アクティベーションする必要があります。

ちなみにオフライン環境の場合には、VCF Operations から使用量ファイルを作成し、作成したファイルを Broadcom Support Portal にアップロードして、それに基づくライセンスファイルを入手し、VCF Operations に登録する手順を180日毎に繰り返す方式になっています。

オンライン環境での手順の流れとしては、以下の通りとなりますが、詳細な手順はこちらのネットワールドさんのブログに非常によく纏まっていますので、こちらを参照して頂くと良いと思います。

VCF Operations を VCF Business Service Console へ登録
VCF ライセンスのアクティベーション
割り当てられたライセンスを vCenter に適用

図10-1： VCF 9.0 ライセンス登録情報

図10-2： VCF 9.0 ライセンスサマリ

図10-3： VCF 9.0 ライセンス使用量分析

いかがでしたでしょうか、VCF 9.0 から管理アーキテクチャが大きく変更になっているため、VCF 4.x から VCF5.xへのアップグレード手順に比べると補足的な作業が多い印象を持たれるかもしれませんが、実際のコンポーネントのアップグレードだけに焦点を当てると殆ど変更はなく、従来と同様にシンプルな手順で実施することが可能です。

これは VCF 9.0を以降のバージョンに上げる際にも踏襲されていく形になりますので、引き続き皆様の SDDC 環境のライフサイクル管理の大きなサポートになると思います。