October 18, 2010 at 12:34 am
Not all SQL servers are suitable virtualisation candidates!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 19, 2010 at 9:15 am
1) HIRE A PROFESSIONAL TO GUIDE YOU OR YOU WILL BE DISAPPOINTED, as have so many others, when moving SQL Server to a virtualized world.
2) I have a client with almost 50TB (yes, I meant TERABYTE there) of virtualized SQL Server data. Some systems have performance problems simply due to only 8 virtual CPUs being available currently. Hope that improves. Most systems run just fine, and I note these are very poorly architected and coded database apps too! So peoples claim that SQL Server doesn't work in virtual environment is definitely false. I do agree that some databases/servers do NOT belong in a virtual environment.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
October 19, 2010 at 9:35 am
Virtualization technology is good and can be good enough for most systems. The problem is how it is managed and administered, in this way it is the same as SANs. With limited budgets, less money for upgrades, all companies want MORE!! So the admins are "forced" (some know better, some dont) to put more onto single hosts and then its game over.
It has been the same in every place that I have worked. 1 team is responsible for the SANs, 1 team is responsible for the virtual environments and 1 team is responsible for the databases.
Everyone is trying to make the most of their environment without realizing (or understanding) what the other team is trying to do.
SANs are a necessary evil for shared disks and high availability... Virtual environments are not required for anything specific.
This is why I have always opted for physical SQL servers in production. DEV, TEST, etc can be virtual, but when they come running over saying that the DB is slow with 10 concurrent users, my general responses is "then how is production possibly running with 200 concurrent users?"
October 19, 2010 at 3:07 pm
Just to add my thoughts here:
Brent does have some good material on the advantages and disadvantages of Virtualisation and a bunch of other posts, check them out here:
http://www.brentozar.com/sql/virtualization-best-practices/
I have a client who primarily uses SQL in vSphere for their production boxes and everything runs pretty well. Databases are relatively small though no TB databases.
It does add an additional level complexity when monitoring troubleshooting and it does help to "know thy neighbour" with regard to the guests running on a physical host but running SQL in virtual land can work...It really depends on your environment.
Gethyn Elliswww.gethynellis.com
October 20, 2010 at 11:53 am
Just to add my 2 cents. My entire environment is virtuals with VSphere. I am lucky that the environment was built from the ground up as a virtual environment and not one that currently existed and someone decided to move to virtuals because it is the new wave. The other thing is that I have one guy to talk to about SAN, CPU, and memory requirements for SQL. We are a small but growing company so the next few months and years will be interesting in how our environment grows and any issues that are encountered. One issue we ran into was CPU pressure but because we run daily trace and perfmon counters we have found that most of the issues can be narrowed down to either a bad execution plan or index issue. We were encountering disk I/O issues a lot but we switched to RDM, moved TempDB to its own RAID 10, and did some disk alignment. That took care of 95% of the I/O issues and the other 5% could be mitigated by examining what the user is trying to accomplish and do some work arounds.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply