【分析】Ceph系统架构

        Ceph是基于RADOS无限扩展的分布式存储集群，提供同时包括对象、块设备、和文件的存储服务，拥有高可靠、易于管理、开源等特点。Ceph有着极易扩展的特性——上千数量的客户端可同时访问PB~EB数量级的数据。 

 

1.1   Ceph的发展历程

        在2004年，Sage Weil开发了一个名叫Ceph的开源项目，并于2006年，基于开源协议开源了Ceph。Weil 曾经是“Inktank Storage”公司的创始人。Inktank Storage一直专注于Ceph的研发，直到它被Redhat收购。

        2012年，Ceph的第一个稳定版本发布了。2014年10月，Ceph的开发团队发布了Ceph的第七个稳定版本Giant。为了让Ceph更加成熟与完美，这个项目还在继续开发中。

 

1.2   Ceph的设计目标

        Ceph的设计目标是采用商用硬件（CommodityHardware）来构建大规模的、具有高可用性、高可扩展性、高性能的分布式存储系统。

        商用硬件一般指标准的x86服务器，相对于专用硬件，性能和可靠性较差，但由于价格相对低廉，可以通过集群优势来发挥高性能，通过软件的设计解决高可用性和可扩展性。标准化的硬件可以极大地方便管理，且集群的灵活性可以应对多种应用场景。

        系统的高可用性指的是系统某个部件失效后，系统依然可以提供正常服务的能力。一般用设备部件和数据的冗余来提高可用性。Ceph通过数据多副本、纠删码来提供数据的冗余。

        高可扩展性是指系统可以灵活地应对集群的伸缩。一般指两个方面，一方面指集群的容量可以伸缩，集群可以任意地添加和删除存储节点和存储设备；另一方面指系统的性能随集群的增加而线性增加。

        大规模集群环境下，要求Ceph存储系统的规模可以扩展到成千上万个节点。当集群规模达到一定程度时，系统在数据恢复、数据迁移、节点监测等方面会产生一系列富有挑战性的问题。

 

1.3   Ceph的基本架构

        Ceph的整体架构由三个层次组成：最底层也是最核心的部分是RADOS对象存储系统。第二层是librados库层；最上层对应着Ceph不同形式的存储接口实现。

Ceph的整体架构大致如下：

        (1) 最底层基于RADOS（reliable，autonomous，distributed object store），它是一个可靠的、自组织的、可自动修复、自我管理的分布式对象存储系统。其内部包括ceph-osd后台服务进程和ceph-mon监控进程。

        (2) 中间层librados库用于本地或者远程通过网络访问RADOS对象存储系统。它支持多种语言，目前支持C/C++语言、Java、Python、Ruby和PHP语言的接口。

        (3) 最上层面向应用提供3种不同的存储接口：

                l  块存储接口，通过librbd库提供了块存储访问接口。它可以为虚拟机提供虚拟磁盘，或者通过内核映射为物理主机提供磁盘空间。

                l  对象存储接口，目前提供了两种类型的API，一种是和AWS的S3接口兼容的API，另一种是和OpenStack的Swift对象接口兼容的API。

                l  文件系统接口，目前提供两种接口，一种是标准的posix接口，另一种通过libcephfs库提供文件系统访问接口。文件系统的元数据服务器MDS用于提供元数据访问。数据直接通过librados库访问。

 

1.4   Ceph客户端接口

        Ceph的设计初衷是成为一个分布式文件系统，但随着云计算的大量应用，最终变成支持三种形式的存储：块存储、对象存储、文件系统，下面介绍它们之间的区别。

