良许Linux教程网 干货合集 etcd:增加30%的写入性能

etcd:增加30%的写入性能

最终的解决方案相当简单,即将现有的卷升级为支持更高 IOPS 的卷,但是在解决问题的过程中我们获得了许多宝贵的经验和教训。

我们的团队负责管理着大约30个自建的 Kubernetes 集群,最近我们需要对 etcd 集群的性能进行分析。

每个 etcd 集群都由 5 个成员组成,这些成员使用 m6i.xlarge 实例类型,最大支持 6000 IOPS。每个成员都有 3 个卷:

  • 根卷
  • 写前日志卷
  • 数据库卷

每个卷都采用了 gp2 类型,大小为 300GB,最大支持 900 IOPS。

image-20240317220659262
image-20240317220659262

测试写性能

首先(在单独的实例上执行)执行etcdctl check perf命令,模拟etcd集群的负载,并打印结果。可以通过--load参数来模拟不同大小的集群负载,支持参数为:s(small), m(medium), l(large), xl(xLarge)

当load为s时,测试是通过的。

image-20240317220702847
image-20240317220702847

但当load为l时,测试失败。可以看到,集群可执行6.6K/s的写操作,可以认为我们的集群介于中等集群和大型集群之间。

image-20240317220705162
image-20240317220705162

下面是使用iostat展示的磁盘状态,其中nvme1n1是etcd的write-ahead-log卷,其IO使用率已经达到100%,导致etcd的线程等待IO。

image-20240317220707641
image-20240317220707641

下面使用fio来查看fdatasync的延迟(见附录):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=benchmark --size=22m --bs=2300 --name=sandbox
...
Jobs: 1 (f=1): [W(1)][100.0%][w=1594KiB/s][w=709 IOPS][eta 00m:00s]
...
fsync/fdatasync/sync_file_range:
sync (usec): min=476, max=10320, avg=1422.54, stdev=727.83
sync percentiles (usec):
|  1.00th=[  523],  5.00th=[  545], 10.00th=[  570], 20.00th=[  603],
| 30.00th=[  660], 40.00th=[  775], 50.00th=[ 1811], 60.00th=[ 1909],
| 70.00th=[ 1975], 80.00th=[ 2057], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2671], 99.50th=[ 2933], 99.90th=[ 4621], 99.95th=[ 5538],
| 99.99th=[ 7767]
...
Disk stats (read/write):
nvme1n1: ios=0/21315, merge=0/11364, ticks=0/13865, in_queue=13865, util=99.40%

可以看到fdatasync延迟的99th百分比为 2671 usec (或 2.7ms),说明集群足够快(etcd官方建议最小10ms)。从上面的输出还可以看到报告的IOPS为709,相比gp2 EBS 卷宣称的900 IOPS来说并不算低。

升级为GP3

下面将卷升级为GP3(支持最小3000 IOPS)。

Jobs: 1 (f=1): [W(1)][100.0%][w=2482KiB/s][w=1105 IOPS][eta 00m:00s]
...
iops        : min=  912, max= 1140, avg=1040.11, stdev=57.90, samples=19
...
fsync/fdatasync/sync_file_range:
sync (usec): min=327, max=5087, avg=700.24, stdev=240.46
sync percentiles (usec):
|  1.00th=[  392],  5.00th=[  429], 10.00th=[  457], 20.00th=[  506],
| 30.00th=[  553], 40.00th=[  603], 50.00th=[  652], 60.00th=[  709],
| 70.00th=[  734], 80.00th=[  857], 90.00th=[ 1045], 95.00th=[ 1172],
| 99.00th=[ 1450], 99.50th=[ 1549], 99.90th=[ 1844], 99.95th=[ 1975],
| 99.99th=[ 3556]
...
Disk stats (read/write):
nvme2n1: ios=5628/10328, merge=0/29, ticks=2535/7153, in_queue=9688, util=99.09%

可以看到IOPS变为了1105,但远低于预期,通过查看磁盘的使用率,发现瓶颈仍然是EBS卷。

鉴于实例类型支持的最大IOPS约为6000,我决定冒险一试,看看结果如何:

Jobs: 1 (f=1): [W(1)][100.0%][w=2535KiB/s][w=1129 IOPS][eta 00m:00s]
...
fsync/fdatasync/sync_file_range:
sync (usec): min=370, max=3924, avg=611.54, stdev=126.78
sync percentiles (usec):
|  1.00th=[  420],  5.00th=[  453], 10.00th=[  474], 20.00th=[  506],
| 30.00th=[  537], 40.00th=[  562], 50.00th=[  594], 60.00th=[  635],
| 70.00th=[  676], 80.00th=[  717], 90.00th=[  734], 95.00th=[  807],
| 99.00th=[  963], 99.50th=[ 1057], 99.90th=[ 1254], 99.95th=[ 1336],
| 99.99th=[ 2900]
...

