Use a new,
unused virtual disk for the destination. See Offline
Initialization for details of this process.In this topic:
Also see:
Configuring Server Groups for Replication
Replication is the process of copying the data from a "source" virtual disk on one DataCore Server to a "destination" virtual disk on another DataCore Server. The destination virtual disk becomes a usable copy of the source virtual disk. Replication is achieved through asynchronous mirroring of the data.
A remote replication is the most usual application of this feature; meaning that the source is on a server in the local server group and the destination is on a server in a remote server group that is "partnered" with the local group. One local group can also be partnered with multiple remote groups. Virtual disks can also be replicated locally from one server to another in the same local server group.
Note: When replicating within the same server group, the port to be used for transmission of replication data between DataCore Servers cannot be specified. As such, data will be sent via the IP address which resolves from the replication server host name (the default DNS name resolution) and this IP may be used for communications other than replication traffic.
Each source virtual disk may only be replicated to one destination virtual disk. In other words, the same source virtual disk cannot be simultaneously replicated to more than one destination. A virtual disk can only be a member of one replication.
Replication is available in two types: Unidirectional and Bidirectional.
o Unidirectional replication allows data to be transmitted in one direction; from a virtual disk on a local DataCore Server (source) to a virtual disk on another DataCore Server (destination) and the direction cannot be reversed.
o Bidirectional replication (Advanced site recovery) allows data to be transmitted in two directions; from a virtual disk on a local DataCore Server (source) to a virtual disk on another DataCore Server (destination) and the direction can be reversed. In this case, the source and destination roles are switched. The original source becomes the new destination, and the original destination becomes the new source. An Advanced Site Recovery license (ASR) is required on both source and destination.
Replication was known as Asynchronous IP Mirroring (AIM) in earlier software versions.
Virtual disk replication is beneficial in environments where synchronous mirroring is not a viable solution due to distance. This is because during the synchronous mirroring process, I/O write acknowledgements are not returned to the requesting host until the data is received by both DataCore Servers responsible for maintaining the mirrored virtual disks. Over long distances, the latency involved may directly and negatively impact performance.
With asynchronous mirroring, it is understood that the throughput between the sites is limited, and therefore, I/O writes to the source virtual disk are acknowledged immediately. Updating the data changes on the destination virtual disk is made as soon as possible, but does lag behind.
Replication provides capabilities that cannot be accomplished with a synchronous mirroring process:
o Off-site data backup and archiving over long distances.
o Emergency site failover for disaster recovery in the event of natural disaster, fire, and so on. (Bidirectional replication allows for site failback.)
o Controlled site swaps for situations; such as site maintenance, scheduled power cut-off, construction activity, and threat of a natural disaster. (Bidirectional replication allows for active sites to be swapped back when desired.)
Virtual disk replication occurs over TCP/IP connection via a proprietary transfer protocol designed by DataCore Software.
When a replication is created, the source and destination virtual disks are synchronized through initialization. Initialization is the process of creating a "baseline" image on the destination virtual disk. Existing data on the destination is overwritten, making the destination an identical copy of the source.
Initialization can be performed online or offline:
o Online initialization is an automatic process, but can require a significant amount of time—perhaps several days to complete. Before the initialization process begins, source and destination virtual disks are checked for consistency. Data on the source is compared to data on the destination. Data transfers are kept to a minimum during initialization by only transferring data that does not already exist on the destination. When the destination disk is newly created and contains no data, a full initialization will occur. Should a problem occur during this process that requires initialization to restart, the data that already exists on the destination will not have to be transferred again. The time required to complete initialization will vary depending on the amount of data and data transfer rates. Online initialization is a good option if the source virtual disk has a small amount of data, or if the destination contains some of the same data that is on the source.
o Offline
initialization is a manual process, but can save a significant amount
of time. Offline initialization could be a good option when the source
virtual disk has a large amount of data, as well as limited data transfer
capacity. In this process, the source virtual disk data is automatically
copied to a pre-existing folder location (removable drive, network location
or local folder) using the Virtual Disk Details page>Replication
tab for the source virtual disk. When all data has been copied to
the offline replication buffer, prepare the data to be transported and
deliver the data to the destination using a shipping or courier service.
When the data has arrived at the destination, copy the data to the offline
replication buffer on the destination. The data will be automatically
copied from the offline buffer folder to the destination virtual disk
using the Virtual Disk Details page>Replication
tab for the destination virtual disk. Since all source data is simply
copied to the destination, the source and destination virtual disks are
not checked for consistency or compared as they are in the online initialization
process.
Use a new,
unused virtual disk for the destination. See Offline
Initialization for details of this process.
After the replication is created, the I/O stream from the host is actively monitored for data changes. Every data change is collected, journalized, and stored in a dedicated buffer location. The data changes are transferred to the destination virtual disk as soon as possible. Data changes will continue to be transferred while the source and destination virtual disks are in a replication configuration.
When a replication is created, the source virtual disk has a status of "active" and is referred to as the "active" virtual disk because from the viewpoint of the host, the paths between the source virtual disk and the host are active. At the same time, the destination virtual disk has a status of "standby" is referred to as the "standby" virtual disk because any paths between the destination virtual disk and the host are disabled. For a complete list of replication states, see Replication Status.
Replication transfer priority ensures that replication traffic is prioritized according to the replication priority setting in the storage profile assigned to a virtual disk Replication priority levels from highest priority to lowest priority are Critical, High, Regular (default setting), and Low.
Replication traffic of virtual disks with higher replication priority settings are given more available throughput to transfer data than virtual disks with lower priority settings.
All active replications to a destination server share one replication transfer path. Each replication priority level is assigned a quota of the total throughput of that transfer path. Virtual disks with a low priority will be afforded the smallest quota of the transfer path, while virtual disks with a critical priority will be afforded the largest quota of the transfer path. For example, assume there are three virtual disks with different replication transfer priorities: one critical, one high, and one regular. The critical virtual disk consumes 50% of the available throughput, the high virtual disk consumes 33% and the regular virtual disk consumes 17%.
Transfers within a priority queue are cycled in round-robin fashion so that if numerous replications exist with the same priority, data transfers are performed equally. If replications do not exist for all priorities, other replications will share the remaining throughput of the transfer channel based on the replication priority priorities.
Additional Notes:
o Replication transfer priority applies to the sender of the data or "Active" replication side only.
o Changes to the replication priority in the storage profile of a virtual disk have an immediate effect on data transfers.
Test mode allows for a "trial run" of the process of reversing the replication direction. This is achieved by temporarily activating the standby virtual disk. Test mode is performed per virtual disk from the standby side of a replication. While in test mode, the standby virtual disk can be tested to ensure that paths are correctly configured and hosts on the standby side will have read/write access to the virtual disk. Data changes made to the standby virtual disk while in test mode are temporary and will be discarded after test mode is exited.
Replication traffic to the active virtual disk can continue while the standby virtual disk is in test mode.
For more information, see Replication Operations.
Advanced site recovery (ASR) allows for bidirectional replication and requires a replication license on the source and destination.
The replication direction can be reversed as required. When a controlled or emergency failover is necessary at the production (source) site, the roles of the source (active) and destination (standby) virtual disks can be swapped. When a failover is required, the replicated virtual disks at the failover site can be activated and made accessible to a host at the failover site. Data changes made by the host at the failover site will be added to the replication buffer created on the DataCore Server at the failover site.
When the production site is functional again, the failback process can begin. The virtual disks at the production side can be activated again. Data changes in the replication buffer at the failover site are transferred to the production site.
See a diagram of the recommended failover/failback scenario. 
In a controlled failover, the replication process eventually transfers all the pending files in the replication buffer to guarantee that both virtual disks are in a known, stable state.
Both virtual disks go through transitional states before the role swap is complete. The source virtual disk goes from Active to Deactivating state and blocks data transfers until all replication file transfers have completed on the destination virtual disk. The destination virtual disk goes from Standby to Activating state.
When both virtual disks are identical, the role swap is completed; the destination virtual disk goes into Active state and becomes the new source, and the old source goes into Standby state and becomes the new destination.
The newly activated virtual disk is served to a host at the failover site and put into use. Data changes made by the host at the failover site are added to the replication buffer on the DataCore Server at the failover site until the production site is functional again.
To failback to the production side, the virtual disks at the production site are activated again.
If the DataCore Server at the production site is unavailable, operations will be performed from the destination server at the failover site. The destination virtual disk is currently in Standby state. The replication configuration is split (removed), but the virtual disk remains and is made available to the host and put in use at the failover site.
When the production site is functional again, the replication configuration can be re-established from the failover site to the production site and allowed to initialize (synchronize). After the virtual disks are initialized, the virtual disks at the production site can be activated again.
For detailed failover/failback instructions, see Replication Operations.
Replication operations can be performed from the Replication tab on the Virtual Disk Details page or from the panels. The Replication tab also provides specific information for the replication such as status, buffer size, time lag and transfer rate in order to monitor replications. See Virtual Disk Details and List for more information.
See Replication Operations for more information and instructions on performing replication operations. Replication operations can also be performed on virtual disk groups, see Virtual Disk Groups for more information.
A type of marker, called a checkpoint, can be used as triggers or actions
for configured tasks, or to update
existing snapshots on the destination server. Checkpoints are marked
(inserted) in the data stream from the source server and transmitted to
the destination server. When the checkpoint is received on the destination
server, the actions are performed.
Since the checkpoint is a marker in
a data transmission and latency does occur, the action will be delayed
in time.
One possible application would be to mark a checkpoint when you are confident that the source virtual disk is in a consistent state and define the action to update a snapshot on the destination.
See Replication Operations for instructions.
The replication buffer is used to store data changes which have occurred on the source virtual disk and are waiting to be transferred to the destination server. The buffer should be created on any replication server which will be transferring data changes. If the replication type is bidirectional, then both servers will need buffers.
When replications are created, unique folders are created in the replication buffer for each virtual disk that is being replicated. As data changes are made on the virtual disk, sets of files (with block-level writes, timestamp, and sequence information) will accumulate in the buffer until they are transferred to the destination.
When files are received at the destination, they are de-staged in-memory and the contents are written on the destination virtual disk. Replication files remain in the buffer on the source server until they are successfully destaged at the destination.
Also see System Health Thresholds to set a an available space threshold for the replication buffer.
The location and size
of the buffer will determine the function and speed with which the replication
process can perform data transfers. Creating a replication buffer using
the recommended guidelines is very important. The performance of the buffer
is critical to the correct functioning of replications. Refer to the Best
Practices Guide (FAQ 1348) on the DataCore Support Web page
for the recommended guidelines. If necessary, the buffer can be recreated
accordingly. See Replication Operations for
instructions on changing the buffer location.
