etcd通常运行良好，资源有限，无需开发或测试; 在笔记本电脑或便宜的云计算机上使用etcd进行开发是很常见的。 但是，在生产中运行etcd集群时，某些硬件指南对于正确管理非常有用。 这些建议不是硬性规则; 它们是强大生产部署的良好起点。 与往常一样，在生产中运行之前，应使用模拟工作负载测试部署。
CPUs
很少有etcd部署需要大量的CPU容量。 典型的集群需要两到四个核心才能顺利运行。 重载的etcd部署，每秒服务数千个客户端或数万个请求，往往受CPU限制，因为etcd可以处理来自内存的请求。 如此繁重的部署通常需要8到16个专用核心。
Memory
etcd的内存占用量相对较小，但其性能仍然取决于是否有足够的内存。 一个etcd服务器将积极地缓存键值数据，并花费大部分其余的内存跟踪观察者。 通常8GB就足够了。 对于拥有数千名观察者和数百万个密钥的大量部署，相应地分配16GB到64GB内存。
Disks
快速磁盘是etcd部署性能和稳定性的最关键因素。慢速磁盘会增加etcd请求延迟并可能损害群集稳定性。由于etcd的共识协议依赖于持久存储元数据到日志，因此大多数etcd集群成员必须将每个请求写入磁盘。此外，etcd还将逐步检查其状态到磁盘，以便截断此日志。如果这些写入花费的时间太长，心跳可能会超时并触发选举，从而破坏群集的稳定性。 etcd对磁盘写入延迟非常敏感。通常需要50个顺序IOPS（例如，7200RPM磁盘）。对于负载较重的群集，建议使用500个连续IOPS（例如，典型的本地SSD或高性能虚拟化块设备）。请注意，大多数云提供程序发布并发IOPS而不是顺序IOPS;发布的并发IOPS可能比顺序IOPS大10倍。要测量实际的顺序IOPS，我们建议使用磁盘基准测试工具，如diskbench或fio。 etcd只需要适度的磁盘带宽，但当故障成员必须赶上集群时，更多的磁盘带宽可以更快地恢复恢复时间。通常，10MB / s将在15秒内恢复100MB数据。对于大型群集，建议在15秒内恢复1GB数据100MB / s或更高。在可能的情况下，使用SSD支持etcd的存储。 SSD通常提供较低的写入延迟并且具有比旋转磁盘更小的变化，从而提高了etcd的稳定性和可靠性。如果使用旋转磁盘，可以获得最快的磁盘（15,000 RPM）。对于旋转磁盘和SSD，使用RAID 0也是提高磁盘速度的有效方法。对于至少三个集群成员，RAID的镜像和/或奇偶校验变体是不必要的; etcd的一致复制已经获得高可用性。
Network
多成员etcd部署受益于快速可靠的网络。 为了使etcd具有一致性和分区容错性，具有分区中断的不可靠网络将导致可用性差。 低延迟确保etcd成员可以快速通信。 高带宽可以减少恢复失败的etcd成员的时间。 1GbE足以用于常见的etcd部署。 对于大型etcd集群，10GbE网络将缩短平均恢复时间。 在可能的情况下在单个数据中心内部署etcd成员，以避免延迟开销并减少分区事件的可能性。 如果需要另一个数据中心的故障域，请选择更接近现有数据中心的数据中心。 有关跨数据中心部署的更多信息，请阅读调优文档。
硬件配置示例
以下是AWS和GCE环境中的一些示例硬件设置。 如前所述，但无论如何都必须强调，管理员应该在将模拟工作负载投入生产之前对其进行测试。 请注意，这些配置假设这些机器完全专用于etcd。 在这些计算机上运行其他应用程序以及etcd可能会导致资源争用并导致集群不稳定。
Small cluster
A small cluster serves fewer than 100 clients, fewer than 200 of requests per second, and stores no more than 100MB of data.
Example application workload: A 50-node Kubernetes cluster
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
Medium cluster
A medium cluster serves fewer than 500 clients, fewer than 1,000 of requests per second, and stores no more than 500MB of data.
Example application workload: A 250-node Kubernetes cluster
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
Large cluster
A large cluster serves fewer than 1,500 clients, fewer than 10,000 of requests per second, and stores no more than 1GB of data.
Example application workload: A 1,000-node Kubernetes cluster
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 cluster
An xLarge cluster serves more than 1,500 clients, more than 10,000 of requests per second, and stores more than 1GB data.
Example application workload: A 3,000 node Kubernetes cluster
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
