VMware Virtual SAN 6.2 リリース ノート

VMware Virtual SAN 6.2 | 2016 年 3 月 15 日 | ISO ビルド 3620759

これらのリリース ノートへの追加や更新を確認してください。

リリース ノートの概要

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

新機能

Virtual SAN 6.2 には、次の新機能および機能強化が含まれています。

  • デデュープおよび圧縮。Virtual SAN 6.2 では、デデュープおよび圧縮がサポートされており、重複データを削除できます。この機能により、組織のニーズを満たすために必要なストレージ総量を低減できます。Virtual SAN クラスタでデデュープおよび圧縮を有効にすると、特定のディスク グループのデータの冗長コピーが単一のコピーに削減されます。デデュープおよび圧縮は、オールフラッシュ クラスタのクラスタ全体の設定として使用できます。

  • RAID 5 および RAID 6 イレージャ コーディング。Virtual SAN 6.2 では、RAID 5 と RAID 6 の両方のイレージャ コーディングがサポートされており、データの保護に必要なストレージ容量を削減できます。RAID 5 および RAID 6 は、オールフラッシュ クラスタの仮想マシンのポリシー属性として使用できます。RAID 5 は 4 個以上のフォールト ドメインのあるクラスタで使用でき、RAID 6 は 6 個以上のフォールト ドメインのあるクラスタで使用できます。

  • ソフトウェア チェックサム。Virtual SAN 6.2 では、ハイブリッド クラスタおよびオールフラッシュ クラスタでソフトウェアベースのチェックサムを使用できます。ソフトウェア チェックサム ポリシー属性は、Virtual SAN クラスタのすべてのオブジェクトでデフォルトで有効になっています。

  • 新しいオンディスク フォーマット。Virtual SAN 6.2 では、vSphere Web Client を介した、新しいオンディスク仮想ファイル フォーマット 3.0 へのアップグレードがサポートされます。このファイル システムでは、Virtual SAN クラスタの新機能がサポートされています。オンディスク フォーマット バージョン 3.0 は、内部 4K ブロック サイズ テクノロジーに基づいています。このテクノロジーを使用すると、効率が向上しますが、ゲスト OS の I/O が 4K にアラインメントされていないとパフォーマンスが低下する可能性があります。>

  • IOPS 制限。Virtual SAN では、IOPS 制限がサポートされており、指定したオブジェクトの 1 秒あたりの I/O(読み取り/書き込み)処理数を制限できます。読み取り/書き込み処理数が IOPS 制限に達すると、現在の秒が経過するまでこれらの処理が遅れます。IOPS 制限は、VMDK や名前空間などの任意の Virtual SAN オブジェクトに適用できるポリシー属性です。

  • IPv6。Virtual SAN では、IPv4 または IPv6 アドレスがサポートされています。

  • 容量レポート。Virtual SAN 6.2 キャパシティ モニターには、使用容量や空き容量などの Virtual SAN データストアに関する情報、およびオブジェクト タイプまたはデータ タイプごとの容量の使用状況の内訳が表示されます。

  • 健全性サービス。Virtual SAN 6.2 には、クラスタを監視し、クラスタの問題を診断して修正できるようにする新しい健全性チェックが用意されています。Virtual SAN 健全性サービスは、健全性の問題を検出すると、vCenter Server イベントおよびアラームをトリガします。

  • パフォーマンス サービス。Virtual SAN 6.2 には、クラスタレベル、ホストレベル、仮想マシンレベル、ディスクレベルの統計情報を備えたパフォーマンス サービス モニターがあります。パフォーマンス サービスは、パフォーマンス統計情報を収集して分析し、グラフィカルな形式でデータを表示します。パフォーマンス チャートを使用して、ワークロードを管理し、問題の根本原因を特定できます。

  • ライトスルー メモリ内キャッシュ。Virtual SAN 6.2 では、ホスト常駐型のライトスルー読み取りキャッシュを使用することで、仮想マシンのパフォーマンスが向上します。このキャッシュ アルゴリズムにより、読み取り I/O 遅延や、Virtual SAN の CPU 使用率およびネットワーク使用率が低減します。

Virtual SAN の旧リリース

Virtual SAN 6.0 および 6.1 の機能と既知の問題は、リリース ノートに記載されています。Virtual SAN のリリース ノートは次の場所にあります。

VMware Virtual SAN コミュニティ

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

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

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

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

Virtual SAN オンディスク フォーマットのアップグレード中に、ディスク グループの退避が実行されます。次に、ディスク グループが削除されて、オンディスク フォーマット バージョン 3.0 にアップグレードされてから、ディスク グループが再びクラスタに追加されます。2 ノードまたは 3 ノード クラスタの場合、あるいは容量が不足していて各ディスク グループの退避を実行できないクラスタの場合、RVC コマンド vsan.ondisk_upgrade --allow-reduced-redundancy を使用してオンディスク フォーマットをアップグレードする必要があります。

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

Virtual SAN 6.2 へのアップグレード中にデデュープおよび圧縮を有効にすると、vSphere Web Client から冗長性の低下を許可を選択できます。

拡張クラスタでの VMware Update Manager の使用

VMware Update Manager を使用して複数のホストを並行してアップグレードすると、拡張クラスタ内のデータ ホストのいずれかと並行して、監視ホストがアップグレードされます。アップグレードの問題を回避するため、拡張クラスタ内のデータ ホストと並行して監視ホストをアップグレードする構成は VMware Update Manager で使用しないでください。すべてのデータ ホストが正常にアップグレードされてメンテナンス モードを終了してから、監視ホストをアップグレードします。

アップグレード中の健全性チェック エラーの確認

Virtual SAN オンディスク フォーマットのアップグレード中に、物理ディスクの健全性チェック(メタデータの健全性チェック)が断続的に失敗することがあります。主に Virtual SAN でストレージ デバイスに物理ブロックを割り当てる必要があることが原因で、ステージング解除プロセスが遅れている場合、これらのエラーが発生する可能性があります。複数の仮想マシンの展開などのアクティビティの多い期間が終了した後は、この健全性チェックのステータスを確認してからアクションを実行します。健全性チェックが赤のままである場合、警告が有効になっています。健全性チェックが緑の場合、以前の警告を無視できます。詳細については、ナレッジベースの記事 2108690 を参照してください。

制限

オールフラッシュ構成では、Virtual SAN は各ディスク グループにつき最大で 600 GB までの書き込みバッファ キャッシュのサイズをサポートします。

Virtual SAN 6.2 リリースにおけるその他の構成制限の最大値については、『構成の上限』ドキュメントを参照してください。

