So until today I was under the impression that SSO only effects the web-client in 5.1. The way I understood was the vSphere client still behaves the way it did before and SSO is not engaged unless the web-client is used to login. This also brought me to the conclusion that if SSO goes down, one cannot login via the web-client but the vSphere client can still be used. Wrong!!
A colleague of mine pointed me to a this page that clearly states the following:
How does SSO integrate with the vSphere Client?
SSO does not integrate with the vSphere Client. However, when you log in through the vSphere Client, vCenter Server sends the authentication request to SSO.
Once I read that I started doubting my thought process and the importance of SSO in 5.1 Apparently all access to vCenter must be down once SSO is down (both via web and vSphere client).
After doing a lot testing this is what I found (vcenter 5.1 build 799731). When SSO is down,
- access via web-client is down as expected
- access via vSphere client is flakey
This also meant any new account that was created or granted access couldn’t login using the vSphere client. Rememeber we only had luck with accounts that were able to login succssfuly prior to SSO service going down. And that too required the checkbox to be checked. If the account was just created or granted access after SSO went down, the screen showed the beautiful message on the right. The same message was received if the account didn’t successfully login while SSO was up. Why cant this message say the SSO cannot be reached is beyond me. By the way the web-client will tell you “Failed to communicate with the vCenter Single Sign On server” when SSO is down. So thank you VMware for doing that.
Another thing to keep in mind. When SSO service is down, your vCenter service continues to run. However, if you attempt to restart your vCenter service you will find yourself in trouble. I was unable to get the vCenter service to start with SSO being offline. Which makes SSO even more important. Yes even with vCenter down your VMs continue to work but there are other vCenter specific features that will not function like DRS, sDRS for example. And if this vCenter is connected to a vCloud instance thats another can of worms.
So the bottom line is, SSO is very very important. It has two parts, the application and the DB part. VMware has done a great job in giving the option to install SSO as single, clustered or even multi-site type deployments. The high availability in the application side is thought out there. However, the problem is DB. VMware does not fully support SSO DB on a SQL cluster. As a matter of fact, there have been known issues that have come about when trying to deploy SSO using a SQL cluster. So the real option with full support is a stand alone SQL node. But that also creates a single point of failure. When the DB goes down, you are unable to login using the web-client, you maybe able to login using the vSphere client and all other things we discussed above.
So building redundancy is extremely important. VMware’s recommended solution is to use vCenter Heartbeat. We all know that can be a pricey solution. However, if full support along with redundancy is importnat to you, that is the way to go. I hope VMware extends their full support to at least allow running DB on a SQL cluster for all their products including vCenter (which is still a grey area). That would be the right thing to do. Heartbeat provides added functionality and there will always be a market for that as well. I hope full support on DB residing on SQL clusters is not further delayed in the interest of the vCenter Heartbeat product.
In the end I will borrow Tom Petty’s words to tell VMware “Don’t do me like that”…