Learn More About Our Business Solutions for:
Legal Services
Howard Rice
Sheppard Mullin
Financial Services
Heritage Bank
Los Angeles Federal Credit Union
Healthcare
Novant Health
Government
New Mexico AODA
Education
Utah State University
Cloud Computing
-
Featured Articles
7 Considerations When Choosing a Replication Software Product (Part 2 of 2)
Tuesday, July 27, 2010
Last week I took a look at the first three...
7 Considerations When Choosing a Replication Software Product (Part 1 of 2)
Monday, July 19, 2010
Replication is becoming an ever more important component in the...
What a Windows Recovery Solution Should Look Like
Monday, June 7, 2010
One of the principle struggles within organizations in the first...
- Solutions Briefs
-
White Papers
-
A Cost-Effective Integrated Solution for Backup and Disaster Recovery
-
A Primer on Next Generation Data Protection Technologies for Healthcare
-
The InMage Analyzer: Gauging Disaster Recovery Requirements
-
Understanding Continuous Data Protection
-
Protecting and Recovering Virtual Server Environments
-
How to Protect and Recover VMware Environments
-
The 5 Critical Planning Steps For An Effective DR Plan
-
How to Leverage Disk to Improve Recovery Plans
-
Using InMage To Address Local Backup Requirements
-
Windows Recovery Solutions For Today's Environments
-
How To Evaluate The ROI Of Your Data Protection Infrastructure
-
InMage: A Compelling Alternative to Deduplicating Virtual Tape Libraries
-
A Cost-Effective Integrated Solution for Backup and Disaster Recovery
- Case Studies
-
News
Aug 30, 2010Aug 24, 2010Aug 12, 2010
Creating Test, Dev and DR Environments that can Co-Exist without the Complexity
Wednesday, November 25, 2009
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
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.
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