VMware vSAN 7.0 Update 1 | 2020 年 10 月 6 日 | ビルド 16850804 リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

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

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

新機能

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

妥協のない拡張性

• HCI メッシュ。HCI メッシュは、vSAN のコンピューティング リソースとストレージ リソースを分割するソフトウェアベースのアプローチです。HCI メッシュは、vCenter Server 内でリモート データストアの容量をクラスタ間で使用できるようにすることで、複数の独立した vSAN クラスタを構築します。HCI メッシュにより、データセンターのリソースを効率的に利用し、大規模な環境でもシンプルなストレージ管理が可能になります。
• vSAN ファイル サービスの機能強化。ネイティブ vSAN ファイル サービスで SMB ファイル共有がサポートされます。また、Microsoft Active Directory や Kerberos 認証もサポートされ、スケーラビリティが向上しています。
• 圧縮のみの vSAN。重複排除と別に圧縮を有効にできます。これにより、重複排除を利用できないワークロードでストレージを効率よく使用できます。圧縮のみの vSAN の場合、障害が発生したキャパシティ デバイスの影響を受けるのはそのデバイスのみです。ディスク グループ全体に影響が及ぶことはありません。
• 使用可能な容量の増加。内部の最適化により、vSAN で内部処理とホスト障害時の再構築用に 25 ～ 30% の空き容量を確保しておく必要がなくなりました。必要な容量は、クラスタのサイズ、ストレージ デバイスの集約度などの展開要因によって決まります。これらを変更することで、ワークロードで使用可能な容量を増やすことができます。
• 2 ノード クラスタの共有監視。vSAN 7.0 Update 1 では、単一の vSAN 監視ホストで複数の 2 ノード クラスタを管理できます。1 台の監視ホストで最大 64 個までのクラスタをサポートできるので、運用とリソースのオーバーヘッドが大幅に減少します。

オペレーションの簡素化

• vSAN による転送中データの暗号化。この機能を使用すると、vSAN クラスタ内のノード間で転送されるデータ トラフィックを暗号化し、保護することができます。vSAN による転送中データの暗号化はクラスタ全体の機能ですが、個別に有効にすることも、vSAN による保存データの暗号化と併用することもできます。トラフィックの暗号化では、既存の暗号化機能と同じ FIPS 2 認定の暗号モジュールを使用します。KMS サーバを使用する必要はありません。
• メンテナンス モード時のデータ持続性の強化。この機能強化により、[アクセシビリティの確保] オプションでホストをメンテナンス モードに切り替えたときのデータの整合性が保護されます。メンテナンス中にホストに書き込まれたすべての増分書き込みは、使用可能な別のホストにリダイレクトされます。この機能は、PFTT=1 が設定されている仮想マシンに効果的です。また、メンテナンス中のデータの整合性を維持するために、PFTT=2 の代わりに使用できます。
• vLCM の機能強化。vSphere Lifecycle Manager (vLCM) は、ソフトウェアとファームウェアのライフサイクル管理を統合するソリューションです。今回のリリースでは、vLCM が強化され、Lenovo ReadyNodes のファームウェア サポートが追加されました。vSAN ストレッチ クラスタとフォルト ドメイン構成が認識され、新しいハードウェア互換性事前チェックが追加されています。また、同時実行のクラスタ処理のスケーラビリティも向上しています。
• 予約済み容量。内部クラスタ操作とホスト障害時の再構築用に容量の予約を行うことができます。予約は、データの再構築、リバランス アクティビティ、ポリシーの再構成などの内部操作を、ユーザーによるプロビジョニング アクティビティが妨害しないように設計されたソフトしきい値です。
• デフォルト ゲートウェイのオーバーライド。vSAN ネットワークには、VMkernel アダプタのデフォルト ゲートウェイをオーバーライドして異なるゲートウェイを指定することができます。この機能により、ストレッチ クラスタ、2 ノード クラスタ、フォルト ドメイン環境のルーティング構成が簡素化されます。以前は、スタティック ルートの構成を手動で行う必要がありましたが、スタティック ルートは必要ありません。
• vSAN ホストの再起動の高速化。再起動またはシャットダウンを行う前にメモリ内のメタデータをディスクに保存することで、予定されたホストの再起動時間が短縮されます。vSAN クラスタ内のホストの再起動に必要な時間が短縮されるので、メンテナンス期間中のクラスタ全体のダウンタイムが短縮されます。
• ワークロード I/O 分析。vCenter Server に直接統合された監視/トラブルシューティング ツールの IOInsight を使用して、仮想マシンの I/O メトリックを分析します。パフォーマンス、I/O のサイズとタイプ、読み取り/書き込みの比率、その他の重要なデータ メトリックなど、仮想マシンの I/O 特性の詳細を確認できます。IOInsight の操作は、仮想マシン、ホスト、またはクラスタ全体に対して実行できます。
• 統合 I/O パフォーマンス ビュー。複数の仮想マシンを選択して、IOPS、スループット、遅延などのストレージ パフォーマンス指標をまとめて表示できます。複数の仮想マシン間でストレージのパフォーマンス特性を比較できます。
• IOPS 制限のある仮想マシンの遅延の監視。パフォーマンス監視機能が改善され、IOPS 制限の適用が原因で発生した遅延期間を識別しやすくなりました。このビューは、仮想マシン ストレージ ポリシーで IOPS 制限を設定している場合に役立ちます。
• セキュアなドライブの消去。vSAN クラスタから廃止する前に、一連の新しい PowerCLI または API コマンドを使用して、フラッシュ ストレージ デバイスを安全にワイプできます。これらのコマンドにより、NIST 標準に従ってデータを安全に消去できます。
• ディスクのデータ移行事前チェック。ホスト メンテナンス モードの vSAN データ移行事前チェックで、個々のディスク デバイスやディスク グループ全体がサポートされます。これにより、ディスクまたはディスク グループに対する廃止の事前チェックをきめ細かく行うことができます。
• VPAT セクション 508 の準拠。vSAN は、VPAT (Voluntary Product Accessibility Template) に準拠しています。VPAT セクション 508 の準拠により、vSAN に対してアクセシビリティ要件の監査を徹底的に行い、コンプライアンス対策を適切に実施するため、製品の変更を行いました。

注：vSAN 7.0 Update 1 では、システム全体でタスク タイマーを標準化し、CPU のパフォーマンスを向上させています。この変更により、要求の前または後にタイマーがアクティブ化され、一部のワークロードでパフォーマンスが低下するという問題が解決されました。  

VMware vSAN コミュニティ

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

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

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

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

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

1. vCenter Server 7.0 Update 1 にアップグレードします。詳細については、「VMware vSphere 7.0 Update 1 リリース ノート」を参照してください。 
2. ホストを ESXi 7.0 Update 1 にアップグレードします。詳細については、「VMware vSphere 7.0 Update 1 リリース ノート」を参照してください。 
3. vSAN のオンディスク フォーマットをバージョン 13.0 にアップグレードします。オンディスク フォーマット バージョン 3.0 以降からアップグレードする場合、データの退避は必要ありません（メタデータの更新のみ）。

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

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

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

制限

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

既知の問題

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

• vSAN の問題

vSAN の問題

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

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

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

• ホストのストレージのサマリ情報に vSAN データストアが含まれていない

  ESXi ホストの [サマリ] ビューをクリックしたときに、[空き]、[使用済み]、[容量] 値に関するストレージのサマリ情報にホストからアクセス可能な vSAN データストアが含まれません。

  回避策：vSAN データストアに関する情報は、クラスタの [サマリ] ビューで確認できます。

• オブジェクトの再フォーマット タスクが停止し、処理が行われない。

  オブジェクトの再フォーマット タスクの実行中、vSAN はバックグラウンドでオブジェクトのフォーマットを再構成します。オブジェクトの再構成は一括で行われますが、この処理はクラスタ内で使用可能な一時的な容量に依存します。一時的な容量の上限を超えると、vSAN は一時的な容量が解放されるまで再フォーマットを続行しません。この段階では、タスクが停止し、処理が行われていないように見える場合があります。

  回避策：回避策はありません。

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

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

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

• vSAN ファイル サービス仮想マシン (FSVM) Docker の内部ネットワークが、ユーザー ネットワークと重複していても、警告や再構成が行われないことがある

  指定されたファイル サービス ネットワークが Docker の内部ネットワーク (172.17.0.0/16) と重複している場合、既知の競合問題が発生します。これにより、正しいエンドポイントに対するトラフィックでルーティングの問題が発生します。

  Docker 内部ネットワーク (172.17.0.0/16) と重複しないように、別のファイル サービス ネットワークを指定します。

• vSAN ファイル サービスが有効なクラスタで重複排除または暗号化/圧縮を有効にすると、ファイル サービス仮想マシン (FSVM) を展開するタスクの一部が失敗することがある

  重複排除または暗号化/圧縮を有効にすると、ディスク フォーマットの変更 (DFC) がトリガされます。DFC は各ホストの FSVM を順番に停止します。ただし、ESX Agent Manager (EAM) は FSVM の展開を試みますが、この展開は失敗します。 

  この障害は無視しても問題ありません。DFC の完了後、FSVM の修正は成功します。

• 深い再キー化でクライアント I/O が中断することがある

  深い再キー化プロセスで、NFS および SMB クライアントの I/O 処理が失敗するか、中断することがあります。

  クライアントの障害を許容できない場合は、メンテナンス ウィンドウで深い再キー化プロセスを実行することをおすすめします。

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

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

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

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

  すべてのファイルが削除されている場合でも、割り当て済みのブロックは vSAN ストレージに戻されません。この割り当て済みブロックは、新しいデータが同じファイル共有に書き込まれるときに再利用されます。

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

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

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

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

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

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

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

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

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

• Update Manager に健全性チェックの名前でなく、テスト ID が表示される

  Update Manager を使用して vSAN クラスタ内のホストを修正するときに、vSAN 健全性チェックでアップグレード問題を特定することができます。ホストで修正タスクが失敗すると、健全性チェックの名前ではなく、テスト ID を含むエラー メッセージが表示されることがあります。例：

  ホストが MM を終了する前に、vSAN の健全性チェックに失敗したため、修正に失敗しました。vSAN 健全性チェック com.vmware.vsan.health.test.controlleronhcl が失敗したため、vSAN クラスタは健全ではありません

  各テスト ID は、vSAN 健全性チェックに関連しています。修正の健全性チェックの詳細については、次の記事を参照してください。https://kb.vmware.com/s/article/60219

  回避策：vSAN ホストで修正タスクが失敗した場合は、健全性サービスを使用して問題を特定し、解決します。解決したら、別の修正タスクを実行します。

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

  クラスタ内にホストが 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 の [動作ステータス] フィールドに [マウント済み] として誤って表示されます。

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