In vSphere 5.5, the SSO (Single-Sign On) component has been completely re-designed to help simplify the management of your SSO Server(s). A built-in automatic multi-master replication architecture is now used to ensure that all SSO instances are always kept in synced. This works great for a pure Windows based environment but what if you wanted to run a hybrid environment that includes a mix of vCenter Server on Windows and the VCSA (vCenter Server Appliance)?
A great use case for this would be for ROBO site management for which you want to simplify the deployment and management of these sites from a centralized location. Instead of deploying additional vCenter Servers on Windows and spend more on Windows licenses, you could leverage the VCSA. With this hybrid model you can still gain all the benefits of having a distributed SSO security domain as well as a centralized place for managing and accessing all your vCenter Servers and Virtual Machines. As you can see from the diagram below, the SSO replication is bi-directional from all SSO instances and this occurs by default every 30seconds. By joining all SSO instances under a common SSO security domain (vsphere.local), you also have the added benefit of being able to see inventory from all SSO instances by logging into anyone of the vSphere Web Clients at each site.
I was recently asked by a couple of VMware colleagues about this particular configuration and whether it would be possible with using the VCSA. It took a couple of days of tinkering in the lab, talking to some folks and several dozen snapshot reverts, but I am please to say I have been successful in getting this to work!
Disclaimer: This configuration is not officially supported by VMware as the configuration has not been officially been tested. Please use at your own risk.
Requirements:
- Configured Windows vCenter Server
- Un-configured VCSA deployed
Step 1 - Deploy vCenter Server 5.5 on a Windows server as you normally would.
Step 2 - Deploy a VCSA but do not configure it just yet, we have a script that will automate this for you.
Step 3 - Download configureAdditionalVCSAUsingCommonSSODomain.sh script which will automatically configure the VCSA to point to the external vCenter Server SSO instance as well as setup the SSO multi-master replication configuration. You can either run the script remotely or run it within the VCSA, but before you do you will need to edit the script and modify the following variables.
PRIMARY_VC
VC_USERNAME
VC_PASSWORD
SSO_SITE_NAME
The first three variables pertains to your Windows vCenter Server and make sure the username is *protected email* The SSO Site name can be identified by following the instructions found here. In addition to the above mandatory variables, there are a couple other variables that will automatically join the VCSA to an Windows Active Directory, you just need to enable the flag and fill in the variables.
Step 4 - You are now ready to run the script! The output is a bit verbose, but if you take a look at the script itself is is only a couple of lines 🙂 This is wayyy easier than deploying a Windows OS and then go through all those complex install wizards!
The majority of the script is actually from an earlier script that I wrote during vSphere 5.1 release for the VCSA. However, there are a couple of additions to the script that I would like to highlight. The first is starting all the VMware SSO Services and also ensure it is automatically started up during boot by running the following commands:
/etc/init.d/vmdird start
/sbin/chkconfig vmdird on
/etc/init.d/vmware-sts-idmd start
/sbin/chkconfig vmware-sts-idmd on
/etc/init.d/vmkdcd start
/sbin/chkconfig vmkdcd on
/etc/init.d/vmcad start
/sbin/chkconfig vmcad on
The final part is to configure the replication between the two vmdird instances using the /usr/lib/vmware-vmdir/bin/vdcpromo command. The command requires both the source and target username/password of the SSO administrator account as well as the source SSO Site name which can be identified by following the instructions here.
Once the script has finished (should only take a minute or two) you now can login to either vCenter Server instances and you will be able to see both your vCenter Server on Windows as well as your VCSA.
Note: Currently, the Lookup Service is shared between all vCenter Servers joined to the common SSO security domain. This behavior is not expected and is currently being investigated by engineering. In the meantime, if the primary vCenter Server hosting the Lookup Service is unavailable, you will not be able to login to your other vCenter Servers. You should ensure proper high availability solutions is provided for the vCenter Server hosting the Lookup Service until this issue is resolved.
In just under a couple of minutes you can easily deploy several VCSA's joined to a common SSO security domain with built-in replication and get a "poor" mans Linked Mode to view and manage all your vCenter Servers from a single place.
Note: Even though SSO multi-master replication between VCSA's is not officially supported by VMware, it does in fact work and is something I have been able to setup in my lab. To perform this, you just need to setup you first VCSA as you normally would and using the script above to join additional VCSA to the first one you setup.
In a follow-up blog post, I will show you how to verify SSO multi-master replication is properly configured and replicating using some free online tools.
Nick Morgowicz says
This is really incredible, William. Thank you for sharing!
My hope for vCenter since i started playing with it not too long ago was to be able to link the vCSA with the traditional windows install, and now we can.
Can you provide a little more information on the lookup service and why you believe that it's being shared on the windows install instead of being used/created on the vCSA? Also, how best could you make that service highly available?
Thank you!
William Lam says
I don't believe it's shared, I know it's shared 🙂 When you go through this configuration, try powering down the source Windows VC and see if you can still login. As mentioned in the article, this behavior is not expected and is currently being investigated by engineering.
Eric M says
I was able to configure a hybrid deployment prior to this script being shared, using your other post i went to confirm that replication was succesful and currently it does not recognize the vcsa machines as servers within each site. Is it possible to run this script against the VCSA that have already been configured and are already technically production? Authentication appears to be working properly but obviously the MMR is not functioning as expected.
William Lam says
Yes, this new script only adds two additional commands from my original one which I mentioned in the above blog article. Just take a look and the bottom of the script and you'll see the two new commands.
Eric M says
Ran the script on 2 VCSAs, one worked fine, the 2nd (which happens to be in the same SSO site as the main lookup host) fails with the following:
Vdcpromo failed. Error[9611] - Unknown (extension) error
InternalModifyEntry failed. DN: cn=DSE Root, Error code: 9611, Error string: CoreLogicModifyEntry failed. (9611)2013-12-18T18:12:40+00:00 VCSA01 vmdird: t@139887287355136: VmDirSrvSetupHostInstance failed. Error(9611)
Can't find anything on those errors, any suggestions?
William Lam says
You should not be running the command on the primary SSO instance you're trying to join from
Eric M says
The primary is a windows host, i am running the command/script on a VCSA server in the same site as that primary windows host. Thanks for the quick response.
Matt Lichstein says
Is there a plan to support multi-master replication between VCSAs offficially?
William Lam says
Yes. This is something that is being looked at
Thorben Jändling says
Thank you for the tips; I have howerver some questions, if I may:
A) If I understand correctly, each vc/sso is able to run independantly of the other (i.e. If one is down, the other still works). If so, then why is one VC named 'Primary VC' in your script? Is it more 'important' than the other?
B) How should one add a third vc/sso? Run vdcpromo for all three 'link/replication' combinations?
C) How does one remove a vc/sso? i.e. Decomissioning.
D) It's been over a year since you said that official support for VCSA only multi-master is being looked at. Has anything changed? What are the concerns about doing this?
We have a windows VC per location that are not linked in anyway, and I would like to switch to VCSA that are linked as you described. i.e. Each will work without the others, yet if they are all there you only need to login into one client once.
William Lam says
A) It was just the name that popped up in my head when I wrote the script, probably should have called it "First VC" just so users know that one needs to be setup then you can connect additional.
B) Refer to Step 3 for additional nodes
C) Take a look at http://www.virtuallyghetto.com/2012/12/seperating-out-vcenter-sso-vsphere-web.html
D) In vSphere 6, you will be able to easily do this using the new Enhanced Linked Mode support. You will be able to setup replication between Windows<->Windows or VCSA<->VCSA when you deploy using an external Platform Services Controller (PSC) which has SSO and other services. I don't believe we're supporting a mix of the two platforms, this is something I would need to double check.
The workflow to setup is much easier in vSphere 6, so definitely recommend you give that a look when it is generally available.
William Lam says
Just got confirmation from Engineering that WindowsVC<->VCSA where both are deployed w/External PSC will be supported
Hauce says
Long time lurker, first time commenter. Is it possible to use WindowsVC with VCSA acting as an external PSC only? A mixed environment if you will?