VMware Cloud Foundation（VCF）5.2.1 で vSAN ESA の VI Workload Domain をデプロイしてみます。ESXi ホストには、ネステッド ESXi を利用しています。
今回の内容です。
- 今回の環境
- 1. VI Workload Domain のデプロイ（vSAN ESA）
- 2. VI Workload Domain デプロイ後の様子
- vSphere Client での vSAN HCL DB の確認 / 更新
- vSAN ESA の VI Workload Domaon デプロイに失敗した際の対処
今回の環境
VCF 5.2.1 で Management Workload Domain をデプロイしてあります。
VI Workload Domain を構成するホストは、ネステッド ESXi で用意してあります。
今回は、3台の vSAN ESA 用ホストをコミッショニングしてあります。
VCF 外部での事前準備は、下記の投稿と同様に実施してあります。利用するネットワーク アドレスなども、この投稿と同様です。
- VCF 5.2 で VI Workload Domain を展開してみる。Part-03：VI Workload Domain の展開（NSX あり）
- DNS レコードの登録
- DHCP サーバーの用意
1. VI Workload Domain のデプロイ（vSAN ESA）
SDDC Manager で、「インベントリ」→「ワークロード ドメイン」にある、「ワークロード ドメイン」→「VI - ワークロード ドメイン」を開きます。
ストレージの種類を選択して、「開始」をクリックします。
- ストレージの選択：vSAN
- vSAN ESA の有効化：チェック ON のまま
一般情報を入力して、「次へ」をクリックします。
- 仮想インフラストラクチャ名：vcf-w01
- 組織名：vcf-w01-org
- SSO ドメイン：管理 SSO ドメインへの参加
クラスタの情報を入力して「次へ」をクリックします。
- クラスタ名：vcf-w01-cl01
- イメージ：Management-Domain-ESXi-Personality
※デフォルトで作成される Management Domain のイメージを利用。
デプロイする vCenter Server の情報を入力して「次へ」をクリックします。
- vCenter Server の FQDN：vcf-w01-vc-01.c.go-lab.jp
- vCenter Server の root パスワード
ネットワークの画面では「新しい NSX Manager インスタンスの作成」を選択したまま、NSX Manager の FQDN を入力して、画面をスクロールします。
- アプライアンス 1 の FQDN：vcf-w01-nsx-01.c.go-lab.jp
- アプライアンス 2 の FQDN：vcf-w01-nsx-02.c.go-lab.jp
- アプライアンス 3 の FQDN：vcf-w01-nsx-03.c.go-lab.jp
- アプライアンス クラスタの FQDN：vcf-w01-nsx.c.go-lab.jp
ネットワークの残りのパラメータを入力して、「次へ」をクリックします。
- NSX Manager アプライアンスのサイズ：大規模
（12 vCPU、48 GB RAM、300 GB ストレージ）
vCPU / RAM は予約設定されるので、物理リソースの少ないラボでは、Workload Domain 展開処理中に NSX Manager 仮想マシンがデプロイされ次第、予約設定を解除しておく。 - 管理者パスワード： admin ユーザーのパスワードを入力
- 監査者パスワード：auditor ユーザーのパスワード（今回は空欄のまま）
vSAN ストレージのタイプを選択して、「次へ」をクリックします。
- vSAN クラスタ タイプ：vSAN HCI
ESXi ホストは、コミッショニングした 3台をすべて選択して「次へ」をクリックします。
スイッチの構成では、Default プロファイルの「選択」をクリックします。
NSX のオーバーレイ ネットワークを構成する TEP の VLAN を指定するため、「Distributed Switch」直下にあるメッセージの「編集」をクリックします。
NSX の VLAN ID を入力して、「変更の保存」をクリックします。
- VLAN ID：74
- IP アドレス割り当て (TEP)：DHCP ※変更不可
「Distributed Switch」の画面に戻るので、「確認」をクリックします。
「次へ」ボタンがアクティブになるのでクリックします。
ライセンスの入力画面では「後でライセンス」を選択して「次へ」をクリックします。
確認画面で「完了」をクリックします。
デプロイ処理が開始されるので、ひたすら待ちます。
vSAN クラスタの「Skyline Health」で「vSAN HCL DB の更新状態」を確認すると、下記の投稿で SDDC Manager に配置した vSAN HCL の JSON ファイルが読み込まれていることが確認できます。
タイミングによっては、この画面で vSAN HCL の JSON ファイルをアップロードすることになります。
VI Workload Domain（vcf-w01）用の NSX Manager 仮想マシン 3台は、物理リソースの少ないラボ環境では、CPU とメモリの予約を解除（0 に設定変更）しておきます。
これは、自動デプロイ → パワーオンが完了したタイミングで、仮想マシンの「設定の編集」から変更します。
数時間ほど待つと、VI Workload Domain の展開が完了します。
2. VI Workload Domain デプロイ後の様子
「ワークロード ドメイン」で、展開した VI Workload Domain（vcf-w01）を開きます。
「クラスタ」タブで、vSAN 構成が「vSAN ESA」と表示されています。
クラスタ名のリンクを開くと、「サマリ」タブで vSAN データストア名や容量を確認できます。
vSphere Client にログインすると、Management Workload Domain の vCenter Single Sign-On（SSO）ドメインに参加しているため、拡張リンク モードになっています。
「ホストおよびクラスタ」インベントリを確認すると、Management Workload Domain の vCenter（ESXi 4台）と、VI Workload Domain の vCenter（ESXi 3台）が両方表示されます。そして、vcf-w01-cl01 クラスタは、vSAN ESA で構成されています。
vcf-w01-cl01 クラスタに含まれる ESXi ホストのディスクは、vSAN ESA のストレージ プールに追加されています。
vcf-w01-cl01 クラスタの Skyline Health を確認すると、「不良」に下記の警告が検知されています。
- vSAN 管理対象ディスクの要求
- VMware によって認定された NVMe デバイス
これは、vSAN HCL DB がオンラインから再取得されているためです。
今回のデプロイ処理は、実は途中でエラーによる停止（NSX Manager のデプロイ処理のあたりで）があり再開しているので、その際にオンラインから再取得されたのかもしれません。
「ローカル HCL DB コピーの最終更新日時」を確認すると、デプロイ中には自作の vSAN HCL ファイルが読み込まれていましたが、この時点ではオンライン更新されたものに置き換えられています。
このままでも vSAN ESA の動作には問題ありませんが、このあとで vSAN HCL DB の手動更新方法を紹介しておきます。
vSphere Client での vSAN HCL DB の確認 / 更新
vSAN クラスタの Skyline Health で、vSAN HCL DB の確認、更新してみます。
vSphere Client で、vSAN クラスタの「監視」→「vSAN」→「Skyline Health」を開きます。
健全性検出では、「不良」が 2件表示されています。これは、ネステッド ESXi の仮想マシンに、vSAN HCL DB に含まれないデバイスが搭載されているためです。
- vSAN 管理対象ディスクの要求
- VMware によって認定された NVMe デバイス
「すべて」を開き、「検出」列のフィルタで「HCL」と入力します。
vSAN HCL DB 関連の検出項目のみが表示されるので、「vSAN 管理対象ディスクの要求」を開くと、「ローカル HCL DB コピーの最終更新日時」から vSAN HCL DB の更新日時を確認できます。
「ファイルから更新」をクリックします。
以前の投稿 で作成した nested-esxi-vsan-esa-hcl_80u3.json をアップロードします。
画面が更新されるので、あらためて「vSAN 管理対象ディスクの要求」を開くと、「ローカル HCL DB コピーの最終更新日時」がアップロードした JSON ファイルの先頭に記載したものになります。
これで、健全性検出の「不良」が 0 件になりました。
vSAN ESA の VI Workload Domaon デプロイに失敗した際の対処
VI Workload Domaon のデプロイ中に、下記のように失敗することがあります。この場合、問題を解消して「タスクの再起動」をクリックするとデプロイ処理を進められることがあります。
対処1. vSAN HCL DB の再アップロード
デプロイ中の vSAN クラスタで、vSAN HCL DB がオンライン更新されてしまっている場合があります。この場合は、直前に紹介したように、vSphere Client で、vSAN HCL の JSON ファイルを再アップロードします。
「不良」にある下記の項目は、エラーではなく「警告」ではありますが、vLCM での処理や Workload Domain のデプロイが停止します。「サイレント アラート」をクリックして対処することもできそうですが、自作の vSAN HCL ファイルをアップロードできていれば「不良」に検知されなくなり。
- vSAN 管理対象ディスクの要求
- VMware によって認定された NVMe デバイス
対処2. 不要なデバイスの削除
ネステッド ESXi を使用している場合、仮想マシンに CD/DVD ドライブや SCSI コントローラが接続されていると、自作の vSAN HCL ファイルが読み込まれていても、vSAN ESA のストレージ プールにディスク追加ができず、エラーになるようです。
下記の投稿にあるように、ESXi 仮想マシンで設定を調整しておきます。
デプロイ中にエラーになった場合でも、この仮想マシン設定変更は、ESXi をいったんシャットダウンして実施します。そして、起動した ESXi が VI Workload Domain の vCenter に接続されたことを確認してから「タスクの再開」をクリックします。
対処3. ストレージ プールにディスクを手動追加
vSAN HCL DB を自作ファイルに置き換えて、仮想マシンに不要デバイスが存在しない状態でもエラーになることがあります。この場合、「vSAN 管理対象ディスクの要求」が「情報」に検出されていたりします。
このケースでは、vSAN ESA のストレージ プールに、手動でディスクを追加すると「タスクの再開」が成功することがありました。
vSAN ESA 構成中のクラスタで、「管理」→「vSAN」→「ディスク管理」を開くと、使用中のディスクが「0/1」になっているので、「未使用ディスクの要求」をクリックします。
各 ESXi ホストのデバイスを選択して、「作成」をクリックします。
これで、使用中のディスクが「1/1」になるので、SDDC Manager で「タスクの再開」をクリックしてみます。
以上、vSAN ESA の VI Workload Domain をデプロイしてみる話でした。
