Sun Cluster 3.0 5/02 Supplement

Previous: Appendix A Campus Clustering with Sun Cluster 3.0 Software - Concepts
Next: Appendix C Installing and Maintaining a Sun StorEdge 9910 or StorEdge 9960 Array

Appendix B Installing and Configuring Sun Cluster HA for SAP

This chapter provides instructions on how to plan, set up, and configure Sun Cluster HA for SAP on your Sun Cluster nodes.

This chapter includes the following procedures.

Sun Cluster HA for SAP Overview

Sun Cluster HA for SAP provides fault monitoring and automatic failover for the SAP application to eliminate single points of failure in an SAP system. The following table lists the data services that best protect SAP components in a Sun Cluster configuration. You can configure Sun Cluster HA for SAP as a failover application or a scalable application.

For conceptual information on failover and scalable services, see the Sun Cluster 3.0 12/01 Concepts.

Table B-1 Protection of SAP Components


SAP Component	Protected by
SAP database	Sun Cluster HA for Oracle, if the database is Oracle
SAP central instance	Sun Cluster HA for SAP, the resource type is `SUNW.sap_ci` or `SUNW.sap_ci_v2`
SAP application server	Sun Cluster HA for SAP, the resource type is `SUNW.sap_as` or `SUNW.sap_as_v2`
NFS file system	Sun Cluster HA for NFS

Use the scinstall(1M) command to install Sun Cluster HA for SAP. Sun Cluster HA for SAP requires a functioning cluster with the initial cluster framework already installed. See the Sun Cluster 3.0 12/01 Software Installation Guide for details on initial installation of clusters and data service software. Register Sun Cluster HA for SAP after you successfully install the basic components of the Sun Cluster and SAP software.

Installing and Configuring Sun Cluster HA for SAP

The following table lists the sections that describe the installation and configuration tasks.

Table B-2 Task Map: Installing and Configuring Sun Cluster HA for SAP


Task	For Instructions, Go To
Plan the SAP installation	"Sun Cluster HA for SAP Overview" "Configuration Guidelines for Sun Cluster HA for SAP" "Sample Configurations" "Pre-Installation Requirements" "Pre-Installation Considerations"

Upgrade Sun Cluster HA for SAP	"How to Upgrade a Resource Type or Convert a Failover Application Resource to a Scalable Application Resource"

Install and configure SAP and the database with a failover application server	"How to Install SAP and the Database" "How to Enable Failover SAP Instances to Run in the Cluster" "How to Verify SAP and the Database Installation with Central Instance" "How to Verify SAP and the Database Installation for Failover Application Server"
or
Install and configure SAP and the database with a scalable application server	"How to Install SAP and the Database" "How to Install SAP for Scalable Application Server" "How to Verify SAP Installation for Scalable Application Server"

Configure the Sun Cluster HA for DBMS	"Configuring Sun Cluster HA for DBMS"

Configure Sun Cluster HA for SAP with a failover application server	"How to Register and Configure Sun Cluster HA for SAP Central Instance" "How to Register and Configure Sun Cluster HA for SAP for Failover Application Server"
or
Configure Sun Cluster HA for SAP with a scalable application server	"How to Register and Configure Sun Cluster HA for SAP Central Instance" "How to Register and Configure Sun Cluster HA for SAP for Scalable Application Server"

Verify Sun Cluster HA for SAP installation and configuration	"How to Verify the Installation and Configuration of Sun Cluster HA for SAP, Central Instance, and DBMS" "How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Failover Application Server" "How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Scalable Application Server"

Configure SAP extension properties	"Configuring Sun Cluster HA for SAP Extension Properties"

Understand Sun Cluster HA for SAP fault monitor	"Sun Cluster HA for SAP Fault Monitor"

Planning the Installation and Configuration

Read the following information to plan your Sun Cluster HA for SAP installation.

Sun Cluster HA for SAP Packages and Support

The following tables lists the packages that Sun Cluster HA for SAP supports.

Table B-3 Sun Cluster HA for SAP packages from Sun Cluster 3.0 7/01


Resource Type	Description
`SUNW.sap_ci`	Added support for failover central instance.
`SUNW.sap_as`	Added support for failover application servers.

Table B-4 Sun Cluster HA for SAP package from Sun Cluster 3.0 12/01


Resource Type	Description
`SUNW.sap_ci`	Same as Sun Cluster 3.0 7/01. See Table B-3.
`SUNW.sap_as`	Same as Sun Cluster 3.0 7/01. See Table B-3.
`SUNW.sap_ci_v2`	Added the Property `Network_resources_used` resource property to the Resource Type Registration (RTR) file.
	Retained support for failover central instance.
`SUNW.sap_as_v2`	Added the Property `Network_resources_used` resource property to RTR file. Added support for scalable application servers.
	Retained support for failover application servers

Configuration Guidelines for Sun Cluster HA for SAP

