It’s been a while coming but I’ve finally got some time to write this article on protecting vCenter Server availability. It’s probably also come as an opportune time as not so long ago VMware announced the end of availability of vCenter Heartbeat so now many of you are probably looking for ways to protect vCenter Server more than ever especially due to the criticality that it brings in management and operations of your vSphere environment. This article will highlight areas that need to be protected and what options you have.
With release after release of vSphere more functionality goes into vCenter Server and more of the virtualized environment relies on it being available to serve the needs of the administrator. although vCenter Server can typically reside on a single server, it is made up of many critical parts. If you’ve sat through an install of vCenter Server you will know that its broken up into 4 core areas, these are Single Sign-on (SSO), Inventory Service, vCenter Server itself and lastly there is also the vSphere Web Client & Services. SSO is a core component of vSphere since its introduction in v5.1, it’s there to handle authentication requests and also is a security broker handling requests coming from the various vSphere solutions. Although there were some operational hiccups in v5.1, subsequent versions have become stronger and deployment options have increased, I’ll take a look at those in a minute. The Inventory Service is another key component that has two functions firstly it stores the custom tags for the vSphere Web Client and secondly it’s also a proxy for the vSphere Web Client which actually assists in reducing the load on the vCenter Server (VXPD), knowing this little tidbit can actually help in deployment scenarios so if you are breaking up the components onto separate servers then it’s best to keep the Inventory Service close to the vSphere Web Client Services. Next there is the vCenter Server itself which is made up of a number of services and critical to the whole environment. Lastly there is the vCenter Web Server/Services which provides the administrator with a web UI for management and operations of the entire environment.
Now we’ve gone through the critical services let’s take a look at deployment and availability options within each group. Ignoring the simple install option of vCenter for the moment, options available when using the custom install method for SSO provide the ability to install in 3 types of deployment modes, these are single SSO, SSO installed in HA mode and SSO installed for multi-site environment. With single deployment it’s just that, SSO is installed onto a system and acts as a single entity for the whole vSphere environment. HA mode provides the ability to add another SSO system to an existing SSO system and provides a failover mechanism in case the primary SSO system fails; typically a load balancer is used in front of the SSO servers for ease of configuration. Lastly the multisite option provides local authentication in a multiple site scenario, be aware though that there is no failover between sites so if a failed site fails then local authentication for that site will fail too. I don’t want to focus too much on the different scenarios too much as there are plenty of blogs out there which highlight best practices for deploying SSO. What is important is the availability of the services especially in a single SSO deployment which let’s face it will be used by large number of SMBs and enterprise customers.
When deployed on a single system SSO services consist of 5 key services, these are the VMware Certificate Services, VMware Directory Services, VMware Identity Management Services, VMware KDC Services and the VMware Secure Token Services when these services are installed the default Windows Service Manager recovery configuration for most of these services are set to restart upon 1st and 2nd failure, you may think this will be OK for availability but what if the service keeps failing, what if the service doesn’t restart, what effect will it have on the other key components in the environment which as we know now are critical to operations. What’s needed is a method to monitor these services and the other components intelligently and remediate any issues that occur within the environment. The other services such as Inventory, vCenter Server and Web Services do not have any recovery options enabled so the administrator is pretty much left to manage those independently.
Using a solution like Symantec ApplicationHA can assist in protecting all of the vCenter Server services and still have the ability to utilize VMware features like VMwareHA and DRS especially useful if vCenter Server has been deployed onto a virtual machine, which I assume you have. Symantec ApplicationHA provides the ability to monitor all of the key components and in the event it is unable to resolve issues it can pass control to VMwareHA to reset the virtual machine. ApplicationHA has a number of application agents it supports and also has a vCenter agent which can be used to protect vCenter. There is also a wizard which can be launched from with vSphere Web/Desktop Client which can be used to protect vCenter. The current version of the wizard does not include SSO configuration but can be added after the wizard is run. Symantec are aiming to update their wizard to include SSO so for the moment we can script the additional services pretty easily with ApplicationHA commands
Symantec ApplicationHA auto detects the services within the deployment and provides the ability to also monitor the connection between the SQL database and vCenter itself.
This is of available vCenter services are displayed within the configuration
The dependency of the services is shown by viewing the dependency component view.
Finally the additional SSO services can be added to the configuration by running the script containing the commands below. I've attached a zip containing the script to this article for conveinence also.
haconf -makerw hatype -modify GenericService RestartLimit 1 hares -add VMWareCertificateService GenericService vCenterServer_SG hares -modify VMWareCertificateService ServiceName VMWareCertificateService hares -modify VMWareCertificateService Enabled 1 hares -add VMwareDirectoryService GenericService vCenterServer_SG hares -modify VMwareDirectoryService ServiceName VMwareDirectoryService hares -modify VMwareDirectoryService Enabled 1 hares -add VMwareIdentityMgmtService GenericService vCenterServer_SG hares -modify VMwareIdentityMgmtService ServiceName VMwareIdentityMgmtService hares -modify VMwareIdentityMgmtService Enabled 1 hares -add VMwareKdcService GenericService vCenterServer_SG hares -modify VMwareKdcService ServiceName VMwareKdcService hares -modify VMwareKdcService Enabled 1 hares -add VMwareSTS GenericService vCenterServer_SG hares -modify VMwareSTS ServiceName VMwareSTS hares -modify VMwareSTS Enabled 1 hares -add vmwarelogbrowser GenericService vCenterServer_SG hares -modify vmwarelogbrowser ServiceName vmwarelogbrowser hares -modify vmwarelogbrowser Enabled 1 hares -link vspherewebclientsvc vpxd hares -link vimQueryService vctomcat hares -link vpxd VMwareKdcService hares -link vpxd VMwareSTS hares -link vpxd VMWareCertificateService hares -link VMwareIdentityMgmtService VMwareDirectoryService hares -link VMwareSTS VMwareIdentityMgmtService hares -link vmwarelogbrowser vspherewebclientsvc hares -unlink vimQueryService vpxd haconf –dump –makero
Here is the final list of all services being monitored by ApplicationHA
And the dependency component view is also updated to include all of the services and the correct dependencies.
Now that the configuration is complete testing for fault scenarios can commence. For more information on ApplicationHA please follow the product link below.
Symantec ApplicationHA
