vCenter Server Deployment Decisions
VMware vCenter Server is essentially the hub of
vSphere 5, the "key to the door" in terms of it unlocking and
unleashing the real power behind virtualisation - as well as being
a central point of management and licensing, so many features of
vSphere are only available when vCenter Server is part of the
deployment:
- vMotion
- Storage vMotion
- Distributed Resource Scheduler (DRS)
|
- Distributed Power Management (DPM)
- High Availability (HA)
- Fault Tolerance (FT)
|
In addition to these key vSphere features,
many additional VMware services and products also make use of
vCenter Server:
- vCenter Converter
- vCenter Update Manager
- Site Recovery Manager
|
- View
- vCenter Lab
Manager
- vCloud Director
|
Third-party products sold by companies such
as Veeam, Quest, and Symantec are written to interface with vCenter
Server to facilitate enriched management, monitoring and
maintenance of a vSphere environment.
vCenter Server runs as a collection of
services on a Windows system, typically a Windows server operating
system such as Windows Server 2003 or 2008, and those services
interface with an external database, most commonly a Microsoft SQL
Server database.
There are numerous deployment decisions
that need to be made prior to the deployment of vCenter Server, and
there are no hard rules or best practices as to how these decisions
should be made:
- Should I run vCenter Server on a physical
or virtual Windows system?
- Where should I host the database used by
vCenter Server?
- Should I join the Windows system that will
run vCenter Server to an Active Directory domain?
This paper will explore each of the above
deployment decisions and discuss the relative merits of the various
choices that can be made prior to deployment, such that an
organisation can make the best choice for their environment to
achieve the most suitable vCenter Server deployment.