更新日:2020 年 6 月 23 日 VMware vSAN 7.0 | 2020 年 4 月 24 日 | ビルド 15843807 リリース ノートに追加または更新された内容をご確認ください。 |
リリース ノートの概要
このリリース ノートには、次のトピックが含まれています。新機能
vSAN 7.0 には、次の新機能および機能強化が含まれています。
- vSphere Lifecycle Manager。vSphere Lifecycle Manager は、ESXi ホストのライフサイクルを一貫した簡単な方法で管理します。理想的な状態をモデルとしてハイパーバイザーのライフサイクルを管理し、ドライバとファームウェアの完全なスタックを提供します。vSphere Lifecycle Manager により、個々のコンポーネントのコンプライアンスを簡単に監視し、クラスタ全体で一貫した状態を維持することができます。vSAN 7.0 では、Dell と HPE ReadyNode でこの機能がサポートされています。
vCenter Server 7.0.0a を使用すると、vSAN ファイル サービスと vSphere Lifecycle Manager を同じ vSAN クラスタで同時に有効にすることができます。 - 統合されたファイル サービス。vSAN ネイティブのファイル サービスでは、vSAN クラスタを使用して NFS v4.1/v3 ファイル共有を作成し、提示することができます。vSAN ファイル サービスは、vSAN の能力(可用性、セキュリティ、ストレージ効率、運用管理など)をファイルに拡張しました。
- NVMe ホット プラグのネイティブ サポート。この機能強化により、NVMe デバイスに一貫した方法でサービスが提供され、特定の OEM ドライブの運用効率が向上します。
- ストレッチ クラスタの容量不均衡に基づく I/O リダイレクト。vSAN は、容量制限のあるサイトから他のサイトに仮想マシンの I/O をすべてリダイレクトします。この処理は容量が解放されるまで行われます。この機能により、仮想マシンのアップタイムが向上します。
- vSphere/vSAN の健全性との Skyline の統合。Skyline ブランドへの参加に伴い、vSphere および vSAN 向けの Skyline Health が vSphere Client で利用できるようになり、プロアクティブで一貫した分析によるネイティブな製品内体験を可能にします。
- 共有ディスクの EZT の削除。vSAN 7.0 では、マルチライター フラグを使用する共有仮想ディスクでもゼロ シック フォーマットを使用しなければならないという前提条件がなくなりました。
- パフォーマンス サービスのメトリックとして vSAN メモリをサポート。vSphere Client と API で、vSAN のメモリの使用状況が取得可能になりました。
- vSAN 容量ビューでの vSphere Replication オブジェクトの可視化。vSAN 容量ビューに、vSphere Replication オブジェクトが表示されます。オブジェクトは vSphere レプリカ タイプとして認識され、レプリケーションのカテゴリで容量使用率が考慮されます。
- 大容量のドライブのサポート。今回の機能強化により、32 TB の物理容量ドライブがサポートされるようになりました。重複排除と圧縮が有効になっている場合、論理容量を 1 PB に拡張できます。
- 新しい監視の展開後すぐに修復。vSAN が監視の置き換えを実行するときに、監視の追加後すぐに修復オブジェクト操作を開始します。
- vSphere with Kubernetes の統合CNS は、vSphere with Kubernetes のデフォルトのストレージ プラットフォームです。この統合により、vSAN、VMFS、NFS データストア上の vSphere with Kubernetes スーパーバイザーとゲスト クラスタに、コンテナ化された複数のステートフル ワークロードを展開できます。
- ファイルベースのパーシステント ボリューム。Kubernetes 開発者は、アプリケーションに共有 (Read/Write/Many) のパーシステント ボリュームを動的に作成できます。複数のポッドでデータを共有できます。vSAN ネイティブ ファイル サービスは、この機能を実現するための基盤となります。
- 最新のアプリケーションに対する vVol サポート。vVol 用に追加された CNS サポートを使用して、最新の Kubernetes アプリケーションを vSphere 上の外部ストレージ アレイに拡張できます。vSphere で、vSAN、NFS、VMFS、vVol 全体のパーシステント ボリュームの統合管理が可能になりました。
- vSAN VCG 通知サービス。vSAN ReadyNode、I/O コントローラ、ドライブ(NVMe、SSD、HDD)などの vSAN HCL コンポーネントにサブスクライブし、変更に関する通知メールを受信できるようになりました。ファームウェア、ドライバ、ドライバ タイプ(非同期/インボックス)などの変更が通知されます。新しい vSAN リリースに伴う変更を追跡できます。
- 新機能:デフォルト ゲートウェイのオーバーライド。ESXi 7.0b の vSAN では、各ホストの vSAN VMkernel アダプタのデフォルト ゲートウェイをオーバーライドして、vSAN ネットワークのゲートウェイ アドレスを構成できます。
Kubernetes ノードの仮想マシンをインストールして構成する方法や、クラウド ネイティブ ストレージを使用する方法については、『VMware クラウド ネイティブ ストレージのスタート ガイド』を参照してください。
クラウド ネイティブ ストレージの既知の問題については、vSphere 7.0 リリース ノートを参照してください。
VMware vSAN コミュニティ
vSAN コミュニティ Web サイトを使用して、vSAN の使用中に見つかった問題に対してフィードバックを提供したり、サポートを依頼します。
このリリースのアップグレード
vSAN のアップグレードの詳細については、VMware vSAN 7.0 のドキュメントを参照してください。
注:アップグレードを実行する前に、「VMware 互換性ガイド」の最新バージョンを確認して、ご使用のプラットフォームで最新の vSAN バージョンが利用可能であることを確認してください。
vSAN 7.0 は、vSphere 7.0 への完全アップグレードを必要とする新しいリリースです。アップグレードを完了するには、次のタスクを実行します。
1. vCenter Server 7.0 にアップグレードします。詳細については、「VMware vSphere 7.0 リリース ノート」を参照してください。
2. ホストを ESXi 7.0 にアップグレードします。詳細については、「VMware vSphere 7.0 リリース ノート」を参照してください。
3. vSAN のオンディスク フォーマットをバージョン 11.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 からアップグレードしている間に、ディスク グループの退避が実行されます。ディスク グループが削除されて、オンディスク フォーマット バージョン 11.0 にアップグレードされてから、ディスク グループが再びクラスタに追加されます。2 ノードまたは 3 ノード クラスタの場合、または各ディスク グループを退避させるための十分なキャパシティのないクラスタの場合は、vSphere Client から [冗長性の低下を許可] を選択します。次の RVC コマンドを使用して、オンディスク フォーマットをアップグレードすることもできます:vsan.ondisk_upgrade --allow-reduced-redundancy
冗長性の低下を許可する場合、この方法ではデータがクラスタ内の他のホストに退避されないため、アップグレードの間、仮想マシンが保護されません。この方法では、各ディスク グループが削除されて、オンディスク フォーマットがアップグレードされ、ディスク グループが再びクラスタに追加されます。すべてのオブジェクトを引き続き使用できますが、冗長性は低下します。
vSAN 7.0 へのアップグレード中に重複排除および圧縮を有効にすると、vSphere Client から [冗長性の低下を許可] を選択できます。
制限
vSAN 7.0 リリースにおける構成の上限については、『構成の上限』ドキュメントを参照してください。
解決した問題
- vSphere 7.0 GA リリースの vSAN クラスタで、vSphere Lifecycle Manager と vSAN ファイル サービスの両方を有効にできない
vSphere Lifecycle Manager が有効になっている場合、同じクラスタで vSAN ファイル サービスを有効にできません。また、その逆も同様です。
vCenter Server 7.0.0a を使用すると、vSAN ファイル サービスと vSphere Lifecycle Manager を同じ vSAN クラスタで同時に有効にすることができます。
既知の問題
既知の問題には、次のトピックが含まれます。
vSAN の問題- ホストからディスク グループが削除されると、「vSAN ファイル サービス ノード (6): vSphere HA 仮想マシンの HA フェイルオーバーに失敗しました」というエラー メッセージが表示される
ホストからディスク グループが削除されると、「vSAN ファイル サービス ノード (6): vSphere HA 仮想マシンの HA フェイルオーバーに失敗しました」というエラー メッセージが表示されることがあります。しかし、ファイル サービス ノードにアクセスできなくなり、ホストから削除されます。
このエラー メッセージは、基盤となるディスク グループが削除されたときの vSAN ファイル サービス ノードのフェイルオーバー アクティビティを表しています。vSAN ファイル サービス ノードは、実行中のホストに固定されている仮想マシンであるため、この仮想マシンを他のホストに移行する vSphere HA の処理は失敗します。
ディスク グループを同じホストに再度追加し、vSAN ユーザー インターフェイスを使用して、このクラスタの vSAN ファイル サービスを修正します。
- ホストがメンテナンス モード (EMM) になっているときに vSAN ファイル サービスの修正タスクが失敗する
ホストで EMM タスクが実行されていると、ファイル サービス仮想マシン (FSVM) がパワーオフ状態になります。vSAN ファイル サービスの修正では、これが FSVM の障害と見なされ、修正が行われます。ただし、vCenter Server は、すべての EMM タスクが完了するまで、vSAN ファイル サービスの修正タスクが実行されないようにします。その結果、エラー メッセージが表示されます。
ホストですべての EMM タスクが完了すると、vSAN ファイル サービスの修正タスクが自動的に継続されます。
- vSAN クラスタに追加するホストにディスク グループがない場合、そのホストにファイル サービス仮想マシン (FSVM) を展開できない
ホストでファイル サービスを有効にするには、vSAN が要求するディスク グループが各ホストに存在している必要があります。
ホストにディスク グループを追加し、vSAN からディスク グループを要求できるようにします。
- クラスタ含まれているホストにインフラストラクチャの問題が存在していると、ファイル共有の作成、削除、再構成に失敗することがある
インフラストラクチャに問題のあるホストにファイル共有の作成、削除、再構成がディスパッチされると、操作が失敗することがあります。
問題のクラスタに操作を再試行してください。
- アップグレード後、一部のホストに複数の FSVM が存在する
ファイル サービス仮想マシン (FSVM) のアップグレードが完了した後、一部のホストに複数の FSVM が存在している場合があります。これは、古いバージョンが実行されているか、パワーオフされている可能性があります。
1. 各 FSVM の現在のバージョンを確認します。
2. FSVM がパワーオフ状態であることを確認したら、その FSVM を削除します。
3. FSVM が古いバージョンで実行されている場合は、パワーオフしてホストから削除します。
4. vSAN クラスタに移動して、[監視] > [vSAN] > [Skyline Health] の順にクリックします。
5. [Skyline Health] セクションで [ファイル サービス] をクリックしてから、[再テスト] の順にクリックします。
6. [インフラストラクチャの健全性] をクリックし、[ファイル サービスの修正] をクリックします。修正が完了するまで待ちます。
7. すべての FSVM がパワーオン状態になり、新しいバージョンで実行されるまで、手順 1 ~ 6 を繰り返します。 - クラスタが低下モードの場合、ファイル共有への書き込みで I/O エラー (EIO) が発生することがある
共有内の既存の容量がすべて使用されている場合、vSAN ファイル サービスは、ストレージをスケールアウトするために新しい vSAN オブジェクトを自動的に作成します。クラスタが新しい vSAN オブジェクトを作成できない状態になっている場合、ファイル共有への書き込みが失敗します。クラスタ内のディスクまたはノードで障害が発生し、障害ドメインの数が不足している場合も同様の状態になります。
vSAN 健全性サービスを確認し、クラスタ内の障害を修正します。
- ファイル共有内のファイルの削除が、vSAN 容量ビューに反映されないことがある
すべてのファイルが削除されている場合でも、割り当て済みのブロックは vSAN ストレージに戻されません。この割り当て済みブロックは、新しいデータが同じファイル共有に書き込まれるときに再利用されます。
ストレージを解放して vSAN に戻すには、ファイル共有を削除します。
- ホストのメンテナンス モードへの切り替え (EMM) タスクがフリーズする
- ファイル サービス仮想マシン (FSVM) がパワーオフできないため、ホストの EMM タスクがフリーズすることがあります。ファイル サービスが有効になっていて、ホストがメンテナンス モードになっている場合、このホストに配置されている FSVM がまだ実行されている可能性があります。この問題は、ホスト上で実行されているバックグラウンド監視手順の一部が仮想マシンのパワーオフ アクションと競合するために発生します。パワーオフ アクションは中断されますが、再試行されないため、仮想マシンは実行を継続します。そのため、ホストをメンテナンス モードに切り替えられません。
EMM タスクをキャンセルして、再試行してください。再試行操作が失敗した場合は、VMware グローバル サポートにお問い合わせください。
- 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 クラスタ メンバーが一致回避策:次の手順を使用してストレッチ クラスタを構成します。
- SSH を使用して、監視ホストにログインします。
- 監視ホスト上のディスクを廃止します。次のコマンドを実行します:esxcli vsan storage remove -s "<SSD UUID>"
- 監視ホストをクラスタから強制的に離脱させます。次のコマンドを実行します:esxcli vsan cluster leave
- 新しい 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 の [動作ステータス] フィールドに [マウント済み] として誤って表示されます。
回避策:[動作ステータス] フィールドの代わりに、[健全性] フィールドを使用してディスク ステータスを確認します。