2.3. 推荐的 etcd 实践

本主题为 OpenShift Container Platform 中的 etcd 提供了推荐的性能和可扩展性实践。

2.3.1. 推荐的 etcd 实践

因为 etcd 将数据写入磁盘并在磁盘上持久化，所以其性能取决于磁盘性能。虽然 etcd 并不是有非常高的 I/O 负载，但它需要使用一个具有低延迟的块设备才能获得最佳性能和稳定性。因为 etcd 的共识协议依赖于将元数据永久存储到一个日志 (WAL)，所以 etcd 对磁盘的写延迟非常敏感。减慢来自其他进程的磁盘活动和磁盘活动可能会导致长时间的 fsync 延迟。

这些延迟可能会导致 etcd 丢失心跳，不会及时向磁盘提交新的建议，并最终遇到请求超时和临时丢失问题。高写入延迟也会导致 OpenShift API 较慢，这会影响集群性能。由于这些原因，请避免在具有 I/O 敏感或密集型的 control-plane 节点上并置其他工作负载，并共享相同的底层 I/O 基础架构。

就延迟而言，应该在一个可最少以 50 IOPS 按顺序写入 8000 字节的块设备上运行。也就是说，当有一个 10ms 的延迟时，使用 fdatasync 来同步 WAL 中的写入操作。对于高负载的集群，建议使用 8000 字节的连续 500 IOPS (2 毫秒)。要测量这些数字，您可以使用基准测试工具，如 fio。

要实现这样的性能，在由低延迟和高吞吐量的 SSD 或 NVMe 磁盘支持的机器上运行 etcd。考虑使用单层单元(SLC)固态驱动器(SSD)（它为每个内存单元提供 1 位），这是可靠的，非常适合于写密集型工作负载。

注意

影响 etcd 上的负载的因素包括静态因素，如节点和 pod 的数量，以及动态因素，包括因为 pod 自动扩展、pod 重启、作业执行和其他与工作负载相关的事件，以及其他与负载相关的事件。要准确调整 etcd 设置的大小，您必须分析工作负载的特定要求。考虑影响 etcd 负载的节点、pod 和其他相关因素的数量。

以下硬盘驱动器实践提供最佳的 etcd 性能：

使用专用 etcd 驱动器。避免通过网络通信的驱动器，如 iSCSI。不要将日志文件或其他重重工作负载放在 etcd 驱动器中。
首选驱动低延迟来支持快速读写操作。
首选高带宽写入，以便更快地压缩和整理碎片。
首选高带宽读取，以便更快地从故障恢复。
使用固态硬盘作为最低选择。在生产环境中首选 NVMe 驱动器。
使用服务器级硬件提高可靠性。

注意

避免 NAS 或 SAN 设置，以及旋转驱动器。Ceph Rados 块设备 (RBD) 和其他类型的网络附加存储可能会导致网络延迟无法预计。要大规模向 etcd 节点提供快速存储，请使用 PCI 透传将 NVM 设备直接传递给节点。

始终使用相关工具（如 fio）进行基准测试。当集群性能增加时，您可以使用这些工具不断监控集群性能。

注意

避免使用网络文件系统 (NFS) 协议或其他基于网络的文件系统。

需要在部署的 OpenShift Container Platform 集群上监控的一些关键指标包括，日志持续时间之前的 etcd 磁盘写入的 p99 值，以及 etcd leader 更改的数量。使用 Prometheus 跟踪这些指标。

注意

在正常操作过程中，etcd 成员数据库大小可能会因集群而异。这种差异不会影响集群升级，即使领导大小与其他成员不同。

要在创建 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/cloud-bulldozer/etcd-perf

如果使用 Docker，请运行以下命令：

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

输出会报告磁盘是否足够快以运行 etcd，它会检查测试运行中获得的 fsync 指标的 p99 值是否小于 10ms。一些最重要的 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。

其他资源

2.3.2. 将 etcd 移动到不同的磁盘

您可以将 etcd 从共享磁盘移到独立磁盘，以防止或解决性能问题。

Machine Config Operator (MCO) 负责为 OpenShift Container Platform 4.13 容器存储挂载辅助磁盘。

注意

这个编码脚本只支持以下设备类型的设备名称：

SCSI 或 SATA: /dev/sd*
虚拟设备: /dev/vd*
NVMe: /dev/nvme*[0-9]*n*

限制：

