ワークロードをソース サイトからターゲット サイトにレプリケートすることで、VMware Cloud Director Availability は vApp および仮想マシンを保護または移行します。これらのレプリケーションは、ソース サイトから受信するか、ターゲット サイトに送信されます。1 つの vApp または 1 台の仮想マシンは、1 つのターゲット サイトにのみレプリケートされます。

vApp および仮想マシンを 1 つのソース サイトから単一のターゲット サイトに保護または移行することで、単一のワークロードをレプリケートします。

レプリケーション タイプ

レプリケーションには次の 2 つのタイプがあります。

保護
vApp または仮想マシンを組織間で保護すると、ワークロードがソース サイトで実行され続けます。
移行
vApp または仮想マシンをリモート組織に移行すると、ワークロードがターゲット サイトで実行されます。

プロバイダは、レプリケーション ポリシーを使用して保護と移行を個別に許可できます（受信のみ、送信のみ、またはその両方を許可するか、どちらも許可しません）。

デフォルトでは、新しくデプロイされた VMware Cloud Director Availability の場合:
  • デフォルトのレプリケーション ポリシーでは、受信と送信の両方で保護が無効になります。

    サイトとの間の保護を許可するには、プロバイダがデフォルト ポリシーを変更する必要があります。または、サブスクライバのディザスタ リカバリのみを維持するために、プロバイダは組織にカスタム ポリシーを割り当てます。詳細については、レプリケーション ポリシーの構成を参照してください。

  • デフォルトのレプリケーション ポリシーで移行（受信と送信の両方）がアクティブになり、すべてのユーザーがワークロードを移行できるようになります。

VMware Cloud Director Availability 4.3 以降では、[クラシック] データ エンジンが選択された VMware Cloud Director によってバッキングされるサイト間のレプリケーションで、別のレプリケーション ソリューションによってすでにレプリケーション用に構成されている仮想マシンでレプリケーションを開始すると、VMware Cloud Director Availability によってレプリケーション用に仮想マシンが再構成されます。

レプリケーションの使用事例

VMware Cloud Director Availability は、レプリケーションのソースとターゲットの両方、および選択したデータ エンジンに応じて、表に示すように、次のソース サイトとターゲット サイト間のクロスサイト レプリケーションをサポートします。

  • [クラシック データ エンジン] は、保護と移行の両方のレプリケーション タイプをサポートします：あり
  • [VMC データ エンジン] は移行のみをサポートします：将来

詳細については、「ワークロードをレプリケートするためのデータ エンジンの有効化」を参照してください。

表 1. VMware Cloud Director Availability クロスサイト サポート
ソース サイト* ターゲット サイト
VMware Cloud Director サイト オンプレミス vCenter Server CDS で管理される VMC SDDC CDS で管理される AVS SDDC CDS で管理される GCVE SDDC CDS で管理される OCVS SDDC CDS で管理されるオンプレミス pVDC
VMware Cloud Director サイト あり あり 将来 将来 あり あり あり
オンプレミス vCenter Server あり あり** 将来 将来 あり あり あり
CDS で管理される VMC SDDC 将来 将来 将来 将来 将来 将来 将来
CDS で管理される AVS SDDC 将来 将来 将来 将来 将来 将来 将来
CDS で管理される GCVE SDDC あり あり 将来 将来 あり あり あり
CDS で管理される OCVS SDDC あり あり 将来 将来 あり あり あり
CDS で管理されるオンプレミス pVDC あり あり 将来 将来 あり あり あり

* アーキテクチャおよびソース サイトとターゲット サイトのデプロイ情報については、次のドキュメントを参照してください。

目標復旧ポイント - RPO

RPO を短くすると、リカバリ中のデータ損失が低減します。ただし、ターゲット サイトのレプリカを更新し続け、vCenter Server データベースのイベント データ量を増やすには、より多くのネットワーク帯域幅を使用します。

RPO を短くするには、バックグラウンドですべての操作を短時間で完了する必要があります。RPO を減らすと、すべてのインフラストラクチャ コンポーネントのストレスが増加し、ソース サイトとターゲット サイトの両方、およびそれらの間の接続に対する要求が増加します。環境を監視して潜在的なボトルネックを検出し、レプリケーション データ トラフィックのフローを最適化するためのインフラストラクチャの変更を実装する詳細については、 レプリケーション フローのドキュメントを参照してください。
保護のターゲット RPO
RPO は、保護されたワークロードからのデータ損失の最も長い許容期間です。
たとえば、1 時間の RPO で保護された仮想マシンは、ソース サイトに障害が発生した場合に、ターゲット サイトでリカバリされた仮想マシンのデータ損失が 1 時間を超えないことを意味します。 VMware Cloud Director Availability 4.3 以降では、保護のために RPO の選択範囲は 1 分から 24 時間です。RPO を短くすると、I/O を多用する保護されたワークロードによって RPO 違反が発生する可能性があります。
注： 移行の RPO は 24 時間です。

