VMware vSAN 7.0 Update 2 | 2021 年 3 月 9 日 | ビルド 17630552 リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

• 新機能
• VMware vSAN コミュニティ
• このリリースのアップグレード
• 制限
• 既知の問題

新機能

vSAN 7.0 Update 2 には、次の新機能および機能強化が含まれています。 

妥協のない拡張性

• HCI メッシュ。HCI メッシュにより、vSAN クラスタで vSphere コンピューティング専用クラスタまたは非 HCI ベース クラスタとキャパシティを共有できます。互換性のあるデータストアを見つけるために、推奨のデータ配置にストレージ ルールを指定することもできます。スケーラビリティが強化され、1 つのリモート vSAN データストアに 128 台までのホストを構成できるようになりました。
• vSAN ファイル サービスの機能強化。vSAN ファイル サービスで、ストレッチ クラスタの展開と 2 ノード構成のクラスタがサポートされるようになりました。スケーラビリティが強化され、クラスタあたり 64 台のホストと 100 個の共有を構成できるようになりました。
• ストレッチ クラスタの機能強化。各サイトで 1 つのストレッチ クラスタに 20 台までのホストを構成できるようになりました。ストレッチ クラスタの DRS 認識により、フェイルバック時のパフォーマンスの安定性が向上しました。
• vSAN over RDMA。vSAN over RDMA により、パフォーマンスと仮想マシンの統合率が向上します。 
• プラットフォームのパフォーマンスの向上。プラットフォームの NUMA 認識が強化され、パフォーマンスが向上しました。 

インフラストラクチャとデータのセキュリティ強化

• vSphere Native Key Provider。vSAN は、組み込みの暗号化で vSphere Native Key Provider をサポートします。
• vSAN ファイル サービスでの転送中データの暗号化。ファイル サービスのセキュリティ強化で、転送中データの暗号化のサポートが追加されました。ファイル サービスが有効になっているときに、vSAN による転送中データの暗号化を使用できます。
• 共有監視での転送中データの暗号化。vSAN 7.0 Update 2 は、共有監視ホストでの転送中データの暗号化をサポートしています。 

オペレーションの簡素化

• vLCM の機能強化。vLCM は、一部の Dell EMC、HPE、Lenovo サーバの既存のサポートに加え、一部の Hitachi UCP HC サーバのファームウェア アップデートをサポートするようになりました。vLCM は、NSX-T ネットワークが構成された vSphere with Tanzu クラスタを更新できます。また、スケーラビリティが強化され、単一の vCenter Server 内の vLCM で 400 台までのホストを管理できるようになりました。 
• vSAN による管理と監視の機能強化。環境の分析に使用できるツールが増えました。問題の根本原因や修正方法を迅速に特定できます。プロアクティブなキャパシティ管理、ネットワーク診断、パフォーマンスに最も影響を及ぼす要因の分析、健全性チェックの履歴表示などの機能強化が行われています。
• 計画外の障害への対応。vSAN 7.0 Update 2 では、ホスト、ディスク、またはネットワークで発生した計画外の障害を許容できるように、障害発生時に追加の持続性コンポーネントを生成し、データの持続性を強化しています。
• ファイル サービスのスナップショット。vSAN 7.0 Update 2 では、スナップショット サポートと API により、ファイル共有のバックアップが簡単になりました。この API により、バックアップとリカバリ ソフトウェア ベンダーと vSAN ファイル サービスの連携が可能になります。
• vSphere Proactive HA サポート。vSAN でプロアクティブ HA がサポートされるようになりました。これにより、ハードウェアの問題を検出してホストをメンテナンス モードに切り替え、プロアクティブな対応を行うことができます。 
• VMFS6 ファイル システムのサポート。オブジェクト フォーマットのバージョンが 14 の場合、vSAN データストアに新しく仮想マシンを作成すると、仮想マシン名前空間オブジェクトのファイル システムが VMFS6 になります。仮想マシンで SEsparse スナップショットを使用できます。 
• 効率的な VMDK の移動。vSphere Datastore Browser UI または API (VirtualDiskManager.moveVirtualDisk) を使用して、同じ vSAN データストア上の 2 つのディレクトリ間で VMDK を移動する場合、VMDK 記述子ファイルとオブジェクト メタデータだけが更新されます。vSAN オブジェクト データをバッキングする VMDK がコピーされないため、処理時間が短縮されます。 

