This article isn’t mean to be an advert for my forthcoming session at SQLBits or the Kent SQL Server user group, both in the next couple of weeks but I suspect it’ll probably turn into one.
Almost everyone has now realised that SQL Server when virtualised works, in fact they can work so well together that we can get flexibility and service levels which are far better than what we had on dedicated physical servers. Yet despite the knowledge the two can work well together I still hear of people who have heard horror stories about virtualised SQL Servers, see environments which suffer from performance issues and meet IT decision makers reluctant to mix the two.
This is no surprise when you think that SQL Server is probably the only piece of software which out of the box can happily use all your server’s resources once a few small databases, small queries and housekeeping jobs have been installed. Traditionally we saw people virtualising their “low footprint” servers, domain controllers, file servers, application servers etc and yet SQL Server is now routinely being virtualised with expected workloads that make it far from being a low footprint application.
In my view hosting your production database servers on a virtualised platform is only something you should do once you have:
- Sized the server’s workload and made sure its a good candidate for virtualisation
- Understood how to defend your server against the memory tricks hypervisors use
- Confirmed, if not configured yourself, the hypervisor to work for you, not against you
- Deployed a DAS/SAN/NAS storage infrastructure which supports SQL Server’s parallel I/O behaviours
In small businesses the person who deploys the virtualisation platform is often also the DBA and if their only previous experience of deploying SQL Server has been on isolated dedicated physical servers then the workload driven contention which virtualisation brings will be a new challenge for them.
In medium sized businesses we may see larger virtualisation platforms deployed but with resource contention and prioritisation introduced to try and make every penny spent count. While they maybe able to afford the SANs, CPUs and hypervisors smaller businesses can’t we need to make sure these expensive resources are configured optimally for our workloads, i.e. we know SQL Server loves taking and keeping memory, it loves parallel I/O work but doesn’t always need lots of CPU cores.
In large businesses we’re almost certainly going to see a different team managing the virtualisation platform to SQL Server, if the virtualisation platform isn’t outsourced to a separate private cloud provider. Are the virtualisation administrators going to know how SQL Server works as well as you do or how your individual deployment of SQL Server is scheduled to work? Almost certainly the answer is no. In those situations the SQL Server person needs to be informed and prepared for dialogue with the virtualisation team, not so they can argue why they must be right, but to explain their point using a common virtualisation terminology.
The points above should give you some insight into what I’ll be covering and why it might be of benefit to you. I’ll post my presentation once its completed and presented, however for those who might be interested in broadening their SQL Server related infrastructure skills it might be the session for you.
SQLBits session, Friday 8th 4pm, link here.