RADOS论文


块式和面向对象的存储架构形成了一种以提升扩展性的存储集群。然而,现存的系统继续把存储节点作为一个被动的设备,尽管他们有能力展示智能和自治。我们提出RADOS的设计和实现,RADOS是一个可靠的面向对象服务,通过利用每个独立节点的智能可以扩展到数千台设备。当允许节点半自治地通过利用集群地图来进行自我复制,错误检测,错误恢复,RADOS保护数据的一致性和强壮的安全语义。我们的实现提供了极好的性能,可靠性,可扩展性,同时,提供给客户端一个逻辑的对象存储。

1.介绍
提供可靠的高性能的规模不断扩大的存储给系统设计者们带来了挑战。高吞吐和低延时的面向文件系,数据库和相关抽象的存储对广泛的应用来说是很重要的。基于块式存储或者对象存储设备(OSD)的聚合集群存储架构正在寻求将低层次的块分配解决方案和安全强制措施分布到智能化存储设备上,从而,通过促进客户端直接访问数据来解决智能化存储设备,简化数据分布和消除IO瓶颈的相关问题。基于商用组件的OSD结合了CPU,网络接口,本地缓存,基础的磁盘或者RAID,把基于块设备接口的存储替换为一个基于命名的变长的对象。

然而,采取这种架构的大规模系统地无法利用设备的智能。因为协议化的存储系统是基于本地或者存储网络的存储设备或者这些兼容T10OSD协议的设备,设备被动地响应读写命令,尽管他们有潜力封装明显的智能。当存储集群增长到数千节点或者更多时,数据迁移的一致性管理,错误检测,错误恢复将给客户端,控制器,元数据目录节点带来极大的压力,限制了可扩展性。

我们已经设计并实现了RADOS,一个可靠的自动的分布式对象存储,它能寻求将设备智能分布到复杂的涉及数据一致性访问,冗余存储,错误检测和恢复等问题的数千节点规模的集群。作为Ceph分布式系统的一部分,RADOS促成了一个优化的平衡的分布式数据和负载,这些数据和负载分布在动态的不均匀的存储集群上,与此同时,RADOS为applications提供一个单一的具有良好的安全语义和强一致保障的逻辑对象存储。

对于PB级的规模,存储系统动态化是有必要的:它们被动态的扩建,它们增长并且与新部署的存储建立联系或使老设备退役,设备出错和恢复是基于连续的数据基础,大量的数据被建立和删除。RADOS确保数据分布对系统的一致性,以及基于cluster map的对象读写的一致性。这个map被复制到所有的节点上(存储和客户端节点),并且被Lazy propagation的增量更新。
【问:客户端需要了解cluster map的复杂性?】
【问:lazy propagation的增量更新具体的解释是什么?】

通过提供给存储节点以完整的数据在系统中的分布信息,设备能够半自治地通过类似点对点的协议来自我管理数据复制,一致和安全的过程更新,参与错误检测,及时响应错误和数据对象复制迁移带来的数据分布变化。这减轻了管理着cluster map主副本的小型monitor集群上的压力,从而,使得剩余的存储集群能够是系统无缝地从几十个节点扩展到数千个节点。

我们的prototype实现提供可供在byte范围可读写的对象接口(就像文件那样),因为那是我们最原始的Ceph的需求。为了防止节点错误和保护数据对象,在OSD集群中数据对象通过N条路被复制。然而,RADOS的可扩展性无法依赖在特定的对象接口或者冗余策略;存储Key-Value的对象和RAID冗余都被计划中。

2.可扩展的集群管理
一个RADOS的系统包括含有大量OSD节点的集合加上一个规模小的负责管理OSD cluster membership的Monitor 集合。每一个OSD节点包括一个CPU,一些易失性内存,一个网络接口和本地磁盘或者RAID。Monitors是有单机进程并且需要少量的本地存储。

2.1Cluster Map
Monitor集群通过管理Cluster Map从而使存储集群被互斥地管理。Cluster Map指定了集群包括哪些OSDs,并简洁地指定了全体数据在系统中的分布。Cluster Map被每一个存储节点和那些与RADOS系统交互的客户端所复制。因为Cluster Map完整地指定了数据分布,客户端提供一个简单的接口用来把整个存储集群(可能一万个节点)虚拟成一个单一的逻辑对象存储。

