High Availability in a vCloud Director Environment

 

Making sure your cloud is accessible, at all time,  to end users and administrators is an important task. When looking into a cloud based on VMware vCloud Director there are several things to take into consideration. A VMware vCloud can consist of a lot of components. The mandatory components are the following

• VMware vCenter Server (Typically Windows 2008/2012 or Linux Appliance)
• VMware ESXi hosts
• VMware vShield Manager (Linux Appliance)
• VMware Director cell (Red Hat Enterprise Linux)
• Database Server for vCenter and vCloud Director

Optional Components

• vCenter Chargeback
• vCenter Operations Manager
• vCloud Automation Center
• VMware Orchestrator
• …

You have to think about how you want to protect the mandatory and optional components. I will focus on the mandatory now.

VMware vCenter Server

There are different ways to protect the vCenter Server. But before you think about protection you need to think about how you are going to deploy it. Your first option is am I going with the Windows version or going with the Linux appliance. In most cases people go for the Windows version, and that is definitely the safe bet. One of the things the Linux appliance has against it is only support for external Oracle databases. No MS SQL support.

If you choose the Windows version you have to consider if you are a splitting the vCenter roles up on multiple virtual machines. The roles you are considering are the following: SSO, Inventory Service, vCenter Service and Update Manager. For best performance and scalability you would split it up. But that also means you have to consider how to protect each server.

SSO has its own “clustering” functionality. But Inventory Service and vCenter does not. In most situations the software is installed inside a virtual machine running on a ESXi host with VMware HA enabled. This means you don’t need to worry about physical server failure. But it does not protect you against a failure on the software side that could be related to the Operating System or vCenter itself. If you figure out you want to go beyond hardware failure your only option is to deploy VMware vCenter Heartbeat. Heartbeat is able to protect all servers running SSO, Inventory Service and vCenter Service. It does it by replicating the server to another virtual or physical machine. Heartbeat is the tool if you have very strict SLA agreements. It will make your system more secure, but it will be on the cost of losing simplicity.

ESXi hosts

The ESXi hosts are the easiest to protect, and you don’t have to do a lot of planning in this area. Just make sure you have multiple ESXi hosts. All connected to the same network and access to the same shared storage. This way the virtual machines can gets it compute resources from any host in the cluster. On that cluster you will enable the DRS and HA functionality. I would not even worry about backing up the ESXi hosts. If you lose a host just reinstall it.

VMware vShield Manager

The vShield Manager comes as a virtual appliance from VMware. You simply download it and import into your management cluster. There is no native clustering functionality so you have to rely on VMware HA or VMware Fault Tolerance.

VMware Director Cell

The vCloud Director software has to be installed on a Linux machine running Red Hat Enterprise. Luckily for us the software has its own clustering functionality. What you basically do is install multiple Red Hat machines. All of these machine will share the same database on MS SQL or Oracle and the will also have access to the same NFS share. When implementing multiple vCloud Director Cells you would deploy the behind a load balancer. That load balancer could be VMware vShield Edge or you could use something else like Netscaler, F5 etc.

Database Server

The database server is extremely critical in the vCloud Environments. If we are only looking at the mandatory components you will have created three databases on your server. One for the SSO service, One for the vCenter Service and One for the vCloud Director Cell.

What you would normally do with your database is to look into clustering the MS SQL or Oracle with its own tools. If you don’t want to cluster the database. At least make sure that it is running as a virtual machine so you get the benefit of VMware HA. And of course remember to backup all databases at a regular interval.

If you are using a MS SQL cluster you have to know that it is not “officially” supported by VMware for the SSO service. Although they will do their best to help you if you have problems. I have installed all of the components against a MS SQL Cluster and haven’t experienced any problems yet. But we aware of this and set it as a risk.