SAP Applications on Windows Server 2008 R2 High Availability Reference Guide

(1)

SAP Applications on Windows Server 2008

R2 High Availability Reference Guide

Authors

Josef Stelzel, Sr. Developer Evangelist, Microsoft Corporation, [email protected]

Summary

This paper describes how to implement a high availability solution for SAP applications on Microsoft® Windows Server® 2008 R2. It is written for developers, technical

consultants, and solution architects. This paper introduces the technologies and architecture used, describes various high availability scenarios, and discusses the implementation process. This paper also contains links to advanced features and technical topics including disaster recovery methods.

Note: Access to some of the linked information might be restricted such as SAP notes available at the SAP Service Marketplace at https://service.sap.com. Access to this Web site is available only to registered SAP customers and partners, and requires a user name and password.

Microsoft – Collaboration Brief June 2010

(2)

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Microsoft, Windows, Windows Server, the Windows logo, SQL Server, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Applies To

• SAP NetWeaver 7.0 • SAP NetWeaver 2004

• SAP Business Suite (mySAP ERP) • SAP Application Server

• SAP Replicated Enqueue • SAP System Central Services

Keywords

SAP NetWeaver, disaster recovery, high availability, SAP Application Server, SAP Replicated Enqueue, planned downtime, unplanned downtime, SQL Server 2005/2008 R2, Windows Server 2008 R2

Contact

This document is provided by Microsoft Corporation. Please check the SAP

interoperability area at www.microsoft.com/sap and the .NET interoperability area in the SAP Developer Network at http://sdn.sap.com for updates or additional information.

(3)

SAP Applications on Windows Server 2008 R2 High Availability Reference Guide iii

Executive Summary

Business applications are central to a corporate IT operation. All corporate business processes are supported by software solutions that help to better plan, process, or communicate in all business related tasks. Consequently, any service failure has an immediate and direct impact on corporate business results. This often decreases revenue and can damage the corporate image.

This is especially true for SAP applications as corporations increase their dependencies on a productive IT environment. Enterprise Service Architecture (ESA) and the global network of interacting companies have increased both uptime requirements as well as the number of IT components that are ultimately needed to fulfill business requirements. As an increasing number of companies join global networks, there is always a time zone that utilizes a computing service. While in the past, centralized application systems like SAP R/3 have been used, ESA orchestrates the use of service providers in order to achieve a larger task. Those services can be distributed inside or outside a company and need to be available.

High availability of mission critical applications has always been the focus for SAP infrastructures. The starting point for increasing availability traditionally has been to address the loss of a critical hardware resource that could generate downtime until the computer system is available again. More solutions have been developed over time to address other problems like downtime due to operating system defects, downtime caused by data inconsistencies, or downtime caused by disasters like earthquakes, floods, or terrorism. Even planned downtime, which is needed to upgrade systems or install patches, is contrary to the requirement to have an application service consistently available. However, planned downtime does reduce system vulnerability and increases reliability.

This guide describes the solutions that address the various areas of availability for SAP on the Windows® platform. It helps to identify the cause of potential downtime and provides the technical strategy to reduce or eliminate it. In addition, this guide provides solution description references that help the reader understand the technology and quickly find assistance.

Microsoft® has a long history of providing a comprehensive portfolio of solutions for protecting enterprise class applications like SAP. Microsoft Windows Server® 2008 R2 offers even more functionality than previous versions with clustering, geographic

distribution, and operating system security. Improved network configuration functionality, performance enhancements, and storage subsystem management included with

Windows Server 2008 R2 make it easier to work with the latest technology from

hardware partners. As a central component of Windows Server 2008 R2, high availability makes managing the complexity of modern infrastructures both effective and affordable.

(6)

High Availability Considerations

High availability refers to all technical or conceptual solutions that are used to improve the application availability. For the purpose of this paper, availability is defined as: usable for the intended purpose of supporting corporate business processes.

Issues with business application availability can have many causes. These causes range from hardware problems to planned downtime due to patching or installing upgrades, to disasters that happen periodically on a larger scale. How to achieve optimal high availability is not always easy to answer. A hardware problem protection solution might not help protect the hardware from possible relational database inconsistencies. The goal of this white paper is to identify the various reasons for the lack of SAP application availability and describe the solutions available to safeguard these points of failure. The intent of this paper is not only to emphasize the benefits of high availability

solutions, but to also identify the potential risks and side effects. When several options are available to solve the same problem, this white paper will help the reader decide which solution is optimal.

Critical application availability requirements

SAP applications are typically used for business critical processes or processes that are essential for maintaining the company workflow. Additionally, SAP applications often directly exchange data with external companies. For example, this is done to process orders electronically or to validate external data such as with credit card validation. The availability requirement for such applications has increased to nearly 24x7x365.

It is primarily corporate globalization and Internet communication that has generated the increased availability requirements. No company can afford to manually track goods, maintain accounting, or control the financial streams. Having the application services available whenever the business process needs them is a necessity. Unavailability directly impacts revenue and reputation, and can even threaten the existence of a company. In addition, some business sectors like the financial sector have laws and regulations that require the corporations to operate their core applications in a failsafe and reliable manner.

Classes of availability problems

While the consequences of losing a mission critical application service for a company are always the same, the reasons for an outage are very diverse and can have a multitude of causes. This ranges from planned downtime for maintenance reasons to a disaster striking an entire geographic area.

In order to implement rational protection against a potential problem, the nature of the problem must be identified. The typical problem types are listed in the following sections. The associated class of solutions with each problem type is discussed in more detail in subsequent sections.

Loss of physical resources

One of the more obvious reasons for an application service loss is a required hardware resource failure. Physical resources are not only servers, storage, or network

(7)

SAP on Windows Server 2008 R2 - High Availability Reference Guide 7

Logical errors and inconsistencies

While many computer system hardware failures often directly and immediately generate unplanned application downtime, there are also problems that can cause logical errors, glitches and spikes during operation, and data inconsistencies. A random memory problem might for example cause data block corruption that potentially might only be discovered the next time this data is accessed. Accidental data deletion or file corruption caused by a computer virus is another example of logical errors.

In many cases, the effect of these problems is not a hardware failure, but system

degradation. However, since there is no way to predict when the system will use the data again, a potential problem might arise at any time during normal operation. Real

application downtime is most often created during the process of recovering, such as when restoring the last backup or cleaning database problems manually. Since the data exists only once, maintaining data consistency is a crucial part of the availability concept.

Disasters

Disasters like fire, flood, hurricanes, earthquakes, and terrorism can instigate the loss of all IT systems in a data center. Problems of this scale might not be sufficiently addressed by having enough redundant hardware in one location. Besides having a proper

geographical distribution of computer systems for the continuation of a critical

application, typical questions include how to synchronize the data between the different sites and how to plan for the real event. In addition to a technical solution, the complete solution requires good planning skills and an in-depth knowledge of the applications and organizational requirements.

Solutions that address the problems discussed are considered disaster recovery solutions rather than high availability solutions. Although, disaster recovery solutions might employ typical high availability techniques like clustering or database mirroring as part of a recovery plan, they clearly have a different scope than solutions that protect against a simple server hardware failure.

Planned downtime

Planned downtime occurs at an intended and often appropriate time, most likely at a time of low application usage. Planned downtime is typically implemented for server and software maintenance, upgrades or migrations, and changes to or the testing of critical configurations. Ironically, this maintenance helps to improve the computer system stability and security by eliminating known problems and by maintaining system resources. However, this maintenance does require application downtime.

This white paper describes some architectural concepts that can help to minimize or eliminate planned downtime for typical SAP application tasks. However, proper planning and change management are still the main reasons for planned downtime. Therefore, it might not be possible to eliminate all planned downtime.

Service level agreements

As shown in the following table, availability measures throughout the IT infrastructure help administrators to determine which application service requires what level of protection. While the loss of a test or a QA system might impact the work in an IT department, the loss of a productive system almost always impacts company processes and outbound communication. Since improving availability is not without cost, it makes sense to focus on the most critical applications.

(8)

Note: To avoid user interruption, all dependencies must be protected as well as the primary application services. If a productive system is integrated into an IT infrastructure, this infrastructure is also critical as is a potential data provider or data consumer in the productive system. Any downtime associated with these dependent systems will interrupt the primary application services as well.

Availability level Application

Standard Application services and infrastructure components that can fail for a short period; typically one to two days without business impact. Standard often also implies a definition of minimum protection like using reliable servers, hot pluggable components, and so on.

High availability Applies to applications that need to be available even when a critical hardware resource is lost. Logical errors and loss or inconsistency of data needs to be addressed and a planned procedure for making the application service available again in case of a problem must exist. The duration of the outage has to be minimized.

Mission critical The application service is absolutely critical for the business processes. A service loss, even for a short period of time, might have a high financial impact on the company. All measures for protection must be taken.

Table 1. Service level agreements

Availability measures

In order to measure and quantify computer system or application availability, the following formula is used:

Availability = 100% * achieved availability / planned availability

Availability is defined as the percentage that the application was used for an intended purpose. Defined availability values like 99.999 are often used in marketing as a solution quality indicator. The following table shows the assumed unavailability for various typical values.

Availability Achieved Planned Maximum possible downtime

Percent Days Days Days Hours Minutes

95 346.75 365 18.25 438 26280 98 357.7 365 7.3 175.2 10512 99 361.35 365 3.65 87.6 5256 99.9 364.635 365 0.365 8.76 525.6 99.99 364.9635 365 0.0365 0.876 52.56 99.999 364.99635 365 0.00365 0.00876 5.256

(9)

High availability solution risks and side effects

Improving the availability of an application service is a complex and intense task. The higher the requirement is, the higher the effort, cost, and complexity of the solution. When the system design requires the implementation of any high availability solution, it becomes a factor for the high availability assessment. This can cause downtime due to the emergence of new processes such as failover testing or disaster emergency training.

Increased complexity

Increased critical application loss protection using hardware redundancy, mirroring technologies, snapshots, clusters, and monitoring solutions always increase the

complexity of an IT system. The disadvantage of complexity is twofold: It costs more to maintain and operate and it bears additional risks. A well educated staff must be available around the clock in case potential problems arise. Good planning, proper IT processes, and good communication between the teams in the IT department are also critical for reliable and secure operation.

Higher costs

Improved application service availability always requires more effort than standard solutions. Hardware failures might only be addressed by providing redundant servers that can be used in case of a failure. High availability software solutions need to be purchased, installed, and maintained. IT personnel need to be trained and IT processes must reflect the extended capabilities. For example, IT personnel need to periodically test and verify that the high availability functionality works. Even support from external providers often must be structured toward the increased requirements. Shorter response times and dedicated support offerings for improved availability carry higher price tags than standard offerings.

The cost of implementing high availability solutions increases exponentially as the expected level of protection rises. While server clustering or database mirroring are standard high availability technologies today that can address problems of a single computer system, extending those solutions into a disaster recovery concept adds more costs. These additional costs include wide area networking, additional facilities and staff, as well as the additional associated operational costs.

Generally, it is relatively easy for organizations to have inappropriate expectations regarding availability targets. It is also easy for organizations to demand higher levels of availability than they are actually willing to pay for before the cost implications are understood.

The cost implications of most availability solutions include, but are not limited to, the following:

• Hardware • Software

• Network infrastructure • Training

• Serviceability and support • Operational costs

(10)

Hyper-V virtualization and availability

As server virtualization technology and supporting hardware have matured to enterprise-level reliability, performance, and functionality, businesses are moving more and more of their critical applications, such as SAP applications, to virtualized environments.