每一次因为OSD状态变化(例如设备错误)或者其他的触发数据分布的事件所引起的Cluster Map的改变,都会触发map epoch递增。Map epochs允许各党派约定当前的数据分布是什么,决定什么时候他们的信息超时。因为Cluster Map改变很频繁,在非常大的集群中OSDs错误检测和恢复很平常,分布式的OSD更新作为map 增量(Cluster Map):小信息来表述两个成功的map epoch间的差异。在大多数情况,这些更新只是说明了一个或者多个OSD节点出错或者错误恢复,尽管一般情况这些更新可能包括很多设备的状态改变,很多更新被集中处理以便描述新的map epochs。

2.2 数据复制
RADOS使用一种将数据伪随机地分布到设备的协议。当新的设备被添加,一个随机的现存数据的副本将迁徙到新的设备上以实现负载均衡。这种策略使系统维护了一定概率的均衡分布,基本上,保持所有的设备有相似的负载,允许系统在任何可能的负载下都能很好的运行。最重要的,数据复制是一个两阶段的过程,计算了正确的对象存储位置;而且不需要一个大型且笨重的集中分配表。

每个存在系统的对象首先先被映射到Placement Group,一个被同一组的设备复制的逻辑对象集合。每个对象的PG是由对象名o的Hash值,数据主从复制的等级r,和一个控制PG总数的bit来决定的。那么说,pgid=(r,hash(o)& m),m = 2的k次方 - 1,从而限制PG的数量是2的N次方。作为集群规模,通过改变m的值来调整PG的总数,这是周期性必要的;这样渐进地调整了设备间的PG迁徙。

