Tip

Five things to consider when using virtualized servers for disaster recovery

Disaster recovery (DR) isn't the No. 1 reason enterprises decide to virtualize their servers, but it is one of the major benefits. Running your applications on virtualized servers puts all your applications, data and configuration,

Requires Free Membership to View

in one neat package that's easy to move around as needed. A properly virtualized server can be easily cloned onto another physical server if its original server fails.

Of course, like everything else about virtualization, the benefits come at a price. It's not a steep price, and increasingly, companies are willing to pay it. However, there are still some things, good and bad, you should know about using server virtualization for DR.

Virtualized DR is fast

One of the best things about virtualized servers is how quickly you can bring your whole environment up on a server across the data center or across the country. With a properly prepared installation, DR takes approximately as long as it does to transfer the files -- if that.

One of the best things about virtualized servers is how quickly you can bring your whole environment up on a server across the data center or across the country.
,
But the key is a properly prepared installation. Cloning over the software, data and configuration is only part of the process. The recovered server needs to be able to run in its new physical environment. Unless you tell it otherwise, the virtual server you've just moved assumes that nothing has changed; that it still has the same connectivity as the same network addresses, same amount of memory, disk organization, etc. that it did before. In fact, the more similar the DR site's server is to the original physical server, the faster DR is.

It's (mostly) painless

If you have configured the virtual server and the physical server properly, the process of bringing up the virtual server to its new home is pretty much automatic.

However, there's a tradeoff here between ease and protection. The easiest, most painless target for the virtual server is the next blade in the rack because the network parameters are almost identical. On the other hand, the most protection comes from using a physical server in a remote data center, the more remote the better. But, that comes at the expense of having to do more configuration to get the virtual server back up. How you choose to balance ease and speed of recovery with protection is your decision, but it's best to make it consciously.

It doesn't protect the balance of the system

Virtualized servers are a great basis for DR, but they're only a basis. Moving a virtual server to a new physical server lets you recover the server, but it doesn't do anything for the storage or any of the other components in the system. Unless they're protected by other means, you're still out of luck.

Storage is a particularly thorny issue in DR. If the problem doesn't involve the storage system, you can continue to use the data in its original system. If the storage system is also involved, you're going to have to move it. While that's easy, you need to have a physical storage system capable of accepting it. Ideally, this means a storage system that's identical to the one on the original host.

Standardization is a good thing

You should establish a standard base configuration for your virtual servers -- same version of the operating system, same system configuration, etc. and as much as possible you should stick to that configuration.

It's also a good idea to standardize the hardware configuration, too. If you're running the same model physical servers with the same storage array, same host bus adapters (HBAs), etc. on all your physical servers, you will have a lot fewer problems

Obviously, you're not always going to be able to keep the same configuration. In fact, it's fairly unlikely that all the physical servers in your data center will be running the same base configuration. But by starting from the same configuration on all of them, it is easier to document changes and to administer all of them.

This is especially important in a DR situation when you trying to bring a server or servers up under pressure. The fewer variables you have to deal with the easier the job is. Not standardizing doesn't make virtualization impossible, but you lose some of the benefits if you don't. This is especially true of a data center with a lot of systems. Less standardization means more work for the administrators and cuts down on the number of servers/storage systems an administrator can handle.

At the physical layer, redundancy is the key to high-availability virtual servers. Avoid single points of failure with dual HBAs, dual data links (Fibre Channel, iSCSI, etc.), proper storage redundancy and other precautions. Needless to say, this goes for your DR target as well as your virtual server's original home.

Testing is easy -- So test it!

The good news about virtualized DR is that it's easy to test. The bad news is you've still got to test your implementation. Ideally, testing should involve actually bringing up the server on another physical machine and making sure that everything works in the real world. In other words, you should be able to cut over from the original virtual server to the new one in a production environment with minimal disruption to your users. At the very least, you should be able to test all aspects of the cloned virtual server, including connectivity.

About the author: Rick Cook specializes in writing about issues related to storage and storage management.


This was first published in May 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.