With this move, new storage and IT requirements as well as opportunities to significantly improve overall application availability in planned or unplanned scenarios emerge. Although a full discussion on virtualization is outside the scope of this document, various virtualization techniques for high availability will be introduced as appropriate.

Microsoft Virtualization provides a new way to install SAP applications on a physical server using the Windows Server 2008 R2 Hyper-V™ role. Rather than using a physical server for each application, multiple applications can be consolidated to a single physical server onto individual virtual machines (VMs) in a virtual environment. With this setup, clustering techniques can be used to provide high availability.

However, with virtualization the requirement for maintaining the highest level of availability is even more important. This is because a physical server in a Microsoft virtualized environment typically holds many virtual machines. Therefore, if the server was to fail, many applications would fail with it. To deal with this issue, several new solutions for virtualized infrastructures have been developed based on existing methods to reduce downtime. These virtualized high availability solutions discussed later in the paper include:

• Unplanned downtime solution: The VM unplanned downtime scenario is still addressed by Windows Server Failover Cluster (WSFC). The only difference exists in the virtualization layer where the agents can now migrate the VM VHD files and then restart the VM on a new server after a failover has occurred.

• Planned downtime solution: The implementation of Live Migration has significantly improved the planned downtime scenario as maintenance downtime can now be avoided altogether.

• Logical errors solution: Logical errors that occur inside a VM such as unintended file deletion and data corruption are addressed with the Hyper-V snapshot feature. • Disaster recovery solution: Disaster recovery solutions for Hyper-V now

incorporate storage replication and WSFC in geographically dispersed installations.

Guest clustering

Also available with Hyper-V is the ability to configure a WSFC between two VMs so that the cluster service runs in the guest operating system. One advantage of this

configuration is that it provides the ability for an entire test lab for cluster services to exist on one physical server. Because only one physical server is required, this configuration would reduce costs.

While the VMs on a guest cluster could feasibly be located on a single physical server, this setup would create problems if the high availability of an application inside this cluster is important. Since the application cannot survive the failure of a single server if both of the VMs in a guest cluster reside there, a configuration with the VMs located on two physical servers is required for high availability. Please note that when using guest clustering, the type of storage used for the cluster disks is restricted to iSCSI.

(11)

Figure 1

More information about support for SQL Server® in a guest cluster environment can be found at:

http://support.microsoft.com/kb/956893

A detailed description for how to configure a Hyper-V guest cluster can be found at: http://blogs.technet.com/b/mghazai/archive/2009/12/12/hyper-v-guest-clustering-step-by-step-guide.aspx

(12)

SAP Architecture and Requirements

High availability always requires a comprehensive analysis of potential risks and the implementation of appropriate measures to protect against those risks. Technical

solutions that protect the application against a loss of critical hardware resources require detailed knowledge about the workflow and requirements of the application itself. The following section describes the general SAP infrastructure architecture options and the basic protection requirements provided by the architecture against the loss of availability.

SAP NetWeaver and its components

As shown in the following figure, SAP NetWeaver™ is an application and integration platform that consists of several individual components. In the most cases, the SAP Application Server (AS) is the technical base for the individual functions of SAP NetWeaver.

Figure 2. SAP NetWeaver framework

For user and information integration, SAP NetWeaver uses the SAP Enterprise Portal (EP) and SAP Business Warehouse (BW). Data is also integrated by the SAP Master Data Management (MDM). By using the SAP Mobile Infrastructure, user integration can be extended to wide variety of remote devices. Process integration is performed by SAP Process Integration (PI), formerly known as SAP Exchange Infrastructure (XI).

Enterprise service architectures are made possible by the integration of people, information, and processes, and are the foundation of a new breed of applications.

(13)

A downside of this flexibility is that it increases the dependency on a greater number of components in the infrastructure in order to make a service available.

Note: Because of the composition of enterprise services to business applications, all service providers in use must fulfill the same level of protection in order to make the composite service highly available.

The following figure shows the SAP NetWeaver platform from a technical perspective in order to show how high availability could be implemented. Besides the SAP AS for the Enterprise Portal, Master Data Management, Business Warehouse, Process

Infrastructure, or Mobile Infrastructure, there are also standalone engines and surrounding support systems. While the Internet Transaction Server today is mostly replaced by the Internet Communication Manager, a component of the SAP AS, there are often standalone gateways for RFC communication or the TREX search engine. Typically, SAP NetWeaver is supplemented by an installation of the SAP solution manager, a SAP NetWeaver administrator, and the SAP NetWeaver development environment.

Figure 3. SAP NetWeaver software development environment

SAP Application Server architecture

The SAP AS is the technical base for SAP applications. While the former R/3 AS only supported the ABAP programming language, the SAP AS supports Java as well.

The AS delivers the transactional power for business applications and must be extremely stable, scalable, and secure. Since the application servers are used as the execution

(14)

layer for the business logic coded in ABAP or Java, they are required for the fulfillment of the business process which in turn creates high availability requirements. Solutions for optimized availability are supported by the SAP AS architecture, but always depend on additional components such as redundant servers and monitoring, and control

processes that are typically in high availability clusters.

Before going deeper into the SAP AS architecture, the general features should be discussed. All application servers consist of at least of one central database and a central SAP instance that provides unique services for the SAP system. If more

transactional performance is required by the SAP system, additional application servers can be added to the SAP system. A SAP system that is identified by a unique System Identifier (SID) might consist of many SAP instances and the common database. Depending on the type of application, a SAP AS can be installed for ABAP, Java, or for both workload types as shown in the following figure:

Figure 4. SAP Web application processing options

ABAP system architecture

The layout and structure of SAP AS 7.00 has changed from version 6.40. The following figure shows how the structure of a pure ABAP system was used up to SAP AS, version 6.40.

(15)

Figure 5. A pure ABAP system using SAP AS version 6.40

