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:
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 UM 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!
Really? No takers but 60+ looks? Hmmm... Well, here's more food for thought... What if we've decided to go with a central/single SSO HA 2-node instance for our 4 vCenters, and we're NOT using an Apache software-based load balancer and are using a (hardware) NetScaler instead? There are so many manual steps in the below KB article it leaves my head somewhat fuzzy.
(See steps 6 and, far worse/complex, step 7 and its sub-steps... really??)
I'm one of those "lookers" and not "taking" because I'm in the same boat as you. I have three vCenter instances(2 being in the same geographic area; one in a different datacenter). We also install each vCenter instance with all the services on that local box, however all the databases reside on an external clustered SQL server. We also currently use linked mode and like you this upgrade with SSO is throwing us for a loop. I like your gameplan and I think it would work, however I'm curious why you don't want to use multisite because initially I thought this would be the way to go. Also, are you planning on creating the SSO database on a server different from the SSO server itself? That's the part I'm not sure how to approach; I was thinking of creating a standalone SSO server and point to an external SQL 2008 database(although I've read about all the scripts you have to run to create it). Also confusing are some of the details in the upgrade although I think its best to create a domain service account for the SSO server and I've read its best to remove linked mode before upgrading and then "re-link" after the upgrade chaos. I'll keep viewing this thread to see if anyone can point both of us in the right direction. I'm starting to think if the new features are worth all this hassle, especially now that 5.0 is stable for us in linked mode.
Jon, see my post here: http://communities.vmware.com/message/2191541#2191541
I don't want to use multisite because I don't see a need for its complexity relative to what we 'get' out of it in return. Multisite will involve multiple SQL databases for something like SSO which is really such a tiny/non-intensive/non-chatty database app to begin with, and the multiple servers that inherently go with them. Then they start talking about custom sync jobs being setup between each SSO database and it's like, 'What for? Why go through all that?'. I'm only speaking for US/my shop, because in some environments it might make a lot of sense. But for us personally? No... not even SSO in HA mode makes sense where 'return on effort' is concerned. We have the tools/infrastructure to afford ourselves a fairly high level of both site and local highly available SSO for our vCenters to point to over fairly high speed, redundant links between the SSO server and the Infrastructure/Web/vCenter servers that will point to it remotely (well, 3 remotely and 1 within same site as SSO box).
So we're gonna keep it nice and simple---going back to the whole 'KISS' acronym.
Yes, the SSO database will reside on a server other than the SSO server itself (in a MSCS/SQL cluster). The whole thing about creating the db users and options therein is reasonably well explained in the guides, but in the end despite its being somewhat convoluted, it seems quite workable on paper and so you take that and test it in a lab. After all, all you need is vCenter 5.1.0b installer which incl all components, and a SQL server you have sa/dbadmin rights to---no need for vCenter itself at all... then you get your steps wired tight where db rights/tables/creation etc are concerned.
Yes, do yourself a favor and don't trust the installer/upgrade to remove Linked Mode itself (which it claims it will do) but I'm not even going to test that in the lab and our steps will assume it CAN'T. We will re-link things ourselves, thank you very much. Linked mode can be goofy/weird enough to add that little factor in to what is far from a trivial upgrade. Yeah, we'll get that one ourselves.
So... test test test in a lab and figure out what might work best for you. I started that new thread after having yet more doubts about setting up SSO in anything more 'elaborate' than a single server (setup as 'primary node' of course so we can always opt to 'scale' at a later date should it become necessary).