Complexity Isn’t Necessary, or Occam was Right

Bill Cole

Bill Cole – Competitive Sales Specialist,Information Management, IBM

I have spent a lifetime in IT hiding the complexity of environments from my users.  When they’re sitting comfortably in front of their screens, they don’t need to know what we’ve done to build that environment any more than just how their car works.  In fact, it’s in their best interest that they don’t.

I feel the same way about clustering systems.  Over the years, there have been numerous forms of clustering available to us.  Think about the System 360 and all its successors, including the System Z.  They’re all just clusters of processors doing specialized tasks.  It’s that model we should emulate when we talk about clustering distributed systems.  While it can seem to be magic, it’s not.  It may be very complex at some level,  but we need not expose that complexity to the world.

And that’s why I think DB2 pureScale is the best clustering solution available.  It is simple, easy to use and you can understand it without spending two weeks with the development team.  No special hardware considerations.  No asking the experts for the best software, hardware and network combinations.  No additional complex software.  Just create your database with the pureScale option and you are in business.

For all that, you can have a pureScale cluster that’s exactly one system wide.  Why,you ask? Easy.  You’re not paying any penalty (or dollars) for the option and it gives you that comfy cushion knowing you can add a second or third node at any time for patching , platform maintenance -or to handle some ad hoc load.  Just start up that second node, make sure you’re in sync and you’re ready to go.  Simple!  Makes you look like a genius to management with all that forethought.  It’s not a choice of active-active or active-passive.  It’s a choice you can make when you need to.  You don’t worry about the directions to Dallas unless you’re going to Dallas, right?  But you’ve got that map app handy just in case.  Same thing here.

I spent more than a decade building and tuning clusters with competing software.  That was a struggle.  The complexity was never hidden.  Instead, it was – and is – viewed as a litmus test of your technical acumen ability.  Can’t understand it?  That’s your fault!  Only the cognoscenti need apply.  It requires that you understand not only the database, but how the operating systems deals with the database, network & disk, how the disk subsystem works, and how the network is configured and what that means to the overall environment.  Phew!  And the required system setup is now considered a gigantic security risk, without an answer.

And then there was tuning and troubleshooting.  Let me tell you it wasn’t easy.  Those activities will turn your hair white. And the answers most often lie with applications using the cluster.  Change the application to be cluster aware.  Really?!  Then the application isn’t actually portable.  Why did a node crash?  It was a network or disk blip within one of the nodes.  Really?  How do you know?  I just know.  Trust me…….  See what I mean?  (I’ve had those very conversations.  It’s uncomfortable for everyone.)

pureScale doesn’t require any of that magic.  It’s built on the proven principles we’ve used for years on System Z.  Even Larry Ellison thinks it’s cool technology.  Interesting endorsement, eh?   pureScale simply requires that you create the database with the proper option and DB2 takes care of the rest.  There’s no magical heartbeat to worry about.  No disk communications issues.  Better yet, there’s no additional software to install, manage and patch.  It’s just DB2.  What could be easier?

What about performance tuning?  DB2 pureScale for LUW scales almost linearly.  First, there are no application changes required.  If the application runs well on a single node, it will probably run just as well on multiple nodes.  Unlike other systems, pureScale is aware that it’s running in a cluster environment so it makes intelligent choices about optimizing queries and using buffer pages.  The autonomics built into the database monitor the activity and make adjustments on the fly.  Better adjustments than we’ll ever be able to make, too.

What about node failures?  Clusters aren’t immune to nodes failing – or being failed.  It’s how the environment prepares for and handles the failure that counts.  pureScale won’t lose transactions due to most types of node failures.  It won’t take hours to re-establish connections and recover the database state.  It knows the state of transactions and locks and blocks globally so the recovery is within a few heartbeats.  The world doesn’t stop while the system recovers.

So what does Occam have to do with this?  Remember what Occam’s razor stands for – I’m paraphrasing here – The simplest solution is the best.  I like that.  It appeals to the couch potato in me.  The geek in me argues about it.  After four decades in IT, I’ve come to treasure simplicity where I can find it.  Or make it.  Or hide it.  Being the “little man behind the curtain” isn’t comfortable.  DB2 pureScale for LUW gives you Occam’s simplicity.  After all, you’ve got an enterprise to keep running.  Let the database manage itself so you can make those contributions to your enterprise.  It’s much more rewarding than reading through countless screens of pointless performance stats.

Bill Cole on Twitter : @billcole_ibm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: