Enthusiast
Enthusiast

Separate SQL Server for Virtual Center?

VMware states that it is best practice to separate the Virtual Center application and database servers onto separate physical hosts. What is the community opinion as to whether this is really required? I understand that there is some advantage in terms of recovery - if you keep a virtual image of the VC app server this can be powered on in the event of a failure to the app server. However, if the app and database were all stored within a vmdk would it not be possible to take regular snapshots for the purposes of recovery?

Is there something I am missing? Are there other reasons it is best practice to separate the app and database?

Thanks for your help.

0 Kudos
2 Replies
Champion
Champion

All your configurations and performance data store on database so by design it would be best to seperated with high end SQL cluster servers elsewhere for redundancy purposes. That doesn't mean you have to follow it just depends on your situation where you have budget issue with hardware purchase and doesn't have enterprise SQL clustering in place. Unless you have a large ESX environment, than having virtual center database on a secure and redundant cluster server is prefer. If you're a small/medium and wants to have everything on one server that's doable and shouldn't be any problems. I still prefer both runs on same server if possible due to the fact you don't have to rely and depend on the network connectity and clustering feature as well things can failed.

I would architect the VC server and database server to maximize its performance and high availability as possible. You can virtualize your virtual center or database as well and by default those VM utilize your HA and VMotion from ESX so you have guaranteed redundancy already. Maintenance and provision your VC/database VMs is much easier comparing to remote and physical database server. Both solutions are great practices as well, since we have large SQL cluster farms, we utilize it to have guaranteed database performance and redundancy so in this case, my vc database is store on seperate sql box. You could take the whole backup .vmdk image or snapshot your VC/database server and move it to DR if needed for recovery.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!! Regards, Stefan Nguyen VMware vExpert 2009 iGeek Systems Inc. VMware vExpert, VCP 3 & 4, VSP, VTSP, CCA, CCEA, CCNA, MCSA, EMCSE, EMCISA
Enthusiast
Enthusiast

Its is considered best practice, but I wouldnt bother seperating VC + SQL DB.

In fact, I have done many implementations where I have used a VM for VC+SQL DB and no probs.

I prefer VC+DB to be in a VM. I like the having the flexibility.

I feel that a "physical" server dedicated for VC is unnecessary, and a single point of failure.

Since one of the main drivers of a VMware Project is server consolidation + containment, I think that VC is better off in a VM.

Chris Troiani Technology Consultant, EMC VMware Affinity Team
0 Kudos