SSO and SQL Cluster

[bilalhashmi]

Can someone please confirm if SSO DB can be installed on a SQL cluster and is this supported? I have read many conflicting deatils on that.

My understanding is that vCenter can be installed on a SQL cluster and is supported (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102405...). Which brings me to the question that if SSO DB is not supported in a SQL cluster, then doesnt that mean one needs to have to instances for vCenter (clustered) and a non clustered instance for SSO. I know vCenter can be installed using a non-clustered  SQL as well, but why not benefit from the reseliency for MSCS?

Finally, if SSO goes down... with it goes down the ability to use the web-client and log into the vCenter. Doesnt that mean one would want the SSO to be in a highly available env? I know we can install SSO in a clustered mode but even that points to a single DB. And if this DB can't live on a clustered SQL setup, how can we make SSO truely highly available. The DB can become a single point of failure from a mangment prespective and such. How is everyone addressing this if SSO can't be installed using a SQL cluster. If it can be done without breaking support, please enlighten me. I have been looking for those words myself for a few days.

[Rufat777]

I'm on the same issue. Any Ideas?

[JimKnopf99]

Hi,

SQL cluster for vCenter is not official certified. It could work. But if you ran into problems, it could be, that you have limited support from VMware.

The only fully supported cluster solution is VMware heartbeat. That protects all of your VMware services. Also SSO database.

Frank

[vcpguy]

WOW !!! I was not at all aware of this limitation. Thanks for your question.

Could you please point where you read about VC database not supported in SQL clustered environment? I know, few of my clients running VC database in a SQL clustered environment. They do complain that during the time of failover VC stops but a reboot fixes the problem.

Please point me to the link/artice that SSO database not supported in a SQL cluster environment.

Thanks

[JimKnopf99]

Sorry. I guess I read your question the wrong way. I thought you want to cluster the application with a ms cluster. Sorry for that. So forget what I have written.

Frank

Am 03.03.2013 um 18:28 schrieb vcpguy <communities-emailer@vmware.com<mailto:communities-emailer@vmware.com>>:

VMware Communities<http://communities.vmware.com/index.jspa>

SSO and SQL Cluster

reply from vcpguy<http://communities.vmware.com/people/vcpguy> in VMware vCenter™ - View the full discussion<http://communities.vmware.com/message/2204539#2204539

[bilalhashmi]

I had a long detailed discussion with VMware regarding this. This was the outcome. SQL DB clustered is not a 100%, VMware will give best effort support for that. For vCenter and VUM I know this is a common config and it usually works. For SSO there are some known issues due to dynamic ports and named instances.But folks have been able to get it working. Bottom line is its not a 100% supported but VMware will give best effort.

So what is a 100% supported solution for application and db? Heartbeat product. That will provide you redundancy for not only the DB side, but also for all aspects of the vCenter like the IS, SSO etc. Problem is its very pricey but then again that is aa fully 100% supported way to go if thats very important.

Here is a confusing KB article, it appears as if they are taking about clustering the application side. After reading whats in the link below, I inquired and reached out to a few folks at VMware and I was suggested heartbeat for all apps and db clustering

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102405...

To your point regarding your clients having to restart their vCenter after a SQL cluster failover. I think whats probably happening is during the failover the vCenter experiences hickup and the vCenter service goes down. I would check to see if the vCenter service is up after SQL has failed over. If not perhaps starting that would do the trick. If its still running, perhaps restarting it would do the trick. Not sure if restarting the vCenter server would be required. If the service does the trick, then maybe a loop can be put in place to attempt to restart the service after a failure to avoid any manual intervention. Hope that helps.

[Robuea]

In my experience those products that use the ODBC DSN's, tend to work with SQL clustering well (i.e. SRM, Vcenter, VUM).

Those which do not, or use jdbc, sometimes dont (i.e. SSO, webclient)

In previous cases before SSO arrived, My clustered SQL deployments could failover with no vSphere client interruptions.

I have now changed from deploying physical SQL clusters to standalone SQL VM's, which works well.

yes, vmware may try their best to support it, but you wont have 100% support.

My view, is that SSO is now (unfortunately) such a critical infrastructure component of vSphere, an unsupported vendor configuration is an unacceptable risk and would be a difficult situation to talk yourself out of if there was a problem.

[gene_torres]

This is good to know especially related to SSO and how crucial it is now to successfully managing the environment.  I know that in the past with vCenter 4.x, we actually housed the DBs on an HP PolyServe cluster, which constantly caused us problems whenever there would be a failover, and our datacenter operators would constantly call because vCenter services were down or not starting.

I personally like the approach of the dedicated SQL server, especially regarding being able to bring it up quicker than an MSCS SQL cluster in a DR event.  1 server, simple config/setup vs. multi-node shared-disk cluster.  I'd actually also prefer to have a vCenter management infrastructure running more than not; even if it's a simple reboot to get services back up again.  At that point, you're at the mercy of whoever set up and supports the cluster, especially if your vCenter DBs aren't a priority compared to business continuity application DBs.