Designing a VMware 5.5 management cluster

In the past we had our vCenter server on his own physical machine. Later we moved vCenter to a virtual machine on the same cluster were all other virtual machine live.

As we get more, bigger and more VMware techniques in our VMware environments, the need for a separate vSphere cluster for VMware services is growing so we can guarantee that the base for our VMware environment isn’t affected by resource consumption of other (production) virtual machines and  of course the same applies the other way around.

A separate VMware management cluster has the following benefits:

  • Separate management resource from production resources.
  • The management services don’t run on the same hardware as your production environment.
  • In case of a complete power-down situation, you first start you management cluster with all VMware services. If all VMware services are up and running you can start the VMware clusters for your production environment making sure that everything you need for a controlled power-up of you production services is in order.

There are several VMware vSphere and vCenter services who can run in a management cluster:

  • Single-Sing-On (SSO)
  • Inventory Services
  • Web client
  • VMware Update Manager (VUM)
  • vShield
  • Cisco Nexus
  • vCenter Operation Manager (VCOPS)
  • Third-party software for exmple anti-virus
  • Active Directory for authentication

Before we start, we have to ask our self some questions:

  1. Do I want a High Available (HA) setup?
  2. Do I want to use self singed SSL certificates or do I want to use a PKI environment (public or private)?
  3. Witch database do I want to use?
  4. Witch type of load balancer do I want to use?

So let us assume that we want to setup a management cluster with the following:

  • 2 SSO servers in HA mode on separate virtual machines
  • 2 vCenter servers load balanced on separate virtual machines (is this scenario we have to separate vSphere clusters)
  • 2 Web clients load balanced on separate virtual machines
  • 2 MS SQL database servers in HA mode on separate virtual machines

Some rules that we have to stick to:

  • Each vCenter server has his own Inventory Service
  • SSO can only be in active/passive mode
  • Each vCenter server has his own VUM server.

When we apply these rules we get the following design.

Virtual Hike

 

 

 

 

 

 

 

 

 

 

 

 

 

So what do you see here.

Web client
We have two virtual machines running the Web client. These Web clients are behind a load balancer. The load balancer divides the connections equally across the 2 Web client servers. If one Web Client goes down, the other one is still available to manage your VMware environment.

vCenter Server
In this example we have 2 vCenter servers. 1 for a VMware cluster running servers (Exchange, SQL, Etc) and 1 for Horizon View. Nice part is, that both vCenters show up in the same Web Client without linked-mode.

Database
We have 2 Microsoft SQL database servers who are in HA mode with log shipping. This guaranties that if 1 database server goes down, vCenter and other VMware servives (Update Manager) for example still continue to work.

VMware Update Manager
Every vCenter Server needs his own Update Manager. This is a one-on-one connection. To prevent that every VUM server has is own patch repository you can share the repository form one VUM server to the other.

Inventory Services
Same as with VUM, every vCenter server needs his own Inventory server.

So why not place the Inventory Service on the same host a the vCenter server? This way you separate the resources. Inventory is primarily for the Web Client. So to make sure that the Inventory Service doesn’t consume resource from the vCenter server we place them on is own hosts.

So why not place them with the Web Clients? What if you get a third vCenter server. Then you have a problem, because this vCenter server also needs a Inventory Service and you only can run 1 Inventory Service per host.

Single Sign-on
Single Sign-on (SSO) came with vSphere 5 and is your central user authentication mechanism. Single Sign-on can have his own user database or makes a connection to (multiple) other authentications services like Microsoft Active Directory. There for we don’t want only 1 SSO server. If this one fails, nobody can authenticate to vCenter including VUM or other VMware servers as VMware vShield.

SSO can be configured in HA mode, but you have to have a load balancer.

Load Balancer
Most VMware services can be load balanced but they can’t do it by them self. You have to make use of a third-party solution. This can either be a software or a hardware load balancer. Make sure you are aware of the functionality you need. Then pick your load balancer.

Whats missing in this picture?
In this picture we don’t see Microsoft Active Directory services for AD authentication or any other third-party software solutions for example anti-virus. If your going to implement a VMware management cluster it’s very likely that those services also run in the VMware management cluster.

Some resources

About Michael

Michael Wilmsen is a VMware training/consultant (no specific order) with more than 15 years in the IT industry. Main focus is VMware vSphere, Horizon View and Site Recovery Manager with a deepdive to performance.
Michael is VCDX 210, VCAP 4/5 certified, has been rewarded with the vExpert title from 2011, is a PernixPro, Nutanix Tech Champion and a Nutanix Platform Professional.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

You must be logged in to post a comment.