架构解密从分布式到微服务：Linux分布式存储系统—Ceph

创新的Linux分布式存储系统——Ceph

Linux中当前备受关注的开源分布式存储系统,除了我们之前提到的GlusterFS,当属Ceph。我们知道，GlusterFS最早被研究于2003年（第Ⅰ次公开的时间是2007年)，那时的开源软件世界还没有能够承载PB级别的数据并且由成千上万的存储节点组成的大规模分布式存储系统，这方面的学术研究是一个热点领域,也是Ceph的作者Sage Weil攻读博士期间的研究课题。Ceph项目发起于2004年，Sage随后在2006年的OSDI学术会议上发表了介绍Ceph的论文，并在该论文的末尾提供了Ceph软件的下载链接，由此，Ceph开始广为人知。随着Ceph的热度不断增加，从2010年开始，来自Yahoo、Suse、Canonical、Intel等公司的一批开发者进入Ceph社区协作开发。Sage于2011年创立了Inktank 公司，主导了Ceph的开发和社区维护。2012年，Ceph被正式纳入OpenStack体系，成为Cinder底层的存储实现，并随着OpenStack 的兴起而被广泛接受。2014年年中，Ceph的实际控制者Inktank 被RedHat 收购，成为RedHat旗下第2个重要的分布式存储产品(继续开源),如今Ceph已经发展成为最广泛的开源软件定义存储项目。

下面说说Ceph的设计思想。在Ceph的设计中有如下两个亮点。

• 首先，充分发挥存储设备（X86 Linux）自身的计算能力，而不仅仅是将其当作存储设备。这样，Ceph就可以通过运行在每个存储节点上的相关辅助进程来提升系统的高可用、高性能与自动化水平。比如Ceph 的自动化能力就包括数据的自动副本、自动迁移平衡、自动错误侦测及自动恢复等。对于一个大规模的分布式系统来说，自动化运维是至关重要的一个能力，因为自动化运维不但保证了系统的高可靠性与高可用性，还保证了在系统规模扩大之后，其运维难度与运维工作量仍能保持在一个相对较低的水平。
• 其次，与同时代的GlusterFS一样，Ceph采用了完全去中心化的设计思路。之前的分布式存储系统因为普遍采用中心化(元数据服务器）设计，产生了各种问题，例如增加了数据访问的延时、导致系统规模难以扩展及难以应对的单点故障。Ceph因为采用了完全去中心化的设计从而避免了上述种种问题，并真正实现了系统规模线性扩展的能力，使得系统可以很容易达到成百上千个节点的集群规模。Yahoo Flick自2013年开始逐渐试用Ceph对象存储并替换原有的商业存储,目前大约由10个机房构成,每个机房为1~～2PB，存储了大约2500亿个对象。

Ceph 整体提供了块存储RBD、分布式文件存储CephFS(类似于GlusterFS)及分布式对象存储RADOSGW三大存储功能,可以说是目前为数不多的集各种存储能力于一身的开源存储中间件。从如下所示的整体架构图可以看出，实际上RBD、CephFS 与RADOSGW只不过是系统顶层的一个“接口”，而Ceph真正的核心在于底层的RADOS(Reliable Autonomic DistributedObject Storage)存储子系统，让 Ceph成名的对象存储RADOSGW不过是基于RADOS实现的一个兼容Swift (OpenStack）和S3（亚马逊对象存储服务）的REST 网关。

下面分析一下RADOS的架构设计特点，如下所示是RADOS的组件图。

RADOS主要由一组OSD (Object Storage Device）组成存储集群，从上图可以看出，一个OSD其实就是一个运行了Ceph OSD守护进程的Linux X86服务器（挂接很多硬盘的那种)，一组(几十到上千个）OSD节点组成了RADOS的存储集群。考虑到分布式情况下集群中的某些OSD节点可能会宕机或者不可用，所以如何设计一个好的算法，能够将海量存储数据映射到大量的存储节点上，同时解决集群故障问题所带来的影响，就成为RADOS需要解决的一个关键技术点。为此，Ceph 发明了特殊的CRUSH (Controlled Replication Under Scalable Hash)算法，可以把海量数据（Object）随机分布到上千个存储设备上，并保证分布均匀、负载均衡及新旧数据混合在一起，在集群存储节点的扩缩容情况下仅仅发生少量的数据迁移。所以，CRUSH算法是Ceph的核心内容之一。与其他算法相比，CRUSH算法具有以下几个特性。

• CRUSH具有可配置的特性，一致性哈希算法并不具备这个特性，管理员可以通过配置参数来决定OSD的映射策略。
• CRUSH具有特殊的稳定性。当在系统中加入新的OSD导致系统规模增大时，大部分PG与OSD之间的映射关系不会改变，只有少部分PG的映射关系会改变并引发数据迁移。
• 任何组件都可以独立计算出每个 Object所在的位置（去中心化)。
• 只需要很少的元数据就能计算，这些元数据仅仅在OSD 的数量改变时才会改变。

CRUSH算法里一个重要的概念就是PG(Placement Group)，PG是Ceph中非常重要的概念，可以将它看作一致性哈希中的虚拟节点，在通常情况下，一个PG 会对应3个OSD以保证数据的高可靠性存储要求。如下图所示，PG实线所指的OSD 为Primary OSD，虚线为两个副本OSD(Replicated OSD)，Primary PG负责该PG的对象写操作,读操作可以通过Replicated PG获得。通过引入 PG，CRUSH算法采用了二次映射的方式，实现了任意Object到OSD 的定位能力。其基本思想是每个存入RADOS的数据单元（Object）都先通过Hash算法确定归属于哪个PG，再从PG中找到对应的OSD设备。

CRUSH 算法在 Object存储过程中的作用如下。

• 确定PG与OSD的映射关系。
• 确定将一个 Object放入哪个PG中。

下面以CephFS为例，看看RADOS是如何实现分布式文件存储功能的，下图显示了关键的过程。

首先,每个文件(File)都被按照一个特定的尺寸(默认是4MB)切分成若干个对象(Object),每一个Object 都有一个Object id (oid)，这种切分相当于RAID中的条带化过程。这样做的好处是:让大小不同的File变成最大size一致并可以被RADOS高效管理的标准化 Object;可以实现大文件的并行IO读写能力。

其次，通过第1层哈希算法，得到某个Object对应PG的ID(pgid)，有了pgid之后，Client就得到PG对应的OSD列表（OSD1、OSD2、OSD3)，列表中的第1个OSD是 Primary OSD,剩下的都是副本OSD(比如在三副本模式下,两个副本分别为Secondary OSD和Tertiary OSD),随后Client 会向 Primary OSD 发起I/O请求。如下所示给出了某个Object对象写入Primary OSD的具体流程图。

Primary OSD在收到写请求后，分别向Secondary OSD和Tertiary OSD发起写入操作(见步骤2、3)，Secondary OSD和Tertiary OSD在各自完成写入操作后，将分别向Primary OSD 发送确认信息（步骤4、5)。Primary OSD在确认其他两个OSD的写入完成后，自己也完成数据写入，并向Client确认Object写入完成(步骤6)。在整个过程中，Client 只向 Primary OSD发起请求，而幕后的操作对于Client来说是透明的。RADOS这种高可用、多副本特性的代价就是文件写入时性能降低，但也可以通过大文件切分后的条带化并行写入能力及优化多副本的写入逻辑来补偿。

那么问题来了，RADOS 中的OSD节点信息、PG 信息、PG与OSD 映射的关系等信息被存储在哪里并且是如何被Client得到的呢?这就涉及Ceph Monitor组件。Monitor的功能与ZooKeeper类似，作为RADOS集群的“大脑（元数据中心)”，Monitor负责维持RADOS集群的元数据、集群拓扑信息(Ceph Cluster Map）及集群状态信息并提供接口供Client调用。可以说，没有Monitor，Ceph就将无法执行一条简单的命令。有了Ceph Monitor，Ceph便能够容忍集群中某些OSD节点所发生的网络中断、掉电、服务器宕机、硬盘故障等意外问题，并可以进行自动修复，以保证数据的可靠性和系统可用性。

如下所示是Ceph Monitor的架构图。从这张图可以看到，Ceph Monitor维护了6个Map，分别是 Monitor Map、OSD Map、PG Map、Log Map、Auth Map及 MDS Map。其中 OSD Map和PG Map是最重要的两个 Map。OSD Map是Ceph集群中所有OSD的信息，所有OSD节点的改变如 OSD守护进程退出、新的OSD节点加入或者OSD节点权重发生变化等都会被反映到这张 Map上，不但OSD Map会被 Monitor 掌握，OSD节点和 Client也会从Monitor那里得到这张表。考虑到OSD节点的数量可能非常多，因此Ceph Monitor并不主动与每个OSD节点通信，而是由OSD主动汇报信息。此外，在OSD Map发生变化后，Monitor并不会发送OSD Map给所有Client，而是发送给那些需要了解变化的Client，比如若一个新的OSD 加入集群后导致某些PG发生迁移(PG对应的OSD Set需要改变)，那么这些PG的OSD都会得到通知。Ceph这种精心设计的消息隔离广播机制可以说与网络中广播域的设计具有一定的相似性，都是为了尽可能减少无效的通信，以适应更大的集群规模。接下来说说PG Map。Monitor维护了每个Pool中所有PG 的信息，其中一个OSD 的角色会是Primary，其他OSD 的角色会是 Replicated。需要注意的是,每个OSD节点都会成为某些PG的Primary OSD,并成为其他PG的Replicated OSD,这个复杂的关系网就是PG Map。

我们看看Ceph Monitor实现的自动修复能力:当某个PG对应的Primary OSD被标记为down时，某个Replica就会成为新的Primary，并处理所有读写Object的请求，此时该PG的当前有效副本数是N-1，所以PG的状态被变更为Active+Degraded，过了M秒之后，如果还是无法连接原来的 Primary OSD，则此OSD被标记为Out，Ceph 会重新计算PG到OSD Set的映射，以保证此PG的有效副本数始终是N。

Ceph Monitor还用到了Paxos 协议，原因在于Ceph Monitor本身也是1个(3节点)集群，Paxos协议在这里有如下两个作用。

• 首先，选择集群的Leader ( Ceph Monitor)。
• 其次，保证Ceph Monitor集群的数据一致性,只有Ceph Monitor集群节点投票通过时，Ceph Monitor维护的集群状态数据才能被写入后端的Key-Value数据库里并生效。