Replicating your infrastructure in a lab
Thursday, July 03, 2008 11:21 AM
Learn two ways to replicate your current environment for testing and evaluation of new server platforms.
A TechRepublic reader wrote in about balancing flexibility and risks in doing a test run of a newer Windows Server platform.
"My company is currently running Exchange 2003 on Windows Server 2003. We want to do a test run of Windows Server 2008/Exchange Server 2007 running together in a test environment.
I have few concerns, I do not want to add Windows Server 2008 to the domain and run into problems but I want flexibility to duplicate our current environment and run them simultaneously."
There are a number of different ways that the reader could accomplish his goals. In this posting, I'll talk about two different options the reader could take.
The physical route--Plan A
This is perhaps the most painful and most obvious option, but will provide the reader with the best comparative baseline analysis.
In short, our dear reader would need to replicate at least a chunk of his infrastructure in a lab environment. This lab would be physically separate from the primary network and each server would be individually reinstalled to match the production environment as closely as possible.
This is an extremely laborious option and introduces significant potential for error. For example, how likely is it that the full Exchange environment would be appropriately replicated? So, on to Plan B.
The physical or virtual route--Plan B
In this case, Plan B is a breeze compared to Plan A. Whereas Plan A would require massive staff time and would not guarantee an identical environment, Plan B corrects both of these deficiencies.
One of my favorite products of all time is PowerConvert from PlateSpin. PowerConvert promises (and delivers!) what they call "anywhere-to-anywhere conversion".
In short, PowerConvert automatically moves a server workload from any physical or virtual machine to any other physical or virtual machine. I've used PowerConvert to perform a number of physical-to-virtual migrations and the product has saved countless hours and perfectly replicated my servers to VMware ESX hosts. PowerConvert, however, isn't designed solely for physical-to-virtual migrations.
The reader in this scenario could in his lab deploy a bank of servers similarly configured to the production systems. Once replicated, the reader could run the lab on a separate network and perform his product evaluations in a safe environment complete with at least some level of performance analysis.
Sure, this isn't perfect since the lab network is still isolated and not accessible by all users, but it's still better than testing in the production environment.
If the reader isn't that concerned with performance baselines but is instead more concerned with how easily his environment can be migrated to Windows Server 2008 with Exchange Server 2007, a virtual environment--rather than a physical one--might be an ever better option.
Although Microsoft doesn't support Exchange Server 2007 on virtual machines, it's still an appropriate platform for testing and will provide the reader with an adequate environmental replica on which to work.
Summary
You probably gathered that the key solution to this problem lies in PowerConvert. Although I am a huge fan of the product, it's not cheap. Pricing starts at US$200 per workload converted.
So, if the reader converts just two servers--his Exchange 2003 server and his Windows Server 2003 domain controller--he's still looking at a minimum outlay of US$400 plus the cost of a lab server.
An ESX license is not essential, however. PowerConvert also supports Microsoft Virtual Server 2005 virtual hosts. I've used PowerConvert with both Virtual Server and ESX Server with excellent results.
There are also other products out there from companies such as Vizioncore. VMware also produces the VMware Converter. In any case, the reader will be able to safely test his migration plans.
Play video
» Blades for superior performance
There are currently no comments for this post.