Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Managing MC/ServiceGuard Extension for SAP R/3: > Chapter 1 Understanding MC/ServiceGuard Extension for SAP

Application Servers

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

The database and the SAP R/3 central instance are always running on nodes that are protected by MC/ServiceGuard. This is different for systems that have the enqueue service, SAP R/3's central lock handling server process, protected by HP Somersault (B8438). Refer to “SGeSAP and HP Somersault” for additional information.

Other SAP R/3 services can be run on HP-UX application server hosts. These hosts do not need to be part of the MC/ServiceGuard cluster. Even if the additional SAP R/3 services are run on nodes in the MC/ServiceGuard cluster, they are not protected by MC/ServiceGuard. A combination of Windows NT/HP-UX application servers is technically possible but additional software is required to access HP-UX filesystems or HP-UX-like remote shells from the Windows NT system.

All application servers different from the central instance are called additional application servers. An additional application server that runs on a cluster node is called an internal application server. External application servers run on HP-UX- or Windows NT-hosts that are not part of the cluster. Even if application servers are external to the cluster, they are affected by package startup and shutdown.

Run the SAP R/3 services dialog, update, batch, spool, and gateway, on additional application servers. Do not run the message or enqueue services on additional application servers. Set up one message server and one enqueue server for each SAP R/3 system.

The message server, enqueue server, database and NFS server are all single points of failure (SPOF). To maintain high availability, all these SPOFs for the SAP R/3 system must be eliminated by configuring them in MC/ServiceGuard cluster nodes.

In standard SAP R/3 scenarios the SPOFs database, NFS, message and enqueue server are all protected. It is highly recommended that you also protect at least one instance of each additional SAP R/3 service in the MC/ServiceGuard cluster.

For all application server nodes outside the MC/ServiceGuard cluster, consider the following for each of the SAP R/3 services:

  • Dialog—Logon using saplogon for an application server groups instead of saptemu/sapgui for each individual application server. When logging on to an application server group with two or more application servers, you not need a different login procedure even if one of the application servers of the group fails. Also, using login groups provides workload balancing between application servers.

  • Update—Configure an update service on a node only for application services running on the same node. This ensures that the remaining SAP R/3 servers, running on different nodes, are affected if an outage occurs on 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 will lead to subsequent outages at these nodes. Configuring the update service on the high available central instance is recommended. Consider using local update servers only if performance issues require it.

  • Batch—Do not specify a destination host when defining a batch job. This allows the batch scheduler to choose a batch server that is available at the start time of the batch job. If you must specify a destination host, specify the batch server running on the highly available central instance.

  • Spool—Print requests stay in the system until the node is available again and the spool server has been restarted. These requests could be moved manually to other spool servers if one spool server is unavailable for a long period of time. An alternative is to print all time critical documents through the highly available spool server of the central instance.

  • Gateway—You don't have to worry about the gateway processes gwrd and gwwr with SAP R/3 3.0 or higher. Do not confuse this with the SNA gateway.

SGeSAP monitors the hardware within the cluster (CPU, Network cards, etc), but it does not monitor the health of the SAP R/3 processes or the database. This means that MC/ServiceGuard will not switch the packages to another node if you have problems with SAP R/3 or the database.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.