We are planning an upgrade of our four have 4 vCenter 4.1 U2 hosts to vCenter 5.1.0b
SSO is clearly the piece that is new and relatively complex design-considerations-wise. There's lots of into out there, and much of it suggests that there's not a lot of deep understanding as to how to install it beyond 'BASIC/SIMPLE' mode.
At first we were thinking multi-site, then we were thinking single site with SSO HA.
NOW I'm thinking single site 'primary node' / single SSO server and nothing more. Here's why this could work out fine for us, and keep things nice and simple with this new funky addition to any vSphere 5.1+ deployment.
We have 4 vCenters as noted. The vCenters are each in separate cites, all within the U.S. All WAN links between sites are redundant and run at gigabit speed (lucky us I guess). We also have SRM capability (or offsite DR otherwise) between the site where the ONE sso server would be installed and the 'recovery' site. So not only do we have high speed, redundant links between the would-be single SSO server, but we also have SRM for relatively fast recovery of the SSO server (IP and DNS would not be an issue; it would come up the same 'everything' in the recovery site). What about local availability/uptime of the VM running SSO? It would leverage a multi-ESXi host HA vsphere cluster so downtime in that scenario would be minimal.
It's not for everybody of course, as 'your mileage may vary' and everyone has different environments, etc. but FOR US, this way we'd have no load balancer to factor in, and eliminate complexities associated with multisite and/or HA SSO deployments. For something as 'new' as SSO, I'm thinking I'd rather get rid of anything that SSO itself might depend upon (load balancers and their configs, multi databases in a multi site scenario, and so on).
We can leverage a combination of both vSphere clustering and SRM investments to provide both local and site level fault tolerance for SSO-based authentication into vCenter----and use only a single SSO server for simplicity/ease overall while meeting our upgrade objective and not really sacrificing anything that I can see in the process.
Further thoughts/confirmation/debate appreciated, and we still may go with an SSO pair in HA mode behind a load balancer (Netscaler if any) since nothing is written in stone yet, so if anyone has feedback on that specifically it would also be appreciated.
Multisite options are best explained here
Having set that, I would have to agree that the complex the set up is, the more issues if something actually goes down.
In terms of deployment, as SRM is already present for a DR scenerio, the best option would be to go in for a basic/simple primary and DR option.
For removing the single point of failure - SSO, SRM can be used in tandem, as the manual SSO backup process limitations (no clone, block level backup restore tending to break SSO, manually restoring backed up SSO config etc "http://kb.vmware.com/kb/2034928") can be counter intuitive.
In your scenerio, even if you have SSO HA Multisite, the next single point of failure would again be the VC machine itself, and that, with added complexity of an HA multisite setup.
Let me know your thoughts
Thanks for the fine blog/link. After having read through it, and based on other lab/setup tests I've done over the past week, I'm convinced that, for us, a single SSO server installed as primary node (for 'future-proofing') will work well.
One thing that the blog's author stated, however, caught my eye, and that being his noting that multisite is 'required' for linking vCenters. I haven't re-linked my 2 vCenters in the lab (both installed/configured to use the same primary node SSO server I setup), but I had read differently... that I can have linked mode vCenters in a primary node SSO config. I can already see both vCenters that I had access/admin rights to prior to upgrading my lab 4.1 ones to 5.1 ones, within the Web Client, so from that perspective they're definitely 'linked' but of course Linked Mode in the classic sense with the 'fat' .Net vSphere client is different. I'll find out soon and post back because I'm doing more lab stuff today.
It's baffling how badly documented SSO's various configs are and how many installation issues there have been since 5.1 came out, necessitating these quick revisions/updates to the code from VMware, namely 5.1.0a and now, 5.1.0b. I have information that I can't elaborate on that yet ANOTHER revision (5.1.1 or 5.2?) will be out circa May that attempts to mitigate many of 5.1's misgivings. Perhaps then they (VMware) will actually have plugins for their very own products for the Web Client, namely Update Manager and SRM.