To Virtualize the Virtual Center Database or not to Virtualize?

[jslarouche]

Hi All,

This question might have already been asked but i figure i'll ask anyway.. In our environment we currently are using SQL 2005 SP2 as our database server.. It's a physical box and want to know what other people are doing with their DB server? Are you virtualizing them or leaving them physical? Currently we have our Virtual Center server as a virtual server on our cluster and i have followed the best practice guide that VMware has release and don't see any issues with that but i am pretty hesitant with virtualizing the DB server.. Thoughts? Should we do it or not? Has anyone virtualized their VC Database and haven't had any issues?

Thanks.

[RParker]

NOT

Yes you CAN do it, but it's not the fastest possible performance, and there is a significant difference. It's better to put SQL on Physical hardware or ANY database product. I can use my car to haul lumber from Home Depot too, and hook up a trailer to a Porsche and drag motorcycles cross country. Just because you CAN doesn't mean you should. There is a such thing as the right tool for the job. VM's are NOT good tools for Databases.

[Rodos]

What rubbish. Sorry to be blunt but you can't just spurt out things like that.

To the original poster. Check out this VMware white paper.

>SQL Server Workload Consolidation

>by VMware on 11/25/2008 @

>Database workloads are very diverse. While most database servers are lightly loaded, larger database workloads can be resource-intensive, exhibiting high I/O rates or consuming large amounts of memory. With improvements in virtualization technology and hardware, even servers running large database workloads run well in virtual machines. Servers running Microsoft's SQL Server, among the top database server platforms in the industry today, are no exception.

To know whether its a good idea for your environment or not is going to depend on the load of that SQL box and can you deliver it from a virtualised environment. How bug is your VMware cluster and what logging level are you running at? How big is the database? What are the SQL statistics for load? What type of storage would you be moving it to.

After you are comfortable with the performance isssue (just like you would be if you were selecting physical hardware, not all of that is the same, same process, can I deliver the required resources) you want to think about the dependencies, licensing, those kinds of things.

I am sure others will pipe in but "VM's are NOT good tools for Databases" is just plain misleading.

Rodos

Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/

[Jasemccarty]

Well... I'll say that my VC DB isn't on a VM... Yet. But I'm working on it.

Right now I have about 300 VM's and 1/3 of them (100) are SQL boxes.

The most important thing to note (for me), with that many VM's that are SQL, it was important to have plenty of disks on the LUNs that have SQL guests on.

I just setup a VMware Midsize Accelleration Kit, and we virtualized the VC box, without any problems.

A good rule of thumb would be to determine how many hosts, how many guests, what amount of logging, and how many users will have console access. Then look at a VC guest, and size it accordingly.

As far as to virtualize SQL or not... 100VM's in production for over 4 years, with zero issues... I couldn't say it is a bad idea to virtualize SQL.

Cheers,

Jase

Jase McCarty

http://www.jasemccarty.com

Co-Author of VMware ESX Essentials in the Virtual Data Center

(ISBN:1420070274) from Auerbach

_{Please consider awarding points if this post was helpful or correct}

[mcowger]

Agree - total rubbish. we run hundreds of DB on VMs, and they are fine, including some heavy duty ones. We also virtualize our VC DB, and have never had 1 problem with it.

--Matt

[admin · Accepted solution]

See also this page for more information -- case studies, white papers -- on SQL Server specifically.

http://www.vmware.com/solutions/business-critical-apps/sql/

[virgilwashere]

NOT

Yes you CAN do it, but it's not the fastest possible performance, and there is a significant difference. It's better to put SQL on Physical hardware or ANY database product. I can use my car to haul lumber from Home Depot too, and hook up a trailer to a Porsche and drag motorcycles cross country. Just because you CAN doesn't mean you should. There is a such thing as the right tool for the job. VM's are NOT good tools for Databases.

It's best to evaluate servers as viable virtualisation candidates on their own merits, not just on the name of their application.

For an environment that doesn't meet the specs of using SQL Express (5 hosts, 50 VMs), it is a good idea to separate the vCenter application and vCenter database SQL instance.

Virgil

[sradnidge]