VMware vSAN コミュニティ

vSAN コミュニティ Web サイトを使用して、vSAN の使用中に見つかった問題に対してフィードバックを提供したり、サポートを依頼します。  

このリリースのアップグレード

vSAN のアップグレードの詳細については、VMware vSAN 7.0 のドキュメントを参照してください。 

注：アップグレードを実行する前に、「VMware 互換性ガイド」の最新バージョンを確認して、ご使用のプラットフォームで最新の vSAN バージョンが利用可能であることを確認してください。

vSAN 7.0 Update 2 は、vSphere 7.0 Update 2 への完全アップグレードを必要とする新しいリリースです。アップグレードを完了するには、次のタスクを実行します。

1. vCenter Server 7.0 Update 2 にアップグレードします。詳細については、『VMware vSphere 7.0 Update 2 リリース ノート』を参照してください。 
2. ホストを ESXi 7.0 Update 2 にアップグレードします。詳細については、『VMware vSphere 7.0 Update 2 リリース ノート』を参照してください。 
3. vSAN のオンディスク フォーマットをバージョン 14.0 にアップグレードします。オンディスク フォーマット バージョン 3.0 以降からアップグレードする場合、データの退避は必要ありません（メタデータの更新のみ）。 
4. FSVM をアップグレードして、ストレッチ クラスタ サポート、スナップショット サポート、転送中データの暗号化などの新しいファイル サービス機能を有効にします。

注：vSAN 7.0 Update 1 で、バージョン 1.0 のディスク フォーマットが廃止されました。バージョン 1.0 のディスク フォーマットを実行しているディスクは vSAN によって認識されません。vSphere Update Manager、ISO のインストールまたは esxcli による vSAN 7.0 Update 1 へのアップグレードはブロックされます。この問題を回避するには、ディスク フォーマット バージョン 1.0 を実行しているディスクを新しいバージョンにアップグレードします。バージョン 1 のディスクを使用している場合、健全性チェックでアラートが表示され、ディスク フォーマットのバージョンをアップグレードするように警告されます。

ディスク フォーマット バージョン 1.0 では、パフォーマンスとスナップショットの機能が強化されていません。チェックサム、デデュープと圧縮、暗号化など、高度な機能はサポートされていません。vSAN ディスク フォーマットのバージョンの詳細については、KB2148493 を参照してください。

容量の少ないホストのオンディスク フォーマットのアップグレード

vSAN オンディスク フォーマットをバージョン 1.0 または 2.0 からアップグレードしている間に、ディスク グループの退避が実行されます。ディスク グループが削除されて、オンディスク フォーマット バージョン 14.0 にアップグレードされてから、ディスク グループが再びクラスタに追加されます。2 ノードまたは 3 ノード クラスタの場合、または各ディスク グループを退避させるための十分なキャパシティのないクラスタの場合は、vSphere Client から [冗長性の低下を許可] を選択します。次の RVC コマンドを使用して、オンディスク フォーマットをアップグレードすることもできます：vsan.ondisk_upgrade --allow-reduced-redundancy

冗長性の低下を許可する場合、この方法ではデータがクラスタ内の他のホストに退避されないため、アップグレードの間、仮想マシンが保護されません。この方法では、各ディスク グループが削除されて、オンディスク フォーマットがアップグレードされ、ディスク グループが再びクラスタに追加されます。すべてのオブジェクトを引き続き使用できますが、冗長性は低下します。

vSAN 7.0 Update 2 へのアップグレード中に重複排除および圧縮を有効にすると、vSphere Client から [冗長性の低下を許可] を選択できます。

制限

vSAN 7.0 Update 2 リリースにおける構成の上限については、『構成の上限』ドキュメントを参照してください。

既知の問題

既知の問題には、次のトピックが含まれます。

• vSAN の問題

vSAN の問題

