vSphere Upgrade

After going through multiple iterations of a upgrade strategy, largely related at the vSphere Server deployment, I believe I’ve finally settled on the implementation.  A part of the reason for the design is that my company is potentially looking at significant growth over the upcoming two years and with the complexity of our virtualization environment after the additional of SRM I don’t want to have to rebuild anytime soon.

I’ve finally come upon what is probably the most complex solution I could for an environment my size but after significant time thinking it all sounds quite sane and simple.  Basically, whatever I do needs to be with existing hardware/software.  I don’t have the budget to purchase vCenter Heartbeat.  I also don’t want to have to rely on any of my companies other resources that I have in my DR recovery plans.  I have no rational argument for it so it’s more like an “I don’t want to share the sandbox” type thing.  The design has to be highly available, a solution is forth coming for data corruption as well.  I’m starting off with a 2 node Microsoft Failover Cluster for all databases and vCenter services.  I’m also researching the best of method of replicating data across the vCenter clusters in my production and DR data center, likely using native SQL Server tools.  I will be using 64 bit Windows 2008.  Because Site Recovery Manager is not currently supported on the vCenter server platform SRM will be installed as a virtual machine on Server 2008 32 bit.  While in the process of splitting up roles I’m going to go ahead and put Update Manager out as another virtual machine.  My physical servers are older IBM HS21 blades that currently only have 8 GB of memory.  This should be enough to support me for the short term and to free resources I either pull vCenter services out into a virtual machine or add more RAM.

Publicly I support VMware’s robustness more than most but I do not want to live through that day when the almost non-existent case of VMFS corruption takes not only some virtual machines but my vCenter database as well.  Again, lame rational I know but I have a really hard time going virtual for a vCenter database.

This is the first time I’ve been in a shop that’s grown large enough to not just toss all services on one box, this isn’t revolutionary but it’s my solution.