VMware Cloud Director Availability 4.6

4.7 4.6
Português (Brasil) Español 日本語 English

Replicating workloads

By replicating the workload from the source site to the destination site,
VMware Cloud Director Availability
 protects or migrates vApps and virtual machines. These replications are either incoming from a source site or outgoing to a destination site. One vApp or one virtual machine replicates only to one destination site.
Replicate a single workload by protecting or migrating its vApps and virtual machines from one source site to a single destination site.

Replication Types

Two types of replications:
Protection
Protecting a vApp or a virtual machine keeps the workload running in the source site.
Migration
Migrating a vApp or a virtual machine runs the workload in the destination site.
The providers allow protections and migrations separately, by using replication policies, either only incoming or only outgoing or both, or neither.
By default, for a newly deployed
VMware Cloud Director Availability
:
  • Protections are inactive in the default replication policy, both incoming and outgoing.
    To allow the protections to or from the site, the provider must modify the default policy. Alternatively, to keep disaster recovery only for subscribers, the provider assigns a custom policy to the organizations. For more information, see Configuring replication policies.
  • Migrations are active in the default replication policy, both incoming and outgoing, to allow migrating workloads for everyone.
For replications to and from sites backed by
VMware Cloud Director
 with the
Classic
 data engine selected, when starting a replication with a virtual machine that is already configured for replication by another replication solution,
VMware Cloud Director Availability
 reconfigures it for replicating.

Replications Use Cases

VMware Cloud Director Availability
 supports cross-site replications between the following source and destination sites, as shown in the following table, depending on the source and the destination and the activated data engine:
  • Classic data engine
     supports both replication types - protections and migrations: Yes
  • VMC data engine
     supports migrations only: Future
VMware Cloud Director Availability
 cross-site support
Source site*
Destination site
VMware Cloud Director
 site
On-premises
vCenter Server
CDS-managed AVS SDDC
CDS-managed GCVE SDDC
CDS-managed OCVS SDDC
CDS-managed on-premises pVDC
CDS-managed VMC SDDC
VMware Cloud Director
 site
Yes
Yes
Yes
Yes
Yes
Yes
Future
On-premises
vCenter Server
Yes
Yes**
Yes
Yes
Yes
Yes
Future
CDS-managed AVS SDDC
Yes
Yes
Yes
Yes
Yes
Yes
Future
CDS-managed GCVE SDDC
Yes
Yes
Yes
Yes
Yes
Yes
Future
CDS-managed OCVS SDDC
Yes
Yes
Yes
Yes
Yes
Yes
Future
CDS-managed on-premises pVDC
Yes
Yes
Yes
Yes
Yes
Yes
Future
CDS-managed VMC SDDC
Future
Future
Future
Future
Future
Future
Future
* For architecture and for deployment information about the source and destination sites, see the following documentation:

Recovery Point Objective - RPO

Shorter RPO lowers the data loss during recovery, at the expense of consuming more network bandwidth for keeping the destination site replica updated and increasing the volume of event data in the
vCenter Server
 database.
Shorter RPO requires all operations in the background to complete in shorter time periods. Reducing the RPO increases the stress for all infrastructure components and increases the demands for both the source and the destination sites and the connectivity between them. For information about monitoring the environment to discover possible bottlenecks and implementing infrastructure changes for optimizing the flow of the replication data traffic, see the Replication Flow document, applicable for all versions.
Target RPO of Protections
RPO is the longest tolerable time period of data loss from a protected workload.
For example, a protected virtual machine with one hour RPO means that the recovered virtual machine in the destination site can incur no more than one hour of data being lost when the source site fails. In
VMware Cloud Director Availability
 4.3 and later, for protections the RPO selection ranges from one minute to 24 hours. With shorter RPO, an I/O intensive protected workload can cause RPO violations.
Migration RPO is 24 hours.
When each replication reaches its target RPO, in addition to updating the destination site replica the
Replicator Service
 writes about 3800 bytes in the
vCenter Server
 events database. To reduce the volume of event data, configure a longer RPO or limit the number of days that the
vCenter Server
 instance retains event data.

Quiescing

To achieve a consistent state, quiescing the
Replicator Service
 guarantees a failure consistency among all disks in a virtual machine.
Activate Quiesce
Activating quiescing might obtain a higher level of failure consistency among the disks belonging to a virtual machine.
The operating system of a virtual machine determines the available types of quiesce. Quiescing is available only for virtual machine operating systems that support quiescing.