• ファイル共有内のファイルの削除が、vSAN 容量ビューに反映されないことがある

  すべてのファイルが削除された後、割り当てられたブロックがすぐに vSAN ストレージに戻されないことがあります。このため、vSAN 容量ビューに再利用されたストレージ容量が更新されるまでには時間がかかります。また、新しいデータが同じファイル共有に書き込まれると、削除されたブロックが vSAN ストレージに戻される前に再利用されることがあります。

  マッピング解除が有効で、vSAN 重複排除が無効になっている場合は、VDFS で 4MB の整列領域が解放されないと、容量は vSAN に戻されません。マッピング解除が有効で、vSAN 重複排除が有効になっている場合は、VDFS によって解放された容量が vSAN に戻されますが、遅延が発生します。

  回避策：ストレージを解放して vSAN にすぐに戻すには、ファイル共有を削除します。 

• vSAN over RDMA で、ネットワークの輻輳が原因でパフォーマンスが低下する場合がある 

  RDMA には、輻輳のないロスレス ネットワーク インフラストラクチャが必要です。ネットワークが輻輳している場合、特定の大規模な I/O ワークロードで TCP よりもパフォーマンスが低下する可能性があります。 

  回避策：RDMA の OEM ベスト プラクティスに従い、ネットワークの輻輳の問題を解決します。

• 転送中データの暗号化を使用すると、ストレッチ クラスタで vCenter Server 仮想マシンがクラッシュする

  転送中データの暗号化が有効になっている vSAN に vCenter Server 仮想マシンが存在する場合、vSAN ストレッチ クラスタで vCenter Server 仮想マシンがクラッシュすることがあります。1 つのサイトですべてのホストが停止し、これらのホストを再びパワーオンすると、障害が発生したサイトが復旧した後で vCenter Server 仮想マシンがクラッシュすることがあります。

  回避策：この問題を解決するには、thumbPrintRepair.py スクリプトを使用します。  

• VMFS データストアまたは vSAN データストアから vSAN データストアへの仮想マシンの移行が失敗する

  コンテンツ ベースの読み取りキャッシュ (CBRC) を有効にすると、sVmotion または xVmotion で 1 つ以上のスナップショットを持つ仮想マシンを vSAN データストアに移行できないことがあります。次のエラー メッセージが表示されることがあります：「このオブジェクトでは、この操作はサポートされていません。」
  
  次のメッセージが /var/log/vmware/vpxd/ に記録されます。
  
  2021-01-31T17:12:27.477Z error vpxd[18588] [Originator@6876 sub=vpxLro opID=65ef3b53-01] [VpxLRO] Unexpected Exception: N5Vmomi5Fault12NotSupported9ExceptionE(Message is: The operation is not supported on the object.,
  --> Fault cause: vmodl.fault.NotSupported
  --> Fault Messages are:
  --> (null)
  --> )
  -->

  回避策：移行前にスナップショットを統合するか、すべてのスナップショットを削除します。

• vSAN では 1 台の仮想マシンをローカル データストアとリモート データストアにプロビジョニングできる

  vSphere では、ユーザーが HCI メッシュ環境内のローカル データストアとリモート データストアに 1 台の仮想マシンをプロビジョニングすることを妨げません。たとえば、ローカル vSAN データストアに 1 つの VMDK をプロビジョニングし、リモート vSAN データストアに 1 つの VMDK をプロビジョニングできます。vSphere HA はこの構成をサポートしていないため、これはサポートされません。

  回避策：ローカル データストアとリモート データストアに 1 台の仮想マシンをプロビジョニングしないでください。

• オブジェクトの再フォーマット タスクが進行していない

  アップグレード後にオブジェクトの再フォーマットが必要になると、健全性アラートがトリガされ、vSAN の再フォーマットが開始します。このタスクをバッチで実行します。この処理はクラスタ内で使用可能な一時的な容量に依存します。一時的な容量の上限を超えると、vSAN は一時的な容量が解放されるまで再フォーマットを続行しません。このフェーズでは、タスクが停止しているように見える場合があります。一時的な容量が使用可能になると、健全性アラートがクリアされ、タスクが続行します。

  回避策：なし。タスクは想定どおり動作しています。 

• システム仮想マシンをパワーオフできない

  vSphere 7.0 Update 1 の vSphere Cluster Services (vCLS) のリリースでは、一連のシステム仮想マシンが vSAN クラスタ内に配置されることがあります。これらのシステム仮想マシンは、ユーザーがパワーオフすることはできません。この問題は、一部の vSAN ワークフローに影響を及ぼす可能性があります。詳しくは次の記事を参照してください。https://kb.vmware.com/s/article/80877

  回避策：この問題の詳細については、KB80483 を参照してください。 

• vSAN オンディスク フォーマットのバージョンが古いため、vSAN ファイル サービスを有効にできない

  バージョン 11.0（vSAN 7.0 のオンディスク フォーマットのバージョン）より前のバージョンの vSAN オンディスク フォーマットで vSAN ファイル サービスは有効にできません。

  ファイル サービスを有効にする前に、vSAN ディスク フォーマットのバージョンをアップグレードしてください。

• vSAN 健全性ネットワーク テストの問題が原因で、大規模なクラスタでクラスタの修正タスクが失敗することがある

  ホストが 16 台を超える大規模なクラスタでは、ホストのアップグレード中に ping が断続的に失敗する場合があります。この障害により、vSphere Life Cycle Manager でホストの修正が中断する場合があります。

  修正の事前チェックが成功すると、次の vSAN 健全性テストのアラートを無効にします。

  • vSAN：基本（ユニキャスト）接続チェック
  • vSAN：MTU チェック（パケット サイズの大きい ping）

  修正タスクが完了したら、vSAN 健全性テストのアラートを元に戻します。

• ドライブを再挿入すると、ホットプラグ シナリオでホスト障害が発生する

  ホット ドライブの取り外し中に、NVMe ドライブが 1 分以内に抜かれて再挿入されると、VMware ネイティブ NVMe ホットプラグにより、ホスト障害が発生することがあります。この問題は、新規または既存のドライブを再挿入するときに、vSphere と vSAN で発生する可能性があります。

  回避策：ホット ドライブを取り外した後、1 分間待ってから、新しいドライブまたは既存のドライブを再挿入します。

• クラスタ内の最後のホストをメンテナンス モードにしたり、ディスクまたはディスク グループを削除したりできない

  クラスタ内にホストが 1 台しかない場合に、そのホストがメンテナンス モードになると、新しいリソースを追加するためのガイダンスが表示されないで、全データの移行モードまたはアクセシビリティの確保モードで操作が失敗することがあります。この問題は、クラスタ内にディスクまたはディスク グループが 1 つしかない場合に、そのディスクまたはディスク グループを削除したときにも発生します。

  回避策：全データの移行モードまたはアクセシビリティの確保モードを選択した状態で、クラスタ内に最後に残ったホストをメンテナンス モードにする前に、同じ構成の別のホストをクラスタに追加します。クラスタ内に最後に残ったディスクまたはディスク グループを削除する前に、同じ構成および同じ容量の新しいディスクまたはディスク グループを追加します。

• 1 つ以上のディスクまたはディスク グループがほぼいっぱいになっている場合は、容量不足のためにオブジェクト再構成ワークフローが失敗することがある

  重複排除されていないクラスタ内のディスクまたは重複排除クラスタ内のディスク グループが、構成可能な再同期一時停止の使用率のしきい値に達すると、vSAN の再同期が一時停止します。この動作の目的は、再同期 I/O でディスク使用率が 100% になるのを防ぐことです。ディスクがこのしきい値に達すると、vSAN は、EMM、修復、リバランス、ポリシー変更などの再構成ワークフローを停止します。

  回避策：クラスタ内の別の場所に使用可能な容量がある場合、クラスタをリバランスすると、その他のディスクの容量が解放されて、それ以降の再構成が成功します。

• クラスタの容量に空きがない状態からリカバリした後、仮想マシンの HA 保護が失われることがある

  ディスク使用率が 100% に到達しているホストを含む vSAN クラスタでは、仮想マシンに保留中の質問があり、そのために HA 保護が失われることがあります。また、クラスタの容量が不足しているシナリオでリカバリすると、保留中の質問がある仮想マシンが HA で保護されなくなります。

  回避策：vSAN クラスタの容量が不足しているシナリオでリカバリした後、次のいずれかの操作を実行します。

  • HA を無効にしてから、再度有効にします。
  • HA を再構成します。
  • 仮想マシンをパワーオフしてから、パワーオンします。
• 保留中の質問がある仮想マシンのパワーオフが失敗する

  仮想マシンに保留中の質問がある場合は、その質問に回答するまで仮想マシン関連の操作を実行できません。

  回避策：関連ボリューム上のディスク容量を解放してから、再試行 をクリックしてください。

