High Availability in an SAP Environment

Keep mission-critical SAP operations running no matter what.

W H I T E

PA P E R

Your business depends on SAP. What happens if it Stops?

Your enterprise has embarked on a major project to implement an SAP Enterprise Resource Planning (ERP) application. Approval for the project came only after a full executive review determined that it would deliver long-term efficiencies and productive growth for the enterprise. Once developed, installed and coordinated to re-engineer long-standing workflow processes, your enterprise can begin to reap the rewards. Inevitably, as time goes on, the software works its way deeper into the organization, operations come to depend increasingly upon it, and the ERP application becomes a critical factor in your bottom line. Due to its integration into every aspect of your business, any lack of availability of the ERP application or its data represents a serious impediment in the way of your companys effectively delivering world-class service and products to its clients. Given this growing dependency, the need to minimize your servers planned and unplanned downtime becomes paramount. Yet, to-date, neither the System i platform, nor SAP ERP software offer inherent protection against planned or unplanned downtime. Thus, taking additional steps to ensure high availability (HA) is now critically important for your company.

visionsolutions.com

W H I T E

PA P E R

Why is High Availability Important?

Simply stated, high availability is crucial because server outages can result in lost revenue, increased costs and, therefore, reduced profits. For example, the Gartner Group determined that the typical outage at a Fortune 1000 company lasts, on average, for 4 hours, at an average cost of $330,000 per outage. The less your server is available to run your business, the less capital your company can generate from its operations. This loss of capital can result from missed opportunities, unclosed sales, shipments not delivered within a contractual period of time, incorrect or incomplete information for the companys management to make critical strategic decisions, and ultimately poor customer satisfaction. With regard to an SAP ERP solution running on the IBM System i platform, the business parameters for ensuring HA are no different than for other platforms, including UNIX and Windows.
The less your server is available to run your business, the less capital your company can generate from its operations.

Planned outages, such as the following, account for a large portion of system downtime: Backups that require that all users sign off from the system (also known as dedicated backup procedures) Operating system and hardware upgrades File reorganization processes to purge old and deleted records Batch jobs that require significant systems resources or that may require a static image of the database (which is simply a legacy issue) Unplanned outages are usually caused by: Failure of system capabilities and capacities Failure of the CPU or other non-resilient system components Internal or external storage disk failure Software failure resulting in application downtime Human error causing disruption of the application or system Natural disasters such as fires, earthquakes, tornados, or power outages If your operating environment has a single point of failure, any dedicated maintenance process stops the companys operations if the organization has come to uterly depend on a fully integrated ERP application such as SAP. Keeping up-to-date with operating system changes and daily database backup processes is an IT audit necessity, required so that the company can restart its business on a replacement or recovery System i server should the primary server be shut down. Thus, IT departments are often caught in a conundrum. Planned downtime for daily backup processes, as well as for i5/OS CUMs, PTFs and upgrades, must occur to prepare for unplanned downtime that, hopefully, will never occur. Yet, as the SAP application grows in significance within your companys workflow processes, even these planned outages become harmful to the revenue stream.

visionsolutions.com

W H I T E

PA P E R

IT organizations with 10-hour business days and a 24-hour or longer maintenance window every weekend may scoff at this concern about planned outages, choosing to meet their needs with a single server. But what happens if, for example, their executives decide to acquire a company that is located many time zones away, with all user workflows consolidated at one site? Or what happens when the executives decide that competitive pressures require that your company must start to sell and/or support customers around-the-clock over the Web? The lack of a sound business-centric solution addressing unplanned and possibly even planned server downtime is an impediment to meeting these objectives. Thus, planning for an HA solution implementation is not just about preparing for a rainy day. Rather, its scope must also take business growth factors into account.

How does an HA solution fit into the SAP system landscape?

Planning for an HA solution implementation is not just about preparing for a rainy day. Rather, its scope must also take business growth factors into account.

SAP AG recommends that System i customers build an SAP system landscape with at least two System i servers. A single server with multiple Logical Partitions (LPARs) could satisfy this requirement as CPU cycles and DASD arm utilization are, for all practical purposes, isolated in each partition. Following this prescription, the SAP system landscape is organized as follows: Test SAP system T01 1st server (or logical partition) Development SAP system DO1 1st server (or logical partition) Production SAP system P01 2nd server (or logical partition) The arrangement envisioned in this minimal recommendation is two-tier (see Figure 1). Obviously, the deployment of the three-tier SAP solution would include additional System i servers for the application server tier. To support an HA configuration, whether your landscape includes two or three tiers , you must include an additional System i server to hold the copy of the primary or production SAP application database server.

Figure 1: SAP two-tier configuration

visionsolutions.com

W H I T E

PA P E R

When it comes to adding a backup server for HA, if the existing configuration features a second network, used privately for the servers inter-communication activity, such as Transports, you can add your additional server to it as shown in Figure 2. The new System i server will have a duplicate production SAP system installed to build the IFS, Kernel and database server infrastructure to hold the synchronized copy of the SAP systems database server. Note that you can use a homogeneous copy of the current production SAP system to build the duplicate production SAP system for high availability. You can also build a new SAP system from the install process to accommodate the backup servers Local Host Name if this server must also support other network applications.

Figure 2: SAP two-tier with backup

