Editor's Note: This is the second part in a series of articles from Mike Laverick on vCenter HeartBeat. Read part one: Boost vCenter server availability with vCenter Server Heartbeat.
First, I began with the installation of the vCSHB product to the primary vCenter Server, with the secondary vCenter Server powered off. The installation routine is relatively straightforward one. After running the setup programme you can indicate that you are configuring the primary node, and whether the configuration is LAN or WAN-based (for the purposed of my evaluation I used the LAN format).
As I had used vCenter Server to hot-clone the primary vCenter Server itself, I was able to select the "Pre-Cloned" option in the wizard. About midway through the installation, you have to be careful to select the correct network interfaces for the system, indicating clearly which NIC is for the VMware Channel and which is for the Principal Public Network. The first network wizard allows you to set the VMware Channel, together with the IP address you intend to use for the secondary server.
It was this second dialog box that I received an error because my secondary server was not yet up and running. vCSHB validates the IP address typed into the "IP Address on Secondary" field, and if it is not "ping-able," will return an error.
In effort to avoid an outage of my primary vCenter Server due to an unforeseen conflict, I had actually kept the secondary server powered off. In hindsight I think I would have been wiser to have the secondary server powered on with its Principal Public Network disabled (to stop IP conflicts), and have the VMware Channel (the one with the 18.104.22.168 address) enabled. Fortunately, it is possible to carry on with the installation regardless of the pop message.
The next part of the wizard configures the Principal Public Network and allows you to set the IP address. In a LAN configuration this is the standard IP address you use to ordinarily connect to vCenter Server. In WAN configuration it's possible to set this to be a different IP address and this is akin to the "Cluster IP" that is used in some other solutions you may have come across. As I was configuring for the LAN, I was able to maintain my existing IP address.
Protection of vCenter Server
The next part of the configuration allows you to indicate if you are protecting just vCenter Server or vCenter Server and SQL Server, or just SQL Server. In the new release, there is an option to even protect the VMware View Composer service that provides the "Linked Clone" feature to the VMware VDI "View" solution.
In my case, vCenter Server runs in a dedicated virtual machine (VM), with the SQL Server instance being in a separate VM. It is possible to run both vCenter Server and SQL Server on the same Windows instance, and vCenter Server Heartbeat can accommodate these different configurations. If your vCenter Server and SQL Server are running in separate instances of Windows, within either physical or virtual machines, the vCSHB license allows you to also protect the backend database behind vCenter as well. I've always used a separate SQL server for vCenter Server, as I know this is a common in the corporate space, and I like my books, guides and articles to mirror real-world configurations as much as possible.
The last two parts of the wizard allows you indicate a shared location for the "Pre-synchronisation Data Configuration" that enables the secondary server to pair with the primary. Additionally, a special packet filter is installed to the primary vCenter Server at this point:
The role of this "packet filter," called the "NeverFail Network Service," is important and somewhat unique to the NeverFail approach to availability. It allows for two nodes (primary and secondary) to reside on the same network with the same host name and IP addresses -- without a conflict occurring. Affectively, the primary and secondary "Principal Public Network" interfaces are not visible to each other, whereas the VMware Channel used to detect failures is still fully functional, albeit NetBIOS is disabled during the installation of vCSHB to prevent computer name conflicts.
Adding the secondary vCenter Server
It was now time to add the secondary vCenter Server to the system. To avoid IP conflicts, this VM was powered up on two internal switches. This allowed me to change the IP address of the secondary server to a temporary address to allow communication both to the primary vCenter Server and the shared location.
This part of the configuration was little a bit tricky, because a couple of times during the installation I had to open the "Local Area Connection" settings to make sure the right IP address had been assigned to the "Principal Public Network." If I made this interface have the same IP address as the primary vCenter too early, I would find I could not access the shared location.
Once the "NeverFail Network Service" driver had been installed, I was able to switch it back to being the same IP address as the primary vCenter midway through the wizard. I found this part somewhat disconcerting. In hindsight, if I'd read the reference guide more closely, I would have found guidance on when to have the Principal Public Network connected and disconnected.
Once the installation had completed, there was some post-configuration tasks to complete in the vCSHB Console. Firstly, I needed to add the primary vCenter Server into the console to do any management, and this was my first opportunity to confirm the installation had been really successful. Within the "Server" tab the "Make Active" button allows you to select the standby and manually failover the primary vCenter Server role to the secondary vCenter Server.
Note: In the screen grab above, I've selected the secondary server, with the option to use the "Make Active" button used to move the vCenter role from one VM to another.
If you are protecting vCenter Server 4.x with vCSHB, you will get an alarm indicating a problem with the vCenter Server licensing. The alarm appears next to the application status on the main summary page, and states that vCenter has "Started -- Warning -- Degraded applications: VMwareVirtualCenter."
The alarm is triggered by vCSHB checking to see if the VMware License Service is available. In a clean installation of vSphere4.x, there is no need for the License Server that is a legacy component of the older VI3.x platform. If you know you don't need the legacy license server, you can turn off this alarm from the Applications Tab. Under the "Rules" option you can scroll down to the bottom and using the edit button disable the alarm rule.
Another change is required to stop a benign warning about the application being "degraded" -- setting a username and password for the vCHB "VirtualCenterNFPlugin." The plug-in speaks to the vCenter internal TomCat Web service and will functional perfectly fine without credentials, but will generate alerts and log entries which can give the appearance of a problem. The configuration is held within the Application Tab, Plugins and then an edit button exists to set the credentials.
The "Network Tab" allowed me to configure additional IP addresses for the hosts to ping to verify their network status, and the enable the automatic failover or "Auto-Switchover" in case an outage occurred. By default, the auto-switchover feature is not enabled by default. I felt that in a production environment it would be desirable to allow this if your goal is to increase the availability of the service. In a more DR=orientated approach, you might wish this to be a more manual and controlled process.
Note: Here I set the 192.168.3.199 and 192.168.3.131 addresses for my second and third targets. These IP address represent my router and my second domain controller respectively, with 192.168.3.130 being my first domain controller.
Note: Auto-switchover is not enabled by default. The value for the "lost pings" should be configured relative to your network latency in a WAN solution, and the reliability of your network.
As you can see, the vCSHB is very easy to configure and setup compared to other solutions, and it does help that the core vCSHB product has been customised to some degree to ease this setup process. The real question was whether after all this effort if my vCenter Server was any more resilient from downtimes than it was before I installed the product… more about that in the next part of my article!
Editor's Note: Part three and four of this vCenter HeatBeat series to follow soon.
ABOUT THE AUTHOR: Mike Laverick is a professional instructor with 15 years of experience with technologies such as Novell, Windows and Citrix, and has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. In addition to teaching, Laverick is the owner and author of the virtualisation website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere 4 and VMware Site Recovery Manager.