Main menu

Virtualization mojo, not voodoo!

vCenter Design Considerations with VUM, SQL, and SRM, Your thoughts?

So I was having a discussion with a few fellow VMware dudes, and we were discussing the vCenter installation methods. One train of thought is to install vCenter, VUM, SQL 2008,, and SRM on 1 VM with 2 vCPUs, 4 GB of memory an a 100 GB drive, Monitor for performance and adjust as required by analyzing the performance data. I have alwbeen doing installations this way lately without issue. I have also done installations on dedicated SQL boxes \ VMs. I have gotten good performance out of the environment with having all services on a single VM. In larger environments of 20 or more hosts and 300 + VMs, I have used a dedicated SQL server. The SRM documetation recommends a separate server for the SRM installation, but I have not seen any issues with it on the same box, and there was not any performance degradation in an environment of less than 200 VMs.

Also in many environments, there is not a DBA to manage the SQL box, and I have had to become the resident expert on-site. Some customers feel more comfortable with single instances. Another train of thought was to separate SQL, VUM and SRM on separate VMs, and while I am not opposed to that, I would like to know what you have been doing in real world scenarios throughout your experience in the industry.

I know what documentation states, but sometimes we have to think outside the box and push the envelope. I remember in the ESX 2 days, some thought that it was too much to put all your eggs in one basket, and the thought of virtualizing SQL and Exchange, much less vCenter was a crime.

I’m sure at least one of the VMware dudes you were talking to was once a Windows System Administrator. I also sure that that same VMware dude cringed at the thought of needlessly putting multiple services on a single VM. He probably thought that as long as the customer had enough money for Windows Server licenses, compute and disk resources, that one should obviously separate each service into their own server. Now, to take a step back, let us say that, yes, it certainly is possible to put all the services you mentioned, vCenter, SQL 2008, VUM, and maybe even SRM on the same box, whether virtual or physical. But of course, whether this is possible or not is not in question. It’s whether it should or should not be done in the first place. I’m going to pull out the age old consultant’s answer and say, “It depends.”

It depends on if the customer has the budget for more Windows or SQL licenses. Does the customer have the compute and disk resources for several more servers? Is there already an existing SQL box or cluster that could be used? Is a DBA on staff, or at least a competent Windows Server admin? Does the customer’s environment even need a full blown SQL installation or would SQL Express do fine?

Now I’m coming from a background of government contracting where money is usually thrown at such projects. Resources for such an implementation are little thought about because they’re going to be there no matter what. This question could impact SMBs more, but probably not large corporations.

I think there are certainly right and wrong ways to implement based on circumstances. On the one hand, if you have the licenses, compute, disk, and administrative resources, I say absolutely, put each service on it’s own separate box. In more constrained environments, you may need to double up two or more services.

I didn’t even touch on the idea of recovering from a failed VM. With an “all your eggs in one basket” approach, if one VM goes down, is somehow unrecoverable, then you’ve lost a lot of data. Separating your services reduces the liklihood that any one VM failure/loss will result in mutlitple services lost.

Reblogged this on VirtuallyMikeBrown and commented:
In response to Miguel’s post, here are my thoughts:
I’m sure at least one of the VMware dudes Miguel was talking to was once a Windows System Administrator. I also sure that that same VMware dude cringed at the thought of needlessly putting multiple services on a single VM. He probably thought that as long as the customer had enough money for Windows Server licenses, compute and disk resources, that one should obviously separate each service into their own server. Now, to take a step back, let us say that, yes, it certainly is possible to put all the services you mentioned, vCenter, SQL 2008, VUM, and maybe even SRM on the same box, whether virtual or physical. But of course, whether this is possible or not is not in question. It’s whether it should or should not be done in the first place. I’m going to pull out the age old consultant’s answer and say, “It depends.”

It depends on if the customer has the budget for more Windows or SQL licenses. Does the customer have the compute and disk resources for several more servers? Is there already an existing SQL box or cluster that could be used? Is a DBA on staff, or at least a competent Windows Server admin? Does the customer’s environment even need a full blown SQL installation or would SQL Express do fine?