When you design a Sun Cluster HA for SAP configuration, consider the following guidelines.

Failover and Scalable Applications

Use an SAP software version that is qualified with Sun Cluster 3.0.
Use an SAP software version with automatic enqueue reconnect mechanism capability - Sun Cluster HA for SAP relies on this capability. SAP 4.0 software with patch information and later releases should have automatic enqueue reconnect mechanism capability.
Retrieve the latest patch for the sapstart executable - This patch enables Sun Cluster HA for SAP users to configure a lock file. For details on the benefits of this patch in your cluster environment, see "Setting Up a Lock File".
Read all of the related SAP online service-system notes for the SAP software release and database that you are installing on your Sun Cluster configuration - Identify any known installation problems and fixes.
Consult SAP software documentation for memory and swap recommendations - SAP software uses a large amount of memory and swap space.
Generously estimate the total possible load on nodes that might host the central instance, the database instance, and the application server, if you have an internal application server - This guideline is especially important if you configure the cluster to ensure that the central instance, database instance, and application server will all exist on one node if failover occurs.
Install application servers on either the same cluster that hosts the central instance or on a separate cluster - If you install and configure any application server outside of the cluster environment, Sun Cluster HA for SAP does not perform fault monitoring and does not automatically restart or fail over those application servers. You must manually start and shut down application servers that you install and configure outside of the cluster environment.
Limit node names as outlined in the SAP installation guide - This limitation is an SAP software requirement.

Scalable Applications

Use the same instance number and the same SID when you create all application server instances on multiple cluster nodes - This guideline ensures ease of maintenance and ease of administration because you will only need to use one set of commands to maintain all application servers on multiple nodes.
Install the application servers locally on the cluster node instead of on a cluster file system - This guideline ensures that another application server does not overwrite the log/data/work/sec directory for the application server.
Ensure that the SAPSIDadm home directory resides on a cluster file system - This guideline enables you to maintain only one set of scripts for all application server instances that run on all nodes. However, if you have some application servers that need to be configured differently (for example, application servers with different profiles), install those application servers with different instance numbers, and then configure them in a separate resource group.
Place the application servers into multiple resource groups if you want to use RGOffload functionality to shut down one or more application servers when a higher priority resource is failing over - This guideline provides flexibility and availability if you want to use RGOffload functionality (a separate resource type) to offload one or more application servers for the database. The functionality you gain from this guideline supersedes the ease of use you gain from placing the application servers into one large group. See "Freeing Node Resources by Offloading Non-critical Resource Groups" on page 332 for more information on using the RGOffload resource type.

Sample Configurations

See your Enterprise Services representative for the most current information about supported SAP versions. The following figures illustrate sample configurations for Sun Cluster HA for SAP.

Figure B-1 Four-Node Cluster with Central Instance, Application Servers, and Database

Figure B-2 Two-Node Cluster with Central Instance, NFS, and Non-HA External Application Servers

only -

The configuration in Figure B-2 was a common configuration under previous Sun Cluster releases. To use the Sun Cluster 3.0 software to the fullest extent, configure SAP as shown in Figure B-1 or Figure B-3.

Figure B-3 Two-Node Cluster With Central Instance and Development Node

Pre-Installation Requirements

Before you install the SAP software, see "Installing and Configuring SAP and Database", understand the following requirements.

After you create all of the file systems for the database and for SAP software, create the mount points, and put the mount points in the /etc/vfstab file on all of the cluster nodes - See the SAP installation guides, Installation of the SAP R/3 on UNIX and R/3 Installation on UNIX-OS Dependencies, for details on how to set up the database and SAP file systems.
Create the required groups and users on all of the cluster nodes - See the SAP installation guides, Installation of the SAP R/3 on UNIX and R/3 Installation on UNIX-OS Dependencies, for details on how to create SAP groups and users.
Configure Sun Cluster HA for NFS on the cluster that hosts the central instance if you plan to install some external SAP application servers - See "Installing and Configuring Sun Cluster HA for NFS" in the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide for details on how to configure Sun Cluster HA for NFS.
Set up the /etc/nsswitch.conf file so that the data service starts and stops correctly during switchovers or failovers - On each node that can master the logical host that runs Sun Cluster HA for SAP, the /etc/nsswitch.conf file must have one of the following entries for group.
group: group: files group: files [NOTFOUND=return] nis group: files [NOTFOUND=return] nisplus
Sun Cluster HA for SAP uses the su user command to start and stop the database node. The network information name service might become unavailable when a cluster node's public network fails. Add one of the preceding entries for group to ensure that the su(1M) command does not refer to the NIS/NIS+ name services if the name service becomes unavailable.

Pre-Installation Considerations

Before you install the SAP software, see "Installing and Configuring SAP and Database", install SAP binaries and SAP users' home directories. Install SAP binaries and users' home directories on a cluster file system. Installation on a cluster file system, however, has some drawbacks with SAP software release upgrades. See "Determining the Location of the Application Binaries" on page 3 for information about drawbacks.

