github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
20416 Commits
1702 Branches
457 Tags
697 MiB
 
 
 
 
 
 
Tree: 13eefbb840
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '13eefbb840'
${ noResults }
consul/website/content/docs/architecture/gossip.mdx

56 lines
3.1 KiB
Raw Blame History

---
layout: docs
page_title: Gossip Protocol | Serf
description: >-
Consul agents manage membership in datacenters and WAN federations using the Serf protocol. Learn about the differences between LAN and WAN gossip pools and how `serfHealth` affects health checks.
---
# Gossip Protocol
Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
to manage membership and broadcast messages to the cluster. The protocol, membership management, and message broadcasting is provided
through the [Serf library](https://www.serf.io/). The gossip protocol
used by Serf is based on a modified version of the
[SWIM (Scalable Weakly-consistent Infection-style Process Group Membership)](https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf) protocol.
Refer to the [Serf documentation](https://www.serf.io/docs/internals/gossip.html) for additional information about the gossip protocol.
## Gossip in Consul
Consul uses a LAN gossip pool and a WAN gossip pool to perform different functions. The pools
are able to perform their functions by leveraging an embedded [Serf](https://www.serf.io/)
library. The library is abstracted and masked by Consul to simplify the user experience,
but developers may find it useful to understand how the library is leveraged.
### LAN Gossip Pool
Each datacenter that Consul operates in has a LAN gossip pool containing all members
of the datacenter (clients _and_ servers). Membership information provided by the
LAN pool allows clients to automatically discover servers, reducing the amount of
configuration needed. Failure detection is also distributed and shared by the entire cluster,
instead of concentrated on a few servers. Lastly, the gossip pool allows for fast and
reliable event broadcasts.
### WAN Gossip Pool
The WAN pool is globally unique. All servers should participate in the WAN pool,
regardless of datacenter. Membership information provided by the WAN pool allows
servers to perform cross-datacenter requests. The integrated failure detection
allows Consul to gracefully handle loss of connectivity--whether the loss is for
an entire datacenter, or a single server in a remote datacenter.
## Lifeguard Enhancements ((#lifeguard))
SWIM assumes that the local node is healthy, meaning that soft real-time packet
processing is possible. The assumption may be violated, however, if the local node
experiences CPU or network exhaustion. In these cases, the `serfHealth` check status
can flap. This can result in false monitoring alarms, additional telemetry noise, and
CPU and network resources being wasted as they attempt to diagnose non-existent failures.
Lifeguard completely resolves this issue with novel enhancements to SWIM.
For more details about Lifeguard, please see the
[Making Gossip More Robust with Lifeguard](https://www.hashicorp.com/blog/making-gossip-more-robust-with-lifeguard/)
blog post, which provides a high level overview of the HashiCorp Research paper
[Lifeguard : SWIM-ing with Situational Awareness](https://arxiv.org/abs/1707.00788). The
[Serf gossip protocol guide](https://www.serf.io/docs/internals/gossip.html#lifeguard)
also provides some lower-level details about the gossip protocol and Lifeguard.