Separate SSO servers for small environments?

[drheim]

We have (2)different VMWare 5.1 environments for security reasons.  We have (1)vCenter server with 6 hosts and 100 VMs and another vCenter server with 20 hosts and 500 VMs. The only reason we have different vCenter environments is because of different VMware admins for the different environments.  They also each have their own SSO server running on the different vCenter servers.  We keep the admin@system-domain password access restricted, but the same for both.  Is there any reason to have (2)different SSO instances?

Thanks,

Dan

[bayupw · Accepted solution]

Hi

There is VMware blog post here regarding when to centralize SSO When to Centralize vCenter Single Sign-On Server 5.5 | VMware vSphere Blog - VMware Blogs

For vSphere 5.5 the VMware recommendation is to centralize vCenter Single Sign-On when you have 8 or more vCenter Server instances in a given location (this is a soft recommendation).

There can be increased risk when centralizing a vCenter Single Sign-On server (to why it is not recommended for smaller environments) due to the increased number of components affected if the vCenter Single-Sign-On server was to become unavailable, in short all vCenter Server components of all vCenter Servers registered will incur authentication loss (when compared to  just the single vCenter Server instance when installed locally) and so availability of the vCenter Single Sign-On centralized server(s) is highly recommended.

There is also a deployment guide on vCenter - VMware vCenter Server 5.5 Deployment Guide http://www.vmware.com/files/pdf/vcenter/VMware-vCenter-Server-5.5-Technical-Whitepaper.pdf

The recommendation is to centralize SSO+Web Client when you have 8+ vCenter Servers, because you will need to make the SSO+Web Client High Available with Load Balancers and there is a couple steps involved to load balance vCenter SSO as described here:

VMware KB: Configuring VMware vCenter Single Sign On for High Availability

Load Balancing vCenter Single Sign-On | VMware vSphere Blog - VMware Blogs

For less than 8 vCenters, the recommended approach for deploying vCenter Server in almost all scenarios involves a single virtual machine for the vCenter Server components and a separate virtual machine for the vCenter Server database.

If you want to keep it as 2 separate vCenters, I do not see any advantages of centralizing SSO.

Centralizing SSO will share @system-domain users including admin@system-domain and you would need to make the SSO high available because it will affect 2 vCenters if SSO is down.

But if you are planning to merge the vCenter, you can have 1 vCenter to manage all the 6+20 hosts and 100 VMs+500 VMs  but can still manage the permissions.

admin@system-domain will be shared can see all the inventories, but specific groups/users can only see 1 environment.

As described here: vSphere 5.5 Documentation Center - Best Practices for Roles and Permissions you can use the No Access role to masks specific areas of the hierarchy that you don’t want particular users to have access to.

So the first groups/users can only see 6 hosts & 100 VMs, and the others only 20 hosts & 500 VMs.

http://www.virtuallyghetto.com/2013/12/why-is-there-no-access-vsphere-role.html

Do not use admin@system-domain for daily operations but create a separate groups/users for this.

You will also save the vCenter Server licensing cost & sns.

So there are 2 options that I can think and no need to go with centralize SSO.

1. Still keep 2 separate vCenters+SSO+WebClient+Inventory Services or

2. Merge the vCenters become 1 vCenter Server+SSO+WebClient+Inventory Services, create & manage new groups/users and assign permission as required

Message was edited by: Bayu Wibowo

[vThinkBeyondVM]

Hi Friend,

  In addition to "Bayu's" suugestion.

3. You can go for MultiVC environment where multiple VCs are connected to same SSO. & In order to provide HA to SSO, you could configure SSO with load balancer (where if 1 SSO goes down second fail over)

[drheim]

Thanks Bayu,  That is what I was looking for.

Dan