各レプリケーションがターゲット RPO に到達すると、ターゲット サイトのレプリカを更新することに加えて、Replicator Service は約 3,800 バイトを vCenter Server イベント データベースに書き込みます。イベント データの量を減らすには、より長い RPO を構成するか、vCenter Server がイベント データを保持する日数を制限します。

静止

整合性のある状態を実現するには、 Replicator Service を静止することで、仮想マシン内のすべてのディスク間で障害時の整合性を保証します。
静止の有効化
静止を有効にすると、仮想マシンに属するディスク間で高レベルの障害時の整合性が得られます。
仮想マシンのオペレーティング システムによって、使用可能な静止のタイプが決まります。静止は、静止をサポートする仮想マシン オペレーティング システムでのみ使用できます。

所有者

注： VMware Cloud Director によってバッキングされていない vCenter Server インスタンス間の vSphere DR および移行の場合、プリンシパルは常に システム です。このユーザーは、アプライアンスを vCenter Server Lookup service に登録する [SSO 管理者ユーザー名] です。この同じユーザーがすべてのレプリケーションを所有しています。つまり、レプリケーションを表示するすべてのユーザーは、レプリケーションを完全に制御できます。
VMware Cloud Director によってバッキングされているクラウド サイトでのレプリケーションの場合、選択したデフォルトのレプリケーション所有者に応じて、新しいレプリケーションを開始するユーザーがその所有者になります。レプリケーションの開始後、 システム管理者は選択したレプリケーションの所有者を変更できます。 システム管理者によって開始されたレプリケーションは、 システム管理者がレプリケーションの所有権を組織に対して明示的に変更しない限り、それぞれの組織とそのテナントには表示されません。このようなレプリケーションをテナントによって管理するには、レプリケーションの所有者をテナントの組織に変更します。
デフォルトのレプリケーション所有者の変更
VMware Cloud Director Availability 4.4 以降では、 システム管理者として、新しいレプリケーションのデフォルトのレプリケーション所有者を変更するには、左側のペインの [構成] で [設定] をクリックし、 [サイト設定] の [デフォルトのレプリケーション所有者] の横にある [編集] をクリックします。 [デフォルトのレプリケーション所有者の変更] ウィンドウで、新しいレプリケーションのデフォルトの所有者を選択し、 [適用] をクリックします。
  • [システム組織] - システム管理者を新しいレプリケーションのデフォルトのレプリケーション所有者として割り当てます。テナントには、システム組織が所有するレプリケーションは表示されません。
  • [テナント組織] - ターゲット* サイトの組織を新しいレプリケーションのデフォルトのレプリケーション所有者として割り当て、ターゲット組織のテナントが新しいレプリケーションを表示して操作できるようにします。
既存のレプリケーション所有者の変更
システム管理者として、すでに開始されている 1 つ以上のレプリケーションの所有者を変更するには、左側のペインでレプリケーションの方向を選択し、 [受信レプリケーション] または [送信レプリケーション] をクリックします。次にレプリケーションを選択し、 [すべてのアクション] > [所有者の変更] をクリックします。 [レプリケーション所有者の変更] ウィンドウで、選択したレプリケーションの新しい所有者組織を選択し、 [適用] をクリックします。
  • [システム組織] - システム管理者をレプリケーション所有者として割り当てます。
  • [テナント組織] - ターゲット* サイトの組織をレプリケーション所有者として割り当てます。
* ターゲット組織の所有権は、クラウド サイトからクラウド サイトへのレプリケーション、およびオンプレミス サイトからクラウド サイトへのレプリケーションの両方に適用されます。レプリケーションのターゲットがオンプレミス サイトの場合、ソース サイトの組織をレプリケーション所有者として割り当て、ソース組織のテナントがレプリケーションを表示して操作できるようにします。ソース組織の所有権は、クラウド サイトからオンプレミス サイトへのレプリケーションにのみ適用されます。

システム管理者によって開始されたレプリケーション タスクは、組織に所有権を付与した後でもテナントに表示されません。