This figure shows two instance types including a central instance and one or more dialog instances. Processes like Dialog, Batch, Update, Spool, or the Dispatcher process exist many times in a SAP system and are therefore redundant. Each installation of an ABAP instance also has one gateway process configured that is used for communication through the Remote Function Call (RFC) protocol. Also, each instance has its own Internet Communication Manager (ICM) process for HTTP-based communication. The Internet Graphics Server (IGS) only supports the creation of bitmaps for browser-based clients.

To register all the instances of a SAP system and to support the communication between the various components of a distributed SAP system, a single message server is

configured in the central instance. Also specific to the SAP system is the central

Enqueue server that manages the lock entries in a distributed SAP system in a lock table inside of the shared memory of the server. Because of these two unique processes, the term central instance was used for this installation. A central instance is the lowest work unit of the SAP system and the performance can be extended by adding an additional AS.

When looking closer at the directory structure of this SAP system, the installation of the SAP AS 6.40 is demonstrated in the following figure.

(16)

Figure 6. SAP central instance

All profiles and executables of a distributed SAP system are made available from the central instance to all dialog instances through the share SAPMNT. In order to support a simple patch process for executables, there is one master copy of the executables on the central instance. Any time a dialog instance starts the SAP utility, SAPCPE checks for the availability of a newer executable version. When available, this executable is copied to the AS local runtime directory before it is used.

Changes in the SAP system ABAP reports are distributed by using the transport system. SAP systems can be configured to be a member of a transport domain. For each

transport domain, there is one directory that is shared by all members of the domain. The directory is: <Drive>:\usr\sap\trans. Because of the central character of this shared directory, it can be considered a single point of failure for the operation of more than one SAP system.

With the introduction of SAP AS 7.0, there was a major change in the layout of the central instance. Similar to the structures in pure Java systems, the unique Message and Enqueue server processes have been moved to a separate SAP instance: the ABAP System Central (ASCS) instance. Therefore, no typical AS has more system wide functions. The following figure shows the SAP landscape simplification:

(17)

Figure 7. Simplified ABAP system setup using SAP AS version 7.0

Subsequently, the file system of an ASCS instance would look like the following figure:

(18)

SAP installations of SAP AS 7.0 consisting of an ASCS instance and a dialog instance will continue to use the name format D<instnr> for the instance directory. This combined installation structure is shown in the following figure:

Figure 9. ASCS instance and dialog instance

Regardless of this combined installation structure, the Enqueue and Message server processes are now in the ASCS instance. This naming convention was not changed because of compatibility reasons with older versions.

Dual-stack system architecture

With the introduction of J2EE as a possible SAP system component in version 6.40, SAP AS can be installed for ABAP, Java, or for both types of workloads. There is a

considerable difference in architecture between ABAP and Java platforms as seen in the following figure:

(19)

Figure 10. A dual-stack system using SAP AS version 6.40

As shown in this figure, both the ABAP and the Java part of the SAP AS have their own Message and Enqueue server as critical components. The Java AS is primarily made up of Java server processes. The software deployment manager (SDM) is used for the installation and management of software versions. The server operating system must also have a Java development kit (JDK) installed to configure the Java virtual machine (JVM). The JDK for Windows is available for Windows through Sun Microsystems. While in ABAP Applications Server version 6.40, the Enqueue and Message server are still a part of the central instance: The Java AS always uses the system central services (SCS) instance concept. This means that every 6.40 dual-stack system must, at a minimum, consist of two instances.

As with the pure ABAP configuration, the hybrid system still has a central database that divides the respective application data types by using a schema. In the hybrid structure, the ABAP and Java functions are shut down simultaneously as if a single instance. Both instance parameters are also configured in a single instance profile. The Java SCS instance in this installation is a complete unit and has its own profile. It can be started or stopped independently.

For the purpose of maintaining distributed installations of SAP instances, all profiles and executables of the SAP system are shared on one central instance on a network share. This server is typically the server that holds the central instance or the SCS instance. All together, the dual-stack directory structures are naturally more complex than a pure ABAP or a Java instance. The SAP AS 6.40 dual-stack system structure is shown in the following figure:

(20)

Figure 11. SAP AS 6.40 dual-stack file structure

As seen previously with the pure ABAP AS, the system structure for dual-stack systems became simpler with the introduction of the SAP AS 7.0. The only difference between the typical identical system instances is the Software Deployment Manager (SDM) that is installed only in one instance. The SDM is required to install and patch Java programs and is only needed when new programs are installed or during software maintenance. Therefore, there is no need to configure the SDM in a cluster solution. To secure SDM service availability, a backup copy can be installed on any AS when needed. As with SAP AS version 7.10, the SDM will be completely removed from the installation and replaced with a new Java Support Package Manager (JSPM) function. The software maintenance functionality will then be an integrated part of every AS and this function would be redundant.

The following figure shows the SAP AS 7.0 dual-stack system structure. As shown in the figure, the ABAP Message server and Enqueue have now been moved to a new,

(21)

Figure 12. SAP AS 7.0 dual-stack system structure

The following figure shows the SAP AS 7.0 dual-stack directory structure with an ABAP, Java, and a SCS instance. In this file system layout, there is a clear distinction of the different components described.

(22)

Figure 13. SAP AS 7.0 dual-stack directory structure

Java system architecture

In addition to the installation variant for ABAP or dual-stack systems, there is a third way to install pure Java systems. In this case, there is no difference between the SAP AS versions 6.40 and 7.0. This configuration typically uses a SAP Web dispatcher or a hardware load balancer to distribute the HTTP connection load. The Java system application servers are all constructed in the same way with the addition of the Software Deployment Manager (SDM) on one instance. This functionality, however, is removed in SAP AS version 7.10 and will no longer appear in subsequent Java system versions. The following are the three main components of a Java system:

• The central Enqueue and Messenger services used by all Java instances • Java and dispatcher processes to handle the workload

