koya979 - Fotolia
There are numerous oversights and mistakes that IT professionals can make when crafting a VMware disaster recovery plan, or a plan for any virtualized environment. One common mistake is to select a tool or service that is simply too much for the business. This could be a tool or service that is too complex, with features and functionality that the business doesn't use or even need, or tools that are hard for the available IT staff to configure or use.
For example, a sophisticated tool with detailed workflow and automation capabilities, such as VMware Site Recovery Manager, might be unnecessarily excessive for an overworked IT staff in a relatively small shop. A more direct tool, like VMware vSphere Replication, or a cloud-based disaster recovery (DR) service, like VMware vCloud Air Disaster Recovery -- or even a third-party service, like Druva Phoenix -- would be better and easier to manage. In addition, features and functionality usually carry higher price tags; eliminating overly complex tools often saves money for the business.
Administrators can weed out tools that are too complicated, too difficult to use or too costly through conscientious evaluations and proof-of-principle projects during the assessment or design phase of a VMware DR plan.
Another common mistake includes selecting a tool that is inadequate for the organization's DR goals. For example, a tool or service that only guarantees recovery point objectives of 15 to 20 minutes isn't the best choice for a mission-critical VM workload that demands almost continuous replication. Similarly, a company that requires synchronous replication probably won't achieve acceptable results with distant replication sites due to excess latency or network bottlenecks. These kinds of mistakes occur when IT professionals fail to properly assess DR requirements or adequately evaluate a DR tool before they make a commitment.
A third problem area is inadequate consideration of the replication or DR site. For example, it's possible to back up or replicate workloads to local storage, but this poses a single point of failure for the business. If the local site is compromised, local DR content might be worthless or unrecoverable. Administrators typically leverage remote sites -- or cloud providers -- for resilience, but it's important to select a site for its security and location. You want a site that's close enough to minimize latency, but far enough to avoid local dangers, like flooding or fires.
Evaluate VMware DR tools
Now that you know the mistakes to avoid when developing and executing a DR plan, take a look at some of the VMware DR tools that can assist you in your recovery efforts.
Finally, a lack of testing often undermines DR plans. IT staff carefully craft DR plans, but fail to test those plans regularly and fail to adjust plans as business needs shift over time. The result is a recovery plan that's outdated and difficult -- and, in some cases, even impossible -- to implement when it's actually necessary. Once an admin has created and implemented a VMware DR plan, he should test the plan as frequently as possible and review it regularly to ensure he meets its changing needs. Modern virtualized DR tools and services usually support nondisruptive recovery testing, which allows IT staff to verify the ability to implement recovery quickly and effectively.
Disaster preparation and recovery planning remains an essential process for every business. Virtualized infrastructures, such as VMware vSphere, help simplify some aspects of the VMware DR plan, but IT professionals must still select the most suitable tools and implement an appropriate plan, and simultaneously avoid common limitations and pitfalls that plague enterprise DR efforts. There is no substitute for adequate DR attention and planning.
Understand cloud recovery service challenges
Achieve continuous availability in VMware vSphere 6.5
Dig Deeper on Disaster recovery, failover and high availability for virtual servers
Related Q&A from Stephen J. Bigelow
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading
ALM and SDLC both cover much of the same ground, such as development, testing and deployment. Where these lifecycle concepts differ is the scope of ... Continue Reading
Eliciting performance requirements from business end users necessitates a clearly defined scope and the right set of questions. Expert Mary Gorman ... Continue Reading