Planning and Designing a vCenter Server Deployment
vCenter Server is a critica1application for managing your virtual infrastructure. Tts implementation should be carefully designed and executed to ensure availability and data protection. When discussing the deployment of vCenter Server, some of the most common questions include the following:
• 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 virtual machine?
A lot of the answers to these questions are dependent upon each other. Still, I have to start somewhere, so I'll start with the first topic: figuring out how much hardware you need for vCenter Server.
Selecting and Sizing Hardware for vCenter Server
The amount of hardware required by vCenter Server is directly related to the number of hosts and virtual machines it will be managing. As a starting point, the vCenter Server minimum hardware requirements are as follows:
• 2GHz processor or faster
• 2GB of RAM or more
• 1GB of free disk space (2GB recommended)
• A network adapter (Gigabit Ethernet strongly recommended)
• Windows Server 2003 Service Pack 1 or Service Pack 2 (x86 or x64), Windows Server 2003 R2 with or without Service Pack 2 (x86 or x64), or Windows Server 2008 (x86 or x64)
Keep in mind these are minimum system requirements. Large enterprise environments with many ESX/ESXi hosts and virtual machines must scale the vCenter Server system accordingly. In addition, these requirements do not account for running a database server, which vCenter Server requires. Although vCenter Server is the application that performs the management of your ESX/ESXi hosts and virtual machines, vCenter Server uses a separate database for storing all of its configuration, permissions, statistics, and other data.
When answering the question of how much hardware vCenter Server requires, you have to address not only the computer running vCenter Server but also the computer running the database server. Although you can run vCenter Server and the database server on the same machine, it's not recommended because it creates a single point of failure for two key aspects of your virtual infrastructure.
CPU Cores
Most modern physical servers ship by default with quad-core CPUs. vCenter Server is able to leverage some of the additional processing power but won't fully utilize all four CPU cores. It's for this reason that our discussion on sizing vCenter Server focuses more on RAM than on CPU capacity.
Throughout this chapter, I'll use the term separate database server to refer to a database server application that is separately installed and managed. Although it might reside on the same computer, it is still considered a separate database server because it is managed independently of vCenter Server. You'll also see the term back-end database, which refers to the actual database that vCenter Server uses on the separate database server.
Without considering the separate database server, VMware suggests a system configured with two CPU cores and 3 GB of RAM to support up to 100 ESX/ESXi hosts and 2,000 virtual machines.
An environment of that size is much larger than a typical environment might be, so it's feasible to simply scale the specifications back to meet your needs. For example, a server with two CPU cores and 2GB of RAM should suffice for up to 50 ESX/ESXi hosts and 1,000 virtual machines. Though it helps to have a good starting point for the deployment of vCenter Server, you can always alter the specifications to achieve adequate performance levels.
Should you choose to run the separate database server on the same physical computer as vCenter Server, you'll need to consult the documentation for whatever database server you choose to use. That brings me to the next topic: choosing which database server to use.
Database Server for vCenter Server
In light of the sensitive and critical nature of the data in the vCenter Server database, VMware supports vCenter Server issues only with back-end databases on enterprise-level database servers. vCenter Server officially supports the following database servers:
• Oracle 109
• Oracle llg
• Microsoft SQL Server 2005 Express Edition (comes bundled with vCenter Server)
• Microsoft SQL Server 2005 with Service Pack 2 (x86 or x64)
• Microsoft SQL Server 2008 (x86 or x64)
IBM DB2 v9.5 is experimentally supported for use with vCenter Server, but not for any other components of VMware vSphere such as vCenter Update Manager or other plug-ins that require database support.
For smaller environments, users have the option of using Microsoft SQL Server 2005 Express Edition. Users should use SQL Server 2005 Express Edition only when their vSphere deployment will be limited in size; otherwise, users should plan on using a separate database server. If you are starting out with a small environment that will work with SQL Server 2005 Express Edition, note that it is possible to upgrade to a more full-featured version of SQL Server at a later date. More information on upgrading SQL Server 2005 Express is available on the Microsoft website (www.microsoft.com).
Because the separate database server is independently installed and managed, some additional configuration is required. Later in this chapter, the section "Installing vCenter Server" provides detailed information about working with separate database servers and the specific configuration that is required for each.
So, how does an organization go about choosing which separate database server to use? The selection of which database server to use with vCenter Server is typically a reflection of what an organization already uses or is already licensed to use. Organizations that already have Oracle may decide to continue to use Oracle for vCenter Server; organizations that are predominantly based on Microsoft SQL Server will likely choose to use SQL Server to support vCenter Server. You should choose the database engine with which you are most familiar and that will support both the current and projected size of the virtual infrastructure.
With regard to the hardware requirements for the database server, the underlying database server will largely determine those requirements. VMware provides some general guidelines around Microsoft SQL Server in the white paper "VirtualCenter Database Performance for Microsoft SQL Server 2005," available on VMware's website at www.vmware.com/files/pdf/vc database performance.pdf. Although written with VirtualCenter 2.5 in mind, this information applies to vCenter Server 4.0 as well. In a typical configuration with standard logging levels, an SQL Server instance with two CPU cores and 4GB of RAM allocated to the database application should support all but the very largest or most demanding environments.
If you are planning on running the database server and vCenter Server on the same hardware, you should adjust the hardware requirements accordingly. Appropriately sizing hardware for vCenter Server and the separate database server is good and necessary. Given the central role that vCenter Server plays in a VMware vSphere environment, though, you must also account for availability.
Planning vCenter Server Availability
Planning for a vCenter Server deployment is more than just accounting for CPU and memory resources. You must also create a plan for business continuity and disaster recovery. Remember, features such as VMware VMotion, VMware Storage VMotion, and VMware DRS - but not VMware HA - stop functioning when vCenter Sever is unavailable. While vCenter Server is down, you won't be able to clone virtual machines or deploy new virtual machines from templates. You also lose centralized authentication and role-based administration of the ESX/ESXi hosts. Clearly, there are reasons why you might want vCenter Server to be highly available.
Keep in mind, too, that the heart of the vCenter Server content is stored in a back-end database on Oracle or SQL Server. Any good disaster recovery or business continuity plan must also include instructions on how to handle data loss or corruption in the backend database, and the separate database server should be designed and deployed in a resilient and highly available fashion. This is especially true in larger environments.
There are a few different ways to approach this concern. First, I'll discuss how to protect vCenter Server, and then I'll talk about protecting the separate database server. First, VMware vCenter Server Heartbeat-a product that VMware released for VirtualCenter/vCenter Server 2.5 to provide high availability with little or no downtime-will be available with support for vCenter Server 4.0 upon the release of VMware vSphere or shortly thereafter. Using vCenter Server Heartbeat will automate both the process of keeping an active and passive vCenter Server instance synchronized and the process of failing over from one to another (and back again).
Virtualizing vCenter Server
Another option for vCenter Server is to install it into a virtual machine. Though you might hesitate to do so, there are really some great advantages to doing this. The most common concern is the misconception that losing the vCenter Server computer causes a domino effect resulting in losing the functionality of VMware HA. The truth, however, is that HA is an advantage to virtualizing the vCenter Server machine because VMware HA continues to function even if vCenter Server is unavailable. In addition to taking advantage of the HA feature, vCenter Server installed as a virtual machine offers increased portability, snapshot functionality, and cloning functionality (though not in the traditional sense).
Although there are advantages to installing vCenter Server in a virtual machine, you should also understand the disadvantages. Features such as cold migration, cloning, and editing hardware are not available for the virtual machine running vCenter Server.
If the vCenter Server computer is a physical server, one way to provide availability is to create 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 computer. In this approach, you'll need to find mechanisms to keep the primary and secondary/ standby vCenter Server systems synchronized with regard to file system content and configuration settings.
A variation on that approach is to keep the standby vCenter Server system as a virtual machine. 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.
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. The installation of vCenter Server is not a time-consuming process. Ultimately, the most important part of the vCenter Server recovery plan is to ensure that the database server is redundant and protected.
For high availability of the database server supporting vCenter Server, you can configure the back-end database on an SQL Server cluster. Figure 3.4 illustrates using an SQL
Server cluster for the back-end database. This figure also shows a standby vCenter Server system. Methods used to provide high availability for the database server are in addition to whatever steps you might take to protect vCenter Server itself. Other options might include using SQL log shipping to create a database replica on a separate system. If using clustering or log shipping database replication is not available or is not within fiscal reach, you should strengthen your database backup strategy to support easy recovery in the event of data loss or corruption. Using the native SQL Server tools, you can create a backup strategy that combines full, differential, and transaction log backups. This strategy allows you to restore data up to the minute when loss or corruption occurred.
The suggestion of using a virtual machine as a standby system for a physical computer running vCenter Server naturally brings me to the last topic: should you run vCenter Server in a virtual machine?
Installing and running vCenter Server in a Virtual Machine
Instead of running a standby clone of vCenter Server as a virtual machine, you also have the option of skipping a physical server entirely and running vCenter Server as a virtual machine from the beginning. This gives you several advantages, including snapshots, VMotion, and VMware HA.
At a high level, snapshot functionality gives you the ability to return to a specific point in time for your virtual machine, in this case, your vCenter Server virtual machine, specifically.
VMotion gives you the portability required to move the server from host to host without experiencing server downtime. VMware HA restarts the vCenter Server automatically if the physical host on which it is running fails. But what happens when a snapshot is corrupted or the virtual machine is damaged to the point it will not run? With vCenter Server as your virtual machine, you can make regular copies of the virtual disk file and keep a "clone" of the server ready to go in the event of server failure. The clone will have the same system configuration used the last time the virtual disks were copied. Given that the bulk of the data processing by vCenter Server ends up in a back-end database running on a different server, this should not be very different.
If vCenter Server is a virtual machine, its virtual disk file can be copied regularly and used as the hard drive for a new virtual machine, effectively providing a point-in-time restore in the event of complete server failure or loss.
By now, you have a good understanding of the importance of vCenter Server in a large enterprise environment and some of the considerations that go into planning for a vCenter Server deployment. You also have a good idea of the features, functions, and role of vCenter Server. With this information in mind, let's install vCenter Server.