Since vCenter Single Sign On was introduced in vSphere 5.1, many questions have been rising around it. There seems to be a very limited amount of resources out there that document best practices related to vCenter Single Sign On, which is the reason for me to develop this post where I will try to combine as many best practices and answers related to vCenter 5.1 Single Sign On as possible.

I have been one of the lucky consultants who has already got to design/implement vSphere 5.1 for quite few enterprise customers where I have got to debate and drive best practices that I used across those implementations. I am sharing them here where others can benefit from them as well to allow a room for others to debate them and contribute their feedback.

Where to install vCenter Single Sign On (Physical vs Virtual)?

Just as the recommendations have always been for vCenter using virtual machine(s) is the best practice to save on cost and benefit of the availability features built in vSphere, that is no difference in vSphere 5.1. You can host all vCenter 5.1 components including SSO on virtual or physical machine, where virtual machine is the recommended practice due to the same reason mentioned earlier. Further, implementing vCenter 5.1 components including Single Sign On in a virtual machine will not limit its scalability by any mean and it still can deliver up to vCenter current maximums of 10,000VMs & 1,000 hosts.

Where to install vCenter Single Sign On (Combine it with vCenter Service & Inventory Service or on its own VM)?

As Single Sign On has became a mandatory requirement when installing vCenter 5.1, & as the option of breaking out the different vCenter components across multiple machines was introduced in vSphere 5.1 this has became the most vCenter Single Sign On related question. Although I titled this article as vCenter Single Sign On best practices, I would like to break in at this question and cover when to combine and when not to combine vCenter Service, vCenter Inventory Service, & SSO.

vCenter Inventory Service: vCenter Inventory Service can be resource intensive at larger environments especially ones that is approaching the 10,000VM/1000hosts vCenter limit. From scalability perspective, you will want to move the inventory service to a separate VM from the one running the vCenter service in environment approaching the vCenter limit (No exact number provided, but I will say anything larger than 8,000VMs/800hosts will fall into that category). In most other environments (>90% of the time), it will make much more sense to keep it running with the vCenter Service on the same VM.

vCenter Single Sign On: Unlike vCenter Inventory Service, SSO is a very light service that is not intense on resources even for the largest environment out there, which leads to scalability not being a concern when combining it with vCenter Service on the same VM.

On the other hand, you will need to decide on whether to place Single Sign On on the same VM as your vCenter service or not based on the importance of its availability & how are you planning to protect it. If your environment is made up of a single vCenter instance & you are quite sure that you will not grow or ever have a reason to have a second vCenter or other service like vCOPs or vCD sharing that same Single Sign On Instance then it is safe to host SSO on the same VM hosting the other vCenter Services. In this scenario, your SSO is only used for a single vCenter instance and it does not matter much if it goes down with it.

On the other hand, if you are having or planning to multiple vCenters in your environment, the importance of SSO is now beyond the importance of any single vCenter as losing it means you can not access any of the other vCenters. Imagine the scenario where you have to carry out maintenance on the vCenter VM hosting your SSO, you will not be only affecting access to that vCenter but every other vCenter & tool that is dependent on that SSO instance. For that in such a case when the availability of SSO is beyond affecting just a single vCenter then you will want to have it on a separate VM and make sure its well protected.

Which vCenter Single Sign On Deployment Mode should I use in my environment?

Before I go through which vCenter Single Sign On Deployment Mode to use in your environment & why, lets recall the vCenter Single Sign On Deployment modes definition as stated in vSphere 5.1 Documentation Center:

Simple mode:  installs vCenter Single Sign On, vCenter Inventory Service, and vCenter Server together on a single host machine using the vCenter Server Simple Install option. This option is appropriate for small deployments.

Basic mode: installs a standalone version of vCenter Single Sign-On. Multiple vCenter Server and Inventory Service instances can point to it. If the Single Sign-On server or the virtual machine hosting the server fails, administrators cannot access vCenter Server, but ESXi hosts continue to function normally. Multiple Active Directory and OpenLDAP instances can be added as identity sources.

High Availability Cluster: Cluster mode installs two or more vCenter Single Sign-On instances in high availability mode. All instances use the same database and point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, will see the primary Single Sign-On instance.

Multisite mode: is designed for deployments with multiple physical locations. Installing a Single Sign-On instance at each site allows fast access to local authentication-related services. Each Single Sign-On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups. In each datacenter, you can install Single Sign-On in standalone or clustered mode, pointing to the identity sources in that location.

Now that we have covered the different SSO deployment modes, let’s discuss which one you should use. The answer in its most diplomatic forms “It depends”. Different modes are used in different scenarios, though below I will talk about the use cases of each:

Simple Mode: This one should only be used for smaller deployments where having all the components on a single VM will not affect their scalability and availability requirements. The next question, I can see running in many people heads is what being regarded a smaller deployment. I have not seen any official statement on this, but it seems 10-25hosts/100-250VMs is where most of the answers I were getting. Something to remember in basic mode, you will be forced to install all your components on a single VM and your SSO availability will be tight to that vCenter instance.

Basic mode: While Basic mode allows you to combine vCenter Service, vCenter Inventory Service, & Single Sign On on the same VM, unlike the Simple Mode it will allow you as well to spread these services across multiple VMs when required for scalability or availability reasons. If vSphere HA or vCenter Heartbeat is your preferred method for protecting your SSO, and you are not planning to use the Multisite mode then Basic mode might be the right deployment mode for you. Unlike Simple mode, Basic mode fit organizations of all sizes and not limited for smaller deployments.

SSO HA: While I used to be more enthusiastic about this method in the past, the complexity it add to the setup and the requirements of a load balancer makes me recommend this only when vSphere HA does not satisfy your availability requirement and vCenter heartbeat is not an option.