Upgrading Sun Cluster HA for SAP

As Table B-3 and Table B-4 illustrate, the Sun Cluster HA for SAP package from Sun Cluster 3.0 7/01 does not support a scalable application server and the Network_resources_used resource property. Therefore, you have the following upgrade options.

Retain (do not upgrade) the existing SUNW.sap_ci and SUNW.sap_as resource types. Choose this option if any of the following statements apply to you.
- You cannot schedule down time.
- You do not want the Network_resources_used resource property.
- You do not want to configure a scalable application server.
Upgrade a resource type.

See "How to Upgrade a Resource Type or Convert a Failover Application Resource to a Scalable Application Resource" for the procedure on how to upgrade a resource type.
Convert a failover application resource to a scalable application resource.

See "How to Upgrade a Resource Type or Convert a Failover Application Resource to a Scalable Application Resource" for the procedure on how to convert a failover application resource to a scalable application resource.

How to Upgrade a Resource Type or Convert a Failover Application Resource to a Scalable Application Resource

To upgrade a resource type or to convert a failover application server resource to a scalable application server resource, perform the following steps. This procedure requires that you schedule down time.

Disable the existing resource.

Delete the existing resource from the resource group.

Delete the existing resource type if no other resource uses it.

Which task are you performing?
- If you are upgrading the resource type for the central instance, skip to Step 7.
- If you are converting a failover application server resource to a scalable application server resource, proceed to Step 6.

Create the new application server resource group scalable-_rg.

Create the new resource in the resource group.

Where to Go From Here

Go to "How to Register and Configure Sun Cluster HA for SAP for Scalable Application Server".

Installing and Configuring SAP and Database

Use the procedures in this section to perform the following tasks.

Install SAP and the database.
Install SAP and the scalable application server.
Enable SAP to run in the cluster.
Verify SAP and the database installation with the central instance.
Verify SAP and the database installation with the failover application server.

How to Install SAP and the Database

To install SAP and the database, perform the following steps.

Become superuser on one of the nodes in the cluster where you are installing the central instance.

Install SAP binaries on a cluster file system.

only -
Before you install SAP software on a cluster file system, use the scstat(1M) command to verify that the Sun Cluster software is fully operational.
1. For all of the SAP-required kernel parameter changes, edit the /etc/system file on all of the cluster nodes that will run the SAP application.
  
  After you edit the /etc/system file, reboot each node. See the SAP document R/3 Installation on UNIX-OS Dependencies for details on kernel parameter changes.
2. See the SAP document Installation of the SAP R/3 on UNIX for details on how to install the central instance, the database, and the application server instances.
  
  See "How to Install SAP for Scalable Application Server" for the procedure on how to install a scalable application server in a Sun Cluster environment.

Where to Go From Here

Go to "How to Enable Failover SAP Instances to Run in the Cluster" or "How to Install SAP for Scalable Application Server".

How to Install SAP for Scalable Application Server

To install scalable application server instances, perform the following steps. This procedure assumes that you installed the central instance and the database.

Tip ( only) -

The following file system layout ensures ease of use and prevents data from being overwritten.

Cluster File Systems

/sapmnt/SID

/usr/sap/SID -> all subdirectories except the app-instance subdirectory

/usr/sap/SID/home -> the SAPSIDadm home directory

/usr/sap/trans
Local File Systems

/usr/sap/local/SID/app-instance

Create all SAP directories on cluster file systems.
- Ensure that the central instance and the database can fail over.
- Set up the lock file on cluster file system for the central instance to prevent a multiple startup from a different node.
  
  For the procedure on how to set up a lock file on the central instance, see "How to Set Up a Lock File for Central Instance".
- Ensure that all application servers can use the SAP binaries on a cluster file system.

Install the central instance and the database on a cluster file system.

See the SAP document Installation of the SAP R/3 on UNIX for details on how to install the central instance and the database.

On all nodes that will host the scalable application server, create a local directory for the data/log/sec/work directories and the log files for starting and stopping the application server.

Caution -
You must perform this step. If you do not perform this step, you will inadvertently install a different application server instance on a cluster file system and the two application servers will overwrite each other.

Create a local directory for each new application server.

Example:
# mkdir -p /usr/sap/local/SC3/D03

Set up a link to point to the local application server directory from a cluster file system, so the application server and the startup/stop log file will be installed on the local file system.

Example:
# ln -s /usr/sap/local/SC3/D03 /usr/sap/SC3/D03

Install the application server.

Edit the start/stop script so that the startup/stop log files will be node specific under the home directories of users sapsidadm and orasapsid.

Example:
# vi startsap_D03
Before:
LOGFILE=$R3S_LOGDIR/`basename $0.log`
After:
LOGFILE=$R3S_LOGDIR/`basename $0`_`uname -n`.log