• A central database for persistent data storage These components are shown in the following figure:

(23)

Figure 14. Java system main components

Multiple J2EE instances placed on several physical servers create a Java cluster. The basic rule is that a Java instance can only be configured once per physical server. At a minimum, the Java instance must consist of at least one Java server process and a dispatcher, but can also have multiple Java server processes. The central SCS instance might also be put together with a regular Java instance on one physical server.

Similar to the ABAP installation, the profiles and executables of a distributed Java system also reside on one physical server and are shared there. Because of the central character of these files, this server is the server that holds the SCS instance of the SAP system.

SAP system single points of failure

Single points of failure are SAP system elements that are critical in order to operate a system and must be protected against high available SAP system loss or failure. Single points of failure assessment

As mentioned previously, every SAP system has the following central components that are required to be available at all times:

• A central database for data storage – one per system

• Separate message servers and Enqueue servers for ABAP and Java systems • The SAPMNT-share for profiles, executables, and Java Secure Store files of a SAP

system. There is one SAPMNT-share per SAP system.

The purpose of the database is to provide persistent data storage for SAP system data and the runtime environment. Databases work with a series of internal mechanisms known as ACID (Atomic, Consistent, Isolated, and Durable). These mechanisms ensure

(24)

data consistency at all times. For example, there is a mechanism that logs all changes executed during a transaction. If a database operation fails in the middle of a

transaction, the logs are used to restore the previous condition. The transaction logs can also be used to reapply transactions to a database image. For example, a database image restored from a backup would not reflect the latest transactional state since the transactions have most likely been executed after the backup was created. The latest transactions would be lost due to the restore if there was no transaction log available to reapply them.

Databases are central application components and are often protected by high availability clusters or other technologies like Microsoft SQL Server® 2005/2008 R2 Database Mirroring. High availability clusters use the same database image that is accessed from two servers (shared disk) for server redundancy. Database mirroring, on the other hand, is able to maintain a physically independent copy of the critical data. The main purpose of all these technologies is to protect the database service against loss since it is the most critical component of a SAP system.

The SAP System Message Server registers all SAP system instances and load balancing user demands by connecting new users to the most available server in the system. Existing connections will remain intact if a message server goes offline, however, no new connections can be made by that server. This makes the Message Server an ideal cluster solution candidate.

The Enqueue Server is part of the SAP lock concept. The purpose of the SAP lock concept is to synchronize data access in order to protect the consistency of SAP data objects. This is one of the most important functions of a SAP system. It keeps SAP data consistent by not allowing two users to make changes to the same data object at the same time. Instead, the data would be locked for the first user.

The Enqueue Server in the following figure consists of a work process and a lock table in the shared memory of the server that is used to store the lock information for an entire SAP system. The Enqueue work process is needed in distributed systems to insert or verify lock information on behalf of the dialog instances. Local work processes can directly access the lock table and do not need this Enqueue work process. If, however, the lock table is lost by a server failure, lock information can no longer be verified. In a distributed system, this would create a transaction reset and roll-back of all pending transactions, even on dialog instances that would normally resume working, and all session contexts would be lost. An example of a SAP AS 6.40 ABAP with a single point of failure (SPOF) is shown in the following figure:

(25)

Figure 15. SAP AS 6.40 ABAP SPOF

This figure shows only the critical SAP AS components and is therefore, not complete. Another critical point resides in the file systems and network shares of the SAP

installation on Windows. It is important that the SAP system executables and profiles are always installed with the central instance or SCS instance in newer systems. Access to these files is provided through the SAPMNT share that is present only once per SAP system. Executables available on this share are copied to the local machine before an instance starts through the SAPCPE SAP program. This is done to improve the stability of the SAP instance. However, the profiles are only read through this share.

The following figure shows the infrastructure of two servers: Server Alpha has the central instance and Server Beta is a SAP application server. Server Alpha hosts the central instance and therefore the SAPMNT share. Both instances have the share SAPLOC that is used to access the local environment of a SAP instance. Both servers have two

environmental variables: SAPGLOBALHOST and SAPLOCALHOST. The UNC names \\SAPGLOBALHOST\sapmnt and \\SAPLOCALHOST\saploc were derived from these variables. These names are used in the SAP kernel to search the SAP system profiles and system directories. Server Alpha has both variables set to the name of the local server so all access points are local. However, Server Beta is directed to the central server when accessing SAPGLOBALHOST. SAPLOCALHOST is used for all instance specific operations and therefore is accessed again through a local path.

(26)

Figure 16. Critical SAP AS components

The mentioned directory structure and the SMPMNT share must be protected within a high availability solution because of their central significance for the SAP system. Since the access to the UNC path is derived from the variable SAPGLOBALHOST, these files are also called global files.

Prior to SAP AS version 7.0, in all ABAP or ABAP + Java systems, the central instance was protected in a cluster. The reason was simple: It was not possible to separate the Enqueue and the Message server from the rest of the SAP central instance. Together with the central instance, the Enqueue server and the Message server, the global files and the SAPMNT share were implicitly protected in a cluster as well.

With the development of the SAP Standalone Enqueue, it became possible for the first time in the SAP AS 6.40 to extract the central component Message server and Enqueue server into a single instance. By doing so, the cluster configuration for critical SAP services was significantly simplified. While in version 6.40, the SAP System Central Services (SCS) was introduced only for Java-based systems. SCS configurations also became available for ABAP-based systems with SAP AS 7.0. These configurations are called ASCS instances.

Note: All high availability configurations of SAP systems today are based on the SCS instances, the protection of the SAPMNT share, and the GLOBAL files in a failover cluster.

(27)

One of the main benefits of this configuration compared to the protection of a complete central instance in older versions is the fact that only two relatively lightweight services need to be moved and restarted. SCS instances lead to shorter failover times and more stability in the cluster implementation. Since there are no SAP users connected to a SCS instance, the effect of a failover is also much smaller in the SAP system. Using the SAP Replicated Enqueue in addition to SCS high availability configurations enables