解決した問題

  • Virtual SAN 6.1 へのアップグレード中に「エージェント オフライン バンドルにアクセスできません」というエラー メッセージが表示される
    このエラーは、健全性チェックが有効な状態の Virtual SAN 6.0 を Virtual SAN 6.1 にアップグレードしているときに発生することがあります。アップグレード プロセス中に健全性チェックの VIB が置き換えられ、そのサービスが一時的に停止されます。健全性チェックでエラー メッセージが生成される場合もあります。

    今回のリリースで、この問題は修正されました。

  • 監視に使用する Virtual SAN クラスタ内にホストを配置し、そのホストをクラスタの外に移動すると、健全性チェックの VIB がそのホストから削除される
    ESXi ホストを Virtual SAN クラスタから移動した場合、その健全性チェック VIB が削除されます。このため、そのホストがクラスタの監視用だった場合、監視のインストール ステータスは赤になります。

    今回のリリースで、この問題は修正されました。

  • フォールト ドメイン内の各ノードが数秒おきに次々に失敗する状況で、大規模な拡張クラスタ(15:15:1 など)でのサイト障害のロールバックの間に、仮想マシンがアクセス不能または孤立した状態になることがある

    今回のリリースで、この問題は修正されました。

  • 拡張クラスタに対して監視ホスト上のオールフラッシュ ディスク グループを構成しようとすると失敗する
    オールフラッシュ ディスク グループを持つ監視ホストを拡張クラスタに追加しようとすると、追加タスクは失敗してホストにディスク グループが追加されません。

    今回のリリースで、この問題は修正されました。

  • ホストを Virtual SAN クラスタに追加すると、インストーラ エラーがトリガされる
    HA および Virtual SAN 健全性サービスが有効なクラスタにESXi ホストを追加するときに、VIB インストールの競合状態が原因で次のエラーのいずれか、または両方が発生する場合があります。

    • タスク ビューの [vSphere HA の構成] タスクが、次のようなエラー メッセージが表示されて失敗する場合があります。vCenter Server Agent Service をインストールできません。不明なインストーラ エラー

    • [エージェントの有効化] タスクが、「操作を完了できません。詳細はイベント ログを確認してください」のようなエラー メッセージが表示されて失敗する場合があります。

    今回のリリースで、この問題は修正されました。

  • 既知の問題

    • Virtual SAN が無効になっていると、ディスクを要求できない
      クラスタで Virtual SAN を有効にする前にディスクを要求してディスク グループを作成しようとすると失敗します。

      回避策:ディスクを要求してディスク グループを作成する前に、クラスタで Virtual SAN を有効にします。

    • esxcli を使用して Virtual SAN 6.2 を有効にすると、自動ディスク要求が機能しない
      esxcli を使用して Virtual SAN 6.2 を有効にすると、自動ディスク要求が機能しません。

      回避策:vSphere Web Client を使用して、自動ディスク要求を構成します。または、手動でディスクを要求することもできます。

    • ロッカー パーティションの容量不足のためホストのアップグレードに失敗する
      アップグレードに失敗して、/var/log/esxupdate.log に次のメッセージが表示されます。

      Failed to create temporary DB dir:[Errno 28] No space left on device:'/locker/packages/var/db/locker/profiles.new' filename = /locker/packages/var/db/locker

      また、/var/log/vobd.log に次のイベントも表示されます。

      2016-02-23T11:50:16.095Z:[VfatCorrelator] 676355748510us:[vob.vfat.filesystem.full] VFAT volume mpx.vmhba32:C0:T0:L0:8 (UUID 55e71deb-2f773c48-5dda-a0369f56dd20) is full.(585696 sectors, 0 free sectors)

      2016-02-24T17:13:00.037Z:[VisorfsCorrelator] 782119690921us:[vob.visorfs.ramdisk.full] Cannot extend visorfs file /vsantraces/vsantraces--2016-02-24T17h12m27s256.gz because its ramdisk (vsantraces) is full.2016-02-24T17:13:00.037Z:[VisorfsCorrelator] 782119691022us:[esx.problem.visorfs.ramdisk.full] The ramdisk 'vsantraces' is full.As a result, the file /vsantraces/vsantraces--2016-02-24T17h12m27s256.gz could not be written.

      回避策:ホストのロッカー パーティションから Virtual SAN Observer の .gz ファイルを削除して、アップグレードを再試行します。

      1. ESXi Shell にログインして、/locker/vsantraces/ にあるロッカー パーティションの消費量を確認します。

      2. df -h コマンドを使用して、100% 使用されている VFAT パーティションを特定します。例:

        df -h
        Filesystem Size Used Available Use% Mounted on
        vfat 249.7M 202.5M 47.3M 81% /vmfs/volumes/68a04eea-90716418-ba59-6dc3297f0ef8
        vfat 249.7M 202.4M 47.3M 81% /vmfs/volumes/6f065ae4-88f03302-b4c6-c0b765c07ff8
        vfat 285.8M 285.7M 112.0K 100% /vmfs/volumes/55e71deb-2f773c48-5dda-a0369f56dd20
        -------------------------------

      3. ホストのロッカー パーティション (/locker/vsantraces/) から Virtual SAN Observer の .gz ログを削除します。例:vsanObserver--YYYY-MM-DDTxxhyymzzs.gz

      4. ホストのアップグレードを再試行します。

    • 6.0 Update 1 ホスト プロファイルが、Virtual SAN vmknic が構成されている 6.0 Update 2 ホストに適用されている場合、コンプライアンス チェックおよび修正に失敗する
      ESXi 6.0 Update 1 から ESXi 6.0 Update 2 にホストをアップグレードしてからホスト プロファイルを適用すると失敗し、「タスクの構成仕様を更新中に予期しないエラーが発生しました: 'IPProtocol'」というメッセージが表示されます。

      回避策:ホストを 6.0 Update 2 にアップグレードし、アップグレードしたホストからホスト プロファイルを抽出して 6.0 Update 2 バージョンのホスト プロファイルを取得できます。

      または、ホスト プロファイルを編集して、編集したホスト プロファイルを、アップグレードしたホストに適用することもできます。

      1. ホスト プロファイルを右クリックし、[ホスト プロファイルのエクスポート] メニューを選択します。ホスト プロファイルが .vpf ファイルとしてエクスポートされます。

      2. テキスト エディタを使用して、.vpf ファイルを開き、次のテキストのすべてのインスタンスを置き換えます。

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IPv4</value></parameter>

        次のテキストに置き換えます。

        <parameter><key>IPProtocol</key><value xsi:type="xsd:string">IP</value></parameter>

      3. 変更したホスト プロファイルをインポートし、ESXi 6.0 Update 2 が実行されているホストに適用します。

    • マスター ノードがフェイルオーバーして再起動すると、SPBM のコンプライアンス ステータスに無効な結果が表示される
      多数の Virtual SAN ノード障害が発生すると、ストレージ ポリシーベース管理 (SPBM) で仮想マシンのコンプライアンス ステータスが誤って [該当なし] と表示されることがあります。この問題は、マスター ノードとバックアップ ノードの両方で障害が発生した場合に起こる可能性があり、その障害に対して SPBM で開始された一連の自動コンプライアンス クエリに起因します。これらのコンプライアンス クエリは、システムにさらに負荷をかけるため、新しいコンプライアンス クエリがタイムアウトしたり、無効な結果が返されたりする可能性があります。

      回避策:自動的に開始されたすべてのコンプライアンス クエリが完了するまで待機します。新しいコンプライアンス クエリでは、無効な結果が返されます。

    • [仮想マシン ストレージ ポリシーの新規作成] ウィザードに誤ったルールのラベルが表示される
      [仮想マシン ストレージ ポリシーの新規作成] ウィザードを開き、Virtual SAN データ サービスに基づいてポリシーを定義する場合、ポリシー ルールを説明するために使用されるラベルに、わかりやすい名前ではなく内部識別子が表示されることがあります。たとえばオブジェクトあたりのディスク ストライプの数の代わりに vsan.capabilitymetadata.propertymetadata.summary.replicaPreference.label が表示されることがあります。

      回避策:vSphere Web Client からログアウトし、再度ログインします。

    • ホストの ESXi ソフトウェア バージョンが異なると、vSphere Web Client の [コンポーネントの再同期] ページに、再同期アクティビティが表示されない
      Virtual SAN クラスタ内のホストをアップグレードすると、一部のホストで ESXi ソフトウェア バージョンが異なることがあります。たとえば、あるホストでは ESXi 6.0 Update 1 が実行されていて、別のホストでは ESXi 6.0 Update 2 が実行されています。アップグレードのこの段階では、vSphere Web Client の [コンポーネントの再同期] ページに、クラスタで発生している再同期アクティビティが表示されない可能性があります。

      回避策:ホストのアップグレード中に再同期アクティビティを監視するには、RVC コマンド vsan.resync_dashboard を使用します。

    • 古い ESXi ソフトウェア バージョンのホストで新しいポリシー ルールが無視される
      この問題は、複数の Virtual SAN クラスタがあり、一方のクラスタで最新のソフトウェアが実行されていて、他方のクラスタで古いバージョンのソフトウェアが実行されている場合に発生することがあります。vSphere Web Client には、最新の Virtual SAN ソフトウェアのポリシー ルールが表示されますが、それらの新しいポリシーは古いホストではサポートされません。たとえば、「RAID-5/6(イレージャ コーディング) – 容量」は、6.0U1 以前のソフトウェアが実行されているホストではサポートされません。新しいポリシー ルールを構成して、任意の仮想マシンおよびオブジェクトに適用できますが、古いソフトウェア バージョンが実行されているホストでは無視されます。

      回避策:なし

    • アップグレード中にスナップショットの統合に失敗することがある
      Virtual SAN オンディスク フォーマットをバージョン 2.0 からバージョン 3.0 にアップグレードしているときに、スナップショットの統合に失敗することがあります。vSphere Client の統合が必要の列では、仮想マシンで統合が必要であることが示されます。このような状況を回避するには、オンディスク フォーマットをアップグレードする前またはアップグレードが完了するまで待機する前にスナップショットの統合を実行します。

      回避策:スナップショットの統合に失敗した場合、オンディスク フォーマットのアップグレードが完了してからこの操作を実行します。

    • Virtual SAN キャパシティ モニターの使用済み容量の内訳にスナップショット メモリ オブジェクトが表示されない
      ハードウェア バージョンが 10 未満で作成された仮想マシンの場合、スナップショット メモリは [使用済み容量の内訳] の [vmem オブジェクト] に含まれます。

      回避策:[使用済み容量の内訳] でスナップショット メモリ オブジェクトを表示するには、10 以上のハードウェア バージョンで仮想マシンを作成します。

    • 統計情報データベース オブジェクトに適用されているストレージ ポリシーを削除すると、Virtual SAN パフォーマンス サービスが無効になる
      パフォーマンス サービスに適用されているストレージ ポリシーを削除すると、vSphere Web Client に「パフォーマンス サービスが無効になっています」という内容のメッセージが表示されます。

      回避策:次の手順を実行して、削除したストレージ ポリシーをリストアするか、既存のストレージ ポリシーをパフォーマンス サービスの統計情報データベース オブジェクトに適用します。この操作では、RVC コマンドを使用します。

      1. SSH を使用して vCenter Server にログインし、Bash シェルにアクセスします。

      2. 次のコマンドを実行して vCenter Server アカウントでログインします。

        rvc localhost

      3. 次のコマンドを実行して、ストレージ ポリシーを統計情報データベース オブジェクトに適用します。

        vsan.perf.stats_object_setpolicy -o <policy> <cluster>

      例:

      vsan.perf.stats_object_setpolicy -o "/localhost/VSAN-DC/storage/vmprofiles/Virtual SAN Default Storage Policy" MyCluster

    • Virtual SAN 6.2 にアップグレードすると、仮想マシンの [サマリ] ページに表示されるストレージ使用量が増えているように見えることがある
      Virtual SAN の以前のリリースでは、仮想マシンのストレージ使用量の値は、データの単一のコピーで使用されている容量でした。たとえば、ゲストが 1 GB を 2 つのミラーがあるシンプロビジョニング オブジェクトに書き込んだ場合、ストレージ使用量は 1 GB として表示されていました。Virtual SAN 6.2 の [ストレージ使用量] フィールドには、データのすべてのコピーを含む実際の使用容量が表示されます。そのため、ゲストが 1 GB を 2 つのミラーがあるシンプロビジョニング オブジェクトに書き込んだ場合、ストレージ使用量は 2 GB として表示されます。Virtual SAN 6.2 にアップグレードすると、一部の仮想マシンで表示されるストレージ使用量が増えているように見えることがありますが、実際の消費容量は増加していません。

      回避策:なし

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

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

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

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

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

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

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

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

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

    • オンディスク フォーマットのアップグレードで、Virtual SAN 上にないディスクが表示される
      ディスク フォーマットをアップグレードする際に、Virtual SAN で、クラスタから削除されたディスクが誤って表示されることがあります。また、ユーザー インターフェイスに、バージョンのステータスが [混合] として表示される場合があります。この表示の問題は、通常、1 つまたは複数のディスクがクラスタから手動でマウント解除された場合に発生します。これは、アップグレード プロセスには影響しません。マウントされたディスクのみがチェックされます。マウント解除されたディスクは無視されます。
    • 回避策:なし

    • 256 文字を超える Virtual SAN フォールト ドメイン名を入力できない
      256 バイトを超えるフォールト ドメイン名を vSphere Web Client で割り当てようとすると、システムに「指定されたパラメータが正しくありません: faultDomainInfo.name」というエラーが表示されます。マルチバイトの Unicode 文字を使用する場合は、256 文字より短くても制限値の 256 バイトに達する可能性があります。

      回避策:なし。

    • すべての Virtual SAN クラスタで、同じ外部プロキシ設定が共有される
      プロキシをクラスタ レベルで設定していても、すべての Virtual SAN クラスタで同じ外部プロキシ設定が共有されます。Virtual SAN では、クラスタがインターネットに直接アクセスしない場合は、外部のプロキシを使用して Support Assistant、カスタマ エクスペリエンス改善プログラム、および HCL データベースに接続します。

      回避策:なし

    • vCenter Server の HTTP または HTTPS ポートおよび証明書設定をデフォルト値から変更すると、Virtual SAN 健全性サービスが正常に動作しない
      Virtual SAN 健全性サービスでサポートされるのは、デフォルトの HTTPS ポート 443 と /etc/vmware-vpx/ssl/rui.crt および /etc/vmware-vpx/ssl/rui.key にあるデフォルトの証明書のみです。デフォルトのポートや証明書を変更すると、Virtual SAN 健全性サービスは正常に動作できなくなります。ステータス コード 400(不正な要求)が返されたり、要求が拒否されたりする可能性があります。

      回避策:デフォルト値を使用するように、Virtual SAN 健全性サービスの HTTP および HTTPS 設定を構成します。

    • Virtual SAN 健全性チェックのマルチキャスト パフォーマンス テストが Virtual SAN ネットワークで実行されない
      ESXi ホストのルーティング構成によっては、ネットワークのマルチキャスト パフォーマンス テストが Virtual SAN ネットワーク上で実行されません。

      回避策:Virtual SAN ネットワークを ESXi ホストの唯一のネットワーク設定として使用し、この構成に基づいて、ネットワークのマルチキャスト パフォーマンス テストを実施します。

      ESXi ホストに複数のネットワーク設定がある場合は、この例に記載された手順に従うこともできます。Virtual SAN は 192.168.0.0 ネットワーク上で実行されると仮定します。

      1. 各ホスト上で、このネットワークへのマルチキャスト グループ アドレスをバインドします。

        $ esxcli network ip route ipv4 add -n 224.2.3.4/32 -g 192.168.0.0?

      2. ルーティング テーブルをチェックします。

        $ esxcli network ip route ipv4 list
        default      0.0.0.0          10.160.63.253  vmk0       DHCP
        10.160.32.0  255.255.224.0    0.0.0.0        vmk0       MANUAL
        192.168.0.0  255.255.255.0    0.0.0.0        vmk3       MANUAL
        224.2.3.4    255.255.255.255  192.168.0.0    vmk3       MANUAL

      3. 事前のマルチキャスト ネットワーク パフォーマンス テストを実行し、結果を確認します。

      4. テストの完了後、ルーティング テーブルを戻します。

        $ esxcli network ip route ipv4 remove -n 224.2.3.4/32 -g 192.168.0.0

    • 優先サイトが分離されると拡張クラスタ内の仮想マシンがアクセス不能になり、その後監視ホストへの接続のみが回復される
      優先サイトが使用できなくなるか、セカンダリ サイトと監視ホストへのネットワーク接続を失うと、セカンダリ サイトが監視ホストとクラスタを形成してストレージ操作が続行されます。優先サイトのデータは、時間の経過とともに古くなる可能性があります。その後優先サイトが監視ホストに再接続されてセカンダリ サイトには接続されない場合、監視ホストは参加していたクラスタを離れて、優先サイトと一緒にクラスタを形成します。このとき、一部の仮想マシンが、このクラスタ内の最新データにアクセスできないために、アクセス不能にあることがあります。

      回避策:優先サイトをクラスタに再接続する前に、セカンダリ サイトを優先サイトとしてマークします。サイトが再同期された後、使用するサイトを優先サイトとしてマークできます。

    • Virtual SAN の監視ホストの OVA で内部 DVS 構成がサポートされない
      VMware Virtual SAN の監視ホストの OVA パッケージでは、監視ホスト内で分散仮想スイッチ (DVS) を構成できません。

      回避策:レガシーの仮想スイッチを使用します。