Quantcast
Channel: VMware Communities: Message List - vCenter™ Server
Viewing all articles
Browse latest Browse all 15787

Re: Separate SSO servers for small environments?

$
0
0

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.

Screen Shot 2014-05-14 at 5.40.19 AM.png

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.

Screen Shot 2014-05-14 at 5.38.58 AM.png

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


Viewing all articles
Browse latest Browse all 15787

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>