FAST20 论文学习

BCW: Buffer-Controlled Writes to HDDs for SSD-HDD Hybrid Storage Server

原文地址

为了兼顾访问性能和硬件成本,目前有不少的存储系统都采用了混合存储(Hybrid Storage),使用 SSD 来提供微秒级访问,配合 HDD 来降低存储成本。在实现细节上,一般会使用 SSD 来服务用户的写操作(cache),然后通过后台操作批量将 SSD 存储的数据搬迁到 HDD 进行更长时间的存储。

阿里云的盘古存储系统采用了类似设计来实现混合存储,在观察了生产环境中的使用情况后,论文作者发现:系统对 SSD/HDD 的利用上存在明显的不均衡现象,SSD 经常被过度使用而 HDD 的利用率却相对较低,尤其是 write-intensive workload。

下表中四种负载分别来自于:(A)计算型任务;(B)存储型任务;(C、D)结构化存储。

在写负载持续增高的情况下,以 SSD 为主的混合存储系统会面临如下问题:

  1. SSD 寿命:持续的高负载会缩短 SSD 寿命,从数据上来看,SSD 的每日写入情况经常触及所设上限,即 DWPD (Drive Writes Per Day)。
  2. SSD 性能:在写入密集的情况下,大量的写请求可能会超过 SSD 的处理能力,导致请求在 SSD queue 中排队,引起长尾延时;除此之外,请求的增加也会更频繁地触发 SSD 的 GC,导致性能下降。

对于此问题,一个直接的解法是引入更多的 SSD,无论是加机器还是单机上增加 SSD,这都能降低单个 SSD 承担的压力,但会引入额外的硬件成本,性价比很低。

是否能够在不增加硬件且不降低系统性能的情况下解决此问题呢?

通过大量针对 HDD 的实验,作者发现,在进行连续的顺序写时,HDD 的延时表现出了显著的周期性。在持续写入的时间线上,延时大致能划分为 fast -> slow -> mid 三个阶段,以 4K 大小的请求为例,fast 阶段持续 60ms,延时为 35us,然后是一个瞬时的 slow 阶段,延时为 12ms,接着的 mid 阶段持续 40ms,延时为 55us,之后则是 mid/slow 交替,直至某个时间点回到 fast(10TB 西数 HDD 上并没有展现完整的周期,但 8TB 西数 HDD 的测试上体现了这一点,下图)。

可以看到,在 fast/mid 阶段,HDD 的延时在 us 级,这和 SSD 非常接近。引起这一现象的源头是 HDD 内部的 buffer 机制,HDD 会在其内置的 DRAM 中给写请求划分一块 buffer,当它将一个请求存入 buffer 后,它会向上层返回成功。而当 buffer 达到一定阈值后,HDD 会将 buffer 中的数据写入物理介质,这个刷盘过程会阻塞后续的写入,从而导致延时增大。除此之外,如果 HDD 持续 idle,它也会隐式地执行此操作来清空 buffer;另外 sync 的调用也可以触发 buffer 的刷盘。

这个发现为前述问题提供了一个解决思路: 如果我们能够预测 HDD 下一次写入的情况,在它能够提供微秒级延时时,将请求交由 HDD 进行处理。

为了更好地描述 HDD 的这一特性,论文中对此进行了建模,F、M、S 分别对应上述 fast/mid/slow 阶段,当进入 M/S 阶段后,需要经过 "sync",才能使时延回到 F。对于不同型号的 HDD,模型参数表中的 L, W, F 会有差异,但均可通过事先测试来获取,具体可参见原文,此处不再赘述。

Design

Write-state Predictor

在模型的基础上,文中根据当前的 buffer 大小以及写入状态(F、M、S)构建了对应的预测状态机,进而设计了预测算法。

此算法中的 ADW 是个持续累积值,需要由外部调用方(下文中的 BCW 算法)来进行清理,除此之外,算法逻辑比较清晰,此处也不展开描述了。

值得一提的是,作者对预测算法的准确性进行了验证:以 128K 为单位连续写入 100GB 数据,每写入 1GB 后就调用一次 sync 操作。结果显示,算法对 F、M、S 三种状态的预测准确率能够达到 99.5%、98.1% 和 60.3%。可见,对 F/M 的预测还是很准确的,对 S 状态的错误预测是因为算法更侧重于保证性能,毕竟从性能角度来看,相比将 S 预测为 F/M,把 F/M 预测为 S 会造成更严重的影响。

Buffer-Controlled Writes (BCW)

基于状态预测算法,作者实现了写入控制算法(BCW),以尽可能保证所有的用户请求都在 HDD 处于微秒时延的状态(F/M)时被写入。