1.4.1  RBD

        RBD（rados block device）是通过librbd库对应用提供块存储，主要面向云平台的虚拟机提供虚拟磁盘。传统SAN就是块存储，通过SCSI或者FC接口给应用提供一个独立的LUN或者卷。RBD类似于传统的SAN存储，都提供数据块级别的访问。

        目前RBD提供了两个接口，一种是直接在用户态实现，通过QEMU Driver供KVM虚拟机使用。另一种是在操作系统内核态实现了一个内核模块。通过该模块可以把块设备映射给物理主机，由物理主机直接访问。

        块存储用作虚拟机的硬盘，其对I/O的要求和传统的物理硬盘类似。一个硬盘应该是能面向通用需求的，既能应付大文件读写，也能处理好小文件读写。也就是说，块存储既需要有较好的随机I/O，又要求有较好的顺序I/O，而且对延迟有比较严格的要求。

 

1.4.2  CephFS

        CephFS通过在RADOS基础之上增加了MDS（Metadata Server）来提供文件存储。它提供了libcephfs库和标准的POSIX文件接口。CephFS类似于传统的NAS存储，通过NFS或者CIFS协议提供文件系统或者文件目录服务。

        Ceph最初的设计为分布式文件系统，其通过动态子树的算法实现了多元数据服务器，但是由于实现复杂，目前还远远不能使用。目前可用于生产环境的是最新Jewel版本的CephFS为主从模式（Master-Slave）的元数据服务器。

 

1.4.3  RadosGW

        RadosGW基于librados提供了和Amazon S3接口以及OpenStack Swift接口兼容的对象存储接口。可将其简单地理解为提供基本文件（或者对象）的上传和下载的需求，它有两个特点：

        l  提供RESTful Web API接口。

        l  它采用扁平的数据组织形式。

 

1.4.3.1     RESTful的存储接口

        其接口值提供了简单的GET、PUT、DEL等其他接口，对应对象文件的上传、下载、删除、查询等操作。可以看出，对象存储的I/O接口相对比较简单，其I/O访问模型都是顺序I/O访问。

1.4.3.2     扁平的数据组织形式

        NAS存储提供给应用的是一个文件系统或者是一个文件夹，其实质就是一个层级化的树状存储组织模式，其嵌套层级和规模在理论上都不受限制。

        这种树状的目录结构为早期本地存储系统设计的信息组织形式，比较直观，容易理解。但是随着存储系统规模的不断扩大，特别是到了云存储时代，其难以大规模扩展的缺点就暴露了出来。相比于NAS存储，对象存储放弃了目录树结构，采用了扁平化组织形式（一般为三级组织结构），这有利于实现近乎无限的容量扩展。它使用业界标准互联网协议，更加符合面向云服务的存储、归档和备份需求。

 

1.5   RADOS

        RADOS是Ceph存储系统的基石，是一个可扩展的、稳定的、自我管理的、自我修复的对象存储系统，是Ceph存储系统的核心。

        RADOS完成了一个存储系统的核心功能，包括：Monitor模块为整个存储集群提供全局的配置和系统信息；通过CRUSH算法实现对象的寻址过程；完成对象的读写以及其他数据功能；提供了数据均衡功能；通过Peering过程完成一个PG内存达成数据一致性的过程；提供数据自动恢复的功能；提供克隆和快照功能；实现了对象分层存储的功能；实现了数据一致性检查工具Scrub。下面分别对上述基本功能做简要的介绍。

 

1.5.1  Monitor

        Monitor是一个独立部署的daemon进程。通过组成Monitor集群来保证自己的高可用。Monitor集群通过Paxos算法实现了自己数据的一致性。它提供了整个存储系统的节点信息等全局的配置信息。

        Cluster Map保存了系统的全局信息，主要包括：

        (1) Monitor Map

                l  包括集群的fsid

                l  所有Monitor的地址和端口

                l  current epoch

        (2) OSD Map：所有OSD的列表，和OSD的状态等。

        (3) MDS Map：所有的MDS的列表和状态。

 

1.5.2  对象存储

        这里所说的对象是指RADOS对象，要和RadosGW的S3或者Swift接口的对象存储区分开来。对象是数据存储的基本单元，一般默认4MB大小。如下图就是一个对象的示意图。

        一个对象由三个部分组成：

对象标志（ID）：唯一标识一个对象。

对象的数据：其在本地文件系统中对应一个文件，对象的数据就保存在文件中。

