The Group Services subsystem is a system-wide, fault-tolerant, and highly available service that provides a general purpose facility for coordinating and monitoring changes to the state of an application that is running on a set of nodes. Group Services helps both in the design and implementation of fault-tolerant applications, and in the consistent recovery of multiple applications. Group Services accomplishes these two distinct tasks in an integrated framework.
Group Services offers a simple programming model because it is based on a small number of core concepts: it is a cluste-rwide group membership and synchronization service based on the publish/subscribe model, which maintains an application-specific state for each group.
Group Services encapsulates a collection of software abstractions that are commonly used in the design of fault-tolerant systems. Specifically, Group Services provides process groups (simply called groups), state data, barrier synchronization, one-phase protocol, and multi-phase commit.
By using the Group Services abstractions, application developers do not have to develop their own synchronization and commit protocols. This is important because such protocols tend to be complex, error-prone, and expensive to duplicate. Developers who use Group Services interfaces are free to use only those abstractions that are suitable for their application, and do not have to use the entire toolkit. For example, developers of applications that have historically relied on their own methods for fault-tolerance, such as database servers, are free to restrict their use of Group Services interfaces to interapplication coordination services.
The Group Services subsystem supports the following features that enhance its use for interapplication coordination.
Extensibility:
Suppose that a new application is being added to a functioning cluster. The synchronization of this application with respect to other applications can be seamlessly managed by Group Services without disturbing existing applications.
No required operator knowledge:
Using Group Services interfaces, the programmers of each application determine the appropriate degree of synchronization between that application and other applications in the cluster. There is no need for an operator to understand all of the interactions between all of the components, as may be the case with other facilities such as scripts.
Different synchronization at different times:
Group Services allows applications to have different dependencies on each other at different times. For example, these dependencies may change during initialization, recovery, and shutdown.
It is equally important to understand what Group Services is not. Group Services is not intended to replace the current collection of communications libraries and services. Group Services was not designed to provide a high-volume, high-bandwidth, general-purpose messaging facility. Group Services does not perform application recovery; rather, it helps applications orchestrate their own recovery.
If you are writing a new application or are considering updating an existing application, you can use the GSAPI to improve SP system availability in a number of ways. You can use the GSAPI to do the following: