Thursday, January 27, 2011

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

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:  The Good:

There will be people who have done research on Virtualization or Pit Bulls and who have legitimate concerns and questions for which you should have answers before “going live.”

These are awesome people.  They know enough to know that there are things that can go very wrong with any given virtualization implementation or individual pit bull, but if you provide them the information about your particular virtual infrastructure, or your big goofy dog, they will look at the evidence with a fair mind, and often ask questions  that lead to a better infrastructure going forward.  In the case of pit bulls, It’s perfectly sensible to want to know if your pit bull is dog aggressive (and you should be sure to know this -- if he is, you need to know how you will handle things like walks, vet visits, and other multiple dog situations).   It’s sensible, not insulting, to want to know if your pit bull can be trusted around small animals (Pit Bull Terriers are Terriers after all).   Personally, I’d also want to know how he got so handsome, but that’s just me.  You put a lot of work into training such a well-mannered gentleman, take the time to show off what a great example of a sweet, stable, dog he is, and show he’s a great ambassador for the breed.


Fig 1.  This is what happens when technical people attempt to draw  their own cartoons –
Also, that’s a pit bull not a kangaroo… no disrespect to kangaroos who probably also have a lot of good ideas.
With respect to virtualization, it’s smart of a DBA, or application owner, to ask questions about your virtual infrastructure, and you should have visibility into, have tested, and be able to answer those questions.   Below are some examples of questions I get that I find comforting to know other people are thinking about before jumping into virtualization.
  • Storage:
    • What does the back end storage look like?
    • What do you consider acceptable latency?
    • How many IOPs at what size, can it do without generating big latency?
    • If the disks are shared, how much overhead does it have for my I/O?
    • What is the storage connectivity?
    • If I need to physically separate logs from data files for DR or performance (the tide seems to be turning on the performance question regarding logs and data, but it’s still a deal breaker for many DBAs, and a serious concern for DR), how will that be done?
    • Will the VM think that storage is local to the VM, or will it be directly mapped? 
      • If it’s directly mapped, what technology is used to map it?
      • If it appears to be local storage, how is it presented to the Host server
      • If it will be presented to the VM as local, can I do live storage migration?
      • If it appears to be local to the VM is there still fault tolerance on the storage side?
      • If storage is directly mapped, will a host failover cause any loss of storage connectivity?
  • High Availability
    • Is the cluster configured for HA?
    • Has HA been tested properly?
    • If only some of the machines in the cluster are fully licensed for SQL server, has DRS (or the Hyper-V equivalent) been turned off, so that servers can’t migrate automatically (which would result in being out of licensing compliance)?
    • If my SQL server has mirrored databases, where will the mirrors run? 
      • Will the mirrors be kept on physically separate Host servers and storage from the primary?
  • Resources:
    • Do I get a dedicated OS per instance?
    • Is network failover configured and tested?
    • How many CPUs/how much memory can be dedicated per VM.
    • Does the host server have at least as many cores per socket as the number of VCPUs to be provisioned per virtual machine?  You can comfortably over-provision the total number of vcpus allocated on the host with respect to the number of physical cores.  However, if your physical machine has 4 sockets, each with 4 cores, if you allocate more than 4 vcpus to any individual VM, spanning more than one physical socket may reduce performance by reducing the number of opportunities to schedule threads across sockets.
It may go without saying (but I’m going to say it anyway, and I’ll be posting more on the subject later), you need a good dialogue with the people who run your storage and virtualization tiers.   If you’re the kind of DBA who believes that DBAs are from Mars, and Storage Guys are from a completely different solar system (you know who you are), think really hard about whether you’ll be able to pull this off.   Ideally, you’re able to at least see eye to eye with the guys who keep the rug under you.

No comments:

Post a Comment