VMware vCenter & SQL : Best Practice

This month I started on a new project and I noticed again a different approach from a colleague to the vCenter/SQL/Physical/Virtual issue. And of course there has been written a lot about this issue but I couldn’t find my exact view anywhere else so I thought I’d open up a discussion here by presenting the Best Practice in my humble opinion.

There are 4 critical decisions you have to make concerning the vCenter server for your VI:

1. vCenter server : physical or virtual.
2. SQL Database (server) : locally or detached.
3. Redundancy options : make it redundant and if so; how?
4. License server : locally or detached.

1. Virtualize your vCenter server. Reasons :

1.1. You’re automatically making it Highly Available. When the physical machine is down, HA still works so your vCenter Server is protected against hardware failures.

1.2. Eat your own dog food; you trust your company/customers to run production on your Virtual Infrastructure, why the h*** wouldn’t you?

2. Install the SQL databaseserver and the database on a different server (cluster) as your vCenter Server. Reason :

2.1 Performance. When hosting a larger environment the database server will get pretty busy and you don’t want your VC and it’s database server getting strangled in a performance struggle.

Take notice that this is concerning larger environments. If you have a smaller environment and use the SQL Server 2005 Express Edition, off course you keep the VC and database on the same server.

3. Redundancy options: Use HA and have a backup VM or physical machine available.

3.1 Options to really cluster the vCenter server is overkill when you ask me. I still consider it “just a management server”; the most important function : HA, works without VC intervention.

3.2 If your VC or database really gets corrupted you still have a serious issue since you won’t be able to find your VM’s, besides that DRS doesn’t function either. Therefore you should have a way to get your VC back quickly.

 

 

 

4.1 No performance impact and running it locally reduces the danger of network failure to interfere.

Take notice: virtualizing your vCenter Server is fully supported by VMware but there are some additional considerations:

A. Make sure its resources are guaranteed. Make use of reservations/shares !

B. Make sure the autostart policy for the VC VM is set with the highest priority (This in case your ESX cluster went down for whatever reason) !

C. Think of the other resources needed for your VC to function : DNS, AD, DB. Make sure these are always up for your VC. So if they run virtual, set the autostart policies and prioritize it like this : 1. DNS, 2. AD, 3. DB.

D. Disable DRS for VC [edit thx to Vikash/Duncan]

Please take notice. These are best practices based on my own experience, experience of others and VMware whitepapers. Most relevant white papers with more details :
Running VC in a VM : http://www.vmware.com/pdf/vi3_vc_in_vm.pdf 
VC SQL Database Performance : http://www.vmware.com/files/pdf/vc_database_performance.pdf.

Off course I’m not the first one writing about this so check out the following sources, which I’ve have also used, for more info about running VC virtual:

Making VC Highly Available @ Yellow-Bricks : http://www.yellow-bricks.com/2008/11/19/make-virtualcenter-highly-available-with-vmware-vi3/

VC Physical or Virtual @ VMGuy : http://vmguy.com/wordpress/?p=67 (btw, that wordpress template is soooo 2008 )

VC Database Best Practices @ Scott Low : http://blog.scottlowe.org/2008/09/18/po2061-vmware-virtualcenter-25-database-best-practices/

VC Virtual ? @ Rich Brambly (VMETC) : http://vmetc.com/2007/12/28/should-virtual-center-run-as-a-virtual-machine/

Physical/Virtual discussion @ VIOps : http://viops.vmware.com/home/message/1359

 Mgmt Cluster : http://www.dailyhypervisor.com/2009/04/14/vmware-virtual-center-physical-or-virtual/  [Edit 15/4/2009]

Again, I’m trying to open up a discussion here so feel free to comment !