基于Cluster Map,Placement Group被分配给OSD节点,每个PG被映射到有序的包含r个OSD节点的链表中,数据副本将存储在这些映射的PG上。我们的实现利用了CRUSH,一个鲁棒性的副本分布算法,用来计算出稳定的,伪随机地映射。(其他可能的复制策略;对于超大型集群,即使是一个映射PG到设备的表也仍然相对较小(MB级。)从高层上看,CRUSH的行为类似于HASH函数:Placement Groups是确定且是伪随机分布的。和Hash函数不同的是,CRUSH是稳定的:当一个节点加入或者离开集群,PGs仍然在原来的存储位置不变;CRUSH只转移足够的数据来维护一个均衡的分布。相对的,HASHING更倾向于强制地对主要的映射进行重新洗牌。CRUSH也会通过权值控制那些基于容量和性能被分配到每个设备的数据。

Placement Groups提供了一个方法来控制副本declustering的等级。这就是,我们摒弃了一个OSD节点与一个或多个设备(mirroring)共享它的副本,或者和不同的设备(完全分散的)共享对象,副本peers的数量取决PG的数量u----典型的是一个OSD节点包含100个PGs。因为分布是随机的,u也会影响设备利用率:每个OSD节点的PG数和数据负载的均衡情况正相关。更重要的是,declustering促进了分布,通过在OSD节点间独立的复制一个PG来达到并行的错误恢复。同时,通过限制每个设备共享数据的节点数,系统可以限制它暴露出来的设备错误。


2.3设备状态
Cluster Map包含一个描述和当前的分布着数据的设备状态。它包括,所有online or up的节点的当前的网络地址,还有指示所有offline的节点信心。RADOS关心OSD节点生命周期的另一个维度:in类设备被包括在map并且被分配PG,out类设备没有。

对于每一个PG,CRUSH产生一个包含确切r个在map上的OSD节点。然后,RADOS过滤掉那些out类的OSD节点,为PG产生出一个包含active的OSDs的list。如果active list是空的,PG数据是暂时不可用的,阻塞IO。

OSDs通常是up类且在map中积极提供IO服务,或者是down类且不在map中,OSDs产生出一个包含确切r个节点的active list。OSDs可能是down态并且仍存在map中,意味着节点当前是不可用状态且PG数据还没完成remap到其他的OSD节点(就像RAID中的degrade状态)。同样的,OSDs可能是up态且不在map中,意味着节点是online且空闲。这产生了多变的场景,包括容忍没有进行数据迁移前的不连续周期的不可用性(例如,节点重启或者网络阻塞),也包括未能立即启用那些新部署的节点(例如,允许测试网络的可用性),也包括安全的把数据从退役节点迁移到新节点的能力。

2.4Map传播
因为RADOS集群可能包含数千甚至更多的节点,简单的广播MAP来更新所有节点是不可行的。幸运的,当Map epoch在两个通信的OSD节点(或一个OSD一个client)上变化时,Map epochs的变化是明显的,它们必须正确的规则。这使得RADOS可以滞后的部署MAP,通过比较OSD内部的消息,有效的转移部署压力到OSD节点上。

每一个OSD维护了MAP更新的增量历史,标识了所有消息的最新的MAP epoch,保持跟踪了大部分最近最新的MAP epoch。如果一个OSD节点接受了另一个维护过时MAP的节点的消息,当前OSD节点会共享出必要的增量信息来帮其同步。相似的,当与一个带有过时MAP的节点通信,当前节点的增量信息也会优先被共享。为了错误检测,心跳消息周期地交互以确保更新的传播速度----O(log N),N为OSD节点数。

例如,当OSD首先启动,它开始通知一个Monitor它已经online,相应的消息OSDBoot包括它最近的Map epoch。Monitor集群设置OSD的状态为up,也会回应OSD节点且发送必要的更新来帮助OSD节点同步到最新。当一个新的OSD节点开始与其他OSD节点共享数据,受这个“Status Change”影响的一个确定的集合会知道合适的Map更新。因为一个新的OSD节点不知道其他OSD节点有些什么MAP更新,它安全共享出最近的更新历史(最少30秒的增量更新)。

这个优先的MAP共享策略是保守的:一个OSD节点当与其他节点通信时总会共享一个更新,导致OSD节点会接收到重复的更新信息。然而,重复更新的数量取决于一个OSD节点拥有多少个peers,多少peers受PG数量u的限制。在实际中,重复更新的数量远小于这个。

3.智能的存储设备
封装在Cluster Map中的数据分布信息允许把冗余数据,错误检测,错误恢复的管理分布到集群中的OSD节点上。这利用类似点对点的协议开发了OSD节点的智能。

RADOS当前实现了基于每个对象版本和PG短期log的N路复制。OSD节点执行数据复制:clients提交一个简单的写操作到第一个主OSD节点上,这个主OSD节点随后会负责一致和安全的数据复制。这转移了数据复制相关的带宽压力到集群内部的网络,满足了client的需求。对象版本和PG的短期log信息促进了节点错误的快速恢复。

我们会简要的描述RADOS集群架构--主要的,Cluster Map--怎样执行数据复制,错误恢复,和怎样处理冗余数据。

3.1数据复制
RADOS实现了三种数据复制模式:primary- copy,chain,混合模式splay复制。在所有情况下,clients发送IO操作到一个单独的OSD节点,集群确保副本被安全更新,读写语义的一致性。一旦所有副本被更新,一个单独的ack被返回到clients。

primary-copy并行地更新所有副本,在主OSD节点执行读写。Chain写到主OSD节点,在最后OSD节点进行读操作,确保读操作总是反应全部的节点数据更新。Splay结合并行地对主OSD节点读写。最主要的优点是,对2路的mirroring有较短的message跳数。

3.2强一致性
所有的RADOS消息--产生自clients或OSD节点---都被发送端的MAP epoch标记,来确保所有的操作是强一致的。如果一个client因为维护过时MAP导致发送IO到一个错误的OSD节点,OSD会响应一个合适的增量更新,以便client可以重定向request。这避免了主动与client共享Map更新:它们会学会与集群交互。在大多数情况下,它们在不影响当前操作的前提下学会去更新且允许future IO被准确地重定向。

如果Cluster Map的主副本中一个特定PG的membership被修改,(数据更新)可能仍以过时的membership进行,因为节点还不知道这个更新。如果这个更新先被一个PG副本感知,当主OSD更新副本时,PG所在的节点将会把新membership的更新暴露出去。这是很安全的,因为任何OSD集合新负责一个PG时需要和所有以前负责这个PG的节点来通信以确保PG内容的正确性,这确保了以前的OSDs感知更新且在新OSD节点工作前停止执行IO。

相较更新而言,强一致性的读操作显得不太natural。当网络错误导致一个OSD节点局部不可用时,读操作失败,但是对于维护着过时MAP的client,这个OSD节点仍可用。同时,更新的MAP会指定一个新的OSD节点取代错误的OSD节点。为了防止老的OSD节点继续提供IO服务,我们需要及时的心跳消息。如果OSD的读操作没在H秒内没有收到心跳消息,读操作将block。


你可能感兴趣的:(RADOS论文)