Note: SSO HA provides limited availability, The database is a single point of failure (no cluster support) and the administration of SSO unavailable when failed over.  vCenter Heartbeat provide better protection and with a simplified configuration of SSO. As you can see vCenter Heartbeat is worth its tag price if you can stretch your budget a bit and if the availability provided by vSphere HA is not enough. In most cases, vSphere HA offer well beyond the availability required for most organization and is the simplest way of doing things.

Multisite mode: The only time I would recommend using multisite mode at the moment is if you are planning to use vCenter Linked Mode. In case you missed it, vCenters setup in linked mode must be connected to the same vCenter SSO instance where the goal of Multisite mode is to allow you to have a single vCenter SSO instance spanning across two different physical locations where each site will have its own SSO nodes(Single or clustered).  While this sound great in theory, there is few hiccups in there that you should be aware off:

• Multisite mode does not offer any kind off availability across the sites. For example if the SSO server at site A fail while it is setup in a Multisite mode with another SSO server at site B which is working fine, you will still lose access to vCenters dependent on the SSO server in site A. The good news is that you can configure each SSO involved in multisite configuration in High Availability Cluster within the same site to protect against its failure.
• SSO does not currently have any built-in replication to keep the nodes across sites within a Multisite mode in sync, where you will have to script the process of SSO database replication across the sites to achieve such configuration which is required by vCenter Linked mode.

I guess depending on your environment, you will have the choose the deployment mode that fit you best. Tthe simplest option where vCenter SSO is being protected by vSphere HA is the most common as it reduce complexity and provide much of the desired availability.

Do you recommend vCenter Linked Mode to obtain a single view of your multiple vCenters?

I have recommended vCenter Linked Mode in vSphere 5.1 environment as long all the vCenters involved were on the same site and have LAN like connectivity. I have usually recommended against the Multi-Site(different physical location) vCenter Linked Mode at the moment due to the complexity as well manual work and amount of maintenance required to keep it going in the long run. As I mentioned earlier, setting up vCenter Linked Mode across sites will require you to setup your SSO in a multi-site configuration as well to script a database synchronization between the two sites. Although its currently supported and workable, I am not advising for it unless it is a mandatory requirements. I am confident though this will improve as vCenter SSO evolve.

Can you recommend on sizing for the SSO VM?

KB2021202 has provided a great sizing recommendation for vCenter components & I referred to it consistently when I started working with vSphere 5.1 & I believe you should give it a look. It has actually recommended a minimum of (2vCPU, 3GB of RAM, 2GB of disk) for vCenter Single Sign On VM. In practice, what I have usually used and recommend for the SSO VM size is (2vCPU, 4GB of RAM, 20GB of disk).

 Where Do I install vCenter SSO Database?

This question has been popping up quite often lately. Do I actually install vCenter Single Sign on database with it on the same VM, or on the DB Server hosting my vCenter DB? While both options work pretty well, consider the below recommendations when making your choice:

– If vCenter DB is hosted on the vCenter VM,  & you have decided to host SSO on a separate VM for availability perspective then you should not host your SSO DB next your vCenter DB on that VM. It just does not make sense, as you will be tying your SSO availability again to vCenter and that is the reason you decided to host SSO on a separate VM from vCenter in the first place.

– If you have a production SQL Server setup and maintained by your DBAs and it is not running on your vCenter VM & maintained separately from it then this might be your best place to install your SSO DB as this will give you the advantage of your DBA maintaining & backing up the DB for you.

– If you like to have a self contained SSO server & not being dependent on any external DB or you don’t have a production DB server that is well maintained and centralize, then your best option will be to host your SSO on an SQL Express Database server that get installed on the vCenter Single Sign On VM it self.

 How to size my vCenter Single Sign On DB?

I hear this question a lot as VMware has not published any numbers on the size of the Single Sign On DB beside saying it is small. Actually after digging it a bit, I have found it to be small enough for most customers that sizing for it can almost be ignored. I have to still see a customer who use even close to 100MB of db size for vCenter Single Sign On. That have been said, I would actually keep a capacity of 1GB for the vCenter Single Sign On just to give you a lot of cushions in case you forget to trim your logs or so on, but in general you will not be using much of space for it at all as it only store the below three main items:

1. Identity Source Configurations
2. Users & Groups membership
3. Password Policies for SSO Users.

Will Microsoft SQL Express be sufficient for my vCenter Single Sign On DB?

Unlike vCenter which is limited to support 5 hosts & 50 VM if you are using Microsoft SQL Express to host its DB, SSO can grow to support the maximums of your vCenter 5.1 (10,000VMs/1,000 hosts) while running on Microsoft SQL Express which make it definitely an option specially if you are planning to install the SSO DB on the same VM as your SSO to keep it self contained and ease image backup and restore of it.

 Additional vCenter Single Sign On Resources:

While in this article I have tried to addressed few of the best practice questions that keep popping up in the field, there is quite valuable resources out there that I thought would be useful to point out in here:

1. Preparing the Database for Single Sign On installation
2. vCenter 5.1 Installation(Part 2) – Single Sign On Installation(Step by Step)
3. VMware vSphere 5.1 new vCenter architecture & Single Sign on
4. Frequently Asked Questions: VMware vCenter Single Sign On 5.1
5. vCenter Single Sign-On FAQ (2034918)
6. VMware SSO Blog

Feedback:

I am really interested in hearing your feedback, thoughts, what best practices that should have been on this list and needed to be added. Anything that you agree with or disagree with. Please keep those productive feedback comings so we can improve this list for everyone benefits.