• クラスタ容量が 100% に到達すると、仮想マシンの IP アドレスが IPV6 に変更されるか、使用できなくなる

  1 つ以上のディスク グループの使用率が 100% に到達しており、vSAN クラスタの容量に空きがない場合は、仮想マシンに、ユーザー アクションが必要な保留中の質問が存在する可能性があります。質問に対する回答がなく、クラスタの容量に空きがない状態で放置されている場合は、仮想マシンの IP アドレスが IPv6 に変更されるか、使用できなくなります。これにより、SSH を使用して仮想マシンにアクセスできなくなります。  また、root を入力した後にコンソールが空白になるため、仮想マシン コンソールを使用できなくなります。

  回避策：なし。

• キャパシティ ディスクが PDL の状態になった後に、重複排除が有効なディスク グループを削除できない

  重複排除が有効なディスク グループ内のキャパシティ ディスクが削除された場合、その一意の ID が変更された場合、またはデバイスでリカバリ不能なハードウェア エラーが発生した場合は、Permanent Device Loss (PDL) 状態になります。ディスク グループを削除しようとすると、アクションを完了できないことを知らせるエラー メッセージが表示されることがあります。

  回避策：キャパシティ ディスクが削除された場合、その一意の ID が変更された場合、またはデバイスでリカバリ不能なハードウェア エラーが発生した場合は、数分待ってからディスク グループを削除してください。

• vSAN の健全性が、非可用性に関連する不適合（保留中のポリシーが失敗）状態を示す

  ポリシー変更要求を行っても、vSAN のオブジェクト健全性ステータスが非可用性に関連する不適合状態のままになります。これは、要求されたリソースを利用しているスケジュール設定された作業が他にあるためです。ただし、リソースが使用可能になると、vSAN はこのポリシー要求を自動的に再スケジュール設定します。

  回避策：通常は、vSAN の定期スキャンを行うと、この問題が自動的に修正されます。ただし、ポリシー変更が受け入れられていて、適用されなかった場合も、進行中の他の作業で使用可能なリソースが使用されることがあります。容量レポートに高い値が表示される場合は、容量を追加できます。

• 重複排除クラスタでディスク使用率が 80% を超えていると表示されている場合は、リアクティブ リバランスが実行されないことがある

  重複排除クラスタのダッシュボードに、ディスク使用率が 80% を超えていると表示されている場合は、リアクティブ リバランスが予測どおりに開始されないことがあります。これは、重複排除クラスタの空き容量の計算に、保留中の書き込みと削除も反映されるためです。

  回避策：なし。

• ゲスト OS からの TRIM/UNMAP コマンドが失敗する

  オンライン スナップショットの統合中にゲスト OS が容量の再利用を実行すると、TRIM/UNMAP コマンドは失敗します。この障害により、容量が再利用されなくなります。

  回避策：オンライン スナップショットの操作が完了してから、容量の再利用を実行します。後続の TRIM/UNMAP 操作が失敗する場合は、ディスクを再マウントしてください。

• オンライン スナップショット統合を実行すると、SCSI TRIM/UNMAP で得られた容量の再利用が失われる

  SCSI TRIM/UNMAP コマンドで得られた容量の再利用は、オンライン スナップショット統合を行うと、失われてしまいます。オフライン スナップショット統合は、SCSI UNMAP 操作に影響しません。

  回避策：オンライン スナップショット統合が完了してから、容量の再利用を実行します。

• データ ホストを監視ホストに変換するときに、ホストに障害が発生する

  vSAN クラスタをストレッチ クラスタに変換する場合は、監視ホストを指定する必要があります。データ ホストは監視ホストに変換できますが、処理中にメンテナンス モードを使用して完全なデータ移行を行う必要があります。[アクセシビリティの確保] オプションを使用してこのホストをメンテナンス モードにしてから、監視ホストとして設定すると、ホストに障害が発生してパープル スクリーンが表示されることがあります。

  回避策：監視ホストのディスク グループを削除してから、ディスク グループを再作成します。

• データストアの移行中に常駐ホストに障害が発生すると、vCenter Server で同じ名前の仮想マシンが複製される

  Storage vMotion で、vSAN から別のデータストア（NFS など）に仮想マシンを移行しているときに、仮想マシンが属するホストで vSAN ネットワークの障害が発生して仮想マシンの HA フェイルオーバーが実行されると、仮想マシンが vCenter Server で複製されることがあります。 

  回避策：無効な仮想マシンをパワーオフして、vCenter Server から登録解除します。 

• 新しい vCenter Server で既存のストレッチ クラスタを再構成すると、vSAN が健全性チェックの警告を表示する
  新しい vCenter Server で既存のストレッチ クラスタを再構築すると、vSAN クラスタの健全性チェックが赤になります。次のメッセージが表示されます：vSphere クラスタ メンバーと vSAN クラスタ メンバーが一致

  回避策：次の手順を使用してストレッチ クラスタを構成します。

  1. SSH を使用して、監視ホストにログインします。
  2. 監視ホスト上のディスクを廃止します。次のコマンドを実行します：esxcli vsan storage remove -s "<SSD UUID>"
  3. 監視ホストをクラスタから強制的に離脱させます。次のコマンドを実行します：esxcli vsan cluster leave
  4. 新しい vCenter Server から [構成] > [vSAN] > [ストレッチ クラスタおよびフォルト ドメイン] の順に進んでストレッチ クラスタを再構成します。 

   

• vSAN がサイズの大きいオブジェクトを再同期しているときに、ディスク フォーマットのアップグレードが失敗する
  vSAN クラスタにサイズの非常に大きなオブジェクトが含まれている場合、オブジェクトの再同期中にディスク フォーマットのアップグレードに失敗することがあります。次のエラー メッセージが表示されることがあります：vSAN のオブジェクトの変換に失敗しました。

  オブジェクトが再同期されるまで、vSAN はアップグレードを実行できません。プロセスが完了する時間を確認するには、[監視] > [vSAN] > [コンポーネントの再同期] の順に選択して、再同期のステータスを確認します。

  回避策：保留中の再同期がなくなるまで待機してから、ディスク フォーマットのアップグレードを再試行します。

• クラスタ一貫性の健全性チェックが深い再キー化操作の実行中に失敗する
  暗号化された vSAN クラスタ上で深い再キー化操作を実行すると、完了するまで数時間かかる場合があります。再キー化の実行中に、次の健全性チェックで障害が検出される場合があります：クラスタ構成の一貫性。クラスタ一貫性チェックでは深い再キー化操作が検出されず、実際は問題が発生していない可能性があります。

  回避策：深い再キー化操作が完了した後で、vSAN クラスタ一貫性の健全性チェックを再テストします。

• クラスタ上で vSAN を無効にした後で vSAN ストレッチ クラスタの構成が失われる
  ストレッチ クラスタ上で vSAN を無効にすると、ストレッチ クラスタの構成は保持されません。ストレッチ クラスタ、監視ホストおよびフォルト ドメインの構成は失われます。

  回避策：vSAN クラスタを再度有効にするときに、ストレッチ クラスタのパラメータを再構成してください。

• パワーオフされた仮想マシンが、監視ホストの交換中にアクセス不能として表示される

  ストレッチ クラスタの監視ホストを変更するときに、パワーオフされた仮想マシンがアクセス不能として vSphere Web Client に短時間表示されます。プロセスが完了すると、パワーオフされた仮想マシンがアクセス可能と表示されます。すべての実行中の仮想マシンはプロセスを通じてアクセス可能として表示されます。

  回避策：なし。 

• 障害のあるブート メディアがホストにあるとメンテナンス モードにすることができない
  vSAN がブート メディアに障害のあるホストをメンテナンス モードにすることができません。設定の変更を保存することができないため、メンテナンス モードに移行するタスクは内部 vSAN エラーで失敗することがあります。次のようなログ イベントが表示されます：Lost Connectivity to the device xxx backing the boot filesystem

  回避策：データの完全退避オプションを使用して、各ホストからディスク グループを手動で削除します。それからホストをメンテナンス モードにします。

• vSAN クラスタに vSphere 6.0 Update 1 以前の ESXi ホストがある場合、健全性サービスが動作しない
  クラスタに vSphere 6.0 Update 1 以前のリリースを実行する ESXi ホストがある場合、vSAN 6.6 以降の健全性サービスは動作しません。

  回避策：vSphere 6.0 Update 1 以前のソフトウェアを実行している ESXi ホストを、vSAN 6.6 以降のクラスタに追加しないでください。

