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.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
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.