Problem solve Get help with specific problems with your technologies, process and projects.

Five things to consider when using virtualized servers for disaster recovery

Disaster recovery isn't the No. 1 reason enterprises virtualize their servers, but it's one of the major benefits. Here are some important things you should know about using server virtualization for DR.

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, 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.

Dig Deeper on Backup for virtual servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.