This post on VMware vSphere Replication will be a two-part series.
In this first part, we will take a look at the following:
- What vSphere Replication
- How vSphere replication works
- Limitations of using vSphere Replication
- Difference between vSphere Replication and Backups
In the second part of this article, we’ll discuss the step by step process of how to set up vSphere Replication (VR) between two sites with vSAN.
VMware vSphere Replication(VR) exists since 2012; the latest version is 8.2 for vCenter/ESXi 6.7.
vSphere Replication can be used independently or included in the VMware Site Recovery Manager (SRM) for disaster recovery plans.
vSphere Replication license is included in vSphere Enterprise Plus, while SRM is an independent product and is a per VM or per CPU (as part of vCloud Suite Enterprise) license.
vSphere Replication protects your VMware Virtual Environment by replicating your VMware environment (site) to a secondary site. vSphere Replication uses network-based Replication; SRM uses storage array-based replication or network-based vSphere Replication.
For this article, we’ll only focus on vSphere Replication that uses replication network-based.
What is vSphere Replication?
VMware vSphere Replication works with vCenter providing hypervisor-based virtual machine replication and recovery with data protection at a lower cost per virtual machine.
vSphere Replication is an alternative to more expensive products, or that need third-party licenses for storage-based replication since it’s a network-based replication.
With vSphere Replication, customers can have a site-to-site replication to avoid failures or downtime on their Virtual Environments. It can also be used with VMware vSAN datastores as target Datastores for replication.
vSphere Replication protects virtual machines from failure between the following sites:
- Replication between sites, from a source site to a target site
- Within a single site from one cluster/datastore to another
- From multiple source sites to a shared remote target site
How does vSphere Replication work?
vSphere Replication Appliance is installed at source and destination (if replication is between sites) and creates host-based replication per VM between different sites.
vSphere Replication creates a copy of the virtual machine in the target using VR agents by sending changed blocks of the VMs between source and target.
This replication process occurs independent of the storage layer, differently from how SRM works when using array-based replication.
To create the initial virtual machine copy on the target, vSphere Replication make a full synchronization of the source virtual machine and its replica copy at the target.
The amount of sync that exists between source and target depends on the Recovery Point Objective (RPO) and the retention of instances from multiple points in time (MPIT) to keep that was selected in your Replication Settings.
All vSphere Replication configuration data is saved in an embedded database. You can also use an external Database on vSphere Replication implementation.
By default, three standard scenarios can be used by vSphere Replication.
Replication Between Two Sites
With this scenario, it is possible to replicate all Virtual Machines inside the site 1 to a different location site 2. One vSphere Replication Appliance needs to be installed and registered in each site for each vCenter.
Meaning, site 1 vSphere Replication Appliance needs to be registered with vCenter in site 1, then vSphere Replication Appliance in site 2 needs to be registered with vCenter in site 2.
Replication In a Single vCenter Server
With this scenario, it is possible to replicate virtual machines inside a vCenter.
In this scenario, there is only the need to implement one vSphere Replication Appliance in the vCenter.
Note: The replication target (Datastore) needs to be different from the source i.e, It is not possible to use the same source and target datastore for the replication.
Replication to a Shared Target Site
With this scenario, it is possible to replicate virtual machines to a shared target site. i.e, we can have more than one vCenter replicating to your target(s), or even replicate to more than one vCenter.
In this scenario, we need to implement a vSphere Replication Appliance in each vCenter (on source and target).
There are certain limitations for vSphere Replication Appliance & Virtual Machine Replication.
vSphere Replication Appliance Limitations
- Is only possible to deploy one vSphere Replication Appliance on each vCenter
- Each vSphere Replication Appliance can only replicate up to 2000 replications. Each VR Appliance can only manage 2000 VMs
- Each vSphere Replication Server can only manage 200 Virtual Machines in a maximum of 9 vSphere Replication Server per vSphere Replication Appliance
Note: Check VMware documentation regarding vSphere Appliance limits.
vSphere Replication – Virtual Machines Replication Limitations
- Replication of FT protected VMs is not supported
- VR can only replicate VMs that are powered on and cannot replicate powered off VMs
- VR cannot replicate Templates, Linked Clones, ISOs or any non-VM files
- VR can only replicate RDMs Virtual Disks that are set with Virtual mode
- Replication of MSCS clusters is not supported. VR cannot replicate disks in multi-writer mode
- Replication of vCenter vApps is not supported. It is only possible to replicate VMs inside the vApps
- VR supports up to 24 recovery points
- Replication of VMs with snapshots is supported; however, the snapshot tree is only available and created at the target site (with the possibility to restore using a snapshot restore point)
Does vSphere Replication use snapshots?
Yes, but only at the target side. After a first and full copy of the virtual machine to target, VR uses snapshots to save the recovery points, called Multiple Point In Time (MPIT).
Creating too many MPIT at your DR site can drop performance of your restore plan in case of disaster recovery. Since there are many snapshots in the source virtual machine, boot time can go from less a minute to several minutes because of snapshots.
Multiplying these values, let’s say 100 VMs, you have a considerable amount of time to boot your systems in your DR site because of many restore points in case of disaster recovery.
Retained instances always are converted into snapshots during a recovery.
Next is an example of replication with only 3 retained instances per day for 5 days (this is just for 2 days).
Always use retained instances wisely and don’t create more than the necessary for your disaster recovery plan and RPO/RTO SLAs.
vSphere Replication does not leave or create any snapshots at the virtual machine source.
How is replication different from backup?
One of the significant differences between a replication and a backup in a data protection environment is the two metrics recovery point objective (RPO) and recovery time objective (RTO). Depending on the times on each one, those are where replication or backup is the selected solution for your environment.
With backups, we have more data retention, and we can implement the backup rule 3-2-1 (At least 3 copies of your data, have backup data on 2 different devices, have at least 1 copy of the data offsite).
Even we can replicate to more than one location; it’s not possible to fully follow the 3-2-1 backup rule with replication. That is one of the reasons that replication is not a backup per se.
Backups involve creating a copy in a point-in-time of your data taken on a repeated cycle – hourly, daily, monthly, or weekly. By using Grandfather-father-son backup (GFS) rotation rule, you can retain your data as long as you wish while complying the local & federal laws as well.
For full data protection and data availability, using replication and backup together is the best option. However, of course, this has costs (particularly on Storage space).
VMware vSphere Backup & Replication with Vembu BDR Suite
Replication is for a disaster recovery scenario and Backup is more for data recovery scenario, but with the new features and new technologies, both now work together for a full disaster recovery plan.
For example: Let’s assume you have configured the replication in place and do not a backup system with the 3-2-1 rule.
In this case, if a system is corrupted or some files deleted from the Guest OS or even a malware attack like ransomware takes place, then this corrupted data is still replicated to your DR. With only replication plan in place, this will not help to recover your lost data.
As stated above, having just a replication in place will not protect your data from several failures that can happen. For a full data disaster recovery and business continuity, a replication implemented with a backup implementation protects your environment and data at all times and in different systems failures.
Today we can have both options by using just one product, like Vembu BDR Suite.
Vembu BDR Suite offers VMware vSphere Backup & Replication to ensure instant failover and business continuity at all times and also guarantees that your data is always recoverable even in case of a disaster, malware or deletion without the need to do a full failover.
Using Vembu BDR suite with VR also certifies that your systems with a backup plan follow the GFS rotation and 3-2-1 rule. All these reasons make Vembu BDR Suite the right combination to have complete protection of your data.
In this part one, we went through some of the features and how vSphere Replication works and the types of replication scenarios where we can use and implement replication.
Also, we discuss the benefits to use vSpshre Replication together with Vembu BDR Suite to have full protect data in all scenarios.
In the second part of this article regarding vSphere Replication, we will discuss how to implement vSphere Replication in a step by step.