Sun Cluster 3.0 12/01 Release Notes Supplement

Appendix B Installing and Configuring Sun Cluster HA for SAP

This chapter contains the procedures on how to install and configure Sun Cluster HA for SAP.

This chapter contains the following procedures.

Sun Cluster HA for SAP Overview

Use the information in this section to understand how Sun Cluster HA for SAP makes SAP highly available.

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

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.

Table B-1 Protection of SAP Components


SAP Component	Protected by
SAP database	Sun Cluster HA for Oracle Use Oracle as your database.
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

Table B-2 lists the tasks for installing and configuring Sun Cluster HA for SAP. Perform these tasks in the order that they are listed.

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


Task	For Instructions, Go To
Plan the SAP installation	Chapter 1 of Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide "Planning the Sun Cluster HA for SAP Installation and Configuration"
Upgrade Sun Cluster HA for SAP	"How to Upgrade a Resource Type or Convert a Failover Application Resource to a Scalable Application Resource"
Prepare the nodes and disks	"How to Prepare the Nodes"
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 `SUNW.HAStorage` or `SUNW.HAStoragePlus`	"Relationship Between Resource Groups and Disk Device Groups" on page 5 to understand the need for these resource types "How to Set Up HAStoragePlus Resource Type" on page 361 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide "How to Set Up HAStorage Resource Type for New Resources" on page 358 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide for the procedures on how to create these resource types
Understand Sun Cluster HA for SAP fault monitor	"Understanding Sun Cluster HA for SAP Fault Monitor"

Planning the Sun Cluster HA for SAP Installation and Configuration

This section contains the information you need to plan your Sun Cluster HA for SAP installation and configuration.

Configuration Restrictions

Caution -

Your data service configuration might not be supported if you do not observe these restrictions.

Use the restrictions in this section to plan the installation and configuration of Sun Cluster HA for SAP. This section provides a list of software and hardware configuration restrictions that apply to Sun Cluster HA for SAP.

For restrictions that apply to all data services, see the Sun Cluster 3.0 12/01 Release Notes.

Limit node names as outlined in the SAP installation guide - This limitation is an SAP software requirement.

Configuration Requirements

Caution -

Your data service configuration might not be supported if you do not adhere to these requirements.

Use the requirements in this section to plan the installation and configuration of Sun Cluster HA for SAP. These requirements apply to Sun Cluster HA for SAP only. You must meet these requirements before you proceed with your Sun Cluster HA for SAP installation and configuration.

For requirements that apply to all data services, see "Identifying Data Service Special Requirements" on page 3 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide.

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" on page 126 for details on how to configure Sun Cluster HA for NFS.
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.
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.

Standard Data Service Configurations

Use the standard configurations in this section to plan the installation and configuration of Sun Cluster HA for SAP. Sun Cluster HA for SAP supports the standard configurations in this section. Sun Cluster HA for SAP might support additional configurations. However, you must contact your Enterprise Services representative for information on additional configurations.

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

Note -

The configuration in Figure B-2 was a common configuration under previous Sun Cluster releases. To use the Sun Cluster 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

Configuration Considerations

Use the information in this section to plan the installation and configuration of Sun Cluster HA for SAP. The information in this section encourages you to think about the impact your decisions have on the installation and configuration of Sun Cluster HA for SAP.

Failover and Scalable Applications

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 consideration 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.

Scalable Applications

Use the same instance number and the same SID when you create all application server instances on multiple cluster nodes - This consideration 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 consideration 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 consideration 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 consideration 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 consideration 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 363 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide for more information on using the RGOffload resource type.

Configuration Planning Questions

Use the questions in this section to plan the installation and configuration of Sun Cluster HA for SAP. Insert the answers to these questions into the data service worksheets in the Sun Cluster 3.0 12/01 Release Notes. See "Configuration Considerations" for information that might apply to these questions.

What resource groups will you use for network addresses and application resources and the dependencies between them?
What is the logical hostname (for failover services) for clients that will access the data service?
Where will the system configuration files reside?

See "Determining the Location of the Application Binaries" on page 3 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide for the advantages and disadvantages of placing the liveCache binaries on the local file system as opposed to the cluster file system.

Packages and Support

Table B-3 and Table B-4 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

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

Use this procedure to upgrade a resource type or to convert a failover application server resource to a scalable application server resource. 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 Prepare the Nodes".

Preparing the Nodes and Disks

This section contains the procedures you need to prepare the nodes and disks.

How to Prepare the Nodes

Use this procedure to prepare for the installation and configuration of SAP.

Become superuser on all of the nodes.

Configure the /etc/nsswitch.conf so that Sun Cluster HA for SAP starts and stops correctly in the event of a switchover or a failover.

On each node that can master the logical host that runs Sun Cluster HA for SAP, include one of the following entries for group in the /etc/nsswitch.conf file.
group: group: files [NOTFOUND=return] nis group: file [NOTFOUND=return] nisplus
Sun Cluster HA for SAP uses the su user command to start and probe SAP. The network information name service might become unavailable when a cluster node's public network fails. When you add one of the entries for group in the /etc/nsswitch.conf file, you ensure that the su(1M) command does not refer to the NIS/NIS+ name services if the network information name service is unavailable.

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

This section contains the procedures you need to install and configure SAP and the database.

How to Install SAP and the Database

Use this procedure to install SAP and the database.

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.

