etcd适合的存储速度？ 让我们问问fio

关于 fio 和 etcd 的小故事

集群性能 等 很大程度上取决于其存储的性能。 etcd 将一些指标导出到 普罗米修斯提供所需的存储性能信息。 例如，wal_fsync_duration_seconds 指标。 etcd 的文档说：要使存储速度足够快，该指标的第 99 个百分位数必须小于 10 毫秒。 如果你计划在 Linux 机器上运行 etcd 集群并想评估你的存储是否足够快（例如 SSD），你可以使用 FIO 是用于测试 I/O 操作的流行工具。 运行以下命令，其中test-data为存储挂载点下的目录：

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

您只需要查看结果并检查持续时间的第 99 个百分位数 数据同步 小于 10 毫秒。 如果是这样，您的存储速度相当快。 以下是结果示例：

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

笔记

• 我们为我们的特定场景定制了 --size 和 --bs 选项。 要从 fio 获得有用的结果，请提供您自己的值。 从哪里得到它们？ 读 我们是如何学会配置 fio 的.
• 测试期间，所有 I/O 负载均来自 fio。 在现实场景中，除了与 wal_fsync_duration_seconds 相关的请求外，可能还会有其他写入请求进入存储。 额外的负载会增加 wal_fsync_duration_seconds 的值。 因此，如果第 99 个百分位数接近 10 毫秒，则表明您的存储速度快用完了。
• 拿版本 FIO 不低于3.5 （以前的不显示 fdatasync 持续时间百分位数）。
• 以上只是 fio 的一小部分结果。

关于 fio 和 etcd 的长篇大论

etcd中的WAL是什么

通常数据库使用 预写日志; etcd 也使用它。 我们不会在这里详细讨论预写日志 (WAL)。 我们知道 etcd 集群的每个成员都将其维护在持久存储中就足够了。 etcd 在将每个键值操作（例如更新）应用于存储之前将其写入 WAL。 如果其中一个存储成员在快照之间崩溃并重新启动，它可以通过 WAL 内容在本地恢复自上次快照以来的事务。

当客户端将键添加到键值存储或更新现有键的值时，etcd 将操作记录在 WAL 中，WAL 是持久存储中的常规文件。 etcd 必须完全确定 WAL 条目在继续处理之前确实发生了。 在 Linux 上，一个系统调用是不够的。 写，因为实际写入物理存储可能会延迟。 例如，Linux 可能会将 WAL 条目存储在内核内存中的缓存（例如页面缓存）中一段时间​​。 并且为了将数据准确写入持久化存储，写入后需要fdatasync系统调用，etcd只是使用它（如工作结果所示） 痕迹，其中 8 是 WAL 文件描述符）：

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

不幸的是，写入持久存储不会立即发生。 如果 fdatasync 调用很慢，etcd 系统的性能将受到影响。 etcd 的文档说如果在第 99 个百分位数中，fdatasync 调用写入 WAL 文件的时间少于 10 毫秒，则认为存储速度足够快。 还有其他有用的存储指标，但在这篇文章中我们只讨论这个指标。

使用 fio 估算存储空间

如果您需要评估您的存储是否适合 etcd，请使用非常流行的 I/O 负载测试工具 fio。 应该记住，磁盘操作可能非常不同：同步和异步、许多类系统调用等。因此，fio 很难使用。 它有很多参数，它们的值的不同组合会产生非常不同的 I/O 工作负载。 为了获得足够的 etcd 数据，您应该确保在写入 WAL 文件时来自 fio 的测试写入负载尽可能接近来自 etcd 的实际负载。

因此，fio 至少应该以一系列连续写入文件的形式创建一个负载，每次写入都将包含一个系统调用 写随后是 fdatasync 系统调用。 顺序写入 fio 需要 --rw=write 选项。 让fio在写的时候使用write系统调用，而不是 写，您应该指定 --ioengine=sync 参数。 最后，为了在每次写入后调用fdatasync，需要添加--fdatasync=1参数。 此示例中的其他两个选项（--size 和 -bs）是特定于脚本的。 在下一节中，我们将向您展示如何设置它们。