enterprises to minimize application server interruptions. For more information, see the Measures to Avoid Unplanned Downtime section.

The information below confirms which configuration is supported by which version. Up to version 6.40, the central instance is clustered.

• During an upgrade of an existing 6.40 central instance to 7.0, the established architecture remains intact. SAP has documented the migration steps to support the new ASCS structure in SAP note 1011190.

• When initially installing SAP AS 7.0, only the SCS/ASCS instance will be clustered. Pure Java systems:

• Since the SAP AS 6.40 SR1 release, only the SCS is clustered. No changes are needed to upgrade to 7.0.

ABAP + Java systems:

• Since the SAP AS 6.40 SR1, the Java SCS instance together with the ABAP central instance is clustered.

• With the new installation of SAP AS 7.0, only the ASCS instance and the SCS instance are clustered.

SAP Enqueue process special requirements

The dependency on the single lock table was not completely resolved by the introduction of the SAP Standalone Enqueue. To address this issue, the SAP Standalone Enqueue was combined with a SAP Replicated Enqueue on another server. The following figure shows the new system design with SCS instances to host the central and critical SAP system services. There would be one for ABAP and one independent SCS instance for Java. Any other component of the SAP System, such as the SAP AS that handles the user workload, would not be considered critical because they are implicitly redundant if more than one is configured in the system. Because of this redundancy, only the SCS instances require high availability protection measures.

(28)

Figure 17. New system design with SCS instances

If one combines the SAP Standalone Enqueue in the SCS instance with a SAP

Replicated Enqueue running on a second server, one can continuously replicate the lock table. In a larger SAP system with several SAP application servers, an operation with minimal interruptions is provided. This is provided even when the central services must be transferred to another server due to a hardware failure.

The SAP Replicated Enqueue can only be used for lock table replication and cannot function as a regular Enqueue server of a SAP system. The lock table in the SAP Replicated Enqueue, which holds the replicated lock entries, cannot be used directly for the Enqueue service. During the process of a failover of the Enqueue server to the replication site, the standard Enqueue process is first started and a new, empty lock table is created. The replicated data in the shadow lock table is then read and transferred to the original lock table before the system is operational again.

The following figure shows the configuration of several SAP application servers and a central instance in combination with a SAP Replicated Enqueue:

(29)

Figure 18. A SAP Replicated Enqueue

A SAP Replicated Enqueue should be combined with a high availability cluster solution. One reason for this is to enable the administrator to switch the Message server from one server to another in case of a severe failure. Another reason for this setup is that the SAP Replicated Enqueue is not a fully functional Enqueue server. Instead, it is only used to replicate the lock table. During regular operation, the SAP Replicated Enqueue only inserts lock requests into a standby lock table on a second server. In case the original server dies, the normal Enqueue Server needs to failover to this server and resume work with this replicated lock table. Additionally, high availability cluster solutions are also used to protect the database against hardware failures.

Since Message and Enqueue servers in the SCS instance have very little resource requirements on a server within a high availability cluster, it is possible to install additional local application servers. In this context, local means that they are not managed by cluster management and are lost by a failure of the respective server hardware.

SAP standalone engines

The typical AS for all kind of SAP applications is the SAP AS. One of the benefits of the SAP AS is the common architecture that can be reused to provide the runtime

environment for the majority of requirements. There are, however, a few special requirements that require a more tailored design or special software components. In SAP terminology, those engines are called the SAP standalone engines.

(30)

The SAP Web Dispatcher

The SAP Web Dispatcher is a Software Load Balancer for HTTP or HTTPS connections. Typically, it will be installed in a demilitarized zone (DMZ) between the SAP backend systems and public Internet access.

Connection requests from the Internet will be passed by the SAP Web Dispatcher to the available SAP system AS in a circular way. The routing algorithms are used to review the capacity and load on all the various instances to determine which server to connect to. With ABAP instances, the number of configured dialog work processes will be evaluated. With Java instances, the number of available server processes determines which server gets the next connection request.

The architecture of the SAP Web Dispatchers corresponds with the SAP Internet Communications Manager (ICM) which is a component of every ABAP instance. While an ICM forwards incoming connection requests directly to a dialog work process of an ABAP instance or to the Java dispatcher of a dual-stack installation, the SAP Web Dispatcher passes those requests first to the respective ICM of a SAP instance which in turn further processes the request. The SAP Web Dispatcher basically acts as a

software router for the incoming HTTP requests.

Because of their central function for Internet communications, the SAP Web Dispatcher is also a critical component in a system landscape that needs to be protected against hardware failures. Since the SAP Web Dispatcher looks like a SAP ABAP instance, it can be integrated relatively easy into a high availability cluster solution and therefore be protected against hardware failure. The typical structure of a SAP landscape using a Web Dispatcher is shown in the following figure:

(31)

In contrast to most of the high availability installations, the installation of a SAP Web dispatcher in a cluster is not supported by SAPINST. SAP note 834184 provides the steps to manually configure a WSFC for the SAP Web Dispatcher in detail. SAP notes can be downloaded from the SAP Service Marketplace at https://service.sap.com. Note: Access to this Web site is available only to registered SAP customers and partners and requires a user name and password.

Additional SAP Web Dispatcher administration information is available at: http://help.sap.com

To access this information, do the following:

 From the left menu pane, click SAP NetWeaver.  Choose English under SAP NetWeaver 7.0 Library.

 Open Technical Operations Manual for SAP NetWeaver.  Open Administration of Standalone Engines.

 Follow the SAP Web Dispatcher link.

SAP standalone gateway

The SAP gateway enables SAP systems and external programs to communicate with one another. The protocol for the communication is the Common Programming Interface Communication (CPI-C) which is also used by the Remote Function Call (RFC) interface. Subsequently, all RFC connections in a SAP system rely on the SAP gateway process. By default, each SAP AS has one gateway process configured.

