SAP R/3 allows a great amount of flexibility in setup and
configuration. The SGeSAP Extension Scripts preserve much of this
flexibility through the use of two integration models:
One Package Configuration Model
Two Package Configuration Model
One-Package Configuration Model |
 |
In a one-package configuration, both the database (DB) and
central instance (CI) run on the same node at all times and are
configured in one MC/ServiceGuard package. Other nodes in the MC/ServiceGuard
cluster function as backups for the primary node (on which the system
runs during normal operation).
If the primary node fails, the database and the central instance
fail over and continue functioning on an adoptive node. The process
of failover results in downtime that can last several minutes, depending
on the work in progress when the failover takes place. The main
portion of this downtime is needed for the recovery of the database.
After failover, the system runs without any manual intervention
needed. The application servers are not part of the cluster but
can either stay up or be restarted during failover.
A sample configuration in Figure 1-1 “One-Package Failover Scenario” shows
node1 with a failure, which causes the package containing
the database and central instance to fail over to node2.
Use the one-package model for all configurations where you
can put the database and central instance on one node and you have
available an equal sized node as a backup. During normal operation,
the backup node can be used as an idle standby, application server,
or test system.
Two-Package Configuration Model |
|
If you are planning to distribute the database and central
instance between two nodes, use the two-package model. The SAP R/3 functionality
is separated into two MC/ServiceGuard packages, one for the database
(DB) and the other for the SAP R/3 central instance (CI). The database
package contains the filesystems for the NFS mount points.
The cluster can be configured so that the two nodes back up
each other, or so that one or more dedicated hosts back up the nodes
running the SAP R/3 packages as illustrated in Figure 1-2 “Two-Package Failover Scenario with
Third Node as Standby”.
If either node1 or node2 fails, the package can fail over to node3. If a failover to a node that is not idle takes place
(for example if node3 were used as an application server), SGeSAP, if requested,
can bring down running instances to free the resources needed to
get the system up.
Under normal conditions, all backup hosts can be used to run
application servers or instances of different test or development
systems, or they can be idle. If needed, additional application
servers inside and outside of the cluster can be restarted automatically.
It is possible to define more than one highly available SAP R/3
system in one cluster.
Printable version
