以下为《Ceph技术架构详解》的无排版文字预览，完整格式请下载

下载前请仔细阅读文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。

Ceph技术架构详解

Ceph项目始于2004年，创始人是Sage Weil，使用C++开发，作为开源项目，支持LGPL协议。Ceph最初由inktank公司主导开发，RedHat在2014年收购了inktank，并推出了Ceph商业版ICE

Ceph是为优秀的性能、可靠性和可扩展性而设计的统一的、分布式的存储系统。同时支持块、文件、对象接口（同一个节点），支持PB级别扩展，可部署到上千台通用服务器。Ceph并不能实现几种接口数据的互通，只有对象接口下S3和Swift写入的数据是相互可读取的。

Ceph已经成为Openstack呼声最高的开源存储之一，块存储和对象存储发展较成熟，文件存储还不能用于生产环境

Ceph的主要应用场景是openstack和网盘等web类应用

截至2013年3月初，Ceph在生产环境下部署的最大规模系统为Dreamhost公司的对象存储业务集群，其管理的物理存储容量为3PB

Ceph和OpenStcak的集成能力，使得Ceph是OpenStack生态系统中呼声最高的开源存储解决方案。包括HP、Dell、Intel等为代表的企业IT领导厂商和Mirantis、eNovance、UnitedStack为代表的OpenStack社区新兴厂XX将Ceph作为重要的开源存储解决方案。

Ceph最主要被互***用来和OpenStack配合搭建云平台，大家选择Ceph的主要原因包括：低成本、SDS、扩展性强、统一存储、和OpenStack的高效结合

分布式存储资源池：

携程基于Ceph搭建PB级云对象存储

浪潮AS13000系列存储也是基于Ceph开发

思科UCS流媒体服务存储也是基于Ceph对象存储

雅虎基于Ceph搭建云对象存储

联通研究院、CERN实验室、United Stack等也基于Ceph搭建了开发环境。

SanDisk InfiniFlash System IF500采用Ceph技术搭建（ IF100硬件和InfiniFlash OS Ceph横向扩展软件）。

私有云融合资源池

乐视基于OpenStack 和Ceph搭建乐视云平台；

宝德云基于OpenStack、Ceph(RBD块存储和CephFS) 和Docker构建。

Redhat在2016.6最新发布了Ceph storage 2，基于Ceph10.2（Jewel）版本，增强对于对象存储工作负载的支持，同时提高了易用性。主要特性包括：

新的全球对象存储集群：提供了单个命名空间，并在多个地区运行的集群之间提供了数据同步。

通过与验证系统集成提供了更强的安全性，包括Active Directory、LDAP和OpenStack Identity (Keystone) v3。

增强的Amazon S3和OpenStack对象存储 (Swift) 兼容性，包括对AWS v4客户端签名、对象版本管理、批量删除等的支持。

整合了红帽存储控制台2，提供了重新设计并且经过精简的用户界面GUI，缩短部署时间并能够主动监控和管理健康状况、性能及容量利用率。

Sandisk已经与Red Hat Ceph Storage 2部署环境开展了全面的IOPS性能测试。Ceph Storage对接InfiniFlash System IF150的最新测试表明性能超过100万次随机读取IOPS。

Ceph系统架构

RADOS：基础存储系统（Reliable Autonomic Distributed Object Store）即可靠的，自动化的，分布式存储。这个Ceph系统的基石，Ceph系统所有数据都是通过经过RADOS这层来保存的。物理上，RADOS由大量的存储设备节点组层，每个节点拥有自己的硬件资源（CPU、内存、硬盘、网络）。

LIBRADOS：这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是整个Ceph）进行应用开发。特别要注意的是，RADOS是一个对象存储系统，因此，librados实现的API也只是针对对象存储功能的。RADOS采用C++开发，所提供的原生librados API包括C和C++两种。物理上，librados和基于其上开发的应用位于同一台机器，因而也被称为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

RADOSGW：RADOSGW即RADO Gateway，是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高，但功能则不如librados强大。

RBD：RBD即Reliable Block Device。提供了标准Block接口，常用于虚拟化的场景下为虚拟机分配volume。目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。

Ceph FS：Ceph FS是兼容Posix分分布式系统。

Ceph逻辑组件

在使用RADOS系统时，大量的客户端程序通过与OSD或者monitor的交互获取cluster map，然后直接在本地进行计算，得出对象的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。可见，在此过程中，只要保证cluster map不频繁更新，则客户端显然可以不依赖于任何元数据服务器，不进行任何查表操作，便完成数据访问流程。在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种：OSD出现故障，或者RADOS规模扩大。而正常应用场景下，这两种事件发生的频率显然远远低于客户端对数据进行访问的频率。

/

OSD依赖底层文件系统xattrs来记录对象状态和元数据,Xattr必须提供足够的容量大小，ext4仅4KB，xfs 64KB，而btrfs没有限制,Btrfs不够稳定,ext4 xattr太小，生产部署推荐xfs测试推荐btrfs

Client：部署在Linux服务器上，实现数据切片，通过Crush算法定位对象位置，并进行对象数据的读写

OSD：存储数据，处理数据复制，恢复，回填，重新调整，并向Monitor报告一些检测信息。单集群至少需要2个OSD，一般情况下一个OSD对应一块物理硬盘，部署btrfs、xfs或ext4的本地文件系统

Monitor：实现OSD集群的状态监控，维护OSD(守护进程)映射,分组(PG)映射，和CRUSH映射

Metadata Cluster：元数据集群，用于管理文件元数据，仅CephFS需要

数据存储逻辑架构

一个Cluster可逻辑上划分为多个Pool

一个 Pool 包含若干个逻辑 PG（ Placement Group ），同时可定义Pool内的副本数量

一个物理文件会被切分为多个Object

每个Object会被映射到一个PG，一个PG内可包含多个Object

一个 PG 映射到一组 OSD，其中第一个 OSD 是主（primary），其余的是从（ secondary ），承担相同PG的OSD间通过心跳来相互监控存活状态

许多 PG 可以映射到某个 OSD

引入PG的概念后，OSD只和PG相关，简化了OSD的数据存储；同时实现了object到OSD的动态映射，OSD的添加和故障不影响Object的映射

/

在Ceph的现有机制中，一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个OSD上大约承载数百个PG，每个PG内通常有3个OSD，因此，一段时间内，一个OSD大约需要进行数百至数千次OSD信息交换。

然而，如果没有PG的存在，则一个OSD需要和与其共同承载同一个object的其他OSD交换信息。由于每个OSD上承载的object很可能高达数百万个，因此，同样长度的一段时间内，一个OSD大约需要进行的OSD间信息交换将暴涨至数百万乃至数千万次。而这种状态维护成本显然过高。

数据寻址流程

三个映射过程，首先要将用户要操作的file，映射为RADOS能够处理的object。就是简单的按照object的size对file进行切分，相当于RAID中的条带化过程。接着把Object映射到PG，在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。

3步映射查找

File-> object 每个object获得唯一的oid

Object->PG hash(oid) & mask -> pgid

哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。基于这一机制，当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射

PG->OSD 将pgid代入其中，然后得到一组共n个OSD,n在生产环境推荐为3（副本）

/

1. File -> object映射

这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分，相当于RAID中的条带化过程。这种切分的好处有二：一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。

2. Object -> PG映射

在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。这个映射过程也很简单，如图中所示，其计算公式是：

hash(oid) & mask -> pgid

3. PG -> OSD映射

第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。如图所示，RADOS采用一个名为CRUSH的算法，将pgid代入其中，然后得到一组共n个OSD。这n个OSD即共同负责存储和维护一个PG中的所有object。前已述及，n的数值可以根据实际应用中对于可靠性的需求而配置，在生产环境下通常为3。

File?—— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。将用户操作的File切分为RADOS层面的Object，每个Object一般为2MB或4MB，大小可设置。

2. Ojbect?—— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。每个Object通过哈希算法映射到唯一的PG.

3. PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。每个PG通过CRUSH算法映射到实际存储单元OSD，PG和OSD间是多对多的映射关系.

4. OSD?—— 即object storage device，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。OSD在物理上可划分为多个故障域（机房、机架、服务器），可通过策略配置使PG的不同副本位于不同的故障域中

数据分布(Data Placement)方式

Cluster Map用来记录全局系统状态记数据结构，由Crush Map和OSD Map两部分组成。 Crush Map包含当前磁盘、服务器、机架的层级结构，OSD Map包含当前所有Pool的状态和所有OSD的状态。

Crush Rules就是数据映射的策略，决定了每个数据对象有多少个副本，这些副本如何存储。 Crush算法是一种伪随机算法，通过权重决定数据存放（如跨机房、机架感知等），通常采用基于容量的权重。Crush算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket(Uniform、List、Tree、Straw)，大多数情况下的都采用Straw。

/

Cluster Map用来记录全局系统状态记数据结构，由Crush Map和OSD Map两部分组成。 Crush Map包含当前磁盘、服务器、机架的层级结构，OSD Map包含当前所有Pool的状态和所有OSD的状态。

Crush Rules就是数据映射的策略，决定了每个数据对象有多少个副本，这些副本如何存储。 Crush算法是一种伪随机算法，通过权重决定数据存放（如跨机房、机架感知等），通常采用基于容量的权重。Crush算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket(Uniform、List、Tree、Straw)，大多数情况下的都采用Straw。

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

CRUSH算法：一种伪随机算法。

Cluster MAP：RADOS的核心数据结构，描述了可用存储资源和层级结构(例如有多少个机架，每个机架上有多少个服务器，每个服务器上有多少个磁盘)。

CRUSH Rules：数据映射的策略。决定了每个数据对象有多少个副本，这些副本存储的限制条件(例如3个副本放在不同的机架中)。

CRUSH MAP：包含当前磁盘、服务器、机架的层级结构

OSD MAP：包含当前所有Pool的状态和所有OSD的状态

OSD/MON状态维护

Ceph集群中，Monitor负责Cluster Map的维护和更新，OSD和Client中也会保存Cluster Map。Monitor和所有OSD间，同一PG的不同OSD间都有心跳连接，当一个OSD检测到同一PG的其他OSD故障，会主动上报给Monitor，触发Cluster Map的更新

cluster map信息是以增量形式扩散的，一次通信的双方发现Cluster Map版本不一致，低版本的一方会进行增量更新； cluster map信息是以异步且lazy的形式扩散的， monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是通过OSD和Monitor、OSD之间、OSD和Client间的通信逐步同步的。

OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）

—— Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；

—— Up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；

—— Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；

—— Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。

OSD和Monitor通信的一些基本概括：

1，OSD检查其他OSD的心跳信息，默认间隔6秒

2，超过20秒未收到心跳信心，则认为该OSD状态为down，报告monitor

3，OSD向Monitor报告3次某OSD down，monitor才认为该OSD down

4，只要有一个OSD报告某OSD down，即认为该报告有效

5，OSD感知不到某一其他peering OSD时，每隔30秒向monitor请求cluster map

6，无论是否有事件发生,OSD每隔120s会向Monitor report一次

7，Monitor未收到OSD的report超过一定时间，认为该OSD down

8，以上所有时间和次数均可通过配置设定

数据读写操作流程

每个Object都只有一个Primary OSD ，Client只向Object所对应Primary OSD 发起读写请求，这保证了数据的强一致性。当Primary收到Object的写请求时，它负责把数据发送给其它Replicas，只有数据被保存在所有的OSD上时Primary才答应Object的写请求，这保证副本一致性。

OSD使用的btrfs、xfs、ext4都是日志型文件系统，日志写入成功即可给客户端返回，无需等待数据写入成功。

/

详细的数据写入流程：

1，client把写请求发到Primary OSD上，Primary OSD上将写请求序列化到一个事务中（在内存里），然后构造一条pglog记录，也序列化到这个事务中，然后将这个事务以directIO的方式异步写入journal，同时Primary OSD把写请求和pglog（pglog_entry是由primary生成的）发送到Replicas上；

2，在Primary OSD将事务写到journal上后，会通过一系列的线程和回调处理，然后将这个事务里的数据写入filesystem（只是写到文件系统的缓存里，会有线程定期刷数据），这个事务里的pglog记录（也包括pginfo的last_complete和last_update）会写到leveldb，还有一些扩展属性相关的也在这个事务里，在遍历这个事务时也会写到leveldb；

3，在Replicas上，也是进行类似于Primary的动作，先写journal，写成功会给Primary发送一个committed ack，然后将这个事务里的数据写到filesystem，pglog与pginfo写到leveldb里，写完后会给Primary发送另外一个applied ack；

4，Primary在自己完成journal的写入时，以及在收到Replica的committed ack时都会检查是否多个副本都写入journal成功了，如果是则向client端发送ack通知写完成；Primary在自己完成事务写到文件系统和leveldb后，以及在收到replica的applied ack时都会检查是否多个 内容过长，仅展示头部和尾部部分文字预览，全文请查看图片预览。 ctive monitor一个短期租约，允许他们散播map给OSDs和client

如果租约长期没有更新，认为leader失效，需要重新选择一个新的leader

OSD/Monitor状态维护

OSD检查其他OSD的心跳信息，默认间隔6秒

该间隔可通过osd heartbeat interval设置

超过20秒未收到心跳信心，则认为该OSD状态为down，报告monitor

该最大容忍间隔可以通过osd heartbeat grace设置

OSD向Monitor报告3次某OSD down，monitor才认为该OSD down

该次数可通过mon osd min down reports设置

只要有一个OSD报告某OSD down，即认为该报告有效

该最小OSD数目可通过mon osd min down reporters设置

OSD感知不到某一其他peering OSD时，每隔30秒向monitor请求cluster map

该间隔可通过osd mon heartbeat interval设置

Monitor未收到OSD的report超过一定时间，认为该OSD down

[文章尾部最后500字内容到此结束,中间部分内容请查看底下的图片预览]请点击下方选择您需要的文档下载。

1. （印刷版）发展党员工作标准化手册（9.6最终稿）
2. 大数据可视化分析 实训报告
3. 子类与继承、接口与实现实验报告
4. 麓山XX实验学校微课申报-基于项目式学习的人工智能课程设计探究
5. 《类目与对象》项目实验报告
6. 关于拟将XXXXXXXXXXXXXXX同志确定为发展对象的公示(1)
7. 建构区纸杯搭建图
8. 幼儿园观察记录表

以上为《Ceph技术架构详解》的无排版文字预览，完整格式请下载

下载前请仔细阅读上面文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。