By: vExpert Gregg Robertson
A Business Continuity and Disaster Recovery (BC/DR) iplan s something every business, no matter how big or small, should be thinking about and implementing. Whilst preparing for my VCAP-DCD and even for my VCDX attempt, BC/DR was a very important topic, as two of the infrastructure qualities of AMPRS (Availability, Manageability, Performance, Recoverability and Security) are availability and recoverability.
In my daily role as a consultant, BC/DR is a core component for every virtualization design, no matter if it is data center virtualization, end-user computing or hybrid cloud. In this four-part blog series, I am going to cover four ways BC/DR can help your small/midsized business (SMB) through the usage of solutions available to you. In this third blog, I will cover the benefits of automated software-based replication built in as a feature in VMware vSphere.
Automated Software-Based Replication
With the release of VMware vSphere 5.1, came the availability of vSphere Replication (VR), which was previously only available in VMware Site Recovery Manager 5.0. VR is a software-based replication engine that works at the host level rather than the array level. Identical hardware is not required between sites, and in fact, customers can run their VMs on any type of storage they choose at their site – even local storage on the vSphere hosts, and VR will still work. It provides simple and cost-efficient replication of applications to a failover site. VR is a component delivered with vSphere Essentials Plus and above editions, and also comes bundled with vCenter Site Recovery Manager. This offers protection and simple recoverability to the vast majority of VMware customers, without additional cost.
vSphere Replication allows single site replication and protection. This is perfect for SMB organizations that may have a local campus, with a single cluster spanning two floors of a building where recoverability is within a proximal datacenter. If a floor loses power and the primary hosts and disks are unreachable, the administrator could simply point to the replica VMDK within VR and choose to recover it. The administrator deploys a single VR Appliance to act as both the replication manager and also the recipient and distributor of changed blocks. Then the admin configures a VM and one or more of its VMDK files to be replicated, giving the local VR Appliance as the target, and selecting a different datastore for the replica of the VM. The vSphere Replication Agent on the appropriate vSphere 5.x host that holds the running VM then starts tracking changes to disk as they are being written, and in accordance with the configured RPO sends the changed blocks to the VR Appliance. The VR Appliance passes the changed block bundle via NFC to a host to write the blocks to the replica VMDK.
VR is also a perfect fit for IT managers looking to protect virtual machines in ROBO scenarios.
In this model, hosts at remote sites are not managed by distributed vCenter Server instances, but from a central ‘head office’ datacenter. A single vCenter Server instance manages both local vSphere instances and remote clusters or hosts.
VMs from multiple remote sites need to be replicated to the central office in this scenario. At the remote sites, as long as the hosts are vSphere 5.x, there is no change necessary to be implemented. They will have the necessary vSphere Replication built in to the kernel.
At the head office datacenter, at least one vSphere Replication Appliance must be deployed to manage the replication of all the VMs (both remote and local targets). This single appliance will usually be sufficient to handle the incoming replications, but sometimes customers will want to isolate replication traffic by source, or will need to scale up the number of recipient servers to handle more incoming replications.
In that case, administrators can deploy more VR Servers (Not the full VR Appliance – there is only one per vCenter) to handle isolating the incoming replication traffic or to adjust for scale.
Each VR Server can be used as a dedicated target for one or more remote sites.
Within the main datacenter, the VR Servers will pass the incoming replication data to the recovery cluster via Network File Copy for committing to local replica copies of the remote VMs.