Ceph的架构

最新推荐文章于 2025-10-11 10:17:43 发布

转载最新推荐文章于 2025-10-11 10:17:43 发布 · 374 阅读

云计算专栏收录该内容

70 篇文章

订阅专栏

本文深入探讨了Ceph存储系统，介绍了其作为统一存储解决方案的特点，包括高扩展性、高可靠性和高性能。文章详细分析了Ceph的架构，包括RADOS、OSD、Monitor、MDS和RADOS Gateway组件，以及数据映射、强一致性和容错性机制。并通过实测对比了Ceph RBD与RAID10的性能。

http://way4ever.com/?p=425

Ceph的架构

朱荣泽September 9, 20134

Contents [hide]

介绍

云硬盘是IaaS云平台的重要组成部分，云硬盘给虚拟机提供了持久的块存储设备。目前的AWS 的EBS(Elastic Block store)给Amazon的EC2实例提供了高可用高可靠的块级存储卷，EBS适合于一些需要访问块设备的应用，比如数据库、文件系统等。在OpenStack中，可以使用Ceph、Sheepdog、GlusterFS作为云硬盘的开源解决方案，下面我们来了解Ceph的架构。

Ceph是统一存储系统，支持三种接口。

Object：有原生的API，而且也兼容Swift和S3的API
Block：支持精简配置、快照、克隆
File：Posix接口，支持快照

Ceph也是分布式存储系统，它的特点是：

高扩展性：使用普通x86服务器，支持10~1000台服务器，支持TB到PB级的扩展。
高可靠性：没有单点故障，多数据副本，自动管理，自动修复。
高性能：数据分布均衡，并行化度高。对于objects storage和block storage,不需要元数据服务器。

背景

目前Inktank公司掌控Ceph的开发，但Ceph是开源的，遵循LGPL协议。Inktank还积极整合Ceph和其他云计算和大数据平台，目前Ceph支持OpenStack、CloudStack、OpenNebula、Hadoop等。

当前Ceph的最新稳定版本0.67(Dumpling),它的objects storage和block storage已经足够稳定，而且Ceph社区还在继续开发新功能，包括跨机房部署和容灾、支持Erasure encoding等。Ceph具有完善的社区设施和发布流程(每三个月发布一个稳定版本) http://way4ever.com/blog/ceph-distributed-block-storage/#2_Ceph 。

目前Ceph有很多用户案列，这是2013.03月Inktank公司在邮件列表中做的调查，共收到了81份有效反馈 http://ceph.com/community/results-from-the-ceph-census/。从调查中可以看到有26%的用户在生产环境中使用Ceph，有37%的用户在私有云中使用Ceph，还有有16%的用户在公有云中使用Ceph。

目前Ceph最大的用户案例是Dreamhost的Object Service，目前总容量是3PB，可靠性达到99.99999%，数据存放采用三副本，它的价格比S3还便宜。下图中，左边是Inktank的合作伙伴，右边是Inktank的用户。

架构

组件

Ceph的底层是RADOS，它的意思是“A reliable, autonomous, distributed object storage”。 RADOS由两个组件组成：

OSD： Object Storage Device，提供存储资源。
Monitor：维护整个Ceph集群的全局状态。

RADOS具有很强的扩展性和可编程性，Ceph基于RADOS开发了 Object Storage、Block Storage、FileSystem。Ceph另外两个组件是：

MDS：用于保存CephFS的元数据。
RADOS Gateway：对外提供REST接口，兼容S3和Swift的API。

映射

Ceph的命名空间是 (Pool, Object)，每个Object都会映射到一组OSD中(由这组OSD保存这个Object)：

(Pool, Object) → (Pool, PG) → OSD set → Disk

Ceph中Pools的属性有：

Object的副本数
Placement Groups的数量
所使用的CRUSH Ruleset

在Ceph中，Object先映射到PG(Placement Group)，再由PG映射到OSD set。每个Pool有多个PG，每个Object通过计算hash值并取模得到它所对应的PG。PG再映射到一组OSD（OSD的个数由Pool 的副本数决定），第一个OSD是Primary，剩下的都是Replicas。

数据映射(Data Placement)的方式决定了存储系统的性能和扩展性。(Pool, PG) → OSD set 的映射由四个因素决定：

CRUSH算法：一种伪随机算法。
OSD MAP：包含当前所有Pool的状态和所有OSD的状态。
CRUSH MAP：包含当前磁盘、服务器、机架的层级结构。
CRUSH Rules：数据映射的策略。这些策略可以灵活的设置object存放的区域。比如可以指定 pool1中所有objecst放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。 pool2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。

Client从Monitors中得到CRUSH MAP、OSD MAP、CRUSH Ruleset，然后使用CRUSH算法计算出Object所在的OSD set。所以Ceph不需要Name服务器，Client直接和OSD进行通信。伪代码如下所示：

locator = object_name
  obj_hash = hash(locator)
  pg = obj_hash % num_pg
  osds_for_pg = crush(pg)  # returns a list of osds
  primary = osds_for_pg[0]
  replicas = osds_for_pg[1:]

这种数据映射的优点是：

把Object分成组，这降低了需要追踪和处理metadata的数量(在全局的层面上，我们不需要追踪和处理每个object的metadata和placement，只需要管理PG的metadata就可以了。PG的数量级远远低于object的数量级)。
增加PG的数量可以均衡每个OSD的负载，提高并行度。
分隔故障域，提高数据的可靠性。

强一致性

Ceph的读写操作采用Primary-Replica模型，Client只向Object所对应OSD set的Primary发起读写请求，这保证了数据的强一致性。
由于每个Object都只有一个Primary OSD，因此对Object的更新都是顺序的，不存在同步问题。
当Primary收到Object的写请求时，它负责把数据发送给其他Replicas，只要这个数据被保存在所有的OSD上时，Primary才应答Object的写请求，这保证了副本的一致性。

容错性

在分布式系统中，常见的故障有网络中断、掉电、服务器宕机、硬盘故障等，Ceph能够容忍这些故障，并进行自动修复，保证数据的可靠性和系统可用性。

Monitors是Ceph管家，维护着Ceph的全局状态。Monitors的功能和zookeeper类似，它们使用Quorum和Paxos算法去建立全局状态的共识。
OSDs可以进行自动修复，而且是并行修复。

故障检测：

OSD之间有心跳检测，当OSD A检测到OSD B没有回应时，会报告给Monitors说OSD B无法连接，则Monitors给OSD B标记为down状态，并更新OSD Map。当过了M秒之后还是无法连接到OSD B，则Monitors给OSD B标记为out状态(表明OSD B不能工作），并更新OSD Map。

备注：可以在Ceph中配置M的值。

故障恢复：

当某个PG对应的OSD set中有一个OSD被标记为down时(假如是Primary被标记为down，则某个Replica会成为新的Primary，并处理所有读写 object请求)，则该PG处于active+degraded状态，也就是当前PG有效的副本数是N-1。
过了M秒之后，假如还是无法连接该OSD，则它被标记为out，Ceph会重新计算PG到OSD set的映射(当有新的OSD加入到集群时，也会重新计算所有PG到OSD set的映射)，以此保证PG的有效副本数是N。
新OSD set的Primary先从旧的OSD set中收集PG log，得到一份Authoritative History(完整的、全序的操作序列)，并让其他Replicas同意这份Authoritative History(也就是其他Replicas对PG的所有objects的状态达成一致)，这个过程叫做Peering。
当Peering过程完成之后，PG进入active+recoverying状态，Primary会迁移和同步那些降级的objects到所有的replicas上，保证这些objects 的副本数为N。