WilliamLam.com

How to automate NTP configurations on the VCSA using the CLI

by // Leave a Comment

NTP configurations should be a mandatory setting for everyone, regardless of whether we are talking about VMware products or general infrastructure software. It is just as critical as having proper DNS configured and can cause a whole slew of issues if not configured or setup properly. A question that was raised internally a couple of days back was around automating NTP configurations on the VCSA (vCenter Server Appliance) which is normally performed through the VAMI web interface as seen in the screenshot below.

Instead of using the VAMI UI, the user was interested in automating it through the command-line and wondered if this was possible. This is definitely possible among other VAMI operations by leveraging the vpxd_servicecfg utility and there are a couple of options when configuring NTP on a VCSA 5.5 system.

The option that most of you will probably using is to configure a list of NTP servers (comma separated). To do so, you can run the following command (replace the NTP server with your own):

/usr/sbin/vpxd_servicecfg timesync write ntp '172.30.0.100' ''

This command should have a return code of 0, else there maybe an issue connecting to your time source from the VCSA. You can also confirm the operation was successful or query the current configuration by running the following command:

/usr/sbin/vpxd_servicecfg timesync read

If you wish to synchronize your time with the underlying ESXi host through VMware Tools, then you can run the following command:

/usr/sbin/vpxd_servicecfg timesync write tools '' ''

Finally, if you wish to disable time synchronization on the VCSA for whatever reason, you can do so by running this command:

/usr/sbin/vpxd_servicecfg timesync write none '' ''

Note: If the VCSA is joined to an Active Directory domain, then the time synchronization is provided by your Active Directory server and no additional configurations are required.

Once you have configured your NTP servers, you should can also manually force a sync to ensure the current date/time is correct by running the following command:

sntp -P no -r [NTP-SERVER]

How to verify SSO Multi-Master Replication is properly configured & working?

by // Leave a Comment

I wrote an article yesterday demonstrating a hybrid configuration using the new SSO Multi-Master Replication in vSphere 5.5 between a vCenter Server for Windows & a VCSA (vCenter Server Appliance). The process itself is pretty straight forward and I even created a script which will automate the entire configuration. However, other than some text being shown at the end of the script stating that MMR (Multi-Master Replication) being successfully setup; how do you actually confirm MMR is properly configured & working when adding additional SSO instances?

This was something I was actually pondering about since the process was just too "easy" and pretty much seamless as it should be from a users perspective. In speaking with engineering, I came to learn that vmdird (VMware Directory Service) just leverages the LDAP standard for MMR. This means we can use any LDAP browser to connect to vmdird and view its current configuration.

Disclaimer: Please take extreme caution when viewing the vmdird database, this is primary for educational purposes. You should not be making any changes while in the database else you can negatively impact your environment.

In this example, we will be leveraging the free open source LDAP browser JXexplorer which can be run from variety of operating systems including Windows and Mac OS X. We will use JXexplorer to verify replication between our source (vCenter Server on Windows) is properly configured with our target (VCSA), you can also do this for a Windows to Windows vCenter Server deployment. We will also verify that replication itself is working by going through an example of creating an object in the source system and then verifying it has been successfully replicated to the target system.

Step 1 - Download and install JXplorer on your desktop, it does not have to run on the vCenter Server itself as we can remotely connect to the vmdird.

Step 2 - Create a new LDAP connection for your source vCenter Server on Windows using the following configuration below:

Protocol: LDAPv3
Port: 11711
Base DN: dc=vsphere,dc=local
Level: User + Password
User DN: cn=Administrator,cn=Users,dc=vsphere,dc=local

If everything was entered correctly, you should now be able to connect to the vmdird database.

Step 3 - To confirm MMR has been successfully configured between your source and target SSO Servers, you can expand the inventory to local->vsphere->Configuration->Sites->Servers. Here you should see the list of SSO Servers participating in a specific site. If you expand each server, you should see a replication agreement between the source and target of each server, this means everything is configured correctly.

In the example I had in my last blog post vcenter55-3.primp-industries.com is my vCenter Server for Windows and vcenter55-2.primp-industries.com is my VCSA. We can clearly see the replication agreements between our two systems and everything looks good.

Step 4 - To check whether MMR is working, a simple test is to create a user in vsphere.local domain using the vSphere Web Client and then compare the Users database between our source and target vmdird databases. To do so, you can open up two JXexplorer sessions, one connecting to the source vmdird and the other connecting to the destination vmdird.

MMR takes ~30sec to perform the replication and in the example above, I created a user called "wlam" on my source site and then I was able to refresh my destination system and the new user has automatically been replicated.

I really like the new SSO architecture and has really simplified SSO installation and configuration by a factor of 1000x. The built-in multi-master replication is completely transparent to the end user and this is the type of user experience our customers have come to expect of VMware. Big kudos to the SSO Engineering/Product team for all their hard work! There is still a lot of work being done to further enhance the overall install/upgrade experience and hopefully we will get to see some of these benefits in the very near future.

Hybrid environment leveraging SSO Multi-Master Replication between vCenter Server for Windows & VCSA

by // 13 Comments

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.