November 14, 2007 at 6:06 am
Hi,
I'm collecting information, recommendations about advantages and disadvantages of usage a virtual server for a SQL Server in production environment.
Do you any test results or benchmarks regarding performance, security, availability and so on?
Thanks
November 26, 2007 at 10:56 am
I haven't seen any, but I'm looking for some.
There is one from VMWare, but since they're selling virtual software, not sure how much to trust it:
November 27, 2007 at 1:20 pm
I don't recommend a VMWare instance for a production SQL Server. A virtual machine only gets a portion of disk space, memory, and CPU so performance isn't very good. We had a SQL Server test environment set up and performance was such an issue that it is no longer used. I think virtual instances might be ok for testing functionality only, but I would never use it in production.
February 9, 2010 at 2:59 pm
That's a bit of a generalization, and not really accurate anymore. Virtualization has improved considerably recently, and many production databases perform quite well on a virtual machine.
So the answer is really, it depends on the production database. What are it's requirements for I/O throughput, CPU usage, etc. There are some advantages to using Virtualizaton and also some disadvantages.
If you use pass through storage with a dedicated HBA, the only real tricky part that I have found is the allocation of CPU resources. That's the one part of VMWare that still in my opinion still has some issues that can make performance tuning tricky.
There is a very useful white paper on SQL Server Consolidation, and this includes using Virtualization to consolidate.
Here is the information about the paper:
Consolidation Using SQL Server 2008
SQL Server Technical Article
Writer: Allan Hirt, Megahirtz LLC (allan@sqlha.com)
Technical Reviewers: Lindsey Allen, Madhan Arumugam, Ben DeBow, Sung Hsueh, Rebecca Laszlo, Claude Lorenson, Prem Mehra, Mark Pohto, Sambit Samal, and Buck Woody
February 10, 2010 at 9:29 am
We have about half of our production SQL servers on VMWare. For the most part these are systems that are not highly transactional. I've really had no issues with them over the past couple of years. In the beginning we did have to be careful about which applications shared the same VM host. Things also got better when we began to use SAN as the disk storage medium.
One really nice plus is the ability to clone the VM to create a Dev or Test environment.
February 10, 2010 at 9:39 am
I agree with Linda, we have SQL instances on Virtuals in Test Environment for more than two years. We had problems with Virtuals Host failing which brings down all viruals hosted on that server. I wouldn't recommend using Virtuals in Production environment, no chance.
February 10, 2010 at 2:56 pm
I agree with Donald Denney on this. I went to an England PASS meeting on this two years ago, and the answer was "it depends". The biggest issue with virtualization tends to be capacity planning. If the physical box is configured correctly and the SQL server being virtualized does not have demands that will bring other VMs on the box down, then I believe it can be done safely. Not only that, but for things like SSRS and configuration databases that do not change much, it is probably a good solution for them.
On the other side of the coin though, I do not think that mission critical databases should go on them. There is a lot that I have read about the features of virtualization, but a lot of it has been stated without real-world data, so that leads me to believe they are selling proof-in-concept solutions, which I do not want to risk with my critical data. Also, some features such as virtualization snapshots are not supported by Microsoft under any vendor, including MS. I also do not think that it would be able to handle a replicated environment well either.
The choice is yours, but I tend to think of mission critical heavy OLTP instances as the last ones to be virtualized, if at all.
Joie Andrew
"Since 1982"
February 10, 2010 at 3:21 pm
I'm not a Windows Administrator, so I don't know all of the details or pitfalls related to making VM stable. I do know that we have very little problem with our Virtual Machines staying up or being stable.
Partly that might have to do with a product called "VMotion", which not only can be used to migrate Virtual Machines to other Physical "ESX" frames, but will automatically fail those machine over to other frames in the result of failure.
I've seen where an ESX frame went down, and the Virtual Machines on there migrated to several other frames, with VMotion deciding where they should go based on resource availability and resource needs, and the people using the Virtual Machines had no idea they had even migrated. There is some performance degradation while this happens, but it's much more seamless that failover within a Microsoft Cluster.
Not only does the database instance not shutdown, but the windows OS never "shuts down". It's pretty impressive.
I do have misgivings about he ability of the VM environment to provide truly reliable, consistent resources without adversely impacting performance. For that reason, I too am leery of putting anything too mission critical or performance sensitive on them, especially something that is truly resource intensive.
I started out being a pretty big VM sceptic myself to be honest, but over time I've been shown that a lot of my original fears unfounded.
February 10, 2010 at 3:31 pm
We have about 50 SQL Servers on VMs, mostly production, but some are development. We do not generally put highly loaded servers on VMs, but they are great for "one off" special purpose servers.
I would say that as long as the VM environment is well managed, that there is no problem. In general, our VM servers have no more downtime than "real" servers.
It saves a lot of management effort and money to be able to do physical to virtual migrations for older servers, rather than keeping them on hardware maintenance contracts or replacing them with new hardware. Being able to move from older, failing hardware without having to reinstall OS, SQL,and application software is a huge time saver, especially when it is older software that is not well supported.
February 11, 2010 at 8:17 am
Multi-instancing is IMHO a superior approach. You get hardware and licensing consolidation, streamlined patch/sp processes, a true picture of hardware level metrics, and a better optimization routine for parallel or heavy loads. Unless you NEED distinct operating environments, there is no reason to pursue VM vs. multi-instancing. Since we don't like to share IO or other resources with other kinds of servers, are mindful of HBA limits, and want "true" resource pictures for performance tuning and capacity planning, we'd prefer to not to go down that route. Ideas of using host migration for SQL servers to me is not good - if you are improperly balanced at the ESX level, this technology covers up your more fundamental design problem. Sometimes SQL servers will have heavy load (indexing, jobs, etc) - I don't want that to overload my host, and if I do, I want more resources permanently, not temporarily by moving the server. Otherwise you end up with round robin server migrations instead of solving the problem.
VM is a great way to sell SAN storage, save rack space, get more utilization out of unver-used resources, and cover up capacity/performance planning mistakes. None of which have anything to do with what I am concerned with as a DBA. However, I think you'll find multi-instancing meets the consolidation and cost saving goals of VM, but in a way that keeps performance, manageability, and responsibility in the hands of the DBA.
February 11, 2010 at 8:58 am
Donald Denney (2/9/2010)
Here is the information about the paper:Consolidation Using SQL Server 2008
SQL Server Technical Article
URL for the paper: http://msdn.microsoft.com/en-us/library/ee692366.aspx
February 11, 2010 at 9:10 am
I'm not sure that I think multi-instancing is better than VMs. First you can't balance memory easily with instances. VMs allow you to more easily move memory around. That may or may not fit.
In terms of licensing, I'm not sure that's true either. Depending on your version, there may be no difference between licensing 4 instances and 4 VMs. The licensing has changed by edition, version (SS2K v SS2K5 v SS2K8), and type of licensing. You'll have to check for your situation if this matters.
In terms of running stable environments, one of the large satellite TV providers runs almost all VMs for their servers. A couple of the very heavily used SQL Servers are not on VMs, but dozens of their SQL installations are, including many fairly important databases. They do use a couple of tricks to make the database servers work differently than things like DCs, file servers, etc.
Normal servers are usually 10:1 on a blade. SQL Servers are about 4:1. They also have virtually clustered the SQL Servers and do not allow them to flow with Vmotion. A few float, but many do not, and with dedicated HBAs, this allows failover to another blade with known performance characteristics.
I am also not sure I agree that VMs are there to sell SAN space. A SAN may or may not be a good idea in your environment. I'm torn on them as performance can be better or worse, administration costs are higher, new machines, etc. On the other hand they do centralize storage, allow some interesting DR options with 2 SANs and they can have great performance. You can also more easily grow space, or add space, to a server than with DASD. VMs don't require SANs; you just need to set up good IO subsystems however you run things. The SAN is there if you want to float those VMs to new machines and require shared disk.
I've seen VMs also cause performance problems because sysadmins think that a new VM somehow gets them free resources. You still need to balance and plan for performance. They do allow you to quickly increase hardware if demand changes. If your 2x2 or 2x4 suddenly is too small and you need a 4x8, VMs are a great way to do this. Previously people caught in this situation tended to overbuy machines to prevent it since it is much harder in many companies to get the approvals to upgrade a machine, or buy a new one. As a result we have many under-utilized machines in data centers that also cover up planning mistakes.
February 11, 2010 at 9:40 am
Gary, I'm not necessarily disagreeing, but stating that as a DBA, I don't like to put enterprise level tuning of OLTP and OLAP SQL servers in the hands of non-DBAs. I think all technologies can be "tuned" to their maximum potential, my point is that in practice, that requires a level of expertise and integration between server and DBA personnel that most organizations don't really have.
For example, given an equal choice between a midlevel server, one could VM it or multi-instance it - give the same resources to each. Implement database mirroring as a hot failover solution, get the benefits of transactional integrity compared to hardware level solutions that may not respect transactions. You could cluster either scenario. The performance requirement is that a failover must perform equally to the primary server. I wouldn't want either the VM or multi-instanced machine to share with non-SQL servers. Given that, the additional overhead of VM would theoretically reduce the maximum potential of the machine. With hot swap memory, disks or hba (depending on which you are using), the same machine can expand without downtime.
You are correct that data centers have too many under-utilized machines, and if the DBAs are not using resources well, that is a good motivation to consolidate using VM. The right tool for the right job most certainly applies to which strategy works best for a company, as does understanding whether the infrastructure or DBA personnel are in the best position to maximize resource use of the database servers.
Still, for performance/DR/failover scenarios running SQL2008 EE in heavy OLTP and OLAP, I don't think even the best tuned VM can deliver performance at a lower cost than the best tuned physical, multi-instanced machines. I'd love to be wrong, as I can see the potential for multi-instancing on VMs if the numbers add up!!
April 28, 2010 at 2:15 pm
Running a Production SQL Server that is highly transactional is an extreme issue. We have had customers with tempdb problems, poor or no response, and database corruption (CHECKDB errors). Can you run SQL on a VM? Yes. But, as a DBA, I would only run dev or test, never production.
April 28, 2010 at 2:17 pm
Another point to remember, Microsoft does not support VMWare. You must consider Hyper-V. Again, when your job counts on it, not for production.
Joe
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply