# 硬件推荐

> etcd 集群的硬件指南

---

LLMS 索引： [llms.txt](/zh/llms.txt)

---

etcd 在资源有限的开发或测试环境中通常运行良好；在笔记本电脑或廉价云主机上开发 etcd 是常见做法。然而，在生产环境中运行 etcd 集群时，遵循一些硬件建议有助于实现有效的系统管理。这些建议并非硬性规定，而是构建稳健生产部署的良好起点。和往常一样，部署前应使用模拟工作负载进行测试。

## 处理器核心 {#cpus}

极少有 etcd 部署需要大量 CPU 资源。典型集群只需两到四个核心即可平稳运行。

高负载的 etcd 部署（例如每秒服务数千个客户端或数万个请求）通常受 CPU 限制，因为 etcd 可以从内存中提供请求服务。此类高负载部署通常需要八到十六个专用核心。


## 内存 {#memory}

etcd 的内存占用相对较小，但其性能仍依赖于充足的内存。etcd 服务器会积极缓存键值数据，并将大部分其他内存用于跟踪监听器。通常 8GB 内存已足够。对于拥有数千个监听器和数百万个键的高负载部署，应相应分配 16GB 至 64GB 内存。


## 磁盘 {#disks}

快速磁盘是影响 etcd 部署性能和稳定性的最关键因素。

慢速磁盘会增加 etcd 请求延迟，并可能影响集群稳定性。由于 etcd 的共识协议依赖于将元数据持久化存储到日志中，集群中多数成员必须将每个请求写入磁盘。此外，etcd 还会将状态增量式地进行快照并写入磁盘，以便截断该日志。若这些写入操作耗时过长，心跳可能超时并触发选举，从而破坏集群稳定性。通常，可通过基准测试工具如 [fio][fio] 判断磁盘是否足够快以满足 etcd 需求。请参阅 [here][fio-blog-post] 了解示例。

etcd 对磁盘写入延迟非常敏感。通常需要 50 个顺序 IOPS（例如，7200 RPM 磁盘）。对于负载较高的集群，建议使用 500 个顺序 IOPS（例如，典型的本地 SSD 或高性能虚拟化块设备）。请注意，大多数云服务提供商公布的都是并发 IOPS 而非顺序 IOPS；公布的并发 IOPS 可能是顺序 IOPS 的 10 倍。为测量实际的顺序 IOPS，建议使用磁盘基准测试工具，例如 [diskbench][diskbench] 或 [fio][fio]。

etcd 对磁盘带宽的要求较低，但更高的磁盘带宽可在成员故障后快速追上集群时显著缩短恢复时间。通常，10 MB/s 的带宽可在 15 秒内完成 100 MB 数据的恢复。对于大规模集群，建议使用 100 MB/s 或更高的带宽，以在 15 秒内完成 1 GB 数据的恢复。

在可能的情况下，使用 SSD 作为 etcd 存储的后端。SSD 通常比传统旋转磁盘提供更低的写入延迟，并且延迟波动更小，从而提升 etcd 的稳定性和可靠性。若使用旋转磁盘，应选择转速尽可能高的磁盘（例如 15,000 RPM）。使用 RAID 0 也是提升磁盘速度的有效方式，适用于旋转磁盘和 SSD。当集群中至少有三个成员时，RAID 的镜像或奇偶校验等冗余模式不再必要，因为 etcd 的一致性复制已提供高可用性。


## 网络 {#network}

多成员 etcd 部署得益于快速且可靠的网络。为确保 etcd 在一致性和分区容错性方面表现良好，不可靠且存在分区故障的网络会导致可用性下降。低延迟可确保 etcd 成员之间通信迅速。高带宽可缩短故障成员恢复所需时间。对于常见的 etcd 部署，1GbE 网络已足够。对于大型 etcd 集群，采用 10GbE 网络可进一步降低平均恢复时间。

在可能的情况下，将 etcd 成员部署于单一数据中心，以避免延迟开销并降低分区事件的发生概率。若需在其他数据中心设置故障域，请选择与现有数据中心更近的数据中心。请同时阅读 [tuning][tuning] 文档，以获取关于跨数据中心部署的更多信息。


## 示例硬件配置 {#example-hardware-configurations}

以下是 AWS 和 GCE 环境中的一些典型硬件配置示例。如前所述，尽管必须反复强调，系统管理员在将 etcd 部署投入生产环境前，应使用模拟工作负载进行测试。

请注意，这些配置假设这些机器完全专用于 etcd。在这些机器上同时运行其他应用程序可能导致资源争用，进而引发集群不稳定。

### 小型集群 {#small-cluster}

小型集群支持的客户端数量少于 100 个，每秒请求数少于 200 次，存储数据量不超过 100MB。

示例应用工作负载：一个包含 50 个节点的 Kubernetes 集群

| 提供商 | 类型 | vCPU 数量 | 内存 (GB) | 最大并发 IOPS | 磁盘带宽 (MB/s) |
|--------|------|-----------|-----------|--------------|------------------|
| AWS | m4.large | 2 | 8 | 3600 | 56.25 |
| GCE | n1-standard-2 + 50GB PD SSD | 2 | 7.5 | 1500 | 25 |


### 中等规模集群 {#medium-cluster}

一个中等规模的集群支持的客户端少于 500 个，每秒请求数少于 1,000 次，存储数据量不超过 500MB。

示例应用负载：一个包含 250 个节点的 Kubernetes 集群

| 提供商 | 类型 | vCPU 数量 | 内存 (GB) | 最大并发 IOPS | 磁盘带宽 (MB/s) |
|--------|------|-----------|------------|----------------|------------------|
| AWS | m4.xlarge | 4 | 16 | 6000 | 93.75 |
| GCE | n1-standard-4 + 150GB PD SSD | 4 | 15 | 4500 | 75 |


### 大规模集群 {#large-cluster}

大规模集群支持的客户端数量少于 1,500 个，每秒请求数少于 10,000 次，存储数据量不超过 1 GB。

示例应用负载：1,000 节点的 Kubernetes 集群

| 提供商 | 类型 | vCPU 数量 | 内存 (GB) | 最大并发 IOPS | 磁盘带宽 (MB/s) |
|--------|------|-----------|------------|----------------|------------------|
| AWS | m4.2xlarge | 8 | 32 | 8000 | 125 |
| GCE | n1-standard-8 + 250GB PD SSD | 8 | 30 | 7500 | 125 |


### 大规模集群 {#xlarge-cluster}

一个 xLarge 集群可支持超过 1,500 个客户端，每秒处理超过 10,000 个请求，并存储超过 1 GB 的数据。

示例应用负载：一个包含 3,000 个节点的 Kubernetes 集群

| 提供商 | 类型 | vCPU 数量 | 内存 (GB) | 最大并发 IOPS | 磁盘带宽 (MB/s) |
|--------|------|-----------|------------|----------------|------------------|
| AWS | m4.4xlarge | 16 | 64 | 16,000 | 250 |
| GCE | n1-standard-16 + 500GB PD SSD | 16 | 60 | 15,000 | 250 |


[diskbench]: https://github.com/ongardie/diskbenchmark
[fio]: https://github.com/axboe/fio
[fio-blog-post]: https://web.archive.org/web/20240726111518/https://prog.world/is-storage-speed-suitable-for-etcd-ask-fio/
[tuning]: /zh/docs/etcd/tuning/