In certain cases, it is also possible to configure a standalone gateway process. One example would be to configure a standalone gateway for the System Landscape Directory (SLD). As the SLD is a component of the Java AS, the standalone gateway acts as a bridge to allow ABAP systems to read and write data per the RFC in the SLD. Another typical use case is the installation of a standalone gateway on a single database instance with no ABAP engine. In this case, the gateway is needed in order to make the database calendar (Transaction DB13) functional. This configuration is also described in SAP note 657999.

In order to configure a standalone gateway in a failover cluster, it is very simple to add the gateway to the Enqueue and Message server process of a SCS instance. This configuration is described in SAP note 1010990.

TREX

TREX is an abbreviation for Text Retrieval and Extraction and is a search engine designed to search for structured and unstructured data. TREX provides SAP

applications with numerous services for searching, classifying, and text mining in large document collections or unstructured data. In addition, TREX provides SAP applications with services for searching and aggregating business objects or structured data.

This search engine is used as a standalone engine in combination with the SAP Enterprise Portal (EP) or the Knowledge Management (KM) application. For access to the TREX search engine, each SAP AS has ABAP or Java components that support the communication with the engine. The most simplified form of a TREX installation is shown in the following figure:

(32)

Figure 20. Basic TREX installation

TREX is one example of a SAP solution that does not rely on a standard SAP AS, but is run on special server architecture. TREX installations can also be implemented as master/slave configurations spanning several physical servers.

Additional information about the distribution and implementation of a TREX engine is available at http://service.sap.com/instguidesnw70.

Note: Access to this Web site is available only to registered SAP customers and partners and requires a user name and password.

To access this information after logging on to the site, do the following:  From the left menu pane, click SAP NetWeaver.

 Choose English under SAP NetWeaver 7.0 Library.

 Follow the Search and Classification (TREX) link.

General information about TREX is available at http://help.sap.com.

SAP liveCache

SAP liveCache is a component of the Advanced Planning and Optimization (APO) application that supports the SAP SCM solution: an application for supply chain

(33)

objects in the liveCache rapidly during operation, those objects are loaded into the liveCache at startup. A special logging mechanism writes savepoints to the disk every few minutes that does not reflect the transactional state of the system.

APO systems consist of a SAP AS and a liveCache as standalone engine. From the perspective of high availability, there are two solutions possible to protect the liveCache: • A failover cluster for the APO system and the liveCache. LiveCache is supported in

the WSFC as of SAP NetWeaver 7.0 SR1.

• A hot standby liveCache where the database log files are exported to a standby server and constantly applied to a database in recovery mode. This log shipping solution works with two independent servers that do not share common storage. Additional information about the installation of SAP liveCache and cluster configurations in WSFC is available at http://service.sap.com/instguidesnw70.

In addition, see the following SAP note about the configuration of liveCache in WSFC at https://service.sap.com/notes.

 SAP note 780795: ―SAP liveCache 7.5: WSFC Installation‖

General information about the administration of the SAP liveCache is available at http://help.sap.com.

To access this information after logging on to the site, do the following:  From the left menu pane, click SAP NetWeaver.

 Choose English under SAP NetWeaver 7.0 Library.

 Follow the SAP liveCache Technology link.

SAP Content Server

The SAP Content Server is an independent server instance for temporary data and Web documents that can be requested by the SAP AS through the Internet. By using the Content Server, large document volumes can be maintained for cached access. A SAP Content Server can be installed together with a SAP AS on a physical server or as standalone instance. It is possible to install this server with or without its own

database. When installing this server with its own database, MAXDB is typically used. The simultaneous use of a SAP AS database and a Content Server is not supported. In order to protect the SAP Content Server against loss, it can be configured in a failover cluster.

(34)

The following SAP notes located at https://service.sap.com/notes provide information about the installation and clustering of the SAP Content Server.

 SAP note 175096: ―SAP Content Server installation guide‖

 SAP note 1039401: ―SAP Content Server Clustering with Windows 2003‖ To access this information, do the following:

 From the left menu pane, click SAP NetWeaver.  Choose English under SAP NetWeaver 7.0 Library.

 Follow the SAP Content Server link.

Additional SAP Content Server administration information is available at: http://help.sap.com.

(35)

Unplanned Downtime Avoidance Strategies

Unplanned downtime is one of the biggest concerns in any IT operation. Especially with the dependencies companies have on SAP applications, downtime of such services at undesired times would block the normal execution of work and could generate severe financial impacts due to lost revenue. The reason for unplanned downtime is most often a failure in hardware components that affect application service availability.

Hierarchy of high availability solutions

Unplanned application interruptions often occur simultaneously with hardware resource loss which is important for the application operation. In addition to the importance of resource redundancy, supervision and control of application operations is critical for high availability as well. For highly available SAP system operation, several solutions have evolved that either independently or in combination assure better protection against the unplanned downtime of a SAP application. The following figure shows the technical solution hierarchy:

Figure 21. Technical solution hierarchy

Securing a SAP application against interruption due to the loss of hardware resources generally requires applying several techniques. Applying these techniques will lead to better application protection.

(36)

Data storage protection

The lowest level of the high availability hierarchy manages the way data is stored and made available in a secure and reliable way. Data storage protection is typically widely implemented in a SAP data center. Most of the storage devices offer some level of protection by default.

However, storage subsystems still have a number of challenges for a SAP data center. First, the amount of data grows rapidly over time. In addition, the data needs to be constantly protected to prevent hardware failure and data access performance loss that directly relates to the overall SAP system performance. SAP system performance is typically measured by user transaction response time.

SAN infrastructures

