Free Trial
Request a demo
Menu
Request a demo

How to Run Disaster Recovery without Site Recovery Manager

by Virtiant Team, on May 4, 2018 3:55:00 PM

How To Run Disaster Recovery Without Site Recovery Manager (1)Read Time: 3.5 minutes

In this age of virtualization, VMware has been the catalyst that has enabled many organizations to make the leap into this new approach to infrastructure. Their innovative product suite has helped to simplify the process of transformation and removed barriers thus enabling many IT organizations to achieve a larger virtual footprint.

The goal for any organization's disaster recovery solution is that it should be easy to execute.  Setup and configuration of your DR shouldn’t be complicated and simple to accomplish. This is critical because, at the time of an IT disruption, you may not have application and your system expertise immediately available to assist with the disruption.

To meet this challenge in the age of virtualization, many organizations have opted to go with Site Recovery Manager (SRM) as their solution of choice. This seems like a logical decision given the fact that SRM is part of the VMWare suite of solutions and is inherently capable of handling replication and recovery of your virtual machines. However, there are some challenges with SRM that can leave gaps in your DR approach. In this article, we will explore SRM, its limitations, and look at some alternative approaches to resolving IT disruptions.

The Basics of SRM

Site Recovery Manager is disaster recovery software that is designed to help you automate failover of your virtual machines to a secondary site. In order to make use of SRM, it must be deployed in pairs. This means that you will have to deploy separate vCenter servers at each site for management purposes. You will also have to have SRM up and running at each site along with the database that stores information about your inventory and recovery plans. Replication is required and would be facilitated with either vSphere Replication or an Array-based approach.

While this deployment is fairly straightforward, the limitations start to become clear as your production infrastructure begins to grow. At a high level, you can quickly see that multiple touch points are required in order to get your secondary site up and running. Each site requires its own vCenter, SRM, database and replication processes so as your number of sites grows, so does the complexity of your DR solution grows exponentially. When choosing array-based replication, you will need to account for the same storage, software and associated licensing at all of your sites.

RM Database Requirements

As mentioned above, each site in your SRM DR solution will require its own database. This is used to store information about your VMware inventory in each site as well as the specifics of your disaster recovery plan. There are a number of database engine options to choose from such as Oracle, Microsoft SQL. It does require that you have a guest machine with its own OS and Database licensing at each site, if the embedded DB is not chosen.

Again, the limitations begin to make themselves evident. Before you can even begin building out your recovery plan, you will need a complete site inventory. In its most basic configuration, SRM will require a minimum of two databases. One located at your primary site and the other located at your recovery site. As you add sites, you will have to add databases that require a server, OS and related licensing. You also run the risk of database sprawl as your sites grow as each database is independent of the others. This means that anytime there are changes to your primary site, you will need to make those updates at each of your other sites resulting in a cumbersome maintenance process.

Replication Requirements

Many SRM solutions make use of vSphere replication as it is fully integrated within VMware. Since it is independent of the underlying technologies, such as OS, it can enforce protection at the VM level. This results in speed and efficiency of the replication process.

Array-Based Replication (ABR) is another popular replication method that makes use of a Storage Replication Adapter (SRA). By utilizing the SRA, data backup is facilitated with built in software that automatically copies data directly from one storage array in your production environment to a like storage array in your secondary site.

A common challenge with vSphere replication is that it requires s good understanding of your environment to ensure that replication occurs successfully for each individual virtual machine. When multiple sites begin to come into play, you will be forced to monitor multiple vSphere hosts in order to verify successful replication of individual VMs.

Likewise, ABR has limitations specifically with monitoring and the need for like storage at both locations. When SRM uses ABR, it is unable to monitor the replication, therefore you must closely monitor SRM to ensure no issues occur with replication of individual VMs. The need for like storage at your multiple sites can quickly drive up costs. This is easily apparent when upgrading storage arrays as you must pay close attention to ensure firmware levels remain inline and like storage is added propositionally. Otherwise, replication would become disabled.

A Better Way to Achieve Scalable and Flexible IT Resiliency with no Reliance on Your Primary Infrastructure and SRM

You can begin to see that SRM has some pretty specific pain points regardless of your configuration. The costs in labor hours to set up, configure, and maintain your SRM solution can be significant. Future growth and upgrades will negatively impact your recovery plans if they are not properly executed. Finally, you will need to ensure knowledgeable expertise remains in-house so that you can keep your production site in sync with your recovery sites and recover quickly in the case of an IT disruption.

At Virtiant, they have taken a different approach to meeting the needs of recovery. Their solution is completely stand-alone. This means that it has no reliance on your primary site, your storage or any of your backup applications in order to recover your virtual machines. Once you connect the Virtiant solution to your vCenter, you can quickly replicate your virtual machines making them available for quick spin up in the event of an IT disruption.

It is built on a software converged infrastructure consisting of commoditized x86, 64-bit hardware. This provides a scalable, yet cost-effective approach to growing your disaster recovery solutions.  When you recover guest machines from your Virtiant recovery solution, you can do so, along with all necessary services, in a matter of minutes. This allows you to continue to run your production environment while your key resources can troubleshoot the root cause of the disruption. No longer are your key experts consumed by recovery activities. Instead, they can remain focused on solving problems and growing your business.

Another benefit of the Virtiant is that they have taken care of the need to design and configure your recovery solution like you would have to do with SRM. Through the use of a user-friendly GUI interface and APIs, the Virtiant solution can replace countless of hours of man-time that was previously required to set up, configure and maintain your SRM recovery sites and plans.

Virtiant also offers a variety of deployment options that can be tailored to your IT organization’s individual needs. If you prefer the confidence and convenience of having your recovery solution onsite, then you can choose an on-premise deployment. If you prefer the ease and scalability of the cloud then Virtiant can offer a solution free from the concerns of hardware dependencies. They can easily handle hybrid solutions and multiple sites as well.

Contact Virtiant today and let them take care of your recovery when the IT hits the fan.

Topics:Disaster RecoveryProductSite Recovery ManagerTechnicalVirtualizationvmware backup solution

Comments