没有合适的资源?快使用搜索试试~ 我知道了~
Ceph分布式文件系统中的自定义存储后端
ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月分布式存储系统ABUTALIB AGHAYEV,卡内基梅隆大学9SAGEWEIL,红帽公司迈克尔·库奇尼克,卡内基梅隆大学MarkNELSON,红帽公司格雷戈里河GANGER和GEORGE AMVROSIADIS,卡内基梅隆大学十年来,Ceph分布式文件系统遵循了在本地文件系统之上构建其存储后端的传统智慧。这是当今大多数分布式文件系统的首选,因为它允许它们从经过实战测试的代码的便利性和成熟性中受益然而,Ceph首先,开发零开销事务机制是一项艰巨的任务。其次,本地级别的元数据性能会显著影响分布式级别的性能。第三,支持新兴存储硬件的速度非常缓慢。Ceph通过BlueStore解决了这些问题,BlueStore是一种旨在直接在原始存储设备上运行的新后端在成立仅两年的时间里,BlueStore的表现超过了之前建立的后端,并被70%的用户在生产中采用通过在用户空间中运行并完全控制I/O堆栈,它实现了空间高效的元数据和数据校验和、擦除编码数据的快速覆盖、内联压缩、降低性能变化,并避免了本地文件系统的一系列性能缺陷最后,它使采用向后不兼容的存储硬件成为可能,这是不断变化的存储环境中的一个重要特征,正在学习接受硬件多样性。CCS概念:·信息系统→分布式存储; ·软件及其引擎→文件系统管理;·软件性能;其他关键词和短语:Ceph,对象存储,分布式文件系统,存储后端,文件系统ACM参考格式:Abutalib Aghayev , Sage Weil , Michael Kuchnik , Mark Nelson , Gregory R.Ganger 和 GeorgeAmvrosiadis。2020. 分布式存储系统中自定义存储后端的案例 ACM Trans. 存储16,2,第9条(2020年5月),31页。https://doi.org/10.1145/3386362Michael Kuchnik得到了NDSEG奖学金的支持作者地址:A. Aghayev,M. Kuchnik,G. R. Ganger和G. Amvrosiadis,卡内基梅隆大学,5000福布斯大街,美国,宾夕法尼亚州,15213;电子邮件:agayev@cs.cmu.edu,mkuchnik@cmu.edu,ganger@ece.cmu.edu,gamvrosi@cmu.edu; S.Weil和M. Nelson,Red Hat Inc,100 East Davie Street,Raleigh,NC 27601,USA;电子邮件:sweil@redhat.com,mnelson@redhat.com。允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用,无需付费,前提是复制品不以营利或商业利益为目的制作或分发,并且复制品在第一页上带有此通知必须尊重作者以外的其他人所拥有的本作品组件的版权。允许用信用进行提取复制,或重新发布,张贴在服务器上或重新分发到列表,需要事先特定的许可和/或费用。从permissions@acm.org请求权限。© 2020版权归所有者/作者所有。出版权授权给ACM。1553-3077/2020/05-ART9 $15.00https://doi.org/10.1145/3386362ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月九:2A. Aghayev等人1介绍分布式文件系统在机器集群上运行,每个机器被分配一个或多个角色,例如集群状态监视器、元数据服务器和存储服务器。存储服务器构成集群中的大部分机器,通过网络接收I/O请求,并使用存储后端软件从本地附加的存储设备为它们提供存储后端位于I/O路径中,对整个系统的性能起着关键作用传统的分布式文件系统直接或通过中间件使用本地文件系统(如ext4或XFS)作为存储后端[31,37,40,44,79,89,98,103,106,108]。这种方法提供了合理的性能,排除了文件系统的适用性问题,分布式存储后端。有几个原因促成了文件系统作为存储后端的成功。首先,它们允许将数据持久性和块分配的难题委托给经过良好测试和高性能的代码。其次,它们提供了一个熟悉的接口(POSIX)和抽象(文件、目录)。第三,它们支持使用标准工具(ls、find)来浏览磁盘内容。Ceph [103]是一个广泛使用的开源分布式文件系统,遵循这一惯例已有十年。Ceph团队使用几种流行的文件系统学到的惨痛教训使他们质疑文件系统作为存储后端的适用性。事后看来,这并不奇怪。Stonebraker,在构建INGRES数据库或数据库之后,不认为“类似地,exokernels证明了为应用程序定制抽象可以显著提高性能[33,53]。除了性能损失之外,采用日益多样化的存储硬件正在成为本地文件系统的挑战,这些文件系统最初是为单个存储介质设计的这篇体验文章的第一个贡献是概述Ceph决定开发BlueStore的主要原因,BlueStore是一种直接部署在原始存储设备上的首先,很难在现有的文件系统上实现高效的事务大量的工作旨在将事务引入文件系统[42,67,69,77,82,85,92,112],但由于其高性能开销,有限的功能,接口复杂性或实现复杂性,这些方法都没有被采用Ceph团队的经验表明,其他选项,例如利用文件系统的有限内部事务机制,在用户空间中实现Write-Ahead Logging,或使用transactional key-value store,也提供了低于标准的性能。其次,本地文件系统更具体地说,Ceph团队面临的一个关键挑战是快速枚举具有数百万条目的Btrfs和基于XFS的后端都存在这个问题,并且发现用于分发元数据负载的目录拆分操作与文件系统策略冲突,从而削弱了整体系统性能。与此同时,成熟文件系统的刚性阻止了它们采用新兴的存储硬件,这些硬件放弃了古老的块接口。生产文件系统的历史表明,它们平均需要十年才能成熟[32,59,109,110]。一旦文件系统成熟,由于错误的后果,它们的维护人员在进行根本性更改时往往会保守然而,针对数据中心的新型存储硬件引入了需要大幅更改的向后不兼容接口例如,为了增加容量,硬盘驱动器(HDD)供应商正在转向叠瓦式磁记录(SMR)技术[41,66,87],该技术与向后不兼容的区域接口[49]配合使用效果最佳类似地,为了消除闪存转换层(FTL)[38,56,114]引起的固态硬盘(SSD)中的长I/O尾部延迟,供应商正在引入消除FTL的分区存储空间(ZNS)SSD,再次暴露区域接口[9,27]。云存储提供商[61,78,116]和存储服务器供应商[18,分布式存储系统中的自定义存储后端九:3ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月60]已经在调整其私有软件堆栈以使用分区设备。然而,分布式文件系统由于在本地文件系统中采用分区设备的延迟而停滞2015年,Ceph项目开始设计和实现BlueStore,这是一种用户空间存储后端,可将数据直接存储在原始存储设备上,并将元数据存储在键值存储中。通过完全控制I/O路径,BlueStore能够有效地实现完整的数据校验和、内联压缩和擦除编码数据的快速覆盖,同时还提高了常见客户工作负载的性能。2017年,经过短短两年的发展,Blue- Store成为Ceph中默认的生产存储后端2018年对Ceph用户进行的一项调查显示,70%的用户在生产中使用BlueStore,部署容量为数百PB [64]。作为第二个贡献,本文介绍了BlueStore的设计,其设计克服的挑战,以及未来改进的机会。BlueStore的新颖性包括(1)在键值存储中存储低级文件系统元数据,例如盘区位图,从而避免磁盘上的格式改变并降低实现复杂性;(2)通过仔细的接口设计优化克隆操作并最小化所得到的盘区引用计数的开销;(3)BlueFS-一种使RocksDB能够在原始存储设备上更快地运行的用户空间文件系统;以及(4)具有每TB磁盘空间固定35 MiB存储器使用的空间分配器。作为第三个贡献,为了进一步展示clean-slate后端的优势,本文描述了在Ceph中采用具有新区域接口的存储设备的第一步。具体来说,我们演示了如何适应BlueFS,从而RocksDB,在高容量SMR驱动器上运行这使得可以在分区设备上的Ceph中存储元数据,我们将开发在分区设备上存储数据的技术作为未来的工作。虽然元数据占总写入的一小部分,但使用小型Ceph集群,我们证明避免元数据写入的转换层开销可将吞吐量提高高达141%,并显着降低写入延迟差异。除了上述贡献之外,我们还进行了几项实验,以评估从Ceph以前的生产后端FileStore到BlueStore的设计更改的改进 我们通过实验测量了日志文件系统的开销、日志的双写、低效的目录拆分和就地更新机制(与写时复制相反)等问题对性能的影响。2背景本节旨在强调分布式存储后端的作用以及构建高效分布式文件系统所必需的功能(第2.1节)。我们简要概述了Ceph的架构(第2.2节)和Ceph存储后端在过去十年中的发展(第2.3节),并介绍了2.1分布式存储后端的基础知识分布式文件系统将来自多个物理机器的存储空间聚合到单个统一的数据存储中,该数据存储提供高带宽和并行I/O、水平可扩展性、容错性和强一致性。虽然分布式文件系统可能设计不同,并使用独特的术语来指代管理物理介质上的数据放置的机器,但存储后端通常被定义为直接管理附接到物理机器的存储设备的软件模块。例如,Lust的对象存储服务器(OSTs)将数据存储在对象存储目标(OSTs)上[ 108 ],GlusterFS的节点将数据存储在砖上[ 79 ],并且Ceph的节点将数据存储在对象存储设备(OSD)上在这些和其他系统中,存储后端是管理连接到物理机(OSS,节点)的磁盘(OST,Brick,OSD)上的空间的软件模块。广泛使用的分布式文件系统,如Lustre [108],GlusterFS [79],OrangeFS [31],BeeGFS [98],XtreemFS [44]和(直到最近)Ceph [103]依赖于通用的本地文件系统,九:4A. Aghayev等人ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月×图1. 对Ceph架构的高层次描述显示了一个具有3个复制的池因此,每个放置组(PG)在三个OSD上复制例如ext4和XFS,来实现它们存储后端。虽然不同的系统需要来自存储后端的不同特征,但是这些特征中的两个,(1)高效事务和(2)快速元数据操作似乎是共同的;另一个新兴的需求是(3)对新颖的、向后不兼容的存储硬件的支持。存储后端的事务支持简化了许多分布式文件系统提供的强一致性的实现[44,79,103,108]。如果备份文件系统已经支持事务,则存储后端可以无缝地提供事务[58,82]。然而,大多数文件系统实现了POSIX标准,它缺乏事务概念。因此,分布式文件系统开发人员通常采用低效或复杂的机制,例如在文件系统上实现预写日志(WAL)[79],或利用文件系统元数据管理是分布式文件系统中另一个经常出现的痛点[74]。无法有效枚举大目录内容或在本地文件系统中大规模处理小文件会削弱集中式[106,108]和分布式[79,103]元数据管理设计的性能为了解决这个问题,分布式文件系统开发人员使用元数据缓存[79],由数据散列排列的深层目录层次结构[103],自定义数据库[94]或本地文件系统的补丁[12,13,119]。对存储后端的一个新需求是支持使用向后不兼容接口运行的新型存储硬件例如,SMR可以将HDD容量提高25%以上,硬件供应商声称,到2023年,超过一半的数据中心HDD将使用SMR [88]。另一个例子是ZNS SSD,它消除了FTL,并且不会遭受无法控制的垃圾收集延迟[9],从而可以更好地控制尾部延迟。这两种新的硬件存储类别都存在向后不兼容的接口,这对于本地的基于块的文件系统来说是具有挑战性的。2.2分布式存储系统体系结构图1显示了Ceph的高级架构Ceph的核心是可靠自主分布式对象存储(RADOS)服务[105]。RADOS可扩展到数千个对象存储分布式存储系统中的自定义存储后端九:5ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月图2. Ceph中存储后端演变的时间轴 对于每个后端,显示了开发时期和作为默认生产后端的时期。设备(OSD),提供自我修复、自我管理、复制的对象存储,具有强大的可靠性。CephCeph提供了三种使用librados实现的服务:RADOS Gateway(RGW),类似于Amazon S3的对象存储[5]; RADOS Block Device(RBD),类似于Amazon EBS的虚拟块设备[4];以及CephFS,具有POSIX语义的分布式文件系统。RADOS中的对象存储在称为池的逻辑分区中。可以将EJB配置为通过复制或擦除编码为包含的对象提供冗余在池中,对象在称为放置组(PG)的聚合单元之间进行分片根据复制因子,PG使用CRUSH(一种伪随机数据分发算法)映射到多个OSD[104]。客户机还使用CRUSH来确定应该包含给定对象的OSD,从而避免了对集中式元数据服务的需要PG和CRUSH在客户端和OSD之间形成了一个间接层,允许对象在OSD之间迁移,以适应集群或工作负载的变化。在RADOS集群的每个节点中,每个本地存储设备都有一个单独的Ceph OSD守护程序每个OSD处理来自librados客户端的客户端I/O请求,并与对等OSD协作数据通过内部ObjectStore接口持久化到本地设备,该接口提供对象的抽象、对象集合、一组用于检查数据的原语以及用于更新数据的事务事务将任意数量的对对象和对象集合进行操作的原语组合成一个原子操作。原则上,每个OSD可以使用ObjectStore接口的不同后端实现,尽管集群在实践中往往是统一的2.3Ceph存储后端的演变ObjectStore接口的第一个实现实际上是一个名为Extent和基于B树的对象文件系统(EBOFS)的用户空间文件系统。2008年,Btrfs出现了一些吸引人的功能,如事务、重复数据删除、校验和和透明压缩,这些都是EBOFS所缺乏的。因此,如图2所示,EBOFS被FileStore取代,FileStore是Btrfs之上的ObjectStore实现。九:6A. Aghayev等人ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月在FileStore中,对象集合映射到目录,对象数据存储在文件中最初,对象属性存储在POSIX扩展文件属性(xattrs)中,但后来当对象属性超过xattrs的大小或计数限制时,被转移到LevelDB。Btrfs上的FileStore作为生产后端已经有好几年了,在此期间,Btrfs一直不稳定,并且遭受严重的数据和元数据碎片。与此同时,ObjectStore接口有了很大的发展,使得切换回EBOFS变得不切实际相反,FileStore被移植到XFS、ext4和更高版本的Linux上运行其中,XFS上的FileStore成为事实上的后端,因为它扩展性更好,元数据性能更快[39]。虽然XFS上的FileStore很稳定,但它仍然受到元数据碎片的影响,并且没有充分利用硬件的潜力。缺乏原生事务导致用户空间WAL实现,该实现执行完整的数据日志记录,并将读取-修改-写入工作负载(典型的Ceph工作负载)的速度限制在WAL的写入速度。此外,由于XFS不是写时复制文件系统,快照大量使用的克隆操作明显较慢。NewStore是解决基于文件系统的备份的元数据问题的第一次尝试,形接头. NewStore没有使用目录来表示对象集合,而是将对象元数据存储在RocksDB中,RocksDB是一种有序的键值存储,而对象数据则保存在文件中。RocksDB还用于实现WAL,由于组合了数据和元数据日志,使读取-修改-写入工作负载变得高效。将对象数据存储为文件并在日志文件系统之上运行RocksDB,但是,引入了高一致性开销。这导致了BlueStore的实现,它使用原始磁盘。以下部分描述了BlueStore旨在解决的挑战BlueStore的完整描述在第4节中给出。3在可扩展文件系统上构建可扩展端很难本节描述Ceph团队在尝试在本地文件系统之上构建分布式存储后端时所面临的挑战3.1挑战1:高效交易事务通过将一系列操作封装到单个原子工作单元中来简化应用程序开发因此,大量的工作旨在将事务引入文件系统[42,67,69,77,82,85,92,112]。然而,由于其高性能开销、有限的功能、接口复杂性或实现复杂性,这些工作都没有被生产文件系统采用因此,有三个有形的选项用于在运行于文件系统之上的存储后端中提供事务:(1)挂钩到文件系统的内部(但有限的(2)在用户空间中实现WAL,以及(3)使用具有事务的键值数据库作为WAL。接下来,我们将描述为什么这些选项中的每一个都会导致显著的性能或复杂性开销。3.1.1利用文件系统内部事务。 许多文件系统实现了内核事务框架,可以原子地执行复合内部操作[19,24,91,99]。由于该框架的目的是确保内部文件系统的一致性,其功能通常是有限的,因此,用户不可用例如,回滚机制在文件系统事务框架中不可用,因为它对于确保文件系统的内部一致性是不必要直到最近,Btrfs才通过一对系统调用将其内部事务机制提供给用户,这对系统调用将它们之间的操作原子地应用于文件系统[24]。在Btrfs上运行的FileStore的第一个版本依赖于这些系统调用,并且缺乏回滚机制。更具体地说,如果Ceph OSD在分布式存储系统中的自定义存储后端九:7ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月→→→事务,如软件崩溃或KILL信号,Btrfs将提交部分事务并使存储后端处于不一致状态。Ceph和Btrfs团队尝试的解决方案包括引入单个系统调用来指定整个事务[101]和通过快照实现回滚[100],这两种方法都被证明是昂贵的。Btrfs的作者最近反对事务系统调用[15]。这一结果类似于微软这些经验强烈表明,在用户空间中实现的存储后端中很难利用文件系统的内部事务机制3.1.2在用户空间中实现WAL使用文件系统内核事务框架的另一种方法是在用户空间中实现逻辑WAL。虽然这种方法行之有效,但它存在三个主要问题。慢读-修改-写入。 典型的Ceph工作负载在对象上执行许多读-修改-写操作,其中准备下一个事务需要读取上一个事务的效果。然而,用户空间WAL实现对每个事务执行三个步骤首先,将事务序列化并写入日志。其次,调用fsync将事务提交到磁盘。第三,将事务中指定的操作应用于文件系统。在第三步完成之前,即将到来的事务无法读取事务的效果,这取决于第二步。因此,每个读-修改-写操作都会导致WAL提交的全部延迟,从而妨碍了高效的流水线操作。非幂等运算在FileStore中,对象由文件表示,集合映射到目录。使用此数据模型,由于非幂等操作,在崩溃后重放逻辑WAL具有当WAL被周期性地修剪时,当仍然在WAL中的已提交事务已经被应用到文件系统时,总是有例如,考虑一个由三个操作组成的事务:clone a b; update a; update c。如果在第二次操作后发生崩溃,则重播WAL会破坏对象b。作为另一个示例,考虑一个事务:更新b;重命名bc;重命名a b;更新d。如果在第三次操作后发生崩溃,则重播WAL会破坏对象a,现在将其命名为b,然后失败,因为对象a不再存在。Btrfs上的FileStore通过定期获取文件系统的持久快照并在快照时标记WAL位置来解决这个问题然后在恢复时恢复最新的快照,并从快照时标记的位置重播WAL当FileStore放弃Btrfs而支持XFS时(第2.3节),缺乏有效的快照导致了两个问题。首先,在XFS上,sync系统调用是将文件系统状态同步到存储的唯一选项但是,在每个节点具有多个驱动器的典型部署中,同步的成本太高,因为它会删除所有驱动器上的所有文件系统这个问题是通过在Linux内核中添加syncfs系统调用[102]来解决的,它只支持给定的文件系统。第二个问题是,对于XFS,没有将文件系统恢复到特定状态的选项,在该状态之后,WAL可以被重放,而不必担心非幂等操作。为了避免重放非幂等操作,增加了保护(序列号),然而,由于问题空间很大,验证复杂操作的保护的正确性很困难编写工具生成复杂操作序列的随机排列,并与故障注入相结合,半全面地验证所有故障情况都得到了正确处理。然而,FileStore代码最终变得脆弱且难以维护。双写。FileStore中WAL的最后一个问题是数据被写入两次:第一次写入WAL,然后写入文件系统,从而使磁盘带宽减半。这是一个已知的问题,九:8A. Aghayev等人ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月→导致大多数文件系统只记录元数据更改,从而导致崩溃后数据丢失 通过首先将新数据写入磁盘,然后仅记录保留的元数据,可以避免对新数据进行两次写入的损失。然而,FileStore的应用程序使用文件系统的状态来推断对象的命名空间及其状态的方法使得该方法由于诸如部分写入的文件之类的极端情况而虽然FileStore3.1.3使用键值存储作为WAL。 使用NewStore,元数据存储在RocksDB中,这是一个有序的键值存储,而对象数据仍然表示为文件系统中的文件。因此,元数据操作可以原子地执行;然而,数据覆盖被记录到RocksDB中并稍后执行我们首先描述了这种设计如何解决逻辑WAL的三个问题,然后说明它引入了高一致性开销,这源于在日志文件系统上运行。首先,避免了缓慢的读取-修改-写入操作,因为键值接口允许读取对象的新状态而无需等待事务提交。第二,避免了非幂等操作重放的问题,因为这种操作的读端在准备事务时被解决例如,对于克隆a b,如果对象a很小,则将其复制并插入到事务中;如果对象a很大,则使用写时复制机制,该机制将a和b都更改为指向相同的数据并将数据标记为只读。最后,避免了新对象的双写问题,因为对象名称空间现在与文件系统状态解耦了因此,新对象的数据首先写入文件系统,然后将对它的引用原子地添加到数据库。尽管有这些有利的属性,RocksDB和日志文件系统的组合引入了高一致性开销,类似于日志的日志问题[51,86]。在NewStore中创建对象需要两个步骤:(1)写入文件并调用fsync,(2)将对象元数据同步写入RocksDB [47],这也调用了fsync。理想情况下,fsync在每一步都应该向磁盘发出一个昂贵的FLUSH CACHE命令[111]然而,对于日志文件系统,每个fsync发出两个刷新命令:在写入数据之后和在将相应的元数据更改提交到文件系统日志之后。因此,在NewStore中创建一个对象会导致四个昂贵的刷新命令到磁盘。我们使用一个模拟存储后端创建许多对象的基准测试来演示日志记录的开销基准测试有一个循环,其中每次迭代首先写入0.5 MiB的数据,然后将500字节的元数据插入RocksDB。我们在两个设置上运行基准测试第一个设置模拟NewStore,为每个对象创建发出四个刷新操作:数据作为文件写入XFS,元数据插入到XFS上运行的RocksDB第二个设置模拟原始磁盘上的对象创建,它为每个对象创建发出两个刷新操作:数据被写入原始磁盘,元数据被插入到修改后的RocksDB中,该RocksDB在具有预分配的WAL文件池的原始磁盘图3显示,在HDD上运行时,原始磁盘上的对象创建吞吐量比XFS高80%,在NVMe SSD上运行时高70%3.2挑战2:快速元数据操作本地文件系统中的元数据操作效率低下是分布式文件系统不断斗争的根源[74,76,119]。Ceph中的关键元数据挑战之一是FileStore分布式存储系统中的自定义存储后端九:9ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月图3. 在日志文件系统上运行对象存储工作负载的开销对象创建吞吐量在原始HDD(4 TB SeagateST4000NM0023)上提高80%,在原始NVMeSSD(400 GB Intel P3600)上提高70%。后端的问题源于对大型目录的缓慢目录枚举(readdir)操作,以及返回结果中缺乏排序[90]。RADOS中的对象根据其名称的散列映射到PG,并按散列顺序枚举。枚举对于像清理[83]、恢复或为列出对象的librados调用服务这样的操作是必要的对于具有长名称的对象(RGW通常就是这种情况),FileStore使用扩展属性绕过本地文件系统中的文件名长度限制,这可能需要stat调用来确定对象名称。FileStore遵循一种普遍采用的解决慢枚举问题的方法:创建一个具有大扇出的目录层次结构,对象分布在目录中,然后在读取选定目录为了快速对目录进行排序并限制可能的stat调用的开销,当目录中的条目数量增加时,通过拆分目录来保持目录这是一个大规模的昂贵过程,主要有两个原因。首先,一次处理数百万个inode会降低dentry缓存的效率,从而导致许多小的磁盘I/O其次,XFS将子目录放在不同的分配组中[48],以确保未来的目录条目有空间靠近在一起[65];因此,随着对象数量的增加,目录内容会分散,并且由于寻道,拆分操作需要更长因此,当所有Ceph OSD开始一致分裂时,性能就会受到影响。这是一个众所周知的问题,多年来一直影响着许多Ceph用户[16,28,93]。为了证明这种效果,我们配置了一个16节点的Ceph集群(第7节),其中大约一半的PG数量是推荐的,以增加每个PG的负载并加速拆分,并在RADOS层插入数百万个队列深度为128的4 KiB对象(第2.2节)。图4显示了在全SSD集群中拆分对FileStore的影响虽然第一次拆分在图表中不明显,但第二次拆分导致吞吐量急剧下降,在全SSD上杀死吞吐量7分钟,在全HDD群集上杀死吞吐量120分钟(未显示),在此期间扫描具有数百万条目的大型深层目录层次结构,甚至创建更深的层次结构由于寻道成本较高,全HDD群集上的恢复时间要长一个数量级九:10A. Aghayev等人ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月图第四章目录拆分对FileStore后端吞吐量的影响 工作负载使用RADOS层的128个并行线程将4 KiB对象插入到16节点Ceph集群(设置在第7节中解释)。目录拆分会使全SSD群集的吞吐量下降7分钟拆分完成后,吞吐量会恢复,但不会恢复到峰值,这是由于文件嵌套更深、底层文件系统的大小增加以及FileStore中目录哈希代码3.3挑战3:对新存储硬件的支持不断变化的存储硬件环境对依赖本地文件系统的为了增加容量,硬盘驱动器供应商正在转向SMR,当使用向后不兼容的接口时,SMR工作得最好虽然供应商已经生产了向后兼容的驱动器管理SMR(DM-SMR)驱动器,但这些驱动器具有不可预测的性能[1]。为了利用额外的容量并同时实现可预测的性能,应使用具有向后不兼容区域接口的主机管理的SMR(HM-SMR)驱动器[49]。然而,区域接口将磁盘管理为必须顺序写入的256 MiB区域序列,鼓励日志结构的写入时复制设计[81]。这种设计与大多数成熟文件系统遵循的就地覆盖设计直接相反。数据中心SSD正在经历类似的变化。OpenChannel SSD消除了FTL,将原始闪存的管理留给主机。由于缺乏官方标准,几家供应商推出了不同的OpenChannel SSD接口方法,导致实现支离破碎[11,22,36]。为了防止这种情况,主要供应商已经联合起来引入了一个新的NVMe标准,称为分区存储空间(ZNS),该标准定义了一个用于管理SSD的接口,而无需FTL [10]。消除FTL有许多优点,例如降低写入放大率、改善延迟异常值和吞吐量、将过度配置降低一个数量级,以及通过减少DRAM(SSD中仅次于NAND闪存的成本最高的组件)来降低成本这两种技术(主机管理的SMR驱动器和ZNS SSD)对于分布式文件系统越来越重要,但是,这两种技术都具有向后不兼容的区域接口,需要对本地文件系统进行彻底更改[9,27]。到目前为止,试图修改生产文件系统(如XFS和ext4)以使用zone接口的分布式存储系统中的自定义存储后端九:11ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月不成功[20,73],主要是因为这些是覆盖文件系统,而区域接口需要一个写时复制的方法来管理数据3.4其他挑战许多公共云和私有云依赖于Ceph等分布式存储系统来提供存储服务[72]。如果没有对I/O堆栈的完全控制,分布式文件系统就很难实施存储延迟SLO。在基于文件系统的存储后端中,高变化请求延迟的一个原因是操作系统页面缓存。为了改善用户体验,大多数操作系统使用回写策略实现页面缓存,其中一旦数据在内存中缓冲并且相应的页面被标记为脏,则写操作完成。在I/O活动很少的系统上,脏页会定期写回磁盘,从而同步磁盘上和内存中的数据副本。然而,在繁忙的系统上,回写行为由一组复杂的策略控制,这些策略可以在任意时间触发写入[8,25,113]。因此,虽然回写策略为系统负载较轻的用户提供了一个响应系统,但它使在繁忙的存储后端实现可预测的延迟变得即使定期使用fsync,FileStore也无法限制延迟的inode元数据回写量,从而导致性能不一致。基于文件系统的后端的另一个挑战是实现更好地使用写时复制支持的操作,如快照。如果备份文件系统是写时复制的,则可以有效地实现这些操作。然而,即使支持写时复制,文件系统也可能有其他缺点,比如Btrfs上的FileStore中的碎片(第2.3节)。如果备份文件系统不是写时复制的,那么这些操作需要执行昂贵的对象完整副本,这使得在FileStore中快照和删除擦除编码数据的成本过高(第5.2节)。4BLUESTORE:一种全新的方法BlueStore是一个从头开始设计的存储后端,旨在解决使用本地文件系统的后端所面临的挑战(第3节)BlueStore的一些主要目标如下:(1) 快速元数据操作(第4.1节)(2) 对象写入没有一致性开销(第4.1节)(3) 写时拷贝克隆操作(第4.2节)(4) 无日志记录双写(第4.2节)(5) 针对HDD和SSD优化的I/O模式(第4.2节)BlueStore在短短两年内实现了所有这些目标,并成为Ceph中的默认存储与通用POSIX文件系统相比,BlueStore成熟得如此之快,有两个因素起了关键作用[32,59,109,110]。首先,Blue-Store实现了一个小型的专用接口,而不是完整的POSIXI/O规范。第二,BlueStore是在用户空间中实现的,这允许它利用经过良好测试和高性能的第三方库。最后,BlueStore的I/O策略实现了额外的特性,我们将在第5节讨论这些特性BlueStore的高级架构如图5所示。BlueStore直接在原始磁盘上运行BlueStore中的空间分配器确定新数据的位置,新数据使用直接I/O异步写入磁盘内部元数据和用户对象元数据存储在RocksDB中,后者运行在BlueFS上,BlueFS是为RocksDB定制的最小用户空间文件系统BlueStore空间分配器和BlueFS共享磁盘并定期通信以平衡可用空间。本节的其余部分将介绍BlueStore中的元数据和数据管理九:12A. Aghayev等人ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月图5. BlueStore的高级架构使用直接I/O将数据写入原始存储设备元数据被写入在BlueFS之上运行的RocksDB虽然BlueFS在逻辑上是一个单独的组件,但它是为RocksDB设计的用户空间库文件系统,它编译并链接RocksDB,并读取和写入原始存储设备。4.1BlueFS和RocksDBBlueStore通过将元数据存储在RocksDB中来实现其第一个目标,即快速元数据操作Blue-Store通过两个更改实现了第二个目标,即没有一致性开销.首先,它将数据直接写入原始磁盘,导致数据写入的一次缓存刷新其次,它将RocksDB更改为重用WAL文件作为循环缓冲区,从而为元数据写入执行一次缓存刷新--这是一个上游到主流RocksDB的特性RocksDB本身运行在BlueFS上,BlueFS是专门为RocksDB设计的最小文件系统,在原始存储设备上运行。RocksDB在Env接口中从底层文件系统中抽象出其需求BlueFS是这个接口的一个实现,它以用户空间、基于扩展的日志文件系统的形式出现。它实现了RocksDB所需的基本系统调用,例如open、mkdir和pwrite。BlueFS可能的磁盘布局如图6所示。BlueFS为每个文件维护一个inode,其中包括分配给该文件的区段列表超级块存储在一个固定的偏移量,并包含日志的inode日志拥有所有文件系统元数据的唯一副本,它在挂载时加载到内存在每个元数据操作(如目录创建、文件创建和扩展区分配)中,日志和内存中的元数据都将更新。日志不存储在固定位置;其扩展区与其他文件扩展区交错当日志达到预配置的大小时,它将被压缩并写入新位置这些设计决策是可行的,因为大型文件和定期压缩会限制任何时间点的元数据量元数据组织。 BlueStore在RocksDB中保留多个命名空间,每个命名空间存储不同类型的元数据。例如,对象信息存储在O命名空间中(即RocksDB键以O开头,其值表示对象元数据),块分配元数据存储在B命名空间中,集合元数据存储在C命名空间中。每个集合映射到一个PG,并表示池的名称空间的一个碎片集合名称包括池标识符和集合的对象名称共享的前缀例如,键值对C12.e4-6标识池12中的集合,该集合具有以e4的6个有效位开始的散列值的对象。因此,对象O12.e532是成员,而对象O12.e832不是。分布式存储系统中的自定义存储后端九:13ACM Transactions on Storage,Vol.号162、第九条。出版日期:2020年5月图第六章BlueFS的一种可能的磁盘数据布局BlueFS中的元数据只存在于日志中日志没有固定的位置-其扩展区与文件数据交错WAL、WARK和SST文件分别是由RocksDB生成的预写日志文件、调试日志文件和排序字符串表文件。元数据的这种组织允许仅通过改变有效位的数量就将数百万对象的集合分成多个集合例如,当将新OSD添加到群集以增加聚合容量或由于故障而将现有OSD从群集中删除时,此收集拆分操作对于跨OSD重新平衡数据是必要的使用FileStore,集合拆分不同于目录拆分(第3.2节),是一个昂贵的操作,通过重命名目录来完成4.2数据路径和空间分配BlueStore是一个写时复制后端。对于大于最小分配大小(HDD为64KiB, SSDs为 16KiB)的传入写入,数据将写入新分配的扩展区。一旦数据被持久化,相应的元数据就会被插入RocksDB。这使得BlueStore提供了一个有效的克隆操作。克隆操作只是增加依赖区的引用计数,写入操作将定向到新的区。它还允许BlueStore避免对象写入的日志双写和大于最小分配大小的部分覆盖对于小于最小分配大小的写入,数据和元数据都首先插入到RocksDB中作为未来I/O的承诺,然后在事务提交后异步写入磁盘。这种延迟写入机制有两个目的。首先,它批处理小的写入以提高效率,因为新的数据写入需要两个I/O操作,而插入RocksDB需要一个。其次,它基于设备类型优化I/O;在HDD上异步执行64 KiB(或更小)的大型对象重写,以避免读取期间
下载后可阅读完整内容,剩余1页未读,立即下载
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://profile-avatar.csdnimg.cn/default.jpg!1)
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
我的内容管理 收起
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
会员权益专享
最新资源
- 京瓷TASKalfa系列维修手册:安全与操作指南
- 小波变换在视频压缩中的应用
- Microsoft OfficeXP详解:WordXP、ExcelXP和PowerPointXP
- 雀巢在线媒介投放策划:门户网站与广告效果分析
- 用友NC-V56供应链功能升级详解(84页)
- 计算机病毒与防御策略探索
- 企业网NAT技术实践:2022年部署互联网出口策略
- 软件测试面试必备:概念、原则与常见问题解析
- 2022年Windows IIS服务器内外网配置详解与Serv-U FTP服务器安装
- 中国联通:企业级ICT转型与创新实践
- C#图形图像编程深入解析:GDI+与多媒体应用
- Xilinx AXI Interconnect v2.1用户指南
- DIY编程电缆全攻略:接口类型与自制指南
- 电脑维护与硬盘数据恢复指南
- 计算机网络技术专业剖析:人才培养与改革
- 量化多因子指数增强策略:微观视角的实证分析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)