Achieving High Availability - Part 1 1 2 3

High availability is simply creating an environment that keeps your systems online to prevent loss of business continuity.  You need to put together a system that will keep the business users up and running.  If the business users don't know who the DBA or system admin is, you are doing your job.

In the example above, you can see what this means.  For companies like Amazon.com, high availability is defined as the system never being offline.  In the other case, it means the marketing department fires up their applications at 8 AM every day and shuts them down at 5 PM every day without ever having the system unavailable.

Implementing high availability

There are a lot of questions that need to be asked when considering a high availability solution.

The first question you need to ask is if you even need to do anything.  Let's face it, the hardware we run in our environments is pretty darn good.  If anything is going to fail, it is a disk.  We use RAID and hot pluggable drives for this. (You do use RAID and hot pluggable drives, don't you?)  This allows us to keep a system running through the most common failure.  Systems come with redundant, hot pluggable fans and power supplies.  This makes even the normal server rather impervious to failures.  Many of the vendors are now guaranteeing 99.9% uptime on their hardware.  Do you really need to squeeze that other .1% out?

The next question to ask are what are the availability requirements.  We've all been there.  The only answer you will ever get is: 24 hours a day.  That is unrealistic for the majority of systems.  You need to determine how the server is used, by whom, and during what time frames.  You also need to determine what function it performs within the business.  Can the system go down for an hour, a day, etc. without monetarily impacting the business?  You could be looking at a system similar to the customer DSS server noted above and still have the manager tell you it has to be up 24 hours a day.  How do I handle this?  I simply ask the manager who needs to approve the several million dollars I'm going to have to spend to achieve that requirement.  You'd be surprised how the tune changes when they get hit in the pocketbook.

After getting the answers to the first 2 questions, you are now in a much better position to determine what you need to look at.  If it turns out that you do need to implement something beyond the normal hardware you have, you have to get a budget.   This is critical up front to minimize the frustration factor and wasted effort.   It doesn't have to be accurate.  It can be adjusted down the road.  The point is that you have an idea of what you are working with.  Make sure you have some ballpark figures to hand them when you do this.  It does no good for them to tell you that your budget is $20,000 when a server is going to cost you $50,000.  This also helps set the managers expectation.

Once you have a budget to work with and an idea of what the availability requirements are, you can get to work.  At this point, know yourself out!  The first thing you want to do is determine the minimum setup you need to achieve the goals.  Then put together the next step up from that solution.  Finally, put together the absolute high end.  (You never know, you just might get lucky!)  When you put these solutions together, make sure you clearly document what the purpose of each component is and how that will help achieve the availability goal.  This listing gives you a very good comparison between the 3 solutions you are presenting.  The managers can then make an informed decision to increase the budget, decrease the budget, or keep it the same.  They also have the information required to tell you which solution is being approved.

Wait a second, you've forgotten something!  All of this availability solutions are worthless if the applications can't take advantage of them.  It does no good to fail over to an alternate server if the applications don't know what that server is or are not coded to handle a failover.  You need to put together a complete list of applications hitting that server and determine how they will react in each of the proposals you are presenting.  Make sure to note which applications can and can't be modified and how extensive those modifications would need to be.   The amount of recoding that is required for the applications to work with your system could make the difference between selecting the low end plan and the high end plan.

Achieving High Availability - Part 1 1 2 3