ETCD硬件推荐

本文主要是介绍ETCD硬件推荐，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

硬件建议

待定

etcd通常在用于开发或测试目的的资源有限的情况下运行良好；通常在笔记本电脑或廉价的云计算机上使用etcd进行开发。但是，在生产环境中运行etcd集群时，一些硬件准则对于正确管理很有用。这些建议不是硬性规定。它们是进行强大的生产部署的良好起点。与往常一样，在生产环境中运行之前，应使用模拟的工作负载对部署进行测试。

中央处理器

很少有etcd部署需要大量的CPU容量。典型的集群需要2到4个核心才能平稳运行。
每秒服务数千个客户端或成千上万个请求的重载etcd部署往往受CPU限制，因为etcd可以服务于内存中的请求。如此繁重的部署通常需要八到十六个专用内核。

记忆

etcd的内存占用相对较小，但是其性能仍然取决于是否有足够的内存。etcd服务器将积极地缓存键值数据，并花费其其余大部分内存跟踪监视程序。通常8GB就足够了。对于具有数千名观察者和数百万个密钥的繁重部署，请相应地将16GB分配给64GB内存。

磁盘

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

缓慢的磁盘会增加etcd请求的延迟，并可能损害群集的稳定性。由于etcd的共识协议依赖于将元数据持久存储在日志中，因此大多数etcd集群成员必须将每个请求写入磁盘。另外，etcd还将以增量方式将其状态检查到磁盘，以便它可以截断该日志。如果这些写入花费的时间太长，则心跳可能会超时并触发选举，从而破坏了群集的稳定性。

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

etcd仅需要适度的磁盘带宽，但是当故障成员必须赶上集群时，更多的磁盘带宽可以缩短恢复时间。通常，每秒10MB的速度将在15秒内恢复100MB的数据。对于大型群集，建议使用100MB / s或更高的速度在15秒内恢复1GB数据。

如果可能，请使用SSD将etcd的存储返回。与旋转磁盘相比，SSD通常提供更低的写入延迟和更少的差异，从而提高了etcd的稳定性和可靠性。如果使用旋转磁盘，请获得最快的磁盘（15,000 RPM）。对于旋转磁盘和SSD，使用RAID 0也是提高磁盘速度的有效方法。对于至少三个群集成员，RAID的镜像和/或奇偶校验变体是不必要的；etcd的一致复制已经获得了高可用性。

网络

多成员etcd部署得益于快速可靠的网络。为了使etcd既一致又容忍分区，具有分区中断的不可靠网络将导致可用性不佳。低延迟确保etcd成员可以快速通信。高带宽可以减少恢复失败的etcd成员的时间。1GbE对于常见的etcd部署就足够了。对于大型etcd群集，10GbE网络将减少平均恢复时间。

尽可能在单个数据中心内部署etcd成员，以避免延迟开销并减少对事件进行分区的可能性。如果需要另一个数据中心中的故障域，请选择一个更靠近现有数据中心的数据中心。另请阅读调整文档，以获取有关跨数据中心部署的更多信息。

硬件配置示例

以下是在AWS和GCE环境上的一些示例硬件设置。如前所述，但无论如何都要强调，管理员在将生产部署之前，应使用模拟的工作负载测试etcd部署。

请注意，这些配置假定这些机器完全专用于etcd。在这些计算机上与etcd一起运行其他应用程序可能会导致资源争用并导致群集不稳定。

小集群

小型群集为少于100个客户端提供服务，每秒少于200个请求，并且存储的数据不超过100MB。

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

中型集群

一个中型集群为少于500个客户端提供服务，每秒少于1,000个请求，并且存储的数据不超过500MB。

应用程序工作负载示例：250个节点的Kubernetes集群

大型集群

大型群集为少于1,500个客户端提供服务，每秒少于10,000个请求，并且存储的数据量不超过1GB。

应用程序工作负载示例：一个1,000节点的Kubernetes集群

xLarge丛集

xLarge群集可为1,500多个客户端提供服务，每秒可处理10,000多个请求，并存储1GB以上的数据。

应用程序工作负载示例：3,000个节点的Kubernetes集群

这篇关于ETCD硬件推荐的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！