这个算法同样不能独立工作,仍需要外部算法在 HDD 处于微秒时延时向写入队列转发请求,算法中通过 flagHDD 来告知外部算法是否可以转发。

BCW 的一个主要设计在于其写入 padding 数据的逻辑:

  • PS padding:由于预测算法会在 F/M 状态下的 ADW 接近 Wf 或 Wm 时返回 S 状态,BCW 根据此可以得知,buffer 即将被填满,所以它通过主动地构造 PS padding 数据(较大,64KB)来触发 slow 写入,直到某次写入的时延对应的状态不再为 S,BCW 即认为当前 HDD buffer 以恢复到能够以微秒时延写入数据的状态,它会重置 ADW。
  • PF padding:考虑到低负载的情况下,HDD 可能不会收到任何写入请求(可能 SSD 足够处理),为了保证算法的稳定性,BCW 会在非 S 状态时不断写入 PF padding(较小,4KB)。算法中仅在预测状态为 M 的情况下进行此操作,这是因为当 sync 或者 HDD 内部隐式 flush 被执行后,buffer 会进入到稳定的 F 状态,此时无需做任何的 padding。

Mixed IO scheduler (MIOS)

正如 BCW 中提到的,它需要外部算法根据其设置的 flag 来决定此时是否能将请求转发给 HDD,因此,整个设计上需要一个调度器,根据 HDD/SSD 的状态来进行综合调度,决定每一个写入请求最终由谁处理。

如图所示,本文设计的调度策略所参考的指标除了前述 HDD 的状态/flag 外,还引入了 SSD 队列长度 l(t)。调度算法如下:

算法的基本逻辑很容易理解:

  • 当 flag 被设置时,HDD 一定处理 S 状态,此时请求只能由 SSD 处理。
  • 当 HDD 处于 F/M 时,如果 SSD 并不忙(队列长度 l(t) 并非超过设置的阈值 L),交由 SSD 处理对性能最好。

关于阈值 L 的选择,文章给出的经验值为 1,Evaluation 部分也给出了相应的验证来说明这一点。

在基本逻辑之上,调度算法还被细化为 MIOS_E 和 MIOS_D,两者的区别在于当 SSD 不忙且 HDD 处于 F 状态时,前者会将请求转发给 HDD 以进一步地降低 SSD 的负载。

需要注意的是,MIOS 算法需要拥有对 HDD 的完全控制,所以当读请求到来时,BCW 算法会被挂起来处理此请求,此时不能再向该 HDD 写入数据。这也比较容易理解,当读请求到达时,HDD 的磁头可能就跑到了另外的地方,无法再保证连续写的要求。因此,对于 read-dominated workload,MIOS 并不适用。

Evaluation

  • Baseline:纯 SSD 写入。
  • MIOS_E
  • MIOS_D

Production Workloads

论文使用了前述的 4 种 workload 对 MIOS 算法进行了详尽的实验,结果如下。

时延对比:无论是平均时延还是长尾时延,MIOS 都拥有更好的效果。

SSD 队列长度分布也体现了长尾延时的降低。

不同请求大小下的平均时延:对于大请求,MIOS 的效果比 baseline 更差,一方面是在写入大请求时,SSD 本身比 HDD 拥有更佳的性能(内部并行机制),另一方面则是大请求相对较少,被 SSD queue length 或 GC block 的概率也较低。

MIOS_E vs MIOS_D

因为 MIOS_E 允许在 SSD 不忙的情况下将请求转发给 HDD,所以相比 MIOS_D,它会转发更多的请求,但也会导致时延上升。这个现象对于 workload A 特别明显,从表 3 可知,相比其他三个 workload 而言,它对 SSD 的 workload 很低,这也使得在 MIOS_D 下,大部分请求仍旧由 SSD 进行处理,能够获得更好的性能,但在 MIOS_E 下,请求被转发给 HDD,导致了性能下降。

但这并不意味着 MIOS_E 毫无用武之地,当 SSD 的写入性能本身就一般的情况下,即使它的 queue length 并未表现出忙的特征,但实际写入的延时可能依旧较高,此时转发给 HDD 反而能获取更好的性能。作者尝试将 SSD 替换为 660p(原先为 960EVO,性能更佳)后,MIOS_E 表现非常好。

