luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Merge pull request #10685 from hashicorp/docs-fix-broken-link-swim-article 

Docs fix broken link swim article
This commit is contained in:
trujillo-adam 2021-07-26 11:31:17 -07:00 committed by GitHub
parent a6a907ac25 e84891296c
commit cc40493bd6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
website/content/docs/architecture/gossip.mdx
View File

@ -12,43 +12,43 @@ description: >-
# Gossip Protocol # Gossip Protocol
Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
to manage membership and broadcast messages to the cluster. All of this is provided to manage membership and broadcast messages to the cluster. The protocol, membership management, and message broadcasting is provided
through the use of the [Serf library](https://www.serf.io/). The gossip protocol through the [Serf library](https://www.serf.io/). The gossip protocol
used by Serf is based on used by Serf is based on a modified version of the
["SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol"](http://www.cs.cornell.edu/info/projects/spinglass/public_pdfs/swim.pdf), [SWIM (Scalable Weakly-consistent Infection-style Process Group Membership)](https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf) protocol.
with a few minor adaptations. There are more details about [Serf's protocol here](https://www.serf.io/docs/internals/gossip.html). Refer to the [Serf documentation](https://www.serf.io/docs/internals/gossip.html) for additional information about the gossip protocol.
## Gossip in Consul ## Gossip in Consul
Consul makes use of two different gossip pools. We refer to each pool as the Consul uses a LAN gossip pool and a WAN gossip pool to perform different functions. The pools
LAN or WAN pool respectively. Each datacenter Consul operates in has a LAN gossip pool are able to perform their functions by leveraging an embedded [Serf](https://www.serf.io/)
containing all members of the datacenter, both clients and servers. The LAN pool is library. The library is abstracted and masked by Consul to simplify the user experience,
used for a few purposes. Membership information allows clients to automatically discover but developers may find it useful to understand how the library is leveraged.
servers, reducing the amount of configuration needed. The distributed failure detection
allows the work of failure detection to be shared by the entire cluster instead of
concentrated on a few servers. Lastly, the gossip pool allows for reliable and fast
event broadcasts.
The WAN pool is globally unique, as all servers should participate in the WAN pool ### 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 regardless of datacenter. Membership information provided by the WAN pool allows
servers to perform cross datacenter requests. The integrated failure detection servers to perform cross-datacenter requests. The integrated failure detection
allows Consul to gracefully handle an entire datacenter losing connectivity, or just allows Consul to gracefully handle loss of connectivity--whether the loss is for
a single server in a remote datacenter. an entire datacenter, or a single server in a remote datacenter.
All of these features are provided by leveraging [Serf](https://www.serf.io/). It
is used as an embedded library to provide these features. From a user perspective,
this is not important, since the abstraction should be masked by Consul. It can be useful
however as a developer to understand how this library is leveraged.
## Lifeguard Enhancements ((#lifeguard)) ## Lifeguard Enhancements ((#lifeguard))
SWIM makes the assumption that the local node is healthy in the sense SWIM assumes that the local node is healthy, meaning that soft real-time packet
that soft real-time processing of packets is possible. However, in cases processing is possible. The assumption may be violated, however, if the local node
where the local node is experiencing CPU or network exhaustion this assumption experiences CPU or network exhaustion. In these cases, the `serfHealth` check status
can be violated. The result is that the `serfHealth` check status can can flap. This can result in false monitoring alarms, additional telemetry noise, and
occasionally flap, resulting in false monitoring alarms, adding noise to CPU and network resources being wasted as they attempt to diagnose non-existent failures.
telemetry, and simply causing the overall cluster to waste CPU and network
resources diagnosing a failure that may not truly exist.
Lifeguard completely resolves this issue with novel enhancements to SWIM. Lifeguard completely resolves this issue with novel enhancements to SWIM.