Consul中文文档—连接证书签名CPU限制

Consul Server 性能 ——Server Performance（下）

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

翻译了Server性能下半部分，主要介绍 连接证书签名CPU限制场景调优。

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

>> 连接证书签名CPU限制（Connect Certificate Signing CPU Limits）

中文翻译

如果启用Connect，则leader服务器将需要对集群中的每个服务实例执行公钥签名操作。通常，这些操作在现代硬件上很快，但是当CA被更改或其密钥轮换时，Leader将面临对每个正在运行的服务实例的更新新证书的大量请求。

虽然Client Agent在30秒内随机分发这些数据，以避免瞬间并发量特别大，但他们没有足够的信息来根据集群中使用的证书数量来调整该时间段，因此选择较长的分发时间会导致小集群人为地减慢循环速度。

超过30秒的分发请求足以使RPC负载达到合理水平，但加密操作产生的额外CPU负载可能会影响服务器的正常工作。为了限制这一点，conver从1.4.1开始公开了两种参数（csr_max_second和csr_max_concurrent）来限制证书签名对Leader 的影响。

默认情况下，我们设置了每秒50个的限制，这在一般的硬件上是合理的，但是如果集群中有超过1500个服务实例使用Connect，那么这个限制可能太低，并且会影响轮换时间。如果可用CPU少于4核，则csr_max_per_second可能是最好的，因为签名使用的整个核心很可能会影响服务器的稳定性（如果全部或大部分可用核心）。缺点是需要进行容量规划：有多少服务实例需要连接证书？在不影响稳定性的情况下，您的服务器能够容忍多大的CSR速率？您希望CA旋转的处理速度如何？

对于较大规模的生产部署，我们通常建议服务器使用多个CPU内核来处理正常的工作负载。如果有四个或更多的内核可用，那么使用csr_max_concurrent来限制签名CPU的影响比调整速率限制更简单。这有效地设置了证书签名工作可以独占多少个CPU内核（尽管它不将其固定到特定的内核上）。在这种情况下，应禁用csr_max_per_second（设置为0）。

例如，如果有一个8核服务器，那么将csr_max_concurrent设置为1将允许您以单核的速度处理csr（这对于非常大的集群来说可能足够了），而不会消耗所有可用的CPU内核，也不会影响服务器的正常工作或稳定性。

英文原文

If you enable Connect, the leader server will need to perform public key signing operations for every service instance in the cluster. Typically these operations are fast on modern hardware, however when the CA is changed or its key rotated, the leader will face an influx of requests for new certificates for every service instance running.

While the client agents distribute these randomly over 30 seconds to avoid an immediate thundering herd, they don’t have enough information to tune that period based on the number of certificates in use in the cluster so picking longer smearing results in artificially slow rotations for small clusters.

Smearing requests over 30s is sufficient to bring RPC load to a reasonable level in all but the very largest clusters, but the extra CPU load from cryptographic operations could impact the server’s normal work. To limit that, Consul since 1.4.1 exposes two ways to limit the impact Certificate signing has on the leader csr_max_per_second and csr_max_concurrent.

By default we set a limit of 50 per second which is reasonable on modest hardware but may be too low and impact rotation times if more than 1500 service instances are using Connect in the cluster. csr_max_per_second is likely best if you have fewer than four cores available since a whole core being used by signing is likely to impact the server stability if it’s all or a large portion of the cores available. The downside is that you need to capacity plan: how many service instances will need Connect certificates? What CSR rate can your server tolerate without impacting stability? How fast do you want CA rotations to process?

For larger production deployments, we generally recommend multiple CPU cores for servers to handle the normal workload. With four or more cores available, it’s simpler to limit signing CPU impact with csr_max_concurrent rather than tune the rate limit. This effectively sets how many CPU cores can be monopolized by certificate signing work (although it doesn’t pin that work to specific cores). In this case csr_max_per_second should be disabled (set to 0).

For example if you have an 8 core server, setting csr_max_concurrent to 1 would allow you to process CSRs as fast as a single core can (which is likely sufficient for the very large clusters), without consuming all available CPU cores and impacting normal server work or stability.