Heartbeat (computing)

In computer science, a heartbeat is a periodic signal generated by hardware or software to indicate normal operation or to synchronize other parts of a computer system.[1][2] Heartbeat mechanism is one of the common techniques in mission critical systems for providing high availability and fault tolerance of network services by detecting the network or systems failures of nodes or daemons which belongs to a network cluster—administered by a master server—for the purpose of automatic adaptation and rebalancing of the system by using the remaining redundant nodes on the cluster to take over the load of failed nodes for providing constant services.[3][1] Usually a heartbeat is sent between machines at a regular interval in the order of seconds; a heartbeat message.[4] If the endpoint does not receive a heartbeat for a time—usually a few heartbeat intervals—the machine that should have sent the heartbeat is assumed to have failed.[5] Heartbeat messages are typically sent non-stop on a periodic or recurring basis from the originator's start-up until the originator's shutdown. When the destination identifies a lack of heartbeat messages during an anticipated arrival period, the destination may determine that the originator has failed, shutdown, or is generally no longer available.

Heartbeat protocol

A heartbeat protocol is generally used to negotiate and monitor the availability of a resource, such as a floating IP address, and the procedure involves sending network packets to all the nodes in the cluster to verify its reachability.[3] Typically when a heartbeat starts on a machine, it will perform an election process with other machines on the heartbeat network to determine which machine, if any, owns the resource. On heartbeat networks of more than two machines, it is important to take into account partitioning, where two halves of the network could be functioning but not able to communicate with each other. In a situation such as this, it is important that the resource is only owned by one machine, not one machine in each partition.

As a heartbeat is intended to be used to indicate the health of a machine, it is important that the heartbeat protocol and the transport that it runs on are as reliable as possible. Causing a failover because of a false alarm may, depending on the resource, be highly undesirable. It is also important to react quickly to an actual failure, further signifying the reliability of the heartbeat messages. For this reason, it is often desirable to have a heartbeat running over more than one transport; for instance, an Ethernet segment using UDP/IP, and a serial link.

A "cluster membership" of a node is a property of network reachability: if the master can communicate with the node , it's considered a member of the cluster and "dead" otherwise.[6] A heartbeat program as a whole consist of various subsystems:[7]

  • Heartbeat Subsystem (HS): The subsystem that monitors the node's presence within the cluster through a series of keepalive or "hear-beat messages".
  • Cluster Manager (CM): The subsystem within the cluster—usually the master server—which keeps track of the "cluster members" and records which resources are on which nodes.
  • Cluster Transition (CT): When a node joins or leaves the cluster, this subsystem is responsible for keeping track of such occurrences for the purpose of triggering events to rebalancing and reconfiguring the master to distribute the load.

Heartbeat messages are sent in a periodic manner through techniques such as broadcast or multicasts in larger clusters.[6] Since CMs have transactions across the cluster, the most common pattern is to send heartbeat messages to all the nodes and "await" responses in non-blocking fashion.[8] Since the heartbeat or keepalive messages are the overwhelming majority of non-application related cluster control messages—which also goes to all the members of the cluster—major critical systems also include non-IP protocols like serial ports to deliver heartbeats.[9]

Design and implementation

Every CM on the master server maintains a finite-state machine with three states for each node it administers: Down, Init, and Alive.[10] Whenever a new node joins, the CM changes the state of the node from Down to Init and broadcasts a "boot-up message", which the node receives the executes set of start-up procedures. It then responses with an acknowledgment message, CM then includes the node as the member of the cluster and transitions the state of the node from Init to Alive. Every node in the Alive state would receive a periodic broadcast heartbeat message from the HS subsystem and expects an acknowledgment message back within a timeout range. If CM didn't receive an acknowledgment heartbeat message back, the node is considered unavailable, and a state transition from Alive to Down takes place for that node by CM.[11] The procedures or scripts to run, and actions to take between each state transition is an implementation detail of the system.

Heartbeat network

Heartbeat network is a private network which is shared only by the nodes in the cluster, and is not accessible from outside the cluster. It is used by cluster nodes in order to monitor each node's status and communicate with each other messages necessary for maintaining the operation of the cluster. The heartbeat method uses the FIFO nature of the signals sent across the network. By making sure that all messages have been received, the system ensures that events can be properly ordered.[12]

In this communications protocol every node sends back a message in a given interval, say delta, in effect confirming that it is alive and has a heartbeat. These messages are viewed as control messages that help determine that the network includes no delayed messages. A receiver node called a "sync", maintains an ordered list of the received messages. Once a message with a timestamp later than the given marked time is received from every node, the system determines that all messages have been received since the FIFO property ensures that the messages are ordered.[13]

In general, it is difficult to select a delta that is optimal for all applications. If delta is too small, it requires too much overhead and if it is large it results in performance degradation as everything waits for the next heartbeat signal.[14]

See also

Notes
  1. Hou & Huang 2003, p. 1.
  2. "Definition of Heartbeat". pcmag.com Encyclopedia. Retrieved 7 October 2020.
  3. Robertson 2000, p. 1.
  4. US 4710926, Donald W. Brown, James W. Leth, James E. Vandendorpe, "Fault recovery in a distributed processing system", published 1987-12-01
  5. Kawazoe Aguilera, Marcos; Chen, Wei; Toueg, Sam (1997). "Heartbeat: A timeout-free failure detector for quiescent reliable communication" (PDF). Distributed Algorithms. Berlin, Heidelberg: Springer Berlin Heidelberg. pp. 126–140. doi:10.1007/bfb0030680. hdl:1813/7286. ISBN 978-3-540-63575-8. ISSN 0302-9743.
  6. Robertson 2000, p. 2.
  7. Robertson 2000, p. 1-2.
  8. Robertson 2000, p. 2-3.
  9. Robertson 2000, p. 5.
  10. Li, Yu & Wu 2009, p. 2.
  11. Li, Yu & Wu 2009, p. 2-3.
  12. Nikoletseas 2011, p. 304.
  13. Nikoletseas 2011, p. 304-305.
  14. Nikoletseas 2011, p. 306.

References
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.