2.5. 推荐的 etcd 实践

对于大型高密度的集群，如果键空间增长过大，超过空间配额，则 etcd 的性能可能会受到极大影响。需要定期维护 etcd（包括整理碎片）以便在数据存储中释放空间。强烈建议您密切监控 Prometheus 中的 etcd 指标数据，并提早进行碎片整理。否则，etcd 可能会引发一个集群范围的警告，使集群进入维护模式（只能对键进行读和删除）。需要密切关注的指标数据是 etcd_server_quota_backend_bytes， 即当前的配额限制；etcd_mvcc_db_total_size_in_use_in_in_bytes ，它显示了对历史数据进行压缩后的实际数据库用量；etcd_debugging_mvcc_db_total_size_in_bytes ，它显示了数据库大小，包括等待进行碎片处理的空闲空间。有关 etcd 碎片整理的说明，请参考 etcd 数据的碎片整理部分。

etcd 将数据写入磁盘，因此其性能在很大程度上取决于磁盘性能。etcd 在磁盘上持久化。速度较慢的磁盘胡来自其他进程的磁盘活动可能会造成长时间的 fsync 延迟，,从而导致 etcd 丢失心跳信号，从而无法及时向磁盘提交新的操作，这可能导致请求超时并暂时丢失领导（leader）的功能。强烈建议您在由低延迟和高吞吐量的 SSD/NVMe 磁盘支持的机器上运行 etcd。

需要在部署的 OpenShift Container Platform 集群上监控的一些关键指标包括，日志持续时间之前的 etcd 磁盘写入的 p99 值，以及 etcd leader 更改的数量。使用 Prometheus 跟踪这些指标。etcd_disk_wal_fsync_duration_seconds_bucket 报告 etcd 磁盘 fsync 持续时间，etcd_server_leader_changes_seen_total 报告领导更改。要排除一个较慢的磁盘并且确认磁盘的速度合理， etcd_disk_wal_fsync_duration_seconds_bucket 的p99 值应该小于 10ms。

fio 是一个 I/O 基准测试工具，可用于在创建 OpenShift Container Platform 集群之前或之后验证 etcd 的硬件。运行 fio 并分析结果：

假设在接受测试的机器上安装了类似 podman 或 docker 的容器运行时，并且 etcd 写入数据存在于 - /var/lib/etcd，请运行：

$ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/openshift-scale/etcd-perf

另外，如果使用 docker，运行以下命令：

$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/openshift-scale/etcd-perf

输出会报告磁盘是否足够快以运行 etcd，它会检查测试运行中获得的 fsync 指标的 p99 值是否小于 10ms。

etcd 在所有成员间复制请求，因此其性能会严重依赖于网络输入/输出（IO）的延迟。大量网络延迟会导致 etcd heartbeat 的时间比选举超时时间更长，这会导致一个可能会对集群造成破坏的领导选举。在部署的 OpenShift Container Platform 集群上监控的一个关键指标是每个 etcd 集群成员上的 etcd 网络对延迟的 p99 百分比。使用 Prometheus 跟踪指标数据。histogram_quantile（0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m])） 报告 etcd 在成员间复制客户端请求的时间 ; 它应该小于 50 ms。