SAP on SUSE Linux Enterprise

Transcription

1 SAP on SUSE Linux Enterprise Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center 11 SP1 December 20, 2011 Best Practice

2 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center List of Authors: Fabian Herschel (fabian.herschel@suse.com), Markus Guertler (mguertler@suse.com), Lars Pinne (lars.pinne@suse.com) Copyright Novell, Inc. and contributors. All rights reserved. This guide has been created in cooperation with LINBIT HA-Solution GmbH. Many thanks for all good contributions. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Section being this copyright notice and license. A copy of the license is included in the section entitled GNU Free Documentation License. For Novell trademarks, see the Novell Trademark and Service Mark list Linux* is a registered trademark of Linus Torvalds. All other third party trademarks are the property of their respective owners. A trademark symbol (, etc.) denotes a Novell trademark; an asterisk (*) denotes a third party trademark. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither Novell, Inc., SUSE LINUX Products GmbH, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.

3 Contents Executive Summary vii Part I Introduction and Concept 1 1 Introduction SAP on Linux SUSE Linux Enterprise Server SUSE Linux Enterprise Server High Availability Extension Database for SAP Sizing, Deployment and Migration Considerations One Concept Two Use Cases High Availability Concept Overview Use Case 1 DRBD dual data center with two clusters - 2x Use Case 2 DRBD dual data center with one cluster Part II Installation of "DRBD dual data center" with MaxDB 29 3 Installation Overview 31 4 Planning 33 5 Prerequisites Hardware Requirements Software Requirements, Connection Data, and all the Rest

4 6 Download the Needed SAP Installation Media 39 7 Install SUSE Linux Enterprise Server 11 SP1 for SAP File System Layout Software Selection Runlevel and System Services Miscellaneous Check SLES for SAP Installation Prepare SAN Storage Multipath Configuration Partitioning MD Configuration DRBD Setup LVM Configuration File System Creation Check the SAN Storage Configure the Cluster on both Sites Install the SUSE Linux Enterprise High Availability Extension Software Packages on all Nodes Basic Cluster and CRM Configuration STONITH Resource Configuration Storage Resource Configuration Configure Virtual IP Addresses Install SAP NetWeaver 7.0 EHP SAP Installation Procedure Installation of the Central Services Instance ASCS Installation of the Database Installation of the Central Instance Check the SAP Installation Integrating SAP into the cluster SAP resource configuration Testing the Cluster Check the SAP Integration Application Cluster Tests

5 Part III Appendix 93 A Software Downloads 95 B Novell Products Online Documentation 97 C SAP Notes 99 D Links to SUSE Linux Enterprise Server, SAP, Databases 103 E Sample CRM Configuration for SAP Simple Stack High Availability 109 F Licenses 113 F.1 GNU Free Documentation License F.2 GNU General Public License Terminology 121

6

7 Executive Summary SAP Business Suite is a sophisticated application platform for large enterprises and mid-size companies. Many critical business environments require the highest possible SAP application availability. SUSE Linux Enterprise High Availability Extension, when running on modern x86-64 hardware platforms, satisfies this requirement. Together with a redundant layout of the technical infrastructure, single points of failure can be eliminated. SAP NetWeaver is a common stack of middleware functionality used to support the SAP business applications. This guide describes a SAP NetWeaver installation on SUSE Linux Enterprise Server 11 SP1 with the additional SUSE Linux Enterprise High Availability Extension. We will also describe possible failure scenarios and methods to avoid them. The described concept has proven its maturity during several years of productive operations for customers of different size and branches. This document focuses on deploying SAP in a dual-site cluster, where each site has redundant access to a SAN storage with two storage heads, using host-based mirroring with MD for intra-site synchronous replication and the DRBD technology to replicate asynchronously off-site. We will cover the commonly used disaster-recovery strategy, having one site with a two-node cluster at one geographical location and another site with another two-node cluster at another geographical location. After a complete failure of the first site (both cluster nodes down), the second site can takeover the operation of the SAP applications and databases. The site fail-over procedure is half-automated and requires some manual interaction. The local site fail-over is completely automated. Two sites with two two-node clusters require four nodes in total. Four dedicated servers and two times a redundant SAN infrastructure with four storage heads in total can be quite expensive. A cheaper, but less redundant variant of this scenario is, to use only one two-node cluster in the first site and a non-redundant standalone server in the second site. The server at the second site could also be equipped with a local storage, thus not requiring a SAN. This is a technical document designed to allow system administrators and technical consultants to integrate highly available SAP bussiness applications into an existing SUSE Linux Enterprise Server infrastructure.

8 The described storage stack and SAP configuration can be used with or without a high availability cluster. It is possible to add high availability functionality to an already running system if the installation complies with the described solution. This guide will show you how to: plan a SUSE Linux Enterprise platform for SAP workload, set up a Linux high availability infrastructure for SAP, including a storage stack that includes DRBD, perform a basic SAP NetWeaver installation on SUSE Linux Enterprise. This guide will also help you to install the following software components: SUSE Linux Enterprise Server 11 SP1 SUSE Linux Enterprise High Availability Extension MaxDB (Oracle and DB2 are supported, too) SAP NetWeaver 7.0 EHP1 (other versions are supported, too) This guide is aimed at IT professionals with skills in: SAP basic operating, data center system concepts and configuration, Linux knowledge at LPI1 or CLE level. To apply this guide, you need access to the following resources: SUSE Linux Enterprise Server 11 SP1 installation media. To update systems, you must have either Internet access, Novell ZENworks Linux Management, or a local Subscription Management Tool. SUSE Linux Enterprise High Availability Extension installation media. To update systems, you must have either Internet access, Novell ZENworks Linux Management, or a local Subscription Management Tool. SAP NetWeaver 7.0 EHP1 Installation Media. viii Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

9 Appropriate hardware: two servers, network, storage. For details, see below. This guide focuses on one DRBD-based solution, which supports a dual data center topology. We will give an overview of the covered SAP scenarios, include a brief overview of the DRBD technology and describe in detail the DRBD configuration in conjunction with the HA cluster configuration. Depending on your requirements, other scenarios can be selected or combined. A typical combination is the DRBD dual data center solution with host-based mirroring (Linux md-raid) and SBD (Stonith Block Device) dual data center solution. In this case, hostbased mirroring is used to replicate SAP data between two local sites (campus cluster). SBD is used as an effective disk-based split-brain protection for the two-node campus cluster located at the first and second site. DRBD is then used to replicate the data to another two-node cluster or a single standalone server at a third site. A typical use-case for this solution is to have two local sites close to each other on the U.S. east-cost and a third site on the U.S. west-coast. The classic method of asynchronous log-shipping to a remote site far away on the database-level would be obsolete with this solution. An overview of typical SAP high availability scenarios can be found in the white-paper "SAP on SUSE Linux Enterprise - Best Practices for Running SAP NetWeaver on SUSE Linux Enterprise Server 11 with High Availability" Executive Summary ix

10

11 Part I. Introduction and Concept

12

13 Introduction SAP on Linux Novell and SAP cooperate on a wide range of tasks. Along with the operating system layer, Novell and SAP work closely to integrate Novell identity and security management solutions with SAP's NetWeaver platform and business software applications. Novell has multiple dedicated resources working at SAP headquarters and the SAP LinuxLab to ensure maximum interoperability between our products with SAP software and technologies. SAP has built SAP LinuxLab to assist with the release of SAP software on Linux. LinuxLab supports other SAP departments in the development of the Linux platform. It processes Linux-specific support problems and acts as an information hub to all SAP partners in the Linux ecosystem A Brief History of SAP on Linux In terms of data and computing, SAP applications are used to build the information backbones of companies. Therefore, SAP workloads need to be high-performance with good scalability. In the past, this need was only met by dedicated data center hardware and operating systems such as IBM Mainframes or HP 9000 UNIX servers (among others). Introduction 3

14 In the 1990s, Intel-based (x86) systems met the performance criteria for running smaller SAP workloads. The main drive behind the adaption of x86-based platforms was the relatively lower cost and higher return on investment (ROI) for these systems compared to mainframe or UNIX servers. At the same time, Linux matured into a fully capable operating system that provided all the key functions needed to run all kinds of workloads. In the following years, Linux (and the x86 platform) evolved into a system that fulfills the needs for all kinds of SAP workloads, from the smallest to the largest systems. Currently, SUSE Linux Enterprise 11 has been tested with up to 4,096 CPUs and 4 TiB RAM, with even higher theoretical limits. In the beginning, SAP on Linux was limited to 32-bit, but with the x86-64 extensions to the x86 architecture, these limitations where overcome. Today, nearly all x86 architecture server CPUs are 64-bit capable. Where possible, SAP endorsed open standards and technologies. This allowed SAP to support a very wide range of operating systems and hardware platforms. Open-sourcebased Linux provides the maximum in openness, so it was only natural for SAP to start supporting it in SAP tries to be operating system agnostic and act neutral on the customer's chosen operating systems. Unlike other software vendors, SAP has clearly stated its policies toward open source and Linux. For instance, the usage of binary only (closed source) device drivers (kernel modules) is not supported. This helps the Linux and open source communities since hardware vendors are encouraged to either publish the specifications and APIs of their hardware so the Linux community can write drivers, or make driver source code available that can be included in the Linux kernel (see SAP Note ). Linux allows customers to reduce their total cost of ownership (TCO). Linux distributors do not charge a license fee for Linux because it is open source. Only support and services need to be acquired. Since Linux is supported on a very wide range of hardware systems, customers now have the choice to opt out of vendor lock-in. In terms of administration, SAP customers see little difference between Linux and proprietary UNIX-like operating systems. Linux is an accepted operating system in all areas of data center computing. Through open interfaces and a wide range of available applications, Linux is very capable of providing services at all availability levels necessary for successful standalone SAP workloads or integration with existing environments. 4 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

15 1.2 SUSE Linux Enterprise Server SUSE Linux Enterprise Server Is Prepared for SAP Since the very start of SAP involvement with Linux, SUSE has been the number one Linux platform for SAP. SUSE Linux Enterprise Server has become the reference platform for SAP's software development. SAP now actively suggests SUSE Linux Enterprise Server when customers want to run SAP workloads on Linux. Recently, SUSE Linux Enterprise Server was chosen as the operating system for SAP's all-in-one business solutions and became a part of the SAP product line. SUSE Linux Enterprise Server has been fine-tuned to provide the best Linux platform for SAP software. YaST, the main installation and administration tool for SUSE Linux Enterprise Server, provides a SAP software pattern that installs the prerequisites needed for running SAP software. Also, some system parameters are fine-tuned in preparation for the SAP workload. In this document, we use SUSE Linux Enterprise Server 11 SP1 x86-64 with updates from Novell Customer Center SUSE Linux Enterprise Server for SAP Applications SUSE Linux Enterprise Server for SAP Applications is the only operating system optimized for all mission-critical SAP software solutions, including appliances, and is recommended by SAP as a preferred Linux platform. SUSE Linux Enterprise Server for SAP Applications is based on the newest SUSE Linux Enterprise technology, a highly reliable, scalable, secure and optimized server operating system that is built to power both physical and virtual mission-critical workloads. SUSE Linux Enterprise Server for SAP Applications is optimized for all missioncritical SAP software solutions. It is validated and certified by SAP and is, therefore, uniquely positioned to support SAP software solutions including appliances. Find more Introduction 5