Note -
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

Use this procedure to install scalable application server instances. This procedure assumes that you installed the central instance and the database. This procedure includes additional steps for SAP 6.10 users to ensure that Sun Cluster HA for SAP can manage and bring online SAP 6.10 services. SAP 6.10 creates one startsap script and one stopsap script. Other SAP versions create one of each of theses scripts for each service you create. This difference accounts for the additional steps for SAP 6.10 users.

Tip -

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.

Create a local directory for each new application server.

Example:
# mkdir -p /usr/sap/local/SC3/D03
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.

Set up a link to point to the local application server directory from a cluster file system, so the application server and the startup log file and the 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.

Are you using SAP 6.10?
- If no, skip to Step 11
- If yes, proceed to Step 7.

Become user sapsidadm.

Make a copy of the startsap script and the stopsap script, and save these files in the SAPSIDadm home directory. The filenames that you choose specify this instance.

# cp /usr/sap/SID/SYS/exe/run/startsap$SAPSID_HOME/ \
startsap_instance-number

# cp /usr/sap/SID/SYS/exe/run/stopsap$SAPSID_HOME/ \
stopsap_instance-number

Make backup copies of the following files because you will modify them. In the SAP profile directory, modify all the filenames for this instance. The filenames that you choose must be specific to this instance, and they must follow the same naming convention you chose in Step 8.

# mv SAPSID_Service-StringSystem-Number_physical-hostname \SAPSID_Service-StringSystem_instance-number

# mv START_Service-StringSystem-Number_physical-hostname \START_Service-StringSystem_instance-number

Modify the contents of the files you created in Step 9 to replace any reference to the physical host with the instance number.

Caution -
It is important that you make your updates consistent so that you can start and stop this application server instance from all the nodes that will run this scalable application server. For example, if you make these changes for SAP instance number 02, then use 02 where this instance number appears. If you do not use a consistent naming convention you will be unable start and stop this application server instance from all the nodes that will run this scalable application server.

Edit the start script and the stop script so that the startup log file and the stop log file 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 13 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). Use this procedure to enable SAP to run in a cluster.

Make backup copies of the files you will modify in Step 5 through Step 8.

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

Are you using SAP 6.10?
- If no, skip to Step 6.
- If yes, proceed to Step 5.

Make a copy of the startsap script and the stopsap script, and save these files in the SAPSIDadm home directory. The filenames that you choose must specify this instance.

# cp /usr/sap/SID/SYS/exe/run/startsap$SAPSID_HOME/ \
startsap_logical-hostname_instance-number
# cp /usr/sap/SID/SYS/exe/run/startsap$SAPSID_HOME/ \
stopsap_logical-hostname_instance-number

Become user sapsidadm, and then perform the following tasks.
- In the SAPSIDadm home directory, modify all of the file names that reference a physical server name.
- In the SAPSIDadm home directory, modify all of the file contents-except log file contents-that reference a physical server name.
- 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

Use this procedure to verify SAP central instance. Perform the following steps on all of the potential nodes on which the central instance can run.

Create the failover resource group to hold the network and central instance resources.
# scrgadm -a -g sap-ci-resource-group [-h nodelist]
Note -
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

Use this procedure to verify SAP and the database installation for the failover application server. Perform the following steps 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
Note -
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 Set Up HAStorage Resource Type for New Resources" on page 358 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide 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

This section contains the procedures you need to configure Sun Cluster HA for SAP.

Sun Cluster HA for SAP Extension Properties

Use the extension properties in Table B-5 and Table B-6 to create your resources. Use the command line scrgadm -x parameter=value to configure extension properties when you create your resource. Use the procedure in Chapter 14 to configure the extension properties if you have already created your resources. You can update some extension properties dynamically. You can update others, however, only when you create or disable a resource. The Tunable entries indicate when you can update each property. See Appendix A for details on all Sun Cluster properties.

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

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

Use this procedure to configure Sun Cluster HA for SAP central instance.

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 "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

Use this procedure to configure Sun Cluster HA for SAP for a failover application server.

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 "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

Use this procedure to configure Sun Cluster HA for SAP for a scalable application server.

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
Note -
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.

Note -
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 363 of the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide 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 "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 RGOffload resource type with this application server, use the following command.
  # scswitch -Z -g sap-as-sa-appinstanceid-resource-group
- If you use the RGOffload resource type with this application server, use the following command.
  # scswitch -z -h node1, node2 -g sap-as-sa-appinstanceid-resource-group
Note -
If you use the SUNW.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

This section contains the procedure you need to verify that you installed and configured your data service correctly.

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

Use this procedure to verify both the Sun Cluster HA for SAP installation with the central instance and the DBMS installation and configuration.

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

Use this procedure to verify the Sun Cluster HA for SAP installation and configuration for a failover application server.

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

Use this procedure to verify the Sun Cluster HA for SAP installation and configuration for a scalable application server.

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 3 until you have tested all of the potential nodes on which the SAP application server can run.

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

Use this procedure to set up a central instance lock file.

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.

Note -
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

Use this procedure to set up a lock file for a scalable application server.

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.

Note -
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.

Understanding 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 to /var/adm/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 /var/adm/messages. 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 /var/adm/messages 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 /var/adm/messages 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 /var/adm/messages. The fault monitor then sets the status of the SAP resource to OK.
Evaluate 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.