Now I’m coming from a background of government contracting where money is usually thrown at such projects. Resources for such an implementation are little thought about because they’re going to be there no matter what. This question could impact SMBs more, but probably not large corporations.

I think there are certainly right and wrong ways to implement based on circumstances. On the one hand, if you have the licenses, compute, disk, and administrative resources, I say absolutely, put each service on it’s own separate box. In more constrained environments, you may need to double up two or more services.
That’s not the least of it. Recovering from a failed VM will cost you less in time, effort, and hopefully, money. With an “all your eggs in one basket” approach, if one VM goes down, is somehow unrecoverable, then you’ve lost a lot of data. Separating your services reduces the liklihood that any one VM failure/loss will result in mutlitple services lost.

Mike, great points and thought provoking. Remember, we are talking about vCenter, not a financial or ERP DB. I think most of us have been Windows SAs at sometime in out past, and we need to use that experience as well as new ideas to think outside the box:)

So you would have possibly four VMs for an installation of vCenter, one for vCenter, one for VUM, one for SQL, and one for SRM. Sounds like a physical design, or a Texas Ranger point of view, one riot, one Ranger:) Not wrong, just another way to skin a monkey. I would hope that I could rely on the HA ability of VMware, and possibly Vcenter Heartbeat. If I lose vCenter, what do I lose that is critical? What great amount of data have i lost? I lose performance data, scheduled tasks, alarms, vDS (hopefully, I have a hybrid solution), FT, nope it is not dependent on vCenter, HA, also not dependent on vCenter, vDS, supposed to work even when vCenter is offline. I could have a clone ready, as I have seen some organizations clone the vCenter on a regular basis. How long will it take me to recover and is the RTO acceptable with the SLAs?Are there SLAs? Another blog. Are there RTOs and RPOs? Yet another blog:)

What does the VMware documentation say about vCenter design and configuration? Is there a “must” in any of the sentences? What are the performance characteristics on vCenter and mean time between failures in a virtual environment? How does vCenter perform during a SRM failover, or during the occasional patch download\remediation? What is the DB doing? Is it a transactional DB with high IO, or is it low intensity?

Although S*&T happens, the virtual environment should be built on some dependable and redundant hardware, unless you are piecing it together. So what is going to fail? Power? Hope you have a UPS. Network? Redundant switching, and the proper HA settings for the VMs, SAN? Redundant disks, controllers. Human error…hmmmm, yep Otis will get you.

I guess if I lose the DB, I could have issues whether it is centralized or de-centralized. If I do lose the DB, I am in the same boat, what do I do? Restore from a conventional backup, use VSC, rebuild and restore? If it is a dedicated SQL server with many DBs, someone is going to have to manage it, unless they give me permissions to touch it. Do I want control of the DB or do I give it up to a DBA? There are SQL maintenance tasks that can be performed and automated. Is the vCenter DB critical to a production environment? I have lost one vCenter, because a junior VCP shot down the SAN while the vCenter was still in an up state. Fortunately, I still had a copy of the vCenter on my desktop, so I just uploaded it and we were back in business, and the production environment did not hiccup. I also lost a vCenter during a network outage,posted in an earlier blog. Human error, easy to recover from, except for the vDS switching on one ESXi host, which got corrupted. Easy enough fix when I was finally notified.

Can I recover quickly from a backup? We also have NetApp Virtual Storage Console or VSC that can take regular backups of the VMs and you can recover quickly from the latest backup dependent on your schedules and retention policy. We need to evolve with the technology and leverage the feature sets that are available to us and become forward thinkers. Just because it has always been done this way in the physical environment and for the last decade, does not mean it has to continue.

What hat do I have on, my consultant, engineer, design, or system admin? Am i simply implementing according to someone else’s instructions, or am I leveraging the documents,experience from the field, as well as my own experiences? I need to leave my customer with a simple, robust, dependable solution for his environment, and maybe, if they are interested, I can save them costs and garner them efficiency. Or if I am the SA, maybe I want a lot of VMs to manage.

Just my humble thoughts and experience. Basically how you gonna act when things go South and you have to initiate your E&E plan and can you justify your decision to Big Dude 6?