Metadata
Title | Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services |
Version | VMware 24/JUN/2007 1.0 |
Author |
VMware (NYSE: VMW) is the global leader in virtualization solutions from the desktop to the data center. Customers of all sizes rely on VMware to reduce capital and operating expenses, ensure business continuity, strengthen security and go green. With 2007 revenues of $1.33 billion, more than 120,000 customers and nearly 18,000 partners, VMware is one of the fastest-growing public software companies. VMware is headquartered in Palo Alto, California, and on the Web at . |
Tags | availability clustering mscs virtualcenter high_availability |
Location | Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services |
Context | This paper documents the steps to successfully implement a high availability solution for VirtualCenter 2.5 using Microsoft's cluster services. There are some basic requirements to start the process. Microsoft requires Active Directory for cluster services. Additionally, Windows 2003 Enterprise server or higher will be necessary. |
Actors | VMware Certified Professionals, VirtualCenter Management / Sysadmin / Operations / Backup Operators |
References | Original document: Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services |
Outline |
|
Support | Please see this KB Article for information about support of this implementation. (TBD) |
How to use this proven practice
This document goes over the steps to successfully implement a high availability solution for VirtualCenter 2.5 using Microsoft's cluster services. It shows the setup of a reference implementation, however, other variations would also be valid. This document will be updated as additional configurations and options are validated.
The instructions were written using VMs for the cluster nodes. However, most of the instructions would apply for physical cluster nodes. For further information on clustering see Additional Resources at the end of this document.
Contributors
Chris Skinner, VMware: wrote the initial version of this document based on his own testing
What's Changed with VirtualCenter 2.5?
For readers who are familiar with the procedure used to set up VirtualCenter 2.0.1 with MSCS, this is how the procedure is changed with VirtualCenter 2.5:
With the release of VirtualCenter 2.5, the database password is now stored in encoded form using the certificate. The challenge is that the certificate is generated separately for each VirtualCenter instance and so the encoded password would be different for each. It is necessary to reset the database password on the first node, copy it over to the second node and reset it there as well. Once that is complete, both nodes will have the same encoded password in their respective certificates and the failover should be seamless.
Deployment Assumptions
This document assumes the following:
Using VirtualCenter 2.5
Cluster nodes run Windows 2003 R2 Enterprise server
Active Directory is properly working with the cluster nodes
The cluster environment has 2 private IP addresses for node to node communications and 4 Public IP addresses, one for each node, one for the cluster and one for VirtualCenter.
The VirtualCenter IP address should be able to communicate with your ESX hosts.
No other VMware product, such as VMware Update Manager or VMware Converter Enterprise, will be installed on the VirtualCenter Server nodes. These products can be installed on separate servers or VMs, and it is recommended that this be done when clustering VirtualCenter
The Guided Consolidation (Consolidate) feature built into VirtualCenter 2.5 is not being used. The instructions don't provide for failing over and restoring of this functionality, so it is recommended that it not be used on any VirtualCenter instance that you wish to cluster
Cluster Prerequisites
The instructions below assume that a cluster is already configured with the following properties:
Two cluster nodes (referred to in the instructions as VCNodeA and VCNodeB)
Public and private network connecting the nodes
Quorum disk
Please make sure that basic cluster functionality is working before proceeding with the rest of this document.
Clustering VirtualCenter Services
Although VirtualCenter is not a "cluster aware" application, its supporting services can be set up in an active-passive configuration. The first section starts this configuration assuming VirtualCenter is installed into the first node, VCNodeA, and is using a SQL server database on a separate server. Of course, SQL Server is a "cluster aware" application and can be setup to be clustered as well.
Verify that VirtualCenter works by logging in VI client. Once that's complete, stop the VirtualCenter service and the License server service in VCNodeA.
Start > All Programs > Administrative Tools > Services
Install VirtualCenter into VCNodeB using the same ODBC connector, database and license file. When prompted to reinitialize the existing VirualCenter repository, click No.
Click Ok twice to accept the notifications. Next, browse to the license file and click Next three times.
Click Install to begin.
Once the install is complete and the services have been verified, stop the VirtualCenter service and License server as before.
Go back to VCNodeA and start the VirtualCenter service and License service.
Copying the Certificates for VirtualCenter
In order to successfully failover in a cluster configuration, both nodes in the VirtualCenter cluster have to have identical certificates. This will not cause a conflict since VirtualCenter does not permit two VirtualCenter instances to simultaneously access the same database. They do, however, have to present the same credentials to the database. With the release of VirtualCenter 2.5, the database password is now stored in encoded form using the certificate. The challenge is that the certificate is generated for each VirtualCenter instance. It will be necessary to reset the database password on the first node, copy it over to the second node and reset it there as well. Once that is complete, both nodes will have the same encoded password in their respective certificates and the failover should be seamless.
Once the services have been restarted on VCNodeA, open a command prompt and navigate to:
C:\Program Files\VMware\Infrastructure\VirtualCenter ServerExecute, vpxd.exe -p to reset the database password to whatever you want.
Stop the VirtualCenter service again on VCNodeA.
On VCNodeA, navigate to:
C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSLCopy the certificates in this directory over to VCNodeB replacing that node's certificate
Note: It might be a good idea to rename VCNodeB's certificates first in case they need to be referred back.
On VCNodeB, perform steps 1-2 using the same password as VCNodeA.
Start the VirtualCenter service and make sure VI client can connect.
Stop the VirtualCenter service on VCNodeB and restart VCNodeA's.
Creating a VirtualCenter Cluster Group in MSCS
Although cluster services previously implemented, that was to establish the nodes involved and identify an owner of the cluster services. It is now necessary to create a new cluster group to specifically manage clustering for VirtualCenter and supporting services separately.
Start the Cluster Administrator on VCNodeA.
Right-clickGroups and select New > Group.
Enter a name and/or description for the VirtualCenter cluster and click Next.
Click Finish without adding any owners. Click Ok.
Select the newly created cluster group, then right-click and choose New > Resource.
The first step is create a single, managed IP address to be used for accessing the VirtualCenter cluster.
Note: Make sure that the IP address being assigned has a Host (A) record in the DNS zone.
Enter a name and choose IP Address from the drop-down list. Check the box, Run this resource in a separate Resource Monitor. Click Next three times.
Now enter the IP address to be used for managing access to the VirtualCenter cluster. Pick the appropriate IP address for your VirtualCenter Server (public facing) network and click Finish. Click Ok.
Create another resource per step 5. The Resource Type should be Network Name. Click Next twice.
In the Dependenciesscreen, add the VC Managed IPresource as a dependency. Select the box Run this resource in a separate Resource Monitor. Click Next three times.
Enter the name defined for the Host (A) record in step 6. Check both boxes and click Finish and Ok.
Create another resource for the VirtualCenter service. Choose Generic Service, check the box and click Next twice.
Add the VC Name as its dependency. Enter vpxd as the Service Name and check Use Network Name from computer name. Click Next and Finish and then Ok.
Create a resource for the web service. Choose Generic Service, check the box and click Next twice.
Add the VC Service as its dependency. Enter webAccess as the Service Name and check Use Network Name from computer name. Click Next and Finish and then Ok.
Create the last resource for the license service. Choose Generic Service, check the box and click Next twice.
Add the VC Service as its dependency. Enter VMware License Server as the Service Name and check Use Network Name from computer name. Click Nextand Finish and then Ok.
That will complete the cluster group for the VirtualCenter server and its supporting services.
Lastly, launch the VI client, log into VCNodeA, and enter the managed IP address defined for the VirtualCenter cluster. Click Administration > VirtualCenter Management Server Configuration...from the menu. Select Runtime Settings and enter managed IP address defined in step 7. Click Ok.
Back in the Cluster Administrator application, bring the VC cluster online. Right-click the VC Clustergroup and choose Bring Online.
At this point, the cluster should be online and running.
To test the VirtualCenter cluster, right-click the VC Cluster and choose Move Group. This should take the VCNodeA offline and bring the VCNodeB online.
Log into VirtualCenter with VI client using the managed DNS/IP address defined for the cluster and register the ESX hosts.
Additional Resources
The following are additional links to some documents that can provide additional information and alternatives, such as physical-to-virtual and cluster-across-box configurations. Additionally, there are some links to VMware whitepapers which provided some of the inspiration for this project.
Using MSCS to Cluster VirtualCenter (VirtualCenter 2.0.1 Patch 2)
http://www.vmware.com/pdf/VC_MSCS.pdfGuide to Creating and Configuring a Server Cluster under Windows 2003 [http://www.microsoft.com/downloads/details.aspx?familyid=96F76ED7-9634-4300-9159 -89638F4B4EF7&displaylang=en]
Technical Overview of Windows Server 2003 Clustering Services [http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx]
For guidance on clustering vCenter Server 4.0 using MSCS, please refer to the following document:
Steve Chambers says:
in response to: MB-NS
Thanks - do you have a reference for doing the basic cluster config that you have used before? We could reference that?
MB-NS says:
in response to: Steve Chambers
Well, I didn't set up a cluster on a VM yet, only on physical hosts.
I used the following generic documentation :
The following Technet article is quite comprehensive :
"Guide to Creating and Configuring a Server Cluster under Windows Server 2003 White Paper"
http://technet.microsoft.com/en-us/library/cc778252.aspx
When using VMs, I would read the VMware guide to know how to set up virtual disks for cluster use :
http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_mscs.pdf
NB : The technet article doesn't talk specifically about the case where you use iSCSI : you have then a third network for SAN access. The cluster must be configured not to use that network (in the network properties in Cluster console, uncheck "Enable this network for cluster use").
On physical hosts, using MPIO with the software initiator has worked well for me.
Chris Skinner says:
in response to: MB-NS
Currently, VMware does NOT support MSCS on iSCSI.
Hello,
Thank you for this nice document !
Just a small suggestion : you should drop a line indicating that basic cluster configuration (quorum resource and such) must be done previously.