ceph架构核心之RADOS

一、ceph生态系统的概念架构

图一：ceph生态系统的概念架构

ceph生态系统可以大致划分为四部分（见图 1）：客户端（数据用户），元数据服务器（缓存和同步分布式元数据），一个对象存储集群（将数据和元数据作为对象存储，执行其他关键职能），以及最后的集群监视器（执行监视功能）。

客户使用元数据服务器，执行元数据操作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。

Com：元数据服务器：确定数据存储位置管理更高层次的POSIX提供的（打开、关闭、重命名等接口功能）

对象存储集群管理：读写文件等POSIX功能

图二：ceph生态系统简化后的分层视图

图三：一个简单的ceph生态系统

二、Ceph架构核心之RADOS

RADOS（Reliable,Autonomic Distributed Object Store）在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统。事实上，RADOS也可以单独作为一种分布式数据存储系统，给适合相应需求的分布式文件系统提供数据存储服务。

图四：RADOS系统架构图

主要包括两个部分，如图四所示：

1．由数目可变的大规模OSDs（ObjectStorage Devices）组成的机群，负责存储所有的Objects数据；

2．由少量Monitors组成的强耦合、小规模机群，负责管理Cluster Map，其中Cluster Map是整个RADOS系统的关键数据结构，管理机群中的所有成员、关系、属性等信息以及数据的分发。

对于RADOS系统，节点组织管理和数据分发策略均有内部的Monitors全权负责，所以，从Clients角度设计相对比较简单，它给应用提供的仅为简单的存储接口。

RADOS详细介绍

扩展机群

A. Cluster Map

存储机群的管理，唯一的途径是ClusterMap通过对MonitorCluster操作完成。ClusterMap是整个RADOS系统的核心数据结构，其中指定了机群中的OSDs信息和所有数据的分布情况。所有涉及到RADOS系统的Storage节点和Clients都有最新epoch的ClusterMap副本。因为ClusterMap的特殊性，Client向上提供了非常简单的接口实现将整个存储机群抽象为单一的逻辑对象存储结构。

Cluster Map的更新由OSD的状态变化或者其他事件造成数据层的变化驱动，每一次ClusterMap更新都需要将mapepoch增加，mapepoch使ClusterMap在所有节点上的副本都保持同步，同时，mapepoch可以使一些过期的ClusterMap能够通过通信对等节点及时更新。

在大规模的分布式系统中，OSDs的failures/recoveries是常见的，所以，ClusterMap的更新就比较频繁，如果将整个ClusterMap进行分发或广播显然会造成资源的浪费，RADOS采用分发incrementalmap的策略避免资源浪费，其中incrementalmap仅包含了两个连续epoch之间ClusterMap的增量信息。

B. Data Placement

数据迁移：当有新的储存设备加入时，机群上的数据会随机的选出一部分迁移到新的设备上，维持现有存储结构的平衡。

数据分发：通过两个阶段的计算得到合适的Object的存储位置。如图五所示。

图五数据分发图示

1．Object到PG的映射。PG(Placement Group)是Objects的逻辑集合。相同PG里的Object会被系统分发到相同的OSDs集合中。由Object的名称通过Hash算法得到的结果结合其他一些修正参数可以得到Object所对应的PG。

2．RADOS系统根据根据ClusterMap将PGs分配到相应的OSDs。这组OSDs正是PG中的Objects数据的存储位置。RADOS采用CRUSH算法实现了一种稳定、伪随机的hash算法。CRUSH实现了平衡的和与容量相关的数据分配策略。CRUSH得到的一组OSDs还不是最终的数据存储目标，需要经过初步的filter，因为对于大规模的分布式机群，宕机等原因使得部分节点可能失效，filter就是为过滤这些节点，如果过滤后存储目标不能满足使用则阻塞当前操作。

C. Device State

图五：Device State描述

D. Map propagate

OSD之间的更新是通过一种抢占式的方法进行。ClusterMap epoch的差异只有在两个通信实体之间有意义，两个通信实体在进行信息交换之前都需要交换epoch，保证ClusterMap的同步。这一属性使得ClusterMap在通信实体内部之间的更新分担了全局的ClusterMap分发压力。