除了性能以外,因为 MIOS_E 会收到更多的 HDD 请求,从而算法中的 padding 数据也会增多,所以它相比 MIOS_D 会产生更多的空间浪费。另外,MIOS 算法将部分 SSD 负载搬迁到 HDD 上执行,会有效提高 HDD 的利用率,但仍需要确认:HDD 仍有足够能力来承担数据搬迁(SSD->HDD)任务。实验对此进行了验证,有兴趣的同学可以参考原文,此处不再赘述。

Write Intensity

由于 MIOS 利用了 HDD 连续写的特性,所以它非常适合 write-intensive workload,作者对此进行了补充测试(X 轴代表的是发送间隔,越小数据量越大)。

可以看到,当写压力很大的情况下(20-60us),SSD 的性能会受到排队和 GC 的影响,平均时延和长尾时延都要高于 MIOS。而当压力降低到可承受范围后,SSD 将保证稳定的写入性能,此时,MIOS_D 退化为纯 SSD 写入(因为 SSD 无忙特征),但 MIOS_E 依旧会转发部分请求至 HDD,所以相对之下会有更高的平均和长尾时延。

总结

总的来说,MIOS 充分利用了 HDD 在连续写场景下的时延周期特性,找到了一种在混合存储下保证微秒级写入和存储成本二者兼得的方法,尤其对于 write-intensive workload,未受到读请求打断的 MIOS 效果会非常好。

整体的设计还是非常容易理解的,但发现这一特性并设计出能够稳定运行的算法(生产环境必须),相信作者们花费了不少功夫。

原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/515965.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

企业微信H5_消息推送接收消息回调配置、内网穿透到本地

文章目录一、环境准备1. 阅读文档2. 登录管控台3. 编辑配置4. 内网穿透5. 测试案例6. 公网访问验证7. 保存配置8. 验证URL有效性二、源码分享2.1. 后端源码2.2. 前端源码一、环境准备 1. 阅读文档 官网文档:https://developer.work.weixin.qq.com/document/path/9…

Serverless 选型:深度解读 Serverless 架构及平台选择

作者 | 悟鹏 阿里巴巴技术专家 导读:本文尝试以日常开发流程为起点,分析开发者在每个阶段要面对的问题,然后组合解决方案,提炼面向 Serverless 的开发模型,并与业界提出的 Serverless 产品形态做对应,为开发…

CSDN 星城大巡礼,长沙“科技之星”年度企业评选正式开启

2020年,长沙市委主要领导发出“软件产业再出发”的号召,颁布了软件三年行动计划。今年5月,CSDN 作为专业的 IT 社区,与长沙高新区签约,将全国总部落户长沙,这一战略决策,让CSDN与长沙的联结进一…

企业微信H5_集成消息解密类,消息推送Get及Post回调处理

文章目录一、 验证URL有效性1. 阅读文档2. 文档分析3. 加解密方案说明4. 下载加解密算法5. 案例分析二、实战集成2.1. 工具类拷贝2.2. 依赖引入2.3. 案例1集成2.4. 参数处理2.5. 重启项目2.6. 验证URL有效性2.7. 验证三、消息接收与处理3.1. 文档阅读3.2. 案例2拷贝3.3. 参数处…

新一代高效Git协同模型AGit-Flow详解

【以下为分享实录,有删节】 Git工作流概述及AGit-Flow的优势 目前,Git已成为源代码管理的标准和基础设施。“为什么Git能这么成功”?Git的创建者Linux在Git十周年的一次采访中,道出了其中的奥秘: The big thing abo…

云原生人物志|APISIX温铭:让API网关“666”

云原生已无处不在,《云原生人物志》是CSDN重磅推出的系列原创采访,我们关注云原生中每一个技术人、公司的身影。知微见著,窥见云原生价值与趋势。 作者 | 宋慧 出品 | CSDN云计算 头图 | 付费下载于IC Photo 第一期,我们采访了唯…

xshell和Xftp连接Linux

xshell和Xftp连接Linux 简单介绍下这两种工具: Xshell :远程连接linux,执行命令行; Xftp :远程连接linux,可视化的实现windows和linux之间的文件传输; 2.关于如何获知linux的ip地址 在虚拟机中登录用户,输入用户名,密码: 此处注意一点:注意区分密码的大小写!!!,因为你在设置密…

企业微信_客户联系,获取客户及客户群列表及详情

文章目录一、调试接口1. 阅读文档2. 权限配置3. 指定应用二、POSTMAN调试接口2.1. 获取配置了客户联系功能的成员列表2.2. 获取客户列表2.3. 获取客户详情2.4. 获取客户群列表2.5. 获取客户群详情三、实战演练代码拆解3.1. 获取配置了客户联系功能的成员列表3.2. 获取客户列表3…

Flink 与 Hive 的磨合期

有不少读者反馈,参考上篇文章《Hive 终于等来了 Flink》部署 Flink 并集成 Hive 时,出现一些 bug 以及兼容性等问题。虽已等来,却未可用。所以笔者增加了这一篇文章,作为姊妹篇。 回顾 在上篇文章中,笔者使用的 CDH 版…

使用arthas排查cpu飙高问题

文章目录一1. 下载arthas2. 启动3. 选择指定jvm进程4. 筛选线程5. 日志分析一 官方文档:https://arthas.aliyun.com/doc 1. 下载arthas curl -O https://arthas.aliyun.com/arthas-boot.jar2. 启动 直接用java -jar的方式启动: java -jar arthas-bo…

oracle 数据库 字符串函数

oracle 数据库 字符串函数 介绍oracle对字符串的操作函数,如图所示,测试字段为:STUDENT 表的 STUNAME 字段 ps:oracle字符串索引从1开始 1.定位索引函数:instr() instr(str,char,begin,n) str:源字符串 char:目标字…

jvm如何排查生产环境cpu飙高的问题

文章目录一、生产环境 cpu 飙高产生的原因?1. CAS 自旋没有控制自旋次数2. 死循环3. 阿里云 Redis 被注入挖矿程序4. 服务器被 DDOS 工具攻击二、windows环境下如何排查cpu飙高问题2.1. 任务管理器2.2. jvisualvm三、环境下如何排查cpu飙高问题3.1. 监控命令3.2. 使…

云原生人物志|华为云CTO张宇昕:云原生已经进入深水区

云原生已无处不在,《云原生人物志》是CSDN重磅推出的系列原创采访,我们关注云原生中每一个技术人、公司的身影。知微见著,窥见云原生价值与趋势。 作者 | 宋慧 出品 | CSDN云计算 头图 | 华为云网站 云原生成为云计算领域当之无愧的最热门技…

开箱即用,Knative 给您极致的容器 Serverless 体验

作者 | 冬岛 阿里巴巴技术专家 导读:托管 Knative 开箱即用,您不需要为这些常驻实例付出任何成本。结合 SLB 云产品提供 Gateway 的能力以及基于突发性能型实例的保留规格功能,极大的节省您的 IaaS 开支,您支付的每一分钱都没有浪…

oracle 11g 数据库cmd修改用户名密码及创建用户

oracle 11g 数据库cmd修改用户名密码及创建用户1. 数据库oracle 11g cmd命令修改用户名和密码1.1. 前言1.2. cmd窗口登录oracle1.3. 更改system用户的密码1.4. 测试修改成果2. 创建新用户并赋予权限2.1. cmd窗口登录oracle2.2.创建用户2.3.分配权限2.4.oracle用户权限等级1. 数…

全国交通智慧升级,阿里云视频上云打造高速公路“视觉中枢”

2019年底,交通运输部办公厅发布《全国高速公路视频联网监测工作实施方案》和《全国高速公路视频联网技术要求》,全面加快推进可视、可测、可控、可服务的高速公路运行监测体系建设。2020年底,基本建立全国高速公路视频联网监测管理机制和制度…

mysql 与 redis 如何保证数据一致性问题 ?

1.先更新 mysql 数据, 再手动清除 Redis 缓存 , 最后重新查询最新的数据同步到Redis中,保证最终一致性。 2.更新 mysql 数据, 在采用 mq 异步的形式 同步数据到 Redis 中 。 缺点: 延迟概率就比较大 优点&#xff1a…

赠书 | 隐私计算:让你的数据信息不再“裸奔”

来源 | 人民数字FINTECH责编 | 晋兆雨头图 | 付费下载于视觉中国*文末有赠书福利在互联网时代,数据隐私泄露到底有多严重?近日,微博大V袁启聪发布微博称,两周前接到一个私人手机号码来电,来电者自称是招商银行的&#…

阿里云开放平台微前端方案的沙箱实现

导读 微前端已经成为前端领域如今比较火爆的话题,关于微前端价值的讨论,可以参考克军的《拥抱云时代的前端开发框架——微前端》。微前端在技术方面,有一个始终绕不过去话题就是前端沙箱。本篇具体探讨一下,在微前端领域如何实现前…

idea全局搜索快捷鍵ctrl+shift+F失效

idea全局搜索快捷鍵ctrlshiftF失效 1.确认是否修改了默认的快捷键配置: file-settings-keymap,在右边的放大镜中搜索find in Path 确认快捷键设置的是:ctrlshiftF 2.快捷键冲突(常见的就是和输入法快捷键冲突) 以我的win10自带…