Achieving High Availability - Part 1 1 2 3

The problem with this is that the geeks, that's us, that implement/research these solutions understand what they are.  Armed with that, as soon as someone says high availability, we are off researching the cost of implementing clusters with a warm standby server all of which can fail over to a mirrored cluster at a remote location.  You are now thinking that you are really lucky because management sees things your way and you can spec and purchase all of the latest and coolest hardware.   You've already told the managers that it can be done, but it will cost extra.   They've given you the typical "whatever it takes" answer.  You spend the next few days or weeks researching what is available, talking to vendors, and getting prices.  You've sat down and put together the ultimate in high availability solutions.  You are going to cluster all 15 of your production servers, provide a warm standby on site for the most critical 5 servers, and establish 5 large clusters at a remote location to cover the possibility of a complete meltdown at your site.  Price tag?  Somewhere in the 5 digits.  You've looked it over and can't find any holes in it.  You congratulate yourself and head for the managers office.

A few minutes later you are beating a hasty retreat with the boss screaming at the top of his lungs about your sanity and why you wasted the last few days/weeks of time coming up with something that is clearly impossible.

What happened?  You had all of the bases covered.  The problem is that you listened, but you did not hear.

High availability is extremely subjective.  High availability for that DSS database the marketing department uses every day is much different than when you talk about high availability for Amazon.com's online order/fulfillment system.  There is a world of difference.

Amazon's database gets hit 24 hours a day, 7 days a week, 365 days a year.  If it goes offline, customers can't order.  Amazon loses money for every second it is offline.  Customers can get frustrated and go to a competitor that is simply a click away.  Some of these customers might never return.  Put simply, Amazon can not afford to have its ordering system offline for even seconds every day.  (I have not seen what Amazon runs on the backend for a solution and so this is speculation based upon what they require.)  You are going to find clustered database servers sitting underneath the site.  (Amazon runs Oracle by the way, but this doesn't mean SQL Server can't accomplish the same thing.)  You will find multiple clusters underneath the site.  The application running on the site more than likely writes to multiple clusters simultaneously and a set of backup clusters is probably kept in synch via replication.  They are going to be running some sort of remote clustering software to allow them to mirror the data onto remote servers.  The application is coded to automatically switch over to an alternate server in the event one cluster goes down.   All of this hardware comes at a very high price.  But, it ensures that Amazon.com is open for business 24 hours a day, 7 days a week, 365 days a year.

The marketing department arrives at 8 AM, goes to lunch between 11:30 AM and 12:30 PM, and goes home at 5 PM.  The database is used simply for decision support in analyzing the effectiveness of certain promotions that have been run.  This analysis is just one piece of the work the marketing department does.  For this reason, the server could die at 5:01 PM every night as long as it was back up at 8 AM.  It can also go offline during the day for short periods of time, because the marketing department can do other tings if it is down.  Put simply, high availability in this case would be that the database has to be available for an appreciable amount of the time between the hours of 8 AM and 5 PM.

I know many of you saw this article and thought: "Cool!  He's going to walk through all of that neat technology and talk about standby's, clusters, and some of the products and techniques out there."  You'll have to wait for the next article for some of that.  I would hope that I have everyone's attention at this point.   All of that neat technology is rarely needed!  I'll duck for a moment as everyone picks up something to throw.

What we will talk about in this article is everything that surrounds high availability.

Achieving High Availability - Part 1 1 2 3