As stated in Chapter 2, previously the vSphere Web Client was not as feature-rich as the traditional vSphere Desktop Client, but since the release of vSphere 5.5, this has changed. When vSphere 5.1 was released, VMware stated it would no longer add features to the vSphere Desktop Client. Since this time VMware have responded to customers wanting to still use the older client. The older Desktop Client for vSphere 5.5 Update 2 and vSphere 6 will allow basic manipulation of VM Hardware Versions 10 and 11, respectively.
As you read through the rest of this book, you can assume that unless I specify the vSphere Desktop Client, the vSphere Web Client is the default choice and the one you should be using.
Providing an Extensible Framework
Just as centralized authentication is not a core vCenter Server service, we don’t include vCenter Server’s extensible framework as a core service. Rather, this extensible framework provides the foundation for vCenter Server’s core services and enables third-party developers to create applications built around vCenter Server. Figure 3.4 shows some of the components that revolve around the core services of vCenter Server.
Figure 3.4 Other applications can extend vCenter Server’s core services to provide additional management functionality.
A key aspect for successful virtualization is the ability to allow third-party companies to provide products that add value, ease, and functionality to existing products. By building vCenter Server in an extensible fashion and providing an application programming interface (API) to it, VMware has shown its interest in allowing third-party software developers to play an integral part in virtualization. The vCenter Server API allows companies to develop custom applications that can take advantage of the virtual infrastructure created in vCenter Server. For example, numerous companies have created backup utilities that work off the exact inventory created inside vCenter Server to allow for advanced backup options of VMs. Storage vendors use the vCenter API to create plug-ins that expose storage details, and other third-party applications use the vCenter Server APIs to provide management, monitoring, life-cycle management, or automation functionality.
You can find more information on vCenter Server functionality in Chapter 10, which provides a detailed look at templates along with VM deployment and management, and in Chapter 8, which goes deeper into vCenter Server’s access controls. Chapter 11 discusses resource management, and Chapter 13 offers an in-depth look at ESXi host and VM monitoring as well as alarms.
You’re almost ready to take a closer look at installing, configuring, and managing vCenter Server. First, however, we’ll discuss how to choose which version of vCenter Server you should deploy in your environment.
Choosing the Version of vCenter Server
As mentioned in the previous section, vSphere 6.0 vCenter Server comes not only as an installable Windows-based application but also as a SUSE Linux–based virtual appliance. As a result, a critical decision you must make as you prepare to deploy vCenter Server is which version you will use. Will you use the Windows Server–based version or the virtual appliance?
There are advantages and disadvantages to each approach:
• If your experience is primarily with Windows Server, you may not be familiar with the Linux underpinnings of the vCenter virtual appliance. This introduces a learning curve that you should consider.
• If you need support for Microsoft SQL Server, the Linux-based vCenter virtual appliance won’t work; you’ll have to deploy the Windows Server–based version of vCenter Server. However, if you are using Oracle, or if you are a small installation without a separate database server, the vCenter Server virtual appliance will work just fine (it has its own embedded Postgres database if you don’t need a separate database server).
• Conversely, if your experience is primarily with Linux or you manage a “Linux only by policy” datacenter, then deploying a Windows Server–based application will require some learning and acclimation for you and/or your staff.
• The Linux-based virtual appliance comes preloaded with additional services like Auto Deploy (covered in Chapter 2), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and syslog. If you need these services on your network, you can provide them with a single deployment of the vCenter virtual appliance. With the Windows Server–based version, these services are separate installations or possibly even separate VMs (or, worse yet, separate physical servers!).
• Because the vCenter Server virtual appliance naturally runs only as a VM, you are constrained to that particular design decision. If you want to run vCenter Server on a physical system, you cannot use the vCenter Server virtual appliance.
As you can see, a number of considerations will affect your decision to deploy vCenter Server as a Windows Server–based installation or as a Linux-based virtual appliance.
My View on the vCenter Virtual Appliance
Some of the early support limitations around the SUSE Linux–based vCenter Server virtual appliance led people to believe that this solution was more appropriate for smaller installations. This may have been because the virtual appliance was certified to support only 5 hosts and 50 VMs or because deploying a virtual appliance that handles all the various services required would appeal more to a smaller implementation. However, VMware has now certified this solution to support up to 1,000 hosts and/or 10,000 VMs, so the former argument is no longer valid. The way I see it, you should always use the right tool for the job (with proper planning), and the vCenter Server virtual appliance is now the right tool for most vCenter jobs.
Something I like to point out when people have concerns with the virtual appliance is that VMware itself uses the vCenter Virtual Appliance internally for large-scale environments. A specific example is that of its Hands-on Labs. Even with this very large environment and intensive workloads, the virtual appliance is used.
In the next section, I’ll discuss some of the planning and design considerations that have to be addressed if you plan to deploy the Windows Server–based version of vCenter Server. Most of these issues apply to the Windows Server–based version of vCenter Server, but some may also apply to the virtual appliance; I’ll point those out where applicable.
Planning and Designing a vCenter Server Deployment
vCenter Server is a critical application for managing your virtual infrastructure. Its implementation should be carefully designed and executed to ensure availability and data protection. When discussing the deployment of vCenter Server and its components, the following questions are among the most common questions to ask:
• How much hardware do I need to power vCenter Server?
• Which database server should I use with vCenter Server?
• How do I prepare vCenter Server for disaster recovery?
• Should I run vCenter Server in a VM and, if so, so I need a separate management cluster?
Many of the answers to these questions are dependent on each other, but we have to start somewhere, so let’s start with the first topic: figuring out how much hardware you need for vCenter Server.
Sizing Hardware for vCenter Server
The amount of hardware that vCenter Server requires is directly related to the number of hosts and VMs it will be managing. This planning and design consideration applies only to the Windows Server–based version of vCenter Server; because it is a prepackaged virtual appliance, the virtual hardware of the vCenter Server virtual appliance is predefined and established before it is deployed.
As a starting point, the minimum hardware