Copy the application server (with the same SAPSID and the same instance number) on all nodes that run the scalable application server.

The nodes that run the scalable application server are in the scalable application server resource group nodelist.

Ensure that you can startup and stop the application server from each node, and verify that the log files are in the correct location.

Install the SAP logon group if you use a logon group.

How to Verify SAP Installation for Scalable Application Server

If you installed scalable application server instances in "How to Install SAP for Scalable Application Server", you verified the installation of SAP for the scalable application server in Step 8 of "How to Install SAP for Scalable Application Server".

How to Enable Failover SAP Instances to Run in the Cluster

During SAP installation, the SAP software creates files and shell scripts on the server on which you installed the SAP instance. These files and scripts use physical server names. To run the SAP software with Sun Cluster software, replace references to a physical server with references to a network resource (logical hostname). Throughout these steps, the term physicalserver represents a physical server, and the term logical-hostname represents a network resource.

To enable failover SAP instances to run in the cluster, perform the following steps.

Make backup copies of the files that you will modify in the following steps.

Shut down the SAP instances (central instance and application server instances) and the database.

Become user sapsidadm, and then perform the following tasks.
1. In the SAPSIDadm home directory, modify all of the file names that reference a physical server name.
2. In the SAPSIDadm home directory, modify all of the file contents-except log file contents-that reference a physical server name.
3. In the SAP profile directory, modify all of the file names that reference a physical server name.

As user sapsidadm, add entries for the parameter SAPLOCALHOST.

Add this entry to the SAPSID_Service-StringSystem-Number_logical-hostname profile file under the /sapmnt/SAPSID/profile directory.

For Central Instance:
SAPLOCALHOST=ci-logical-hostname
This entry enables the external application server to locate the central instance by using the network resource (logical hostname or shared address).

For Application Server:
SAPLOCALHOST=as-logical-hostname

Become user orasapsid, and then perform the following tasks.
- In the oraSAPSID home directory, modify all of the file names that reference a physical server name.
- In the oraSAPSID home directory, modify all of the file contents-except log file contents-that reference a physical server name.

Ensure that the /usr/sap/tmp directory owned by user sapsidadm and group sapsys exists on all nodes that can master the failover SAP instance.

Where to Go From Here

Go to "How to Verify SAP and the Database Installation with Central Instance".

How to Verify SAP and the Database Installation with Central Instance

To test starting and stopping the SAP central instance on all of the potential nodes on which the central instance can run, perform the following steps.

Create the failover resource group to hold the network and central instance resources.
# scrgadm -a -g sap-ci-resource-group [-h nodelist]
only -
Use the -h option to the scrgadm(1M) command to select the set of nodes on which the SAP central instance can run.

Verify that you have added to your name service database all of the network resources that you use.

Add a network resource (logical hostname) to the failover resource group.

# scrgadm -a -L -g sap-ci-resource-group -l ci-logical-hostname [-n netiflist]

Enable the resource group.

Run the scswitch(1M) command to move the resource group into a managed state and bring the resource group online.
# scswitch -Z -g sap-ci-resource-group

Ensure that the database is running.

Manually start the central instance.

Start the SAP GUI using the logical hostname, and verify that SAP initializes correctly.

The default dispatcher port is 3200.

Manually stop the central instance.

Switch this resource group to another cluster member that can host the central instance.
# scswitch -z -h node -g sap-ci-resource-group

Repeat Step 5 through Step 9 until you verify startup and shutdown of the central instance on each cluster node that can host the central instance.

Where to Go From Here

Go to "How to Verify SAP and the Database Installation for Failover Application Server".

How to Verify SAP and the Database Installation for Failover Application Server

To test starting and stopping the failover application server, perform the following steps procedure on all of the potential nodes on which the failover application server can run.

Create the failover resource group to hold the network and application server resources.
# scrgadm -a -g sap-as-fo-resource-group
only -
Use the -h option to the scrgadm command to select the set of nodes on which the SAP application server can run.
# scrgadm -a -g sap-as-fo-resource-group [-h nodelist]

Verify that you added to your name service database all of the network resources that you use.

Add a network resource (logical hostname) to the failover resource group.

# scrgadm -a -L -g sap-as-fo-resource-group -l as-fo-logical-hostname [-n netiflist]

Enable the resource group.

Run the scswitch(1M) command to move the resource group into a managed state and bring the resource group online.
# scswitch -Z -g sap-as-of-resource-group

Manually start the application server.

Start the SAP GUI using the logical hostname, and verify that SAP initializes correctly.

Manually stop the application server.

Switch this resource group to another cluster member that can host the application server.
# scswitch -z -h node -g sap-as-fo-resource-group

Repeat Step 5 through Step 7 until you verify startup and shutdown of the application server on each cluster node that can host the application server.

Where to Go From Here

