SGeSAP Administration Issues

This section describes the new aspects that a System Administrator of any SGeSAP cluster should always be aware of.

Installation of the SGeSAP Integration Scripts significantly changes the hardware and software setup of your system. This affects the way you administer your SAP R/3. To get more detailed information on your specific setup, please refer to the documentation you receive from the person that installs the SGeSAP Integration on your system.

You no longer need to treat the Central Instance of your SAP R/3 system and its accompanying database Instance as though it runs on a dedicated host. With SAP R/3 they are wrapped up inside one or more MC/ServiceGuard packages and packages can be sent to any of the hosts that are inside of your MC/ServiceGuard cluster.

This provides not only a mechanism to cope with hardware failures but also a new amount of flexibility and opportunities. If you have to maintain the host machine on which your SAP R/3 is running, you can "send the running SAP R/3 over" to another host. This causes a few minutes of downtime only, in contrast to the significantly higher amount downtime if you have to wait until the maintenance is completed before you can restart your SAP R/3 Instances.

On the other hand you have to be more careful in changing the setup. This applies to hardware changes as well as software issues.

The balance of this section describes the following SGeSAP administration aspects:

Hardware Aspects

If you add new hardware and SAP R/3 needs access to it to work properly, make sure to allow this access from any host of the cluster by appropriately planning the connectivity. For example:

It is possible to increase database disk space by adding a new RAID-Array to the primary host on which your Database Instance normally runs.

Setup with shared disks, so the new RAID-Array is visible on the new host and does not create an error.

You can add the RAID-Array using the conventional method you are used to. But remember: The fact that your SAP R/3 system runs correctly after the changes does not imply that it will work after a switchover to a different host as well.

For the same reason a high available SAP R/3 Spooling Service needs a connection to the printers from any host in the cluster.

If you do not feel comfortable in changing your hardware setup, please contact your HP-consultant.

HP-UX Software Aspects

Depending on your particular setup, you will have to deal with three important groups of directories that need special treatment:

common directories that are kept local on any node
Using a standard setup the following directories and their files are kept locally on any host of the cluster:
/etc/cmcluster—the directory in which MC/ServiceGuard keeps its configuration files
/home/<SID>adm—the home directory of the SAP R/3 system Administrator.
It is your responsibility to synchronize the contents of these directories on all hosts of the cluster. /home/<SID>adm does not need to be the same on all of the hosts. For example:
It is possible to install an additional application server on a host of the cluster. The application server will not be part of any package. It is local to this host. The SAP startup scripts are only needed on this dedicated host. You do not need to distribute them to other hosts.
The standard HP-UX configuration files are local, too. Never delete the mutual .rhosts entries of the root user and <SID>adm on any of the nodes. Never change entries in /etc/hosts, /etc/services, /etc/passwd or /etc/group on only some of the nodes. Keep them unified.
If you use an ORACLE database, be aware that the listener configuration file of SQL*Net V2 is kept locally as /etc/listener.ora by default, too.
directories that reside on shared disks
Changing these files on any host of the cluster applies the change to the whole cluster.
Files in the following directories and all subdirectories are typically shared:
/usr/sap/<SID>/DVEBMGS<instance_id> /export/usr/sap/trans /export/sapmt/<SID> /export/informix or /oracle/<SID>
They are only available on a host if the package they belong to is running on it. MC/ServiceGuard switches them to another node with the package. If you use a two package concept all directories belong to the database package (db) apart from the first which belongs to the Central Instance package (ci). Please refer to the description of your particular setup to obtain a list of your shared directories.
directories that are treated by the automounter
These directories are mounted automatically as needed. This is true not only for the nodes of the cluster. If you use external application servers, they also use them.
Automounter directories are:
/sapmnt/<SID> /usr/sap/trans /informix
They are NFS-mounted from their equivalents in the /export directory of the node(s) which run(s) the package(s). The automounter setup uses the relocatable IP addresses. The directories are soon available again after a switchover has taken place.
There are two important issues concerning these directories:
- The directories below /export are exported without root permissions.
  This happens according to the recommendations of SAP R/3 and enhances the security of the installation. The effect is, that the root user cannot modify these directories or their contents. With standard permissions set, the root user cannot even see the files. This is not an error and the system runs without problems. If you want to modify anything as root, please use the equivalent directory below /export on the host the package runs on.
- If the database package is halted, you cannot log in as <SID>adm unless you keep the binaries local.
  The reason for this is, that /usr/sap/<SID>/SYS/exe is part of the path of <SID>adm. Without local binaries this directory links to /sapmnt/<SID> which in fact is handled by the automounter. The automounter cannot contact the host belonging to the relocatable address that is configured because the package is down. The system hangs. To avoid this, always keep local copies of the executables.

SAP R/3 Administration Aspects

As far as SAP R/3 is concerned, nearly everything remains the same. The only difference is the use of the relocatable IP-addresses. During installation of the SGeSAP Integration, the profiles are changed to contain only relocatable IP-addresses for the database as well as the Central Instance. You can check this using transaction RZ10. In the DEFAULT.PFL the entries are altered:

SAPDBHOST		= <relocatible_db_name>
rdisp/mshost		= <relocatible_ci_name>
rdisp/vbname		= <relocatible_ci_name>_<SID>_<nr>
rdisp/enqname		= <relocatible_ci_name>_<SID>_<nr>
rdisp/btcname		= <relocatible_ci_name>_<SID>_<nr>
rslg/collect_daemon/host = <relocatible_ci_name>

