Max Myrick, Author at SQLHA

July 7, 2015

Defending Fort SQL Server

I’m seeing a common theme with a subset of our customers. It goes something like this: An enemy horde is on the horizon and the database team has banded together and barred the gates of Fort SQL Server to keep it at bay or die trying.

Unfortunately, the enemy is “change” and the DBAs have about as much chance of winning as cocker spaniel does in a fight against a pack of velociraptors. It really is just a matter of time.

The particular change du jour that some are stalwartly resisting is the encroachment of virtualization into the hallowed halls of SQL Server. This puzzles me because virtualization is a potentially beneficial change. However, conversations along those lines usually result in a “Keep that virtualization away from my SQL Server!” cry from these DBAs.

In computer history terms, virtualization is by no means a “new” technology. It’s been around for more than a decade. It has already been accepted as the foundation of the modern datacenter and the secret sauce for both public and private clouds. It is also the queen of the fully automated test environment.

Logic, logic, wherefore art thou logic? Can virtualization really be good for everything else, but not good for SQL Server?

Our customers that embrace virtualization and allow us to help them tend to find that it:

Adds almost no overhead (1-2% in most cases)
Provides some nice options for building (and rebuilding in DR scenarios) standardized servers from templates
Gives the only type of failover (either vMotion of Live Migration depending on your invading virtualization horde of choice) that keeps SQL Server’s hard earned self-tuning knowledge
Increases the available options for server consolidation which usually improves both hardware utilization and HA/DR options

That is not to say that the pathway to virtualization is a cakewalk which doesn’t have its challenges. Typically, there is new knowledge to be gained and new skills to master. Service monitoring becomes a must have to thwart the “noisy neighbor” scenario and other resource conflicts. At many companies, the DBAs become more reliant on the IT operations staff for certain tasks they previously owned – up to and including some types of failover. However, none of these is by any means terrifying to IT professionals. This is partially because no other field progresses as fast as computing, and over time we’ve gotten used to the pace of our changing technologies.

My business partner Allan has also seen quite a few of these SQL-under-siege situations. It is one of the main reasons that we are teaming up for a talk about virtualizing SQL coming up on Wednesday July 8 at noon EDT for the PASS Virtualization virtual chapter (http://virtualization.sqlpass.org/). If you are interested, please join us there. Click here to register.

Our goal is to help you understand what long-term benefits Hyper-V brings to the table so you will be leading the team doing the planning and deployment. In the end, a great Hyper-V implementation the best defense of all.

June 11, 2015

Features Should Not Dictate Mission Critical System Designs

I was working up a new presentation for the upcoming 24 Hours of PASS on mission critical system design (a bit more on that later) when one of those puzzles of life we all have cooking away on the back burners of the mind suddenly snapped into focus. The story of that puzzle goes a little something like this…

The development team ships a great feature called ladders for changing those light bulbs in high ceilings. They also have a fashionable feature called yellow polka dot cloth, which is just perfect for those retro 70s swimming trunks and bikinis that are all the rage. And they put in a cleverly-engineered tricycle feature loved by our active 4 year olds. Nothing at all wrong here.

Yet many times I arrive onsite to help a new customer with their mission critical system only to find that they’ve currently got a three wheeled, yellow polka dot, monster truck jacked up on stilts. I always used to wonder just how on earth they ever got to this point.

Now, thanks to last week’s epiphany, I finally understand. There is a natural tendency of humans to map what they need to what they have – regardless of any actual correlation between the two. There’s probably a law of needs way down the list about this already, and if not there should be because it really is true.

I guess this was correct in most natural situations. If a caveman needed a weapon to fight off a sabertooth tiger, picking one that was close at hand would be a critical survival skill. Clearly this is no time to start with a blank page and work through exactly what the best weapon would be to kill a huge, hungry cat that is looking at you like you are the answer to all his culinary dreams.

But therein lies the real moral of the story, and it’s just as true for DBAs.

Under pressure you’ll have to take the existing features which are, after all, designed to implement high availability and disaster recovery. The funny thing is that this is relative cheap and fast, but just always seems to fit like that sweater your aunt knitted you for Christmas – one sleeve too short, one too long, a bit tight around the neck, and never draping just right.

The features that ship in the product are great. However, chances are that if you sat down and wrote out real wants and needs for your particular applications and environment you would find that those existing features can get you only part of the way to success. Suddenly the gaps that you never saw when you just implemented HA/DR features become all too noticeable. The plan becomes a bit more complex and you wind up using a feature for this, part of a feature for that, writing some scripts over here, and adding a bit of custom hardware over there. It starts to be, well, work. But now the solution fits. It just feels right and does what it should when it should.

Of course, some knowledge always helps, and I mentioned that I was working on a new session for 24 Hours of PASS called “The Art and the Science of Designing a Mission Critical SQL Server Solution”. If you’ve ever thought about taking out that blank page and starting from scratch, I believe you’ll find it gives you some fresh new ideas and a nice starting point.

I hope some of you will join me there on Wednesday, June 24^th at 8PM Pacific/11PM Eastern. Alternatively, feel free to try to fend off that big cat with a convenient tree branch – but we both know down deep that it’s probably going to end with one very happy feline.

If I’ve achieved nothing else, I hope you take away that what you really need is rarely what you have conveniently at hand and that you must actively resist human nature to see that this is the case.

Categories