Hardware recommendations
管理etcd集群的硬件指南
Etcd通常在开发或测试目的的有限资源下运行良好;在笔记本电脑或便宜的云机器上使用etcd进行开发是很常见的。然而,当在生产中运行etcd集群时,一些硬件指南对于适当的管理是有用的。这些建议并不是硬性规定;它们是健壮的生产部署的良好起点。与往常一样,部署在生产中运行之前应该使用模拟工作负载进行测试
CPUs
很少etcd部署需要大量的CPU容量。典型的集群需要2到4个内核才能平稳运行。负载重的etcd部署(每秒服务数千个客户机或数万个请求)往往受CPU限制,因为etcd可以从内存为请求服务。这种重型部署通常需要8到16个专用内核
内存
Etcd占用的内存相对较小,但它的性能仍然取决于有足够的内存。etcd服务器将积极地缓存键值数据,并将剩余的大部分内存用于跟踪监视程序。通常8GB就足够了。对于拥有数千个观察者和数百万个keys的重型部署,相应地分配16GB到64GB内存。
磁盘
快速磁盘是etcd部署性能和稳定性的最关键因素。
缓慢的磁盘将增加etcd请求延迟,并可能损害集群的稳定性。由于etcd的共识协议依赖于持久地将元数据存储到日志中,所以大多数etcd集群成员必须将每个请求写入磁盘。此外,etcd还将增量地将其状态写入到磁盘,以便截断此日志。如果这些写入花费的时间太长,心跳可能会超时并触发选举,从而破坏集群的稳定性。通常,要判断一个磁盘是否足够快,可以使用基准测试工具,如fio(https://github.com/axboe/fio)。阅读这里的例子(https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd)。
Etcd对磁盘写延迟非常敏感。通常需要50个连续IOPS(例如,7200 RPM的磁盘)。对于负载较大的集群,推荐使用500个顺序IOPS(例如典型的本地SSD或高性能的虚拟化块设备)。请注意,大多数云提供商发布的是并发IOPS而不是顺序IOPS;发布的并发IOPS可以大于顺序IOPS 10倍。为了测量实际的顺序IOPS,我们建议使用磁盘基准测试工具,如diskbench(https://github.com/ongardie/diskbenchmark)或fio。
Etcd只需要适当的磁盘带宽,但是当失败的成员必须赶上集群时,更多的磁盘带宽可以换取更快的恢复时间。通常10MB/s可以在15秒内恢复100MB的数据。对于大型集群,建议在15秒内恢复1GB数据的速度为100MB/s或更高。
如果可能,使用SSD作为etcd的存储。SSD通常提供比机械磁盘更低的写延迟和更小的变化,从而提高了etcd的稳定性和可靠性。如果使用机械磁盘,请尽可能使用最快的磁盘(15,000 RPM)。对于机械磁盘和SSD,使用RAID 0也是一种提高磁盘速度的有效方式。对于至少三个集群成员,不需要RAID的镜像和/或奇偶校验变体;Etcd的一致性复制已经获得了高可用性
网络
多成员etcd部署受益于快速和可靠的网络。为了使etcd既一致又能容忍分区,带有分区中断的不可靠网络将导致较差的可用性。低延迟确保etcd成员可以快速通信。高带宽可以减少恢复失败的etcd成员的时间。1GbE对于普通的etcd部署已经足够了。对于大型etcd集群,10GbE网络将减少恢复的平均时间。
尽可能在单个数据中心中部署etcd成员,以避免延迟开销并减少分区事件的可能性。如果需要在其他数据中心中设置故障域,请选择离现有数据中心较近的数据中心。还请阅读调优(https://etcd.io/docs/v3.5/tuning/)文档,了解有关跨数据中心部署的更多信息
硬件配置示例
下面是AWS和GCE环境上的一些硬件设置示例。如前所述,但必须强调的是,管理员应该在将etcd部署投入生产之前使用模拟工作负载测试它。
注意,这些配置假定这些机器完全专用于etcd。在这些机器上与etcd一起运行其他应用程序可能会导致资源争用并导致集群不稳定
小集群
小集群服务的客户端少于100个,每秒请求数少于200个,存储的数据不超过100MB。
示例应用程序工作负载:一个50节点的Kubernetes集群
Provider | Type | vCPUs | Memory (GB) | Max concurrent IOPS | Disk bandwidth (MB/s) |
---|---|---|---|---|---|
AWS | m4.large | 2 | 8 | 3600 | 56.25 |
GCE | n1-standard-2 + 50GB PD SSD | 2 | 7.5 | 1500 | 25 |
中性集群
中等集群服务少于500个客户端,每秒请求数少于1000个,数据存储容量不超过500MB。
示例应用程序工作负载:250个节点的Kubernetes集群
Provider | Type | vCPUs | Memory (GB) | Max concurrent IOPS | Disk bandwidth (MB/s) |
---|---|---|---|---|---|
AWS | m4.xlarge | 4 | 16 | 6000 | 93.75 |
GCE | n1-standard-4 + 150GB PD SSD | 4 | 15 | 4500 | 75 |
大型集群
大型集群服务的客户端少于1500个,每秒请求数少于10,000个,存储的数据不超过1GB。
示例应用程序工作负载:1000节点的Kubernetes集群
Provider | Type | vCPUs | Memory (GB) | Max concurrent IOPS | Disk bandwidth (MB/s) |
---|---|---|---|---|---|
AWS | m4.2xlarge | 8 | 32 | 8000 | 125 |
GCE | n1-standard-8 + 250GB PD SSD | 8 | 30 | 7500 | 125 |
巨大集群
一个xLarge集群服务超过1500个客户端,每秒超过10,000个请求,存储超过1GB的数据。
示例应用程序工作负载:一个3000节点的Kubernetes集群
Provider | Type | vCPUs | Memory (GB) | Max concurrent IOPS | Disk bandwidth (MB/s) |
---|---|---|---|---|---|
AWS | m4.4xlarge | 16 | 64 | 16,000 | 250 |
GCE | n1-standard-16 + 500GB PD SSD | 16 | 60 | 15,000 | 250 |