SQL Server 2000 on VMware - Advantages/Disadvantages
-
One thing thats not clear here is what version of VMWare we're talking about. The flagship product VMWare ESX Server, does get down and dirty with the hardware and allows a lot finer resource management.
It does also come with a rather hefty price tag which makes a lot of people think of other options. Given the right hardware resources, ESX server might be a viable virtualisation platform for SQL Server.
--------------------
Colt 45 - the original point and click interface
-
i have had several problems with SQL Server 2000 running on VMWare. We have experienced a problem with the read and write buffers in the VMWare virtual disks reporting back to SQL that data is written before it is and then accessing the data generates an internal SQL error.
It has been intermittant and infrequent, but there appears to be no solution. SQL 2000 sp4 helped - there is some additional error handling that was added, but all it did was make the error messages more useful.
We use VMWare for all of our test and development environments, but I would not put a production SQL server on it unless I really had to.
-
I have a client that is running 2 VMs on VMWare ESX server each with sql server and it is an absolute dog. To be fair the machine doesn't have enough RAM (most important) nor CPUs (distant second). However, from my prospective as a SQL Server consultant for many years, the benefits of virtualization do not outweigh the disadvantages except in isolated instances such as a test/dev environment.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service -
The version is VMWare ESX infrastructure 3.
-
The problem is many of us would avoid it from a perfomance standpoint unless you have enough hardware to do the job. If you do then their may be no legitimate reason other than cost and best utilization of the resources you have. You most likely will need the pros and cons list from the vendor so you can determine if their reasoning is sound and has no wholes in it. But it is like proving a negative, very hard to do. That is why I suggest the vendor do a real world example of a system comparable to what you will need. We do virtualization here and have blades with enough equipment I couldn't tell you which were virtualized and which were coffee makers. Also without a large enough load I couldn't tell you what impact each virtualization has on overall perfomance.
But here is a nice little link I found
http://scaleoutadvantage.techweb.com/news/str_nwc20070406_achieving.jhtml
Plus you can find more stuff searching on google for
virtualization performance hits
But all in all the key is this, virtualization will impact total performance of the machine in a negative manner but this can be tuned to the level of how many VMs you can handle on a single machine. The key VM does provide is seperation of environments for longevity of the individual environments since app 1 in VM 1 wil not impact app 2 in VM. But in the end it that is really a sign of something wrong in the design of the app and usualy you know if you have any apps that have failing tendencies which may impact time on the same box. VM just allows you to mitigate the chance better for maximum uptime of each app but like any solution for improved service it comes at a premium.
-
I work for a client where they are looking at doing something similar. The great thing about VM's is you can get one up and running real fast once the "base install" is created - though this is not a good argument for production it does help with disaster recovery etc.
Main thing is if you are going to do it youhave to do it properly or it will be a performance dog - main issue with "out of the box" virtualisation is disk access is now to a virtualised disk which is really just a file on the host OS - that is real bad for performance so you need to make sure you are using high quality hardware - typically this mean a SAN with direct SAN drivers in the guest OS so it does not go via host OS file system. Second thing is you need big iron - again typically the overall spec is bigger than the sum of combined servers you are joining in. A question was asked as to what is better about VM'ing the multi SQL servers rather than having multi SQL 200 instances direct - the answer is resource management - each SQL server instance would happily try to grab all the CPU etc from the host OS but VMWare ESX has all sorts of fancy resource management controls so you can limit a guest VM to certain amounts of CPU etc. Also it is often easier for migration as if your apps were all configured for different boxes they still will see different boxes.
Do it properly and there are benefits - especially in disaster recovery etc but also e.g. if you have some heavy process you need to run in a single guest you can give it more whack temproarily while you do it.
James Horsley
Workflow Consulting Limited -
I have been looking for articles from Microsoft articles on NOT using VMWARE with MSSQL. So far, I have only come across vague recommendatios in chatrooms and forums.
Any definitive article that I can be pointed to?
-
I'll be able to answer this for you shortly as we are preparing to move our production sql servers to vmware (ESX Enterprise). To be clear, this will be on new hardware with plenty of ram/cpu for each vm, and will be using an iSCSI SAN.
For us personally, the key features include:
* Vmotion: allows the vm to be moved to another host without impacting the users. This will allow hardware repair without downtime.
* HA: provides automatic vm restarts on surviving hosts if an active host fails.
* VM snapshots: reduces risks from problematic updates or software installations. Recovery, if necessary, is quick and easy. This is especially attractive to us because our developers have admin rights to the prod servers (Arg!). They tend to mess things up and can never seem to undo it, which typically results in a reinstall
* VM clones/templates: allows for rapid & simplified deployment.
* Centralized resource monitoring: by being able to dictate and track resource utilization, we can begin to accurately allocate resource costs to the appropriate department.
* Hardware independence: make hardware upgrades easier by just moving the vm to the more powerful host.
* Server life cycle management: simplifies server infrastructure-deploying/retiring
* Consolation: I don't think there's any doubt as to the benefits of consolidating non-SQL servers, so it would make sense to virtualize everything, right?
This puts the DBA in a position of having to prove why "their baby" is different- aka "doesn't play nicely with others" at my company.
Our DBA had a couple legitimate concerns:
* CPU limit: A single vm can only have a maximum of 4 CPU's. Our largest server today is an 8-way (two physical processors, each a dual-HT @ 2GHz). Since the new servers will be true quad-cores and around 3GHz, they should have about 20% more processing capabilities.
* Host overhead & latency: I share this concern and won't be able to rule it out until I test it for myself. We're getting ready to do some lab work to compare SQL performance in and out of a virtual environment, and then we'll schedule a
So if you can tell, I'm not necessarily against it for SQL in a production environment, but we're testing our own systems before fully committing. If properly configured, any catastrophe should be easily recoverable and you can always change your mind. To be honest, I'm actually more concerned about possible problems moving multiple SQL servers to an iSCSI SAN than I am about vmware.
I'll post again after our first round of tests.
-
Thanks for keeping the post active. I would be interested in hearing from others on how they approach the changes to VMWare.
-
At my clients location SQL Server was hosted on Virtual Servers. It worked like a champ initially but we started facing performance issues at a later stage. Yes, there were a couple of badly written stored procs which were causing the applications to die but extensive tuning didn't help much. We then cam across some forum where people had faced similar issues in the past and suggested that we move our SQL Servers from a VM to a physical server. We liked the idea and wanted to try it out. We then moved the one particular database from a VM to physical server and guess what !!!......it did work...we could see huge a difference in the application performance and we have left that database on that server till date.:Wow:
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply