HC3 Replication for Local or Remote Disaster Recovery
All HyperCore software systems include a free, built-in feature for system-to-system replication at the per-VM level. System-to-system replication is designed to run continuously and to transmit changes to a secondary system as quickly as possible, using the snapshot functionality as the base for VM changes.
This integrated replication feature protects against additional disaster scenarios such as site and regional disasters which may impact an entire HC3 system, affecting local recovery options. Some key features include:
Manual snapshots or automated snapshot schedules as quickly as 5 mins can be utilized for VM replication.
Snapshots and replication are intelligent and efficient, tracking unique and shared blocks where shared blocks are sent once for multiple snapshots, leaving unique blocks to be sent as they occur.
Replication uses compression for efficiency over a secure connection authenticated with the remote HC3 system web interface credentials and a unique key exchange.
Easy disaster recovery testing and failback during disaster recovery scenarios using the nearly instant VM cloning feature based on the stored snapshot instances.
HC3 replication leverages change tracking using the VM snapshots. This limits the impact of replication on the system by reducing the I/O required to read and transmit changes. This also eliminates the need to “brute force” read and compare data to determine which blocks have changed since the last replication cycle.
In addition, compression functionality is built-in to efficiently determine the data changes between the most recent snapshot and the snapshot that represents the last completed replication point and transmits only the changes to the remote cluster. It is also possible to set independent snapshot retention schedules between the production and remote systems to help manage system capacity.
For VMs that were created from snapshots or via cloning that share common data blocks (such as multiple VMs created from a “template” and cloned), HC3 is intelligent enough to transmit those common blocks across the network to the remote system a single time which can greatly reduce the bandwidth required for the initial replication of a new VM created from an already replicated template.
In the same sense, during failback to a source system after a disaster scenario, the HC3 system is intelligent enough to determine the blocks that have changed from the time the original production VM went down to the current running VM image on the target disaster recovery system. Only data blocks that have changed since the initial failover will be replicated back to get the production VM up to speed and back into service.