TheVMinator
Expert
Expert

When to Separate vCenter and Single Sign on Server

With 5.1, I have the option to have the Single Sign on Server separate from vCenter Server.  When is this necessary and appropriate and when is it overkill?  If I am using vCOPS, VCD, and other components?  What are the factors that influence the decision to need to separate them such as:

-having many components in the environment needing authentication

-Having a heavly load of authentication traffic

-Other factors?

Thanks for your input.

0 Kudos
10 Replies
MarekZdrojewski
VMware Employee
VMware Employee

I'm facing the same question for a design I'm working on. Anyone any helpful tips?

Thanks.

| Blog: http://defaultreasoning.com | Twitter: @MarekDotZ |
0 Kudos
TheVMinator
Expert
Expert

Not a hot topic I guess...?

0 Kudos
MarekZdrojewski
VMware Employee
VMware Employee

I guess not... documentation is not providing any good info too Smiley Sad

| Blog: http://defaultreasoning.com | Twitter: @MarekDotZ |
0 Kudos
joshp
Enthusiast
Enthusiast

In environments where you plan to have multiple vCenter instances it makes sense to have a dedicated SSO server. You can point all of your vCenter servers to the same SSO server and have access to the same identity sources (included SSO defined users). Further, if you are operating in a high-secure environment; you can put the single SSO server behind a firewall and only allow point-to-point ACLs access to the SSO webservices (meaning vCenter, WebClient, etc would only be allowed to access the SSO webservices). This secures the SSO server greatly. I have deployed a vCenter server on an internal network (domain joined) and also a vCenter server in a DMZ (non-domain joined) and pointed both to the same firewalled SSO server. This solution works great because the non-domain joined server in the DMZ can be logged onto using Active Directory accounts in the domain where the SSO server is located. This deployment scenario was not possible until SSO was released.

I have deployed many environments with the new SSO component. In every instance the deployment consists of 5 servers:

1. vCenter instance with Inventory Service

2. SSO server

3. Web Client server

4. SQL server (for SSO RSA database, vCenter DB, and UpdateManager DB)

5. vMA Appliance (for remote administration and Syslog services for ESXi servers)

Note: I highly recommend you deploy SSO in the high availability mode even if you currently don't have plans to create multiple SSO servers for the same SSO instance. Once you select the single-server SSO install during installation you cannot move to an HA version of SSO without reinstalling.

VCP 3, 4 www.vstable.com
MarekZdrojewski
VMware Employee
VMware Employee

Thanks for your response.

How about scaling? Could you provide info how did you scaled those environements?

Thanks in advance.

| Blog: http://defaultreasoning.com | Twitter: @MarekDotZ |
0 Kudos
joshp
Enthusiast
Enthusiast

Specifically in regard to scaling; a single SSO installation should be able to handle pretty much all you can throw at it from an authentications per second perspective assuming you don't use very complext vCenter object permissions (see below). I have seen a single instance of SSO handle two 3rd party storage products that login to vCenter against SSO at least 50 times per minute 24 hours per day without any problems. Additionally, in an all VMware only implementation, SSO will only be queried at user login when "admin" type apps (vCenter, WebClient, API) are used--in most enviroments there probably isn't going to be hundreds of users using the vSphere Client or the WebClient.

That said, in my opinion there are major SSO scaling concerns in the way it handles enumeration of access to vCenter. It would appear (and confirmed by a VMware engineer), that when a user logs into a vCenter system via SSO; SSO performs backwards queries. Specifically, SSO checks your group membership for every object role you have defined in vCenter instead of checking a list of Security groups against all the object roles in vCenter (I know this is confusing). In other words, the more complex the permissions structure is within vCenter--the longer the SSO authentication is going to take because of the way it enumerates/checks permissions--the longer the login takes the greater the chance of timeouts (see below).

Lastly, SSO (contrary to some reports) is a very solid product after you get all the components implemented correctly (primarily SSL related issues). However, SSO still has some major kinks to work out that are scalability related. If you have a larger Active Directory environment (20+ thousand user/group objects) where you have users in multiple OUs under the domain root (ex. ou=corpusers,dc=foo,dc=bar and ou=execusers,dc=foo,dc=bar); after implementing SSO users may experience timeouts when logging into the vSphere Client and the WebClient. The current workaround is to change the Base DN value in an effort to forcefully limit the number of objects seen/searched by SSO; however, this workaround doesn't apply in cases where you have users in multiple OUs off the domain root path (not nested under a single OU). There's another issue where if you point the SSO "Groups" Base DN to something different than the User object Base DN--only the User object Base DN will apply reglardless of what you have set in the Groups Base DN field.

VCP 3, 4 www.vstable.com
TheVMinator
Expert
Expert

Great thanks for the great info.  So to clarify your comments:

I have deployed many environments with the new SSO component. In every instance the deployment consists of 5 servers:

1. vCenter instance with Inventory Service

2. SSO server

3. Web Client server

4. SQL server (for SSO RSA database, vCenter DB, and UpdateManager DB)

5. vMA Appliance (for remote administration and Syslog services for ESXi servers)

So with regard to vCenter Server, we are definitely planning for multiple vCenter Servers in the future, so I gather that having a separate virtual machine run SSO server is your recommendation.

So you are also saying that having Web Client server on it's own separate server - different from vCenter Server and from SSO server  - is also a good idea?

The issues here are not so much that the environment is huge and has huge performance needs (this environment is less than 2000 VMs and 200 physical servers)

(What we are desiging for more has to do with adding vCloud Director later and multiple private clouds as well as VCOPs, VUM, SRM).

0 Kudos
MarekZdrojewski
VMware Employee
VMware Employee

Thanks for your input, much appreciated.

Cheers!

| Blog: http://defaultreasoning.com | Twitter: @MarekDotZ |
0 Kudos
TheVMinator
Expert
Expert

This prompts me to ask another question which I've opened a separate thread for on separating web Client server:

http://communities.vmware.com/thread/429549

0 Kudos
JoBob
Contributor
Contributor

Dear Team just happened to see this discussion will you be able to provide inputs on the below query which have posted

VCenter and SSO Database

We are using external dedicated Database Server

During VCenter SSO installation RSA Database got created using the script (RSA_DATA.mdf,RSA_INDEX.ndf,translog.ldf)and pointed the SSO to it

Now During the installation of VCenter we pointed this also to RSA,the installation got completed.

Is this ok to have the above set up, will any issue arise in future?

In  future if we need to change to a diff DB for VCenter alone  is it possible to make the change?

Please  suggest

Also one query is it ok to have SSO on the default SQL instance bundled rather than pointing to an external DB? as for VCenter it shows that there is a restriction on VM counts on the default Database SQL express edition

Thanks

0 Kudos