etcd_0">etcd部署硬件资源推荐
原文:https://etcd.io/docs/v3.5/op-guide/hardware/
etcd 通常在开发或测试环境中运行良好,即使资源有限;在笔记本电脑或廉价云服务器上开发时,使用 etcd 也很常见。然而,在生产环境中运行 etcd 集群时,遵循一些硬件指南对于正确的管理非常有用。这些建议并非硬性规定;它们为稳健的生产部署提供了良好的起点。
正如以往一样,在投入生产之前,应使用模拟工作负载对部署进行测试。
CPUs
大多数 etcd 部署对 CPU 的需求并不高。典型的集群需要 2 到 4 个核心即可平稳运行。对于负载较重的部署,如服务成千上万的客户端或每秒处理数万个请求,可能会受到 CPU 限制,因为 etcd 可以从内存中处理请求。此类重负载部署通常需要 8 到 16 个专用核心。
内存(RAM)
etcd 的内存占用相对较小,但性能仍然依赖于足够的内存。etcd 服务器会积极缓存键值数据,并将大部分内存用于跟踪watchers。通常,8GB 的内存已足够。对于拥有成千上万watchers和数百万keys的重负载部署,建议分配 16GB 至 64GB 的内存。
磁盘(Disks)
快速磁盘是 etcd 部署性能和稳定性的最关键因素。
慢速磁盘会增加 etcd 请求的延迟,并可能影响集群的稳定性。由于 etcd 的共识(consensus)协议依赖于将元数据持久化存储到日志中,大多数 etcd 集群成员必须将每个请求写入磁盘。此外,etcd 还会定期将其状态增量地保存到磁盘,以便在需要时截断日志。如果这些写入操作太慢,心跳可能会超时并触发选举,从而破坏集群的稳定性。一般来说,要判断磁盘是否足够快,可以使用基准测试工具,例如 fio。可以在此处查看示例。
etcd 对磁盘写入延迟非常敏感。通常,需要 50 次顺序 IOPS(例如,7200 转速的磁盘)。对于负载较重的集群,建议使用 500 次顺序 IOPS(例如,典型的本地 SSD 或高性能虚拟化块设备)。请注意,大多数云服务提供商发布的是并发 IOPS,而非顺序 IOPS;发布的并发 IOPS 可能是顺序 IOPS 的 10 倍。要测量实际的顺序 IOPS,建议使用磁盘基准测试工具,如 diskbench 或 fio。
etcd 对磁盘带宽的要求适中,但更高的磁盘带宽可以在成员故障后更快地恢复。通常,10MB/s 的带宽可以在 15 秒内恢复 100MB 的数据。对于大型集群,建议提供 100MB/s 或更高的带宽,以在 15 秒内恢复 1GB 的数据。
如果可能,建议使用 SSD 来支持 etcd 的存储。SSD 通常提供比旋转磁盘更低的写入延迟和更小的延迟变化,从而提高 etcd 的稳定性和可靠性。如果使用旋转磁盘,建议选择最快的磁盘(如 15000 转速)。使用 RAID 0 也是提高磁盘速度的有效方法,适用于旋转磁盘和 SSD。对于至少有三个集群成员的情况,RAID 的镜像和/或奇偶校验变种并非必需;etcd 的一致性复制已能提供高可用性。
网络(Network)
多成员的 etcd 部署受益于快速且可靠的网络。为了确保 etcd 一致性和分区容忍性,不可靠的网络和分区故障会导致可用性差。低延迟确保 etcd 成员之间的快速通信。高带宽可以减少恢复失败成员所需的时间。对于常见的 etcd 部署,1GbE 网络已足够。对于大型 etcd 集群,10GbE 网络可以减少平均恢复时间。
如果可能,将 etcd 成员部署在同一数据中心,以避免延迟开销并减少分区事件的可能性。如果需要在另一个数据中心的故障域中部署,请选择距离现有数据中心更近的数据中心。有关跨数据中心部署的更多信息,请参阅调优文档。
示例硬件配置
以下是在 AWS 和 GCE 环境中的一些示例硬件配置。正如之前提到的,管理员应在将 etcd 部署投入生产之前,使用模拟工作负载进行测试。
请注意,这些配置假设这些机器完全专用于 etcd。在这些机器上运行其他应用程序可能会导致资源争用,从而导致集群不稳定。
小型集群
服务于少于 100 个客户端,每秒少于 200 个请求,存储不超过 100MB 数据。
示例应用工作负载:50 节点的 Kubernetes 集群
提供商 | 类型 | vCPUs | 内存(GB) | 最大并发 IOPS | 磁盘带宽(MB/s) |
---|---|---|---|---|---|
AWS | m4.large | 2 | 8 | 3600 | 56.25 |
GCE | n1-standard-2 | 2 | 7.5 | 1500 | 25 |
中型集群
服务于少于 500 个客户端,每秒少于 1000 个请求,存储不超过 500MB 数据。
示例应用工作负载:250 节点的 Kubernetes 集群
提供商 | 类型 | vCPUs | 内存(GB) | 最大并发 IOPS | 磁盘带宽(MB/s) |
---|---|---|---|---|---|
AWS | m4.xlarge | 4 | 16 | 6000 | 93.75 |
GCE | n1-standard-4 | 4 | 15 | 4500 | 75 |
大规模(Large)集群
超大规模(Large)集群服务于少于 1500 个客户端,每秒少于 10000 个请求,存储不超过 1GB 数据。
示例应用工作负载:1000 节点的 Kubernetes 集群
提供商 | 类型 | vCPUs | 内存(GB) | 最大并发 IOPS | 磁盘带宽(MB/s) |
---|---|---|---|---|---|
AWS | m4.2xlarge | 8 | 32 | 8000 | 125 |
GCE | n1-standard-8 + 250GB PD SSD | 8 | 30 | 7500 | 125 |
超大规模(xLarge)集群
超大规模(xLarge)集群服务于超过 1,500 个客户端,每秒处理超过 10,000 个请求,存储超过 1GB 的数据。
示例应用工作负载:3,000 节点的 Kubernetes 集群
提供商 | 类型 | vCPUs | 内存(GB) | 最大并发 IOPS | 磁盘带宽(MB/s) |
---|---|---|---|---|---|
AWS | m4.4xlarge | 16 | 64 | 16,000 | 250 |
GCE | n1-standard-16 + 500GB PD SSD | 16 | 60 | 15,000 | 250 |