Owner

For
vSphere
 DR and migration between
vCenter Server
 instances not backed by
VMware Cloud Director
, the principal always is
System
. This user is the
SSO Admin Username
 that registers the appliance with the
vCenter Server Lookup service
. This same user owns all replications, meaning all users that see a replication have full control over it.
For replications with cloud sites backed by
VMware Cloud Director
, the user that starts a new replication becomes its owner, depending on the selected default replication owner. After starting the replication, the
system administrator
 can change the owner of a selected replication. Any replication started by the
system administrator
 is not visible to the respective organization and its tenants unless the
system administrator
 explicitly changes the replication ownership to the organization. To manage such a replication by a tenant, change the replication owner to the organization of the tenant.
Change Default Replication Owner
In
VMware Cloud Director Availability
 4.4 and later, as a
system administrator
, to change the default replication owner for new replications, in the left pane under
Configuration
, click
Settings
, then under
Site settings
 next to
Default Replication owner
, click
Edit
. In the
Change Default Replication Owner
 window, select an owner as default for new replications and click
Apply
.
  • System organization
     - assigns the system administrator as a default replication owner for new replications. Tenants do not see replications owned by the system organization.
  • Tenant organization
     - assigns the organization in the destination* site as a default replication owner for new replications, allowing the tenants from the destination organization both to see and interact with the new replications.
Change Existing Replications Owner
As a
system administrator
, to change the owner of one or more already started replications, in the left pane choose a replication direction and click
Incoming Replications
 or
Outgoing Replications
, then select the replications and click
All Actions
Change Owner
. In the
Change Replication Owner
 window, select a new owner organization for the selected replications and click
Apply
.
  • System organization
     - assigns the system administrator as the replications owner.
  • Tenant organization
     - assigns the organization in the destination* site as replications owner.
* Destination organization ownership applies both for replications from cloud sites to cloud sites and from on-premises sites to cloud sites. When the destination of the replication is an on-premises site, assigns the organization in the source site as a replication owner, allowing the tenants from the source organization to see and interact with the replication. Source organization ownership applies only for replications from cloud sites to on-premises sites.
Replication tasks initiated by the
system administrator
 are not visible to the tenants, even after providing the organization with ownership.

Modifying the Hardware of a Source Virtual Machine While Protected by
VMware Cloud Director Availability

The hardware version of the virtual machines in the source site must not be higher than the destination site. This limitation applies both for
vSphere
 DR and migration between
vCenter Server
 instances and for replications with cloud sites backed by
VMware Cloud Director
.
For information about the hardware versions, see
Virtual Machine Compatibility
in the
vSphere
 documentation.
  • Changing a replicated virtual machine name, depending on the replication source:
    • For replications from Cloud Director sites as the source, the destination virtual machine receives the new name within five minutes.
    • For replications from on-premises sites as the source, or
      vSphere
       DR and migration between two vCenter sites, keep the name of the destination virtual machine unchanged.
  • Adding another virtual disk to a replicated virtual machine at the source site pauses the replication.
  • VMDK resizing with
    vSphere
     7.0 in the source site automatically resizes the protected virtual machine disk in the destination site, retaining the replication instances.
  • Modifying the vCPU count or the RAM size of the source virtual machine replicates on RPO or during a manual synchronization in the destination site.

Replicating Thin or Thick Provisioning Virtual Disks

After starting a replication or changing its storage profile,
VMware Cloud Director Availability
 creates the independent disk with a thick provision VMDK, which, on its first resize, becomes a thin provision VMDK.
As a result, from the replication start or change of storage profile until the first resize, the consumed storage equals double the source virtual machine size.
Replication alignment with the destination storage profile
Replications
Replica Disk Provisioning Type
Replications using seed
Thin provision seed disk
Thin provision
Thick provision lazy zeroed seed disk
Thick provision lazy zeroed
Thick provision eager zeroed seed disk
Thick provision eager zeroed
New replications with no seed in
VMware Cloud Director Availability
 4.4 and later
Allowed organization VDC thin provisioning.
Thin provision
Disallowed organization VDC thin provisioning.
Thick provision lazy zeroed
Existing started replications:
  • in earlier
    VMware Cloud Director Availability
     versions.
  • after upgrading to
    VMware Cloud Director Availability
     4.4.
Retain the existing disks types, depending on the seed disk types
vSphere
 DR and migration between
