Книга: Mastering VMware® Infrastructure3

Planning a VirtualCenter Deployment

Planning a VirtualCenter Deployment

When discussing the deployment of VirtualCenter, some of the most common topics include:

? How much hardware do I need to power VirtualCenter?

? How do I prepare VirtualCenter for disaster recovery?

? Should I run VirtualCenter in a virtual machine?

The amount of hardware required by VirtualCenter is directly related to the number of hosts and virtual machines it will be managing. 

The operating system running VirtualCenter has a maximum memory limit of 4GB: 2GB for use by the operating system and the other 2GB allocated for the application. In addition, VirtualCenter with multiple processors can support large enterprise environments. 

VMware suggests that VirtualCenter be configured with two processors and 3GB of RAM to support up to 100 ESX Server 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 single processor and 1.5GB of RAM should suffice for up to 50 ESX Server hosts and 1,000 virtual machines. Though it helps to have a good starting point for the deployment of VirtualCenter, you can always alter the specifications to achieve adequate performance levels.

More important than detailing the CPU and memory allocations for VirtualCenter is the plan devised for recovery in the event of disaster. Remember, the heart of the VirtualCenter content is stored in a back-end SQL Server or Oracle database. Any good disaster recovery or business continuity plan should include instructions on how to handle data loss or corruption on the back-end.

If the VirtualCenter server is a physical box, the best approach to providing availability is to create a stand-by VirtualCenter server that can be turned on in the event of a failure of the online VirtualCenter server. After failure, the stand-by server can be brought online and attached to the existing SQL Server database, and then the hosts can be added to the new VirtualCenter server.

For high availability of the data component of VirtualCenter, you can configure the back-end database on a SQL Server cluster. Figure 5.35 illustrates using a SQL Server cluster for the back-end database and a stand-by VirtualCenter computer. If a SQL Server cluster is not available or 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 will allow you to restore data up to the minute when loss or corruption occurred.

Figure 5.35 A good disaster recovery plan for VirtualCenter should include a quick means of regaining the user interface as well as ensuring the data is highly available and protected against damage.

Snapshot functionality will give you the ability to return to a point in time for your VirtualCenter. VMotion will give you the portability required to move the server from host to host without experiencing server downtime. But what happens when a snapshot is corrupted or the virtual machine is corrupt altogether? With VirtualCenter as your virtual machine, you can make regular copies of the .vmdk 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 in the last. vmdk copy process, which should not be extremely different, given that the bulk of the data processing by VirtualCenter ends up in a back-end database running on a different server. Figure 5.36 illustrates the setup of a manual cloning of the VirtualCenter server.

Figure 5.36 If VirtualCenter is installed and configured as a virtual machine, its .vmdk 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.

As a last resort for recovering VirtualCenter, it's possible to just reinstall the software, point to the existing database, and connect the host systems. The installation of VirtualCenter is not a time-consuming process. Ultimately the most important part of the VirtualCenter recovery plan is to ensure that the database server is redundant and protected.

Оглавление книги