Over the past few weeks I’ve heard a whole lot of arguments around vCenter design considerations. A few of the questions asked were:

• Do I install vCenter on 32 bit or 64 bit?
• vCenter as a physical or Virtual machine?
• vCenter Database – Local or Remote?
• Placement of the Update Manager Server and Database

Before I dig into the vCenter design topic, I think it would be good to put some perspective on this post and why I’ve decided to blog on this. Last week I attended a meeting with some fellow virtualisation consultants and one of the topics raised in the meeting was to find a common standard practise between us regarding vCenter Server design and specifically the “default” stance between the consultants in regards to the placement of the vCenter server and whether it should be a physical or a virtual machine. Some consultants were in favour of the idea of a default stace and others were against the idea, stating that the decision of vCenter being hosted on a physical or virtual machine is down to the circumstances of each consultancy engagement. Thinking back now, I don’t think we came to an agreement in the end.

This post is basically my opinion on vCenter design, and the steps that I take in deciding what my infrastructure design will look like.

Do I install vCenter on 32bit or 64bit?

The simple answer to this question is: 64-bit! Why? Well future releases of vCenter will almost certainly be 64-bit only. This means that if you install vCenter 4.0 on a 32-bit Windows operating system today, you will have to rebuild the vCenter server as future releases of vCenter will not install on 32-bit Windows. In simple terms, if you are on 32-bit Windows now, you will not be able to do a simple upgrade to future releases of vCenter.Another reason for going with 64-bit Windows is the fact that you can make use of 4GB RAM and more. I almost always assign at least 4GB of RAM to my vCenter Server, and this will not be efficiently used on 32-bit Windows.

vCenter as a physical or virtual machine?

In order to answer this question, we will have to look at the advantages and disadvantages of both solutions. Personally, my default take on this is to install vCenter on a Virtual Machine. I have many reasons for this approach, one of the reasons being that we cannot tell everyone to run SQL and Exchange of virtual machines if we are not prepared to run vCenter on a virtual machine. If we evangelise VMware vSphere to the world, but cannot lead by example, then what message does that send out? Now, I know by this time you must be thinking “This guy is mad to design an infrastructure based on some political and moral grounds rather than technical grounds. Although this is probably not a good enough and certainly not a technical reason to virtualise vCenter Server, I do have some technical and cost reasons for this approach as well. As I said before, we have to look at the advantages and disadvantages of both physical and virtual vCenter designs.

Is it supported?

The first thing we should look at is support. As VMware fully supports vCenter Server on both physical and virtual machines, there shouldn’t be any issues with support, providing that you use a supported operating system and database. If you do decide to host vCenter on a Virtual Machine, make sure that the virtual machine is configured to meet the minimum supported hardware requirements.

vCenter as a Physical Machine:

vCenter as a Virtual Machine:

Let’s look at vCenter as a Physical Machine first

Advantages:

• Not susceptible to potential virtual infrastructure failures:
  Where vCenter is running as a Virtual Machine, there is a danger that the VM can go down due to an infrastructure failure. There are many things that could cause a VM outage, one of these being the datastore where the VM is hosted could run out of space. Running vCenter on a physical host will guard your vCenter server against such VI failures.

Disadvantages:

• Dedicated server hardware is required:
  The first reason most people turn to virtualisation, is to get rid of underutilised hardware and the costs involved with running all that hardware. Running vCenter as a physical machine will require dedicated hardware that needs support, cooling, power, rack space, multiple switch ports, etc.
• High availability is expensive and complex to implement:
  In order to provide high availability to vCenter, the use of either Microsoft Cluster Services or VMware vCenter Heartbeat will be required. Both of these technologies require extra software configurations. Both technologies are complex to implement. Both cost a lot of money. MSCS requires at least Windows Server 2003 Enterprise Edition.

Things to bear in mind when opting for vCenter as a physical machine:

• Performance is limited only by the server hardware. This could be a good or a bad thing. Generally this is seen as an advantage as the vCenter server does not have to contend with other servers for resources.
• vCenter Server backups are done with traditional tools / agents. This makes recovering from a disaster more tricky and lengthy. I therefore see this as more of a disadvantage than an advantage. In the case of a disaster, you will have to rebuild the server from scratch and then try and restore the system state onto the newly installed operating system. Then you’ll have to say a prayer and hope it works.
• Microsoft Cluster Services or VMware vCenter Heartbeat can be configured to provide high availability to the vCenter system. This can be Physical-to-Physical or Physical-to-Virtual clustering. Bear in mind that if you choose to use these technologies, the use of SQL Express is not an option. The vCenter database will have to be hosted on a remote database server, which will in turn also be required to be configured with MSCS (if the SQL server is physical) or VMware HA (if the SQL server is virtual) to provide high availability.

Let’s look at vCenter as a Virtual Machine

Advantages:

