vSphere Design Best Practices
Apply industry-accepted best practices to design
reliable high-performance datacenters for your
professional expertise distilled
P U B L I S H I N G
BIRMINGHAM - MUMBAI
vSphere Design Best Practices
Copyright © 2014 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, without the prior written
permission of the publisher, except in the case of brief quotations embedded in
critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy
of the information presented. However, the information contained in this book is
sold without warranty, either express or implied. Neither the authors, nor Packt
Publishing, and its dealers and distributors will be held liable for any damages
caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the
companies and products mentioned in this book by the appropriate use of capitals.
However, Packt Publishing cannot guarantee the accuracy of this information.
First published: May 2014
Production Reference: 1200514
Published by Packt Publishing Ltd.
35 Livery Street
Birmingham B3 2PB, UK.
Cover Image by Abhishek Dhir (email@example.com)
Muhammad Zeeshan Munir
Content Development Editor
About the Authors
Brian Bolander spent 13 years on active duty in the United States Air Force. A
veteran of Operation Enduring Freedom, he was honorably discharged in 2005. He
immediately returned to Afghanistan and worked on datacenter operations for the
US Department of Defense (DoD) at various locations in southwest Asia. Invited
to join a select team of internal consultants and troubleshooters responsible for
operations in five countries, he was also the project manager for what was then the
largest datacenter built in Afghanistan.
After leaving Afghanistan in 2011, he managed IT operations in a DoD datacenter
in the San Francisco Bay Area. His team was responsible for dozens of multimillion
dollar programs running on VMware and supporting users across the globe.
He scratched his adrenaline itch in 2011 when he went back "downrange", this
time directing the premier engineering and installation team for the DoD in
Afghanistan. It was his privilege to lead this talented group of engineers who were
responsible for architecting virtual datacenter installations, IT project management,
infrastructure upgrades, and technology deployments on VMware for the entire
country from 2011 to 2013.
Selected as a vExpert in 2014, he is currently supporting Operation Enduring
Freedom as a senior virtualization and storage engineer.
He loves his family, friends, and rescue mutts. He digs science, technology, and geek
gear. He's an audiophile, a horologist, an avid collector, a woodworker, an amateur
photographer, and a virtualization nerd.
Christopher Kusek had a unique opportunity presented to him in 2013, to take
the leadership position responsible for theater-wide infrastructure operations
for the war effort in Afghanistan. Leveraging his leadership skills and expertise
in virtualization, storage, applications, and security, he's been able to provide
enterprise-quality service while operating in an environment that includes the real
and regular challenges of heat, dust, rockets, and earthquakes.
He has over 20 years' experience in the industry, with virtualization experience
running back to the pre-1.0 days of VMware. He has shared his expertise with
many far and wide through conferences, presentations, #CXIParty, and sponsoring
or presenting at community events and outings whether it is focused on storage,
VMworld, or cloud.
He is the author of VMware vSphere 5 Administration Instant Reference, Sybex, 2012,
and VMware vSphere Performance: Designing CPU, Memory, Storage, and Networking for
Performance-Intensive Workloads, Sybex, 2014. He is a frequent contributor to VMware
Communities' Podcasts and vBrownbag, and has been an active blogger for over
A proud VMware vExpert and huge supporter of the program and growth of the
virtualization community, Christopher continues to find new ways to outreach
and spread the joys of virtualization and the transformative properties it has on
individuals and businesses alike. He was named an EMC Elect in 2013, 2014, and
continues to contribute to the storage community, whether directly or indirectly,
with analysis and regular review.
He continues to update his blog with useful stories of virtualization and storage and
his adventures throughout the world, which currently include stories of his times in
Afghanistan. You can read his blog at http://pkguild.com or more likely catch him
on Twitter; his twitter handle is @cxi.
When he is not busy changing the world, one virtual machine at a time or Facetiming
with his family on the other side of the world, he's trying to find awesome vegan
food in the world at large or somewhat edible food for a vegan in a war zone.
About the Reviewers
Andy Grant works as a technical consultant for HP Enterprise Services. Andy's
primary focus is datacenter infrastructure and virtualization projects across a
number of industries including government, healthcare, forestry, financial, gas
and oil, and international contracting. He currently holds a number of technical
certifications including VCAP4/5-DCA/DCD, VCP4/5, MCITP:EA, MCSE, CCNA,
Security+, A+, and HP ASE BladeSystem.
Outside of work, he enjoys backcountry camping, playing action pistol sports (IPSC),
and spending time being a goof with his son.
Muhammad Zeeshan Munir is a freelance ICT consultant and solution architect.
He established his career as a system administrator in 2004 and since then has
acquired and executed many successful projects in multimillion ICT industries.
With more than 10 years of experience, he now provides ICT consultancy services
to different clients in Europe. He also works as a system consultant for Qatar
Computing Research Institute. He regularly contributes to different wikis and
produces various video tutorials mostly about different technologies, including
VMware products, Zimbra e-mail services, OpenStack, and Red Hat Linux, which
can be found at http://zee.linxsol.com/system-administration. When he is
doing nothing, he likes to travel around and speak languages such as English, Urdu,
Punjabi, and Italian.
Prasenjit Sarkar is a senior member of the technical staff in VMware Service
Provider Cloud R&D where he provides architectural oversight and technical
guidance to design, implement, and test VMware's Cloud datacenters. You can
follow him on Twitter at @stretchcloud.
He is an author, R&D guy, and a blogger focusing on virtualization, cloud
computing, storage, networking, and other enterprise technologies. He has more
than 10 years' expert knowledge in R&D, professional services, alliances, solution
engineering, consulting, and technical sales with expertise in architecting and
deploying virtualization solutions and rolling out new technology and solution
initiatives. His primary focus is on the VMware vSphere infrastructure and public
cloud using VMware vCloud Suite. One of his other areas of focus is to own the
entire life cycle of a VMware-based IaaS (SDDC), especially vSphere, vCloud
Director, vShield Manager, and vCenter Operations.
He was one of the VMware vExperts in 2012 and 2013 and well known for his
acclaimed virtualization blog http://stretch-cloud.info. He holds certifications
from VMware, Cisco, Citrix, Red Hat, Microsoft, IBM, HP, and Exin. Prior to joining
VMware, he has served other fine organizations such as Capgemini, HP, and GE as a
solution architect and infrastructure architect.
I would like to thank and dedicate this book to my family.
Without their endless and untiring support, this book would
not have been possible.
Support files, eBooks, discount offers and more
You might want to visit www.PacktPub.com for support files and downloads related to
Did you know that Packt offers eBook versions of every book published, with PDF and ePub
files available? You can upgrade to the eBook version at www.PacktPub.com and as a print
book customer, you are entitled to a discount on the eBook copy. Get in touch with us at
firstname.lastname@example.org for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a
range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book
library. Here, you can access, read and search across Packt's entire library of books.
Fully searchable across every book published by Packt
Copy and paste, print and bookmark content
On demand and accessible via web browser
Free Access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access
PacktLib today and view nine entirely free books. Simply use your login credentials for
Instant Updates on New Packt Books
Get notified! Find out when new books are published by following @PacktEnterprise on
Twitter, or the Packt Enterprise Facebook page.
Table of Contents
Chapter 1: Virtual Data Center Design
Virtual Data Center design principles
Designing Virtual Data Center
VMware vCenter components
Choosing a platform for your vCenter server
Using the vCenter server appliance
Sizing your vCenter server
Choosing your vCenter database
vSphere clustering – HA and DRS
Chapter 2: Hypervisor Design
ESXi hardware design
Memory and NUMA considerations
Virtual NUMA (vNUMA) considerations
Considerations for Java virtual machines (JVMs)
Network interface card considerations
Hypervisor storage components
Stateless host design
Scale-Up and Scale-Out designs
Table of Contents
Chapter 3: Storage Design
Chapter 4: Network Design
Chapter 5: Virtual Machine Design
Fibre Channel (FC)
Fibre Channel over Ethernet (FCoE)
Virtual machine filesystems
Local storage considerations
Datastore and cluster design
VMware storage features
Configurable storage features
Configuring the multipathing path selection policy
Introducing vSphere switching
vNetwork Standard Switches (vSS)
vNetwork Distributed Switches (vDS)
Common networking design considerations
Best practices to implement in your design
Implementing Network I/O Control (NIOC)
Providing network redundancy, resiliency, and throughput
Physical switches and adapters
ESXi host hardware
Considerations when using IP storage
Separating your traffic
Validating your storage configurations
Virtual machine resources and templates
Best practices for virtual machines and templates
Over-allocation can be a painful proposition
Physical to virtual migrations
Shares, limits, and reservations
[ ii ]
Table of Contents
Causes of virtual machine performance problems
CPU performance issues
Memory performance issues
Storage performance issues
Network performance issues
Chapter 6: Business Critical Applications
Chapter 7: Disaster Recovery and Business Continuity
Appendix A: vSphere Automation Tools
Special considerations for tier 1 applications
Designing for Microsoft Exchange
Considering Microsoft SQL server
HA, DRS, and vMotion considerations
Ensuring high availability and application resiliency
Enabling CPU Hot Add in vSphere client
The vCenter operations manager dashboard
Other business critical application resources
The benefits of disaster avoidance
Designing backup strategies
Designing for RPO and RTO requirements
Choosing replication technologies
VMware vSphere Replication
Mixing replication solutions
Planning and testing the DR strategy
Introducing VMware vCenter Orchestrator
Introducing VMware vCloud Automation Center
Unified IT service catalog
Advanced Service Designer
Designing for automation and XaaS
[ iii ]
Table of Contents
Appendix B: Certification Resources
VMware Certification Roadmap
Advanced professional exams
VMware vExpert program
VMware Partner Network (VPN) path
Recommended reading, blogs, and podcasts
Exam and study tips
[ iv ]
Welcome to vSphere Design Best Practices, an easy-to-read guide full of hands-on
examples of real-world design best practices. Each topic is explained and placed
in the context of virtual datacenter design.
This book is all about design principles. It isn't about operations or administration;
instead, we focus on designing virtual datacenters to meet business requirements
and leveraging vSphere to get us to robust and highly available solutions.
In this book, you'll learn how to utilize the features of VMware to design, architect,
and operate a virtual infrastructure using the VMware vSphere platform. Readers
will walk away with a sense of all the details and parameters there are for a design
that has been well thought out.
We'll examine how to customize your vSphere infrastructure to fit business needs
and look at specific use cases for live production environments. Readers will become
familiar with new features in Version 5.5 of the vSphere suite and how these features
can be leveraged in design.
Readers will walk away with confidence as they will know what their next steps are
towards accomplishing their goals, whether that be a VCAP-DCD certification or a
sound design for an upcoming project.
What this book covers
Chapter 1, Virtual Data Center Design, gives you an insight into the design and
architecture of the overall datacenter, including the core components of vCenter
Chapter 2, Hypervisor Design, dives into the critical components of the datacenter by
providing the best practices for hypervisor design.
Chapter 3, Storage Design, explains one of the most important design points of the
datacenter—storage. This chapter focuses attention on the design principles related
to the storage and storage protocols.
Chapter 4, Network Design, peels back the layers of networking by focusing on designing
flexible and scalable network architectures to support your virtual datacenter.
Chapter 5, Virtual Machine Design, covers what it takes to inspect your existing
virtual machines and provides guidance and design principles to correctly size
and deploy VMs.
Chapter 6, Business Critical Applications, breaks through the barriers and concerns
associated with business critical applications, allowing business requirements to
translate into a successful and stable deployment.
Chapter 7, Disaster Recovery and Business Continuity, considers the many parameters
that make up a DR/BC design, providing guidance to make sound decisions to
ensure a well-documented and tested disaster recovery policy.
Appendix A, vSphere Automation Tools, briefly discusses the value of automation tools
such as vCenter Orchestrator (vCO) and vCloud Automation Center (vCAC), their
differences, and use cases for your design and implementation.
Appendix B, Certification Resources, gives guidance on the VMware certification
roadmap and lists resources for the Data Center Virtualization (DCV) track.
What you need for this book
As this book is technical in nature, the reader should possess an understanding of the
• Storage technologies (SAN, NAS, Fibre Channel, and iSCSI)
• Networking—both physical and virtual
• VMware vSphere products and technologies such as:
vMotion and Storage vMotion
Cluster capabilities such as High Availability (HA) and Distributed
Resource Scheduler (DRS)
Who this book is for
This book is ideal for those who desire a better understanding of how to design
virtual datacenters leveraging VMware vSphere and associated technologies. The
typical reader will have a sound understanding of VMware vSphere fundamentals
and would have been involved in the installation and administration of a VMware
environment for more than two years.
In this book, you will find a number of styles of text that distinguish between
different kinds of information. Here are some examples of these styles, and an
explanation of their meaning.
Code words in text are shown as follows: "VMware Communities Roundtable
podcast hosted by John Troyer (@jtroyer)."
New terms and important words are shown in bold. Words that you see on the
screen, in menus or dialog boxes for example, appear in the text like this: "You can
adjust your guests' vNUMA configuration on a per-VM basis via Advanced Settings
in order to adjust vNUMA to meet your needs."
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Feedback from our readers is always welcome. Let us know what you think about
this book—what you liked or may have disliked. Reader feedback is important for us
to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to email@example.com,
and mention the book title via the subject of your message. If there is a topic that you
have expertise in and you are interested in either writing or contributing to a book,
see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to
help you to get the most from your purchase.
Although we have taken every care to ensure the accuracy of our content, mistakes
do happen. If you find a mistake in one of our books—maybe a mistake in the text or
the code—we would be grateful if you would report this to us. By doing so, you can
save other readers from frustration and help us improve subsequent versions of this
book. If you find any errata, please report them by visiting http://www.packtpub.
com/submit-errata, selecting your book, clicking on the errata submission form link,
and entering the details of your errata. Once your errata are verified, your submission
will be accepted and the errata will be uploaded on our website, or added to any list of
existing errata, under the Errata section of that title. Any existing errata can be viewed
by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media.
At Packt, we take the protection of our copyright and licenses very seriously. If you
come across any illegal copies of our works, in any form, on the Internet, please
provide us with the location address or website name immediately so that we can
pursue a remedy.
Please contact us at firstname.lastname@example.org with a link to the suspected
We appreciate your help in protecting our authors, and our ability to bring
you valuable content.
You can contact us at email@example.com if you are having a problem with
any aspect of the book, and we will do our best to address it.
Virtual Data Center Design
The datacenter has quite simply become one of the most critical components to
organizations today. Some datacenters, either owned by large enterprises or leased
by large service providers, can contain great amounts of bleeding-edge technologies,
tens of thousands of servers, huge network pipes from multiple carriers, and enough
contingency mechanisms to keep their systems running for months in case of a
disaster. Other datacenters can consist of just a small handful of servers and
off-the-shelf networking gear stuffed in a closet. Every organization is a bit different
and has its own unique set of requirements in order to provide IT services to its
users. As system administrators, engineers, and architects, we need to be able to take
those requirements, sometimes even search for or define them, and design a solution
to meet or exceed those requirements.
As datacenters have evolved, we've seen a paradigm shift towards virtualization.
This is due to a number of factors including performance, availability, management,
and recoverability. This book aims to help call attention to these factors and explains
how to address them in your Virtual Data Center designs.
The Virtual Data Center has several key components such as compute, storage,
networking, and management.
We will be covering the following topics in this chapter:
• Core design principles for the Virtual Data Center
• Best Practices for Virtual Data Center design
• How best practices change over time
• Virtual Data Center design scenarios
• vCenter design including the Linux-based vCenter Server Appliance (vCSA)
• vSphere clustering, HA, and DRS
• A consideration of the other components of the vCloud Suite
Virtual Data Center Design
Virtual Data Center design principles
VMware vSphere is a leading platform for virtualization with many components
that make up the VMware vCloud Suite including vCenter Server, ESXi hypervisor,
and Site Recovery Manager (SRM). Through these products, the vSphere platform,
with proper design characteristics, enables an IT infrastructure to provide services,
availability, flexibility, recoverability, and performance that its customers require.
Apart from knowledge of the aforementioned VMware products (or perhaps
any third-party solutions being considered), there are a few key principles to get
started with our designs. While there are numerous methodologies out there,
this is a framework on which you can base your process consisting of three basic
phases—Conceptual Design, Logical Design, and Physical Design, as shown in the
It is important to remember that while the process is important, the focus of this book
is about the design decisions. If you typically subscribe to a different framework or
methodology, that is OK, as the design decisions discussed throughout the book will
hold true regardless of your process and methodology in most cases.
First, create a Conceptual Design by gathering and analyzing business and
application requirements, and then document the risks, constraints, and
assumptions. Once all of the information is gathered and compiled, you should be
able to formulate a high-level end goal, which is ultimately a vision of the solution.
For example, you could have requirements to provide 99.99 percent uptime to an
application, guarantee 2500 IOPS via shared storage, 25 GHz CPU, and 48 GB of
RAM. You could be constrained by a budget of $100,000 among various risks and
assumptions. So, conceptually, you'll have a high-level idea that you'll need a certain
class of compute, storage, and network to support that type of application.
You certainly don't need to know the specifics at this point but you should have a
vision and direction of the goal.
Next, building from the conceptual design, we'll begin formulating the Logical
Design. To do this, we'll begin laying down the logical representations of the
infrastructure components. Why just logical representations? Continuing with the
above example, we don't know what servers we need or how many, we just know
that we need servers. We don't know what storage array we need or what size,
we just know that we need shared storage, and so on. We need to map each of the
requirements to a logical solution within the complete design. This also begins to
flush out dependencies between components and services. While it would be great if
we could jump straight from the conceptual design right to the complete solution, we
should be taking smaller steps towards our goal. This step is all about putting ideas
down on paper and thinking through this Logical Design before we start procuring
hardware and building up the datacenter by trial and error.
Finally, we transition our Logical Design into a Physical Design. While the previous
steps allow us to be somewhat theoretical in our work, this phase absolutely requires
us to do our homework and put specific parameters around our design. For example,
we determine we need six servers with dual 8-core CPUs, 128 GB RAM, 15 TB of
array-based fiber channel attached storage, 4 x 10 Gbe NICs, 2 x 8 Gb Fiber Channel
HBAs, and so on. In most cases, you'll have this detail down to the manufacturer of
each component as well. This physical design should consist of all the infrastructure
components that will be required to support the requirements gathered in the
Conceptual Design phase. For example, a complete Physical Design might include a
vSphere Network Design, Storage Design, Compute Design, Virtual Machine (VM)
Design, and Management Design. As you can imagine, the documentation for a
physical design can get quite large and time consuming, but this is a critical step.
In summary, remember that the three design phases are additive and dependent
upon one another. In order to have a successful Physical Design, both the Conceptual
and Logical Designs must be solid. Document as much as is reasonable in your
designs and even include reasoning behind choices. Many choices seem obvious
while making them; however, when it is time to review and deploy a design months
later, it may not be as obvious as to why certain choices were made.
We hear the term Best practices everywhere but what does it really mean? Do we
always adhere to best practices? What happens to best practices as technology
evolves, or as your business evolves? These are great questions and ones that many
people don't seem to ask. There are three scenarios when addressing a design.
Virtual Data Center Design
You may ignore best practices, strictly follow best practices, or employ a combination
of the two. The third scenario is the most common and should be your target. Why?
The simplified answer is that there are certainly times when best practices aren't in
fact best for your design. A great example is the general best practice for vSphere
where the defaults for just about everything in the environment are acceptable. For
example, take storage multipathing. VMware default is for fixed path and if best
practice is default, you may consider not modifying this; experience shows that often
you'll see performance gains switching to Round Robin (see VMware KB1011340
for details). While changing this default may not be a best practice, then again, "Best
Practice" might not fit your needs in the real world. Choose what works for you and
the constraints of your environment.
Best practices also seem to have a shelf life much longer than intended. A favorite
example is that the best size for vSphere datastore is 500 GB. While this sizing
best practice was certainly true at one time, vSphere has improved how it handles
datastore sizing using features such as SCSI Reservation, which enables much
higher VM per datastore density. Since vSphere 5.0, we've been able to create 64 TB
datastores and the best practice is more about evaluating parameters such as number
of VMs, number of VMDKs per VM, required IOPS, SLAs, fault domains, and
restore capabilities. Many a times the backend disk capabilities will determine the
ideal datastore size. Yet, many customers continue to use 500 GB as their standard
datastore size. There are many more examples but the bottom line is that we should
use best practices as a guideline and then do our homework to determine how to
apply them to our designs.
Along with the best practices and design framework we've already discussed, it is also
important to define and adhere to standards throughout your Virtual Data Center.
This includes items such as naming conventions for ESXi hosts and VMs as well as
IP address schemes, storage layout, network configurations, and security policies.
Adhering to these standards will make understanding the design much easier as well
as help as changes are introduced into the environment after deployment.
Designing Virtual Data Center
As previously mentioned VMware's Virtual Data Center (vDC) is composed of
several key components: vCenter, ESXi hypervisor, CPU, storage, networking, and
virtual machines. Many datacenters will have additional components but these form
the foundation of typical vDC. Note that it is possible to operate, albeit in a limited
capacity, without vCenter in the management layer. We find that it is really the core
of the vDC and enables many features we seem to take for granted, such as vMotion,
DRS (Distributed Resource Scheduling), and HA (High Availability).
Our vDCs will also consist of several constructs that we will leverage in our designs
to provide organization and operability. These include the following:
• Resource pools
By using these constructs, we can bring consistency into complex designs. For
example, by using folders and tags, we can organize VMs, hosts, and other objects so
we can easily find them, report on them, or even perform operations such as backup
based on folders or tags.
Tags are a new feature in vSphere 5.1 and above that work much
like tagging in other applications. It allows us to put arbitrary tags
on objects in our vDC for organizational purposes. Folders present a
challenge when we have objects that could belong in multiple folders
(which isn't possible). Many administrators use a combination of folders
and tags to both organize their inventory as well manage it.
The following screenshot is a specific example of how folders can be used to organize
our vDC inventory:
It is important to define a standard folder hierarchy as part of your design and
include tags into that standard to help organize and manage your infrastructure.
Virtual Data Center Design
Another facet to our designs will be how we might employ multiple vCenters and
how we manage them. Many organizations utilize multiple vCenters because they
want to manage Production, QA, and Test/Dev, separately. Others have vCenters
distributed geographically with a vCenter managing each local infrastructure. In
any case, with vSphere 5.5, multiple vCenter management has become much easier.
We have what is called Linked Mode as an option. This allows us to provide a
single pane of access to resources connecting to multiple vCenters—think shared
user roles/groups and being able to access objects from any vCenters that are linked
through a single console. However, with the vSphere web client included with
vSphere 5.1 and above, we are able to add multiple vCenters to our view in the
client. So, if your requirements are to have less roles and groups to manage, then
Linked Mode may be the best route. If your requirements are to be able to manage
multiple vCenters from a single interface, then the standard vSphere web client
should meet your needs without adding the complexity of Linked Mode.
Next, we have Single sign-on (SSO). This is a new feature introduced in vSphere 5.1
and improved in vSphere 5.5. Previously, SSO had a difficult installation process and
some difficult design decisions with respect to HA and multisite configurations. With
SSO in vSphere 5.5, VMware has consolidated down to a single deployment model,
so we're able to much more easily design HA and multisite configurations because
they are integrated by default.
Finally, there is the subject of SSL certificates. Prior to vSphere 5.0, it was a best
practice (and a difficult task) to replace the default self-signed certificates of the
vSphere components (vCenter, ESX, and so on) with CA-signed certificates. That
remains the case, but fortunately, VMware has developed and released the vCenter
Certificate Automation tool, which greatly reduces the headaches caused when
attempting to manually generate and replace all of those SSL certificates. Although
not a steadfast requirement, it is certainly recommended to include CA-signed
certificates in your designs.
VMware vCenter components
There are four primary components to vCenter 5.1 and 5.5:
• Single sign-on: This provides identity management for administrators and
applications that interact with the vSphere platform
• vSphere web client: This is the service that provides the web-based GUI for
administrators to interact with vCenter and the objects it manages
• vCenter inventory service: This acts as a cache for vCenter managed objects
when accessed via the web client to provide better performance and reduce
lookups to the vCenter database
[ 10 ]
• vCenter server: This is the core service of vCenter, which is required by all
There are also several optional components and support tools, which are as follows:
• vSphere client: This is the "legacy" C#-based client that will no longer be
available in the future versions of vSphere (although still required to interact
with vSphere Update Manager)
• vSphere Update Manager (VUM): This is a tool used to deploy upgrades
and patches to ESXi hosts and VMware tools and virtual hardware version
updates to VMs
• vSphere ESXi Dump Collector: This is a tool used mostly to configure
stateless ESXi hosts (that is, have no local storage) to dump VMkernel
memory to a network location and then pull those logs back into vCenter
• vSphere Syslog Collector: This is a tool similar to the Dump Collector
that allows ESXi system logs to be redirected to a network location and be
accessed via vCenter
• vSphere Auto Deploy: This is a tool that can provision ESXi hosts over the
network and load ESXi directly into memory allowing for stateless hosts and
• vSphere Authentication Proxy: This is a service that is typically used with
Auto Deploy so that hosts can be joined to a directory service, such as MS
Active Directory, without the need to store credentials in a configuration file
At the onset of your design, these components should be accounted for (if used)
and integrated into the design. For small environments, it is generally acceptable
to combine these services and roles on the vCenter while larger environments will
generally want to separate these roles as much as possible to increase reliability
by reducing the fault domain. This ensures that the core vCenter services have the
resources they need to operate effectively.
Choosing a platform for your vCenter server
Now that we've reviewed the components of vCenter, we can start looking at
making some design decisions. The first design decision we'll need to make relative
to vCenter is whether you'll have a physical or virtual vCenter. VMware's own
recommendation is to run vCenter as a VM. However, just as with best practices,
we should examine and understand why before making a final decision. There are
valid reasons for having a physical vCenter and it is acceptable to do. However, if
we make the appropriate design decisions, a virtual vCenter can benefit from all the
flexibility and manageability of being a VM without high amounts of risk.
[ 11 ]
Virtual Data Center Design
One way to mitigate risks is to utilize a Management Cluster (sometimes called
a management pod) with dedicated hosts for vCenter, DNS, Active Directory,
monitoring systems, and other management infrastructure. This benefits us in a few
ways such as being able to more easily locate these types of VMs if vCenter is down.
Rather than connecting to multiple ESXi hosts via Secure Shell (SSH) or using the
vSphere Client to connect to multiple hosts in order to locate a domain controller
to be manually powered on, we're able to identify its exact location within our
management pod. Using a management cluster is sometimes not an option due to the
cost of a management pod, separate vCenter server for management, and the cost of
managing a separate cluster. In smaller environments, it isn't such a big deal because
we don't have many hosts to go searching around for VMs. But, in general,
a dedicated cluster for management infrastructure is recommended.
A second way to mitigate risks for vCenter is to use a product called vCenter
Heartbeat. VMware vCenter Heartbeat provides automated and manual failover
and failback of your vCenter Server and ensures availability at the application and
service layer. It can restart or restore individual services while monitoring and
protecting the Microsoft SQL Server database associated with vCenter Server, even
if it's installed on a separate server. For more information on vCenter Heartbeat,
you can go to the product page at http://www.vmware.com/products/vcenterserver-heartbeat/.
In general, if choosing a virtual vCenter, do everything possible to ensure that the
vCenter VM has a high priority with resources and HA restarts. An option would
be to set CPU and memory resource shares to High for the vCenter VM. Also, do
not disable DRS or use host affinity rules for the vCenter VM to try to reduce its
movement within the vDC. This will negate many of the benefits of having a
Using the vCenter server appliance
Traditionally, this decision hasn't really required much thought on our part. The
vCenter Server Appliance (vCSA or sometimes called vCVA or vCenter Virtual
Appliance) prior to vSphere 5.5 was not supported for production use. It also had a
limit of managing five hosts and 50 VMs. However, with vSphere 5.5, vCSA is fully
supported in production and can manage 1000 hosts and 10000 VMs. See vSphere
5.5 Configuration Maximums at http://www.vmware.com/pdf/vsphere5/r55/
[ 12 ]