ディスク フォーマットのアップグレードは任意であり、以前のディスク フォーマット バージョンを使用していても Virtual SAN クラスタはスムーズに稼働し続けます。

最適な結果を得るには、オブジェクトをアップグレードして最新のオンディスク フォーマットを使用します。 最新のオンディスク フォーマットでは、Virtual SAN の完全な機能セットを使用できます。

ディスク グループは一度に 1 つずつアップグレードされるため、ディスク グループのサイズによってはディスク フォーマットのアップグレードに時間がかかる可能性があります。 各ディスク グループのアップグレードでは、ディスク グループの各デバイスにあるすべてのデータが退避させられ、Virtual SAN クラスタからディスク グループが削除されます。 その後、新しいオンディスク フォーマットの Virtual SAN にそのディスク グループが再び追加されます。

オンディスク フォーマットのアップグレードを開始すると、Virtual SAN はいくつかの操作を実行し、これらの操作は [コンポーネントの再同期] ページで監視できます。 次の表に、ディスク フォーマットのアップグレード中に行われる各プロセスを示します。

表 1. アップグレードの進行状況

進行状況

説明

0 ~ 5%

クラスタのチェック。 クラスタ コンポーネントが確認され、アップグレードの準備が行われます。 このプロセスには数分かかります。 Virtual SAN は、アップグレードの妨げとなるおそれがある未解決の問題がないことを確認します。

  • すべてのホストが接続されていること。

  • すべてのホストでソフトウェア バージョンが正しいこと。

  • すべてのディスクが健全であること。

  • 自動的なディスクの要求が無効であること。

  • すべてのオブジェクトにアクセスできること。

5 ~ 10%

ディスク グループのアップグレード。 Virtual SAN はデータ移行なしで初期のディスク アップグレードを実行します。 このプロセスには数分かかります。

10 ~ 15%

オブジェクトの再編成。 Virtual SAN はすべてのオブジェクトのレイアウトを変更し、正しく編成されるようにします。 このプロセスは、スナップショットが少ない小規模なシステムでは数分で完了する場合もありますが、スナップショットが多く、断片化した書き込みが多く、未編成のオブジェクトが多い大規模なシステムでは数時間または数日かかる場合もあります。

15% ~ 95%

ディスク グループの削除および再フォーマット。 各ディスク グループがクラスタから削除され、再フォーマットされ、再びクラスタに追加されます。 このプロセスにかかる時間は、割り当てられたメガバイト数とシステムの使用率によって異なります。 I/O 容量いっぱいに近いシステムは転送が非常に遅くなります。

95% ~ 100%

最終的なオブジェクト バージョンのアップグレード。 新しいオンディスク フォーマットへのオブジェクトの変換と再同期が完了します。 このプロセスにかかる時間は、使用している領域、および 冗長性の低下を許可 オプションを選択しているかどうかによって異なります。

アップグレード中、アップグレード プロセスは [コンポーネントの再同期] ページに移動したときに vSphere Web Client から監視できます。 Virtual SAN クラスタでの再同期タスクの監視を参照してください。 RVC コマンド vsan.upgrade_status <cluster> を実行してアップグレードを監視することもできます。 オプションの -r <seconds> フラグを使用して、Ctrl+C を押すまでアップグレードのステータスを定期的に更新します。 更新ごとに許容された最小の秒数は 60 秒です。

デバイスの削除やアップグレードなどのその他のアップグレード タスクは、vSphere Web Client のステータス バーの [最近のタスク] ペインから監視できます。

ディスク フォーマットをアップグレードするときは次の考慮事項が適用されます。

  • 各ホストにディスク グループがある 3 台のホストを含む Virtual SAN クラスタをアップグレードし、データの損失を招く可能性がある障害から保護するために完全な退避を実行する場合、許容する障害の数 が 0 より大きい構成のオブジェクトは退避に失敗します。 この理由は、3 台のホスト クラスタでは、2 台のホストのみのリソースを使用して完全に退避されるディスク グループを再保護できないためです。たとえば、許容する障害の数 を 1 に設定した場合、Virtual SAN には 3 つの保護コンポーネント(2 つのミラーと 1 つの監視)が必要で、各保護コンポーネントは個別のホストに置かれる必要があります。

    3 台のホスト クラスタの場合、退避モードとして アクセシビリティの確保 を選択する必要があります。 このモードの場合、ハードウェア障害でデータが損失する可能性があります。

    十分な空き領域があることも確認する必要があります。 この領域は、最も大きいディスク グループの論理的消費容量と等しくする必要があります。 移行されるディスク グループとは異なるディスク グループにこの領域がある必要があります。

  • 3 台のホスト クラスタで作業する場合、または制限されたリソースで Virtual SAN をアップグレードする場合、オプション付きの RVC コマンド vsan.ondisk_upgrade --allow-reduced-redundancy を実行して、アップグレード中に仮想マシンが低下した冗長性モードで動作できるようにします。

  • --allow-reduced-redundancy コマンド オプションを使用すると、特定の仮想マシンが移行中の障害を許容できない可能性があります。 この障害に対して許容性を低下させたことが、データの損失を招く可能性もあります。 Virtual SAN は、アップグレードの完了後に完全なコンプライアンスと冗長性をリストアします。 アップグレード中は、仮想マシンのコンプライアンス ステータスとその冗長性は一時的に準拠しなくなります。 アップグレードを完了してすべての再構築タスクを完了すると、仮想マシンは準拠するようになります。

  • アップグレードの進行中は、ホストを削除または切断したり、ホストをメンテナンス モードにしたりしないでください。 これらの処理によって、アップグレードが失敗する場合があります。

RVC コマンドとコマンド オプションの詳細については、『RVC コマンド リファレンス ガイド』を参照してください。