• ストレッチ クラスタのフェイルオーバーの後、優先サイト上の仮想マシンが次のアラートを登録する：Failed to failover

  ストレッチ クラスタのセカンダリ サイトが失敗すると、仮想マシンは優先サイトにフェイルオーバーします。すでに優先サイトにある仮想マシンは次のアラートを登録する場合があります：Failed to failover。このアラートは無視してかまいません。これはフェイルオーバーの動作には影響しません。

  回避策：なし。 

• ネットワークのパーティショニング中に、アクティブなサイトのコンポーネントに一時的な障害が発生したと表示される
  vSAN 2 ホストまたはストレッチ クラスタでのネットワークのパーティショニング中に、vSphere Web Client は、非アクティブ サイトの観点からクラスタのビューを表示することがあります。プライマリ サイトのアクティブ コンポーネントに一時的な障害が発生したと表示されることがあります。

  回避策：RVC コマンドを使用して、クラスタ内のオブジェクトの状態をクエリします。例：vsan.vm_object_info

• 強制的な修復後、一部のオブジェクトが非準拠になる
  強制的な修復後、一部のオブジェクトが修復されないままになることがあります。これは、オブジェクトの所有権が処理中に別のノードに転送されたためです。これらのオブジェクトに対する強制的な修復は遅延することがあります。

  回避策：他のすべてのオブジェクトが修復され再同期された後で、強制的な修復を実行します。vSAN がオブジェクトを修復するまで待機することができます。

• ある暗号化クラスタから別の暗号化クラスタに移動したホストを元のクラスタに戻すと、タスクが失敗する
  ある暗号化 vSAN クラスタから別の暗号化 vSAN クラスタにホストを移動し、そのホストを元の暗号化クラスタに戻すと、タスクが失敗する場合があります。次のメッセージが表示される場合があります：一般的なシステム エラーが発生しました：無効な障害です。このエラーは、vSAN が元の暗号化キーを使用してホスト上のデータを再暗号化できないことが原因で発生します。しばらくすると、vCenter Server がホスト上で元のキーをリストアし、vSAN クラスタ内のマウント解除されていたディスクがすべてマウントされます。

  回避策：ホストを再起動し、すべてのディスクがマウントされるまで待ちます。

• サイトの復元後、ストレッチ クラスタのバランスが失われる
  ストレッチ クラスタの障害のあるサイトを復元する場合、そのサイトのホストが長い時間をかけて連続的に戻されることがあります。vSAN は、不完全なコンポーネントの修復を開始するときに一部のホストを過度に使用する可能性があります。

  回避策：障害のあるサイトのすべてのホストを、短時間で一括して復元します。

• ストレッチ クラスタでの HA の問題が原因で、仮想マシン操作が失敗する

  ストレッチ クラスタでの特定の障害シナリオで、vMotion や仮想マシンのパワーオンなどの特定の仮想マシン操作が影響を受ける場合があります。該当する障害シナリオには、サイトの一部または全体の障害や、サイト間の高速ネットワークの障害などがあります。この問題は、ストレッチ クラスタ サイトの通常操作に使用される VMware HA への依存性が原因です。

  回避策：vMotion、仮想マシンの作成、または仮想マシンのパワーオンを実行する前に、vSphere HA を無効にします。その後、vSphere HA を再び有効にします。

• ディスク グループがアンマウントされている場合、深い再キー化を実行することができない
  vSAN は、深い再キー化を実行する前に浅い再キー化を実行します。アンマウントされたディスク グループがある場合、浅い再キー化は失敗します。そのため、深い再キー化を開始することができません。

  回避策：アンマウントされたディスク グループを再マウントするか削除します。

• ログ エントリにファイアウォール構成が変更されたことが示されている
  vSAN 暗号化を有効にすると、新しいファイアウォール エントリ vsanEncryption がセキュリティ プロファイルに表示されます。このルールは、ホストが KMS とどのように直接通信するかを制御します。ルールが適用されると、ログ エントリが /var/log/vobd.log に追加されます。次のメッセージが表示される場合があります：

  Firewall configuration has changed.Operation 'addIP4' for rule set vsanEncryption succeeded.
  Firewall configuration has changed.Operation 'removeIP4' for rule set vsanEncryption succeeded.

  これらのメッセージは無視することができます。

  回避策：なし。 

• vmknic 上で監視トラフィックをサポートするトラフィック タイプ オプションを設定した後、HA フェイルオーバーが発生しない
  vmknic 上で監視トラフィックをサポートするトラフィック タイプ オプションを設定すると、vSphere HA は自動的に新しい設定を検出しません。HA を一度手動で無効にしてから再度有効にして vmknic を検出できるようにする必要があります。vmknic および vSAN クラスタを最初に構成し、次にクラスタ上で HA を有効にすれば、vmknic が検出されます。

  回避策：クラスタ上で vSphere HA を手動で無効にしてから再度有効にします。

• iSCSI MCS がサポートされていない

  vSAN iSCSI ターゲット サービスでは、Multiple Connections per Session (MCS) がサポートされていません。

  回避策：なし。 

• すべての iSCSI イニシエータで iSCSI ターゲットが検出される
  vSAN iSCSI ターゲット サービスでは、ネットワーク上のすべてのイニシエータで iSCSI ターゲットが検出されます。

  回避策：ESXi ホストを個別の VLAN に配置することによって、それらのホストを iSCSI イニシエータから隔離します。

• ネットワーク パーティションの解決後、リンク クローン仮想マシンでの一部の仮想マシン操作が失敗することがある
  ゲスト OS 内に I/O が発生していないリンク クローン仮想マシン上での一部の仮想マシン操作が失敗することがあります。失敗する可能性がある操作には、スナップショットの作成や仮想マシンのサスペンドが含まれます。この問題は、ネットワーク パーティションが解決された後、親ベース仮想マシンのネームスペースにまだアクセスできない場合に発生する可能性があります。親仮想マシンのネームスペースがアクセス可能になった場合、HA には仮想マシンをパワーオンするように通知されません。

  回避策：I/O 操作がアクティブに実行されていない仮想マシンの電源を入れ直します。

• 監視ホストをメンテナンス モードに切り替えることができない
  監視ホストをメンテナンス モードに切り替えようとしても、ホストの状態は変わらず、次の通知が表示されます。指定されたパラメータが正しくありませんでした。

  回避策：監視ホストをメンテナンス モードに切り替える場合、[データの移行なし] オプションを選択します。

• 監視ホストを拡張クラスタ内に移動し、その監視ホストを拡張クラスタの外に移動すると、クラスタの構成が誤った状態のままになる
  vSAN 対応の vCenter Server クラスタに監視ホストを配置すると、監視ホストをクラスタに配置できないことがアラームで通知されます。ただし、監視ホストをクラスタから移動しても、クラスタの構成が誤った状態のままになります。

  回避策：監視ホストを vSAN ストレッチ クラスタから移動し、ストレッチ クラスタを再構成します。詳細については、ナレッジベースの記事 KB2130587 を参照してください。

• HA ハートビート データストアのあるクラスタ内でネットワークのパーティション分割が発生した場合に、他のデータ サイト上で仮想マシンが再起動されない
  vSAN クラスタ内の優先サイトまたはセカンダリ サイトで他のサイトへのネットワーク接続が失われた場合、ネットワーク接続を失ったサイト上で実行中の仮想マシンが他のデータ サイト上で再起動されず、「vSphere HA 仮想マシンの HA フェイルオーバーに失敗しました」という内容のエラーが表示される場合があります。

  これは、vSAN クラスタにおいて想定されている動作です。

  回避策：クラスタで vSphere HA を構成中は、HA ハートビート データストアを選択しないでください。

• アンマウントされた vSAN ディスクおよびディスク グループが、vSphere Web Client の [動作ステータス] フィールドで [マウント済み] として表示される

  ディスクの待ち時間が継続的に長くなっている場合に、esxcli vsan storage disk group unmount コマンドまたは vSAN のデバイス監視サービスを実行して vSAN ディスクまたはディスク グループをアンマウントした後で、vSphere Web Client の [動作ステータス] フィールドに [マウント済み] として誤って表示されます。

  回避策：[動作ステータス] フィールドの代わりに、[健全性] フィールドを使用してディスク ステータスを確認します。