vRA: Identity Appliance or vSphere SSO when there are multiple vCenters (each with their own SSO) in the environment?

[RebeccaW]

Setup: We have multiple vCenters each with their own SSO. We have build a minimal install lab of vRA 6.1 and used the SSO of the vCenter that is the lab endpoint (and wound up having problems when that vCenter's SSO had to be rebuilt and in turn wound up rebuilding vRA). Currently building out a vRA 6.2 Distributed Lab (based on the large deployment in the 6.1 reference architecture) to validate our plan for production and have decided to use the Identity Appliance.

Question: For a production buildout is there any reason not to use the Identity Appliance (scalability, performance, lack of HA)? If using vSphere SSO, when there are multiple vCenters which one should be used for vRA's SSO? If that vSphere SSO is ever removed (say down the line things are changed to one central SSO for all of the vCenters rather than each on their own, or some issue necessitates it to be rebuilt) is there a clean way to repoint vRA's SSO without a rebuild?

Message was edited by: RebeccaW (removed unrelated Postgres question)

[willonit · Accepted solution]

What I have done in this instance is to build a fresh SSO cluster using vCenter SSO and pointing vCAC to it. This becomes my primary SSO source and I slowly point vCenters and other components to it overtime. You will usually want to put signed certs on vCAC SSO and typically I don't find people deploying vCenter SSO this way. So instead trying to modify an existing vCenters SSO and risking having to reinstall your VC because you botched the certs, just build a new one. This also mitigates a vCenter changing overtime and messing up the vCAC SSO. The identity appliance cannot be clustered or joined to existing SSO domains. So if you are looking for HA and scale that probably will not cut it.

[sbeaver]

Rebecca,

I just want to comment on what I have in place.  I am using the identity appliance for vCAC and I have several different vCenter spread over multiple datacenters with each data center having its own master SSO site  and have not had any problem with vCAC to VCO communicating and working with any of the vCenters as long as I had the right credentials set up.  

[stvkpln]

We use the Identity Appliance, too. The TL;DR version is this: if the intended best practice was vSphere SSO, the Identity appliance wouldn't exist.

Frankly, I think it's bad (bad bad bad) juju to use SSO. What's that old adage? "Just because you can.. it doesn't mean you should.". When we were architecting, it was a concern that due to the differing development cycles for vCAC and vSphere, there could be incompatibilities between versions of the two, and while I'm sure VMware does test this sort of thing, do you want your upgrade cycle tied to supported configurations? That was ultimately proven out with multiple situations where vCAC would be updated, and it subsequently wouldn't work with vSphere SSO and then a patch would have to be released to address it... and so on and so forth.

As far as I recall, vSphere SSO's "redundancy" isn't really all that redundant in the sense that there's any sort of automated way to perform failover. With vCenter and it's ilk, that can be mitigated with load balancing (if you have it), but I've never heard that vCAC can even be successfully tied to a load balanced SSO URL in lieu of directly to an instance.

I suppose what you should really ask yourself is if the integration risks are really worth some amount of (maybe) redundancy. Really need to consider what you're going to get out of pointing to vSphere SSO that can't reasonably be achieved with vSphere HA on the cluster hosting that appliance.

Just my two cents.