SSO with VDI

[Richie67000]

Hello,

I have a question.

I want to implement VDI in my architecture VMware. I am in Vsphere 5.0. So i want to migrate to 5.5.

Concerning the SSO role, it is recommanded to seperate the role SSO in other machine?? Or i can implement this role in the same machine on my vSphere Server?? What are the advantage and drawbacks?

Thanks

Richie

[rh5592 · Accepted solution]

VMware's recommendation is to deploy all components (SSO, web client, inventory service, vCenter) into the same machine. This removes complexity in architecting and managing the environment. Checkout this blog post When to Centralize vCenter Single Sign-On Server 5.5 | VMware vSphere Blog - VMware Blogs

[grasshopper]

Generally I agree with VMware's recommendation to scale these components up on the same server.  However, VDI is the only exception IMHO as failed SSO upgrades have a tendency to stop the vCenter Server service (vpxd), which equates to a denial of service for VDI.  For this reason, I personally prefer to separate the SSO piece only for VDI deployments.

[Richie67000]

OK OK!

If the SSO is down, VDI is down??

[grasshopper]

My point is the following...

If running brokered VDI instances that power up on demand, if the vCenter service is stopped, that's perceived as an outage since no net-new VDI's can be deployed.  It should not affect running VMs or VDI instances if the vCenter service is down.  This is of course totally dependent upon your setup and YMMV.

With the method of deploying SSO as separate VM, You can keep on trying if the SSO upgrade fails.  However, if the SSO deployment fails when attempting to install it on your current vCenter, there is a possibility (undocumented as far as I know) that when the SSO installer rolls-back, it will stop your vCenter Server service.  I cannot give any more detail than that.

As always, just ensure that you have good backups / snapshots of your current deployment before performing any vCenter upgrade activities and you will be fine.  You may also consider spinning up extra VDIs to satisfy demand while the vCenter service is down.