Go to "Configuring Sun Cluster HA for DBMS" for information on how to configure DBMS, an SAP service, so that it is highly available.

Configuring Sun Cluster HA for DBMS

SAP supports various databases. See the appropriate chapter of this book for details on how to configure the resource type, resource group, and resource for your highly available database. For example, see "Installing and Configuring Sun Cluster HA for Oracle" on page 16 for more information if you plan to use Oracle with SAP.

Additionally, see the appropriate chapter of this book and the appropriate chapter of your database installation book for details on other resource types to configure with your database. This book includes details on how to configure other resource types for Oracle databases. For instance, set up the SUNW.HAStorage resource type if you use Oracle. See the procedure "How to Configure SUNW.HAStorage Resource Type" on page 35 for more information.

Where to Go From Here

Go to "Registering and Configuring Sun Cluster HA for SAP".

Registering and Configuring Sun Cluster HA for SAP

Use the procedures in this section to perform the following tasks.

How to Register and Configure Sun Cluster HA for SAP Central Instance

To register and configure Sun Cluster HA for SAP central instance, perform the following steps.

Become superuser on one of the nodes in the cluster that hosts the central instance.

Create SAP central instance resources in this failover resource group.

# scrgadm -a -j sap-ci-resource -g sap-ci-resource-group \
-t SUNW.sap_ci | SUNW.sap_ci_v2 \
-x SAPSID=SAPSID \
-x Ci_startup_script=ci-startup-script \
-x Ci_shutdown_script=ci-shutdown-script

See "Configuring Sun Cluster HA for SAP Extension Properties" for a list of extension properties.

Enable the failover resource group that now includes the SAP central instance resource.
# scswitch -Z -g sap-ci-resource-group

Where to Go From Here

Go to "How to Register and Configure Sun Cluster HA for SAP for Failover Application Server" or "How to Register and Configure Sun Cluster HA for SAP for Scalable Application Server".

How to Register and Configure Sun Cluster HA for SAP for Failover Application Server

To register and configure Sun Cluster HA for SAP for a failover application server, perform the following steps.

Become superuser on one of the nodes in the cluster that hosts the application server.

Register the resource type for the failover application server.
# scrgadm -a -t SUNW.sap_as | SUNW.sap_as_v2

Create SAP application server resources in this failover resource group.

# scrgadm -a -j sap-as-resource -g sap-as-fo-resource-group \
-t SUNW.sap_as | SUNW.sap_as_v2 \

-x SAPSID=SAPSID \

-x As_instance_id=as-instance-id \

-x As_startup_script=as-startup-script \

-x As_shutdown_script=as-shutdown-script

See "Configuring Sun Cluster HA for SAP Extension Properties" for a list of extension properties.

Enable the failover resource group that now includes the SAP application server resource.
# scswitch -Z -g sap-as-fo-resource-group

Where to Go From Here

Go to "How to Verify the Installation and Configuration of Sun Cluster HA for SAP, Central Instance, and DBMS".

How to Register and Configure Sun Cluster HA for SAP for Scalable Application Server

To register and configure Sun Cluster HA for SAP for a scalable application server, perform the following steps.

Become superuser on one of the nodes in the cluster that hosts the application server.

Create a scalable resource group for the application server.
# scrgadm -a -g sap-as-sa-appinstanceid-resource-group \ -y Maximum_primaries=value \ -y Desired_primaries=value
only -
You will not use the shared address to perform load balancing of the application server. The SAP Message Server will be used to perform load balancing of the application server.

only -
If you are using the SUNW.RGOffload resource type to offload an application server within this scalable application server resource group, then set Desired_primaries=0. See "Freeing Node Resources by Offloading Non-critical Resource Groups" on page 332 for more information about using the SUNW.RGOffload resource type.

Create SAP application server resources in this scalable resource group.

# scrgadm -a -j sap-as-resource -g sap-as-sa-appinstanceid-resource-group \

-t SUNW.sap_as_v2 \

-x SAPSID=SAPSID \

-x As_instance_id=as-instance-id \

-x As_startup_script=as-startup-script \

-x As_shutdown_script=as-shutdown-script

See "Configuring Sun Cluster HA for SAP Extension Properties" for a list of extension properties.

Enable the scalable resource group that now includes the SAP application server resource.
- If you do not use the SUNW.RGOffload resource type with this application server, use the following command.
  # scswitch -Z -g sap-as-sa-appinstanceid-resource-group
- If you use the SUNW.RGOffload resource type with this application server, use the following command.
  # scswitch -z -h node1, node2 -g sap-as-sa-appinstanceid-resource-group
only -
If you use the SUW.RGOffload resource type with this application server, you must specify which node you want to bring the resource online by using the -z option instead of the -j option.

Where to Go From Here

Go to "How to Verify the Installation and Configuration of Sun Cluster HA for SAP, Central Instance, and DBMS".

