Hello all. We're planning for the upgrade of our vSphere 4.1 U2 (vCenters and ESXi hosts all at 4.1 U2) and have done a bunch of reading including the Installation/Upgrade guides for vSphere 5.1, blogs here and there, etc. Still, we question our own planning, mainly where it comes to SSO---even if we think we finally have a winner. Current layout:
- 4 vCenters, 1 per physical site.
- Each vCenter has its own vCenter and Update Manager SQL databases/instance running on same box.
- vCenters are all in linked mode.
- Sites are all connected via redundant low latency, high bandwidth links, with slowest being an under utlized 155/OC3, else gigabit or higher.
- There are 54 ESXi hosts and 662 VMs currently spanning all vCenters for a 12:1 ratio. All healthy/happy overall, no performance issues/bottlenecks to speak of. Really not that big of an environment even with projected growth doubling that amount over the next 3 years. I'd call us 'medium' sized at most, agreed?
Long story short, we've done a lot of reading/research and our planned upgrade sequence is outlined as follows:
1. Upgrade vCenter 4.1 (and related components) to v5.1.0a
- 2. Upgrade ESXi 4.1 hosts to ESXi 5.1 using Update Manager 5.1 (There are interactive and scripting options for upgrading ESXi as well but UM baseline remediation is recommended by VMware primarily and seems fine for us given we don't have all that many hosts to upgrade)
- 3. Upgrade guest VM Tools and Hardware versions using Update Manager 5.1
'Easy' enough but of course that first section introduces several new variables/design considerations involving SSO, the Inventory Service, and the Web Client service.
At first, we were considering the SSO 'Multisite' model but long story short we've ditched that idea. Instead, we're going to install a pair of SSO servers into HA/cluster mode (primary followed by secondary) in 1 of the 4 sites and have all 4 vCenters point to it given our relatively high speed WAN infrastructure. 'Hub and Spoke' SSO, if you will, with the 2 servers behind a load balancer. That takes care of SSO overall and 'keeps it simple', with a single SSO database to administer and maintain.
For the Web Client server and Inventory pieces, we plan on building a single new VM into each site (within existing HA/DRS clusters) and installing those 2 components onto each server for each site's vCenter to point to. Those components themselves, at installation time, would in turn point to the SSO HA singular instance. (Sure, we could install both services onto the existing vCenter/SQL servers in each site but wanted to separate/distributed the services a bit to potentially allow for better overall performance and stay away from 'all eggs in one basket' etc).
Finally, with SSO/Inventory/Web services all set, we would upgrade vCenter and UM in-place on each server where they currently reside. They are already VMs so we have full backups etc including file level as well as entire VM level. vCenter upgrade installations in all sites, when prompted, would point to the central SSO service/instance but would use their own site's Inventory/Web services. After all 4 vCenter upgrades are completed, we would then re-enable Linked Mode via the web client, which we would plan to use exclusively (to 'wean' ourselves off the C+ client we've all come to know and love over the years).
Even with high speed, redundant links, I realize that one perceived 'caveat' might be a bit of a delay where any SSO lookups for authentication/rights to vCenter will be concerned, but I would say that will likely be minimal and the trade-off in simplicity of the SSO design/layout will be well worth it.
Feedback/recommendations welcome and appreciated. SSO along with the Inventory and Web services is a game-changer in the upgrade cycle and we think we have a good fit for us, but it's always good to solicit opinions from the field as we work to build out our lab and test this approach. Thanks!