Consul
  • Consul中文文档
  • Consul介绍
    • Consul与其他软件对比
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
      • Consul by HashiCorp
  • Consul 架构
    • 反熵
    • 共识协议
    • Gossip协议
    • Japsen测试
    • 网络候选人
  • Consul安全模型
    • 访问控制(ACLs)
      • ACL系统
      • ACL规则
      • ACL Auth Methods组件
    • 加密
  • 服务网格
  • 开始使用
    • 启用数据中心
由 GitBook 提供支持
在本页
  • »Gossip in Consul
  • »Lifeguard Enhancements

这有帮助吗?

  1. Consul 架构

Gossip协议

上一页共识协议下一页Japsen测试

最后更新于4年前

这有帮助吗?

Consul uses a to manage membership and broadcast messages to the cluster. All of this is provided through the use of the . The gossip protocol used by Serf is based on , with a few minor adaptations. There are more details about .

Gossip in Consul

Consul makes use of two different gossip pools. We refer to each pool as the LAN or WAN pool respectively. Each datacenter Consul operates in has a LAN gossip pool containing all members of the datacenter, both clients and servers. The LAN pool is used for a few purposes. Membership information allows clients to automatically discover 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 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 an entire datacenter losing connectivity, or just a single server in a remote datacenter.

All of these features are provided by leveraging . 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

SWIM makes the assumption that the local node is healthy in the sense that soft real-time processing of packets is possible. However, in cases where the local node is experiencing CPU or network exhaustion this assumption can be violated. The result is that the serfHealth check status can occasionally flap, resulting in false monitoring alarms, adding noise to 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.

For more details about Lifeguard, please see the blog post, which provides a high level overview of the HashiCorp Research paper . The also provides some lower-level details about the gossip protocol and Lifeguard.

gossip protocol
Serf library
"SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol"
Serf's protocol here
Serf
Making Gossip More Robust with Lifeguard
Lifeguard : SWIM-ing with Situational Awareness
Serf gossip protocol guide
»
»