16 details about this product at -sap.html. Installing a highly available cluster using SUSE Linux Enterprise Server for SAP Applications is more comfortable, because all needed packages including the cluster packages and SAP-related packages, like the java JDK, are already included in one single product Support and Certification For SAP customers, Novell offers the SUSE Linux Enterprise Server Priority Support for SAP Applications. This support offering provides customers with a single support point of entry for issues ranging from the operating system to the application ( Currently the following SUSE Linux Enterprise Server systems, including all service packs (SP), are certified as 64-bit version for SAP: SUSE Linux Enterprise Server for SAP Applications 11 ( SUSE Linux Enterprise Server 11 for AMD64 and Intel EM64T SUSE Linux Enterprise Server 11 SUSE Linux Enterprise Server 11 for AMD64 and Intel EM64T SUSE Linux Enterprise Server 11 for IBM Power SUSE Linux Enterprise Server 11 for IBM System z SUSE Linux Enterprise Server 11 for Intel ia64 SUSE Linux Enterprise Server 10 SUSE Linux Enterprise Server 10 for AMD64 and Intel EM64T SUSE Linux Enterprise Server 10 for IBM Power SUSE Linux Enterprise Server 10 for IBM System z 6 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

17 SUSE Linux Enterprise Server 10 for Intel ia64 SUSE Linux Enterprise Server 9 SUSE Linux Enterprise Server 9 for AMD64 and Intel EM64T SUSE Linux Enterprise Server 9 for IBM POWER SUSE Linux Enterprise Server 9 for zseries SUSE Linux Enterprise Server 9 for Intel ia64 SUSE Linux Enterprise Server 8 SUSE Linux Enterprise Server 8 for zseries SAP and Novell are working together to ensure that SUSE Linux Enterprise Server service packs always match the certification of the respective product. In fact, SAP recommends to always use the latest available service pack. Novell will provide at least five years of general support for platform and operating system products, including its revisions, starting at the date of a product's general availability. When general support ends, Novell will offer extended support for a minimum of two years. This gives SAP customers a long installation run-time ensuring a low TCO. 1.3 SUSE Linux Enterprise Server High Availability Extension Your data is your most valuable asset it is what your business depends on. Robust, scalable and manageable storage is a top priority for your IT department. High availability storage, applications and services are critical for your business to be competitive. But even as data grows, you can lower storage management costs and still benefit from an easy-to-manage, high-availability and storage foundation that scales as needed. The High Availability Extension, a featured addition for SUSE Linux Enterprise Server 11, satisfies these needs. It includes high availability service and application clustering, file systems/clustered file systems, network file systems (NAS), volume managers, Introduction 7

18 networked storage systems and drivers (SAN), and the management of all these components working together. Unlike proprietary solutions, SUSE Linux Enterprise High Availability Extension keeps costs low by integrating open source, enterprise-class components. The key components of the extension are: OpenAIS, a high availability cluster manager, supports multinode failover. Distributed Replicated Block Devices (DRBD8) provides fast data resynchronization capabilities over LAN, replicated storage area network (SAN) semantics, allowing cluster-aware file systems to be used without additional SANs. We use DRBD with the LinBit Resource Agent to mirror the data asynchronously from one data center to an other. Resource Agents to monitor availability of resources Oracle Cluster File System 2 (OCFS2), a parallel cluster file system, offers scalability. Cluster Logical Volume Manager (clvm2), a logical volume manager for the Linux kernel, provides a method of allocating space on mass storage devices that is more flexible than conventional partitioning schemes. High availability GUI and various command line tools. SUSE Linux Enterprise Server High Availability Extension integrates these open source technologies and enables you to support line-of-business workloads traditionally reserved for UNIX and mainframe systems. Without this integration, you would have to configure each component separately and manually prevent conflicting administration operations from affecting shared storage. When delivered as an integrated solution, the High Availability Storage Infrastructure technology automatically shares cluster configuration and coordinates cluster-wide activities to ensure deterministic and predictable administration of storage resources for shared disk-based clusters. The multinode failover support in OpenAIS, the improved node and journaling recovery in OCFS2, and the snapshots in the Logical Volume Management System (clvm2) are some examples of the high availability features in the storage infrastructure. Other features, such as the cluster awareness and ready-to-run support of Oracle RAC, enrich the environment, simplifying administrative tasks or eliminating them completely. 8 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

19 Availability is a result of the interaction of cluster software with application services on the front side and the operating system and hardware resources behind it. Following this basic idea, cluster software like OpenAIS could not increase availability on its own. It needs a lot of modules, such as services, resource agents, a messaging layer, network and file system availability, and a stable Linux kernel designed and configured for productive server systems in data centers. Figure 1.1 Modules of a High Availability SAP Cluster The central application of our cluster is the SAP system itself. We need to provide the SAP database and the central SAP instance with high availability (white boxes). Operating system (light colored boxes) and cluster software (dark colored boxes) together give us the needed functionality. In this document, we use SUSE Linux Enterprise Server High Availability Extension x86-64 with updates from Novell Customer Center. Introduction 9

20 1.3.1 Storage Scenarios and I/O Stack for SAP The file systems required by the operating system (i.e. mounted on / or /var) are usually stored on local hard drives using RAID-1 or RAID-5 disk arrays. Sometimes LVM is also used to gain more flexibility, i.e. for online file system extensions. This implies that these file systems can only be accessed by the local operating system or applications running locally on this server. Even if these file systems are placed on LUNs in a storage area network (SAN) outside the server, they are treated as local. Besides the usual file systems for the operating system installation (like /, /var and others), SAP and the SAP databases require their own file systems. These file systems are not stored locally. Instead they are provided by NFS file servers or on LUNs exported by storage units in storage area networks. Please be aware that the storage on which the database resides is subject to specifications and recommendations of the database vendor. Some file systems have to be shared across all cluster nodes so that every cluster node can access the file system at the same time. The recommended way of providing this service is the usage of a network file system (NFS). The NFS service also has to be highly available. In this document we use a dedicated NFS server. This server could be either a third-party product or a SUSE Linux Enterprise Server High Availability Extension cluster that runs NFS resources. Under specific circumstances, it may be possible to integrate the NFS server into the SAP cluster. Both the separate NFS cluster as well as the integrated NFS server are described in separate documents. 10 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

21 Figure 1.2 SAN IO Layers of High Availability Stack for SAP 8 Filesystem Ext3 Ext3 7 Logical Volumes lv1_sap lv2_sap 6 Volume Groups vg_sap 5 DRBD asynchronous data replication drbd0 4 MD Raid 1 for Host Based Mirroring md0 3 Multipath devices mpath1 mpath2 2 HBA raw devices sda sdb sdc sdd 1 SAN storage system Other file systems, e.g. mounted to /usr/sap/<sid> or /oracle/<sid>, only have to be available on one cluster node at the same time. However, each cluster node must be able to access these file systems if the cluster manager decides to use them. In our current concept, we use LVM2 on top of DRBD and MD RAID, which has shown its road capability for years. This storage stack can be used with or without a cluster. The UNIX file system is the highest layer of a whole I/O stack consisting of multiple I/O layers. Each layer provides a certain kind of functionality. For all I/O critical tasks, we have configured an I/O stack that supports the following functions: Low latency: high I/O throughput and fast response times. Host-based mirroring for storing data simultaneously on two separate storage units in a SAN. DRBD to synchronize the data from one site to the other. Logical Volume Manager for a flexible management of file systems. Multipath I/O for an additional level of redundancy for file systems stored on LUNs in the SAN. Introduction 11

22 Online resizing (extending) of file systems, snapshots of file systems using LVM snapshots, moving or copying file systems. This guide describes two common use cases in which DRBD (Distributed Replicated Block Device) technology is used to replicate SAP data over IP networks. The first use case describes a scenario in which SAP data is replicated asynchronously from one site to another site. Each site runs a local-cluster. This use-case is described in detail. The second use case simplifies the setup by not having two clusters at two sites, but only one cluster at the first site and a standalone server at the second site Introduction to DRBD DRBD (Distributed Replicated Block Device) is a distributed storage system that replicates data on the block device layer over the network between two hosts. It is sometimes referred to as raid over the network. However, DRBD has some unique additional features: 1. Fully synchronous, memory synchronous or asynchronous modes of operation. 2. Automatic recovery after node, network, or disk failures. 3. Bandwidth of background resynchronization are tunable. 4. Online data verification. 5. Feature-complete OCF Heartbeat/Pacemeker resource agent. 6. Support for TCP/IP over Ethernet, SuperSockets over Dolphin NICs (8.3.2) and SDP over Infiniband. 7. Support for single block device sizes of up to one petabyte. 8. Support for active bandwidth management for mirroring over long distance and high throughput internet links, including optional complete fall behind in case bandwidth is not sufficient. A complete feature list is available at -list/ 12 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

23 DRBD communication protocols Protocol A. Asynchronous replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred and the replication packet has been placed in the local TCP send buffer. In the event of a forced failover, data loss may occur. The data on the standby node is consistent after failover. However, the most recent updates performed prior to the crash may be lost. Protocol B. Memory synchronous (semi-synchronous) replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred and the replication packet has reached the peer node. Normally, no writes are lost in case of a forced fail-over. However, in the event of simultaneous power failure on both nodes and concurrent, irreversible destruction of the primary node's data store, the most recent writes completed on the primary node may be lost. Protocol C. Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss. Data loss is, of course, inevitable even with this replication protocol if both nodes (or their storage subsystems) are irreversibly destroyed at the same time. The definition of these protocols have been taken from the DRBD user guide. We are using protocol A in this solution to implement an asynchronous mirror from one data center to an other. DRBD refers to both the software (kernel module and associated userspace tools) and the specific logical block devices managed by the software. The terms "DRBD device" and "DRBD block device" are also often used for the latter. DRBD layers logical block devices (conventionally named /dev/drbdx, where X is the device minor number) over existing local block devices on participating cluster nodes. Writes to the primary node are transferred to the lower-level block device and simultaneously propagated to the secondary node. The secondary node then transfers data to its corresponding lower-level block device. All read I/O is performed locally. Should the primary node fail, a cluster management process promotes the secondary node to a primary state. This transition may require a subsequent verification of the Introduction 13

24 integrity of the file system stacked on top of DRBD, by way of a filesystem check or a journal replay. When the failed ex-primary node returns, the system may (or may not) raise it to primary level again, after device data resynchronization. DRBD's synchronization algorithm is efficient in the sense that only those blocks that were changed during the outage must be resynchronized rather than the device in its entirety. The DRBD suite is open source and licensed under the GNU General Public License v2 and is part of the official Linux kernel. It is mainly being developed by the Austrian company LINBIT. Novell has a strong partnership with LINBIT and therefore can ensure a fast and high-quality support as well as a fast resolution of software defects (bugs) SAP Resource Agents The SAP Instance Resource Agent is responsible for starting, stopping and monitoring the services in a SAP instance. The following services are monitored in the resource agent: disp+work, msg_server, enserver, enrepserver, jcontrol, and jstart. The SAP Instance Resource Agent can be used to manage the following SAP instances: SAP WebAS ABAP Release , SAP WebAS Java Release (for 6.40 please also read SAP note ), SAP WebAS ABAP + Java Add-In Release (Java is not monitored by the cluster). The purpose of the SAP Database resource agent is to start, stop and monitor the database instance of an SAP system. Together with the relational database management systems (RDBMS), it will also control the related network service for the database, like the Oracle Listener and the xserver of MaxDB. The resource agent expects a standard SAP installation and therefore needs fewer parameters to configure. The monitor operation of the resource agent can test the availability of the database by using SAP tools (R3trans or jdbcconnect). This ensures that the database is really accessible for the SAP system. The SAP Database resource agent supports the following databases in a SAP installation: Oracle 10gR2 and 11gR2, 14 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

25 IBM DB2 UDB for Windows and Unix 9.x, SAP-DB / MaxDB 7.7. The resource agents are part of the SUSE Linux Enterprise Server High Availability Extension. 1.4 Database for SAP Three major RDBMS are supported with SAP on SUSE Linux Enterprise Server, either with or without the SUSE Linux Enterprise Server High Availability Extension. In addition, for SAP deployments with each of these databases, SAP priority support is available from Novell. Oracle 10gR2 and 11gR2 IBM DB2 UDB for Windows and UNIX 9.x SAP-DB / MaxDB 7.x The supported hardware platform for all RDBMS on SUSE Linux Enterprise Server 11 is x86-64 (also known as x86 64-bit, AMD64, EM64T ). Nevertheless, some databases are also supported on other hardware platforms such as power or z-series. Details can be found on the certification pages listed as links in the appendix. SUSE Linux Enterprise Server ships with an installation pattern for Oracle database servers. The pattern contains the RPM package orarun which sets several system settings according to the needs of an Oracle server. If Oracle is installed together with SAP, this package should not be installed to avoid conflicts with the settings from the RPM sapconf. Further information can be found on the web pages listed in the appendix. MaxDB was chosen as RDBMS for this document mainly to shorten the planning and installation procedure. Since the document is targeting a basic installation of SAP in a high-availability cluster, the use cases are covered with MaxDB. This installation example does not imply any judgement on how well one of the database management systems fits for a given workload. Introduction 15

26 1.4.1 MaxDB The SAP MaxDB is the database of choice for small business and midsize companies requiring a solid, affordable low-maintenance database. MaxDB is available for all installations of the SAP Business All-in-One solution and the SAP Business Suite family of business applications. MaxDB is bundled with the full license for the SAP NetWeaver technology platform. And the SAP Business by Design solution uses MaxDB as the default database for the host system. Designed for online transaction processing and database sizes up to multiple terabytes, MaxDB is the preferred database for internal SAP installations on UNIX and Linux ( sme/businessallinone/kits/lowertco.epx). MaxDB s ancestor AdabasD was available on Linux in Between 1997 and 2004 the software was available as SAP-DB, then it was renamed to MaxDB. MaxDB as standalone product is supported for SUSE Linux Enterprise Server 11 on the hardware platforms x86-64 and ppc64 ( As an integrated database for the SAP NetWeaver technology platform, the respective certification applies for SUSE Linux Enterprise Server 11 on x86-64 and ppc64. For SAP systems, the appropriate product certification matrix should be applied ( websmp201.sap-ag.de/pam). MaxDB installation media can be obtained from the SAP portal along with NetWeaver. The installation of MaxDB is seamlessly integrated into the SAP installer. SAP offers several services around MaxDB for SAP applications. More information can be found on the Web pages listed in the appendix. 1.5 Sizing, Deployment and Migration Considerations Running SAP workloads in SUSE Linux Enterprise Server can reduce the TCO considerably. Through the homogenization of the data center (and thus the consolidation of resources), cost savings can be achieved even for highly specialized SAP installations. SUSE Linux Enterprise Server is very well prepared for automated installation and deployment, making it easy to deploy many servers. Novell provides tools for managing updates and releases as well as ease day-to-day administration. 16 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

27 SUSE Linux Enterprise Server is very capable of providing the base for small or large systems. Customers run smaller central instances or larger distributed systems all with the same system base. It is quite possible to run multiple SAP instances in parallel on one system even when using high availability clusters. SAP requests that system sizing is done by the hardware vendor. Novell has good relationships with many hardware vendors to make sure SUSE Linux Enterprise Server runs smoothly on a broad range of enterprise servers fit to run SAP workloads. Novell and its partners are very active in providing customers with solutions to their specific needs when it comes to Linux deployment. Novell consulting has been developing best practices for high availability SAP installations and provides this information to customers and partners. Hundreds of successful SAP to Linux migrations have been made. The results regarding cost savings, performance and reliability have exceeded expectations in many instances. Since most data centers have adopted a Linux strategy, the know-how for deploying and administrating Linux systems is often in place and available. SAP-specific configurations and administration experience is available through Novell consultation and partners. This makes the operating system side of the migration less risky and a ROI can be seen within the first six months of migration. SAP provides check lists and guidelines for the OS and database migration. Introduction 17

28

29 One Concept Two Use Cases 2 SAP NetWeaver installation can be adapted to several architectures for the entire system. You can plan and implement a simple stack SAP system with one instance and the database on the same machine without any methods to increase the availability. You can take this simple installation scenario, add high availability components and bring the SAP system into a high availability scenario. There may also be reasons to install a SAP system with additional application servers. In a high availability scenario, this could lead to a more advanced enqueue replication setup. In all previously mentioned cases, SAP is treated in a two-tier manner, this means SAP application and database processes can run on the same system. Another common use case is to run the enqueue replication server and the database on different machines. In this case, high availability for the enqueue replication server is covered by the described concept as well. This document covers these two use cases: DRBD dual data center with two clusters - 2x2 nodes DRBD dual data center with one cluster and one standalone node nodes Both use cases (2x2 and 2+1) can be used with all common SAP installation types. SAP central system: All instances are running on one node. Depending on the installation type, this may be one central instance or multiple instances on one node. SAP enqueue replication: The replicated enqueue server solves one availability issues of the enqueue service which otherwise would be a single point-of-failure (SPOF). The One Concept Two Use Cases 19

30 replicated enqueue server provides a transparent solution to this availability issue and enables the SAP system to continue production in the case of a failing enqueue server. In a typicall setup there are two host machines (physical or virtual), one for the standalone enqueue server and one for the replicated enqueue server. Refer to the SAP documentation at the SAP Marketplace for more details. Such a two system setup has the following advantages: Redundancy: The replicated enqueue server holds a complete copy of the lock table. Flexability: The two most critical components (enqueue server and message server) could be restarted in a very short time and even faster than a complete SAP application server. Availability: The standby server runs a replicated enqueue server that can be activated if the primary enqueue server fails, using the enqueue table copy. The result is that in the event of standalone enqueue server failure, no transactions or updates are lost and the enqueue service for the SAP system continues without interruption. The SAP instances are running on different nodes, including the enqueue replication mechanism. The database may run on a different cluster. The installation of the first use case (2x2) will be shown step by step in this document. The simplified use case 2 (2+1) can be easily adopted from the first use case by omitting the setup of the second cluster. Of course, you have to setup the complete storage stack and IP addresses. 2.1 High Availability Concept Overview The concept was chosen to match these top-level goals: High availability Low complexity Flexible scalability 20 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

31 Road capability To achieve these goals, we separate the SAP system into a clustered and an unclustered area. The clustered area holds all mandatory SAP components such as SAP database and needed SAP instances. The unclustered area holds all optional and scalable SAP components such as additional SAP instances. This allows to scale the entire SAP system without increasing the cluster complexity. The horizontal scaling is just a purpose of the unclustered area. The architecture is focused to one single SAP system, even if it is possible to run more than one SAP system in the same cluster. The example configuration described in this document consists of a total of 4 SAP nodes spread across two distinct sites, with 2 nodes per site. The nodes in each site form a Pacemaker high availability cluster. This architecture assumes that within a single site, a SAN exists with fully meshed fibre channel connectivity. Cluster nodes are assigned two SCSI Logical Units (LUNs) spread across two different shared storage devices. Each cluster node has access to both LUNs with redundant (multipath) connectivity and uses Linux software RAID (MD) for hostbased mirroring. For replication between sites, a DRBD device is layered on top the RAID mirror. Thus, asynchronous storage replication between sites requires no SAN connectivity -- simple IP connectivity is sufficient. This concept uses STONITH (Shoot The Other Node In The Head) and can be expanded with SFEX (Shared Disk File Exclusiveness). While STONITH allows server fencing using remote management boards over LAN, SFEX provides storage protection over SAN. In our example setup for DRBD we do not use SFEX. One Concept Two Use Cases 21

32 Figure 2.1 General Architecture The network file system (NFS) is used to share data between the nodes, for example for the SAP transport directory. In this concept we assume that a reliable NFS is provided by a service outside the cluster. Either a highly available NFS server based on SUSE Linux Enterprise Server 11 or a third party product could be used. An NFS high availability cluster based on SUSE Linux Enterprise Server 11 is described in another document. In some case it might be desirable to have the NFS server in the same cluster as the SAP application. This is also covered in an extra document. 22 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

33 In a complex, high availability SAP environment, several types of failures may occur. These failures range from software crashes up to a loss of the whole network or SAN infrastructure. The cluster must be able to safely handle all of these failures. Even in a split brain scenario, if the cluster communication between both nodes is broken, the cluster must ensure a proper continuation of all services Server Fencing and Storage Protection STONITH, SBD, watchdog, and LAN-based quorum STONITH (Shoot the other Node in the Head) is a key mechanism of corosync clusters. STONITH is used to clearify the cluster node status in a situation where a cluster node got lost. Such a situation can occur in the following example cases: A node has a power outage or (complete) hardware problem, so the node is not longer available. A node crashes with a kernel freeze. A node has far to high load and cannot answer on the cluster communication for a (longer) period of time. A node has a network disruption and cannot answer on the cluster communication. In all these cases, the cluster can notify that a node got lost but cannot determine whether the node can still affect any resources controlled by the cluster. This is why the cluster decides to fence the node via a STONITH device. Such a STONITH action can switch a node off or force it to reboot (reset). Typical STONITH methods are: Remote Management Board-based system control Remote management boards, like HP's ILO boards can reset, start or shut down a server. The reset and power cycle functions can be accessed not only via their webinterfaces but also via the network using standardized interfaces like IPMI (intelligent platform management interface) or similar. This functionality makes these boards ideal candidates for STONITH agents. For ILO2 boards, a dedicated STONITH agent called riloe exists. For boards of other manufacturers, take a look at the list of available One Concept Two Use Cases 23

34 STONITH agents or use the IPMI agent, which works for most servers. A clear disadvantage of STONITH with remote-management boards is that a total power failure of a server also disables the remote management boards. A STONITH request from another node cannot be completed in this case and prevents an automatic fail-over. Power switch-based system control Remotely controllable power switches provide a reliable way to start, shut down and power-cycle a server. This method is preferred over the use of remote management boards. It is much more likely that a power switch is still accessible after a powerfailure affecting a single server than a remote management board, which usually relies on the power supplies of the affected server. STONTIH agents exist for various power-switches, e.g. from APC. A disadvantage of power-switches may be the administrative domain in large data centers. If the power switch is not under control of the cluster administration team, it may happen that somebody changes the password of the power-switch without noticing the cluster team. SBD (Split Brain Detection) - SAN-based system control An alternative option is STONITH based on a Split Brain Detection (SBD) disk together with the kernel watchdog. Future implementations of the SBD will respect the cluster's quorum status. In case the SBD disk fails, the cluster will continue to work as long as it has the quorum. Thus, the impact of a failing SAN LUN is reduced compared to the SFEX-based solution mentioned above. The second major advantage is that server fencing works in LAN-split, SAN-split, and complete-split scenarios. A solution based on this SBD will be described in another document. In this example installation, we use the Management Board-based system control via IPMI or ILO interfaces. 2.2 Use Case 1 DRBD dual data center with two clusters - 2x2 The "2x2" scenario of the DRBD dual data center uses two separate and nearly independent corosync clusters working at two different sites. Nearly independent cluster means that the clusters do not have a direct communication at the cluster layer, so both cluster frameworks are running only local at their specific site. 24 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

35 Of course the data need to be synchronized from one site to the other and that is why the cluster nodes of one site need a communication channel via TCP/IP to the other site. To avoid both clusters to run the DRBD device in master role and to start the SAP system, one site is defined to always run the DRBD device in slave mode (be the passive side of the synchronization). The other site is defined to always run the DRBD device in master mode (be the active side of the synchronization). If the data center communication fails, the current site running the SAP system will stay productive while the other site is waiting for the DRBD synchronization to come back. If the active cluster site fails completely and you need to run a site-failover, the administrator needs to change the DRBD device role from slave to master. Of course the administrator must prevent both clusters from running in master mode at the same time. This is why we decided to run the site-failover in a semi-automatic mode with only one administrative interaction. You can also run the sites active/active if you place more than one SAP system on the clusters and define multiple DRBD synchronizations. But each of these DRBD devices needs to be run as master/slave and never dual active. Figure 2.2 DRBD synchronization with two clusters in two data centers One Concept Two Use Cases 25

36 The advantages of this cluster model: Flexible design Synchronization between two data centers Second site also runs with High Availability to improve the status of the DRBD synchronization Both sites uses the same architecture Site failover is semi-automatic but can be triggered easily. One disadvantage is: Four nodes are used for this concept. 2.3 Use Case 2 DRBD dual data center with one cluster The "2+1" scenario of the DRBD dual data center uses one corosync cluster and a standalone node working at two different sites. The data must be synchronized from one site to the other, therefore the cluster nodes of one site need a TCP/IP communication channel to the standalone node of the other site. To avoid both sites running the DRBD device in master role and to start the SAP system, one site is defined to always run the DRBD device in slave mode (be the passive side of the synchronization). The other site is defined to always run the DRBD device in master mode (be the active side of the synchronization). If the data center communication fails, the current site running the SAP system will stay productive while the other site is waiting for the DRBD synchronization to come back. If the active cluster site fails completely and you need to run a site-failover, the administrator needs to change the DRBD device role from slave to master and start a procedure which starts all resources (storage devices, file systems, IP addresses, database and 26 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

37 SAP instances). The administrator must prevent both clusters running in master mode at the same time. This scenario does not provide a semi-automatic site-failover. The failover must be covered by the system management procedures. Figure 2.3 DRBD synchronization with two clusters in two data centers Flexible design Synchronization between two data centers Price: Only 3 nodes are used for the local High Availability cluster and the datacenter synchronization. Some disadvantages are: The sites uses different architectures Site takeover is more complex (start of the SAP system) Not recommended for active/active scenarios. One Concept Two Use Cases 27

38

39 Part II. Installation of "DRBD dual data center" with MaxDB

40

41 Installation Overview 3 This part describes the installation of a SAP NetWeaver with MaxDB on SUSE Linux Enterprise Server for SAP Applications for a proof of concept. The procedure is divided into the following steps: Planning (Chapter 4, Planning (page 33)) Checking prerequisites (Chapter 5, Prerequisites (page 35)) Downloading SAP NetWeaver installation media (Chapter 6, Download the Needed SAP Installation Media (page 39)) Installation of SUSE Linux Enterprise Server for SAP Applications on all nodes (Chapter 7, Install SUSE Linux Enterprise Server 11 SP1 for SAP (page 43)) Preparing SAN storage on both sites (Chapter 8, Prepare SAN Storage (page 49)) Cluster Configuration on both sites (Chapter 9, Configure the Cluster on both Sites (page 63)) Installation of SAP NetWeaver and MaxDB (Chapter 10, Install SAP NetWeaver 7.0 EHP1 (page 75)) Integration of SAP NetWeaver and MaxDB into the High Availability Cluster (Chapter 11, Integrating SAP into the cluster (page 85)) Checking final results (Chapter 12, Testing the Cluster (page 87)) Installation Overview 31

42

43 Planning 4 Proper planning is essential for a well performing SAP system. For planning and support of your SAP installation, visit [ to download installation guides, review installation media lists and browse through the SAP notes. This section focuses on aspects of planning a SAP installation. The first major step is to size your SAP system then derive the hardware sizing to be used for implementation. Use the SAP benchmarks ( solutions/benchmark/index.epx) to estimate sizing for a proof of concept. If you plan to migrate an existing SAP system you should first obtain or estimate the system characteristics of the old SAP system. The key values of these characteristics include: SAPS (benchmarks) of the old SAP system Memory (RAM) size and usage of the old hardware Disk size, performance and usage of the old SAP system Network performance and utilization of the old hardware Language support (including Unicode) If you have valid key values, you can adapt these to the characteristics of your new SAP system. If you plan a new installation instead of a migration, you might need to adapt experiences with other SAP installations or use some of the published benchmarks as mentioned above. Planning 33

44 Estimate the SAPS in the new SAP system. This includes planning additional capacities, if needed. The calculation should also include estimated growth calculations, such as a boost of SAPS per year. Typical SAP growth is between 10% and 20% per year. Choose RAM size, as well as disk size and performance for the Linux system. Also include a boost of the usage. Depending on the usage, the disk space may grow 30% per year. The disk size must also include the export and r3trans areas if they are not provided by other servers. Check if Unicode support is necessary for the new system. 34 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

45 Prerequisites 5 This chapter describes what hardware and software is needed for a proof of concept. It also outlines how to gather all information necessary to succeed. 5.1 Hardware Requirements The final hardware sizing for production systems is always the responsibility of the hardware vendor. At the time this document was written, a base installation of NetWeaver on top of SUSE Linux Enterprise Server 11 SP1 for a proof of concept could be done on the following hardware equipment: 2* CPU x GHz (AMD64 or EM64T), 8GB RAM, 100GB disk space for OS and empty SAP system, a few hundred GB up to some TB additional disk space for test data, 3* Gbit/s Ethernet, IPMI or ILO remote management board. Although the cluster offers High Availability across two servers, each single server should already have the maximum possible availability using redundant devices: self correcting ECC RAM, Prerequisites 35

46 two or three redundant power supplies (connected to two circuits), several redundant cooling fans, two or more internal disks with RAID(1/5/6/10) controller, redundant LAN network controllers, redundant LAN network links (connected to two switches), redundant SAN host bus controllers, redundant SAN FC links (connected to two switches). Make sure to use certified hardware. Information about certified hardware can be found in the Novell YES database ( Search.jsp), in the SAP notes and on the hardware manufacturer's pages. Use certification notes from the Novell YES database and the hardware manufacturer to select appropriate hardware components. 5.2 Software Requirements, Connection Data, and all the Rest Before you can start with the installation, make sure you meet the prerequisites. SAP documentation: Make sure that you have the latest version of the Master Guide by checking SAP Service Marketplace immediately before starting the installation. The Master Guide is regularly updated on SAP Service Marketplace at service.sap.com/instguidesnw70. Sizing data gathered in the planning stage for the installation. Configuration data: IP addresses, DNS names, gateway SAP SIDs Linux usernames (like <sid>adm), UIDs 36 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

47 Connection data: SAN LUNs (names, LUN numbers) and multipath configuration parameters. There are some special parameter settings for multipath and SAN-HBA kernel modules, depending on the hardware setup (SAN storage model and SAN setup). Check if SAN storages require partition alignment for performance reasons. Refer to the installation and configuration guides from Novell and hardware vendors. Access to the system management boards to be used by the cluster to fence a node in special cases (STONITH). For most common data center hardware, there are supported management boards like ILO or IPMI, which provide stable interfaces to be used with STONITH. In addition to the network that connects the SAP servers to the clients, we recommend two additional dedicated network links between the two servers for cluster intercommunication. At least one additional dedicated network link is mandatory. Infrastructure such as DNS server, NTP server and a pingable highly available network node. This network node can be the gateway between the SAP system and the clients who need to access the service. If the gateway is no longer available, the service is not available. The cluster can determine which cluster node has a (ping) connection to the ping node and can migrate a service if needed. SAP installation media (for details see the table in the next section). The SAP installation media can either be ordered as a physical CD/DVD or downloaded from The next section describes the procedure for downloading the SAP media. SAP S-User (partner user) to download the media and installation guides and to browse through the SAP notes system. The S-User must have permission to download the installation media. Ask your company's SAP partner manager to create an S-User and to grant the proper rights. During installation of the central instance of SAP NetWeaver you will be asked to provide a Solution Manager Key. You need to create such a key for your combination of hostname (DNS name of the virtual IP address for high availability installations), SAP system ID (SID) and SAP instance number (like 00, 01, 02). This key can be created using your company s Solution Manager, an additional SAP program. This document does not cover the installation of the Solution Manager. If you do not have Prerequisites 37

48 access to your company s Solution Manager, ask your internal SAP partner manager how to get a Solution Manager key. To download the SAP installation media, you will need the SAP download manager. A short description of the installation is integrated in the next section. To run the download manager you need a matching Java version. In former PoCs, SUN Java (package java-1_6_0-sun u1-26) worked very well. Have a look at the installation notes presented during the procedure to download the SAP download manager. An up-to-date patch level of the SUSE Linux Enterprise Server 11 SP1 installation. You will need: a Novell Customer Center account, "SUSE Linux Enterprise Server for SAP Applications 11 SP1" installation media for x86-64 hardware platform, or "SUSE Linux Enterprise Server 11 SP1" and "SUSE Linux Enterprise High Availability Extension 11 SP1" installation media for x86-64 hardware platform, possibly additional hardware-specific driver updates, and a software management software such as the subscription management tool (optional). To test the SAP system you either need to have a previously installed SAP client (guilogon, guistart) or you need to install this software on at least one of your workstations. 38 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

49 Download the Needed SAP Installation Media 6 This section describes in a more general way how to download the SAP installation media. As an example, we download the media for SAP NetWeaver 7.0 EHP1 with database engine MaxDB RDBMS 7.7 for SUSE Linux Enterprise Server 11 SP1 x We recommend you use a SUSE Linux Enterprise Server 11/SUSE Linux Enterprise Desktop 11 SP1 or newer to download the media. This section only describes the download using a SUSE Linux Enterprise system. 1. Access the SAP download site 2. You are asked to login with your S-User and password (see prerequisites). 3. From the menu on the left, select Download Installation and Updates Entry by Application group. 4. From the Installation and Upgrades menu on the right, select SAP NetWeaver SAP NetWeaver (yes, twice). 5. Now you have to select your NetWeaver version. In our example, we select SAP EHP1 for SAP NetWeaver 7.0 Installation and Upgrade Linux SAP DB. The version for your use case may differ, the example will follow the names and paths of NW 7.0 EHP1. 6. From the media list, select the following media and click on Add to download basket. Download the Needed SAP Installation Media 39

50 Table 6.1 SAP NetWeaver Installation Sources Type Number Title Size [KB] Date ZIP CD SAP License Keys & License Audit EXE _1 Onl. Doc. SAP NW 7.0 EHP1 SPS02 1 of RAR _2 Onl. Doc. SAP NW 7.0 EHP1 SPS02 2 of EXE _1 NW 7.0 EHP1 Installation Export 1 of RAR _2 NW 7.0 EHP1 Installation Export 2 of EXE _1 NW 7.0 EHP1 Kernel LINUX 1 of RAR _2 NW 7.0 EHP1 Kernel LINUX 2 of RAR _3 NW 7.0 EHP1 Kernel LINUX 3 of RAR _4 NW 7.0 EHP1 Kernel LINUX 4 of RAR _5 NW 7.0 EHP1 Kernel LINUX 5 of RAR _6 NW 7.0 EHP1 Kernel LINUX 6 of RAR _7 NW 7.0 EHP1 Kernel LINUX 7 of Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

51 Type Number Title Size [KB] Date RAR _8 NW 7.0 EHP1 Kernel LINUX 8 of ZIP _8 NW 7.01/BS 7 Installation Master Linux on x bit ZIP _8 MaxDB RDBMS Build 28 - Linux on x bit The total size of installation sources is 10GB for the chosen NetWeaver 7.0 EHP1 with MaxDB. To unpack the archives, roughly twice the disk space is needed. Other products might need more space. 7. After some time, a pop-up with two buttons appears. Press "Download Basket". 8. Your selected media is shown in your download basket. If you haven't installed the SAP download manager yet, you will have to download and install it now. Click get download manager in this case. The SAP Download Manager Installation Guide is shown. Check the section prerequisites and the SAP Download Manager installation guide. You need a Java version that fits SAP needs. Download the Linux version. You get a self-extracting archive that starts after the download. Follow the installation steps. We have installed the Download Manager in the local home directory, SAP_Download_Manager. 9. Start the installed SAP Download Manager using the command ~/SAP_Download/Manager/Download_Manager. 10. If you start the SAP Download Manager for the first time, you will need to provide some credentials such as the SAP Marketplace address ( Download the Needed SAP Installation Media 41

52 .com), your S-User, your S-User-Password and the Data Store (directory to place the downloaded files). 11. Press the "download all objects" button (the button with two right arrows). 12. Be patient, the download will take some time. 13. After the download, unpack the downloaded files using unzip (for ZIP type) and unrar (for EXE and RAR type). Unrar is able to skip the self extracting code in the EXE files and will include all files of a media set such as 1/2, 2/ Copy (rsync) the extracted files to your system to be installed or create NFS exports on the installation source and NFS mounts on the target systems. In our setup we use: /sapcd/instma for the Installation Master, /sapcd/kernel for the NW 7.01 kernel, /sapcd/maxdb for the MaxDB engine, /sapcd/instexp NW 7.0 EHP1 installation export. 15. You also need the JRE Unlimited Strength Jurisdiction Policy Files Archive (unrestricted.zip) matching your Java version. Download it from either IBM or SUN. 42 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

53 Install SUSE Linux Enterprise Server 11 SP1 for SAP 7 In this chapter we describe relevant configuration parameters of SUSE Linux Enterprise Server 11 SP1 x86-64 for this use case. The installation procedure itself should be well known to the target audience and therefore is not described. Refer to the product documentation for general information on the SUSE Linux Enterprise Server 11 ( You can also use this chapter for the installation of SUSE Linux Enterprise Server for SAP Applications 11 SP File System Layout For a proof of concept, the following partition and file system layout for the operating system is a good example: Table 7.1 OS File System Layout No. Mount Point Size File System Options 1 /boot 128MB ext2 noatime 2 swap 2*RAM (max. 20GB) swap 3 / 16GB ext3 noatime Install SUSE Linux Enterprise Server 11 SP1 for SAP 43

54 No. Mount Point Size File System Options 4 /var rest ext3 noatime,data=writeback SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise High Availability need about 4.5GB disk space. The size of /boot depends on the number of kernels that should be installed in parallel. Each kernel needs approximately 35MB disk space in /boot. The size of /var depends on the amount of log data and application-specific usage, 5GB or more are appropriate. If the SAP NetWeaver installation sources should be put on the local disk, 20GB additional free space is needed. We use the directory link /sapcd in our examples. Besides the usual OS file systems, SAP and the SAP databases require their own file systems. These file systems are not stored locally. Instead they are provided by NFS file servers or on LUNs in Storage Area Networks (SAN). Typically we need for SAP: /sapmnt /usr/sap/<sid> /sapdb (for MaxDB. Oracle and DB2 require other paths.) File system sizes depend on the use case. The database file system can be from 100GB up to multiple TB. After a fresh installation, around 30GB are in the database. 7.2 Software Selection It is a good practice to install as little software as needed or recommended. We deselect the GNOME Desktop Environment as we plan to run the server in runlevel 3 and not use local Gnome sessions. Since we install the X Window System, we can still start X-Window-based applications locally or remotely. We also deselect AppArmor, because we do not plan to use it. SAP recommends some additional software to be installed. The resulting pattern selection should be: + Base system pattern + X Window pattern + 32-bit runtime pattern + Print server pattern + SAP Application Server Base pattern 44 Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability - DRBD dual data center

55 + C/C++ Compiler and Tools pattern + High Availability pattern - No AppArmor pattern - No Gnome pattern NOTE If you are installing SLES for SAP, then you should also install the pattern High Availability. For the standard SLES, we recommend to install this pattern later. Now your pattern list should look like the one in: Figure 7.1 SUSE Linux Enterprise Server 11 Software Selection for SAP Make sure you also install the following SAP-specific packages: sapconf prepares the operating system for SAP needs. sap-locale contains special code pages only needed for non-unicode systems. If you plan to run SAP application servers on SUSE Linux Enterprise Server together with application servers on another OS, see SAP Notes and on how to get the correct code pages. Install SUSE Linux Enterprise Server 11 SP1 for SAP 45