There are also two additional profile parameters SAPLOCALHOST and SAPLOCALHOSTFULL included as part of the Instance Profile of the Central Instance. Anywhere SAP R/3 uses the local hostname internally, this name is replaced by the relocatable values <relocatible_ci_name> or <relocatible_ci_name>.domain.organization of these parameters. Make sure that they are always defined and set to the correct value. This is vital for the system to function correctly.

Normally use the relocatable name of your Central Instance package if SAP R/3 asks for the hostname of the machine the Central Instance runs on. Unfortunately, SAP R/3 sometimes uses local addresses by itself. If the system is set up correctly as described in Chapter 2, "Chapter 2 “Step by Step Installation Guide”," you do not have to worry about this. The values change if you switch over to another host.

The destination for print formatting, which is done by a Spool Work process, uses the application server name. Use the relocatable name if you plan to use Spool Work processes with your Central Instance. In these cases no changes need to be done in case of a failover - printing will work persistently. Note that a print job in process at the time of the failure will be canceled and needs to be reissued manually after the failover. To make a spooler highly available on the Central Instance, set the destination of the printer to <relocatible_ci_name>_<SID>_<nr> using the transaction SPAD. Print all time critical documents via the high available spool server of the Central Instance. Print requests to other spool servers stay in the system after failure until the host is available again and the spool server has been restarted. These requests can be moved manually to other spool servers if the failed server is unavailable for a longer period of time.

Batch jobs can be scheduled to run on a particular instance. Generally speaking, it is better not to specify a destination host at all. Sticking to this rule, the batch scheduler chooses a batch server which is available at the start time of the batch job. However, if you wish to specify a destination host, specify the batch server running on the highly available Central Instance. The application server name and the hostname (which is retrieved from the Message Server) are stored in the batch control tables TBTCO, TBTCS,.... In case the batch job is ready to run, the application server name is used to start it. Therefor, when using the relocatable name to build the application server name for the SAP R/3 Instance, you do not need to change batch jobs which are tied to it after a switchover. This is true even if the hostname which is also stored in the above tables, differs.

Plan to use saplogon to application server groups instead of saptemu/sapgui to individual application servers. When logging on to an application server group with two or more application servers, the SAP R/3 user does not need a different login procedure if one of the application servers of the group fails. Also, using login groups, provides workload balancing between application servers, too.

Within the CCMS you can define operation modes for SAP R/3 Instances. An operation mode defines a resource configuration. It can be used to determine which instances are started and stopped and how the individual services are allocated for each instance in the configuration. An instance definition for a particular operation mode consists of the number and types of Work processes as well as Start and Instance Profiles. When defining an instance for an operation mode you need to enter the hostname and the system number of the application server. By using relocatable names to fill in the hostname field, the instance will be working under control of the CCMS after a failover without a change. Note however, that if an instance is running on the standby node in normal operation and is stopped during the switchover, the control console will show the instance to be down afterwards.

Only configure the update service on a node for Application Services running on the same node. As a result, the remaining SAP R/3 servers, running on different nodes, are not affected by the outage of the update server. However, if the update server is configured to be responsible for application servers running on different nodes, any failure of the update server leads to subsequent outages at these nodes. Configure the update server on the highly available Central Instance. Using local update servers should only be considered, if performance issues require it.

MC/ServiceGuard Administration Aspects

MC/ServiceGuard keeps information about the cluster configuration, it especially needs to know the relocatable IP addresses and its subnets, your Volume Groups, the Logical Volumes and their mountpoints. Check with your HP consultant for information about the way MC/ServiceGuard is configured to suite your SAP R/3 system. If you touch this configuration, you have to reconfigure your cluster.

SGeSAP Administration Aspects

The SGeSAP needs some additional information about the configuration of your SAP R/3 system. It gathers this information from the file /etc/cmcluster/sap.conf. It is very important that the information in this file is consistent with the way your system is configured. This file must be available on all nodes of the cluster. Under normal operation there is no need to touch this file. But it is a good idea for you as an administrator to have a look at it to prevent you from doing things that can cause the setup to be no longer able to switch. Comments are provided within the file and most things are self-explanatory if you are trained to understand shell scripts. For example, the following administration activities are possible but they must be accompanied by an adaptation of the sap.conf file on all cluster nodes:

changing the SAP System ID
changing the name of the SAP System Administrator
migrating to another database vendor
adding/deleting additional application servers
changing Instance Numbers
changing the name belonging to a relocatable address
changing the name of a SGeSAP-Integration package
changing hostnames of hosts inside the cluster
changing hostnames of hosts that run additional application servers
changing the location of any SAP-specific directory in the filesystem
changing the name of the ORACLE listener

After performing any of the above mentioned activities the ability to failover correctly has to be tested again. Be aware that changing the configuration of your SAP R/3 cluster in any way can lead to the loss of warranty. Always make sure to plan those steps together with your HP consultant.

SGeSAP Administration Issues

Technical documentation

» Table of Contents

» Index

Hardware Aspects

HP-UX Software Aspects

SAP R/3 Administration Aspects

MC/ServiceGuard Administration Aspects

SGeSAP Administration Aspects