vSphere Design Best Practices Free ebook download

  

vSphere Design Best Practices

Apply industry-accepted best practices to design reliable high-performance datacenters for your business needs Brian Bolander Christopher Kusek 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.

  Livery Place

  35 Livery Street Birmingham B3 2PB, UK.

  ISBN 978-1-78217-626-8

   abhishekdhirimages@gmail.com

  Cover Image by Abhishek Dhir ( )

  

Credits

Authors Project Coordinator

  Brian Bolander Melita Lobo Christopher Kusek Proofreader

  Simran Bhogal Reviewers

  Andy Grant Indexers

  Muhammad Zeeshan Munir Mariammal Chettiyar Prasenjit Sarkar Tejal Soni

  Commissioning Editor Graphics Rebecca Youe Valentina Dsilva

  Abhinash Sahu Acquisition Editor

  Meeta Rajani Production Coordinator

  Alwin Roy Content Development Editor

  Sharvari Tawde Cover Work

  Alwin Roy Technical Editors

  Rosmy George Manal Pednekar Copy Editor

  Laxmi Subramanian

  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

  , Sybex, 2014. He is a frequent contributor to VMware

  Performance-Intensive Workloads

  Communities' Podcasts and vBrownbag, and has been an active blogger for over a decade. 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

  @cxi on Twitter; his twitter handle is .

  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

  

   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

  @stretchcloud follow him on Twitter at .

  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

  

   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. www.PacktPub.com Support files, eBooks, discount offers and more You might want to visit your book.

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 service@packtpub.com 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.

_TM http://PacktLib.PacktPub.com 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.

  Why Subscribe?

• 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 immediate access.

  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

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  Table of Contents

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

[ ]

  Table of Contents

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

[ ]

  Table of Contents

  

  

  

  

  

  

  

[ ]

  Preface

  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 and ESXi.

  

Chapter 2 , Hypervisor Design, dives into the critical components of the datacenter by

providing the best practices for hypervisor design.

  Preface

  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.

  , Virtual Machine Design, covers what it takes to inspect your existing

  Chapter 5

  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.

  , Disaster Recovery and Business Continuity, considers the many parameters

  Chapter 7

  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 following concepts:

• Storage technologies (SAN, NAS, Fibre Channel, and iSCSI)
• Networking—both physical and virtual
• VMware vSphere products and technologies such as:

  ° Hypervisor basics

  ° vMotion and Storage vMotion °

  Cluster capabilities such as High Availability (HA) and Distributed Resource Scheduler (DRS)

  

[ ]

  Preface 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.

  Conventions

  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.

  Reader feedback

  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 feedback@packtpub.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,

   .

  

[ ]

  Preface Customer support

  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.

  Errata

  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

  

  , 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

  Piracy 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.

  copyright@packtpub.com

  Please contact us at with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content.

  Questions questions@packtpub.com

  You can contact us at 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 following diagram:

  Physical Design Logical Design

  Conceptual Design

  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.

  

[ ]

Chapter 1 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.

  Best practices

  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).

  

[ ]

Chapter 1 Our vDCs will also consist of several constructs that we will leverage in our designs

  to provide organization and operability. These include the following:

• Datacenters • Clusters • Resource pools
• Folders • Tags 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

  

[ ]

• vCenter server: This is the core service of vCenter, which is required by all other components
• 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 efficient provisioning
• vSphere Authentication Proxy: This is a service that is typically used with

  [ ]

  There are also several optional components and support tools, which are as follows:

  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.

  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,

  

  

  

  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 virtual vCenter.

  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/

  

  

[ ]

Chapter 1 So why would we want to use an appliance versus a full Windows VM? The

  appliance is Linux-based and comes with an embedded vPostgres, which will support up to 100 hosts and 3000 VMs. In order to scale higher, you need to use an external Oracle database server. Environments can save on Windows and MS SQL licensing by leveraging the vCSA. It is also a much simpler deployment. There are a few caveats, however, in that VMware Update Manager (VUM) still requires a separate Windows-based host with an MS SQL database as of vSphere 5.5. If you are running Horizon View, then you'll need a Windows server for the View Composer service and a similar situation exists if you are running vCloud Director. The general idea, though, is that the vCSA is easier to manage and is a purpose-built appliance. While vCSA may not be for everyone, but I would encourage you to at least consider it for your designs.

  Sizing your vCenter server

  If you're using the vCSA, this is less of an issue but there are still guidelines for disk space and memory as shown in the following table. Note that this only applies to vCSA 5.5 and above as the vCSA prior to 5.5 is only supported with a maximum of five hosts and 50 VMs.

  VMware vCenter Server Requirement Appliance Hardware Disk storage on the host The vCenter Server Appliance requires at least 7 GB of disk

