Tuesday, February 1, 2011

Things to Think About Before Virtualizing SQL Server’s Underlying OS, or Adopting a Pit Bull – Part Three


Note:  This is an old article, and while Pit Bulls, in general, have remained largely the same in the meantime (although Gerald in particular has a very distinguished grey face now), SQL Server licensing for virtualized platforms has changed dramatically.  For more information on the current licensing requirements see the SQL 2012 Licensing Guide, or consult your Microsoft Rep.

Part One – Know if you Can, and if You Can, Be Patient
Part Two – Know your environment and be excited to answer questions
Part Three:  You Will be Held to a Higher Standard – It’s Not Fair, but You’ll Need to Live up to it.

We’ve already discussed the fact that there are plenty of people who have put a lot of thought into both SQL virtualization and pit bull ownership, and who have legitimate concerns.  Unfortunately, there is also a lot of misinformation out there, and there are people who have already made up their minds about  SQL virtualization and pit bulls.  This will put the burden of proof on you, to show that your dog or infrastructure is not a problem before alternatives are considered.
Your pit bull and your virtual infrastructure will be judged much more harshly than other, possibly less stable, dogs and infrastructure.   While most people are sensible, kind,  and thoughtful, you will almost certainly encounter people who have read one article, heard a horror story, or worse, tried it and made a mess of it.  Often these people subsequently believe anything that goes wrong in the world is the fault of either pit bulls or virtualization. 

Even if your pit bull is stable, courteous, and just an all around wonderful guy, people may still cross the street to avoid walking past your perfectly well mannered fella who is heeling next to you on his leash.  By the same token, your stable, cost effective, virtual infrastructure may be passed up for physical hardware that is less fault tolerant and less performant, simply because it’s perceived to be impossible to design a stable, performant, virtual infrastructure.  There will always be the guy with a notoriously badly behaved application, who believes that all of the application’s problems are caused by the fact that somewhere down the chain, there is a virtualized SQL server which couldn’t possibly be as stable as the performance and uptime history you’ve provided on said server indicates.   In both of these situations, only time and track record will make a difference, and even then, some people may never be convinced.  All you can do is make your pit bull and your virtual SQL servers, shining examples of the breed or architecture they represent.

PrintFig 1. One of these tricks is made up:   Gerald doesn’t really fetch slippers, he’s far too smart to ever put fabulous shoes in his mouth
Note the sudden improvement in comics, thanks Lisa!
When you’re held to a higher standard of proof, be able to point to resources and data (nicely) to respond to the statements below: 
  • “Microsoft doesn’t support it”
  • “I tried it and it was a disaster, it can’t be done”
    • This one is hard to address tactfully.  My love for all things Dorothy Parker results in the need to bite my tongue to quell the urge to “get quippy” with this one.   I’ll stick to noting that I, personally, can’t run a marathon, but plenty of people do it, and do it really well.
    • In a real life situation, it’s prudent to answer this question in the nicest way possible.  It’s true that virtualizing SQL server used to be a disaster, and wasn’t supported, but recently there have been major advances in best practices for VMware and Hyper-V, stability, performance, and support.  With all the new best practices available, it could be worth giving it another look.
  • “Storage is a disaster on virtual platforms”
    • Storage certainly can be a disaster on virtual platforms, but virtualization can also drastically simplify storage and make it much more flexible
    • If you have good storage administrators, you can abstract yourself from the physical storage layer almost completely.  For me, it’s great to think in terms of IOPS and latency, rather than what raid level is being used, how the disks are attached/presented, and even what storage you’re on.
      • I know it’s very important to a lot of people who are much smarter than me, that you look at dedicated spindles, raid configuration, and attach/presentation methods.  With very high performance systems  it’s important to know more than IOPS and latency, but when we’re talking about vitualization, we’re talking about much smaller machines.  With the current vcpu max at 8vcpus and 256g memory, very high performance machines aren’t candidates for virtualization.  It seems to me that with smaller systems, all of the physical concerns boil down to guaranteeing high IOPS and low latency.  For someone like me who is not a storage admin, I like to be comfortable that a good storage admin will give me the information I can work with which is, for example, “Will this configuration support 10,000 8K IOPs at <7ms latency?”
      • If storage looks local to a virtual machine and you are running vSphere (as opposed to Hyper-V), you can transparently migrate to a different storage system with no downtime – there’s overhead for this, it shouldn’t be done at peak times.
      • You can expand a virtual machine’s disks on the fly, it will depend on the backend storage’s file system whether this is asking for fragmentation.