• Allows the migration of the vCenter server with VMotion during maintenance windows:
  As the vCenter is a virtual machine in your existing ESX/ESXi environment, the vCenter server can be migrated with VMotion just as all the other VMs can be migrated. This allows for the vCenter server to be moved to another ESX host without downtime in order to perform maintenance tasks on hardware or to apply patches / software upgrades to the ESX hosts.
• No extra power, cooling, rack space, etc is needed:
  This will help reduce capital and operating expenditure as no additional data centre configurations need to be made in order to implement the new vCenter server.
• Allows the entire vCenter server to be backed up with VCB:
  As the vCenter server is now essentially a bunch of files, the VM can be backed up with VMware Consolidated Backup or VMware vDR and sent to tape. This makes things a lot easier when a disaster recovery operation is invoked as you will be able to restore the entire VM from backup in minutes. Not to state the obvious, but if the vCenter database is on a separate database server, this then needs to be backed up separately.
• Allows the use of VMware HA to restart the vCenter server in the case of a hardware failure:
  VMware HA can restart the vCenter VM on another ESX/ESXi host in the event of a hardware failure on the host where the VM was running. This is a much simpler and cost effective approach to providing high availability than the use of MSCS or VMware vCenter Heartbeat.

Disadvantages:

• Susceptible to potential virtual infrastructure failures:
  The vCenter virtual machine is susceptible to potential virtual infrastructure failures. These failures can be brought on by many things such as the loss of connectivity to the storage array, a datastore that ran out of free space, snapshot failures, etc.
• The VM will have to contend with other VMs for resources:
  As vCenter will now run as a VM alongside other VMs on the same ESX/ESXi host, the VM will have to contend with the other VMs for its resources. In a well designed infrastructure with plenty of resources, this is not normally a problem, but it is something to look out for.

Things to bear in mind when opting for vCenter as a virtual machine:

To balance the load in a DRS cluster, DRS may move the vCenter VM to other hosts on a regular basis. If for some reason the vCenter VM fails and does not restart with HA, you will not be able to manage your servers and virtual machines until you find the server on which the VM is registered. Unless you limit the DRS movement of the VM, you may have difficulty finding the VM in a large DRS cluster. It is also possible with VMware HA to set the preferred failover host of an individual VM. This can be done by setting an advanced parameter called das.defaultfailoverhost. For more information on das.defaultfailoverhost, refer to page 24 of the Availability guide at http://www.vmware.com/pdf/vsphere4/r40/vsp_40_availability.pdf (Opens in a new window)

Along with the das.defaultfailoverhost setting, it may also be a good idea to set the HA restart priority of this VM to high.

vCenter Database – Local or Remote?

Another thing to consider is whether the database should be hosted on the same server as the vCenter server or on a separate server.

Advantages of a Local database

• Can use the bundled version of Microsoft SQL Server 2005 Express for smaller deployments of up to 5 hosts and 50 virtual machines
• Removes the network dependency between the vCenter server and the database server and is therefore more robust
• Easier to maintain as you only have to maintain one server and not two
• If vCenter is installed on a VM, a single backup will be performed for both vCenter configuration files as well as the vCenter database.

Disadvantages of a Local database

• Increases resource requirements for the vCenter Server
• Not a very flexible solution as it is more difficult for database administrators to manage.

Advantages of a Remote database

• This is convenient to support and maintain by the DBA team on existing database servers
• Resource requirements for the vCenter server is lower
• The vCenter database can be hosted in a SQL Failover cluster for high availability

Disadvantages of a Remote database

• Requires a robust network connection between the vCenter server and database server. vCenter will crash if connectivity is lost

VMware Update Manager

One other thing to factor into your vCenter design is the placement of the Update Manager Server and its database.

Advantages of a Local installation (Update Manager on the vCenter Server)

• Simplifies magement
• Saves on Windows licenses as no additional Windows servers are required

Disadvantages of a Local installation (Update Manager on the vCenter Server)

• Affects the performance of the vCenter server
• Requires the vCenter server to have access to a proxy server or direct access to the internet in order to download patches from VMware

Advantages of a Remote installation (Update Manager on a separate Server)

• Does not affect the vCenter server’s performance or configuration

Disadvantages of a Remote installation (Update Manager on a separate Server)

• Requires an additional Windows License
• Cannot communicate with vCenter if network connectivity is lost

Where to place the Update Manager Database

Regardless of where the Update Manager server is installed (local to the vCenter server or not) always create a dedicated Update Manager database instead of using the vCenter Database. This prevents the performance impact on the vCenter database, although it increases the administrative burden. Also, try to place the Update Manager and the vCenter database on the same server as it simplifies administration.

• Add New
• Search
• RSS

Comments (0)

Write comment

Your Contact Details:

Name:

Email: do not notifynotify

Website:

Comment:

Title:

UBBCode:         -color-aquablackbluefuchsiagraygreenlimemaroonnavyolivepurpleredsilvertealwhiteyellow -size-tinysmallmediumlargehuge

Message:

Joomla components by Compojoom