machine space, and is limited to a maximum size of 80 GB. The vCenter

  Server Appliance can be deployed with thin-provisioned virtual disks that can grow to the maximum size of 80 GB. If the host machine does not have enough free disk space to accommodate the growth of the vCenter Server Appliance virtual disks, vCenter Server might cease operation, and you will not be able to manage your vSphere environment.

  Memory in the VMware

• Very small (≤ 10 hosts, ≤ 100 virtual machines): This vCenter Server Appliance has a size of at least 4 GB.
• Small (10-100 hosts or 100-1000 virtual machines): This has a size of at least 8 GB.
• Medium (100-400 hosts or 1000-4000 virtual machines): This has a size of at least 16 GB.
• Large (≥ 400 hosts or 4000 virtual machines): This has

  a size of at least 24 GB.

  

Source: VMware KB 2052334

[ ]

  Virtual Data Center Design

  If you are choosing a Windows-based vCenter, you need to size your machine appropriately based on the size of your environment. This includes CPU, memory, disk space, and network speed/connectivity.

  

The number of clusters and VMs within a vCenter can absolutely

affect performance. This is due to DRS calculations that must be made

and more objects mean more calculations. Take this into account

when estimating resource requirements for your vCenter to ensure performance and reliability.

  It is also recommended to adjust the JVM (Java Virtual Machine) heap settings for the vCenter Management Web service (tcServer), Inventory Service, and Profile-driven Storage Service based on the size of deployment. Note that this only affects vCenter 5.1 and above.

  The following VMware KB articles have up-to-date information for your specific vCenter version and should be referenced for vCenter sizing:

  vCenter version

  VMware KB article number 5.0 2003790 5.1 2021202 5.5 2052334

  Choosing your vCenter database

  The vCenter database is the location where all configuration information, along with some performance, task, and event data, is stored. As you might imagine, the vCenter DB can be a critical component to your virtual infrastructure. But it also can be disposable—although this is becoming a much less adopted strategy than it was a couple of years ago. In some environments that weren't utilizing features like the Virtual Distributed Switch (VDS) and didn't have a high reliance on the stored event data, we saw that vCenter could be quickly and easily reinstalled from scratch without much of an impact. In today's vDC's, however, we see more widespread use of VDS and peripheral VMware technologies that make the vCenter DB much more important and critical to keep backed up. For example, the VDS configuration is housed in the vCenter DB, so if we were to lose the vCenter DB, it becomes difficult and disruptive to migrate those hosts and their VMs to a new vCenter.

  

[ ]

Chapter 1 There are two other components that require a DB in vCenter and those are VUM

  and SSO. SSO is a new component introduced in vSphere 5.1 and then completely rewritten in vSphere 5.5. If you haven't deployed 5.1 or 5.5 yet, I'd strongly encourage you to go to 5.5 when you're ready to upgrade due to this re-architecture of SSO. In vSphere 5.1, the SSO setup requires manual DB configuration with SQL authentication and JDBC SSL, which caused many headaches and many support tickets with VMware support during the upgrade process.

  We have the following choices for our vCenter DB:

• MS SQL Express • MS SQL
• IBM DB2
• Oracle The different versions of those DBs are supported depending on the version of vCenter you are deploying, so check the VMware Product Interoperability Matrixes located at

  

  The MS SQL Express DB is used for small deployments—maximum of five hosts and

50 VMs—and is the easiest to set up and configure. Sometimes, this is an option for dev/test environments as well.

  Next, we have probably the most popular option, that is, MS SQL. MS SQL can either be installed on the vCenter itself, but it is recommended to have a separate server dedicated to SQL. Again, sometimes in smaller deployments, it is OK to install the SQL DB on the vCenter server, but the general best practice is to have that dedicated database server for better protection, flexibility, and availability. With vCenter 5.5, we now have broader support of Windows Failover Clustering (formerly Microsoft Cluster Services or MSCS), which enhances our options for the availability of the vCenter DB.

  Last, we have Oracle and IBM DB2. These two options are common for organizations that already have these databases in use for other applications. Each database type has its own benefits and features. Choose the database that will be the easiest to manage while providing the features that are required. In general, any of the database choices are completely capable of providing the features and performance of vCenter.

  

[ ]

  Virtual Data Center Design vSphere clustering – HA and DRS

  Aside from vCenter itself, HA and DRS are two features that help unlock the true potential of virtualization. This combination of automatic failover and workload balancing result in more effective and efficient use of resources. The mechanics of HA and DRS are a full topic in and of itself, so we'll focus on how to design with HA and DRS in mind.

  The following components will be covered in this section:

• Host considerations
• Networking design considerations
• Storage design considerations
• Cluster configuration considerations
• Admission control

  Host considerations