【SNIA技术白皮书】
**超大规模存储
Hyperscaler Storage**
摘要
大型数据中心用户通常称作Hyperscaler（超大规模用户）。这类用户几乎普遍采用软件定义存储（Software Defined Storage，以下简称SDS）构建存储系统，将商用组件虚拟化为超大规模资源池。实践证明，要管理好这一庞大的资源池极具挑战性，以及由超大规模带来的其它问题也层出不穷。本文将讨论超大规模存储面临挑战以及相应解决方案。
目录
- 介绍
- 超大规模存储基础架构
- 超大规模存储面临挑战
- 尾延迟
- 尾延迟修复
- 超大规模存储解决方案
- 小结
- 介绍
由于超大规模用户通过RFP采集对存储系统提出各种独特的定制化需求，于是存储厂商开发出各种新功能来满足这些超大规模用户需求，当然各种新功能的实施落地会依据不同用户场景“因地制宜”，SDS这一产品形态就这么衍生而来。当下很多企业都在使用SDS，他们都是超大规模技术的受益者。
2016年FAST会议（Conference on File and Storage Technologies，文件与存储技术会议，是存储领域最好的专业会议之一），Eric Brewer（Google基础架构部门副总裁）谈到了Google面临的超大规模存储挑战，相关内容可在Google之前发布的白皮书Disks for Data Centers（《数据中心的硬盘》）里看到。当然，不止Google，来自微软Azure的Mike McGrath也证实了微软面临同样的挑战。如果能很好地解决这些挑战，将有更多超大规模用户收益。
Google白皮书Disks for Data Centers中，主要从两大层面来阐释大规模存储的挑战：一是物理层面（比如硬盘盘片尺寸、驱动器高度），二是逻辑层面。本文将着重围绕后者，即逻辑层面的挑战来开展讨论，并给出解决方案。
- 超大规模存储基础架构
超大规模用户通常采用ODM厂商提供的商用组件来构建存储系统。由于驱动器本身的不可靠性，跨节点数据冗余必然存在。再考虑到节约成本，使用较低可靠性的驱动器是可以接受的。存储系统由一系列驱动器（JBOD磁盘族，和/或JBOF闪存族）以及计算服务器组成。通过SDS，在现有集群上实现节点的横向扩展，支持块级、文件级和对象级接口，灵活满足应用需求。
SDS还通过跨节点冗余副本或纠删码技术提供高可用，通过并行数据服务实现高性能，通过定制化管理软件实现数据中心级的系统监控管理，以及跨数据中心的地域复制提高业务连续性以及灾难恢复能力等。
- 超大规模存储面临挑战
在实际生产环境中，超大规模用户对存储系统的要求可归纳为以下几个方面：
- 更高的IOPs
- 更高的存储容量
- 更低的尾延迟
- 更高的安全性
- 更低的TCO
可以说，SDS通过跨节点乃至跨数据中心的数据扩展已在整体上实现了高性能和高可用。但在某些情况下，为了更可靠的存取数据不得不牺牲性能一致性。存储系统亟待进一步优化提升。
超大规模存储需要的优化提升包括：
- 后台任务的时序控制（当尾延迟问题明显）
- 磁盘细节信息的把握（哪个块存储响应缓慢）
- 请求的优先处理，但依然允许磁盘固件做调度
- 有一个抽象层来承载多厂商提供的各种功能支持
针对每I/O的重试策略（努力尝试，快速失败）
- 尾延迟
毋庸置疑，尾延迟是部署超大规模存储首当其冲的一大难题。在FAST 2016会议上，另一篇论文The Tail at Store: A Revelation from Millions of Hours of Disk and SSD Deployments（《存储尾延迟：基于数百万小时的机械盘和SSD部署实践启示》）进行了这样的研究分析：
- 对超过45万块机械盘和4千块SSD长达87天的存储性能监测
- 总运行时间长达：8亿5700万小时（机械盘），700万小时（SSD）
- 存储介质极慢响应占比较低：
a. 机械盘极慢响应占比0.2%，存在某个特别的I/O响应速度比同一RAID族群里的其它I/O慢2倍以上；
b. SSD极慢响应占比0.6% - 基于机械盘和SSD的RAID条带至少经历一次极慢驱动（也就是存储尾延迟），且时间占比分别为1.5%（机械盘）和2.2%（SSD）
尾延迟是由于SSD跨节点扩展数据、并行发送请求，于是最慢的驱动导致了整体响应延迟。在大多数情况下，该最慢驱动可以通过拥有同样数据的其它驱动，或是基于纠删码的冗余，能够形成响应。超大规模存储的条带化很可能提高尾延迟的出现几率。
- 尾延迟修复
修复尾延迟的一个潜在解决思路是在I/O操作期间提供一个重试策略的提示，表明该I/O操作是携带跨节点冗余数据的某RAID条带的一部分，且支持超过数据恢复的响应时间。存储驱动器解读该策略，将重试减至最少，并返回一个error信息，而不是过多耗时试图恢复数据。SDS从冗余副本提供丢失的数据，并形成及时响应，消除尾延迟。
定制化数据中心管理软件监控着全局驱动及其响应情况，它可标识出缓慢返回数据的驱动并让其离线，之后SDS找其它驱动来存放数据的冗余副本。也许只是该驱动的一部分响应过慢，但这样做可以帮助消除尾延迟。离线驱动的替换不需要马上进行，可在数据中心定期维护期间来替换。
如果只是驱动的一部分响应过慢，驱动也能侦测到介质上这些慢区域，那么相关LBA（Logical Block Address，逻辑块地址）可以重映射到闲置介质上。这样就避免了数据中心管理软件将整个驱动离线。通常重映射只在介质故障时进行，让驱动离线会比重映射更快消耗闲置介质，也就更需要扩大闲置介质的容量。也有存储厂商考虑到这一情况在生产初期就配置了额外的闲置容量。
- 超大规模存储解决方案
（1）驱动截断以及存储元件锐减
重新定位“锐减”（Depopulation）是一个方法，即：识别出慢介质，并向主机传达慢介质所在位置已经确认。主机找出这些确定区域后，向驱动发出请求，要求这些区域退出服务。一个REMOVE ELEMENT AND TRUNCATE命令，将截断LBA范围，移除慢介质，并生成一个容量减小的驱动，SDS会视其为一个刚添加的全新驱动来使用。不过保存数据这类保证无法提供。
保存数据的“锐减”机制当然也能识别出慢介质，但它还能让主机保存LBA里的数据，如果LBA将被截断，该数据会被迁至另一个可选地址。对于非截断LBA空间的有效数据，则完全被保存。这一机制对于固定RAID大小的存储系统十分有用，对于其它RAID条带，如果需要重建驱动作为该条带的一部分，这一机制可加速重建过程。
（2）流
“流”（Streams）是一个将“块”与更高级别的“文件”“对象”关联起来的概念。如果所有块作为一个整体被删除，那么对于用不到的写位置的垃圾回收也很可能大幅减少。SSD能将与流有关的LBA统一合并为一个或多个写块。当使用TRIM命令或UNMAP命令时，全体写块将被擦除。这样能提升性能，并最小化因垃圾回收引起的写入放大，还能提升设备寿命。
（3）高级后台操作
驱动异步执行主机请求，相关执行操作包括：
- 垃圾回收
- 清理
- 重映射
- 缓存刷新
- 连续自检
这些操作可能会延迟主机的I/O运行，导致尾延迟。如果给予主机能力去影响这些操作的调度，那么这些高级后台操作将被依次调度，从而降低对I/O的影响，缓解尾延迟。
（4）开放通道的SSD
开放通道的SSD是一块没有完整固件FTL（Flash Translation Layer，闪存转换层）的固态硬盘，但是能向主机展现存储介质的完整物理地址空间。FTL在主机上运行，可通过NVMe这样的接口通信。开源部署FTL通常用于实现损耗均衡、垃圾回收和节约空间，从而给予超大规模用户物理介质的访问控制权，并允许控制FTL进程。这样SDS就能管控尾延迟了。
LightNVM项目支持开放通道的SSD，通过坏块管理、元数据的持久化和扩展等功能支持原子I/O操作，不过这些功能依然需要设备固件来管理。
（5）快速RAID重建
对于SAS和SATA，当驱动进入重建辅助模式（可按需启用/禁用），将根据情况做不同动作。驱动不会很努力去试图获取数据，因为在这种模式下，主机被认为在其它某处有可用的数据副本。该模式可基于每I/O禁用，于是复杂的错误恢复可基于该I/O执行。
当检测到一个error，驱动不仅会告知主机关于所请求块上的错误，它还会告知主机关于邻近chunk上（邻近“好”块的LBA）的其它错误。这样一来，主机就不会去打扰尝试访问那些显而易见的坏块，而是向前一步，为这些块寻求其它来源的数据获取。
（6）I/O提示
SAS和SATA支持使用LBM（Logical Block Markup，逻辑块标记）的提示，举例如下：
- 顺序I/O提示——就其它I/O而言优先这个I/O
- 顺序读——针对这个LBA范围的顺序读几率
a. 支持智能缓存预取
b. 允许数据读取后从缓存移除 - 顺序写——针对这个LBA范围的顺序写几率
SAS最高支持的LBM数为64，且每个LBM包含一组提示。每个I/O可参考一个LBM。SATA的Data Set Management命令可将一个LBM分配给一系列LBA。
SDS使用这些提示让驱动更好地管理工作负载，从而实现更高的吞吐或IOPs。
- 小结
当下超大规模用户都是直接将各种定制化存储需求传递给厂商，厂商方面应对各路RFP响应的产品实现是很碎片化的，这也与最终标准化的愿景相背离。因此，SNIA认为应该适当推迟上述新功能在超大规模企业用户领域的应用。
点击这里，可登陆SNIA官网查看该白皮书英文原版PDF。
5621
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
