Information Technology Reference
In-Depth Information
Appropriately sizing hardware for vCenter Server and the separate database server is good
and necessary. Given the central role that vCenter Server plays in a vSphere environment,
though, you must also account for availability.
Planning for vCenter Server Availability
Planning for a vCenter Server deployment is more than just accounting for CPU and memory
resources. You must also create a plan for business continuity and disaster recovery. Remember,
features such as vSphere vMotion, vSphere Storage vMotion, vSphere DRS, and to a certain
extent vSphere HA stop functioning or are signii cantly impacted when vCenter Server is
unavailable. While vCenter Server or any component it depends on is down, you won't be able
to clone VMs or deploy new VMs from templates. You also lose centralized authentication and
role-based administration of the ESXi hosts. Clearly, there are reasons why you might want
vCenter Server to be highly available.
Keep in mind, too, that the heart of the vCenter Server and its components are stored in
backend databases. Any good disaster-recovery or business-continuity plan must also include
instructions on how to handle data loss or corruption in the backend databases, and the separate
database server(s)—if running on a separate physical computer or in a separate VM—should
be designed and deployed in a resilient and highly available fashion. This is especially true in
larger environments.
There are a few different ways to approach this concern. First, we'll discuss how to protect
the vCenter Server components, then the vCenter Server itself, and i nally we'll talk about pro-
tecting the separate database server.
Protecting Single Sign-On
Single Sign-On is an integral part of vCenter Server. Without it there is no ability to log in and
administer vCenter. Therefore, it is imperative that your protection strategy for the whole of
vCenter Server (and it's components) covers vCenter Single Sign-On. There are three methods for
ensuring you have an SSO instance available to you with little or no downtime: deploying in a
High Availability cluster, deploying to multiple sites, and having a solid backup plan.
During the SSO installation, you have the ability to join an existing deployment and coni gure
a High Availability (HA) cluster. With this coni guration, all SSO instances must sit behind a load
balancer. Deploying SSO in this way protects you from an outage of the SSO application or server.
The other installation option for SSO is called Multisite. This mode lets you install SSO with
multiple physical locations. While this is usually deployed when you need to be able to sign in
from multiple locations, it can also be used to facilitate a protection mechanism.
To save the time of redeploying and restoring a backup, if your SSO server is a VM, you can
also regularly clone this VM to serve as a recovery point. This, however, is no substitute for a
properly coni gured, company-wide backup solution that covers the SSO deployment.
Protecting the Inventory Service
VMware doesn't provide any type of built-in High Availability, but you can always run the
Inventory Service on an HA-enabled vSphere cluster (see the section “Running vCenter Server
