C H A P T E R 5 |
This chapter describes how the CLM API indicates changes in the state of the cluster by sending notifications to system services and applications.
Notifications are information messages sent by the nhcmmd daemon on a node to services or applications registered to receive them. Notifications are sent when there is a change in the membership of the cluster.
Cluster notifications enable a service or application to maintain an accurate view of the state of the cluster and of the state of any peer node. An application or service can use notifications to coordinate changes in system services when a peer node joins or leaves the cluster.
To verify that the nhcmmd daemon is running on your peer nodes, see the Netra High Availability Suite 3.0 1/08 Foundation Services Cluster Administration Guide. For information about the nhcmmd daemon, see the nhcmmd1M (Solaris) or nhcmmd8(Linux) man page.
Applications that you write can register a callback function to handle notification messages. The callback function SaClmClusterTrackCallbackT must be used and is registered during the library initialization. Notification tracking is started by calling the function saClmClusterTrack() with either the SA_TRACK_CHANGES or SA_TRACK_CHANGES_ONLY flag. The first flag requires notification including information about all the cluster members, including those that left the cluster after the last notification. The second flag asks for notifications including information about only the nodes that suffered any change. The flags are mutually exclusive.The callback function receives the following three parameters.
The notification buffer has the following members.
Each element of the notification array is of the structure type SaClmClusterNotification with the following fields.
Fields | Description |
---|---|
clusterNode | A structure with node information as described in Using the saClmClusterNodeT Structure for Information About Cluster Nodes. |
clusterChange | The change in the cluster membership related to the node in clusterNode. |
Nodes can be changed as follows:
The following example presents a simple application showing all the notifications received:
In this example, the selection object is not used to poll for data. Instead, saClmDispatch() is called with the flag SA_DISPATCH_BLOCKING. Any thread calling saClmDispatch() with this flag remains within dispatch and executes the callbacks as they become pending. The thread does not return until the corresponding saClmFinalize() function is executed by another thread. Because this example has no other thread, this situation would require you to kill the process.Applications that are configured to keep track of the cluster's state must rely on the notifications. To initially get the state of the cluster, the track function must be called with the SA_DISPATCH_CURRENT flag. However, between both calls, some notification could be missed. To avoid this, combine both flags in the same call to the track function.
Copyright © 2008, Sun Microsystems, Inc. All rights reserved.