(完整版)Ceph分布式存储

1、Ceph分布式存储系统Ceph是根据加州大学SantaCruz分校的SageWeil的博士论文所设计开发的新一代自由软件分布式文件系统，其设计目标是良好的可扩展性（PB级别以上）、高性能及高可靠性。Ceph其命名和UCSC（Ceph的诞生地）的吉祥物有关，这个吉祥物是“Sammy，一个香蕉色的蛞蝓，就是头足类中无壳的软体动物。这些有多触角的头足类动物，是对一个分布式文件系统高度并行的形象比喻。其设计遵循了三个原则：数据与元数据的分离，动态的分布式的元数据管理，可靠统一的分布式对象存储机制。本文将从Ceph的架构出发，综合性的介绍Ceph分布式文件系统特点及其实现方式。、Ceph基本架构Ceph

2、是一个高可用、易于管理、开源的分布式存储系统，可以在一套系统中同时提供对象口、对象存取接口和文件系统接口组成，如图所示宿主机,一个基fXfi的舶w网看,玉容53和加如，个U口、对象存取接口和文件系统接口组成，如图所示宿主机,一个基fXfi的舶w网看,玉容53和加如，个U密的，嗯用1屈皿内核用口fUQtMU/DM驮动的全楠分布的块地密-力与叫位而兼容分布式文件案绦忸EliLJK内梭用户井且支持FU*卜IBKADOS一-能让应用通过对C、C+,J?ivaj.Pyilion、Ruby和Hr1的支持直接连谢劭坯的仓麻Ceph的底层是RADOS，它的意思是“Areliable,autonomous,di

3、stributedobjectstorage。RADOS作为Ceph分布式文件系统的一个子项目，是为了满足Ceph的需求而设计的，但是，其也可以单独作为一种分布式数据存储系统，给其他的有类似需求的分布式文件系统提供数据存储服务。Ceph文件系统,Ceph对象存储和Ceph块设备从RADOS的存储集群中读去和写入数据。Ceph作为一个分布式存储系统，其对外提供的接口，决定了其通用性以及扩展性。如上图架构图中所示的那样，Ceph对外提供了丰富多样的服务接口，包括多种编程语言接口LIBRADOS(备注，上图来自Ceph中文社区，社区人员在翻译的过程中将字母L遗失掉了)、对象存储接口(RADOSGW)

4、、块存储接口(RBD)以及文件系统接口(CephFS)。其中LIBRADOS编程接口是其他各种客户端接口的基础，其他接口都是基于LIBRADOS来进行扩展实现的。Ceph中RADOS(ReliableAutonomicDistributedObjectStore)存储集群是所有其他客户端接口使用和部署的基础。RADOS由两个组件组成：OSD：ObjectStorageDevice，提供存储资源。Monitor：维护整个Ceph集群的全局状态。OSDsMonitorsOSDs典型的RADOS部署架构由少量的Monitor监控器以及大量的OSD存储设备组成，它能够在动态变化的基于异质结构的存储设备

5、集群之上提供一种稳定的、可扩展的、高性能的单一逻辑对象存储接口。CfejwiuoQikireERdi叫GSDs一寸一二。RADOSCfejwiuoQikireERdi叫GSDs一寸一二。我们看到，RADOS不是某种组件，而是由OSD(ObjectStorageDevice)集群和Monitor集群组成。通常，一个RADOS系统中，OSD集群是由大量的智能化的OSD节点组成；Monitor集群是由少量的Monitor节点组成。OSD集群负责存储所有对象的数据。Monitors集群负责管理Ceph集群中所有成员、关系、属性以及数据分发等信息。Ceph客户端接口(Clients)我们将Ceph架构中

6、除了底层基础RADOS之上的LIBRADOS、RADOSGW、RBD以及CephFS统一称为Ceph客户端接口。而LIBRADOS又是Ceph其它如RADOSGW、RBD以及CephFS的基础。简而言之就是RADOSGW、RBD以及CephFS根据LIBRADOS提供的多编程语言接口开发。所以他们之间是一个阶梯级的关系。RADOSGWRADOSGW(RADOSGmeway)，又叫Ceph对象存储网关，是一个底层基于librados向客户端提供RESTful接口的对象存储接口。目前Ceph支持两种API接口：Spatible：S3兼容的接口，提供与AmazonS3大部分RESTfuIAPI接口兼