每一个OSD都会缓存最近ClusterMap和到当前时刻的所有incrementalmap信息，OSD的所有message都会嵌入incrementalmap，同时侦听与其通信的peer的ClusterMap epoch。当从peer收到的message中发现其epoch是过期的，OSDshare相对peer来说的incrementalmap，使通信的peers都保持同步；同样的，当从peer收到message中发现本地epoch过期，从其嵌入到message中的incrementalmap中分析得到相对本地的incrementalmap然后更新，保持同步。

不是同一个通信对等方的两个OSD之间的epoch差异，不影响同步。

智能存储

A. Replication

RADOS实现了三种不同的Replication方案，见下图六示：

图六：三种不同的Replication方案

图六RADOS实现的三种replication方案

Primary-copy：读写操作均在primaryOSD上进行，并行更新replicas；
Chain：链式读写，读写分离；
Spaly：Primary-copy和Chain的折中方案：并行更新replicas和读写分离。

B. Consistency

一致性问题主要有两个方面，分别是Update和Read：

1. Update：在RADOS系统中所有Message都嵌入了发送端的map epoch协调机群的一致性。

2. Read：为避免部分OSD失效导致数据不能从该OSD读需要转向新的OSD，但是read operation的发起方还没有该OSD的失效信息的问题，同一个PG所在的OSDs需要实时交换Heartbeat。
   
   

C. Failure detection

错误检测：RADOS采取异步、有序的点对点Heartbeat。(此处的错误检测是OSDs自身检测)

D. Data Migration & FailureRecovery

由于设备失效、机群扩展、错误恢复造成的ClusterMap更新使得PG到OSDs的对应关系发生了变化，一旦ClusterMap发生变化，相应的OSDs上的数据也需要做相应的调整。数据的移植和数据恢复都是由PrimaryOSD负责统一完成。

Monitor

Monitors是Cluster Map主备份存储目标，所有其他位置上的Cluster Map最初都是从Monitors请求得到。Monitors通过对Cluster Map的周期更新升级实现存储机群的管理。

Monitor的工作分两个阶段：

1．首先在多个Monitors中选举Leader，之后Leader向所有Monitors请求Map Epoch，Monitors周期性向Leader汇报结果并告知其活跃(Active Monitor)，Leader统计Quorum。这阶段的意义是保证所有的Monitors的Map Epoch都是最新的，通过Incrementalupdates对已失效的Cluster Map进行更新。

2．Leader周期向每一个Active Monitor授权许可提供分发Cluster Map副本给OSDs和Clients的服务。当授权失效但Leader仍没有重新分发认为Leader died，此时重回第一阶段进行Leader重选；当Active Monitor没有周期向Leader反馈ACK则认为有Monitor died，重回第一阶段进行Leader选举并更新Quorum。Leader周期分发Lease和Active Monitor周期反馈ACK的另外一个作用是同步Monitors的Cluster Map。Active Monitor收到Update请求时，首先验证当前的Epoch是否为最新，如果不是，更新后向上汇报到Leader，Leader分发给所有的Monitors，同时回收授权，重新开始新一轮的Leader选举到Cluster Map服务。

通常Monitor的负载比较小：OSDs上的Cluster Map更新通过OSDs之间的机制实现；OSDs的状态变化比较罕见不会对Monitors的负载造成影响。但是一些特殊情况可能会对Monitors负载带来影响，比如：同时有n OSDs failed，每一个OSD store m个PGs，此时会形成m×n个failure report到达Monitors，对于规模较大的机群这样的数据量比较大。为避免这种情况给Monitor带来的负载压力，OSDs采用伪随机的时间间隔交错安排failure检测(此处是从OSDs到Monitor的检测)向上汇报，另外根据Monitors的并行化和负载均衡分配的特点，扩展Monitors是解决Monitors的负载压力的另一措施。

总结

与传统的分布式数据存储不同，RADOS最大的特点是：

1．将文件映射到Objects后利用Cluster Map通过CRUSH计算而不是查找表方式定位文件数据在存储设备中的位置。省去了传统的File到Block的映射和BlockMap管理。

2．RADOS充分利用了OSDs的智能特点，将部分任务授权给OSDs，最大程度的实现可扩展。