Verifying Sun Cluster HA for SAP Installation and Configuration

Use the procedures in this section to perform the following tasks.

Verify the installation and configuration of Sun Cluster HA for SAP, the central instance, and DBMS.
Verify the installation and configuration of Sun Cluster HA for SAP with a failover application server.
Verify the installation and configuration of Sun Cluster HA for SAP with a scalable application server.

How to Verify the Installation and Configuration of Sun Cluster HA for SAP, Central Instance, and DBMS

To verify both the Sun Cluster HA for SAP installation with the central instance and the DBMS installation and configuration, perform the following steps.

Start the SAP GUI to check that Sun Cluster HA for SAP is functioning correctly.

As user sapsidadm, use the central instance stopsap script to shut down the SAP central instance.

The Sun Cluster software restarts the central instance.

As user root, switch the SAP resource group to another cluster member.
# scswitch -z -h node2 -g sap-ci-resource-group

Verify that the SAP central instance starts on this node.

Repeat Step 1 through Step 5 until you have tested all of the potential nodes on which the SAP central instance can run.

Where to Go From Here

Go to "How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Failover Application Server" or "How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Scalable Application Server".

How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Failover Application Server

To verify the Sun Cluster HA for SAP installation and configuration for a failover application server, perform the following steps.

As user sapsidadm, start the SAP GUI to check that the application server is functioning correctly.

Use the application server stopsap script to shut down the SAP application server on the node you identified in Step 1.

The Sun Cluster software restarts the application server.

As user root, switch the resource group that contains the SAP application server resource to another cluster member.
# scswitch -z -h node2 -g sap-as-resource-group

Verify that the SAP application server starts on the node you identified in Step 4.

Repeat Step 1 through Step 5 until you have tested all of the potential nodes on which the SAP application server can run.

How to Verify the Installation and Configuration of Sun Cluster HA for SAP for Scalable Application Server

To verify the Sun Cluster HA for SAP installation and configuration for a scalable application server, perform the following steps.

Log on to one of the nodes that runs the application server.

Become user sapsidadm.

Start the SAP GUI to check that the application server is functioning correctly.

Use the application server stopsap script to shut down the SAP application server on the node you identified in Step 1.

The Sun Cluster software restarts the application server.

Repeat Step 1 through Step 4 until you have tested all of the potential nodes on which the SAP application server can run.

Configuring Sun Cluster HA for SAP Extension Properties

Use the Sun Cluster HA for SAP extension properties in this section to create the central instance resources and application server resources. Typically, you use the command line scrgadm -x parameter=value to configure the extension properties when you create the central instance or application resource. You can also use the procedures described in Chapter 13 to configure them later. See Appendix A for details on all of the Sun Cluster properties.

See the r_properties(5) and the rg_properties(5) man pages for details on all of the Sun Cluster extension properties.

Table B-5 describes SAP extension properties that you can set for the central instance. You can update some extension properties dynamically. You can update others, however, only when you create or disable the SAP resource. The Tunable entries indicate when you can update each property. Table B-6 describes the extension properties that you can set for the application servers.

Table B-5 Sun Cluster HA for SAP Extension Properties for the Central Instance


Property Category	Property Name	Description
SAP Configuration	`SAPSID`	SAP system name or `SAPSID`. Default: None Tunable: When disabled
	`Ci_instance_id`	Two-digit SAP system number. Default: `00` Tunable: When disabled
	`Ci_services_string`	String of central instance services. Default: `DVEBMGS` Tunable: When disabled
Starting SAP	`Ci_start_retry_ interval`	The interval in seconds to wait between attempting to connect to the database before starting the central instance. Default: `30` Tunable: When disabled
Starting SAP	`Ci_startup_script`	Name of the SAP startup script for this instance in your `SIDadm` home directory. Default: None Tunable: When disabled
Stopping SAP	`Stop_sap_pct`	Percentage of stop-timeout variables that are used to stop SAP processes. The SAP shutdown script is used to stop processes before calling Process Monitor Facility (PMF) to terminate and then kill the processes. Default: `95` Tunable: When disabled
Stopping SAP	`Ci_shutdown_script`	Name of the SAP shutdown script for this instance in your `SIDadm` home directory. Default: None Tunable: When disabled
Probe	`Message_server_name`	The name of the SAP Message Server. Default: `sapms` `SAPSID` Tunable: When disabled
	`Lgtst_ms_with_ logicalhostname`	How to check the SAP Message Server with the SAP `lgtst` utility. The `lgtst` utility requires a hostname (IP address) as the location for the SAP Message Server. This hostname can be either a Sun Cluster logical hostname or a localhost (loopback) name. If you set this resource property to `TRUE`, use a logical hostname. Otherwise, use a localhost name. Default: `TRUE` Tunable: Any time
	`Check_ms_retry`	Maximum number of times the SAP Message Server check fails before a total failure is reported and the Resource Group Manager (RGM) starts. Default: `2` Tunable: When disabled
	`Probe_timeout`	Time-out value in seconds for the probes. Default: `60` Tunable: Any time
	`Monitor_retry_count`	Number of PMF restarts that are allowed for the fault monitor. Default: `4` Tunable: Any time
	`Monitor_retry_ interval`	Time interval in minutes for fault monitor restarts. Default: `2` Tunable: Any time