7、容的API接口。(2)Spatible：提供与OpenStackSwift大部分接口兼容的API接口。Ceph的对象存储使用网关守护进程(radosgw),radosgw结构图如图所示：S3compatibleAPISwiftcompatibleAPIradosgwlibradosOSDsMonitors在实际的Ceph集群中，radosgw是一个监听RESTfulAPI访问的后台进程，s3API和SwiftAPl使用同一个命名空间，即共享同一个命名空间；所以，你可以用其中一个接口写入数据而又用另外一个接口读出数据。1.2.2.RBD一个数据块是一个字节序列(例如，一个512字节的数据块)。基

8、于数据块存储接口最常见的介质，如硬盘，光盘，软盘，甚至是传统的9磁道的磁带的方式来存储数据。块设备接口的普及使得虚拟块设备成为构建像Ceph海量数据存储系统理想选择。在一个Ceph的集群中，Ceph的块设备支持自动精简配置，调整大小和存储数据。Ceph的块设备可以充分利用RADOS功能，实现如快照，复制和数据一致性。Ceph的RADOS块设备(即RBD)通过RADOS协议与内核模块或librbd的库进行交互。RBD的结构如图所示：KernelModulelibrbdRADOSProtocolOSDsMonitors在Ceph中，如果客户端要想使用存储集群服务提供的块存储，必须要先安装相应的Li

9、nux内核模块KernelModule，或者使用librbd编程接口。1.2.3.CephFSCeph文件系统（CEPHFS）是一个POSIX兼容的文件系统，使用Ceph的存储集群来存储其数据。Ceph的文件系统使用相同的Ceph的存储集群系统比如Ceph的块设备，Ceph的S3和SwiftAPI对象存储，或本机绑定（librados）。CEPHFS的结构图如下所示：CephFSKernelObjectCephFSFUSECephFSLibraiy(libcephfs)CephStorageClusterProtocol(librados)OSDsMDSsMonitorsCEPHFS是一个符合

10、POSIX标准的文件系统接口，同时支持用户空间文件系统FUSE。在CEPHFS中，与对象存储接口与块存储接口最大的不同就是在集群中增加了文件系统元数据服务节点MDS（CephMetadataServer）。MDS也支持多台机器分布式的部署，以实现系统的高可用性。文件系统客户端需要安装对应的Linux内核模块CephFSKernelObject或者CephFSFUSE组件。二、Ceph数据存储2.1.数据存储过程Ceph存储集群从客户端接收文件，每个文件都会被客户端切分成一个或多个对象，然后将这些对象进行分组，再根据一定的策略存储到集群的OSD节点中，其存储过程如图所示：图中，对象的分发需要经过

11、两个阶段的计算，才能得到存储该对象的OSD,然后将对象存储到OSD中对应的位置。对象到PG的映射。PG（PlaccmentGroup）是对象的逻辑集合。PG是系统向OSD节点分发数据的基本单位，相同PG里的对象将被分发到相同的OSD节点中（一个主OSD节点多个备份OSD节点）。对象的PG是由对象ID号通过Hash算法，结合其他一些修正参数得到的。（2）PG到相应的OSD的映射，RADOS系统利用相应的哈希算法根据系统当前的状态以及PG的ID号，将各个PG分发到OSD集群中。OSD集群是根据物理节点的容错区域（比如机架、机房等）来进行划分的。Ceph中的OSD节点将所有的对象存储在一个没有分层和

12、目录的统一的命名空问中。每个对象都包含一个ID号、若干二进制数据以及相应的元数据。ID号在整个存储集群中是唯一的；元数据标识了所存储数据的属性。一个对象在OSD节点中的存储方式大致如图所示。MetadataIDBinai-yDataMetadata123401L01L010101L01L01L001L101L01L01001L0namelvauel01101L100001101L011001L10JL01101001L0name2vaue201101L100001101L0110011101L01L01001L0nameNvaueN而对存储数据的语义解释完全交给相应的客户端来完成，比如，Cep

