1.5. 推荐的 etcd 实践
因为 etcd 将数据写入磁盘并在磁盘上持久化，所以其性能取决于磁盘性能。虽然 etcd 并不是有非常高的 I/O 负载，但它需要使用一个具有低延迟的块设备才能获得最佳性能和稳定性。因为 etcd 的共识协议依赖于将元数据永久存储到一个日志 (WAL)，所以 etcd 对磁盘的写延迟非常敏感。减慢来自其他进程的磁盘活动和磁盘活动可能会导致长时间的 fsync 延迟。
这些延迟可能会导致 etcd 丢失心跳，不会及时向磁盘提交新的建议，并最终遇到请求超时和临时丢失问题。高写入延迟也会导致 OpenShift API 较慢，这会影响集群性能。因此，需要避免在 control-plane 节点运行其他工作负载。
就延迟而言，应该在一个可最少以 50 IOPS 按顺序写入 8000 字节的块设备上运行。也就是说，当有一个 20ms 的延迟时，使用 fdatasync 来同步 WAL 中的写入操作。对于高负载的集群，建议使用 8000 字节的连续 500 IOPS (2 毫秒)。要测量这些数字，您可以使用基准测试工具，如 fio。
要实现这样的性能，在由低延迟和高吞吐量的 SSD 或 NVMe 磁盘支持的机器上运行 etcd。考虑使用单层单元(SLC)固态驱动器(SSD)（它为每个内存单元提供 1 位），这是可靠的，非常适合于写密集型工作负载。
以下硬盘功能提供最佳的 etcd 性能：
- 支持快速读取操作的低延迟。
- 高带宽写入，实现更快速的压缩和碎片处理。
- 高带宽读取，加快从故障恢复。
- 固态硬盘是最小的选择，NVMe 驱动器是首选的。
- 来自不同制造商的服务器级硬件可以提高可靠性。
- RAID 0 技术以提高性能。
- 专用 etcd 驱动器。不要将日志文件或其他重重工作负载放在 etcd 驱动器中。
避免 NAS 或 SAN 设置，以及旋转驱动器。始终使用相关工具（如 fio）进行基准测试。在增加时，持续监控集群性能。
避免使用网络文件系统 (NFS) 协议或其他基于网络的文件系统。
需要在部署的 OpenShift Container Platform 集群上监控的一些关键指标包括，日志持续时间之前的 etcd 磁盘写入的 p99 值，以及 etcd leader 更改的数量。使用 Prometheus 跟踪这些指标。
要在创建 OpenShift Container Platform 集群之前或之后验证 etcd 的硬件，您可以使用 fio。
先决条件
- 您正在测试的机器上安装了 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 值是否小于 20ms。一些最重要的 etcd 指标可能受到 I/O 性能的影响，如下所示：
-
etcd_disk_wal_fsync_duration_seconds_bucket指标报告了 etcd 的 WAL fsync 持续时间。 -
etcd_disk_backend_commit_duration_seconds_bucket指标报告 etcd 后端提交延迟持续时间 -
etcd_server_leader_changes_seen_total指标报告领导更改
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。
