Disaster recovery (DR), testing and development environments have historically been closely linked whether or not anyone liked to admit it. Organizations would construct test and development environments and then use them for DR purposes if needed; or, they would quietly repurpose computer gear purchased using DR funds for testing and development. However the trick is getting both of these distinct but separate business processes to share this same environment without creating new levels of complexity.
Every organization plays this game of mixing its test, dev, and DR environments from time to time at some level. An organization may have a budget for testing and development but limited or no funds for a DR environment so the test and dev environment doubles as a DR environment when the situation warrants. Or conversely the organization has monies for servers, storage and networking gear for a DR environment which it invariably ends up using to test and develop its applications some or all of the time.
While this sounds like a practical use of equipment and funds, it works marginally well at best. Any time a test and dev environment has to be used for DR, backups of the test and dev environment ideally should first occur and configuration settings saved. Whether or not these tasks happen depends on the urgency of the DR event (exercise or real) and how organized the administrators of the test and dev environment are. Too often, backups of test and dev servers never occur and configuration settings are not preserved resulting in a multitude of problems when it comes time to reconstruct the test and dev environment.
Some would argue that the advent of server virtualization fixes this historical problem. This is partially true. In the case of DR, server virtualization makes it easier to recover production applications at a DR site by using VMware features like vMotion. Recoveries of production applications can occur on the same physical server that host test and development virtual machines (VMs) without impacting pre-existing test and dev VMs.
However for this scenario to succeed, vMotion makes at least three assumptions that do not always hold true:
- The production applications all run on VMs
- The source and target physical servers have access to the same networked storage
- A high speed network exists
So while features found in server virtualization address some of these historical problems associated with mixing test and dev with DR, it still is only a partial solution.
Organizations need to recognize that test/dev and DR environments are inseparably linked. However they must treat and manage them as distinct processes while still sharing the same underlying physical resources for the simple reason that organizations have inadequate funds to justify expenditures on both types of environments. To accomplish this, they must deliver on the distinct requirements of each process while avoiding the complexity that can result when sharing the same underlying physical infrastructure.
Server virtualization is certainly a part of this equation but it is only a part. It also needs data protection and DR software such as what InMage Systems offers. InMage directly addresses an organization’s DR problems but it also indirectly solves this issue of helping companies combine their test and development environments within their DR environment without compromising the integrity or reliability of either one.
It does so in the following two key ways:
- Does physical to virtual (P2V) replication. Organizations can keep their existing production applications on physical machines but recover them in a virtualized server environment – be it a DR or test/dev environment. Using InMage’s P2V replication capabilities, organizations can recover physical machines on VMs while enabling test, development and DR VMs to peacefully co-exist.
- Eliminates the need for high-bandwidth network connections and shared storage. These are two distinct drawbacks of solutions like vMotion. While these two issues may be lesser factors when recovering applications locally, these requirements can become cost prohibitive when doing DR remotely. InMage alleviates these concerns by using asynchronous replication which includes options to throttle how much data is sent and when it is sent. In this fashion, organizations can recover applications locally or remotely without incurring huge additional network bandwidth or even storage costs.
InMage also creates new avenues to help in the testing and development of applications. Since InMage has access to any copy of production data at any time, it can take snapshots of this data and present it to test and dev VMs with zero impact to production applications.
Once this data is presented, organizations have a lot of flexibility in terms of what they can do with the copies. They can be virtual copies for fast creation, they can be presented to physical servers if higher performance is needed. Organizations can even create multiple copies of the same snapshot. They can then modify this copy, throw it away, and re-create the same exact starting point as many times for optional uses.
For example, organization might use these copies of production data as source data for testing, simulate software upgrades or patches on production servers or even test drive how the application would run in a virtualized environment on other types of server hardware.
It also gives DBAs new flexibility for getting access to copies of data for testing. Normally they have to contact the backup or storage teams for copies of production data and coordinate with them to get this data. InMage eliminates this requirement as they can obtain these copies of data without directly involving either of these two teams each time.
Organizations have an ongoing need to successfully complete application testing and development while also delivering reliable and dependable DR solutions sharing the same infrastructure. Only now is it possible for these environments to successfully co-exist and deliver on these requirements but this does not happen by accident. It is only by using server virtualization in conjunction with technologies like InMage that companies can successfully deliver on these objectives without creating new levels of cost and complexity