《ODCC:2023存储系统时延问题分析与测量白皮书(30页).pdf》由会员分享,可在线阅读,更多相关《ODCC:2023存储系统时延问题分析与测量白皮书(30页).pdf(30页珍藏版)》请在三个皮匠报告上搜索。
1、1存储系统时延问题分析与测量ODCC-2023-0500B编号 ODCC-2023-0500B存储系统时延问题分析与测量开放数据中心委员会2023-09 发布I存储系统时延问题分析与测量ODCC-2023-0500B版权声明版权声明ODCC(开放数据中心委员会)发布的各项成果,受著作权法保护,编制单位共同享有著作权。转载、摘编或利用其它方式使用 ODCC 成果中的文字或者观点的,应注明来源:“开放数据中心委员会 ODCC”。对于未经著作权人书面同意而实施的剽窃、复制、修改、销售、改编、汇编和翻译出版等侵权行为,ODCC 及有关单位将追究其法律责任,感谢各单位的配合与支持。II存储系统时延问题分
2、析与测量ODCC-2023-0500B编写组编写组项目经理:项目经理:李军深圳忆联信息系统有限公司工作组长:工作组长:郭亮中国信息通信研究院贡献专家:贡献专家:张华深圳忆联信息系统有限公司樊文慧深圳忆联信息系统有限公司豆坤三星半导体有限公司冯方三星半导体有限公司胡泽志美团张亮东芝电子(中国)有限公司张北宁东芝电子(中国)有限公司王浩博东芝电子(中国)有限公司梁文俊浪潮电子信息产业股份有限公司路明远浪潮电子信息产业股份有限公司周春法浪潮电子信息产业股份有限公司张希伟浪潮电子信息产业股份有限公司胡振国联想(北京)有限公司黄福帅联想(北京)有限公司吴福磊联想(北京)有限公司林峰江波龙王晋强深圳大普微
3、电子科技有限公司王俊鹿深圳大普微电子科技有限公司李斌希捷III存储系统时延问题分析与测量ODCC-2023-0500B刘佳希捷刘涛西部数据霍锐西部数据张岸西部数据林润斌SK海力士半导体(中国)有限公司李朝兰北京忆恒创源科技股份有限公司孙英达北京忆恒创源科技股份有限公司IV存储系统时延问题分析与测量ODCC-2023-0500B前前 言言带宽和时延不仅是服务器网络系统的性能指标,也是存储部件的基础性能指标。存储系统的时延作为服务器系统从客户端输入到获得客户端输出总响应时间的一个重要组成部分,与网络系统的时延表现一样,一直受到高度的关注。在数据中心客户端反映的问题中,与时延有关的问题的比例占总问题
4、数量的三分之一以上。尤其是在网络系统,运算系统的性能以几何级数增长的今天,时延问题往往成为存储系统需要解决的首要问题。近年来,和 CPU核数的增加,网卡端口数的增加和带宽的增加,以及 GPU 运算单元数的增加的技术进步相反,存储系统的时延随着技术复杂度的增加并没有同等的减少,而且一些新的存储技术的实现是以时延的增加为代价的。硬盘更高的存储密度导致的对振动的更加敏感,固态硬盘的每存储单元的电平数的增加导致的写时间延长都在一定程度上增加了存储系统的时延。数据中心的时延问题一直被高度重视,一个首要的原因是问题发生的范围是几千台服务器,数万个存储部件,从几天发生一次到一天发生几次,这个发生频率是实验室
5、测试中用几个到几百个测试样品无法测到的。而成为故障的 Latency stall-长尾延时,是一种单个 IO的完成时间远大于预期而导致的问题。但是长尾延时问题的定位以及随后的故障分析,目前业界没有一个系统的测试方法。V存储系统时延问题分析与测量ODCC-2023-0500B存储部件的时延问题是数据中心性能表现的一个基础问题。需要有一套与时俱进的测试,评估和优化的方法。VI存储系统时延问题分析与测量ODCC-2023-0500B目目 录录版权声明.I编写组.II前言.IV一、存储系统时延问题的历史和现状.1二、存储器时延的产生原因.2三、时延测试方法,测试模型.6四、时延测试结果分析.15五、减
6、低时延的技术路线以及技术发展展望.21六、结语.1存储系统时延问题分析与测量ODCC-2023-0500B1存储系统时延问题分析与测量存储系统时延问题分析与测量一、一、存储系统时存储系统时延问题延问题的的历史历史和现和现状状存储系统的时延,在客户-服务模型上表现为服务请求端发出命令到服务端完成命令所需要的时间。数据中心应用对时延的感知是在应用层。可能发生时延的部分,存在于存储系统的层级结构中的所有传递节点。由于每一个传递节点都有数据的封装、解封,数据重排,队列,访问控制,资源的申请/释放,纠错,重传等行为,由此导致的时延问题的测量就成为一个复杂的系统问题。而对于时延问题的解法更多地表现为一个取
7、舍的行为,这样就更加增添了测试和问题复现的复杂度。存储系统时延问题分析与测量ODCC-2023-0500B2在以硬盘为主要载体的时期,存储系统的读写命令时延在 10 毫秒到 30 秒之间,这个时间主要由于切换读写操作位置需要进行磁盘的寻道操作,而寻道操作需要硬盘至少旋转一周才能完成。在 SSD中由于没有硬盘那样的寻道过程,两个读写指令之间的时延会减小,但是减小的幅度仍然受限于存储介质的响应时间。目前的 SSD 这个响应时间在 50微秒到 5毫秒的范围。用户对时延的感知并非是直接的。由于用户是通过文件打开,关闭,读写的操作使用硬盘和 SSD,通常的文件操作需要的时间远大于一个单一的读写指令完成的
8、时间,因此用户对存储器的时延的感觉首先来自于存储部件的带宽。如拷贝一个文件尺寸为 1G 的文件通常需要 10 秒左右的时间。而此时主机与存储部件的命令和数据交换的实际时延平均在 1毫秒以下。二、二、存储存储器器时时延延的产生的产生原因原因硬盘和 SSD 的命令时延的发生机理,与用户的普遍感知是不同的。在绝大多数状况下,硬盘和 SSD 的单个读写命令响应时间在 1秒以内,但是硬盘和 SSD 的设计的最长命令响应时间并不是如此。使用 sg_opcoeds-R 指令可以看到 SAS SSD 的每个指令的标准响应时间以及最大响应时间,如下图所示,指令的标准响应时间是 1 秒,多数指令的最长响应时间为
9、5 秒,但是很多指令的最长响应时间能达到 60秒甚至更长。存储系统时延问题分析与测量ODCC-2023-0500B3这些最长命令响应时间发生几率很低,但是却是存储部件设计的必须。硬盘和 SSD 的数据存储机制的底层物理机制是一些模拟量的生成,保持和测量过程。这些过程远比数字世界的 0-1状态复杂。存储系统时延问题分析与测量ODCC-2023-0500B4这些模拟量的生成,保持和测量对应的是存储器的写入,存储和读取操作。这些操作对应的是大量连续的电压和电流的模拟量的信号处理过程,这些过程都会在各个环节发生抖动,偏移并在数模转换和模数转换过程中发生误码,这些误码需要相应的纠错机制进行处理。大多数的
10、情况下处理过程是不会造成可测量到的时延,但是如果瞬时的误码较大,就会激发一系列的重试过程。这些重试过程对于硬盘和 SSD 的数据可靠性是必需的,但是也会发生相应的可感知的时延。下图示意的是一个硬盘的一次重试的流程图。这个重试的过程在设计中可以重复 255 次,如果每次平均是 12 毫秒的话,最长就会超过 30秒。实际应用中的问题在于,大多数的应用程序和驱动程序对这些硬盘和 SSD 设计中需要的命令最长响应时间的处理机制并不完善,存储系统时延问题分析与测量ODCC-2023-0500B5常见的处理方法就是几次重试之后就丢弃文件或者丢弃存储卷,这样就会随之产生数据丢失甚至应用程序的崩溃。在绝大多数
11、的测试场景和用户使用场景,这些命令所对应的最长命令响应时间是不会遇到的。但是如果驱动程序的设计以及应用程序的设计没有考虑到对这些最大时延进行恰当处理,就会出现丢失数据甚至丢失存储卷的严重问题。在读写操作时根据可能的最大响应时间设计响应的延时处理机制和等待机制,是驱动程序设计和软件系统设计需要关注的问题。这种由于存储部件基于对数据读写一致性,数据安全性的保证而发生的时延是硬盘和 SSD 固件设计必须做的,因为读出和写入数据如果不一致是比一个指令的响应时间相应较长更加不能接受的。存储系统时延问题分析与测量ODCC-2023-0500B6三、三、时时延测试延测试方方法法,测试测试模型模型对时延的测试
12、首先是测试与用户感知对应的文件操作的时延。在操作系统中对硬盘和 SSD 时延的测试工具分为内核态的测试工具软件和用户态的测试工具软件。在工程中还会采用分析仪来测量数据通道的指令,数据和状态转换时间对应的时延。在用户态基于文件系统读写指令完成时间的工具软件的测量原理是对某一个或一个系列的打开文件,进行文件读写,关闭文件等操作指令计时,或者打开一个裸设备进行读写操作并对指令完成时间计时。常用的工具有 iozone,fio等。在内核态的测试工具是由操作系统提供的计数器接口实现的。在 linux中有 iostat,iotop 以及 blktrace等常用工具。存储系统时延问题分析与测量ODCC-202
13、3-0500B7其中,iozone 可以测量文件系统下的文件操作命令响应时间。fio 可以对通过文件系统的文件操作以及不通过文件系统直接调用内核的块设备读写过程来测试硬盘和 SSD的命令响应时延。Linux系统中现有的测试工具是可以用来收集时延有关问题的状态和现场的。以下工具包是时延测试方法需要的。sysstat工具包:iostat,saratop工具包block trace 工具包debug fssmart logtelemetry logSYSSTAT工具包sysstat 工具里有 iostat 和 sar 工具可以用来监控读写的等待时间,查看 r-await 和 w-await 的数值来
14、实时监控系统块设备的 latency.我们可以使用 sysstat 工具来监视 Linux 系统的性能,包括磁盘I/O 性能。sysstat 是一个强大的日志记录和监视工具,可用于监视系统性能并解决问题。它可以记录和跟踪 Linux 系统中发生的几乎所有事情。我们可以使用以下命令安装 sysstat:sudo apt-get install sysstat要查看磁盘 I/O 性能,可以使用iostat命令。例如,要查看每秒读取和写入的字节数,使用以下命令:存储系统时延问题分析与测量ODCC-2023-0500B8iostat-d-k 1我们可以使用 sysstat 的 iostat 以及 sa
15、r 工具获得文件访问的时延数据分布状况,这个时延是从文件系统调用开始到设备的读写操作和数据传输操作结束。同时,我们可以从 atop 的历史测试数据获得主机到设备间的数据读写操作和数据传输操作对应的时延。使用 blktrace可以获得更加详细的单步骤的命令响应时间。使用 debug fs 里面的 nvme event trace 可以获得单个 nvme 指令的指令码以及命令执行时间。iostat-x 可以看到从系统加电以来的 io 状况。iostat-xmd n 可以实时每 n 秒间的 io状况。存储系统时延问题分析与测量ODCC-2023-0500B9iostat 是一个用于监控 CPU 利用
16、率和磁盘 I/O 活动的工具,它可以显示每个设备的平均服务时间(svctm)和平均等待时间(await),但这些指标并不是直接测量设备时延的。平均服务时间(svctm)表示设备完成 I/O 请求所需的平均时间,包括寻道时间、旋转延迟和数据传输时间。平均等待时间(await)表示 I/O 请求在队列中等待和在设备上被服务所需的总时间。我们可以使用 sar 工具来监控磁盘 I/O 活动并获取有关设备的平均等待时间(await)的信息。sar 是 sysstat 工具包中的一个实用程序,它可以收集、报告和保存系统活动信息。要使用 sar 来监控磁盘 I/O 活动并获取有关设备的平均等待时间(awai
17、t)的信息,我们可以使用以下命令:sar-d-p 1存储系统时延问题分析与测量ODCC-2023-0500B10这个命令会每秒运行一次 sar,并显示磁盘 I/O 活动的信息。在输出中,我们可以找到名为 await 的列,它表示 I/O 请求在队列中等待和在设备上被服务所需的总时间。请注意,要使用 sar 工具,用户需要先安装 sysstat 软件包并启用数据收集。我们可以使用用户的发行版的包管理器来安装 sysstat软件包,并按照文档说明启用数据收集。我们可以使用 atop 工具来监控 SSD 的实时性能参数。atop 是一个用于监控系统资源使用情况的工具,它可以显示 CPU、内存、磁盘和
18、网络等资源的使用情况。ATOP,HTOP,IOTOP 工具包atop 工具可以实时监控系统块设备的 io 状态,同时监控 cpu,内存以及正在运行的进程的资源占用。atop 可以在后台运行,收集 cpu,内存,存储器的使用率,占用情况。默认 10 分钟一个记录。记录可以看到每个进程的命令行以及各种资源的总体情况和进程的占用情况。atop-r 可以回放记录的场景。使用 c,d,m键可以切换 cpu,存储,内存的统计。使用大写的 C,D,可以对进程按照,存储,内存的使用量按照大小排序。要使用 atop 来监控 SSD 的实时性能参数,我们可以在终端中运行 atop 命令:atop存储系统时延问题分
19、析与测量ODCC-2023-0500B11运行 atop 命令后,用户将看到一个交互式界面,其中显示了系统资源的实时使用情况。我们可以按 d 键来切换到磁盘视图,查看磁盘 I/O 活动的信息。在磁盘视图中,我们可以看到每个设备的读写速度、繁忙时间百分比和 I/O 请求队列长度等信息。这些信息可以帮助用户了解SSD 的实时性能。请注意,要使用 atop 工具,用户需要先安装 atop 软件包。我们可以使用用户的发行版的包管理器来安装 atop 软件包。HTOP 可以进一步跟踪到进程的系统调用,IOTOP 可以实时记录和显示系统的 IO.可以定时记录 io 状态。这些软件包在发行版的 Linux中
20、基本没有默认包含,需要自行安装。debugfsLinux 的内核 debug fs 可以看到主机对 nvme 盘发出的 nvme 指令和相应的时间。存储系统时延问题分析与测量ODCC-2023-0500B12使用 echo 1 /sys/kernel/debug/tracing/events/nvme/enable 来打开内核的 nvme trace。我们可以使用 debugfs 工具来调试 Linux 的 HDD 和 SSD。Debugfs 是一个文件系统,用于在 Linux 内核中提供调试信息。它允许用户查看文件系统的内部状态,包括文件系统的超级块、inode、目录项和数据块。要使用 de
21、bugfs,请确保已安装 e2fsprogs 软件包。要挂载 debugfs,请使用以下命令:mount-t debugfs none/sys/kernel/debug要查看文件系统的 inode,请使用以下命令:debugfs-R stat /dev/要查看文件系统的数据块,请使用以下命令:debugfs-R dump /dev/block trace 和 blockmon使用 blkiomon来动态显示 IO栈情况,命令如下:。blktrace/dev/nvme0n1-a issue-a complete-w 180-o-|blkiomon-I 10-h-存储系统时延问题分析与测量ODCC
22、-2023-0500B13其中和 BLKTRACE 相关的概念说明如下一个 I/O请求进入 block layer之后,可能会经历下面的过程:Remap:可 能 被 DM(Device Mapper)或 MD(Multiple Device,Software RAID)remap 到其它设备Split:可能会因为 I/O 请求与扇区边界未对齐、或者 size 太大而被分拆(split)成多个物理 I/OMerge:可能会因为与其它 I/O 请求的物理位置相邻而合并(merge)成一个 I/O被 IO Scheduler依照调度策略发送给 driver被 driver 提交给硬件,经过 HBA、
23、电缆(光纤、网线等)、交换机(SAN 或网络)、最后到达存储设备,设备完成 IO 请求之后再把结果发回。Q 即将生成 IO请求G IO请求生成I IO请求进入 IO Scheduler队列D IO请求进入 driverC IO 请求执行完毕Q2G 生成 IO请求所消耗的时间,包括 remap 和 split的时间;G2I IO 请求进入 IO Scheduler 所消耗的时间,包括 merge 的时间;I2D IO 请求在 IO Scheduler中等待的时间;D2C IO 请求在 driver和硬件上所消耗的时间;存储系统时延问题分析与测量ODCC-2023-0500B14Q2C 整个 IO
24、 请求所消耗的时间(Q2I+I2D+D2C=Q2C),相当于 iostat的 await。其中 D2C可以作为硬件性能的指标;I2D 的数值可以作为 IO Scheduler 性能的指标。通常具有较大的I2D的系统的有效带宽会较高。目前的 nvme 盘都支持 smart log 和 telemetry log.Smart log 的意义在于记录盘的基本信息,部件的 module name,系列号,固件版本,读写量,如有出现过错误,会有错误类型的统计。Telemetry log 是通用的 nvme 盘的 debug 信息,如果在抓取之前出现过 nvme 盘的固件需要处理的异常,如不可恢复读错误,
25、或者写错误,在 telemetry log 里面会有记录。SSD 内部由于误码,噪声,电压偏移造成的读错误是造成 SSD命令响应时间变长的主要原因,而且随之 SSD 盘的写入量增加造成存储系统时延问题分析与测量ODCC-2023-0500B15的每个存储单元的平均 retention 时间减小,这种重读的发生几率会比较高。对系统中所有 SSD 的 latency 时间的跟踪可以发现这种变化趋势,并找到发生的时间和位置。四、四、时时延延测试结果测试结果分析分析可能发生时延问题的节点,存在于存储系统的层级结构中的所有数据交换节点。由于每一个传递节点都有数据的封装、解封,数据重排,队列,访问控制,资
26、源的申请/释放,纠错,重传等行为,由此导致的时延问题的测量就成为一个复杂的系统问题。因此时延问题的现场记录,需要尽可能详细的各个层级的状态。这是一个时延测试的例子:使用 iostat看到的时延数据,在使用散碎数据块的状态下,使用libaio 这个异步 io 引擎,记录了较高的时延。但是同时可以看到,系统在时延较高时 iops并没有下降而且还有总体较高的数据吞吐量。存储系统时延问题分析与测量ODCC-2023-0500B16这是因为异步 io 的设计思想就是通过数据的重排获得较高的带宽利用率,减少一定数据量的总体 io时间占用。时延测试数据的解析:公平不一定效率高这个例子是在大数据块和小数据块同
27、时传输时,由于 SSD 需要以同等优先级处理所有的队列,因此两个队列具有相同的 iops。这样使用小数据块的队列由于没有做 io 合并,虽然命令队列是连续的块但是带宽比小数据块单独传输减低了很多。但是如果 SSD 的固件设计成平均分配带宽,由于小数据块的系统开销大,最大带宽很低。这样总体的带宽利用率就会严重下降。存储系统时延问题分析与测量ODCC-2023-0500B17iozone 的测试结果以及分析:在运行用直接 IO 参数运行 iozone的同时使用 iostat 抓取主机对 SSD 的读写指令,发现在运行 iozone时,虽然 iozone 测试发生的读写数据量是对等的,但是在 ios
28、tat 中看到只有写数据没有读数据的操作。因此下表中的都操作的带宽差异以及对应的时延,是发生在主机的内存和文件系统的驱动之间,是由文件系统对内存中块设备读写缓存的操作导致,而不是块设备的驱动调用硬盘 SSD的读写指令后硬盘 SSD 实际的读命令执行和读数据传输的时延造成。存储系统时延问题分析与测量ODCC-2023-0500B18对 SSD 用 fio 进行 jesd219 数据块分布类型读写压力测试一天,运行过程中抓取 iostat数据进行分析,可以看到读写操作的延时在逐渐增加。这个延时的增加与 SSD 内部数据的块分配表项目的不连续以及对小于 SSD 最小写单元的数据进行合并处理的开销有关
29、。对一个使用了一段时间的 SSD 进行读性能扫描,可以得到如下的结果示意图图中可见 SSD 的读指令响应时间是弥散的。原因就是上图所示,SSD的写操作的历史会影响测试时的读写操作的性能。存储系统时延问题分析与测量ODCC-2023-0500B19对 SSD 进行 trim 操作可以减低这种离散状态的影响。目前的主流操作系统默认在 1 周到 1 个月的时间间隔会对 SSD 的文件系统进行一次 trim操作。这种数据的离散以及后台进行的介质扫描和 SSD 的 GC 操作对硬盘和 SSD 的性能影响可以使用总线分析仪进行深入分析。总线分析仪的时延显示的是数据链路上数据传输特性。下图中蓝线表示的是数据
30、传输时延。阶梯状的增加是当时总线上没有数据传输,而前面的数据传输所对应的时延随着时间的增加,进行非数据传输的信元交换的增加而线性地增加。存储系统时延问题分析与测量ODCC-2023-0500B20总线分析仪看到的命令和信元的时延.使用总线分析仪抓取主机到存储器的命令序列是目前业界主流的 debug 方式。这种方式不能实时对大批量的生产状态的存储部件进行监控和命令流的抓取。debugfs的 trace功能可以达到类似的目的。总线上的非数据信元造成的时延增加现象:存储系统时延问题分析与测量ODCC-2023-0500B21下面是一个 3.10内核+NVMeSSD问题的测试和解决的例子:CentOS
31、 4.18 及以下的版本内核存在一个跟 NVMe SSD 相关的漏洞,会概率性的导致 IO 阻塞问题。具体表现就是 iostat 的 util 一直显示 100%,但是其他 IO 参数几乎都是 0(除了队列深度这一项有值外,其它都是 0),总体表现就是 IO 阻塞,新的 IO 无法下发。使用 iostat可以看到问题所在。连续内存几乎消耗殆尽:解法:问题的本质是 Kernel版本在 4.18 之前的版本有已知 bug,当连续内存空间消耗较多的时候,就会概率性的发生 IO 阻塞的问题。经过检查 kernel 的更新文档,采用新版本的 kernel 或者修改 NVMe的 max_sectors_k
32、b为 128可以解决这个问题。五、五、减减低低时时延延的技术的技术路线路线以以及及技术发展展技术发展展望望存储系统时延问题分析与测量ODCC-2023-0500B22对于由于设计导致的偶发的硬盘和 SSD 时延,由于误码的难以避免,只能通过增加数据封装的复杂性,采用能容忍更小信噪比的数据解码算法来减少。对于硬盘,由于高温和振动会造成读数据过程的物理量抖动从而增加误码,那么减低硬盘的温度以及减少硬盘收到的振动可以减低误码,从而有效地减少响应的时延。对于 SSD,除了采用高速和高复杂度的 lDPC 编码外,降低温度,增加数据保持时间从而减低读操作的误码率,以及采用多级缓存减少常用数据的读操作时延,
33、通过使用低时延部件减低写操作时延,是目前主流的减低时延的技术方向。在云存储应用中,使用 SRIOV 技术,与传统的使用文件系统下的大文件构造存储池的方式,能够避免文件系统本身造成的时延。时延结果表明,使用 SRIOV 的虚拟机的时延可以达到传统的存储池方式的十分之一。下图就是使用 SRIOV 方式的带宽和使用传统存储池方式的虚拟机性能比较。带宽相差 10 倍,也就是 SRIOV 方式的时延是传统存储池方式的十分之一。1存储系统时延问题分析与测量ODCC-2023-0500B六六、结语结语存储部件的时延是目前数据中心应用非常关心的一个技术要点。由于对时延的感知是在应用层,而时延问题发生在文件系统
34、,操作系统以及设备内部,甚至与环境也有相关性,而可能发生时延的部分,存在于存储系统的层级结构中的所有传递节点。由于每一个传递节点都有数据的封装、解封,数据重排,队列,访问控制,资源的申请/释放,纠错,重传等行为,由此导致的时延问题的测量和解决就成为一个复杂的系统问题。而对于时延问题的解法更多地表现为一个取舍的行为,这样就更加增添了测试和问题复现的复杂度。在这种情况下,时延问题的分析和解决就需要进行系统有效的有针对性的测试,排除所有可能产生问题的疑点,才有可能有效解决问题。同时,采用一些有效的降低时延的设备端,数据链路层和主机端技术路线,可以在较大概率上减低存储系统的总体时延。由于硬盘和 SSD 的技术发展趋势和市场趋势是需要更大的容量,需要更高的可靠性,同时兼顾速度的提高,因此时延问题的存在将是长期性的,而且会不断地表现出新的技术侧面和技术链相关性,因此,本项目所涉及的技术链条分析以及相应的解决方案也需要随着新技术的发展而不断更新,深入和完善。