A Storage Area Network (SAN) provides a centralized approach to maintaining the storage resources needed in a computer system. Traditionally, Direct Attached Storage (DAS) has been used for the computer system local storage requirements. The use of DAS has high space requirements and administration costs. By centralizing data storage into a scalable, network type architecture, administrative costs are lowered, and space is managed more efficiently. SANs can be built on Fibre Channel connections using fiber optic cables and built on the SCSI protocol for block-oriented data transfer.

In addition, iSCSI devices are now available that use normal TCP/IP networks for the transport. The SCSI protocol for the data transfer is packaged into the TCP/IP transport. From the high availability perspective, the use of SAN infrastructures in data centers is recommended. Redundancy of physical disks and protection against the single disk failure is maintained in the storage subsystem itself and follows the hierarchical

approach shown at the beginning of this section. Depending on the vendor and the type of storage subsystems in a SAN, even data replication over larger distances can be achieved with SAN-based storage.

Additional information on the concepts of the SAN infrastructure for highly available Windows systems can be found in the Server Cluster: Storage Area Networks white paper by searching for the title at http://technet.microsoft.com/en-us/default.aspx. Multipathing

Data storage protection against unplanned downtime always includes connection protection between a server and its storage. If there is only one storage subsystem host adapter and subsequently only one storage cable connection, any host adapter, cable, or controller failure in the storage array would create an application interruption. The use of a WSFC could help protect the server components such as the host adapter.

However, it is preferable to avoid connection failovers in a cluster. These failover types can be avoided by using a redundant host adapter and two cable connections to a storage device that in turn has two storage controllers. This configuration is called multipathing.

The Windows operating system supports multipathing through the MPIO driver. Additional information for MPIO configurations is found in the Multipathing and the Microsoft MPIO Driver Architecture white paper at:

(37)

http://download.microsoft.com/download/3/0/4/304083f1-11e7-44d9-92b9-SAP on Windows Server 2008 R2 - High Availability Reference Guide 37

Server protection

Servers host the individual components such as the SAP instances and services that compose a SAP system. The server role and importance depends on its function. A database server for a productive SAP system typically has the highest requirements in availability, stability, and performance. While SAP specific solutions are discussed later in this paper, there are a number of general server recommendations that incorporate high availability.

With high availability, redundancy is the method to protect servers against downtime. Inside of a server this could mean that the server has two independent power supplies with two power cords. Of course, each power cord needs to supply enough energy to sustain the operation in case the other one fails. It might also include redundant host adapters for storage or network access. Finally, a conceptually well designed system with hot pluggable components is always valuable.

However, there are server components that cannot be easily configured to be redundant. Main memory or CPUs are examples of these critical components as well as the server operating system that also exists only once. There are two solutions that are typically used to address this. One solution would be to use fault tolerant systems built to recover from memory or CPU hardware failures. However, the disadvantage to this solution is the limited performance range and higher prices.

The second solution for protecting servers against failures is high availability clusters like the WSFC. With WSFC, two or more servers share storage subsystem access and can take over the storage volumes and restart applications automatically in case a server fails. This concept even maintains redundancy at the operating system level as each server has its own operating system. However, clusters depend on additional software components and need a proper configuration and a change management policy. We will discuss the possible cluster implementations with SAP applications later in this section.

Network high availability

Networks are the backbone of all corporate communication, both internally and externally. The SAP application network implementation has multiple communication layers based on different functionalities including:

• A server network that interconnects SAP application servers and the database server.

• A client network for local users using the SAP GUI or a browser. • A demilitarized zone for connection to the public Internet.

• A provider for access to the public Internet.

Again, component redundancy is the key factor for high availability solutions. However, the architecture of a real implementation reflects additional considerations. For example, public access to the Internet immediately raises security concerns and has more

requirements than the internal and isolated server network. While in the server network, besides availability, performance might be another issue. The following figure shows the different SAP network aspects.

(38)

Figure 22. Different SAP network aspects Important considerations for highly available SAP networks include:

• Router and switch redundancy: The server network is redundant up to the used routers or switches. Redundancy can be accomplished by network teaming of Network Interface Cards (NIC). Routers need to monitor each other and take over the functionality of a failed device.

• Client separation: Clients are typically not connected in a redundant way. However, there needs to be a separation of clients between different switches so that only a single client group can be affected by a hardware failure.

• DMZ redundancy: In the DMZ, there is typically a redundant SAP Web dispatcher configuration or hardware load balancers.

• Internet access redundancy: Redundant access to the public Internet is necessary. Additional information about the SAP systems high availability network requirements can be found in the SAP Help pages at http://help.sap.com.

To access the information, do the following:

 In the left menu pane, click SAP NetWeaver.

 Under SAP NetWeaver 7.0 Library, choose English.  Search for Network High Availability.

(39)

Application specific configurations

High availability clusters are a classic solution for protecting SAP applications against critical hardware resource failure. In the Windows-based SAP installations, SAP supports the database and the SAP SCS instance installation in a WSFC.

SAP components can be installed into the cluster by using the SAPINST SAP tool. In the simplest configuration, the cluster consists of two servers and a storage subsystem that the application components are installed on. The storage subsystem has to be

accessible by both servers. A SAP system with a SQL Server database is shown in the following figure:

Figure 23. SAP system with a SQL Server database

Each of the cluster nodes has its own local operating system with the SQL Server engine installed locally. Each node must be capable of accessing the external storage

subsystem where the applications components are installed. Supported storage systems include Serial Attached SCSI (SAS), Fibre Channel, or iSCSI-based systems.

Every WSFC cluster needs to maintain a copy of the cluster database that contains cluster configuration information. This information determines which cluster node can take ownership of the cluster resource group for the SAP application and database in case the communication between the nodes is interrupted. When two servers compete for the cluster resource group, this is known as Split-Brain syndrome and can generate a deadlock.

In the simple cluster configuration shown in the previous figure, the cluster database is stored on each node. If the cluster uses a Disk Witness, the Disk Witness will also store

SAP Applications on Windows Server 2008 R2 High Availability Reference Guide