13、hFS客户端将文件元数据（比如所有者、创建日期、修改日期等）作为对象属性存储在Ceph中。算法Ceph作为一个高可用、高性能的对象存储系统，其数据读取及写入方式是保证其高可用性及高性能的重要手段。对于已知的数据对象，Ccph通过使用CRUSH(ControlledReplicationUnderScalableHashing)算法计算出其在Ceph集群中的位置，然后直接与对应的OSD设备进行交互，进行数据读取或者写入。例如其写入数据的其主要过程如图所示。首先，客户端获取Ceph存储系统的状态信息ClusterM叩，然后根据状态信息以及将要写入的Pool的CRUSH相关信息，获取到数据将要写入的

14、OSD，最后OSD将数据写入到其中相应的存储位置。其中相关概念的解释如下：(1)集群地图(ClusterM叩)：Ceph依赖于客户端以及OSD进程中保存有整个集群相关的拓扑信息，来实现集群的管理和数据的读写。整个集群相关的拓扑信息就称之为“ClusterM叩”。ClusterM叩主要保存Monitor集群、OSD集群、MDS集群等相关的拓扑结构信息以及状态信息。(2)存储池(P001)：是对Ceph集群进行的逻辑划分，主要设置其中存储对象的权限、备份数目、PG数以及CRUSH规则等属性。在传统的存储系统中，要查找数据通常是依赖于查找系统的的文件索引表找到对应的数据在磁盘中的位置。而在Ceph对

15、象存储系统中，客户端与OSD节点都使用CRUSH算法来高效的计算所存储数据的相关信息。相对于传统的方式，CRUSH提供了一种更好的数据管理机制，它能够将数据管理的大部分工作都分配给客户端和OSD节点，这样为集群的扩大和存储容量的动态扩展带来了很大的方便。CRUSH是一种伪随机数据分布算法，它能够在具有层级结构的存储集群中有效的分发对象副本。CRUSH算法是根据集群中存储设备的权重来进行数据分发的，数据在各个OSD设备上近似均匀概率分布。CRUSH中，数据在存储设备上的分布是根据一个层次化的集群地图(ClusterM叩)来决定的。集群地图是由可用的存储资源以及由这些存储资源构建的集群的逻辑单元组

16、成。比如一个Ceph存储集群的集群地图的结构可能是一排排大型的机柜，每个机柜中包含多个机架，每个机架中放置着存储设备。数据分发策略是依照数据的存放规则(placementrules)进行定义的，存放规则是指数据在备份以及存放时应该遵循的相关约定，比如约定一个对象的三个副本应该存放在三个不同的物理机架上。给定一个值为x的整数，CRUSH将根据相应的策略进行哈希计算输出一个有序的包含n个存储目标的序列：CRUSH(x)=(osd1，osd2，osd3osdn)CRUSH利用健壮的哈希函数，其得到的结果依赖于集群地图ClusterMap、存放规贝则(placementmles)和输入x。并且CRUS

17、H是一个伪随机算法，两个相似的输入得到的结果是没有明显的相关性的。这样就能确保Ceph中数据分布是随机均匀的。2.3.数据一致性Ceph中，为了保持数据的一致性，在PG内部通常会进行对象的净化过程(scrubobjects)。数据净化通常每天进行一次(通常在数据I/O量不大，进行系统维护时进行)。OSD设备还能够通过进行数据对象bit-for-bit的对比进行深度的数据净化，用以找到普通数据净化中不易察觉的问题(比如磁盘扇区损坏等)。通过数据维护和净化，为数据的一致性提供了保障。三、扩展性和高可用性在传统的分布式系统中，客户端通常与一个中央节点进行交互，这样通常存在着单点故障问题，而且不利于系

18、统的扩展。Ceph中客户端是直接与OSD节点进行交互，而不需要通过中心节点。对同一个对象，Ceph通常会在不同的OSD节点上创建多个备份，这样就保证了数据可靠性和高可用性。Ceph对元数据服务器也采用高可用的集群管理，这样也提高了系统元数据的的高可用性。Ceph的良好的高可用性和扩展性是系统设计的核心，这其中用到了很多精巧的设计和算法，下面就对实现Ceph的一些关键的实现技术进行介绍。高可用性的Monitor集群在Ceph的客户端读或者写数据之前，他们必须先通过CephMonitor来获取最新的ClusterMap的副本。如果只有一个Monitor节点，Ceph存储集群也可以正常工作，但是这样

19、会有单点的风险(如果这一台Monitor节点宕机了，整个Ceph集群就无法正常工作)。Ceph中支持多台Monitor节点组成高可用的集群来提高整个Ceph系统的高可用性。Ceph中通过Paxos算法来保持Monitor集群中各个节点的状态一致性。高可用性的MDS集群在通过CephFS接口使用Ceph集群时，Ceph集群中需要部署MDS(MetadataServer)进程，通常也是使用集群的方式进行部署。MDS集群的主要作用是将所有的文件系统元数据(目录、文件拥有者、访问权限等)存放在高可用的内存中。这样，客户端简单的文件操作(区cd等)将由MDS集群快速的响应，而不用消耗OSD设备的I/O,

20、实现了元数据与数据的分离。为CephFS文件系统接口将能提供了性能上的保证。CcphFS旨在提供POSIX兼容的文件系统接口，依赖于MDS中运行的ceph-mds进程，该进程不仅能够作为一个单一的进程运行，还可以分布式的运行在多个服务器上，实现了高可用性和扩展性。(1)高可用性：通常在Ceph集群中有多个ceph-mds进程在运行。当一个Ceph-mds出现运行故障时，备用的其他的ceph-mds能够立刻接替失效的ceph-mds的工作。这个过程主要依赖于Ceph中的日志机制并且通过高可用的Monitor进程来完成相关的恢复工作。(2)扩展性：Ceph集群中可以分布式的部署多个ceph-mds

21、进程实例，他们共同完成Ceph文件系统相关的工作，并且能够动态的实现负载均衡。超大规模智能守护(OSD)在许多传统的集群架构中，往往设立一个中心节点来掌控整个集群的全部元数据信息，这样不仅会因为单点问题对系统的高可用性造成影响，而且中心节点的性能也会成为系统横向扩展的瓶颈。在Ceph就没有这样的瓶颈，在Ceph中，每个Ceph的客户端和OSD节点都保存有整个系统相关的拓扑信息。这样，客户端就能直接和存储数据的OSD节点进行交互，OSD节点相互之间也能直接进行交互。Ceph中去中心节点的架构能够带来以下一些好处：OSD节点能直接为客户端提供服务：我们知道，任何网络设备都有一个并发连接的上限。中心

22、节点结构的分布式集群中，中心节点往往是整个系统性能的瓶颈。Ceph中客户端能与存放数据的OSD节点直接通信，而不用经过任何的中心节点，这样整个系统不仅没有单点问题，而且性能就得到了很大的提升。OSD节点参与系统的维护：通常一个OSD节点加入到Ceph存储集群中，要向集群中的Monitor节点汇报自己的状态。如果OSD节点宕机，则需要系统能自动检测出来。这通常是由Monitor节点周期性的对各个OSD节点中的相关服务进行检测来实现。如果Monitor节点检测的周期间隔太短会影响系统的性能；而如果检测周期间隔太长，则会使整个系统有较长的时间处于不一致的状态。Ceph中允许OSD节点对相邻的OSD节

23、点的状态进行检测，如果相邻的节点有状态变化，OSD节点则会主动向整个集群进行汇报，同时集群中相关的ClusterMap得到更新。这样大大减轻了Monitor节点的压力。系统的扩展性和高可用性得到很大的提升。OSD节点定期的数据清洁：数据清洁是指，一个OSD节点中存储的对象与另外一个存储该对象副本的OSD节点之间进行对象的元数据对比，依此来找出文件系统相关的错误。Ceph中OSD节点能够自动的进行数据清洁(通常是一天一次)。除了普通的数据清洁，Ceph中OSD节点还可以通过对相同对象不同副本中的数据进行按位(bit-for-bit)的深度数据清洁(通常一周一次)。这种数据清洁机制对系统的数据一致

24、性有很大的帮助。数据智能备份：和Ceph客户端一样，CephOSD节点也使用CRUSH算法。但是和客户端使用CRUSH算法来查找数据不同，CephOSD节点使用该算法来计算对象的备份副本应该被存储在哪个位置。数据智能备份的大致流程如图所示：智能负载均衡当在Ceph集群中增加或减少OSD设备时，集群会执行负载再均衡的过程(rebalancing)。首先，集群地图(ClusterMap)会得到更新，PGID以及OSD集群相关的信息都会得到更新。如下图，简单展示了增加OSD存储设备时数据再均衡的大致过程。其中，一些PG从其原来所处的OSD存储设备迁移到了新的OSD存储设备。在数据再均衡过程中，CRU

25、SH保持稳定，有许多的PG还是依然保留其原有的配置。并且由于进行了数据的迁出，原有OSD设备中的剩余容量也会相应的有所增加。整个数据再均衡过程也是利用的CRUSH算法，数据依然是均衡的分布在新的OSD集群中。BeforeMed17345#BeforeMed17345#GGQGGppP口口PG#1AGPG#4PG#5四、小结在本文中，我们介绍了Ceph分布式文件系统的基本架构、工作机制及原理。并且从架构和原理的基础上论述了其优良的特性。综合看来，Ceph分布式文件系统有如下的特点：Ceph的核心RADOS通常是由少量的负责集群管理的Monitor进程和大量的负责数据存储的OSD进程构成，采用无中

26、心节点的分布式架构，对数据进行分块多份存储。具有良好的扩展性和高可用性。Ceph分布式文件系统提供了多种客户端，包括对象存储接口、块存储接口以及文件系统接口，具有广泛的适用性，并且客户端与存储数据的OSD设备直接进行数据交互，大大提高了数据的存取性能。Ceph作为分布式文件系统，其能够在维护POSIX兼容性的同时加入了复制和容错功能。从2010年3月底，以及可以在Linux内核(从2.6.34版开始)中找到Ceph的身影，作为Linux的文件系统备选之一，Ceph.ko已经集成入Linux内核之中。虽然目前Ceph可能还不适用于生产环境，但它对测试目的还是非常有用的。Ceph不仅仅是一个文件系

27、统，还是一个有企业级功能的对象存储生态环境。现在，Ceph已经被集成在主线Linux内核中，但只是被标识为实验性的。在这种状态下的文件系统对测试是有用的，但是对生产环境没有做好准备。但是考虑到Ceph加入到Linux内核的行列，不久的将来，它应该就能用于解决海量存储的需要了。五、参考资料Ceph中文文档：/ceph HYPERLINK /ceph/ceph4e2d658765876863/ceph-1 /ceph/ceph4e2d658765876863/ceph-1Ceph的工作原理及流程本节将对Ceph的工作原理和若干关键工作流程进行扼要介绍。如前所述，由于Ceph的功能实现本质上依托于R

28、ADOS，因而，此处的介绍事实上也是针对RADOS进行。对于上层的部分，特别是RADOSGW和RBD，由于现有的文档中（包括Sage的论文中）并未详细介绍，还请读者多多包涵。首先介绍RADOS中最为核心的、基于计算的对象寻址机制，然后说明对象存取的工作流程，之后介绍RADOS集群维护的工作过程，最后结合Ceph的结构和原理对其技术优势加以回顾和剖析。寻址流程Ceph系统中的寻址流程如下图所示：上图左侧的几个概念说明如下：File此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的对象”，也就是用户直接操作的对象”。Ojbect

29、一一此处的object是RADOS所看到的对象。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4乂8），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的对象这一名词，而直接使用file或object进行说明。PG（PlacementGroup）一一顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一

30、个object只能被映射到一个PG中，即，PG和object之间是一对多映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是多对多映射关系。在实践当中，n至少为2,如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。OSD即objectstoragedevice，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应

31、有的优势。Failuredomain这个概念在论文中并没有进行定义，好在对分布式存储系统有一定概念的读者应该能够了解其大意。基于上述定义，便可以对寻址流程进行解释了。具体而言，Ceph中的寻址至少要经历以下三次映射：File-object映射这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分，相当于RAID中的条带化过程。这种切分的好处有二：一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并

32、行化处理。每一个切分后产生的object将获得唯一的oid，即objectid。其产生方式也是线性映射，极其简单。图中，ino是待操作file的元数据，可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该fileid之后得到的。举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到的oid就依次为filename。、filename1和filename2。这里隐含的问题是，ino的唯一性必须得到保证，否则后续映射无法正确进行。Object-PG映射在

33、file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。这个映射过程也很简单，如图中所示，其计算公式是：hash（oid）&mask-pgid由此可见，其计算由两步组成。首先是使用Ceph系统指定的一个静态哈希函数计算oid的哈希值，将oid映射成为一个近似均匀分布的伪随机值。然后，将这个伪随机值和mask按位相与，得到最终的PG序号（pgid）。根据RADOS的设计，给定PG的总数为m（m应该为2的整数幂），则mask的值为m-1。因此，哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。基于这一机制，当有大量object和大

34、量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的size相同，因而，这一映射最终保证了，各个PG中存储的object的总数据量近似均匀。从介绍不难看出，这里反复强调了大量。只有当object和PG的数量较多时，这种伪随机关系的近似均匀性才能成立，Ceph的数据存储均匀性才有保证。为保证大量的成立，一方面，object的最大size应该被合理配置，以使得同样数量的file能够被切分成更多的object；另一方面，Ceph也推荐PG总数应该为OSD总数的数百倍，以保证有足够数量的PG可供映射。PG-OSD映射第三次映射就

35、是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。如图所示，RADOS采用一个名为CRUSH的算法，将pgid代入其中，然后得到一组共n个OSD。这n个OSD即共同负责存储和维护一个PG中的所有object。前已述及，n的数值可以根据实际应用中对于可靠性的需求而配置，在生产环境下通常为3。具体到每个OSD，则由其上运行的OSDdeamon负责执行映射到本地的object在本地文件系统中的存储、访问、元数据维护等操作。和“object-PG”映射中采用的哈希算法不同，这个CRUSH算法的结果不是绝对不变的，而是受到其他因素的影响。其影响因素主要有二：一是当前系统状态，也就是

36、上文逻辑结构中曾经提及的clustermap。当系统中的OSD状态、数量发生变化时，clustermap可能发生变化，而这种变化将会影响到PG与OSD之间的映射。二是存储策略配置。这里的策略主要与安全相关。利用策略配置，系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上，从而进一步改善存储的可靠性。因此，只有在系统状态(clustermap)和存储策略都不发生变化的时候，PG和OSD之间的映射关系才是固定不变的。在实际使用当中，策略一经配置通常不会改变。而系统状态的改变或者是由于设备损坏，或者是因为存储集群规模扩大。好在Ceph本身提供了对于这种变化的自动化支持

37、，因而，即便PG与OSD之间的映射关系发生了变化，也并不会对应用造成困扰。事实上，Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性，Ceph可以将一个PG根据需要动态迁移到不同的OSD组合上，从而自动化地实现高可靠性、数据分布re-blancing等特性。之所以在此次映射中使用CRUSH算法，而不是其他哈希算法，原因之一正是CRUSH具有上述可配置特性，可以根据管理员的配置参数决定OSD的物理位置映射策略；另一方面是因为CRUSH具有特殊的稳定性，也即，当系统中加入新的OSD，导致系统规模增大时，大部分PG与OSD之间的映射关系不会发生改变，只有少部分PG的映射关系

38、会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此，CRUSH算法的设计也是Ceph的核心内容之一，具体介绍可以参考。至此为止，Ceph通过三次映射，完成了从file到object、PG和OSD整个映射过程。通观整个过程，可以看到，这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构clustermap,在后文中将加以介绍。可以在这里指明的是，clustermap的维护和操作都是轻量级的，不会对系统的可扩展性、性能等因素造成不良影响。一个可能出现的困惑是：为什么需要同时设计第二次和第三次映射？难道不重复么？关于这一点，Sage在其论文中解说不多，而笔者个人的

39、分析如下：我们可以反过来想像一下，如果没有PG这一层映射，又会怎么样呢？在这种情况下，一定需要采用某种算法，将object直接映射到一组OSD上。如果这种算法是某种固定映射的哈希算法，则意味着一个object将被固定映射在一组OSD上，当其中一个或多个OSD损坏时，object无法被自动迁移至其他OSD上（因为映射函数不允许），当系统为了扩容新增了OSD时，object也无法被re-balance到新的OSD上（同样因为映射函数不允许）。这些限制都违背了Ceph系统高可靠性、高自动化的设计初衷。如果采用一个动态算法（例如仍然采用CRUSH算法）来完成这一映射，似乎是可以避免静态映射导致的问题。

40、但是，其结果将是各个OSD所处理的本地元数据量爆增，由此带来的计算复杂度和维护工作量也是难以承受的。例如，在Ceph的现有机制中，一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个OSD上大约承载数百个PG，每个PG内通常有3个OSD，因此，一段时间内，一个OSD大约需要进行数百至数千次OSD信息交换。然而，如果没有PG的存在，则一个OSD需要和与其共同承载同一个object的其他OSD交换信息。由于每个OSD上承载的object很可能高达数百万个，因此，同样长度的一段时间内，一个OSD大约需要进行的OSD间信息交换将暴涨至数

41、百万乃至数千万次。而这种状态维护成本显然过高。综上所述，笔者认为，引入PG的好处至少有二：一方面实现了object和OSD之间的动态映射，从而为Ceph的可靠性、自动化等特性的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。理解这一点，对于彻底理解Ceph的对象寻址机制，是十分重要的。数据操作流程此处将首先以file写入过程为例，对数据操作流程进行说明。为简化说明，便于理解，此处进行若干假定。首先，假定待写入的file较小，无需切分，仅被映射为一个object。其次，假定系统中一个PG被映射到3个OSD上。基于上述假定，则file写入流程可以被下图表示：如图所

42、示，当某个client需要向Ceph集群写入一个file时，首先需要在本地完成5.1节中所叙述的寻址流程，将file变为一个object，然后找出存储该object的一组三个OSD。这三个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的PrimaryOSD，而后两个则依次是SecondaryOSD和TertiaryOSD。找出三个OSD后，client将直接和PrimaryOSD通信，发起写入操作（步骤1）。PrimaryOSD收到请求后，分别向SecondaryOSD和TertiaryOSD发起写入操作（步骤2、3）。当SecondaryOSD和TertiaryOSD各自完成写

43、入操作后，将分别向PrimaryOSD发送确认信息（步骤4、5）。当PrimaryOSD确信其他两个OSD的写入完成后，则自己也完成数据写入，并向client确认object写入操作完成（步骤6）。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免造成数据丢失。同时，由于client只需要向PrimaryOSD发送数据，因此，在Internet使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向client发送确认信号，则整体延迟可能难以忍受。因此，Ceph可以分两次向clie

44、nt进行确认。当各个OSD都将数据写入内存缓冲区后，就先向client发送一次确认，此时client即可以向下执行。待各个OSD都将数据写入磁盘后，会向client发送一个最终确认信号，此时client可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，client可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的client可以同时和大量的OSD进行并行操作。同时，如果一个file被切分成多个object，这多个object也可被并行发送至多个OSD。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个

45、OSD变成性能瓶颈。如果需要读取数据，client只需完成同样的寻址过程，并直接和PrimaryOSD联系。目前的Ceph设计中，被读取的数据仅由PrimaryOSD提供。但目前也有分散读取压力以提高性能的讨论。集群维护前面的介绍中已经提到，由若干个monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同形成clustermap的master版本，然后扩散至全体OSD以及client。OSD使用clustermap进行数据的维护，而client使用clustermap进行数据的寻址。在集群中，各个monitor的功能总体上是一样的，其相互间的关系可以被简单理解为主从备份关系

46、。因此，在下面的讨论中不对各个monitor加以区分。略显出乎意料的是，monitor并不主动轮询各个OSD的当前状态。正相反，OSD需要向monitor上报状态信息。常见的上报有两种情况：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息后，monito门将更新clustermap信息并加以扩散。其细节将在下文中加以介绍。Clustermap的实际内容包括：Epoch，即版本号。Clustermap的epoch是一个单调递增序列。Epoch越大，则clustermap版本越新。因此，持有不同版本clustermap的OSD或client可以简单地通过比

47、较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的clustermap。当任意两方在通信时发现彼此epoch值不同时，将默认先将clustermap同步至高版本一方的状态，再进行后续操作。（2）各个OSD的网络地址。（3）各个OSD的状态。OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；Up且out：说明该OSD正常运行，但并未承载任何PG，

48、其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。（4）CRUSH算法配置参数。表明了Ceph集群的物理层级关系（clusterhierarchy），位置映射规则（placementrules）。根据clustermap的定义可以看出，其版本变化通常只会由（3）和（4）两项信息的变化触发。而这两者相比，（3）发生变化的概率更高一些。这可以通过下面对OSD工作状态变化过程的介绍加以反映。一个新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入clustermap，并设置为up且out状态，再将最新版本的clustermap发给这个新OSD。收到monitor发来的clustermap之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个