可以看到的确遇到了瓶颈,当IOPS规格从900变为3000时,实际IOPS增加了30%,但IOPS规格从3000变为6000时却没有什么变化。

IOPS到哪里去了?

操作系统通常会缓存写操作,当写操作结束之后,数据仍然存在缓存中,需要等待刷新到磁盘。

数据库则不同,它需要知道数据写入的时间和地点。假设一个执行EFTPOS(电子钱包转帐)交易的数据库被突然重启,仅仅知道数据被”最终”写入是不够的。

AWS在其文档中提到:

 

事务敏感的应用对I/O延迟比较敏感,适合使用SSD卷。可以通过保持低队列长度和合适的IOPS数量来保持高IOPS,同时降低延迟。持续增加卷的IOPS会导致I/O延迟的增加。

吞吐量敏感的应用则对I/O延迟增加不那么敏感,适合使用HDD卷。可以通过在执行大量顺序I/O时保持高队列长度来保证HDD卷的高吞吐量。

etcd在每个事务之后都会使用一个fdatasync系统调用,这也是为什么在fio命令中指定—fdatasync=1的原因。

 

fsync()会将文件描述符fd引用的所有(被修改的)核心数据刷新到磁盘设备(或其他永久存储设备),这样就可以检索到这些信息(即便系统崩溃或重启)。该调用在设备返回前会被阻塞,此外,它还会刷新文件的元数据(参见stat(2))

fdatasync() 类似 fsync(),但不会刷新修改后的元数据(除非需要该元数据才能正确处理后续的数据检索)。例如,修改st_atimest_mtime并不会刷新,因为它们不会影响后续数据的读取,但对文件大小(st_size)的修改,则需要刷新元数据。

image-20240317220711854
image-20240317220711854

可以看到这种处理方式对性能的影响比较大。

下表展示了各个卷类型的最大性能,与etcd相关的是Max synchronous write:

image-20240317220714531
image-20240317220714531

可以看到etcd的iops一方面和自身实现有关,另一方面受到存储本身的限制。

附录

 

使用Fio来测试Etcd的存储性能

etcd集群的性能严重依赖存储的性能,为了理解相关的存储性能,etcd暴露了一些Prometheus指标,其中一个为wal_fsync_duration_seconds,etcd建议当99%的指标值均小于10ms时说明存储足够快。可以使用fio来验证etcd的处理速度,在下面命令中,test-data为测试的挂载点目录:

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

在命令输出中,只需关注fdatasync的99th百分比是否小于10ms,在本场景中,为2180微秒,说明存储足够快:

fsync/fdatasync/sync_file_range:
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是唯一的I/O,但在实际场景中,除了和wal_fsync_duration_seconds相关联的写入之外,很可能还会有其他写入存储的操作,因此,如果从fio观察到的99th百分比略低于10ms时,可能并不是因为存储不够快。
  • fio的版本不能低于3.5,老版本不支持fdatasync

Etcd WALs

数据库通常都会使用WAL,etcd也不例外。etcd会将针对key-value存储的特定操作(在apply前)写入WAL中,当一个成员崩溃并重启,就可以通过WAL恢复事务处理。

因此,在客户端添加或更新key-value存储前,etcd都会将操作记录到WAL,在进一步处理前,etcd必须100%保证WAL表项被持久化。由于存在缓存,因此仅仅使用write系统调用是不够的。为了保证数据能够写入持久化存储,需要在write之后执行fdatasync系统调用(这也是etcd实际的做法)。

使用fio访问存储

为了获得有意义的结果,需要保证fio生成的写入负载和etcd写入WAL文件的方式类似。因此fio也必须采用顺序写入文件的方式,并在执行write系统调用之后再执行fdatasync系统调用。为了达到顺序写的目的,需要指定--rw=write,为了保证fio使用的是write系统调用,而不是其他系统调用(如 pwrite),需要使用--ioengine=sync,最后,为了保证每个write调用之后都执行fdatasync,需要指定--fdatasync=1,另外两个参数--size--bs需要根据实际情况进行调整。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !

137e00002230ad9f26e78-265x300
本文由 良许Linux教程网 发布,可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
良许

作者: 良许

良许,世界500强企业Linux开发工程师,公众号【良许Linux】的作者,全网拥有超30W粉丝。个人标签:创业者,CSDN学院讲师,副业达人,流量玩家,摄影爱好者。
上一篇
下一篇

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部