When people like me, with an information technology background, think about SAP, what immediately come to mind are powerful applications able to manage business operations, such as billing. These business applications are developed by a German Company,SAP AG, which is well known and serves many important customers.
Since SAP business application data is normally stored in a relational database, what I would like to do with this post is offer you a best practice to ensure their high availability, taking into consideration also the concurrent need of accessing relational data.
SAP applications normally need at least one server, known as SAP Application Server (which was recently renamed SAP NetWeaver Application Server), so in this post when I talk of SAP as a single word I will normally mean the SAP Application Server. Otherwise I will always write SAP applications. The same approach applies to IBM DB2: I mean the DB2 subsystem if I use the single word; otherwise I will write DB2 database.
SAP application criticality: The need
Today SAP business applications are a key application technology element in many customer information and communication technology (ICT) environments. In addition, it is very easy to find IBM DB2 as the database repository for SAP services. Normally a high number of transactions is executed during the day, and many services are extended during the night, often unattended for cost reasons. More and more services are being offered to customers that require SAP applications and DB2. Normally any of these technology elements may reside in different machines and platforms, and they have to be almost always concurrently available. Interruptions should be limited to the very minimum, both in case of application problems and in case of scheduled maintenance, which must normally be performed during the night or on weekends, when no employees are available. But what happens if there is a crash of the infrastructure, or if the DB2 database needs to be reorganized, for example in order to make recent billing information available?
All transactions are executed in a heterogeneous way, often involving more than one server, not necessarily running in the same type of platform. For example, it is common to see SAP on a UNIX box, while DB2 is located on IBM z/OS in the mainframe. SAP applications and the DB2 database must always be synchronized in order to avoid service degradation due to delays caused by data that is out of date at the time of a SAP application transaction execution.
Such an infrastructure is very delicate due to the resources that must be available at the same time, and it can strongly affect customer business. In fact, if data is not available and updated when a SAP application transaction is executed, delays might be experienced in providing services, with a consequent loss of customer satisfaction. For this reason the described infrastructure needs to be constantly monitored and automated, and all of its elements must be in the desired status time after time. That means our SAP-DB2 configuration has to be always active-active.
Managing the SAP-DB2 infrastructure: Tivoli System Automation
One of the most important tasks for managing this infrastructure is automating its start and stop without any manual intervention, taking care of the correct start and stop sequence for every involved component. Another extremely important thing to consider is to avoid having SAP active if DB2 is not active. Otherwise there could be a lot of transaction errors that the customer is unable to repair. This situation can happen if there are problems in DB2, or more often if DB2 needs to be reorganized.
IBM Tivoli System Automation (TSA) can cover these needs. In particular, if the DB2 database is on the mainframe,IBM Tivoli Workload Scheduler (TWS) can help with its end-to-end scheduling capabilities.
Normally TSA allows clients to define multiple applications or application groups with the scope to manage their high availability. This is performed through automation policies, which can be defined using the intuitive web console, or through a batch or command line. In many situations when the type of infrastructure is very complex, TSA also provides policy packages ready to be implemented against the infrastructure. This is exactly the case of a SAP-DB2 infrastructure.
In the picture above you can graphically see how the policy is defined so that TSA can take care of rules and actions defined in the policy automatically in case of problems.
When the infrastructure resides in a distributed environment, often clustered, then Tivoli System Automation for Multiplatforms takes care of the entire high availability environment, managing start, stop and synchronization activities.
Best practice with DB2 for z/OS: Tivoli Workload Scheduler
Now let’s see how Tivoli Workload Scheduler end-to-end can help TSA in managing the infrastructure high availability when the DB2 database resides on the mainframe.
As we said before, there are two possibilities:
- Problems in the application or in the database
- Planned or unplanned maintenance in the DB2 database
In both situations, SAP must be stopped before DB2 and later restarted after DB2. TSA takes cares of the start and stop, while TWS takes care of the sequence.
The above picture gives you an idea of how easily the best practice was realized. Since SAP must be stopped first, TWS starts a TSA operation in the server where SAP is running to perform the stop of SAP. When the TSA job is finished, TWS starts the successor TSA operation on z/OS in order to stop DB2. When all corrective actions or needed maintenance have been done, there is the opposite TWS occurrence, which first schedules a TSA operation in order to reactivate DB2 on z/OS and then restarts SAP on the appropriate server through a second TSA operation. This way SAP and DB2 will always remain synchronized, without any manual intervention. In fact, in case of problems or maintenance needs, an unavailability event can be automatically generated. This event is intercepted by TWS, which is responsible to start and end the entire end-to-end process.
I helped one of my clients to implement this specific infrastructure with DB2 on z/OS. The client was very satisfied and decided to be a client reference, so I am sure others can take advantage of this easy implementation too.
Have you found similar high availability needs with some of your customers? This doesn’t necessarily have to be with SAP and DB2. I would be interested to learn about other examples of best practices to ensure high availability of a particular multitechnology infrastructure. Leave your comments below and we’ll discuss.