Development System	`Shutdown_dev`	Whether the RGM should shut down the development system before starting up the central instance. Default: `FALSE` Tunable: When disabled
	`Dev_sapsid`	SAP System Name for the development system (if you set `Shutdown_dev` to `TRUE`, Sun Cluster HA for SAP requires this property). Default: None Tunable: When disabled
	`Dev_shutdown_script`	Script that is used to shut down the development system. If you set `Shutdown_dev` to `TRUE`, Sun Cluster HA for SAP requires this property. Default: None Tunable: When disabled
	`Dev_stop_pct`	Percentage of startup timeouts Sun Cluster HA for SAP uses to shut down the development system before starting the central instance. Default: `20` Tunable: When disabled

Table B-6 Sun Cluster HA for SAP Extension Properties for the Application Servers


Property Category	Property Name	Description
SAP Configuration	`SAPSID`	SAP system name or `SAPSID` for the application server. Default: None Tunable: When disabled
	`As_instance_id`	Two-digit SAP system number for the application server. Default: None Tunable: When disabled
	`As_services_string`	String of application server services. Default: `D` Tunable: When disabled
Starting SAP	`As_db_retry_interval`	The interval in seconds to wait between attempting to connect to the database and starting the application server. Default: `30` Tunable: When disabled
Starting SAP	`As_startup_script`	Name of the SAP startup script for the application server. Default: None Tunable: When disabled
Stopping SAP	`Stop_sap_pct`	Percentage of stop-timeout variables that are used to stop SAP processes. The SAP shutdown script is used to stop processes before calling Process Monitor Facility (PMF) to terminate and then kill the processes. Default: `95` Tunable: When disabled
Stopping SAP	`As_shutdown_script`	Name of the SAP shutdown script for the application server. Default: None Tunable: When disabled
Probe	`Probe_timeout`	Time-out value in seconds for the probes. Default: `60` Tunable: Any time
	`Monitor_retry_count`	Number of PMF restarts that the probe allows for the fault monitor. Default: `4` Tunable: Any time
	`Monitor_retry_ interval`	Time interval in minutes for fault monitor restarts. Default: `2` Tunable: Any time

Setting Up a Lock File

Use the procedure in this section to perform the following tasks.

Set up a lock file for the central instance.
Set up a lock file for a scalable application server.

Set up a lock file to prevent multiple startups of the SAP instance when the instance is already active on one node. Multiple startups of the same instance crash each other. Furthermore, the crash prevents SAP shutdown scripts from performing a clean shutdown of the instances, which might cause data corruption.

If you set up a lock file, when you start the SAP instance the SAP software locks the file startup_lockfile. If you start up the same instance outside of the Sun Cluster environment and then try to bring up SAP under the Sun Cluster environment, the Sun Cluster HA for SAP data service will attempt to start up the same instance. However, because of the file-locking mechanism, this attempt will fail. The data service will log appropriate error messages in /var/adm/messages.

The only difference between the lock file for the central instance or the failover application server and the lock file for a scalable application server is that the lock file for scalable application server resides on the local file system and the lock file for the central instance or the failover application server resides on a cluster file system.

How to Set Up a Lock File for Central Instance

To set up a central instance lock file, perform the following steps.

Install the latest patch for the sapstart executable, which enables Sun Cluster HA for SAP users to configure a lock file.

Set up the central instance lock file on a cluster file system.

Edit the profile SC3_DVEBMGS00 to add the new SAP parameter, sapstart/lockfile, for the application server.
sapstart/lockfile =/usr/sap/SC3/DVEBMGS00/work/startup_lockfile
sapstart/lockfile

New parameter name.

/usr/sap/local/SC3/DVEBMGS00/work

Work directory for the application server.

startup_lockfile

Lock file name that Sun Cluster HA for SAP uses.

SAP creates the lock file.

only -
You must locate the lock file path on a cluster file system. If you locate the lock file path locally on the nodes, startups of the same instance from multiple nodes cannot be prevented.

How to Set Up a Lock File for Scalable Application Server

To set up a lock file for a scalable application server, perform the following steps.

Install the latest patch for the sapstart executable, which enables Sun Cluster HA for SAP users to configure a lock file.

Set up the application server lock file on the local file system.

Edit the profile SC3_instance-id to add the new SAP parameter, sapstart/lockfile, for the application server.
sapstart/lockfile =/usr/sap/local/SC3/Dinstance-id/work/startup_lockfile
sapstart/lockfile

New parameter name.