Figur e 0: SA P tw o -tie r wi th backup

What are the Hardware Considerations for High Availability?

As depicted in Figure 2, an additional System i is required. The common question is: how big should it be in terms of CPU, main memory and DASD resources? The typical answer is how much service level degradation can the enterprise tolerate in the event of a system failure? In the case of DASD, there is not much choice: unless you are willing to forgo some applications or modules completely during a downtime event, you need to recreate the same allocation of auxiliary storage currently in use for the production System i server holding the SAP database server. Even if you decide that your business can survive without the use of some functionality and its related data for the duration of the worst downtime event, because different applications and modules often share data, omitting data on the backup server can be dangerous and should be done only after very careful analysis of the critical applications data requirements.
5
visionsolutions.com

W H I T E

PA P E R

You can scale back CPU and memory to some extent, but this action requires a capacity planning study of your current production server. The mirroring software that is used to replicate the database server should tolerate a smaller CPU resource on the recovery server for its own instruction path compared to the production server executing SAP I/O instructions (SAP work processes). However, if you allocate less CPU and memory to the recovery server, when you fail over the production SAP system to the recovery server it will not deliver the service level that the production server provides. Therefore, careful consideration must be made when choosing a recovery server. As for the network connectivity considerations, Figure 2 diagrams a LAN for the SAP GUI access and another LAN for the server access. This is highly recommended for isolating the end-user environment from the transport and mirroring data traffic. It is important to note that the maximum frame size specifications in the routers (if any) that are used for the second LAN addressing scheme should match their respective definitions in the corresponding line and control descriptions to eliminate packet segmentation. In addition, to allow duplex operation, the production and recovery System i servers connection should not go through any hubs. In many cases, SAP customers defer some HA project costs by using a smaller CPW model and lower main memory for the backup server. If they do, they should consider reassigning less-critical client definitions to a secondary instance.
A thought to keep in mind when considering lowering some of the hardware costs of HA: hardware is a one-time expense that can be depreciated, whereas personnel costs are ongoing.

Typically, application servers in three-tier configurations are nothing more than secondary instance profiles specified on a separate System i server (loaded with large amounts of main memory). In the case of isolating client environments from the Central Instance (CI), these secondary instances can still execute on the same System i server as the database server component of the SAP system if there are no capacity issues. The purpose of segregating client environments to secondary instances is so that, when a database server failover does occur, the SAP customer can restrict non-critical clients from executing on the backup server. When the duplicate production SAP system on the backup System i server is started, some or all of the secondary instances are not selected for operation. Only the CI starts with the critical clients will be selected to run on the lower performance backup system. A thought to keep in mind when considering lowering some of the hardware costs of HA: hardware is a one-time expense that can be depreciated, whereas personnel costs are ongoing. When you purchase solutions that fall short of the recommendations made in this white paper, you drive up the costs of operations within your IT organization. Programmers and analysts must spend more time reorganizing the existing configuration to accommodate the smaller, lower performance hardware and explaining to end-user groups why response time is not meeting service levels and expectations consistently.

visionsolutions.com

W H I T E

PA P E R

Is it Possible to Fail over an Active SAP ERP Application?

Yes, you can fail over an active SAP ERP application should the primary server become unavailable. Failing over is an on or off process. The procedure will either work or not. You achieve success by planning and constant testing.
Choosing the most appropriate high availability solution for your SAP ERP environment involves significant tactical, logistical and financial planning.

The first requirement for a successful failover test is the synchronization of the required tables between the production and recovery System i servers. The HA software must accurately track how individual tables are changed by the SAP work processes on the production server. The HA software must then reproduce those changes on on the recovery server. Thus, there must be a utility within the mirroring software that proactively examines the tables, comparing the production image with the backup image, without impacting the SAP and journaling CPU overhead. To secure an easy and error-free failover operation, the HA software must support not only SAP table synchronization, but also i5/OS object synchronization (object ownership, authorization list and IFS directories). Due to the intensely mission-critical nature of HA environments, these utilities should be integrated features within the HA software and not separate code provided by in-house programming staff this further assures the integrity and accuracy of the data. Once you have achieved a secure, synchronized mirroring operation, you can exchange the business operations from one System i server to another using the TCP/IP i5/OS commands and specifications along with the HA software extensions that assist the operations staff. Since the SAP application is a client-server implementation, resolving the database server by host name with the IP address, no SAP GUI client modifications are required even if the recovery System i servers host name is used in the SAP system landscape. The failover scripts offered by the HA provider will guide this process and synchronize the re-direction of the journal readers and SAP GUI sessions from the production server to the recovery server.

Conclusion
Choosing the most appropriate high availability solution for your SAP ERP environment involves significant tactical, logistical and financial planning. With market forces dictating a necessity for round-the-clock, 24 x 365 business operations, eliminating planned and unplanned downtime is no longer a luxury. Implementing the most effective HA solution, then, becomes synonymous with sound business sense and an appreciation for protecting your enterprises most valued asset: its data.

iTERA
15300 Barranca Parkway Irvine, CA 92618 800-957-4511 801-799-0300 visionsolutions.com

MIMIX

OMS/ODS

Copyright 2010, Vision Solutions, Inc. All rights reserved. IBM and System i are trademarks of International Business Machines Corporation. WP_SAP_E_1005

visionsolutions.com