2.4. 推荐的 etcd 实践
对于大型高密度的集群，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。定期维护和碎片 etcd 释放数据存储中的空间。监控 Prometheus 以了解 etcd 指标数据，并在需要时对其进行碎片处理；否则，etcd 可能会引发一个集群范围的警报，使集群进入维护模式，以只接受键读和删除。
监控这些关键指标：
-
etcd_server_quota_backend_bytes，这是当前配额限制 -
etcd_mvcc_db_total_size_in_use_in_bytes，表示历史压缩后实际数据库使用量 -
etcd_debugging_mvcc_db_total_size_in_bytes会显示数据库大小，包括等待碎片整理的空闲空间
有关 etcd 碎片整理的更多信息，请参阅 "Defragmenting etcd data" 部分。
因为 etcd 将数据写入磁盘并在磁盘上持久化，所以其性能取决于磁盘性能。减慢来自其他进程的磁盘活动和磁盘活动可能会导致长时间的 fsync 延迟。这些延迟可能会导致 etcd 丢失心跳，不会及时向磁盘提交新的建议，并最终遇到请求超时和临时丢失问题。在由低延迟和高吞吐量的 SSD 或 NVMe 磁盘支持的机器上运行 etcd。考虑单层单元(SLC)固态驱动器(SSD)，每个内存单元提供 1 位，是可靠，非常适合于写密集型工作负载。
在部署的 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的 99 百分比是否小于 10 ms。
要在创建 OpenShift Container Platform 集群之前或之后验证 etcd 的硬件，您可以使用名为 fio 的 I/O 基准测试工具。
先决条件
- 您正在测试的机器上安装了 Podman 或 Docker 等容器运行时。
-
数据被写入
/var/lib/etcd路径。
流程
运行 fio 并分析结果：
如果使用 Podman，请运行以下命令：
$ 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，以查看它是否小于 10 ms。
因为 etcd 在所有成员间复制请求，所以其性能会严重依赖于网络输入/输出(I/O)延迟。大量网络延迟会导致 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。