/usr/sap/SC3/Dinstance-id/work

Work directory for the central instance.

startup_lockfile

Lock file name that Sun Cluster HA for SAP uses.

SAP creates the lock file.

only -
The lock file will reside on the local file system. The lock file does not prevent multiple startups from other nodes, but the lock file does prevent multiple startups from the same node.

Sun Cluster HA for SAP Fault Monitor

The Sun Cluster HA for SAP fault monitor checks SAP process and database health. SAP process health impacts SAP resources' failure history. SAP resources' failure history in turn drives the fault monitor's actions, which include no action, restart, or failover.

In contrast to SAP process health, the health of the database SAP uses has no impact on SAP resources' failure history. Database health does, however, trigger the SAP fault monitor to log any syslog messages and to set the status accordingly for the SAP resource that uses the database.

Sun Cluster HA for SAP Fault Probes for Central Instance

For the central instance, the fault probe executes the following steps.

Retrieves the process IDs for the SAP Message Server and the dispatcher
Loops infinitely (sleeps for Thorough_probe_interval)
Checks the health of the SAP resources
1. Abnormal exit - If the Process Monitor Facility (PMF) detects that the SAP process tree has failed, the fault monitor treats this problem as a complete failure. The fault monitor restarts or fails over the SAP resource to another node based on the resources' failure history.
2. Health check of the SAP resources through probe - The probe uses the ps(1) command to check the SAP Message Server and main dispatcher processes. If any of the SAP Message Server or main dispatcher processes are missing from the system's active processes list, the fault monitor treats this problem as a complete failure.
  
  If you configure the parameter Check_ms_retry to have a value greater than zero, the probe checks the SAP Message Server connection. If you have set the extension property Lgtst_ms_with_logicalhostname to its default value TRUE, the probe completes the SAP Message Server connection test with the utility lgtst. The probe uses the logical hostname interface that is specified in the SAP resource group to call the SAP-supplied utility lgtst. If you set the extension property Lgtst_ms_with_logicalhostname to a value other than TRUE, the probe calls lgtst with the node's localhost name (loopback interface).
  
  If the lgtst utility call fails, the SAP Message Server connection is not functioning. In this situation, the fault monitor considers the problem to be a partial failure and does not trigger an SAP restart or a failover immediately. The fault monitor counts two partial failures as a complete failure if the following conditions occur.
  1. You configure the extension property Check_ms_retry to be 2.
  2. The fault monitor accumulates two partial failures that happen within the retry interval that the resource property Retry_interval sets.
  A complete failure triggers either a local restart or a failover, based on the resource's failure history.
3. Database connection status through probe - The probe calls the SAP-supplied utility R3trans to check the status of the database connection. Sun Cluster HA for SAP fault probes verify that SAP can connect to the database. Sun Cluster HA for SAP depends, however, on the highly available database fault probes to determine the health of the database. If the database connection status check fails, the fault monitor logs the message, Database might be down, to syslog. The fault monitor then sets the status of the SAP resource to DEGRADED. If the probe checks the status of the database again and the connection is reestablished, the fault monitor logs the message, Database is up, to syslog and sets the status of the SAP resource to OK.
Evaluates the failure history

Based on the failure history, the fault monitor completes one of the following actions.
- no action
- local restart
- failover

Sun Cluster HA for SAP Fault Probes for Application Server

For the application server, the fault probe executes the following steps.

Retrieves the process ID for the main dispatcher
Loops infinitely (sleeps for Thorough_probe_interval)
Checks the health of the SAP resources
1. Abnormal exit - If the Process Monitor Facility (PMF) detects that the SAP process tree has failed, the fault monitor treats this problem as a complete failure. The fault monitor restarts or fails over the SAP resource to another node, based on the resources' failure history.
2. Health check of the SAP resources through probe - The probe uses the ps(1) command to check the SAP Message Server and main dispatcher processes. If the SAP main dispatcher process is missing from the system's active processes list, the fault monitor treats the problem as a complete failure.
3. Database connection status through probe - The probe calls the SAP-supplied utility R3trans to check the status of the database connection. Sun Cluster HA for SAP fault probes verify that SAP can connect to the database. Sun Cluster HA for SAP depends, however, on the highly available database fault probes to determine the health of the database. If the database connection status check fails, the fault monitor logs the message, Database might be down, to syslog and sets the status of the SAP resource to DEGRADED. If the probe checks the status of the database again and the connection is reestablished, the fault monitor logs the message, Database is up, to syslog. The fault monitor then sets the status of the SAP resource to OK.
Evaluates the failure history

Based on the failure history, the fault monitor completes one of the following actions.
- no action
- local restart
- failover
  
  If the application server resource is a failover resource, the fault monitor fails over the application server.
  
  If the application server resource is a scalable resource, after the number of local restarts are exhausted, RGM will bring up the application server on a different node if there is another node available in the cluster.