Consul中文文档—如何合理设置Consul节点规格？

本篇文章翻译自： https://www.consul.io/docs/install/performance

翻译了服务器性能的前半部分，主要是介绍Consul读、写能力的限制因素，以及生产环境如何根据负载情况， 合理地部署Consul集群。

转载请注明🙂，喜欢请一键三连哦😊

由于Consul使用 共识协议 来处理所有的 写操作 和关联了几乎所有的 读操作， 所以服务器性能对于Consul吞吐量和运行状况至关重要。Consul 的 写操作 通常受操作的I/O的约束， 因为每次添加Entry时，底层的Raft日志存储区都会执行与磁盘的操作的同步。Consul 读操作 受 限制于CPU,因为读取工作是针对完全并发访问进行了优化的完全内存数据存储进行的。

最小服务规格需求

在consul0.7中，对默认的服务器性能参数进行了调整，使Consul能够在由三个AWS t2.micro(6核1g)实例组成的服务器集群上可靠地运行（但速度相对较慢）。这些阈值是根据经验确定的，使用一个leader实例，该实例处于足够的读、写和网络负载下，导致其永久地处于零CPU，从而迫使它进入该实例类型的基准性能模式。

通常情况下，这是一个比较保守的调整策略。

这个默认值是根据用户的反馈选择的，他们中的许多人希望使用低成本的计算资源运行小型生产或开发集群，来节省成本，从而牺牲了在Leader失败检测和Leader选举时间方面的一些性能。

默认性能配置相当于：

{
  "performance": {
    "raft_multiplier": 5
  }
}

生产环境Server规格选择

在生产环境中运行Consul0.7及更高版本时，建议将服务器性能参数配置回Consul最初的高性能设置。比起默认配置， 这将使Consul Server更快的检测到Leader故障，并比更快地完成Leader选举，默认配置Raft的超时时间延长了5倍，因此在这侦测失败和Leader选举期间十分缓慢;

高性能的配置如下：（PS : 1-10，默认为5， 理论越小性能越高，侦测失败更快，选举更快，但是需要根据实际场景权衡）

{
  "performance": {
    "raft_multiplier": 1
  }
}

该值必须考虑服务器之间的网络延迟以及服务器上的读/写负载。

raft_multiplier 是一个比例因子并且能直接的影响接下面这些参数:

Param	Value
HeartbeatTimeout	1000ms	default
ElectionTimeout	1000ms	default
LeaderLeaseTimeout	500ms	default

默认Consul 用一个比例因子是5， 5的结果是下面这些值：

Param	Value	Calculation
HeartbeatTimeout	5000ms	5 x 1000ms
ElectionTimeout	5000ms	5 x 1000ms
LeaderLeaseTimeout	2500ms	5 x 500ms

注意： 具有延迟高的广域网将在raft_multiplier值较大时表现更好。

在Leader稳定性和从实际Leader失败中恢复的时间之间进行权衡。较小的系数可以最大限度地减少故障检测和选主时间，但在高延迟情况下可能会频繁触发。这可能导致持续的Leader变动和相关的不可用。高系数可以减少虚假故障导致Leader流失的可能性，但这样做的代价是检测实际故障所需的时间更长，从而恢复群集可用性需要更长的时间。

Leader的不稳定也可能是由CPU资源不足引起的，在CPU周期与其他工作负载共享的环境中更可能出现这种情况。为了Consul Server保持Leader地位，它必须每隔几百毫秒向所有其他Server Node发送频繁的心跳消息。如果由于Leader没有足够的CPU按时发送这些心跳信息而导致其中一些丢失或延迟，其他Server Node将检测到失败，并举行新的选举。

PS: 下面的建议中，会涉及到 Consul的一致性模型，对Consul 三种一致性模型还不了解的同学请参考：Consul 反熵机制）

在为Consul选择生产服务器时，最好使用实际的工作负载进行基准测试。以下是一些一般性建议：

• Consul将使用多个核心，建议至少使用2个核心;

• 虚假的Leader 选举可能是由服务器之间的网络问题或CPU资源不足引起的。云环境中的用户可以选择升级网络和CPU规格，直到Leader选举稳定下来。 除了提升硬件规格， 在Consul0.7或更高版本中，提供了性能参数配置方便我们对性能进行调优。你可以使用consul.raft.leader.lastContact 指标，观察Raft协议（发送心跳）的执行情况，并指导决定是否调整Raft性能或添加更强大的服务器。

