This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
4. - Be prepared when big trouble comes knocking: Read more in this section
- Creating a VMware disaster recovery plan
- Improving business continuity via a virtual disaster recovery strategy
- Building a remote VMware disaster recovery site
Explore other sections in this guide:
- 1. - The best approaches for virtual machine backup and virtual recovery
- 2. - Using snapshots to defend and resurrect your virtual machines
- 3. - Switch virtual recovery efforts to autopilot with vCenter Site Recovery Manager
Virtualization offers distinct disaster recovery advantages, but consolidating your servers into a vSphere infrastructure can still leave your organization vulnerable, if you do not maintain a remote VMware disaster recovery site.
More on VMware disaster recovery
VMware disaster recovery strategies for small environments
VMware vSphere Replication breaks DR barriers
Top 10 websites for VMware DR tools
Every enterprise needs a disaster recovery (DR) plan, but studies show that less than 50% of companies have one. While virtualization makes it easy to migrate workloads between physical servers, the need for a DR plan at a secondary data center is just as necessary with a virtual infrastructure as it is with a physical infrastructure.
Fortunately, virtualization disaster recovery is getting easier. Let’s find out what you need to build a remote VMware disaster recovery site.
Why virtualization disaster recovery is easier than ever
Server virtualization eases DR for the following reasons:
- Server operating systems and applications are no longer tied to specific physical server hardware.
- Virtual machines (VMs) are portable, and you can run them on any vSphere server.
- You can clone, take snapshots and move VMs with virtualization features.
- Advanced features, like VMware High Availability and Distributed Resource Scheduler, can help organizations recover from disasters quicker as well as prevent slow performance and downtime because of resource capacity.
Since companies started implementing virtualization, a number of features have made disaster recovery easier. For example, change block tracking in the vStorage APIs for Data Protection allows backup disaster recovery tools to easily identify the blocks of the VM disk file that have changed. The changed blocks can then be replicated over a wide area network to a remote VMware disaster recovery site. In addition, the availability of software-based DR solutions, instead of hardware tools, have made VM replication more affordable for organizations of all sizes.
Planning for a remote VMware disaster recovery site
Before you build a remote VMware disaster recovery site, there are a number of things to consider. After all, proper DR planning will prevent you from wasting a lot of money on equipment and designs that don’t meet your organization’s needs.
Let’s take a look at some considerations when planning a remote VMware disaster recovery site:
- Inventory your current infrastructure. You can’t begin to replicate the primary data center if you aren’t absolutely sure of its contents. A couple of good, free documentation tools for vSphere infrastructures include RVTools and Veeam Inc. Reporter (free edition).
- Learn your applications and dependencies. With a basic knowledge of how your applications work and their dependencies, you’ll understand what the applications need to survive a disaster. If your DR plan only fails over some of your servers, applications that are dependent on multiple servers may not work. Consider any potential differences in storage or network architecture, and be sure that applications will work as expected, when they fail over to the backup location, in spite of those differences.
- Keep your clients in mind. Just because you get all of your servers and apps up and running doesn’t mean that the end users can use them. How will you replace their desktop and applications? How will they gain remote access?
- Prioritize applications. If you can’t provide a remote VMware disaster recovery site with capacity identical to your production data center, what are you priorities? Which applications need to be recovered first?
- Establish your recovery point objective (RPO) and recovery time objective (RTO).
- How soon does your company need a VM (and its application) back online. An RTO of 24 hours means that the business could function without the VM for 24 hours.
- How much data loss can you accept? If the data is replicated hourly to the secondary data center and a disaster occurs, you could lose up to 59 minutes and 59 seconds of data. If that is acceptable without seriously affecting the business, then your RPO could be one hour.
- Set your budget. Determine how much money your company is willing to spend on a disaster recovery site (that you will hopefully never use). If the company asks how much it will cost, you may have to create a list of required resources to find out and scale it down, if needed.
Building your remote VMware disaster recovery site
Once you define your disaster recovery needs and budget, you can build a plan. Keep in mind that every company’s disaster site will be different.
As an example, let’s consider a data center that has 10 critical VMs. These VMs have an RTO of four hours and an RPO of one hour. Here is my suggested list of steps on how to build a remote VMware disaster recovery site:
- Pick a data center location. Where is the location of the remote disaster recovery site? How close is it to the primary site? Will it have a high-speed bandwidth connection with the primary site? Does it fit your budget? In my opinion, an affordable high-speed bandwidth connection with the primary data center is one of the most crucial considerations for selecting a disaster recovery site. While selecting a secondary data center halfway around the world may reduce the danger of a single event affecting both locations, it is not useful if you can't keep your data in sync. Most companies have to find a middle ground between a data center that is geographically separate, but not so far away that the data transfer speed suffers and you can’t travel to both in a reasonable amount of time.
- Obtain, install and prepare hardware. Thanks to the portability of virtual machines, you don’t need identical hardware mappings between primary and secondary sites anymore. While you can get away with a higher consolidation ratio at a disaster recovery site, I wouldn’t recommend it unless you are OK with decreased performance from your applications. Don’t try to get away with using old hardware. Remember, you are trying to put as many VMs on those hosts as possible. I recommend using a solid KVM-over-IP system for the disaster recovery servers, because you don’t want to travel to the remote VMware disaster recovery site if something goes wrong.
- Install and configure vSphere. Installing ESXi on your disaster recovery hosts won’t take long. (If you have more than 25 hosts, you may want to use Auto Deploy.) If affordable, I would recommend having the same licenses and vCenter Server at the secondary site that you do at the primary site. You’ll want to test replicated VMs and the failover process periodically.
- Select a tool. Today, many tools include replication of VM backups. These products may be an affordable option for transferring VMs to the remote VMware disaster recovery site. Examples of such tools include Veeam Backup & Replication, PHD Virtual Technologies’ Virtual Backupand AppAssure Software Inc.’s Backup. Alternatively, you may prefer a disaster recovery replication tool that is built into your storage area network or that loads directly on your ESXi hosts (e.g., VMware Site Recovery Manager and Zerto Virtual Replication). These tools may provide lower RTO and RPO.
- Use replication. The initial replication of your data is going to be the largest transfer of data. Subsequent replications of the changed blocks will be much smaller, but the size will vary based on the amount of data that is changed by your applications. The amount of data replicated will also vary, based on the replication intervals (determined by the RPO).
The hardware in the primary data center is likely to be different from the hardware used in a disaster recovery site. But if they are both run vSphere, you can still manage both data centers with the same tools, such as the vSphere Client.
Consider the cloud for disaster recovery
One of the newest options a remote disaster recovery site is the cloud. More specifically, Disaster Recovery as a Service is made possible by the new vSphere Replication in Site Recovery Manager (SRM) 5. With these types of services, you likely don’t have to buy SRM or remote site hardware. You don’t even need to lease rack space for the remote VMware disaster recovery site. You can simply subscribe to the service. Whether you are interested in using cloud backup services today or not, you should ensure that your backup software will support cloud-based backups in the future. An example of a company offering this service is Hosting.com.
Building a remote VMware disaster recovery site isn’t easy. Your budget and RPO/RTO requirements will determine the scope of the project. Fortunately, just about all of the disaster recovery replication options have trials, so you can see if they meet your needs.