Information Technology Reference
In-Depth Information
and Its Components as VMs”). While HA is certainly an option for protecting the Inventory
Service, unfortunately Fault Tolerance is not because the hardware requirements for this server
state the need for two cores, as does SSO.
While the data that the Inventory Service stores is not as important as that in the SSO or
vCenter itself, the Inventory Service still needs to be available for vCenter to function and there-
fore you must consider a plan on how to keep downtime to a minimum. Like SSO, the Inventory
Service installs with a backup script within its installation directory. To use this feature, run the
following command from the Inventory Service server:
vCenter_Server_installation_directory
\Infrastructure\Inventory Service\scripts\backup.bat -
file
backup_file_name
As stated earlier, the data that the Inventory Service holds locally is not as mission critical as
the data SSO or vCenter holds. If you were in the position that your Inventory Service needed to
be reinstalled and you had no backup to restore, you would only lose the tags metadata (tags are
explained later in this chapter).
Protecting vCenter Server
First, vCenter Server Heartbeat—a product available from VMware since VirtualCenter/vCen-
ter Server 2.5 to provide high availability with little or no downtime—will be available with
support for vCenter Server 5.5 upon release or shortly after the release of vSphere 5.5 (vCenter
Server 5.5). Using vCenter Server Heartbeat will automate both the process of keeping the active
and passive vCenter Server instances synchronized and the process of failing over from one to
heartbeat
has m
ore information on vCenter Server Heartbeat.
If the vCenter Server computer is a physical server, one way to provide availability is to cre-
ate a standby vCenter Server system that you can turn on in the event of a failure of the online
vCenter Server computer. After failure, you bring the standby server online and attach it to the
existing SQL Server database, and then the hosts can be added to the new vCenter Server com-
puter. In this approach, you'll need to i nd mechanisms to keep the primary and secondary/
standby vCenter Server systems synchronized with regard to i le system content and coni gu-
ration settings. The use of the Linux-based virtual appliance might make this approach easier
because it is a VM; it therefore can be cloned (a process you'll see in more detail in Chapter 10).
A variation on that approach is to keep the standby vCenter Server system as a VM. You can
use physical-to-virtual (P2V) conversion tools to regularly “back up” the physical vCenter Server
instance to a standby VM. This method reduces the amount of physical hardware required
and leverages the P2V process as a way of keeping the two vCenter Servers synchronized.
Obviously, this sort of approach is viable for a Windows Server-based installation on a physical
system but not applicable to the virtual appliance version of vCenter Server.
As a last resort for recovering vCenter Server, it's possible to just reinstall the software, point
to the existing database, and connect the host systems. Of course, this assumes that the database
is housed on a separate system from vCenter Server itself. The installation of vCenter Server is
not a time-consuming process. Ultimately, the most important part of the vCenter Server recov-
ery plan is to ensure that the database server is redundant and protected.