• 对于DNS繁重的工作负载，使用allow-stale配置选项配置允许集群中所有的Server都可以直接响应读请求，而不仅仅是Leader Node。concul 0.7及更高版本默认启用DNS的过时读取。有关详细信息，请参阅《DNS缓存指南》中的“过时读取”。如果用户比较关注过时时长指标，那么设置合理的非零 DNS TTL values值也是很好的。

• 在其他针对Consul执行大量读取的应用程序中，请考虑使用可用的过时一致性模式，允许所有Server都可以响应读请求，而不仅仅是转发给Leader。

• 在Consul0.9.3及更高版本中，Consul Client模式上有一个新的limits参数配置，可以限制它们对Consul服务器的RPC请求速率。在达到限制之后，请求将开始返回速率限制错误，直到时间过去并且允许更多的请求。在整个集群中配置此项，实现限流功能，防止超出Server最大接收能力。

内存需求

Consul Server Agent对 KV，Catalog，查询， ACL以及Session的等一些列数据集操作是在内存中进行的, 这些数据的快照和自上一次快照对比，产生的更改以日志的形式通过Raft协议持久化到磁盘上。

当设计内存需求时，通常应该为服务器代理分配足够的RAM，以包含工作集大小的2到4倍。您可以通过consul.runtime.alloc_bytes指标来确定工作集大小；

注意：Consul并不是作为一个通用数据库设计的，在选择要填充到key/value存储中的数据时，应该记住这一点。

Server Performance

---

Since Consul servers run a consensus protocol to process all write operations and are contacted on nearly all read operations, server performance is critical for overall throughput and health of a Consul cluster. Servers are generally I/O bound for writes because the underlying Raft log store performs a sync to disk every time an entry is appended. Servers are generally CPU bound for reads since reads work from a fully in-memory data store that is optimized for concurrent access.

Minimum Server Requirements

In Consul 0.7, the default server performance parameters were tuned to allow Consul to run reliably (but relatively slowly) on a server cluster of three AWS t2.micro instances. These thresholds were determined empirically using a leader instance that was under sufficient read, write, and network load to cause it to permanently be at zero CPU credits, forcing it to the baseline performance mode for that instance type. Real-world workloads typically have more bursts of activity, so this is a conservative and pessimistic tuning strategy.

This default was chosen based on feedback from users, many of whom wanted a low cost way to run small production or development clusters with low cost compute resources, at the expense of some performance in leader failure detection and leader election times.

The default performance configuration is equivalent to this:

{
  "performance": {
    "raft_multiplier": 5
  }
}

Production Server Requirements

When running Consul 0.7 and later in production, it is recommended to configure the server performance parameters back to Consul’s original high-performance settings. This will let Consul servers detect a failed leader and complete leader elections much more quickly than the default configuration which extends key Raft timeouts by a factor of 5, so it can be quite slow during these events.

The high performance configuration is simple and looks like this:

{
  "performance": {
    "raft_multiplier": 1
  }
}

This value must take into account the network latency between the servers and the read/write load on the servers.

The value of raft_multiplier is a scaling factor and directly affects the following parameters:

Param	Value
HeartbeatTimeout	1000ms	default
ElectionTimeout	1000ms	default
LeaderLeaseTimeout	500ms	default

By default, Consul uses a scaling factor of 5 (i.e. raft_multiplier: 5), which results in the following values:

Param	Value	Calculation
HeartbeatTimeout	5000ms	5 x 1000ms
ElectionTimeout	5000ms	5 x 1000ms
LeaderLeaseTimeout	2500ms	5 x 500ms

NOTE Wide networks with more latency will perform better with larger values of raft_multiplier.

Memory Requirements

Consul server agents operate on a working set of data comprised of key/value entries, the service catalog, prepared queries, access control lists, and sessions in memory. These data are persisted through Raft to disk in the form of a snapshot and log of changes since the previous snapshot for durability.

When planning for memory requirements, you should typically allocate enough RAM for your server agents to contain between 2 to 4 times the working set size. You can determine the working set size by noting the value of consul.runtime.alloc_bytes in the Telemetry data.

NOTE: Consul is not designed to serve as a general purpose database, and you should keep this in mind when choosing what data are populated to the key/value store.z

参考文档

1. Server Performance
2. Consul中文文档—Consul是如何维护服务和健康信息的？（Consul Anti-Entropy机制）