Rod said everyting I would have said, but I'll add that in your own words "there is such a thing as the right tool for the job". If you consider all SQL workloads to be equal, and thus the tool for the SQL job to be invariant, I will happily add you to the vIdiot nomination list.

[jslarouche]

I'd like to thank everyone on who replied to my post.. Currently our environment is setup as a six host cluster using HP DL580G4's dual core processor servers. We have roughly 200 VM's on this cluster that is backended to two EVA81000's. The load on this cluster is roughly 40-60% CPU utilized thru the business day. Ram is not an issues since each host has 64 gigs of ram. I guess the next step for me is to run some performance stats on our VC database server and see if it truely is a candidate.. I am glad that there are other companies that have converter to a VM. THe reason why i was asking is our physical VC server is setup as a boot-to-san server and it replicated to like 2 like hardware at our DR site. So i was thinking on converting it to a VM and place it on our ESX cluster and place it on a replicated LUN in VMware and when we have our sanity test every year it'll be so fast to fail over it's not even funny and easier as well.

[Texiwill]

Hello,

I do not virtualize VC, but mostly it is because my VC server also runs my License manager, I have had issues with a virtualized LM. I make my VC box do double duty as my backup system. Its fairly well loaded with memory, etc. They key is to determine what you will do in failure cases. I had an issue where unknown to me at the time my LM running in a VM was down for over 14 days. It caused me to not power on VMs... Just then the VC VM needed an update, so now I was without VC, without LM, and could not boot a single VM until I got an LM back and running.

Once I moved to physical I never had this problem again. However, an easy solution for me was to put the LM on a laptop and redirect LM for the hosts to my laptop. boot up the VMs, fix the virtualized LM and I was back in business.

This is one reason I do not virtualize LM. I also do not virtualize backup and since I needed a host for that, I just made one host do it all.

If you do virtualize your VC, be aware that there are some chicken and the egg situations that due pop up from time to time and you need a DR solution for thos.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[alecprior]

We run VC as a VM and it backs onto an Oracle VM. We've had no performance problems at all, it's actually faster than when it backed onto our old production database over three physical nodes in an oracle cluster as it's not sharing the database and therefore the database config can be tuned much better for VC operations (our other databases are tuned for data warehousing). If you have tens of hosts with thousands of VMs then your mileage may vary, but for our 10 hosts and few hundred VMs it barely breaks a sweat. VC seems to be a very light load on its database. SQL on a VM may be a different case though, all i use it for is a test VC with three nodes and it's OK as a VM for that but there's a clear disk bottleneck on ours which is more evident with ArcServe (no user apps use the SQL database).

[admin]

We currently do it three ways

1, vCenter as a VM then using MS iSCSI within the VM to a dedicated area of storage presented to that VM for SQL

or

2, vCenter Physical then again MS iSCSI to a dedicated area of storage presented to that physical Server for SQL

or

3, vCenter Physical then connect to an already provisioned SQL server, basically create another SQL instance for the vCenter and one for Update Manager

also SQL in general, I have not experienced any issues with it all being a pack of .vmdk files, depending on the load we might opt a similar config as option one above

[msemon1]

We had some chicken and egg issues with running VC and the Database server on VM's. It will probably work ok, however, we found it better to have them as physical servers in case we have problem with virtual environment. If nothing better, peace of mind.

Mike

[mnasir]

That’s not true, I am running SQL server 2005 SP3 with 2 Vcpu on a virtual machine which is running multiple database instances, the underlying host is IBM 3650, there is absolutely no issue. I am running 800/1200 transitions/second without any issues. Unless you need 8 vCpu and 128GB memory and have a website that is as busy as EBay, you should be able to run Oracle, SQL, MySQL, easily on virtual machine.

My only question was, should I use vmfs or go with Virtual RDM? After running several database testing scripts and researching the web, I came to conclusion, that I don’t need virtual rdm (unless it is SAN specific), vmFS volume should be fine. But, you should follow best practices from Microsoft - split database on to two different logical drives, don’t dump ldf and mdf files in the same logical drive. Have system DBs separate from user DBs, and yap, proper memory management.