vCenter Server
 sites
When creating each replication, select one of the following provisioning formats for the destination disk:
  • Thin provision
  • Thick provision lazy zeroed
  • Thick provision eager zeroed
By default,
VMware Cloud Director Availability
 4.4 and later for new replications:
  • To and from cloud sites backed by
    VMware Cloud Director
     provision the disk type, depending on whether the destination storage allows thin provisioning in the
    VMware Cloud Director
     organization VDC. For more information, see
    Modify the VM Provisioning Settings of an Organization Virtual Data Center
    in the
    VMware Cloud Director
     documentation.
  • For
    vSphere
     DR and migration between
    vCenter Server
     sites, select the destination disk provisioning format when creating each replication.
The disk provisioning type never changes after creating the replication: starting a replication permanently provisions its replicated disks as thin or thick. The disk provisioning type does not change during the replication lifespan, neither when performing a failover nor when performing a migration.
Existing replications started in an earlier
VMware Cloud Director Availability
 version, after upgrading to version 4.4 retain their disk provisioning type, and for the organization VDC storage policy to take precedence, delete the replications then create and start them again, without using existing replication seeds.
Seed
The replicated disk provisioning type always depends on whether a replication uses a seed. For information about the seeds, see レプリケーション シードの使用.
  • When using seed in the replication, the provisioning of each replica disk retains the provisioning of each replication seed virtual machine disk:
    • Thick-provisioned replication seed disks always provision thick lazy zeroed replica disks.
    • Thin-provisioned replication seed disks always provision thin replica disks.
    For example, a replication seed virtual machine that contains one thin-provisioned and one thick-provisioned disk always replicates as one thin and one thick disk in the destination site, regardless of the storage policy of the organization VDC.
  • When not using seed in the replication, the provisioning of the replicated disks follows the preceding logic.

Replicating Other Storage

Non-volatile memory express (NVMe)
To replicate virtual machines with an NVMe disk controller,
VMware Cloud Director Availability
 requires that both the source and the destination sites run
vCenter Server
 7.0 U2 or later, and
ESXi
 7.0 U2 or later.
Storage DRS (SDRS)
  • At the protected site, storage DRS is supported.
  • At the recovery site, storage DRS does not move replication files between datastores. Datastore maintenance mode, storage balancing, and IO balancing all ignore replication files. The only supported way to move the replication files between datastores is to change the storage policy.
Raw Device Mapping (RDM)
  • RDM in
    virtual
     compatibility mode can be replicated.
  • RDM in
    physical
     compatibility mode is skipped from replication.
Multi-writer Disks
VMware Cloud Director Availability
 does not replicate disks in multi-writer mode.
Independent Disks
VMware Cloud Director Availability
 does not replicate independent disks.
Change Block Tracking (CBT)
VMware Cloud Director Availability
 instances are not compatible with CBT in the source site. For information about the instances, see インスタンスの使用.
IOfilters
VMware Cloud Director Availability
 does not support vSphere APIs for IO Filtering neither in the source site, nor in the destination site.
VMware Cloud Director Availability
 cannot replicate a source virtual machine assigned with a VM Storage Policy that contains IOFilters. You cannot assign such a policy to the destination virtual machine either. Before replicating a virtual machine, ensure its assigned VM Storage Policy does not contain IOFilters. Do not assign VM Storage policies with IOFilters to virtual machines configured for replication.

Storage Space Consumption in the Destination

Replica files keep expanding until there is space on the datastore, disregarding any restrictions in
VMware Cloud Director
:
VMware Cloud Director Availability
 resizes the independent disks associated with the replicated virtual machines to represent the actual used space by the replica data. That causes
VMware Cloud Director
 to display the actual allocation size, which might be greater than the configured allocation size limit of the organization VDC.
Some replication settings and operations require double space in the destination storage, compared with the size of the source virtual machine.
  • For both test failover and for reverse operations, the destination storage must accommodate double the space for the disk size of the source virtual machine. For information about the prerequisites for each operation, see レプリケーションのフェイルオーバーのテスト and レプリケーションのリバース. In
    VMware Cloud Director Availability
     4.2 and later, failover tasks require destination storage space equal to the source workload size. For information about the test failover storage consumption with examples for a datastore and for VMware vSAN storage, see
    VMware Cloud Director Availability
     Storage Requirements
    in the
    Cloud Director サイトのインストール、構成、およびアップグレード ガイド
    .

Content feedback and comments