对象的元数据：以Key-Value（键值对）的形式，可以保存在文件对应的扩展属性中。由于本地文件系统的扩展属性能保存的数据量有限制，RADOS增加了另一种方式：以Leveldb等的本地KV存储系统来保存对象的元数据。

 

1.5.3  pool和PG的概念

        pool是一个抽象的存储池。它规定了数据冗余的类型以及对应的副本分布策略。目前实现了两种pool类型：replicated类型和Erasure Code类型。一个pool由多个PG构成。

        PG（placement group）从名字可理解为一个放置策略组，它是对象的集合，该集合里的所有对象都具有相同的放置策略：对象的副本都分布在相同的OSD列表上。一个对象只能属于一个PG，一个PG对应于放置在其上的OSD列表。一个OSD上可以分布多个PG。

        PG1和PG2都属于同一个pool，所以都是副本类型，并且都是两副本

        PG1和PG2里都包含许多对象，PG1上的所有对象，主从副本分布在OSD1和OSD2上，PG2上的所有对象的主从副本分布在OSD2和OSD3上。

        一个对象只能属于一个PG，一个PG包含多个对象。

        一个PG的副本分布在对应的OSD列表中。在一个OSD上可以分布多个PG。示例中PG1和PG2的从副本都分布在OSD2上。

 

1.5.4  对象寻址过程

        对象寻址过程指的是查找对象在集群中分布的位置信息，过程分为两步：

        1）对象到PG的映射。这个过程是静态hash映射（加入pg split后实际变成了动态hash映射方式），通过对object_id，计算出hash值，用该pool的PG的总数量pg_num对hash值取模，就可以获得该对象所在的PG的id号：

                pg_id = hash( object_id ) % pg_num 

        2）PG到OSD列表映射。这是指PG上对象的副本如何分布在OSD上。它使用Ceph自己创新的CRUSH算法来实现，本质上是一个伪随机分布算法。

如图所示的对象寻址过程：

        1）通过hash取模后计算，前三个对象分布在PG1上，后两个对象分布在PG2上。

        2）PG1通过CRUSH算法，计算出PG1分布在OSD1、OSD3上；PG2通过CRUSH算法分布在OSD2和OSD4上。

 

1.5.5  数据读写过程

        Ceph的数据写操作如图1-8所示，其过程如下：

        1）Client向该PG所在的主OSD发送写请求。

        2）主OSD接收到写请求后，同时向两个从OSD发送写副本的请求，并同时写入主OSD的本地存储中。

        3）主OSD接收到两个从OSD发送写成功的ACK应答，同时确认自己写成功，就向客户端返回写成功的ACK应答。

        在写操作的过程中，主OSD必须等待所有的从OSD返回正确应答，才能向客户端返回写操作成功的应答。

        由于读操作比较简单，这里就不介绍了。

 

1.5.6  数据均衡

        当在集群中新添加一个OSD存储设备时，整个集群会发生数据的迁移，使得数据分布达到均衡。Ceph数据迁移的基本单位是PG，即数据迁移是将PG中的所有对象作为一个整体来迁移。

        迁移触发的流程为：当新加入一个OSD时，会改变系统的CRUSH Map，从而引起对象寻址过程中的第二步，PG到OSD列表的映射发生了变化，从而引发数据的迁移。
举例来说明数据迁移过程，表1-1是数据迁移前的PG分布，表1-2是数据迁移后的PG分布。

        当前系统有3个OSD，分布为OSD1、OSD2、OSD3；系统有4个PG，分布为PGa、PGb、PGc、PGd；PG设置为三副本：PGa1、PGa2、PGa3分别为PGa的三个副本。PG的所有分布如表1-1所示，每一行代表PG分布的OSD列表。

表1-1　数据迁移前的PG分布

        当添加一个新的OSD4时，CRUSH Map变化导致通过CRUSH算法来计算PG到OSD的分布发生了变化。如表1-2所示：PGa的映射到了列表[OSD4，OSD2，OSD3]上，导致PGa1从OSD1上迁移到了OSD4上。同理，PGb2从OSD3上迁移到OSD4，PGc3从OSD2上迁移到OSD4上，最终数据达到了基本平衡。

