MC/ServiceGuard Architecture

This daemon is used by the ServiceGuard commands and by the SAM interface to gather information from all the nodes within the cluster. It gathers configuration information such as information on networks and volume groups. It also distributes the cluster binary configuration file to all nodes in the cluster. This daemon is started by inetd(1M). There are entries in the /etc/inetd.conf file.

This daemon is used to determine cluster membership by sending heartbeat messages to other cmcld daemons on other nodes within the ServiceGuard cluster. It runs at a real time priority and is locked in memory. The cmcld daemon sets a safety timer in the kernel which is used to detect kernel hangs. If this timer is not reset periodically by cmcld, the kernel will cause a system TOC, that is, a Transfer of Control, which means a CPU reset and the creation of a crash dump file. This could occur because cmcld could not communicate with the majority of the cluster's members, or because cmcld exited unexpectedly, aborted, or was unable to run for a significant amount of time and was unable to update the kernel timer, indicating a kernel hang. Before a TOC due to the expiration of the safety timer, messages will be written to /var/adm/syslog/syslog.log and the kernel's message buffer.

The cmcld daemon also detects the health of the networks on the system and performs local lan failover. Finally, this daemon handles the management of ServiceGuard packages, determining where to run them and when to start them.

	NOTE: The three central components of MC/ServiceGuard—Package Manager, Cluster Manager, and Network Manager—run as parts of the cmcld daemon. This daemon runs at priority 20 on all cluster nodes. It is important that user processes should have a lower priority than 20, otherwise they might prevent MC/ServiceGuard from updating the kernel safety timer, thus causing the node to undergo a TOC.

cmlogd is used by cmcld to write messages to syslog. Any message written to syslog by cmcld it written through cmlogd. This is to prevent any delays in writing to syslog from impacting the timing of cmcld.

This daemon is responsible for keeping track of all the volume group(s) that have been made cluster aware. When a volume group is made cluster aware, a cluster node can only activate it in exclusive mode. This prevents the volume group from being activated in write mode by more than one node at a time.

This daemon is responsible for providing information about the cluster to clients—external products or tools such as ServiceGuard Manager that depend on knowledge of the state of cluster objects. Clients send queries to the object manager and receive responses from it. This daemon may not be running on your system; it is used only by clients of the object manager.

cmomd accepts connections from clients, and examines queries. The queries are decomposed into categories (of classes) which are serviced by various providers. The providers gather data from various sources, including, commonly, the cmclconfd daemons on all connected nodes, returning data to a central assimilation point where it is filtered to meet the needs of the exact client query. This daemon is started by inetd(1M). There are entries in the /etc/inetd.conf file.

This daemon is used by ClusterView to obtain information about the cluster. This daemon produces the Cluster MIB. Details on the cluster MIB can be found on URL http://docs.hp.com/hpux/ha under the Frequently Asked Questions area. This will only be running if the /etc/rc.config.d/cmsnmpagt file has been edited to autostart this subagent. For proper execution, the cmsnmpd has to start before the ServiceGuard cluster comes up.

This daemon forks and execs any script or processes as required by the cluster daemon, cmcld. There are two type of forks that this daemon carries out:

For services, cmcld monitors the service process and, depending on the number of service retries, cmcld either restarts the service through cmsrvassistd or it causes the package to halt and moves the package to an available alternate node.

The shared tape daemon is responsible for keeping track of all the shared tape devices that are part of the cluster. Share tape devices can be configured using the stapplyconf command.

The quorum server daemon provides tie-breaking services when needed during cluster re-formation. The quorum server runs on a system external to the cluster, and it is started by the user, not by ServiceGuard. It is normally started out of /etc/inittab, which means that it automatically re-spawns if it fails or is killed.

All members of the cluster initiate and maintain a connection to the quorum server. If the quorum server dies, the ServiceGuard nodes will detect this and then periodically try to reconnect to the quorum server until it comes back up. If there is a cluster reconfiguration while the quorum server is down and there is a partition in the cluster that requires tie-breaking, the reconfiguration will fail.