当新磁盘附加到集群时，etcd 数据库是 root 挂载的一部分。当主节点被重新创建时，它不是二级磁盘的一部分或预期的磁盘。因此，主节点不会创建单独的 /var/lib/etcd 挂载。

先决条件

有集群的 etcd 数据备份。
已安装 OpenShift CLI(oc)。
您可以使用 cluster-admin 权限访问集群。
在上传机器配置前添加额外的磁盘。
MachineConfigPool 必须与 metadata.labels[machineconfiguration.openshift.io/role] 匹配。这适用于控制器、worker 或自定义池。

注意

这个过程不会将 root 文件系统的部分内容（如 /var/ ）移到已安装节点上的另一个磁盘或分区。

重要

使用 control plane 机器集时不支持这个过程。

流程

将新磁盘附加到集群，并在 debug shell 中运行 lsblk 命令来验证节点中是否检测到磁盘：
```
$ oc debug node/<node_name>
```
```
# lsblk
```
记录下 lsblk 命令报告的新磁盘的设备名称。

创建以下脚本，并将其命名为 etcd-find-secondary-device.sh ：

#!/bin/bash
set -uo pipefail

for device in <device_type_glob>; do 1
/usr/sbin/blkid "${device}" &> /dev/null
 if [ $? == 2  ]; then
    echo "secondary device found ${device}"
    echo "creating filesystem for etcd mount"
    mkfs.xfs -L var-lib-etcd -f "${device}" &> /dev/null
    udevadm settle
    touch /etc/var-lib-etcd-mount
    exit
 fi
done
echo "Couldn't find secondary block device!" >&2
exit 77

1: 将 <device_type_glob> 替换为您的块设备类型的 shell glob。对于 SCSI 或 SATA 驱动器，使用 /dev/sd*; 对于虚拟驱动器，使用 /dev/vd*; 对于 NVMe 驱动器，使用 /dev/nvme*[0-9]*n*。

从 etcd-find-secondary-device.sh 脚本创建一个 base64 编码的字符串，并记录它的内容：
```
$ base64 -w0 etcd-find-secondary-device.sh
```

创建名为 etcd-mc.yml 的 MachineConfig YAML 文件，其内容如下：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 98-var-lib-etcd
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
        - path: /etc/find-secondary-device
          mode: 0755
          contents:
            source: data:text/plain;charset=utf-8;base64,<encoded_etcd_find_secondary_device_script> 1
    systemd:
      units:
        - name: find-secondary-device.service
          enabled: true
          contents: |
            [Unit]
            Description=Find secondary device
            DefaultDependencies=false
            After=systemd-udev-settle.service
            Before=local-fs-pre.target
            ConditionPathExists=!/etc/var-lib-etcd-mount

            [Service]
            RemainAfterExit=yes
            ExecStart=/etc/find-secondary-device

            RestartForceExitStatus=77

            [Install]
            WantedBy=multi-user.target
        - name: var-lib-etcd.mount
          enabled: true
          contents: |
            [Unit]
            Before=local-fs.target

            [Mount]
            What=/dev/disk/by-label/var-lib-etcd
            Where=/var/lib/etcd
            Type=xfs
            TimeoutSec=120s

            [Install]
            RequiredBy=local-fs.target
        - name: sync-var-lib-etcd-to-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Sync etcd data if new mount is empty
            DefaultDependencies=no
            After=var-lib-etcd.mount var.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 1
            ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
            ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
        - name: restorecon-var-lib-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Restore recursive SELinux security contexts
            DefaultDependencies=no
            After=var-lib-etcd.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecStart=/sbin/restorecon -R /var/lib/etcd/
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target

1: 将 <encoded_etcd_find_secondary_device_script > 替换为您记录的编码脚本内容。

验证步骤

在节点的 debug shell 中运行 grep /var/lib/etcd /proc/mounts 命令，以确保挂载磁盘：

$ oc debug node/<node_name>

# grep -w "/var/lib/etcd" /proc/mounts

输出示例

/dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

其他资源

Red Hat Enterprise Linux CoreOS (RHCOS)

2.3.3. 分离 etcd 数据

对于大型、高密度的集群，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。定期维护并处理碎片化的 etcd，以释放数据存储中的空间。监控 Prometheus 以了解 etcd 指标数据，并在需要时对其进行碎片处理；否则，etcd 可能会引发一个集群范围的警报，使集群进入维护模式，仅能接受对键的读和删除操作。