为什么是 fio 以及我们如何学会设置它

在这篇文章中，我们描述了一个真实的案例。 我们有一个集群 Kubernetes 我们使用 Prometheus 监控的 v1.13。 etcd v3.2.24 托管在 SSD 上。 Etcd 指标显示 fdatasync 延迟太高，即使集群什么都不做也是如此。 这些指标很奇怪，我们并不真正了解它们的含义。 集群由虚拟机组成，有必要了解问题出在哪里：在物理 SSD 中还是在虚拟化层中。 此外，我们经常更改硬件和软件配置，我们需要一种方法来评估其结果。 我们可以在每个配置中运行 etcd 并查看 Prometheus 指标，但这太麻烦了。 我们正在寻找一种相当简单的方法来评估特定配置。 我们想检查我们是否正确理解来自 etcd 的 Prometheus 指标。

但是为此，必须解决两个问题。 首先，etcd 在写入 WAL 时创建的 I/O 负载是什么样的？ 使用了哪些系统调用？ 记录的大小是多少？ 其次，如果我们回答这些问题，我们如何用 fio 重现类似的工作负载？ 不要忘记 fio 是一个非常灵活的工具，有很多选项。 我们用一种方法解决了这两个问题——使用命令 的 и 痕迹. lsof 列出进程使用的所有文件描述符及其关联文件。 使用 strace，您可以检查一个已经在运行的进程，或者启动一个进程并检查它。 strace 打印来自正在检查的进程（及其子进程）的所有系统调用。 后者非常重要，因为 etcd 只是采用了类似的方法。

当集群没有负载时，我们首先使用 strace 探索 Kubernetes 的 etcd 服务器。 我们看到几乎所有 WAL 记录的大小都差不多：2200-2400 字节。 因此，在帖子开头的命令中，我们指定了参数 -bs=2300（bs 表示每个 fio 条目的字节大小）。 请注意，etcd 条目的大小取决于 etcd 版本、分布、参数值等，并影响 fdatasync 持续时间。 如果您有类似的情况，请使用 strace 检查您的 etcd 进程以找出确切的数字。

然后，为了更好地了解 etcd 文件系统在做什么，我们使用 strace 和 -ffttT 选项启动它。 因此，我们尝试检查子进程并将每个子进程的输出记录在单独的文件中，并获得有关每个系统调用的开始和持续时间的详细报告。 我们使用 lsof 来确认我们对 strace 输出的分析，并查看哪个文件描述符被用于哪个目的。 于是在strace的帮助下，得到了如上图所示的结果。 同步时间统计确认来自 etcd 的 wal_fsync_duration_seconds 与使用 WAL 文件描述符的 fdatasync 调用一致。

我们浏览了 fio 的文档并为我们的脚本选择了选项，以便 fio 生成类似于 etcd 的负载。 我们还通过从 strace 运行 fio 来检查系统调用及其持续时间，类似于 etcd。

我们仔细选择了 --size 参数的值来表示来自 fio 的整个 I/O 负载。 在我们的例子中，这是写入存储的总字节数。 事实证明它与写入（和 fdatasync）系统调用的数量成正比。 对于一定的bs值，fdatasync的调用次数=size/bs。 由于我们对百分位数感兴趣，因此我们必须有足够的样本才能确定，并且我们计算出 10^4 对我们来说就足够了（即 22 兆字节）。 如果 --size 较小，则可能会出现异常值（例如，几次 fdatasync 调用花费的时间比平时长，并且会影响第 99 个百分位）。

亲自尝试一下

我们向您展示了如何使用 fio 并查看存储速度是否足以让 etcd 正常运行。 现在您可以自己尝试使用，例如，带有 SSD 存储的虚拟机 IBM Cloud.

来源： habr.com