Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64) Manufacturing Part Number: T2392-90013 February 2008
Legal Notices Copyright © 2000-2008 Hewlett-Packard Development Company, L.P. Serviceguard, Serviceguard Extension for SAP, Serviceguard Extension for RAC, Metrocluster and Serviceguard Manager are products of Hewlett-Packard Company, L. P., and all are protected by copyright. Confidential computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR 12.211 and 12.
Contents 1. Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios . . . . . . . . . . . Mutual Failover Scenarios Using the Two Package Concept . . . . . . . . . . . . . . . . . . . Robust Failover Using the One Package Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clustering Stand-Alone J2EE Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Highly Available (HA) NFS . . . . . . . . . . . . . .
Contents SGeSAP/LX Package Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Installation Tasks and Installation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Serviceguard Extension for SAP on Linux: cmcluster.config . . . . . . . . . . . . . . . . . . . 83 SAP Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 SAP Installation Considerations . . . . . . . .
Contents 5. Serviceguard Extension for SAP on Linux Cluster Administration Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Level Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAP Software Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Serviceguard Extension for SAP on Linux Administration Aspects . . . . . . . . . .
Contents 6
Printing History Table 1 Editions and Releases Printing Date Part Number Serviceguard Extension for SAP on Linux Operating System Releases Oct/04 T1227-90004 x86_32 RHEL 3 SLES 8 Dec/05 T2392-90001 IA64 Integrity SLES 9 July/06 T2392-90010 IA64 Integrity and x86_64 RHEL 4 SLES 9 Feb/08 T2392-90013 IA64 Integrity and x86_64 RHEL 4, RHEL 5 and RHEL 5.1 SLES 9 and SLES10 The printing date and part number indicate the current edition. The printing date changes when a new edition is printed.
About this Manual... This document describes how to configure and install highly available SAP systems on Linux using Linux Serviceguard. To get further information regarding SAP and High Availability in general, please refer to the SAP documents: • SAP Web Application Server in Switchover Environments • SAP BC High Availability To understand this document you have to have knowledge of the basic Serviceguard concepts and commands. Experience in the Basis Components of SAP will also be helpful.
Understanding Serviceguard Extension for SAP on Linux 1 Understanding Serviceguard Extension for SAP on Linux HP Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64) hereafter documented as HP Serviceguard Extension for SAP on Linux, extends HP Serviceguard’s failover cluster capabilities to SAP application environments. Serviceguard Extension for SAP on Linux continuously monitors the health of each SAP cluster node and automatically responds to failures or threshold violations.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios Designing Serviceguard Extension for SAP on Linux Cluster Scenarios SAP applications can be divided into one or more distinct software components. Most of these components share a common technology layer, the SAP Web Application Server (SAPWAS). The SAP Web Application Server is the central building block of the SAP Netweaver technology.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios The following sections introduce different Serviceguard Extension for SAP on Linux package types and provide recommendations and examples for the cluster layouts that should be implemented.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios Mutual Failover Scenarios Using the Two Package Concept SAP ABAP Engine based applications usually rely on two central software services that define the software SPOFs: the SAP Enqueue Service and the SAP Message Service. These services are traditionally combined and run as part of a unique SAP Instance that is called the Central Instance (ci).
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios Every ABAP Engine also requires a database service. Usually, this is provided by ORACLE or MAXDB RDBMS systems. The package type (db) clusters any type of these databases. It unifies the configuration, so that database package administration for all vendors is treated identically.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios A cluster can be configured in a way that two nodes back up each other. The principle layout is depicted in figure 1-1. This picture as well as the following drawings are meant to illustrate basic principles in a clear and simple fashion. They omit other aspects and the level of detail that would be required for a reasonable and complete high availability configuration.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios Robust Failover Using the One Package Concept In a one-package configuration, both the database (db) and Central Instance (ci) run on the same node at all times and are configured in one Serviceguard Extension for SAP on Linux package. Other nodes in the Serviceguard cluster function as failover nodes for the primary node on which the system runs during normal operation.
Understanding Serviceguard Extension for SAP on Linux Designing Serviceguard Extension for SAP on Linux Cluster Scenarios Some Web Application Server installations automatically install more than one Central Instance at a time. E.g. a SAP Exchange Infrastructure 3.0 installation creates a DVEBMGS instance as well as a System Central Service SCS instance using different Instance Numbers.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components Clustering Stand-Alone J2EE Components Some SAP applications are stand-alone J2EE components and do not come in an ABAP context. For example, SAP Enterprise Portal installations. Beginning with SAP Web Application Server 6.40, these components can be treated a fashion similar to ABAP installations. Comparing Figure 1-4 with Figure 1-3 shows the similarity on a conceptual level.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components Highly Available (HA) NFS Distributed SAP environments require the Network File System (NFS) to be highly available. Serviceguard Extension for SAP on Linux packages can be combined with the Serviceguard NFS toolkit for Linux to achieve this functionality. Typically, the Serviceguard Extension for SAP on Linux database package also provides Highly Available NFS functionality.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components Dialog Instance Clusters as Simple Tool for Adaptive Enterprises Databases and Central Instances are Single Points of Failure. ABAP Dialog Instances can be installed in a redundant fashion. In theory, this allows to avoid additional SPOFs in Dialog Instances. This doesn’t mean that it is impossible to configure the systems including SPOFs on Dialog Instances.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components One can simulate this flexibility by installing Dialog Instances on every host and activating them if required. This might be a feasible approach for many purposes and saves the need to maintain virtual IP addresses for each Dialog Instance. But there are ways that SAP users unintentionally create additional short-term SPOFs during operation if they reference a specific instance via its hostname. This could e.g.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components Dialog Instance packages provide high availability and flexibility at the same time. The system becomes more robust using Dialog Instance packages. The virtualization allows to move the instances manually between the cluster hosts on demand.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components necessary caused by a fail back of the (dbciSID) package. The two instances can be separated to different machines without impacting the production environment negatively.
Understanding Serviceguard Extension for SAP on Linux Clustering Stand-Alone J2EE Components Standard Serviceguard Extension for SAP on Linux scenarios at least protect database, NFS, Message Server and Enqueue Server. It is recommended that you also protect at least one instance of each additional SAP WAS ABAP Application Service in the Serviceguard cluster. If non-packaged Additional Dialog Instances are used, certain rules should be followed: Use saplogon with Application Server logon groups.
Understanding Serviceguard Extension for SAP on Linux The Replicated Enqueue The Replicated Enqueue In case your environment has very high demands regarding guaranteed uptime, it makes sense to active a Replicated Enqueue with Serviceguard Extension for SAP on Linux. With this additional mechanism it is possible to failover ABAP or JAVA System Central Service Instances without impacting ongoing transactions on Dialog Instances.
Understanding Serviceguard Extension for SAP on Linux The Replicated Enqueue A stand-alone version of the Enqueue Server is included with the binaries of SAP kernel 6.40. The stand-alone version of the Enqueue Server has the ability to create a copy of its memory content to a Replicated Enqueue Service that needs to be running on a remote host. This is a real-time copy mechanism and ensures that the replicated memory accurately reflects the status of the Enqueue Server at all times.
Understanding Serviceguard Extension for SAP on Linux The Replicated Enqueue the ASCS Instance provides startup and shutdown routines, failure detection, split-brain prevention and quorum services to the stand-alone Enqueue Server.
Understanding Serviceguard Extension for SAP on Linux The Replicated Enqueue Dedicated Failover Host More complicated clusters that consolidate a couple of SAP applications often have a dedicated failover server. While each SAP application has its own set of primary nodes, there is no need to also provide a failover node for each of these servers. Instead there is one commonly shared secondary node that is in principle capable to replace any single failed primary node.
Understanding Serviceguard Extension for SAP on Linux The Replicated Enqueue transactions for the systems they belong to. They are ideally sacrificed in emergency conditions in which a failing database and/or Central Instance need the spare resources.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure Serviceguard Extension for SAP on Linux File structure The Linux distribution of Serviceguard uses a special file, /etc/cmcluster.config, to define the locations for configuration and log files within the Linux file system. These paths differ depending on the Linux distribution used.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure The cmapplyconf(1m) command together with the above two files (xxx.config and xxx.control.script) is used to create a Serviceguard package “xxx”. The cmapplyconf command generates or updates the data that is stored in the binary configuration file ${SGCONF}/cmclconf and distributes it to all cluster nodes. • SAP in one-package: dbci.config, dbci.control.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure Package Directory Content for the One-Package Model NOTE In this document, references to ${SGCONF} can be replaced by the definition of the variable that is found in this file /etc/cmcluster.config.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure • ${SGCONF}//customer.functions - contains all functions which can be modified for special setups. This file may also contain your own additional functions. If there is a need to do a hotfix to functions in ${SGCONF}/sap.functions, copy them over to ${SGCONF}//customer.functions and modify them there. Never modify ${SGCONF}/sap.functions itself. Any function provided in customer.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure Package Directory Content for the Two-Package Model NOTE In this document, references to ${SGCONF} can be replaced by the definition of the variable that is found in this file /etc/cmcluster.config.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure 34 • ${SGCONF}//dbhanfs.sh - contains NFS specific runtime logic used during database package startup or shutdown. It needs to be customized. The file is optional, if a central Highly Available NFS package is used. • ${SGCONF}//dbtoolkit.sh - contains NFS specific flowlogic for package startup and package shutdown. It is optional, if a central Highly Available NFS package is used.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure Figure 1-5 illustrates the required configuration files, and the questions they answer, for an Serviceguard Extension for SAP on Linux application package in Serviceguard. Figure 1-5 Configuration Files Needed to Build a Cluster cmapplyconf cmcluster.config ciSID.config, dbSID.
Understanding Serviceguard Extension for SAP on Linux Serviceguard Extension for SAP on Linux File structure 36 Chapter 1
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment 2 Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment The goal of this chapter is to determine the correct storage layout for SAP file systems in a Serviceguard cluster configuration.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Overview The following table outlines important concepts that you should understand before using Serviceguard with SAP. Each step is cumulative, that is each step builds upon itself.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Configuration Environments About SAP Configuration Environments The SAP Web AS (Application Server) options offer migration paths between the older ABAP engines and the newer J2EE JAVA engines. You can choose to program your SAP applications using the following options: • ABAP (Advanced Business and Application Programming) is the original programming language for developing applications for an SAP R/3 system. • .
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Configuration Environments Table 2-2 SAP Web AS Programming Options SAP Web AS Programming Option SAP Web AS Programming Option SAP ABAP+JAVA SAP Web AS JAVA Description • This system option consists of the ABAP only components. There is no J2EE JAVA Engine. • The ABAP engine requires its own database schema. Therefore a database instance installation is mandatory.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components About SAP Components The following terms are used to describe the components of an SAP system. NOTE Refer to the SAP Web Application Server in Switchover Environments manual for additional information. Go to http://service.sap.com for this and other SAP documentation.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components Table 2-3 SAP Component Terminology (Continued) Term JAVA CI Definition A JAVA Central instance provides server processes for the SAP Web AS JAVA and SAP Web AS JAVA Add-In variant. These processes include the JAVA dispatcher, JAVA server processes, and the Software Delivery Manager (SDM). It does not include the database processes.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components Table 2-3 SAP Component Terminology (Continued) Term JAVA CI Definition A JAVA Central instance provides server processes for the SAP Web AS JAVA and SAP Web AS JAVA Add-In variant. These processes include the JAVA dispatcher, JAVA server processes, and the Software Delivery Manager (SDM). It does not include the database processes.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components Table 2-3 SAP Component Terminology (Continued) Term AREP Definition ABAP Replicated Enqueue Server. In a high-availability environment the Enqueue Server component consists of the standalone Enqueue Server and an enqueue replication server. The Replicated Enqueue Server (AREP) runs on another host and contains a replica of the lock table (replication table).
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components Figure 2-1 Comparison between Traditional SAP Architecture and SAP WEB AS Architecture Traditional SAP Architecture SAP Web AS Architecture GUI Internet GUI GUI Enqueue Server Message Server Work Process Work Process Enqueue Server Enqueue Server Message Server JAVA Dispatcher Dispatcher Work Process Gateway To other instances of SAP systems Work Process Work Process Dispatcher Work Process
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About SAP Components NOTE With SAP NetWeaver 04 JAVA, the Message Server and the Enqueue Server are separated from the central instance. These two services are grouped within the SAP SCS (SAP Central Services) Instance as services. From NW04s the ABAP SCS can be also separated from the central instance. Each stack, ABAP and JAVA, has its own message Service and enqueue Service.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About Impacted File Systems About Impacted File Systems In an SAP environment, the storage, the file system layout and the mount points of the SAP system and the Database instance are key for configuring a Serviceguard cluster. The file systems are key because of the separation task of the file systems required: which file systems can be shared between cluster nodes and which file systems cannot.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About Impacted File Systems Figure 2-2 shows a two node cluster with LOCAL and SHARED mounted / connected storage.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About Impacted File Systems “LOCAL mount” or “SHARED mount” The first step for each of the file systems used in an SAP configuration is to classify if the mount point will be of type SHARED or of type LOCAL. The disadvantage of a LOCAL mount point is that any changes to the contents of these file systems will require a copy to all cluster nodes to keep the contents of the file systems synchronized.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About Impacted File Systems NOTE In prior SGeSAP/LX documentation this category (LOCAL) was called “Environment specific”. SHARED NFS or SHARED EXCLUSIVE SHARED NFS In this category file system data is shared among the SAP instances via NFS and is made available / exported to all cluster nodes. An example could be /sapmnt//profile directory which contains the profile for all SAP instances in the cluster.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment About Impacted File Systems SHARED EXCLUSIVE This type of storage mounts, relocates the storage volume together with the relocation of the application and the Serviceguard package from one cluster node to another cluster node. The file system is exclusively mounted on the node the application is running on. The file system is not mounted by any of the other cluster nodes or accessed by these.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios Configuration Scenarios In the following sections the file systems used for several different SAP configuration scenarios will be analyzed. Other combinations of scenarios are possible.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios DB Instance One of the following two databases could be used: MaxDB: /etc/opt/sdb /sapdb/C11 /sapdb/data /sapdb/programs /var/spool/sql Oracle: $ORACLE_HOME /oracle/client /oracle/oraInventory /oracle/stage /oracle/C11/saparch /oracle/C11/sapreorg /oracle/C11/sapdata1 ...
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios One ABAP CI, one ABAP DI and one DB This configuration scenario consists of one SAP Central Instance (= CI), one SAP Dialog Instance (=DI) and one Database instance (=DB). So one additional dialog instance (= D01) will be added when compared to the previous example. The CI again is identified by the following name “DVEBMGS00”, the dialog instance is identified by the name “D01” in the file system path.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios The file system layout in the case of a Oracle database: /$ORACLE_HOME /oracle/client /oracle/oraInventory /oracle/stage /oracle/C11/saparch /oracle/C11/sapreorg /oracle/C11/sapdata1 ...
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios Two ABAP DI’s and one ABAP SCS and one DB Using the terminology of the previous example, the next configuration scenario consists of one ABAP Central instance (= ABAP CI), one ABAP Dialog instance (ABAP DI), one ABAP SAP Central Services (ABAP SCS) and one Database instance (=DB). So compared to the previous example one instance (ABAP SCS) will be added. This instance is identified by the name “ASCS02”.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios Two ABAP DI’s, one ABAP SCS, one JAVA CI, one JAVA SCS, and one DB Compared with the previous scenario JAVA components will now be added. The JAVA SCS instance is identified by the name “SCS03”, the JAVA CI instance is identified by JC04. The JAVA CI naming convention remains since the SDM services are part of the JAVA CI as described above.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Configuration Scenarios Two ABAP DI’s, one ABAP SCS, one JAVA CI, one JAVA SCS, one JAVA REP, and one DB Compared to the previous example one JAVA enqueue replication server instance (= JAVA REP) will be added. The JAVA REP instance is identified by the name “REP03. For this instance one new file system is required: /usr/sap/C11/REP03.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Putting it all Together Putting it all Together Considering the above discussion the following file system layout was chosen: Table 2-4 SAP CI Instance Type Path /usr/sap/trans/ NFS /usr/sap/tmp/ LOCAL /usr/sap//DVEBMGS00/ EXCLUSIVE to this ABAP CI INSTANCE /usr/sap//SYS/ LOCAL /sapmnt// NFS /home/adm LOCAL Why SAP Provides sapcpe Technically the file system /usr/sap//SYS/exe/run could be
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Putting it all Together mechanism. With every startup of an SAP instance, sapcpe matches the latest executables that were stored centrally with those stored locally and copies all required updates. Figure 2-3 shows the file system layout with sapcpe.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Putting it all Together Table 2-5 Other SAP Instance Implementation Options as Listed in the Previous Sections: Path Description /usr/sap//D01/ EXCLUSIVE to this ABAP DI INSTANCE /usr/sap//ASCS02/ EXCLUSIVE to this ABAP ASCS INSTANCE /usr/sap//SCS03/ EXCLUSIVE to this JAVA SCS INSTANCE /usr/sap//JC04/ LOCAL to this JAVA CI INSTANCE Note: According to the SAP documentation, it is recommended to config
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment SHARED NFS: the NFS automounter SHARED NFS: the NFS automounter The option for SHARED NFS is to use the NFS automounter as described below. The automount scheme means that with the access to a automounter mount point the NFS file system will be mounted to the local file system tree for as long as it is needed. When there is no activity on that file system the automounter will automatically unmount the file system.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment SHARED NFS: the NFS automounter 3. The configuration of automounter is based on two files /etc/auto.master and a mount specific file /etc/auto.import (also called an automounter map file). An example of automounter map file in /etc/auto.master: /import /etc/auto.import nfsvers=3 And the automounter map file itself /etc/auto.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment SHARED NFS: the NFS automounter Summary of automount file systems The following is a summary of file systems that will be mounted with the automounter: For the SAP instance with SID: nfsvip:/export/sapmnt/ /import/ nfsvip:/export/usr/sap/trans /import/trans For the MaxDB / liveCache database: nfsvip:/export/var/spool/sql/in /import/in nfsvip:/export/sapdb/programs /import/programs nfsvip:/export/sapdb/data /import/dat
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment SHARED NFS: the NFS automounter Lastly, create symbolic links that point from the original SAP and original database directory names to NFS place holders in /import. ln -sf /import/ /sapmnt/ ln -sf /import/trans /usr/sap/trans ln -sf /import/ini /var/spool/sql/ini ln -sf /import/programs ln -sf /import/data /sapdb/programs /sapdb/data ln -sf /import/oracle/stage /oracle/stage NOTE Chapter 2 The 2.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Serviceguard packages Overview Serviceguard packages A package groups application services together. A Serviceguard package consists of the following: 1. Package name 2. Virtual IP address 3. Application processes that run one cluster node and “belong” to that package 4. Storage that “belongs” to the application that is started with this Serviceguard package. The typical high availability package is a failover package.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Serviceguard packages Table 2-6 Component Mapping of SAP components to Serviceguard Extension for SAP on Linux package types Description DB Database Instance for ABAP and JAVA components (db) ABAP CI ABAP Central Instance (ci) JAVA CI JAVA Central instance Note: not recommended by SAP for switchover.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Serviceguard packages The disadvantage is that any time one of the package components (db or ci) has to be stopped, the other package component also has to be stopped. SGeSAP/LX Implementations The following diagram gives an overview of a Serviceguard cluster and its packages.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Serviceguard packages • The package dbRIS is responsible for starting and stopping the database application for SAP instance RIS. • The package ciRIS is responsible for starting and stopping the SAP central instance for id RIS. • The package d01RIS is responsible for starting and stopping the SAP dialog instance D01 for id RIS.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Overview Serviceguard packages The combination of Serviceguard package name, virtual IP address, the EXCLUSIVE file system and the application to start and stop are considered to be an entity.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package Conclusion: Mount Points, Access Types and SGeSAP/LX Package The following gives a final overview of some mount points, the access type and the SGeSAP/LX package that will us the mount point.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package Table 2-8 Other SAP component mount points and SGeSAP/LX packages: Mount Point Access Type SGeSAP/LX Package /usr/sap//SCS jci /usr/sap//ASCS ci /usr/sap//REP /usr/sap//AREP EXCLUSIVE rep arep MaxDB mount points and SGeSAP/LX packages The considerations given below for MaxDB will also ap
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package the kernel processes are written into the working directory. These core files have file sizes of several Gigabytes. Sufficient free space needs to be configured for the shared logical volume to allow core dumps. NOTE For MaxDB starting with version 7.6 these limitations do not exist any more. The working directory is used by all instances and can be globally shared.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package NOTE In high availability scenarios, valid for MaxDB versions up to 7.6, the runtime directory /sapdb/data/wrk is configured to be located at /sapdb//wrk to support consolidated failover environments with several MaxDB instances.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package Oracle Database Instance Storage Considerations Oracle server directories reside below /oracle/. These directories get shared via the database package In addition, any SAP Application Server needs access to the Oracle client libraries, including the Oracle National Language Support files (NLS) shown in Table 2-7 NLS Files Default Location.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package Sometimes a single host may have an installation of both a Central Instance and an additional Application Server of the same SAP System. These instances need to share the same environment settings. SAP recommends using the server path to NLS files for both instances in this case.
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package Table 2-11 Oracle DB Instance Mount Point /oracle//saparch Access type SGeSAP/LX Package EXCLUSIVE db or dbci NFS sapNFS /oracle//sapreorg /oracle//sapdata1 /oracle//sapdatan /oracle//origlogA /oracle//origlogB /oracle//mirrlogA /oracle//mirrlogB /oracle/stage $ORACLE_HOME Chapter 2 77
Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment Conclusion: Mount Points, Access Types and SGeSAP/LX Package 78 Chapter 2
Step-by-Step Cluster Conversion 3 Step-by-Step Cluster Conversion This chapter describes in detail how to implement a SAP cluster using Serviceguard and Serviceguard Extension for SAP (Serviceguard Extension for SAP on Linux). It is written in the format of a step-by-step guide. It gives examples for each task in great detail. Actual implementations might require a slightly different approach. Many steps synchronize cluster host configurations or virtualized SAP instances manually.
Step-by-Step Cluster Conversion SGeSAP/LX Naming Conventions and Package Types SGeSAP/LX Naming Conventions and Package Types Various Serviceguard Extension for SAP on Linux package types are supported, including • SAP Central Instances and ABAP System Central Services (ci) • JAVA System Central Services (jci) • Database Instances for ABAP components (db) • Database Instances for J2EE components (db) • Replicated Enqueue ABAP System Central Services (arep) • Replicated Enqueue for the JAVA Syste
Step-by-Step Cluster Conversion SGeSAP/LX Naming Conventions and Package Types SGeSAP/LX Package Names In order to ensure a consistent naming scheme in the following installation and configuration steps, the Serviceguard Extension for SAP on Linux package names are assembled from the package type and SAP System ID: = or, in case of ambiguous results = Examples: dbC11, ciC11, dbciC11, dbcijciC11, dbC11, jciC11, dbjciC11, d01C11, d02C11, arepC11
Step-by-Step Cluster Conversion SGeSAP/LX Naming Conventions and Package Types Installation Tasks and Installation Steps The installation steps cover Suse SLES 9 and Redhat RHEL4 using Serviceguard 11.16 or higher. In any case, the installation is only valid for HP non-SSI (non-Single System Image) environments.
Step-by-Step Cluster Conversion SGeSAP/LX Naming Conventions and Package Types NOTE For installation steps in this chapter that require the adjustment of SAP specific parameter in order to run the SAP WAS system in a switchover environment example values are given. These values are for reference ONLY and it is recommended to read and follow the appropriate SAP OSS notes for SAP’s latest recommendation. Whenever possible the SAP OSS note number is given. Serviceguard Extension for SAP on Linux: cmcluster.
Step-by-Step Cluster Conversion SGeSAP/LX Naming Conventions and Package Types In principle all SAP cluster installations look very similar. Older SAP systems get installed in the same way as they would without a cluster. Cluster conversion takes place afterwards and includes a set of manual steps. Some of these steps can be omitted since the introduction of high availability installation options to the SAP installer SAPINST.
Step-by-Step Cluster Conversion SAP Preparation SAP Preparation This section covers the SAP specific preparation, installation and configuration before creating a high available SAP System landscape. This includes the following logical tasks: • SAP Installation Considerations • Replicated Enqueue Conversion SAP Installation Considerations This section gives additional information that help with the task of performing SAP installations in HP Serviceguard clusters.
Step-by-Step Cluster Conversion SAP Preparation NOTE For JAVA-only based installations the only possible installation option is a High Availability System installation.
Step-by-Step Cluster Conversion SAP Preparation NW04S400 Preparation Step: Create a Serviceguard package directory on each node of the cluster. This directory will be used by all packages that belong to the SAP System with a specific SAP System ID . mkdir -p /${SGCONF}/ NW04S420 Preparation Step: Create standard Serviceguard package configuration and control files for each package.
Step-by-Step Cluster Conversion SAP Preparation Specify NODE_NAME entries for all hosts on which the package should be able to run. Specify the created control scripts that were created earlier on as run and halt scripts: RUN_SCRIPT $SGCONF//.control.script HALT_SCRIPT $SGCONF//.control.script Specify subnets to be monitored in the SUBNET section. In the ${SGCONF}//.control.script file(s), there is a section that defines a virtual IP address array.
Step-by-Step Cluster Conversion SAP Preparation NW04S445 Preparation Step: The package configuration needs to be applied and the package started. This step assumes that the cluster as such is already configured and started. Please refer to the Managing Serviceguard user’s guide if more details are required. cmapplyconf -P ${SGCONF}/C11/dbcijciC11.config cmrunpkg -n dbcijciC11 All virtual IP address(es) should now be configured.
Step-by-Step Cluster Conversion SAP Preparation SAP Netweaver 2004s High Availability System Installer NW04S1330 Installation Step: The installation is done using the virtual IP provided by the Serviceguard package. SAPINST can be invoked with a special parameter called SAPINST_USE_HOSTNAME. This prevents the installer routines from comparing the physical hostname with the virtual address and drawing wrong conclusions. The installation of the entire SAP WAS 7.
Step-by-Step Cluster Conversion SAP Preparation The SAPINST_USE_HOSTNAME option can be set as an environment variable, using export or setenv commands. It can also be passed to SAPINST as an argument. cd /IM_OS/SAPINST/UNIX//sapinst \ SAPINST_USE_HOSTNAME= (A)SCS installation: The SAP installer should now start. Follow the instructions of the (A)SCS installation process and provide the details when asked by SAPINST.
Step-by-Step Cluster Conversion SAP Preparation The instances are now able to run on the installation host, once the corresponding Serviceguard packages have been started. It is not yet possible to move instances to other nodes, monitor the instances or trigger automated failovers. Don’t shut down the Serviceguard packages while the instances are running. Netweaver 2004 JAVA-only High Availability Option This section describes the installation of a JAVA-only based Web Application Server 6.
Step-by-Step Cluster Conversion SAP Preparation Netweaver 2004 JAVA-only High Availability Option This section describes the installation of a JAVA-only based Web Application Server 6.40 as provided as part of Netweaver 2004SR1. A SAP application relying on a JAVA-only Web Application Server 6.40 is SAP Enterprise Portal 6.0. This component debuts the virtualized installation with SAPINST that is generally used for Netweaver 2004s, but this early procedure differs in many details from the final process.
Step-by-Step Cluster Conversion SAP Preparation NW04J420 Preparation Step: Create standard package configuration and control files for each package. The SAP JAVA instances are mapped to Serviceguard Extension for SAP on Linux package types as follows: The SCS Instance requires a (jci) package type. The database requires a (db) package type. The package files are recommended to be named .control.script for a control file and .config for a configuration file.
Step-by-Step Cluster Conversion SAP Preparation In the ${SGCONF}//.control.script file(s), there is a section that defines a virtual IP address array. All virtual IP addresses specified here will become associated with the SAP instances that are going to be installed. Edit the array and create at least one virtual IP: IP[0]=xxx.xxx.xxx.xxx Distribute the edited package templates to all cluster nodes.
Step-by-Step Cluster Conversion SAP Preparation NW04J1310 Preparation Step: The SAP J2EE engine needs a supported and tested JAVA SDK on all cluster nodes. Check the installed JAVA SDK with the requirement as of the NW04 Master Guide Part 1. Be sure to install the required SDK on all nodes in the cluster. In case the J2EE engine uses security features that utilize the need for the JAVA Cryptographic Toolkit, it has to be downloaded both from the Sun website as well as from the SAP Service Marketplace.
Step-by-Step Cluster Conversion SAP Preparation NW04J1330 Installation Step: The installation is done using the virtual IP provided in the Serviceguard package. The SAPINST installer is invoked with the parameter SAPINST_USE_HOSTNAME to enable the installation on a virtual IP address of Serviceguard. This parameter is not mentioned in SAP installation documents, but it is officially supported. The installer will show a warning message that has to be confirmed.
Step-by-Step Cluster Conversion SAP Preparation It is recommended to pass the catalog as an argument to SAPINST. The XML file that is meant to be used with Serviceguard Extension for SAP on Linux clusters is included on the installation DVD/CD’s distributed by SAP. SAPINST 6.40 installation options with HA catalog file The SAPINST_USE_HOSTNAME option can be set as an environment variable, using export or setenv commands. It can also be passed to SAPINST as an argument.
Step-by-Step Cluster Conversion SAP Preparation ASCS installation Follow the instructions of the ASCS installation process and provide the required details when asked by SAPINST. Provide the virtual hostname to any ASCS instance related query. cd /IM_OS/SAPINST/UNIX//sapinst \ SAPINST_USE_HOSTNAME= The SAP installer should now start.
Step-by-Step Cluster Conversion SAP Preparation /IM_OS/SAPINST/UNIX/SAPINST \ /IM_OS/SAPINST/UNIX/\ product_ha.catalog The SAP installer should now start. Follow the instructions of the JAVA Central Instance installation process. JAVA dialog instances get installed in the same fashion. Afterwards, the virtualized installation for SAP J2EE Engine 6.40 should have completed, but the cluster still needs to be configured.
Step-by-Step Cluster Conversion SAP Preparation Replicated Enqueue Conversion This section describes how a SAP ABAP Central Instance DVEBMGS can be converted to use the Enqueue Replication feature for seamless failover of the Enqueue Service. The whole section can be skipped if Enqueue Replication is not going to be used for the ABAP stack. It can also be skipped in case Replicated Enqueue is already installed.
Step-by-Step Cluster Conversion SAP Preparation Splitting a Central Instance The SPOFs (Single Point of Failure) of the DVEBMGS instance will be isolated in a new instance called ABAP System Central Services Instance ASCS. This instance will replace DVEBMGS for the (ci) package type. The remaining parts of the Central Instance can then be configured as Dialog Instance D.
Step-by-Step Cluster Conversion SAP Preparation RE030 Replicated Enqueue Conversion: Create instance subdirectories in the mounted logical volume. They will be switched between the cluster nodes later. su - adm cd /usr/sap//ASCS mkdir data log sec work RE040 Replicated Enqueue Conversion: If the used SAP kernel has a release smaller than 6.40: Download the executables for the Standalone Enqueue server from the SAP Service Marketplace and copy them to /sapmnt//exe.
Step-by-Step Cluster Conversion SAP Preparation #---------------------------------# enqueueserver settings #---------------------------------enque/server/internal_replication = true enque/server/replication = true enque/server/threadcount = 1 enque/enrep/keepalive_count = 0 enque/process_location = local enque/table_size = 4096 ipc/shm_psize_34 = 0 #---------------------------------# messageserver settings #---------------------------------rdisp/mshost= #---------------------------------# prevent s
Step-by-Step Cluster Conversion SAP Preparation Here is an example template for the startup profile START_ASCS_ #----------------------------------------------------------------------SAPSYSTEMNAME = INSTANCE_NAME =ASCS ----------------------------------------------------------------------# start SCSA handling #----------------------------------------------------------------------Execute_00 =local $(DIR_EXECUTABLE)/sapmscsa -n\ pf=$(DIR_PROFILE)/_ASCS_ #---
Step-by-Step Cluster Conversion SAP Preparation Start_Program_03 = local $(_EN) pf=$(DIR_PROFILE)/_ASCS_ #----------------------------------------------------------------------# start syslog send daemon #----------------------------------------------------------------------SE =se.
Step-by-Step Cluster Conversion SAP Preparation The exact changes depend on the individual appearance of the file for each installation. The startup profile is also individual, but usually can be created similar to the default startup profile of any Dialog Instance.
Step-by-Step Cluster Conversion SAP Preparation Creation of Replication Instance The ASCS (ABAP) or SCS (JAVA) instance will be accompanied with an [A]REP (ABAP or JAVA) instance that permanently keeps a mirror of the ASCS internal state and memory. As a result, no information gets lost due to the fact of failing SAP System Central Services, if the Serviceguard Extension for SAP on Linux package that includes [A]SCS fails over to the node that runs [A]REP during runtime.
Step-by-Step Cluster Conversion SAP Preparation #---------------------------------# general settings #---------------------------------SAPSYSTEMNAME = SAPLOCALHOST = <[A]REPRELOC> SAPLOCALHOSTFULL = <[A]REPRELOC>.
Step-by-Step Cluster Conversion Linux Configuration Linux Configuration The valid Linux kernel to deploy to the servers needs to be certified with the SAP LinuxLab and at the same time needs to be supported with HP Serviceguard Extension for SAP on Linux. The SAP LinuxLab publishes kernels to deploy on its FTP server. The latest kernel to deploy can be obtained from SAP. Instructions from where to download these kernels can be found on http://www.sap.com/linux/.
Step-by-Step Cluster Conversion Linux Configuration A correct Linux configuration ensures that all cluster nodes provide the environment and system configuration required to run SAP. Several of the following steps must be repeated on each node. Record the steps completed for each node, as you complete them. This helps identify errors in the event of a malfunction later in the integration process.
Step-by-Step Cluster Conversion Linux Configuration NOTE Repeat the above steps for each host that has an external application server installed. Performing some of the iterations in parallel is fine, just use caution in any complex setup situation. Directory Structure Configuration NOTE The steps in this section are only performed once on the primary host.
Step-by-Step Cluster Conversion Linux Configuration IS010 Installation Step: Make sure that the volume group layout is compliant with the needs of the Serviceguard package(s) as specified in the tables of Section "Planning a File System Layout for SAP in a Serviceguard/LX Cluster Environment.” All directories that are labeled shared in these tables need to reside on logical volumes on a shared external storage system.
Step-by-Step Cluster Conversion Linux Configuration MD040 MaxDB Database Step: NOTE This step can be skipped for MaxDB instances starting with versions 7.6 and higher. Make sure you have mounted a sharable logical volume on /sapdb//wrk as discussed in section MaxDB Storage Considerations in Chapter 2. Change the path of the runtime directory of the MaxDB and move the files to the new logical volume accordingly. cd /sapdb/data/wrk/ find . -depth -print | cpio -pd /sapdb//wrk cd ..
Step-by-Step Cluster Conversion Linux Configuration To automatically synchronize local copies of the executables, SAP components deliver the sapcpe mechanism. With every startup of the instance, sapcpe matches new executables stored centrally with those stored locally. Figure 3-1 shows a SAP file system layout with sapcpe activated for two Application Servers.
Step-by-Step Cluster Conversion Linux Configuration of saposcol. To complete the process, a plain text configuration file is needed that tells sapcpe which files need to be included in the copying process. A file of this type is usually called sapcpeft. If sapcpeft exists, sapcpe will automatically be executed as the first step of the next instance restart. It needs to be created in the central executable directory.
Step-by-Step Cluster Conversion Linux Configuration Cluster Node Synchronization NOTE Repeat the steps in this section for each node of the cluster that is different than the primary host. Logon as root to the system where the SAP Central Instance is installed (primary host) and prepare a logon for each of its backup hosts – if not already available. IS070 Installation Step: Open the groupfile file, /etc/group, on the primary side.
Step-by-Step Cluster Conversion Linux Configuration IS090 Installation Step: Look at the service file, /etc/services, on the primary side. Replicate all SAP services listed here (sapdp, sapdbs, sapms, sapgw, sapgws, orasrv, tlissrv sql16...) on the Primary Node that exist on the primary node onto the backup node. IS100 Installation Step: Change the Linux kernel on the backup node to meet the SAP requirements. The entries on the primary node may act as a reference.
Step-by-Step Cluster Conversion Linux Configuration mv .dbsrc_.sh .dbsrc_.sh The following statement should automate this activity for standard directory contents. Do not use a line break within the awk statement: su - adm ls -a|awk '// { system( sprintf( "mv %s %s\n", $0,\ gensub("", "", 1 ))) }' exit Never use the relocatable address in these filenames.
Step-by-Step Cluster Conversion Linux Configuration OR150 Oracle Database Step: If the primary node has the ORACLE database installed: Create additional links in /oracle/ on the primary node. For example: su - ora ln .dbenv_.csh .dbenv_.csh ln .dbenv_.sh .dbenv_.sh exit NOTE If you are implementing an Application Server package make sure that you install the Oracle Client libraries locally on all nodes you run the package on.
Step-by-Step Cluster Conversion Linux Configuration IS191 Installation Step: If the primary node has the Central Instance installed and the backup node has no internal application server with local executables installed, for example on the primary node: cd /usr/sap//SYS find . -depth -print | cpio >/tmp/SYS.cpio Use ftp(1) to copy the file over to the secondary node. On the secondary node: su - adm mkdir -p /usr/sap//SYS cd /usr/sap//SYS cpio -id
Step-by-Step Cluster Conversion Linux Configuration IS220 Installation Step: Create a local mount point for each file system that was specified in chapter “Planning the Storage Layout to have shared disk” to have a “NFS” access point. Refer to the tables in chapter 2 for LOCAL, SHARED or NFS mountpoints and the corresponding tables that represent entries for the required database type. Depending on the past usage of the hosts, some of the directories might already exist.
Step-by-Step Cluster Conversion Linux Configuration MD236 MaxDB Database Step: For releases starting with MaxDB 7.
Step-by-Step Cluster Conversion Linux Configuration Cluster Node Configuration NOTE Repeat the steps in this section for each node of the cluster. IS241 Installation Step: Logon as root. Serviceguard Extension for SAP on Linux needs remote login to be enabled on all cluster hosts. The traditional way to achieve this is via remote shell commands. If security concerns prohibit this, it is also possible to use secure shell access instead.
Step-by-Step Cluster Conversion Linux Configuration The file id_dsa.pub contains the security information (public key) for the user@host pair e.g. root@. This information needs to be added to the file $HOME/.ssh/authorized_keys2 of the root and adm user. Create these files if they are not already there. This will allow the root user on to remotely execute commands via ssh under his own identity and under the identity of adm on all other relevant nodes.
Step-by-Step Cluster Conversion Linux Configuration rpm -Uhv \ nfs-toolkit-.product...rpm rpm -Uhv \ sgesap-toolkit-.product...rpm rpm -Uhv sgcmon-.product...rpm rpm -Uhv pidentd-.product...rpm IS280 Installation Step: Create all central instance directories below /export as specified in Chapter 2.
Step-by-Step Cluster Conversion Linux Configuration IS320 Installation Step: If you need to establish frontend and server LANs to separate network traffic, be sure to add static routing entries to the internet routing configurations of /etc/sysconfig/network/routing file. Route all relocatable client LAN addresses to the local server LAN addresses. For example, a two package concept would result in two entries: 255.255.255.255 255.255.255.
Step-by-Step Cluster Conversion Linux Configuration if [ -e /proc/lvm –a –x /sbin/vgchange –a –f /etc/lvmtab ]; then action $”Setting up LVM:” /sbin/vgscan && /sbin/vgchange \ –a –y fi IS392 Installation Step: Check chapter 2 for more automounter details. In this environment the automounter (autofs) version 4 is required for mounting NFS file systems. Check the installed version with: lsmod | grep autofs autofs4 60040 1 If “autofs4” is not listed, install the corresponding rpm.
Step-by-Step Cluster Conversion Linux Configuration IS394 Installation Step: Edit the automounter file/etc/auto.import, the indirect automounter map file. In this file, all NFS client mounted directories will now be configured to be accessed / mounted via the /import directory. This action consists of several steps that belong together. The idea behind the action to be performed here is that each path below /export should be automounted into a placeholder directory that is below /import.
Step-by-Step Cluster Conversion Linux Configuration cd /import mkdir trans mkdir mkdir programs mkdir data mkdir ini Be sure to change the ownership of the directories according to your needs. Normally all SAP directories belong to :sapsys, while database specific file systems belong to the database user, e.g. ora:dba or sqd:sapsys. 3.
Step-by-Step Cluster Conversion Linux Configuration It is important that the nosymlink option is specified. The nosymlink option does not create symbolic links to local directories if the NFS server file system is local. Instead it always mounts from the virtual IP address . Therefore a cluster node can be an NFS server and client at the same time and the NFS server file systems can be dynamically relocated to the other cluster nodes. 5.
Step-by-Step Cluster Conversion Cluster Configuration Cluster Configuration This section describes the cluster software configuration with the following topics: • Serviceguard Configuration • Serviceguard NFS Toolkit Configuration • Serviceguard Extension for SAP on Linux Configuration Configuring SGeSAP/LX on Linux The following sections contain information on configuring SGeSAP/LX (Serviceguard Extension for SAP). It is assumed that a basic Serviceguard cluster is up and running.
Step-by-Step Cluster Conversion Cluster Configuration export SGCONF export SGROOT export SAPSTAGE Variables ${SGCONF} and ${SGROOT} can also be set with the following command: . /etc/cmcluster.conf IS400 Installation Step: Logon as root on the primary host. Create a SGeSAP/LX package directory. This directory will be used by all packages that belong to the SAP System with a specific SAP System ID .
Step-by-Step Cluster Conversion Cluster Configuration cmmakepkg -p db.config cmmakepkg -s db.control.script cmmakepkg -p ci.config cmmakepkg -s ci.control.script cmmakepkg -p d01.config cmmakepkg -s d01.control.script NOTE The above creates a default Serviceguard package. which in the first step is not related to any of the SGeSAP/LX components yet.
Step-by-Step Cluster Conversion Cluster Configuration OS430 Optional Step: Specify NODE_NAME entries for all hosts on which the package should be able to run. If the package can run on any of the cluster nodes a “*” can be entered: NODE_NAME * In the Serviceguard configuration file (xxx.config) specify the script that gets executed when running or halting the Serviceguard package. The script that get executed will be the Serviceguard control script (xxx.control.script). db.
Step-by-Step Cluster Conversion Cluster Configuration OS440 Optional Step: Serviceguard also allows the monitoring of resources and processes that belong to a Serviceguard package. The terminology used to describe this capability is called a “Serviceguard monitoring service”. The “Serviceguard monitoring service” name is defined in the Serviceguard configuration file (xxx.config) and the script to execute for monitoring a resource is specified in the Serviceguard control script (xxx.control.script).
Step-by-Step Cluster Conversion Cluster Configuration NOTE The manual startup using common startsap/stopsap scripts may not work correctly with Netweaver 2004s based Web Application Servers. In this case the instances need to started by directly using the sapstart binary passing the start profile as a parameter.
Step-by-Step Cluster Conversion Cluster Configuration Serviceguard Control Script Template - xxx.control.script IS470 Installation Step: The script that get executed for “running” or “halting” a Serviceguard package is the Serviceguard control script (xxx.control.script). It is located in directory ${SGCONF}/. In xxx.control.script the volume groups, logical volumes, the virtual IP addresses and subnets and last not least the SGeSAP/LX scripts to run and halt SAP instances are added.
Step-by-Step Cluster Conversion Cluster Configuration # definitions below are included in volume group definitions. # Specify the filesystems which are used by this package. Uncomment # LV[0]=""; FS[0]=""; FS_TYPE[0]=""; FS_MOUNT_OPT[0]=""; # FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]="" and fill in # the name of your first logical volume, filesystem, type, mount, # umount and fsck options for the file system. # # Valid types for FS_TYPE are 'ext2' and 'reiserfs'.
Step-by-Step Cluster Conversion Cluster Configuration SERVICE_NAME[0]=”ciC11ms” SERVICE_CMD[0]=”${SGCONF}/C11/sapms.mon SERVICE_RESTART[0]=”” # START OF CUSTOMER DEFINED FUNCTIONS # This function is a place holder for customer define functions. # You should define all actions you want to happen here, before the service # is started. You can create as many functions as you need. # function customer_defined_run_cmds { . /usr/local/cmcluster/conf/C11/sapwas.
Step-by-Step Cluster Conversion Cluster Configuration FS_TYPE[0]="reiserfs"; \ FS_MOUNT_OPT[0]="-o rw"; \ FS_UMOUNT_OPT[0]=""; \ FS_FSCK_OPT[0]="" # IP ADDRESSES IP[0]="16.41.101.163" SUBNET[0]="16.41.101.0" # START OF CUSTOMER DEFINED FUNCTIONS function customer_defined_run_cmds { . /usr/local/cmcluster/conf/LXM/sapwas.sh start LXM test_return 51 } function customer_defined_halt_cmds { . /usr/local/cmcluster/conf/LXM/sapwas.
Step-by-Step Cluster Conversion Cluster Configuration test_return 52 } # END OF CUSTOMER DEFINED FUNCTIONS IS500 Installation Step: Distribute the Serviceguard package ascii files to all cluster nodes. Copy all Serviceguard configuration files in directory ${SGCONF}/ from this node into the same directory on all other cluster nodes. Also copy file ${SGCONF}/sap.functions from this host into the same directory on all cluster nodes.
Step-by-Step Cluster Conversion Cluster Configuration For testing it can help to create a file called ${SGCONF}//debug on all nodes in the cluster. This enables you to start the Serviceguard packages without running the Serviceguard Extension for SAP on Linux specific steps of starting or stopping an SAP instance. Do not forget to remove all debug files after the tests.
Step-by-Step Cluster Conversion Cluster Configuration A MaxDB example would also have the following entries added: XFS[2]=”-o rw *:/export/sapdb/programs” XFS[3]=”-o rw *:/export/sapdb/data” XFS[4]=”-o rw *:/export/var/spool/sql/ini IS550 Installation Step: A Serviceguard NFS monitor can be configured in section NFS MONITOR in hanfssh. The naming convention for the service should be sapnfs. An example: NFS_SERVICE_NAME[0]=”sapnfs” NFS_SERVICE_CMD[0]=”${SGCONF}/SAPNFS/nfs.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Serviceguard Extension for SAP on Linux Configuration – sap.config This section deals with the configuration of the SAP specifics of the Serviceguard packages SGeSAP/LX SAP specific configuration file called ${SGCONF}//sap.config.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Specification of the Packaged SAP Components For each type of potentially mission-critical SAP software components there exists a set of configuration parameters in SECTION 1 of the ${SGCONF}//sap.config file. The information delivered here will be specified exactly once and it will configure all packaged components of a within the cluster.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config IS600 Installation Step: Specify the relocatable IP address where the Serviceguard NFS shared file systems can be reached. Format is IPv4: nnn.nnn.nnn.nnn. This value specifies the default for commonly shared file systems.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config OS620 Subsection for the CI component: Provide information about the Central Instance if it will part of Serviceguard Extension for SAP on Linux package. Set the parameter CINAME to the SAP instance name where ABAP Enqueue and Message Service are located. This usually is the Central Instance or the ABAP System Central Service. The name is either DVEBMGS or ASCS.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config OS640 Subsection for the D component: A set of SAP ABAP Application Servers and ABAP Dialog Instance can be configured in each Serviceguard package. Set the relocatible IP address of the dialog instance in DRELOC, the dialog instance name in DNAME and the instance ID number in DNR. For example: DRELOC[0]=0.0.0.0 DNAME[0]=D DNR[0]=53 DRELOC[1]=0.0.0.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config OS665 Subsection for the REP component: Serviceguard Extension for SAP on Linux supports SAP stand-alone Enqueue Service with Enqueue Replication. It’s important to distinguish between the two components: the stand-alone Enqueue Service and the replication. The stand-alone Enqueue Service is part of the (ci)or (jci) component.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Configuration of Application Server Handling In more complicated setups, in directory ${SGCONF}/ there can be several XXX.config files for each package. For example a Dialog Instance package can have its own sap.config configured to start additional non-critical Dialog Instances, whereas this setting should not be effective for a Central Instance package with the same SID.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config considered to be non-critical. In certain setups, it is necessary to free up resources on the failover node to allow the failover to succeed. Often, this includes stopping less important SAP Systems, namely consolidation or development environments. If any of these instances is a Central Instance, it might be that there are additional Application Servers belonging to it.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config — ${STOP_WITH_PKG}: Add 2 to ASTREAT[*] if the Application Server should automatically be stopped during halt of the package. — ${RESTART_DURING_FAILOVER}: Add 4 to ASTREAT[*] if the Application Server should automatically be restarted if a failover of the package occurs. If the restart option is not used the SAP ABAP Engine has to be configure to use DB-RECONNECT.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config ${START_WITH_PACKAGE}, ${STOP_WITH_PACKAGE} and {RESTART_DURING_FAILOVER} only make sense if ASSID[]=${SAPSYSTEMNAME}, i.e. these instances need to belong to the clustered SAP component. ${STOP_IF_LOCAL_AFTER_FAILOVER} and {STOP_DEPENDENT_INSTANCES} can also be configured for different SAP components. The following table gives an overview of ASTREAT[*] values and their combination.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Example 2: The failover node is running a Central Consolidation System QAS. It shall be stopped in case of a failover to this node. ASSID[0]=QAS; ASHOST[0]=node2; ASNAME[0]=DVEBMGS; ASNR[0]=10; ASTREAT[0]=8; ASPLATFORM[0]="HP-UX" The failover node is running the Central Instance of Consolidation System QAS.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config IS680 Installation Step: The REM_COMM value defines the method to be used to remotely execute commands for Application Server handling. It can be set to ssh to provide secure encrypted communications between untrusted hosts over an insecure network. Information on how to set up ssh for each node refer to Section Cluster Node Configuration. Default value is remsh.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config can significantly speed up the package start and stop, especially if Windows NT application servers are used. Use this value only if you have carefully tested and verified that timing issues will not occur. OS710 Optional Step: Specify SAPOSCOL_STOP=1 if saposcol should be stopped together with each instance that is stopped.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config • NOTE strict - uses Linux commands to free up all semaphores and shared memory segments that belong to any SAP Instance of any SAP system on the host if the Instance is to be started soon. It uses Linux to free up all semaphores and shared memory segments that belong to any database if the SAP database is to be started soon. Do not use the strict policy unless it is critical that you do.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Optional Parameters and Customizable Functions In ${SGCONF}/ there is a file called customer.functions that provides a couple of predefined function hooks. They allow the specification of individual startup or runtime steps at certain phases of the package script execution. Therefore it is not necessary and also not allowed to change the sap.functions.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Table 3-2 Optional Parameters and Customizable Functions List (Continued) Command: Description: stop_addons_predb relates to start_addons_postdb stop_addons_postdb relates to start_addons_predb The customer.functions template that is delivered with Serviceguard Extension for SAP on Linux provides several examples within the hook functions.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config OS750 Optional Step: Specify RFCADAPTER_START=1 to automatically start the RFC adapter component, e.g. for some early Exchange Infrastructure versions. Make sure that the JVM executables can be reached via the path of SIDADM. Example: RFCADAPTER_START=1 RFCADAPTER_CMD="run_adapter.sh" OS760 Optional Step: Specify SAPCCMSR_START=1 if there should be a CCMS agent started on the DB host automatically.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config Global Defaults The fourth section of sap.config is rarely needed. It mainly provides various variables that allow overriding commonly used default parameters. OS770 Optional Step: If there is a special demand to use values different from the default, it is possible to redefine some global parameters.
Step-by-Step Cluster Conversion Serviceguard Extension for SAP on Linux Configuration – sap.config # ps –ef | grep sapstartsrv # kill {PID of sapstartsrv } To make use of the sapstartservice configure the SAPSTARTSRV_START and SAPSTARTSRV_STOP values. The sapstartsrv daemon is started and stopped accordingly. For example: SAPSTARTSRV_START=1 SAPSTARTSRV_STOP=1 OS785 Optional Step for sap.config: Variables JMSSERV_BASE and MSSERV_BASE can be used to set the base Message Server port.
Step-by-Step Cluster Conversion Database Configuration Database Configuration This section deals with additional database specific installation steps and contains the following: • Additional Steps for Oracle • Additional Steps for MaxDB Additional Steps for Oracle The Oracle RDBMS includes a two-phase instance and crash recovery mechanism that enables a faster and predictable recovery time after a crash.
Step-by-Step Cluster Conversion Database Configuration All these parameters can be used to tune the duration of Instance / Crash recovery. More details on these useful High-Availability features can be found both in the Oracle8i and Oracle9i documentation Oracle8i Designing and Tuning for Performance (Chapter 24: Tuning Instance recovery Performance) and Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2).
Step-by-Step Cluster Conversion Database Configuration echo "startup mount;" >> $SRVMGRDBA_CMD_FILE echo "spool endbackup.log" >> $SRVMGRDBA_CMD_FILE echo "select 'alter database datafile '''||f.name||''' end backup;'" >> $SRVMGRDBA_CMD_FILE echo "from v\$datafile f, v\$backup b" >> $SRVMGRDBA_CMD_FILE echo "where b.file# = f.file# and b.status = 'ACTIVE'" >> $SRVMGRDBA_CMD_FILE echo "/" >> $SRVMGRDBA_CMD_FILE echo "spool off" >> $SRVMGRDBA_CMD_FILE echo "!grep '^alter' endbackup.log >endbackup.
Step-by-Step Cluster Conversion Database Configuration OR870 Oracle Database Step: Copy $ORACLE_HOME/network/admin/tnsnames.ora to all additional application server hosts. Be careful if these files were customized after the SAP installation. OR880 Oracle Database Step: Be sure to configure and install the required Oracle NLS files and client libraries as mentioned in section Oracle Storage Considerations included in chapter Planning the Storage Layout. Also refer to SAP OSS Note 180430 for more details.
Step-by-Step Cluster Conversion Database Configuration The file consists of two identical parts Table 3-3 Working with the two parts of the file Part of the file: first part Instruction: Replace each occurrence of the word LISTENER by a new listener name. You can choose what suits your needs, but it is recommended to use the syntax LISTENER: ( host = ) Change nothing. second part Replace each occurrence of the word LISTENER by a new listener name different from the one chosen above.
Step-by-Step Cluster Conversion Database Configuration Create a /etc/services entry for the new port you specified above. Use tlisrv as service name. The name is not needed anyhow. This entry has to be made on all hosts that run an instance that belongs to the system. This includes all external application server hosts outside of the cluster. OR900 Optional Step: If you use multiple packages for the database and SAP components: Set the optional parameter SQLNET.EXPIRE_TIME in sqlnet.
Step-by-Step Cluster Conversion Database Configuration OR920 Oracle Step: Additional steps for Application server and Oracle 8.1.x RDBMS: If you run an Oracle DB >= 8.1.x and install additional SAP Application Server follow the procedure described in OSS303238 to install the ORACLE client libraries. If you configure multiple Application servers to be started with the parallel startup option in sap.
Step-by-Step Cluster Conversion Database Configuration or symbolic links. For example create symbolic links to these libraries in the central executable directory /sapmnt//exe is a possible solution. OR941 Oracle Step: Additional steps for Oracle 10g RDBMS: Even though no cluster services are needed when installing a Oracle 10g Single Instance, the cluster services daemon ($ORACLE_HOME/bin/ocssd.bin) is installed. It will remain running, even when the database is shut down.
Step-by-Step Cluster Conversion Database Configuration Additional Steps for MaxDB Logon as root to the primary host of the database where the (db) or (dbci) package is running in debug mode. MD930 MaxDB Database Step: Create additional links in /sapdb/ on the primary node. For example: su - sqd ln -s .dbenv_.csh .dbenv_.csh ln -s .dbenv_.sh .dbenv_.
Step-by-Step Cluster Conversion Database Configuration For all previously listed user keys run the following command as adm Administrator: # dbmcli -U quit exits the upcoming prompt: # dbmcli on : > quit should be relocatable. If it is not, the XUSER mapping has to be recreated.
Step-by-Step Cluster Conversion SAP WAS System Configuration SAP WAS System Configuration This section describes some required configuration steps that are necessary for SAP to become compatible to a cluster environment. NOTE The following configuration steps do not need to be performed if the SAP System was installed using virtual IPs. The steps are only required to make a non-clustered installation usable for clustering.
Step-by-Step Cluster Conversion SAP WAS System Configuration If you don’t have Replicated Enqueue: rdisp/enqname = __ The following parameters are only necessary if an application server is installed on the adoptive node.
Step-by-Step Cluster Conversion SAP WAS System Configuration The instance profile name is often extended by the hostname. You do not need to change this filename to include the relocatible hostname. Serviceguard Extension for SAP on Linux also supports the full instance virtualization of SAPWAS 6.40 and beyond. The startsap mechanism can then be called by specifying the instance’s virtual IP address.
Step-by-Step Cluster Conversion SAP WAS System Configuration IS1150 Installation Step: Connect with a SAPGUI. Import the changed SAP profiles within SAP. The transaction is called RZ10. After importing the profiles, check with rsparam in SE38 if the parameters SAPLOCALHOST and SAPLOCALHOSTFULL are correct. If you do not import the profiles, the profiles within SAP can be edited by the SAP Administrator.
Step-by-Step Cluster Conversion SAP WAS System Configuration IS1180 Installation Step: Within the SAP Computing Center Management System (CCMS) you can define operation modes for SAP instances. An operation mode defines a resource configuration for the instances in your SAP system. It can be used to determine which instances are started and stopped, and how the individual services are allocated for each instance in the configuration.
Step-by-Step Cluster Conversion SAP WAS System Configuration This mechanism is different from SAPLOCALHOST and SAPLOCALHOSTFULL since ICM allows HTTP Server Aliasing via icm/server_port_ settings. During startup, icman reads its configuration and propagates it to the SAP Message Server or the SAP Web Dispatcher Server. These servers then act as the physical point of access for HTTP requests.
Step-by-Step Cluster Conversion SAP WAS System Configuration SAP J2EE Engine specific installation steps This section is applicable for SAP J2EE Engine 6.40 based installations that were performed prior to the introduction of SAPINST installations on virtual IPs. There is a special SAP OSS Note 757692 that explains how to treat a hostname change and thus the virtualization of a SAP J2EE Engine 6.40.
Step-by-Step Cluster Conversion SAP WAS System Configuration Table 3-4 IS1130 Installation Step Choose... Change the following values cluster_data -> dispatcher -> cfg -> kernel -> Propertysheet LockingManager enqu.host = cluster_data -> dispatcher -> cfg -> kernel -> Propertysheet ClusterManager ms.host = cluster_data -> server -> cfg -> kernel -> Propertysheet LockingManager enqu.host = cluster_data -> server -> cfg -> kernel -> Propertysheet ClusterManager ms.
SAP Supply Chain Management 4 SAP Supply Chain Management Within SAP Supply Chain Management (SCM) scenarios two main technical components have to be distinguished: the APO System and the liveCache The first technical component, the APO System is based on SAP WAS technology. Therefore, (ci), (db), (dbci), (d) and (sapnfs) packages may be implemented for APO. These APO packages are set up the same way as the Netweaver packages.
SAP Supply Chain Management The tasks are presented as a sequence of steps. Each mandatory installation step is accompanied by a unique number of the format XXnnn, where nnn are incrementing values and XX indicates the step relationship, as follows: • LCnnn—LP Package Installation Steps • GSnnn—General Installation Steps Whenever appropriate, Linux sample commands are given to guide through the installation process in as detailed a manner as possible.
SAP Supply Chain Management Planning the Volume Manager Setup Planning the Volume Manager Setup In the following, the liveCache (lc) package of Serviceguard Extension for SAP on Linux gets described. The (lc) package was developed according to the SAP recommendations and fulfills all SAP requirements for liveCache failover solutions. liveCache distinguishes an instance dependant path (/sapdb/) and two instance independent paths IndepData (/sapdb/data) and IndepPrograms (sapdb/programs).
SAP Supply Chain Management Planning the Volume Manager Setup Table 4-1 File System Layout for liveCache Package running separate from APO (Option 1) Storage Type Package Mount Point Shared Exclusive lc /sapdb Shared Exclusive lc /sapdb/ / datan Shared Exclusive lc /sapdb/ / logn Shared Exclusive lc /var/ spool/sql lc /sapdb/ programs Shared Exclusive 1 Local Volume group Logical Volume Device Number /etc/opt/sdb This denotes the pac
SAP Supply Chain Management Planning the Volume Manager Setup LVM Option 2: Full Flexibility - No Constraints If multiple MaxDB based database components are either planned or already installed, care must be taken how the storage volumes are configured. For configuring storage in a liveCache environment the following directories are affected: /sapdb/programs: The central directory with all liveCache/MaxDB executables.
SAP Supply Chain Management Planning the Volume Manager Setup NOTE For liveCache starting with version 7.6 these limitations do not exist any more. The working directory is utilized by all instances (IndepData/wrk) and can be globally shared. /var/spool/sql: This directory hosts local runtime data of all locally running liveCache/MaxDB Instances. Most of the data in this directory becomes meaningless in the context of a different host after failover.
SAP Supply Chain Management Planning the Volume Manager Setup MaxDB Storage Considerations Serviceguard Extension for SAP on Linux supports current MaxDB, liveCache and older SAPDB releases. The considerations made below will apply similarly to MaxDB, liveCache and SAPDB clusters unless otherwise noticed. MaxDB distinguishes an instance dependant path /sapdb/ and two instance independent paths, called IndepData and IndepPrograms. By default all three point to a directory below /sapdb.
SAP Supply Chain Management Planning the Volume Manager Setup /sapdb/programs/runtime/7402=7.4.2.0, For MaxDB and liveCache Version 7.5 (or higher) the SAP_DBTech.ini file does not contain sections [Installations], [Databases] and [Runtime]. These sections are stored in separate files Installations.ini, Databases.ini and Runtimes.ini in the IndepData path /sapdb/data/config. A sample SAP_DBTech.ini, Installations.ini, Databases.ini and Runtimes.ini for a host with a liveCache 7.5 (LC2) and an APO 4.
SAP Supply Chain Management Planning the Volume Manager Setup LC010 liveCache installation Step: If you decided to use option three, and the liveCache version is lower than 7.6: 1. Log on as adm on the machine on which liveCache was installed. Make sure, you have mounted a sharable logical volume on /sapdb//wrk as discussed above. 2. Change the path of the runtime directory of the liveCache and move the files to the new logical volume accordingly. cd /sapdb/data/wrk/ find .
SAP Supply Chain Management Linux Setup Linux Setup This section describes how to setup Serviceguard extension for SAP with Linux. Clustered Node Synchronization 1. Repeat the steps in this section for each node of the cluster that is different from the primary. 2. Logon as root to the primary host and prepare a logon for each of its backup hosts. LC030 liveCache installation Step: Synchronize the /etc/group and /etc/passwd files.
SAP Supply Chain Management Linux Setup LC060 liveCache installation Step: 1. Copy the content of the adm home directory to the backup node. This is a local directory on each node. 2. Rename the environment scripts on the secondary nodes. Some of the environment scripts may not exist. For example: su - adm mv .dbenv_.csh .dbenv_.csh mv .dbenv_.sh .dbenv_.sh For liveCache 7.6: su - adm mv .lcenv_.csh .lcenv_.csh mv .
SAP Supply Chain Management Linux Setup LC070 liveCache installation Step: Make sure /var/spool/sql exists as a directory on the backup node. /usr/spool must be a symbolic link to /var/spool. LC080 liveCache installation Step: On the backup node, create a directory as future mountpoint for all relevant directories from the table of section that refers to the layout option you chose.
SAP Supply Chain Management Linux Setup LC130 liveCache installation Step: If you establish frontend and server LANs to separate network traffic: Add routing entries to the internet routing configurations of /etc/rc.config.d/netconf. This is the only phase of the whole installation in which you will need to specify addresses of the server LAN. Route all relocatable client LAN addresses to the local server LAN addresses.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration Serviceguard Extension for SAP on Linux Package Configuration This section describes how to package the Serviceguard Extension for SAP on Linux Configuration. LC150 liveCache installation Step: As mentioned in an earlier section of this document, references to variable ${SGCONF} can be replaced by the definition of the variable that is found in this file /etc/cmcluster.config.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration The command: rpm -Uhv / sgesap-toolkit-.product...rpm copies all relevant SGeSAP/LX files in the ${SAPSTAGE} staging area. The following files need to be copied from the ${SAPSTAGE} staging to the SGeSAP/LX package directory: LC160 liveCache installation Step: Copy the relevant Serviceguard Extension for SAP on Linux files for liveCache to the cluster directory.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration LC170 liveCache installation Step: • Create the Serviceguard package control script and configuration files. Note the package naming convention lc as described in previous sections. cd ${SGCONF}/ cmmakepkg -s lc.control.script cmmakepkg -p lc.config Both files need to be adapted to reflect the file system layout and the individual network setup chosen.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration LC180 liveCache installation Step: In file ${SGCONF}//lc.control.script add the following lines to the customer defined functions customer_defined_run_cmds and customer_defined_halt_cmds. These commands will actually call the SGeSAP/LX relevant functions to start and stop the liveCache instance.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration The strict option can be set in order to guarantee the liveCache package gets all resources required on the adoptive node. Remember that this option can crash a system running on the adoptive node. • The following liveCache specific parameters in sap.config have to be set: LCSTARTMODE specifies the mode of the liveCache database up to which it should be started automatically. Possible values for version 7.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration LC200 liveCache installation Step: You can optionally handle SAP ABAP Application Servers with a liveCache package.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration Service Monitoring SAP recommends the use of service monitoring in order to evaluate the availability of liveCache processes. The Serviceguard service monitor, provided with Serviceguard Extension for SAP on Linux, periodically checks the availability and responsiveness of the liveCache system. The sanity of the monitor will be ensured by standard Serviceguard functionality.
SAP Supply Chain Management Serviceguard Extension for SAP on Linux Package Configuration NOTE Activation of pause mode, state changes of liveCache and liveCache restart attempts get permanently logged into the standard package logfile ${SGCONF}//lc.control.script.log. The monitor can also be paused by standard administrative tasks that use the administrative tools delivered by SAP.
SAP Supply Chain Management APO Setup Changes APO Setup Changes Running liveCache within a Serviceguard cluster package means that the liveCache instance is now configured for the relocatable IP of the package. This configuration needs to be adopted in the APO system that connects to this liveCache. GS220 liveCache installation Step: Run SAP transaction LC10 and configure the logical liveCache names LCA and LCD to listen to the relocatable IP of the liveCache package.
SAP Supply Chain Management APO Setup Changes • To find out if a given user key mapping works throughout the cluster, the relocatable address should be added to the primary host using cmmodnet -a. Run the following command as APO Administrator: dbmcli -U quit exits the upcoming prompt: dbmcli on : > quit should be relocatable. If it is not, the XUSER mapping has to be recreated. Example: mv .XUSER.62 .XUSER.62.
SAP Supply Chain Management APO Setup Changes GS240 liveCache installation Step: Distribute the XUSER mappings by distributing the file /home/adm/.XUSER. to all APO nodes that are member of the SGeSAP/LX cluster.
SAP Supply Chain Management General Serviceguard Setup Changes General Serviceguard Setup Changes Depending on the storage option chosen, the globally available directories need to be added to different existing Serviceguard packages. The following installation steps require that the system has already been configured to use the automounter feature. If this is not the case, refer to installation steps IS730 to IS770 found in Chapter 3 of this manual for setting up the automounter.
SAP Supply Chain Management General Serviceguard Setup Changes 4. Add the following entry to /etc/auto.direct. on all hosts of the liveCache package: /sapdb/programs :/export/sapdb/programs For Storage Option 3: 1. Add two shared logical volume for /export/sapdb/programs and /export/sapdb/data to the global NFS package (sapnfs). 2. Copy the content of /sapdb/programs and the remaining content of /sapdb/data from the liveCache primary node to these logical volumes. 3.
Serviceguard Extension for SAP on Linux Cluster Administration 5 Serviceguard Extension for SAP on Linux Cluster Administration A SAP application within an Serviceguard Extension for SAP on Linux cluster is no longer treated as though it runs on a dedicated host. It is wrapped up inside one or more Serviceguard packages and packages can be moved to any of the hosts that are nodes of the Serviceguard cluster.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management Change Management Serviceguard has to store information about the cluster configuration. It especially needs to know the relocatable IP addresses and its subnets, storage volume groups, the Logical Volumes and their mountpoints. System Level Changes Serviceguard Extension for SAP on Linux provides some flexibility for hardware change management.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management Entries in /etc/hosts, /etc/services, /etc/passwd or /etc/group should be kept unified across all cluster nodes. If you use an ORACLE database, be aware that the listener configuration file of SQL*Net V2 is kept as a local copy in /etc/listener.ora by default.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management NOTE If the database package with HA NFS services is halted, you cannot log in as adm unless you keep a local copy of the SAP binaries using sapcpe. To allow proper troubleshooting the level of information logged can be adjusted by changing the parameter DEBUG_LEVEL in the sap.config file.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management SAP Software Changes During the configuration of SAP on Serviceguard Extension for SAP on Linux the SAP profiles (with kernel <7.0) are modified to contain only virtual IP address instead of the initial physical IP addresses. This can be checked using SAP transaction RZ10. In the DEFAULT.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management NOTE Any running print job at the time of the failure will be canceled and needs to be reissued manually after the failover. To make the SAP print spooler highly available on the Central Instance, set the destination of the printer to __ using the SAP transaction SPAD. Print all time critical documents via the high available spool server of the Central Instance.
Serviceguard Extension for SAP on Linux Cluster Administration Change Management using relocatable names to fill in the hostname field, the instance will after a failover and under control of CCMS - continue to work without a change NOTE If an instance is running on the standby node in normal operation and is stopped during the switchover. Only configure the update service on a node for SAP application services running on the same node.
Serviceguard Extension for SAP on Linux Cluster Administration Serviceguard Extension for SAP on Linux Administration Aspects Serviceguard Extension for SAP on Linux Administration Aspects Serviceguard Extension for SAP on Linux needs some additional information about the configuration of an SAP environment. This information is stored in the file ${SGCONF}//sap.config. For more complicated cases additional configuration files ${SGCONF}//sap.config can be created. A sap.
Serviceguard Extension for SAP on Linux Cluster Administration Serviceguard Extension for SAP on Linux Administration Aspects After performing any of the above mentioned activities Serviceguard Extension for SAP on Linux failover has to be tested again to confirm proper operation.
Serviceguard Extension for SAP on Linux Cluster Administration Serviceguard Extension for SAP on Linux Administration Aspects Upgrading SAP Software Upgrading the SAP applications does not normally require changes to Serviceguard Extension for SAP on Linux. Usually Serviceguard Extension for SAP on Linux detects the release of the application that is packaged automatically and treats it as appropriate.
Serviceguard Extension for SAP on Linux Cluster Administration Switching Serviceguard Extension for SAP on Linux Off and On Switching Serviceguard Extension for SAP on Linux Off and On This section provides a brief description of how to switch off Serviceguard Extension for SAP on Linux. Your individual configuration may require additional steps that are not included in this document.
Serviceguard Extension for SAP on Linux Cluster Administration Switching Serviceguard Extension for SAP on Linux Off and On SO020: Unconfigure Serviceguard Extension for SAP on Linux: Turn on the debug mode of the Serviceguard Extension for SAP on Linux Integration. Create the debug file ${SGCONF}/debug. Then Serviceguard will mount all the file systems and enable relocatable IP addresses for the packages, but will not start the database or SAP instances.
Serviceguard Extension for SAP on Linux Cluster Administration Switching Serviceguard Extension for SAP on Linux Off and On SO070: Unconfigure Serviceguard Extension for SAP on Linux: Start all SAP Instances and the database as adm. NOTE SO080: The automounter is still using the relocatable IP-addresses. You do not need to turn off the automounter. Serviceguard and the packages remain running and provide all necessary resources. • Import the profiles with SAP ABAP Engine transaction code: RZ10.
Serviceguard Extension for SAP on Linux Cluster Administration Switching Serviceguard Extension for SAP on Linux Off and On SO510: Switching On Serviceguard Extension for SAP on Linux: Restore all profiles with the versions that use relocatable addresses. They were backed up in step SO040. If appropriate, incorporate any changes that occurred to these files during the switch off process. You can use diff(1) and the second backup you took in SO080 to easily find out if anything changed.
