| The topics we have discussed this far are not tied to a particular application. HP does supply versions of Serviceguard that are intrinsically linked to a particular application. Currently, they include: -
Serviceguard Extensions for Oracle Real Application Clusters (RAC) : High availability clusters configured with Oracle Real Application Cluster software are known as RAC clusters. RAC on HP-UX lets you maintain a single database image that is accessed by the HP 9000 servers in parallel, thereby gaining added processing power without the need to administer separate databases. Further, when properly configured, the Serviceguard Extension for RAC provides a highly available database that continues to operate even if one hardware component should fail. In RAC clusters, you create packages to start and stop RAC itself as well as to run applications that access the database instances. Serviceguard provides the cluster framework for Oracle, a relational database product in which multiple database instances run on different cluster nodes. A central component of Real Application Clusters is the distributed lock manager (DLM), which provides parallel cache management for database instances. Each node in a RAC cluster starts an instance of the DLM process when the node joins the cluster, and the instances then communicate with each other over the network. The DLM is an internal component of the Real Application Clusters software. The group membership service (GMS) is the means by which Oracle instances communicate with the Serviceguard cluster software. GMS runs as a separate daemon process that communicates with the cluster manager. This daemon is an HP component known as cmgmsd . The cluster manager starts up, monitors , and shuts down the GMS daemon. When an Oracle instance starts, the instance registers itself with GMS; thereafter, if an Oracle instance fails, GMS notifies other cluster nodes to perform recovery. If GMS dies unexpectedly, Serviceguard will fail the node with a TOC (Transfer of Control). -
Serviceguard extension for SAP : The HP Serviceguard Extension for SAP R/3 (SGeSAP) extends Serviceguard's powerful failover capabilities to SAP R/3 environments. It continuously monitors the health of each SAP R/3 node and automatically responds to failures or threshold violations. It can also minimize planned downtime when performing SAP R/3 upgrades. Serviceguard protects the SAP R/3 central instance and database by defining them in Serviceguard packages. 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 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 Serviceguard package. Other nodes in the 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 with no manual intervention needed. The application servers are not part of the cluster but either can stay up or be restarted during failover. -
- 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 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. 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. |
