VMware vSAN アップグレードのベストプラクティス

Products

VMware vSAN

Issue/Introduction

この記事では、vSAN クラスタをアップグレードするための規範となるベストプラクティスについて説明します。

Symptoms:
免責事項：これは英文の記事「VMware vSAN upgrade best practices (2146381)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

Environment

VMware vSAN 8.0.x
VMware vSAN 7.0.x
VMware vSAN 6.x

Resolution

vSAN クラスタのアップグレードを成功させるには、クラスタのアップグレードのための前提条件を満たすこと、そして特定の推奨事項に従ってアップグレードを実行することが重要です。

vSAN クラスタのアップグレードの前

vSAN のアップグレードプロセスを開始する前に、次の要件が満たされていることを確認します。

vSphere 環境が最新である

ホストを管理する vCenter Server のパッチレベルは、管理する ESXi ホストと同等以上である必要があります。
vCenter と ESXi のバージョンを一致させることをお勧めします。そうしないと、KB vCenter version to ESXi version (68174) に記載されているように、両者間で通信の問題が発生する可能性があるからです（サポートされる vCenter と ESXi のバージョンの組み合わせについては、KB Build numbers and versions of VMware ESXi/ESX(2143832) および Build numbers and versions of VMware vCenter Server(2143838) を参照してください）。
vSAN クラスタアップグレードを開始する前に、すべてのホストが同じ ESXi のビルドを実行している必要があります。クラスター全体で統一されたESXIホストのバージョンだけが、効率的なvSANの機能を保証します。
ESXi ホストのバージョンが一致しない場合は、アップグレードの前にホストにパッチを適用して同じビルドにする必要があります。

vSAN クラスタの健全性がすべて緑色であることが必須です
( vSAN クラスタ > 監視 > vSAN > Skyline 健全性 )

全ての vSAN コンポーネント(ディスク/DOMオブジェクト/ネットワークなど)が健全であること
障害や認識できないディスクがないこと
これは、クラスタ > 構成 > vSAN > ディスク管理で確認できます

コントローラのHCLは、ドライバとファームウェアの組み合わせが一致し、ESXiのターゲットバージョンでサポートされている必要があります

HCLは、ホストにインストールされているドライバ/ファームウェアのバージョンを、リンク先のデータベースで確認することで検証できます： https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanio

アクセス不能な vSAN オブジェクトがないこと

これは、vSAN 6.0 以降の vSAN 健全性サービス、またはすべてのリリースの Ruby vSphere Console (RVCは非推奨) で確認できます。

アップグレードプロセスの開始時にアクティブな再同期がないこと

ホストの再起動後にデータを同期する必要があるため、アップグレード中に再同期アクティビティが発生することがあります。管理者は再同期が終了するまで待ってから、次のホストをメンテナンスモードにする必要があります。

現在の vSAN バージョンとターゲットの vSAN バージョンとの間に既知の互換性の問題がないことを確認してください。アップグレード要件については、「vSAN upgrade requirements (2145248)」を参照してください。

アップグレードパスの互換性を確認します
必要に応じて、アップグレードプロセスを開始する前に、vSAN クラスタを必要なビルドに更新、互換性の問題を回避します。

ESXiホストの準備

正しいメンテナンスモードオプションを選択していることを確認します。vSAN でホストをメンテナンスモードに移行する場合、3 つのオプションを選択できます：

アクセシビリティの確保：
アクセシビリティの確保を選択すると、vSAN では、完全データ移行よりも高速にホストをメンテナンスモードに移行し、環境内の仮想マシンへのアクセスを確保できます
全データの移行：
vSAN はすべてのデータをクラスタ内の他のホストに退避させます。この退避モードでは、データ転送量が最も多くなり、最も多くの時間とリソースを消費します。
データの移行なし：
データの移行なしを選択すると、vSAN はこのホストからデータを退避しません。ホストをパワーオフするかクラスタから削除すると、一部の仮想マシンにアクセスできなくなる可能性があります。これは安全に使用できるオプションではありません。

メンテナンスモードの終了と再同期：

ESXi ホストがアップグレードされ、メンテナンスモードを解除したとき、デフォルトの再同期遅延タイマーである 60分を超えると再同期が発生します。これは vSphere クライアントで確認できます。
次のホストに移る前に、再同期が完了していることを確認してください。更新されたホストが再び vSAN データストアに貢献できるようになるため、再同期が行われています。データ損失を回避するために、この再同期が完了するまで待つことが重要です。

ストレッチ vSAN クラスタ環境では、物理ノードの後に必ず witness ホストをアップグレードしてください。また、witness ホストを 6.x から 7.x またはそれ以上のバージョンにアップグレードする場合は、「vSAN 健全性サービス - ストレッチクラスタ - Witness Appliance を vSphere 7.0 以降にアップグレードする場合は注意が必要です (76948)」を参照してください。

注：バージョン 7.0 の場合、またはアップグレード対象のバージョンが 7.0 の場合は、物理ノードをアップグレードする前に witness ホストをアップグレードする必要があります。

vSAN クラスタのアップグレードを開始した後

アップグレードプロセスを開始した後、いくつかの点に注意する必要があります。

vSAN クラスタのアップグレードを開始したら、同じクラスタ内で ESXi のバージョンが混在している場合（特にメジャーリリースが異なる場合）は、サポートされていない構成であり、パフォーマンスの問題やクラスタの不安定性などの問題が発生する可能性があるため、早急に、できれば 1 週間以内にアップグレードを完了するようにしてください。これは、同じクラスタ内でコードが混在して互いに通信していることが原因です。32ホスト以下のクラスタでは、通常24～48時間以内にアップグレードが完了する予定です。32〜64ホストの大規模クラスタでは、通常48〜72時間以内にアップグレードが完了します。
クラスタに新しいバージョンを導入してワークロードを移行することで、クラスタをアップグレードしようとしないでください。

クラスタアップグレードの途中で新しいホストを導入する場合は、vSAN ネットワークパーティションの発生を防ぐため、すべてのホストが同じ ESXi バージョンにアップグレードされるまで、ディスクグループが存在/作成しないようにしてください。新しく追加したホストにディスクグループを作成する前に、必ず上記 1 に従ってクラスタのアップグレードを完了してください。

アップグレード中にディスクを追加または交換する場合、該当する場合は、ディスクが適切なレガシーオンディスクフォーマットバージョンでフォーマットされていることを確認してください（該当する場合）。詳細については、「How to format vSAN Disk Groups with a legacy format version (2146221)」および「Failure to promote CMMDs version resulting in vSAN cluster to become partitioned during upgrade (76841)」を参照してください。

特定の vSAN 動作の変更は、現在のオンディスクフォーマットによって制御されます。新しいバージョンのオンディスクフォーマットバージョンがクラスタに混在しないことが重要です。詳細については、「Understanding vSAN on-disk format versions and compatibility (2145267)」を参照してください。

これらのベストプラクティスに従わない場合、次の問題が発生する可能性があります：

予期しないネットワークパーティション
データ可用性の予期しない損失
不安定な vSAN クラスタ

Additional Information

VMware vSAN upgrade best practices