Replication Overview
HyperFlex 2.5 introduced new data protection features, including snapshot-based VM-level replication between two HyperFlex clusters. Replication can be used to migrate or recover a single VM in the secondary HX cluster, coordinate or recover groups of VMs, or recover all VMs as part of a disaster recovery scenario. In order to start using replication, you must install two HyperFlex clusters and ensure network connectivity between them. The clusters can be extended clusters, and it is possible to replicate between hybrid and all flash clusters. The clusters are allowed to use self-encrypting disks or standard disks in either location, both of them, or neither of them; there is no restriction in that respect. To avoid complications with duplicate VM IDs, recommended practice dictates that the two replicating HyperFlex clusters be managed by two different VMware vCenter servers. Figure 6-1 shows the logical network topology used for replication.
)
Figure 6-1 Replication Logical Network Topology
Port Requirements for Replication
The firewall ports listed in Table 6-1 need to be open when configuring native HX asynchronous cluster-to-cluster replication. If any of these ports are not open, the storage controller virtual machines (SCVMs) cannot communicate using the specific service for which the ports are closed. Closed ports also prevent the proper functionality of the replication feature.
Table 6-1 Firewall Ports Required to Be Open for Replication
Port Number |
Service/Protocol |
Source |
Port Destinations |
Essential Information |
9338 |
Data Services Manager |
Each CVM node |
Each CVM |
Bidirectional, including cluster management IP addresses |
3049 |
Replication for CVM/TCP |
Each CVM node |
Each CVM |
Bidirectional, including cluster management IP addresses |
4049 |
Cluster Map/TCP |
Each CVM node |
Each CVM node |
Bidirectional, including cluster management IP addresses |
4059 |
NR NFS/TCP |
Each CVM node |
Each CVM node |
Bidirectional, including cluster management IP addresses |
9098 |
Replication Service |
Each CVM node |
Each CVM node |
Bidirectional, including cluster management IP addresses |
8889 |
NR Master for Coordination/TCP |
Each CVM node |
Each CVM node |
Bidirectional, including cluster management IP addresses |
9350 |
Hypervisor Service/TCP |
Each CVM node |
Each CVM node |
Bidirectional, including cluster management IP addresses |
Replication Considerations
When applying replication in HyperFlex, consider the following:
Administrator: All replication and recovery tasks, excluding monitoring, can only be performed with administrator privileges on the local cluster. For tasks involving a remote cluster, both the local and remote user must have administrator privileges and should be configured with the vCenter SSO on their respective clusters.
Storage space: Ensure that there is sufficient space on the remote cluster to support the replication schedule. The protected virtual machines are replicated (copied) to the remote cluster at every scheduled interval. Although storage capacity methods (deduplication and compression) are applied, each replicated virtual machine will consume some storage space.
Not having sufficient storage space on the remote cluster can cause the remote cluster to reach capacity usage maximums. If there are errors reporting out-of-space errors, all replication schedules must be paused until the space is appropriately adjusted on the HX cluster. Always ensure that the cluster capacity consumption is below the space utilization warning threshold.
Supported clusters: Replication is supported between the following HyperFlex clusters:
1:1 replication between HX clusters running under fabric interconnects.
1:1 replication between all flash and hybrid HX cluster running under fabric interconnects.
1:1 replication between a 3-node or 4-node HX Edge cluster and another 3-node or 4-node HX edge cluster.
1:1 replication between all flash 3-node and 4-node edge and hybrid 3-node and 4-node HX edge clusters.
1:1 replication between a 3-node or 4-node HX edge cluster and an HX cluster running under fabric interconnects.
Recovery Considerations
When configuring recovery in HyperFlex, consider the following:
Rebooting nodes: Do not reboot any nodes in an HX cluster during any restore, replication, or recovery operation.
Thin provision: Protected virtual machines are recovered with thin provisioned disks, regardless of how disks were specified in the originally protected virtual machine.
Protection group limitations: The maximum number of VMs allowed in a protection group is 32. Do not add VMs with ISOs or floppies to protection groups.
Non-HX datastores: If you have protected a VM with storage on a non-HX data-store, periodic replication will fail. You can either unprotect this VM or remove its non-HX storage. Do not move protected VMs from HX datastores to non-HX data-stores. If a VM is moved to a non-HX datastore through storage vMotion, unprotect the VM and then reapply the protection.
Protection and recovery of virtual machines with snapshots: There are several options:
VM with no snapshots: When replication is enabled, the entire content of the VM is replicated.
VM with VMware Redo-log snapshots: When replication is enabled, the entire content, including the snapshot data, is replicated. When a VM with redo-log snapshots is recovered, all previous snapshots are preserved.
VM with HyperFlex snapshots: When replication is enabled, only the latest data is replicated, and the snapshot data is not replicated. When the VM is recovered, previous snapshots are not preserved.
Data protection and disaster recovery (DR) snapshots: These snapshots are stored on the same datastore as the protected VMs. Manual deletion of these snapshots is not supported. Deleting the snapshot directories would compromise HX data protection and disaster recovery.