VMware Cloud Director Availability による保護中のソース仮想マシンのハードウェアの変更

注： ソース サイトの仮想マシンのハードウェア バージョンは、ターゲット サイトよりも高くすることはできません。この制限は、 vCenter Server インスタンス間の vSphere DR と移行、および VMware Cloud Director によってバッキングされているクラウド サイトでのレプリケーションの両方に適用されます。

ハードウェア バージョンの詳細については、vSphere ドキュメントの仮想マシンの互換性を参照してください。

  • ソース サイトのレプリケートされた仮想マシンに別の仮想ディスクを追加すると、レプリケーションが一時停止します。
  • ソース サイトの vSphere 7.0 で VMDK のサイズを変更すると、ターゲット サイトの保護対象の仮想マシン ディスクのサイズが自動的に変更され、レプリケーション インスタンスが保持されます。
  • ソース仮想マシンの vCPU 数または RAM サイズを変更すると、RPO またはターゲット サイトでの手動同期でレプリケートされます。

シン プロビジョニングまたはシック プロビジョニング仮想ディスクのレプリケート

レプリケーションを開始するか、そのストレージ プロファイルを変更した後、VMware Cloud Director Availability はシック プロビジョニング VMDK を使用して独立ディスクを作成します。このディスクは、最初のサイズ変更時にシン プロビジョニング VMDK になります。

その結果、レプリケーション開始またはストレージ プロファイルの変更から最初のサイズ変更まで、使用されるストレージはソース仮想マシンのサイズの 2 倍になります。

表 2. レプリケーションとターゲット ストレージ プロファイルのアライメント
レプリケーション レプリカ ディスクのプロビジョニング タイプ
シードを使用したレプリケーション シン プロビジョニング シード ディスク シン プロビジョニング
シック プロビジョニング (Lazy Zeroed) シード ディスク シック プロビジョニング (Lazy Zeroed)
シック プロビジョニング (Eager Zeroed) シード ディスク シック プロビジョニング (Eager Zeroed)
VMware Cloud Director Availability 4.4 以降でシードのない新しいレプリケーション 許可された組織 VDC シン プロビジョニング。 シン プロビジョニング
許可されていない組織 VDC シン プロビジョニング。 シック プロビジョニング (Lazy Zeroed)
既存の開始済みレプリケーション：
  • 以前のバージョンの VMware Cloud Director Availability。
  • VMware Cloud Director Availability 4.4 にアップグレードした後。
 シード ディスク タイプに応じて、既存のディスク タイプを保持
vCenter Server サイト間の vSphere DR と移行 各レプリケーションを作成する場合は、ターゲット ディスクに対して次のいずれかのプロビジョニング フォーマットを選択します。
  • シン プロビジョニング
  • シック プロビジョニング (Lazy Zeroed)
  • シック プロビジョニング (Eager Zeroed)

デフォルトでは、新しいレプリケーションでは VMware Cloud Director Availability 4.4 以降：

  • VMware Cloud Director によってバッキングされるクラウド サイトとの間で、ターゲット ストレージが VMware Cloud Director 組織 VDC でシン プロビジョニングを許可するかどうかに応じて、ディスク タイプをプロビジョニングします。詳細については、VMware Cloud Director ドキュメントの組織仮想データセンターの仮想マシン プロビジョニング設定の変更を参照してください。
  • vCenter Server サイト間の vSphere DR および移行の場合は、各レプリケーションを作成するときにターゲット ディスクのプロビジョニング フォーマットを選択します。

レプリケーションの作成後にディスクのプロビジョニング タイプが変更されることはありません。レプリケーションを開始すると、レプリケートされたディスクが永続的にシンまたはシックとしてプロビジョニングされます。ディスク プロビジョニング タイプは、フェイルオーバーを実行するときも移行を実行するときも、レプリケーションの存続期間中は変更されません。

以前の VMware Cloud Director Availability バージョンで開始された既存のレプリケーションは、バージョン 4.4 にアップグレードした後もディスク プロビジョニング タイプを保持し、組織 VDC ストレージ ポリシーが優先される場合は、既存のレプリケーション シードを使用せずにレプリケーションを削除し、その後再度作成して起動します。