监控这些关键指标：

etcd_server_quota_backend_bytes，这是当前配额限制
etcd_mvcc_db_total_size_in_use_in_bytes，表示历史压缩后实际数据库使用量
etcd_mvcc_db_total_size_in_bytes 显示数据库大小，包括等待碎片整理的可用空间

在导致磁盘碎片的事件后（如 etcd 历史记录紧凑）对 etcd 数据进行清理以回收磁盘空间。

历史压缩将自动每五分钟执行一次，并在后端数据库中造成混乱。此碎片空间可供 etcd 使用，但主机文件系统不可用。您必须对碎片 etcd 进行碎片清除，才能使这个空间可供主机文件系统使用。

碎片清理会自动发生，但您也可以手动触发它。

注意

自动清理碎片非常适合大多数情况，因为 etcd operator 使用集群信息来确定用户最有效的操作。

2.3.3.1. 自动清理

etcd Operator 自动清理碎片磁盘。不需要人工干预。

查看以下日志之一来验证碎片整理过程是否成功：

etcd 日志
cluster-etcd-operator pod
Operator 状态错误日志

警告

自动清除可能会导致各种 OpenShift 核心组件中的领导选举失败，如 Kubernetes 控制器管理器，这会触发重启失败的组件。重启会有危害，并会触发对下一个正在运行的实例的故障切换，或者组件在重启后再次恢复工作。

成功进行碎片处理的日志输出示例

etcd member has been defragmented: <member_name>, memberID: <member_id>

进行碎片处理失败的日志输出示例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>

2.3.3.2. 手动清理

Prometheus 警报指示您需要手动进行碎片处理。该警报在两个情况下显示：

当 etcd 使用超过 50% 的可用空间超过了 10 分钟
当 etcd 活跃使用小于其数据库总大小的 50% 超过了 10 分钟

您还可以通过检查 etcd 数据库大小（MB）来决定是否需要进行碎片整理。通过 PromQL 表达 (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024 来释放空间。

警告

分离 etcd 是一个阻止性操作。在进行碎片处理完成前，etcd 成员将没有响应。因此，在每个下一个 pod 要进行碎片清理前，至少等待一分钟，以便集群可以恢复正常工作。

按照以下步骤对每个 etcd 成员上的 etcd 数据进行碎片处理。

先决条件

您可以使用具有 cluster-admin 角色的用户访问集群。

流程

确定哪个 etcd 成员是领导成员，因为领导会进行最后的碎片处理。

获取 etcd pod 列表：

$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

输出示例

etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

选择 pod 并运行以下命令来确定哪个 etcd 成员是领导：

$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

输出示例

Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

基于此输出的 IS LEADER 列，https://10.0.199.170:2379 端点是领导。与上一步输出匹配此端点，领导的 pod 名称为 etcd-ip-10-0-199-170.example.redhat.com。

清理 etcd 成员。

连接到正在运行的 etcd 容器，传递不是领导的 pod 的名称：
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
```
取消设置 ETCDCTL_ENDPOINTS 环境变量：
```
sh-4.4# unset ETCDCTL_ENDPOINTS
```

清理 etcd 成员：

sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

输出示例

Finished defragmenting etcd member[https://localhost:2379]

如果发生超时错误，增加 --command-timeout 的值，直到命令成功为止。

验证数据库大小是否已缩小：

sh-4.4# etcdctl endpoint status -w table --cluster

输出示例

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

本例显示这个 etcd 成员的数据库大小现在为 41 MB，而起始大小为 104 MB。

重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。
至少要在碎片处理操作之间等待一分钟，以便 etcd pod 可以恢复。在 etcd pod 恢复前，etcd 成员不会响应。

如果因为超过空间配额而触发任何 NOSPACE 警告，请清除它们。
1. 检查是否有 NOSPACE 警告：
```
sh-4.4# etcdctl alarm list
```
  输出示例
```
memberID:12345678912345678912 alarm:NOSPACE
```
2. 清除警告：
```
sh-4.4# etcdctl alarm disarm
```

2.3. 推荐的 etcd 实践

2.3.1. 推荐的 etcd 实践

2.3.2. 将 etcd 移动到不同的磁盘

2.3.3. 分离 etcd 数据

2.3.3.1. 自动清理

2.3.3.2. 手动清理

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links