Description of the Group Membership Service. More...
Description of the Group Membership Service.
Description of the Group Management Service.
CLM Service manages the membership of the cluster with specified cluster configuration, for the nodes that are administratively configured to be part of it. It provides a consistent view of the cluster across all nodes of the cluster.
A node must be member of the cluster to host high availability applications on it. CLM Service allows a node to be a member of a cluster only if the node is healthy and is well-connected to the cluster.
When ASP is started, Component Manager (CPM) sends a request to GMS for the membership of the node for the cluster. GMS processes the request and decides upon the membership of the node. It also elects a leader and a deputy node for the cluster based on the leadership credentials and the node ID of the member nodes. If the cluster join from CPM followed by the leader election are successful, GMS provides a track notification to the registered members with the view of the cluster along with the leader and deputy information. CPM being one of the registered users for cluster track, it gets the above said notification from GMS after a successful join.
An application can register for track notifications with GMS using the clGmsClusterTrack() APIs. After registration, GMS notifies the application for any changes in the cluster membership such as when a node joins, leaves the cluster or a node is reconfigured. The application continues to receive such notifications until it invokes the clGmsClusterTrackStop() API.
GMS provides the following functions for the clustering service:
Note: In the ASP framework, joining or leaving a cluster is generally managed by CPM. The applications should not clGmsClusterJoin() and clGmsClusterLeave() IPIs as it would lead to incosistent state of the cluster.
GMS generalizes the CLM Service by allowing a set of applications or processes in the cluster to form a group and manage such groups. This service, referred to as the Process Group Service, also allows user to track the group by providing a consistent view of the group and notifies about the changes in the membership of the group.
The Process Group Service provides the following functionalities:
The main objective of CLM service is to provide high availability of services in co-ordination with AMF and CPM. These ASP services register with GMS for track notification on the cluster. So at any given time, AMF running on each node is aware of the leader (or master System Controller node) in the cluster.
If the master System Controller node is terminated, GMS instance informs all the nodes and applications through the track notifications. Based on this information, AMF makes the standby System Controller as Active. The other applications like Checkpointing Server can take necessary actions to move their Checkpoint Master Server on the newly active System Controller node.
The main objective of Process Group Service is to allow a set of processes, implementing a distributed component, service, or application to form a group in order to share data or to co-ordinate access to shared resources. Generally these processes are multiple instances of the same code running on different nodes.
For example, a Name Service (NS) implementation will depend on a local NS daemon running on every node in a system. An NS entry created by an application on a node is registered with the local NS daemon. The other nodes can view this entry by allowing the NS daemons to form a group and using group communication to disseminate information among them.
This can be achieved in two possible ways. Both the solutions require that the current group view is available to all members.
GMS depends on CPM for component management and uses RMD infrastructure between the GMS client and the server instances. Also it uses the event service to find out if any of the components that are member of the group goes down. This component death event is given by CMP service, and GMS would remove this member from all the groups of which it was member.
GMS provides a set of the configurable parameters. You can configure the values of these parameters through the clGmsConfig.xml file located in the $ASP_CONFIG directory.
clusterName: Name of the cluster being formed.
linkName: Name of the IP network interface of the machine on which GMS instance will bind.
multicastAddress: Multicast IP address to which GMS Server binds and exchanges its information (such as handshake messages with other GMS instances in the cluster).
multicastPort: Port number to be used to bind for the multicast socket. This socket is used along with the MulticastAddress to exchange internal information with other GMS instances in the cluster.
maxNoOfGroups: Maximum number of process groups allowed to be formed in a cluster.
openAisLoggingOption: This options controls the log output from OpenAis software used by GMS. This tag can take the value 'file', 'stderr', 'syslog' and 'none'. The default value is 'none'. Note that this option is useful while debugging issues with GMS. Also note that, if the option is 'syslog', then local5 channel is used. So user needs to configure this channel in syslog.conf. And if the option is set to 'file', then a log file with name 'OpenAis.log' under $ASP_LOGDIR directory.
Note 1: In order for the GMS to work properly, the values of MulticastAddress and the MulticastPortT parameters should be identical on all the nodes that are part of the same cluster.
Note 2: GMS runs on top of IP multicast. It uses the multicast address and the multicast port number specified in the configuration given above and forms a multicast group. This way it know when a new member joins a group and leaves a group. Please note that multicast has certain dependencies such as the firewall should be disabled on the machine using "iptables -F" command, etc.