シード
レプリケートされたディスク プロビジョニング タイプは、レプリケーションがシードを使用するかどうかによって常に異なります。シードの詳細については、 レプリケーション シードの使用を参照してください。
  • レプリケーションでシードを使用する場合、各レプリカ ディスクのプロビジョニングは、各レプリケーション シード仮想マシン ディスクのプロビジョニングを保持します。
    • シック プロビジョニングのレプリケーション シード ディスクは、常にシック (Lazy Zeroed) レプリカ ディスクをプロビジョニングします。
    • シン プロビジョニングのレプリケーション シード ディスクは、常にシン レプリカ ディスクをプロビジョニングします。
    たとえば、1 つのシン プロビジョニング ディスクと 1 つのシック プロビジョニング ディスクを含むレプリケーション シード仮想マシンは、組織 VDC のストレージ ポリシーに関係なく、常にターゲット サイトに 1 つのシン ディスクと 1 つのシック ディスクとしてレプリケートされます。
  • レプリケーションでシードを使用しない場合、レプリケートされたディスクのプロビジョニングは前述のロジックに従います。

その他のストレージのレプリケート

Non-Volatile Memory Express (NVMe)
NVMe ディスク コントローラを使用して仮想マシンをレプリケートするには、 VMware Cloud Director Availability でソース サイトとターゲット サイトの両方が vCenter Server 7.0 U2 以降を実行している必要があります。
Storage DRS (SDRS)
  • 保護サイトでは、Storage DRS がサポートされます。
  • リカバリ サイトでは、Storage DRS はデータストア間でレプリケーション ファイルを移動しません。データストアのメンテナンス モード、ストレージ バランシング、および I/O バランシングではすべて、レプリケーション ファイルが無視されます。データストア間でレプリケーション ファイルを移動する唯一の方法は、ストレージ ポリシーを変更することです。
Raw Device Mapping (RDM)
  • [仮想]互換モードの RDM はレプリケートできます。
  • [物理]互換モードの RDM はレプリケーションからスキップされます。
マルチライター ディスク
VMware Cloud Director Availability では、マルチライター モードのディスクはレプリケートされません。
独立したディスク
VMware Cloud Director Availability では、独立ディスクはレプリケートされません。
変更ブロックのトラッキング (CBT)

VMware Cloud Director Availability インスタンスは、ソース サイトの CBT と互換性がありません。インスタンスの詳細については、インスタンスの使用を参照してください。

IOfilter
VMware Cloud Director Availability は、ソース サイトでもターゲット サイトでも I/O フィルタリング用の vSphere API をサポートしていません。 VMware Cloud Director Availability は、IOFilter を含む仮想マシン ストレージ ポリシーで割り当てられたソース仮想マシンをレプリケートできません。このようなポリシーをターゲット仮想マシンに割り当てることもできません。仮想マシンをレプリケートする前に、割り当てられた仮想マシン ストレージ ポリシーに IOFilter が含まれていないことを確認します。IOFilter を含む仮想マシン ストレージ ポリシーを、レプリケーション用に構成された仮想マシンに割り当てないでください。

ターゲットのストレージ容量使用量

注： レプリカ ファイルは、データストアに容量が存在する限り、 VMware Cloud Director の制限を無視して、拡張し続けます。

VMware Cloud Director Availability は、レプリカ データによって実際に使用されている領域を表すために、レプリケートされた仮想マシンに関連付けられている独立ディスクのサイズを変更します。これにより、VMware Cloud Director に実際の割り当てサイズが表示され、組織 VDC の構成済みの割り当てサイズ制限よりも大きくなる可能性があります。

一部のレプリケーション設定および操作では、ソース仮想マシンのサイズと比較して、ターゲット ストレージに 2 倍の容量が必要です。

  • テスト フェイルオーバーとリバース操作の両方で、ターゲット ストレージはソース仮想マシンのディスク サイズの 2 倍の容量に対応する必要があります。各操作の前提条件の詳細については、レプリケーションのフェイルオーバーのテストおよびレプリケーションのリバースを参照してください。VMware Cloud Director Availability 4.2 以降では、フェイルオーバー タスクにはソース ワークロード サイズと同じターゲット ストレージ容量が必要です。テスト フェイルオーバー ストレージ使用量の詳細と、データストアおよび VMware vSAN ストレージの例については、『Installation, Configuration, and Upgrade Guide in the Cloud Director Site』のVMware Cloud Director Availability のストレージ要件を参照してください。

  • シードを使用する場合、ターゲット ストレージはソース仮想マシンのディスク サイズの 2 倍の容量に対応する必要があります。シードを使用する場合の容量要件の詳細については、ターゲット データストアの領域使用量を参照してください。