表1-2　数据迁移后的PG分布

1.5.7  Peering

        当OSD启动，或者某个OSD失效时，该OSD上的主PG会发起一个Peering的过程。Ceph的Peering过程是指一个PG内的所有副本通过PG日志来达成数据一致的过程。当Peering完成之后，该PG就可以对外提供读写服务了。此时PG的某些对象可能处于数据不一致的状态，其被标记出来，需要恢复。在写操作的过程中，遇到处于不一致的数据对象需要恢复的话，则需要等待，系统优先恢复该对象后，才能继续完成写操作。

1.5.8  Recovery和Backfill

        Ceph的Recovery过程是根据在Peering的过程中产生的、依据PG日志推算出的不一致对象列表来修复其他副本上的数据。

        Recovery过程的依据是根据PG日志来推测出不一致的对象加以修复。当某个OSD长时间失效后重新加入集群，它已经无法根据PG日志来修复，就需要执行Backfill（回填）过程。Backfill过程是通过逐一对比两个PG的对象列表来修复。当新加入一个OSD产生了数据迁移，也需要通过Backfill过程来完成。

 

1.5.9  纠删码

        纠删码（Erasure Code）的概念早在20世纪60年代就提出来了，最近几年被广泛应用在存储领域。它的原理比较简单：将写入的数据分成N份原始数据块，通过这N份原始数据块计算出M份效验数据块，N+M份数据块可以分别保存在不同的设备或者节点中。可以允许最多M个数据块失效，通过N+M份中的任意N份数据，就还原出其他数据块。

        目前Ceph对纠删码（EC）的支持还比较有限。RBD目前不能直接支持纠删码（EC）模式。其或者应用在对象存储radosgw中，或者作为Cache Tier的二层存储。其中的原因和具体实现都将在后面的章节详细介绍。

 

1.5.10   快照和克隆

        快照（snapshot）就是一个存储设备在某一时刻的全部只读镜像。克隆（clone）是在某一时刻的全部可写镜像。快照和克隆的区别在于快照只能读，而克隆可写。

        RADOS对象存储系统本身支持Copy-on-Write方式的快照机制。基于这个机制，Ceph可以实现两种类型的快照，一种是pool级别的快照，给整个pool中的所有对象统一做快照操作。另一种就是用户自己定义的快照实现，这需要客户端配合实现一些快照机制。RBD的快照实现就属于后者。

        RBD的克隆实现是在基于RBD的快照基础上，在客户端librbd上实现了Copy-on-Write（cow）克隆机制。

 

1.5.11   Cache Tier

        RADOS实现了以pool为基础的自动分层存储机制。它在第一层可以设置cache pool，其为高速存储设备（例如SSD设备）。第二层为data pool，使用大容量低速存储设备（如HDD设备）可以使用EC模式来降低存储空间。通过Cache Tier，可以提高关键数据或者热点数据的性能，同时降低存储开销。

        Cache Tier的结构如图所示：

说明如下：

        l  Ceph Client对于Cache层是透明的。

        l  类Objecter负责请求是发给CacheTier层，还是发给Storage Tier层。

        l  Cache Tier层为高速I/O层，保存热点数据，或称为活跃的数据。

        l  Storage Tier层为慢速层，保存非活跃的数据。

        l  在Cache Tier层和Storage Tier层之间，数据根据活跃度自动地迁移。

 

1.5.12   Scrub

        Scrub机制用于系统检查数据的一致性。它通过在后台定期（默认每天一次）扫描，比较一个PG内的对象分别在其他OSD上的各个副本的元数据和数据来检查是否一致。根据扫描的内容分为两种，第一种是只比较对象各个副本的元数据，它代价比较小，扫描比较高效，对系统影响比较小。另一种扫描称为deep scrub，它需要进一步比较副本的数据内容检查数据是否一致。

 

摘自：《Ceph源码分析》