High availability is difficult to define, as it can mean different things to different people. Wikipedia defines high availability as "a system design protocol and associated implementation that ensures a certain degree of operational continuity during a given measurement period." This can be simplified to mean "ensuring that your systems are available whenever they are needed."
Is high availability what you need?
Before heading into the land of high availability, however, a great deal of research and planning is necessary. You may, in fact, want to allot the greater portion of your implementation project to the planning stage. Creating a checklist of the areas you need to address and the questions you need answered is a good start.
A high availability topic checklist
Such areas and questions might include the following:
- System resources
- Available disk storage
- Number of CPUs
- Amount of main storage (memory)
- Communications resources
- Communications protocols
- Network configuration and security
- System workloads
- Types of applications (batch, interactive, ODBC, SQL)
- Number of users (local and remote)
- Applications and Database
- Which are "mission-critical?"
- Are work files used?
- Where do the work files reside
- What files have the highest activity?
- Is journaling currently being used?
- Are before and after images necessary
- Is commitment control being used?
- What objects are journaled?
- What objects need to be journaled?
- What is your current backup strategy?
- How will high availability impact your backup strategy?
- How will high availability your security policies
- How will your security policies impact high availability?
- Do you have an idea how your system performs today?
- How might high availability impact your performance?
- Who are the vendors and what options are available?
- How quickly can they implement their solutions?
- How do you determine which one is the better fit for your environment?
These are just a few of the issues to take into account when considering a high availability solution. It may be a little overwhelming once you get started, but there is a great deal of information available on the subject. There are also utilities available to help answer some of your questions.
Where to begin
A good place to start is to gather information on how high availability may impact your current environment. It would also help to get information on any plans for the immediate future that may impact your environment. These might include purchasing new systems, installing new applications or acquiring other businesses.
Another important issue is journaling. Journaling is the backbone of high availability, and it helps to know how it works. IBM has a number of Redbooks and white papers available on journaling, and they have a utility called Pseudo Journal that can help determine how journaling might impact your system.
Many vendors have been providing high availability solutions for some time, and their products are quite stable. They should also have information and utilities for their users, just as IBM does, to help you with your high availability project. You may want to check with other iSeries (IBM i) shops and find out if they have implemented a high availability solution. Ask about any issues they may have had and how they were resolved, and find out about the options they researched and why they chose the one they are using. Also, scour the various iSeries forums on the subject of high availability.
The main thing to remember is that you're not the first one to search out a high availability solution. There is a whole world of information out there and plenty of people who are ready and willing to help. Some will tell you nothing but horror stories, and others who will say you can slam any old option in and go. High availability is no small task, but it doesn't have to be overwhelming and drag on forever. The key to your successful implementation is gathering all of the information available and spend most of your time on planning.
ABOUT THE AUTHOR: Paula Johnson is an IBM iSeries System Administrator and Programmer with 28 years of experience. She began on the S/34 and S/38 as a Technical Writer before moving to what was then known as the AS/400. An admitted "major geek," Paula is passionate about the IBM i, even being known to give them names (and pet them). She is currently in search of her next opportunity. This was first published in November 2009
This was first published in November 2009