| 编辑推荐: |
| 本文来自于csdn，本文通过逐步深入记录Ceph的学习和运用介绍了ceph的架构原理，希望对您的学习有所帮助。 |
|
Ceph简介
Ceph是一个分布式存储系统，提供对象，块和文件存储，是一个免费开源软件的存储解决方案，可以部署于普通的x86兼容服务器上，可用于解决统一存储的io问题。Ceph诞生于2004年，最早是SageWeil一项关于存储系统的PhD研究项目，致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目之一。
该系统被设计成自动修复和智能管理，希望减低管理员和预算开销。
想达到的目标：没有单点故障的完全分布式存储系统，使数据能容错和无缝的复制，可扩展EB水平(EB,PB,TB,GB)
Ceph同时支持块、文件、对象接口，支持PB级别扩展，规格上可部署到上千台通用服务器。对象S3和Swift写入的数据是相互可读取的。
Ceph的优点
CRUSH算法
Crush算法是ceph的两大创新之一，简单来说，ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。
高可用
Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性；
ceph可以忍受多种故障场景并自动尝试并行修复。
高扩展性
Ceph不同于swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。
特性丰富
Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用ceph作为openstack的唯一后端存储来提升数据转发效率。
Ceph的存储实现架构
Ceph系统可以大致划分为两大部分，客户端和服务端，客户端包含了四种接口，服务端包含了元数据服务器，对象存储集群和集群监视器：
客户端
面向用户的使用提供接口，目前有三种存储方式接口提供，对象存储 RGW(rados
gateway)、块存储 RBD(rados block device) 和文件存储 CephFS。
块存储和文件存储都是基于对象存储来进行封装实现的，块存储和文件存储的底层还是对象存储。
对象存储（RGW:RADOS gateway）
Ceph 对象存储服务提供了 REST 风格的 API ，它有与 Amazon
S3 和 OpenStack Swift 兼容的接口。也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL和其他扩展;
RADOSGW是一套基于当前流行的RESTFUL协议的网关，并且兼容S3和Swift。
块存储（RBD：RADOS block device）
RBD通过Linux内核客户端和QEMU/KVM驱动来提供一个分布式的块设备。
RBD 是通过librbd库对应用提供块存储，主要面向云平台的虚拟机提供虚拟磁盘；RBD类似传统的SAN存储，提供数据块级别的访问；
目前 RBD 提供了两个接口，一种是直接在用户态实现， 通过 QEMU
Driver 供 KVM 虚拟机使用。 另一种是在操作系统内核态实现了一个内核模块。通过该模块可以把块设备映射给物理主机，由物理主机直接访问。
文件存储 （CEPH FS）
CEPH FS通过Linux内核客户端和FUSE来提供一个兼容POSIX的文件系统。
Ceph 文件系统服务提供了兼容 POSIX 的文件系统，可以直接挂载为用户空间文件系统。它跟传统的文件系统如Ext4是一个类型，区别在于分布式存储提供了并行化的能力；
原生接口
除了以上3种存储接口， 还可以直接使用 librados 的原生接口，直接和RADOS通信；
原生接口的优点是是它直接和和应用代码集成，操作文件很方便；但它的问题是它不会主动为上传的数据分片；一个1G的大对象上传，落到
Ceph 的存储磁盘上就是1G的文件；
而以上三个接口是具有分片功能（即:条带化 file-striping)
服务端
元数据服务器
主要是实现集群元数据的分布式管理
对象存储集群
因为ceph的三种存储接口都是通过对象存储实现的，对象存储集群将数据和元数据作为对象存储，执行其他关键职能。
对象存储集群的核心组件是RADOS (Reliable, AutonomicDistributed
Object Store)。
集群监视器
执行监视功能，保证集群的健康运行和告警
客户端和服务端交互
它们之间的结构和交互如图:
从架构图中可以看到最底层的是RADOS，RADOS自身是一个完整的分布式对象存储系统，它具有可靠、智能、分布式等特性，Ceph所有的存储功能都是基于RADOS实现，所以Ceph的高可靠、高可拓展、高性能、高自动化都是由这一层来提供的，用户数据的存储最终也都是通过这一层来进行存储的，RADOS可以说就是Ceph的核心。
RADOS系统主要由两部分组成，分别是OSD和Monitor。
RADOS采用C++开发，所提供的原生Librados API包括C和C++两种。Ceph的上层应用调用本机上的librados
API，再由后者通过socket与RADOS集群中的其他节点通信并完成各种操作。
基于RADOS层的上一层是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。
基于LIBRADOS层开发的又可以看到有三层，分别是RADOSGW、RBD和CEPH
FS。
RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful
API的gateway，以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。
目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。
这两种方式目前在云计算中应用的比较多。
CEPHFS则提供了POSIX接口，用户可直接通过客户端挂载使用。它是内核态的程序，所以无需调用用户空间的librados库。它通过内核中的net模块来与Rados进行交互。通过FUSE挂载到客户端的存储系统使用起来跟本地硬盘的使用方式一致，使用挂载路径即可访问。
Ceph的物理部署
服务端 RADOS 集群主要由两种节点组成：一种是为数众多的、负责完成数据存储和维护功能的OSD（Object
Storage Device），另一种则是若干个负责完成系统状态检测和维护的monitor。
Monitor
Monitor 集群提供了整个存储系统的节点信息等全局的配置信息，通过
Paxos 算法保持数据的一致性。
OSD
Pool是存储对象的逻辑分区，它规定了数据冗余的类型和对应的副本分布策略；支持两种类型：副本（replicated）和
纠删码（ Erasure Code）；目前我们公司内部使用的Pool都是副本类型（3副本）；
PG（ placement group）是一个放置策略组，它是对象的集合，该集合里的所有对象都具有相同的放置策略；简单点说就是相同PG内的对象都会放到相同的硬盘上；
PG是 ceph的核心概念， 服务端数据均衡和恢复的最小粒度就是PG；
OSD是负责物理存储的进程，一般配置成和磁盘一一对应，一块磁盘启动一个OSD进程；
下面这张图形象的描绘了它们之间的关系：
一个Pool里有很多PG，
一个PG里包含一堆对象；一个对象只能属于一个PG；
PG有主从之分，一个PG分布在不同的OSD上（针对三副本类型）
Ceph的组件详解
Ceph的核心组件包括Ceph OSD、Ceph Monitor和Ceph
MDS。
Ceph OSD
OSD的英文全称是Object Storage Device，它的主要功能是存储数据、复制数据、平衡数据、恢复数据等，与其它OSD间进行心跳检查等，并将一些变化情况上报给Ceph
Monitor。一般情况下一块硬盘对应一个OSD，由OSD来对硬盘存储进行管理，当然一个分区也可以成为一个OSD。
Ceph OSD的架构实现由物理磁盘驱动器、Linux文件系统和Ceph
OSD服务组成，对于Ceph OSD Deamon而言，Linux文件系统显性的支持了其拓展性，一般Linux文件系统有好几种，比如有BTRFS、XFS、Ext4等，BTRFS虽然有很多优点特性，但现在还没达到生产环境所需的稳定性，一般比较推荐使用XFS。
OSD是强一致性的分布式存储，它的读写流程如下图
Ceph的读写操作采用主从模型，客户端要读写数据时，只能向对象所对应的主osd节点发起请求。主节点在接受到写请求时，会同步的向从OSD中写入数据。当所有的OSD节点都写入完成后，主节点才会向客户端报告写入完成的信息。因此保证了主从节点数据的高度一致性。而读取的时候，客户端也只会向主osd节点发起读请求，并不会有类似于数据库中的读写分离的情况出现，这也是出于强一致性的考虑。由于所有写操作都要交给主osd节点来处理，所以在数据量很大时，性能可能会比较慢，为了克服这个问题以及让ceph能支持事物，每个osd节点都包含了一个journal文件。
伴随OSD的还有一个概念叫做Journal盘，一般写数据到Ceph集群时，都是先将数据写入到Journal盘中，然后每隔一段时间比如5秒再将Journal盘中的数据刷新到文件系统中。一般为了使读写时延更小，Journal盘都是采用SSD，一般分配10G以上，当然分配多点那是更好，Ceph中引入Journal盘的概念是因为Journal允许Ceph
OSD功能很快做小的写操作；一个随机写入首先写入在上一个连续类型的journal，然后刷新到文件系统，这给了文件系统足够的时间来合并写入磁盘，一般情况下使用SSD作为OSD的journal可以有效缓冲突发负载。
在ceph中，每一个osd进程都可称作是一个osd节点，也就是说，每台存储服务器上可能包含了众多的osd节点，每个osd节点监听不同的端口，类似于在同一台服务器上跑多个mysql或redis。每个osd节点可以设置一个目录作为实际存储区域，也可以是一个分区，一整块硬盘。如下图，当前这台机器上跑了两个osd进程，每个osd监听4个端口，分别用于接收客户请求、传输数据、发送心跳、同步数据等操作。
如上图所示，osd节点默认监听tcp的6800到6803端口，如果同一台服务器上有多个osd节点，则依次往后排序。
在生产环境中的osd最少可能都有上百个，所以每个osd都有一个全局的编号，类似osd0，osd1，osd2……..序号根据osd诞生的顺序排列，并且是全局唯一的。存储了相同PG的osd节点除了向mon节点发送心跳外，还会互相发送心跳信息以检测pg数据副本是否正常。
之前在介绍数据流向时说过，每个osd节点都包含一个journal文件，如下图：
默认大小为5G，也就说每创建一个osd节点，还没使用就要被journal占走5G的空间。这个值是可以调整的，具体大小要依osd的总大小而定。
Journal的作用类似于mysql innodb引擎中的事物日志系统。当有突发的大量写入操作时，ceph可以先把一些零散的，随机的IO请求保存到缓存中进行合并，然后再统一向内核发起IO请求。这样做效率会比较高，但是一旦osd节点崩溃，缓存中的数据就会丢失，所以数据在还未写进硬盘中时，都会记录到journal中，当osd崩溃后重新启动时，会自动尝试从journal恢复因崩溃丢失的缓存数据。因此journal的io是非常密集的，而且由于一个数据要io两次，很大程度上也损耗了硬件的io性能，所以通常在生产环境中，使用ssd来单独存储journal文件以提高ceph读写性能。
Ceph Monitor
由该英文名字我们可以知道它是一个监视器，负责监视Ceph集群，维护Ceph集群的健康状态，同时维护着Ceph集群中的各种Map图，比如OSD
Map、Monitor Map、PG Map和CRUSH Map，这些Map统称为Cluster Map，Cluster
Map是RADOS的关键数据结构，管理集群中的所有成员、关系、属性等信息以及数据的分发，比如当用户需要存储数据到Ceph集群时，OSD需要先通过Monitor获取最新的Map图，然后根据Map图和object
id等计算出数据最终存储的位置。
Mon节点监控着整个ceph集群的状态信息，监听于tcp的6789端口。每一个ceph集群中至少要有一个Mon节点，官方推荐每个集群至少部署三台。Mon节点中保存了最新的版本集群数据分布图（cluster
map）的主副本。客户端在使用时，需要挂载mon节点的6789端口，下载最新的cluster map，通过crush算法获得集群中各osd的IP地址，然后再与osd节点直接建立连接来传输数据。所以对于ceph来说，并不需要有集中式的主节点用于计算与寻址，客户端分摊了这部分工作。而且客户端也可以直接和osd通信，省去了中间代理服务器的额外开销。
Mon节点之间使用Paxos算法来保持各节点cluster map的一致性；各mon节点的功能总体上是一样的，相互间的关系可以被简单理解为主备关系。如果主mon节点损坏，其他mon存活节点超过半数时，集群还可以正常运行。当故障mon节点恢复时，会主动向其他mon节点拉取最新的cluster
map。
Mon节点并不会主动轮询各个osd的当前状态，相反，osd只有在一些特殊情况才会上报自己的信息，平常只会简单的发送心跳。特殊情况包括：1、新的OSD被加入集群；2、某个OSD发现自身或其他OSD发生异常。Mon节点在收到这些上报信息时，则会更新cluster
map信息并加以扩散。
cluster map信息是以异步且lazy的形式扩散的。monitor并不会在每一次cluster
map版本更新后都将新版本广播至全体OSD，而是在有OSD向自己上报信息时，将更新回复给对方。类似的，各个OSD也是在和其他OSD通信时，如果发现对方的osd中持有的cluster
map版本较低，则把自己更新的版本发送给对方。
推荐使用以下的架构
这里的ceph除了管理网段外，设了两个网段，一个用于客户端读写传输数据。另一个用于各OSD节点之间同步数据和发送心跳信息等。这样做的好处是可以分担网卡的IO压力。否则在数据清洗时，客户端的读写速度会变得极为缓慢。
Ceph MDS
全称是Ceph MetaData Server，Mds是ceph集群中的元数据服务器，而通常它都不是必须的，因为只有在使用cephfs的时候才需要它，对象存储和块存储设备是不需要使用该服务的，而目前云计算中用的更广泛的是另外两种存储方式。
Mds虽然是元数据服务器，但是它不负责存储元数据，元数据也是被切成对象存在各个osd节点中的，如下图：
在创建CEPHFS时，要至少创建两个POOL，一个用于存放数据，另一个用于存放元数据。Mds只是负责接受用户的元数据查询请求，然后从osd中把数据取出来映射进自己的内存中供客户访问。所以mds其实类似一个代理缓存服务器，替osd分担了用户的访问压力,如下图：
Ceph与云平台的关系
Ceph已经成为OpenStack后端存储标配，OpenStack作为IaaS系统，涉及到存储的部分主要是块存储服务模块、对象存储服务模块、镜像管理模块和计算服务模块，对应为其中的Cinder、Swift、Glance和Nova四个项目。
Ceph RBD块存储是以独立卷的方式挂接到OpenStcak Cinder模块，主要用作数据盘，这种方式主要通过Cinder
Driver实现，删除虚拟机时卷依然存在。Nova对接Ceph时，Ceph RBD块存储卷需要与虚拟机绑定，所以删除虚拟机时卷也删除，一般用作启动盘。Ceph也可以和Glance对接用于镜像卷。Keystone作为OpenStack对象Swift的认证模块，支持Ceph通过RADOSGW网关认证，给OpenStcak提供Swift存储服务。
Ceph社区已经把Ceph 的RBD块存储镜像支持功能扩展到Docker中。在Docker中Ceph的RBD镜像功能主要是负责把RBD镜像通过异步通信的方式从一个Ceph集群复制到另一个Ceph集群，用于对Docker镜像容灾保护和恢复。
Ceph内部数据存储视图
在Ceph存储系统中，Cehp的基础服务架构主要包括了Object
Storage Device(OSD)，Monitor和MDS。
提供了Librados原生对象基础库、Librbd块存储库、基于S3
和Swift兼容的Librgw对象库和Libceph文件系统库。
搭建一台Ceph系统至少需要1个Ceph Monitor和2个Ceph
OSD。
一个Cluster可逻辑上划分为多个Pool。
一个 Pool由若干个逻辑 PG( Placement Group)组成，Pool内的副本数量也是可以设置的
Ceph底层是对象系统，所以一个文件会被切分为多个Object，每个Object会被映射到一个PG，每个
PG 会映射到一组 OSD(Object Storage Device)，其中第一个OSD 是主，其余的是备，OSD间通过心跳来相互监控存活状态。引入PG概念后，OSD只和PG相关，不但简化了OSD的数据存储，而且实现了Object到OSD的动态映射，OSD的添加和故障不影响Object的映射。
Ceph数据如何存储
在Ceph存储系统中，数据存储分三个映射过程
首先要将用户要操作的file，映射为RADOS能够处理的object。就是简单的按照object的size对file进行切分，相当于RAID中的条带化过程。
接着把Object映射到PG，在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。
第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。
文件存入时，首先把File切分为RADOS层面的Object，每个Object一般为2MB或4MB(大小可设置)。每个Object通过哈希算法映射到唯一的PG。每个PG通过Crush算法映射到实际存储单元OSD，PG和OSD间是多对多的映射关系。OSD在物理上可划分到多个故障域中，故障域可以跨机柜和服务器，通过策略配置使PG的不同副本位于不同的故障域中。
Ceph数据分布算法
在分布式存储系统中比较关注的一点是如何使得数据能够分布得更加均衡，常见的数据分布算法有一致性Hash和Ceph的Crush算法。Crush是一种伪随机的控制数据分布、复制的算法，Ceph是为大规模分布式存储而设计的，数据分布算法必须能够满足在大规模的集群下数据依然能够快速的准确的计算存放位置，同时能够在硬件故障或扩展硬件设备时做到尽可能小的数据迁移，Ceph的CRUSH算法就是精心为这些特性设计的，可以说CRUSH算法也是Ceph的核心之一。
Ceph以私有Client方式对外提供服务，支持Linux用户态(Fuse)和内核态(VFS)方式，Clinet还实现数据切片，通过Crush算法定位对象位置，并进行数据的读写。但在测试中，通常在Ceph服务器端将Ceph配置成NFS服务的ExportFS，通过标准NFS接口导出目录。
CephFS 支持POSIX、HDFS、NFS、CIFS服务接口，其中NFS和CIFS通过外置网关实现(通过Clinet导出)。
在PG通过Crush算法映射到数据的实际存储单元OSD时，需求通过Crush
Map、Crush Rules和Crush算法配合才能完成。
Cluster Map用来记录全局系统状态记数据结构，由Crush
Map和OSD Map两部分组成。 Crush Map包含当前磁盘、服务器、机架的层级结构，OSD
Map包含当前所有Pool的状态和所有OSD的状态。
Crush Rules就是数据映射的策略，决定了每个数据对象有多少个副本，这些副本如何存储。
Crush算法是一种伪随机算法，通过权重决定数据存放（如跨机房、机架感知等），通常采用基于容量的权重。Crush算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket(Uniform、List、Tree、Straw)，大多数情况下的都采用Straw。
在说明CRUSH算法的基本原理之前，先介绍几个概念和它们之间的关系。
存储数据与object的关系：当用户要将数据存储到Ceph集群时，存储数据都会被分割成多个object，每个object都有一个object
id，每个object的大小是可以设置的，默认是4MB，object可以看成是Ceph存储的最小存储单元。
object与pg的关系：由于object的数量很多，所以Ceph引入了pg的概念用于管理object，每个object最后都会通过CRUSH计算映射到某个pg中，一个pg可以包含多个object。
pg与osd的关系：pg也需要通过CRUSH计算映射到osd中去存储，如果是二副本的，则每个pg都会映射到二个osd，比如[osd.1,osd.2]，那么osd.1是存放该pg的主副本，osd.2是存放该pg的从副本，保证了数据的冗余。
pg和pgp的关系：pg是用来存放object的，pgp相当于是pg存放osd的一种排列组合，我举个例子，比如有3个osd，osd.1、osd.2和osd.3，副本数是2，如果pgp的数目为1，那么pg存放的osd组合就只有一种，可能是[osd.1,osd.2]，那么所有的pg主从副本分别存放到osd.1和osd.2，如果pgp设为2，那么其osd组合可以两种，可能是[osd.1,osd.2]和[osd.1,osd.3]，是不是很像我们高中数学学过的排列组合，pgp就是代表这个意思。一般来说应该将pg和pgp的数量设置为相等。这样说可能不够明显，我们通过一组实验来体会下：
先创建一个名为testpool包含6个PG和6个PGP的存储池
ceph osd pool create testpool 6 6
通过写数据后我们查看下pg的分布情况，使用以下命令：
ceph pg dump pgs | grep ^1 | awk ‘{print
1,1,2,$15}’
dumped pgs in format plain
1.1 75 [3,6,0]
1.0 83 [7,0,6]
1.3 144 [4,1,2]
1.2 146 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
第1列为pg的id，第2列为该pg所存储的对象数目，第3列为该pg所在的osd
我们扩大PG再看看
ceph osd pool set testpool pg_num
12
再次用上面的命令查询分布情况：
1.1 37 [3,6,0]
1.9 38 [3,6,0]
1.0 41 [7,0,6]
1.8 42 [7,0,6]
1.3 48 [4,1,2]
1.b 48 [4,1,2]
1.7 48 [4,1,2]
1.2 48 [7,4,1]
1.6 49 [7,4,1]
1.a 49 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
我们可以看到pg的数量增加到12个了，pg1.1的对象数量本来是75的，现在是37个，可以看到它把对象数分给新增的pg1.9了，刚好是38，加起来是75，而且可以看到pg1.1和pg1.9的osd盘是一样的。
而且可以看到osd盘的组合还是那6种。
我们增加pgp的数量来看下，使用命令：
ceph osd pool set testpool pgp_num
12
再看下
1.a 49 [1,2,6]
1.b 48 [1,6,2]
1.1 37 [3,6,0]
1.0 41 [7,0,6]
1.3 48 [4,1,2]
1.2 48 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
1.7 48 [1,6,0]
1.6 49 [3,6,7]
1.9 38 [1,4,2]
1.8 42 [1,2,3]
再看pg1.1和pg1.9，可以看到pg1.9不在[3,6,0]上，而在[1,4,2]上了，该组合是新加的，可以知道增加pgp_num其实是增加了osd盘的组合。
通过实验总结：
（1）PG是指定存储池存储对象的目录有多少个，PGP是存储池PG的OSD分布组合个数
（2）PG的增加会引起PG内的数据进行分裂，分裂相同的OSD上新生成的PG当中
（3）PGP的增加会引起部分PG的分布进行变化，但是不会引起PG内对象的变动
pg和pool的关系：pool也是一个逻辑存储概念，我们创建存储池pool的时候，都需要指定pg和pgp的数量，逻辑上来说pg是属于某个存储池的，就有点像object是属于某个pg的。
以下这个图表明了存储数据，object、pg、pool、osd、存储磁盘的关系
本质上CRUSH算法是根据存储设备的权重来计算数据对象的分布的，权重的设计可以根据该磁盘的容量和读写速度来设置，比如根据容量大小可以将1T的硬盘设备权重设为1，2T的就设为2，在计算过程中，CRUSH是根据Cluster
Map、数据分布策略和一个随机数共同决定数组最终的存储位置的。
Cluster Map里的内容信息包括存储集群中可用的存储资源及其相互之间的空间层次关系，比如集群中有多少个支架，每个支架中有多少个服务器，每个服务器有多少块磁盘用以OSD等。
数据分布策略是指可以通过Ceph管理者通过配置信息指定数据分布的一些特点，比如管理者配置的故障域是Host，也就意味着当有一台Host起不来时，数据能够不丢失，CRUSH可以通过将每个pg的主从副本分别存放在不同Host的OSD上即可达到，不单单可以指定Host，还可以指定机架等故障域，除了故障域，还有选择数据冗余的方式，比如副本数或纠删码。
下面这个式子简单的表明CRUSH的计算表达式：
CRUSH(X) -> (osd.1,osd.2…..osd.n)
式子中的X就是一个随机数。
下面通过一个计算PG ID的示例来看CRUSH的一个计算过程：
（1）Client输入Pool ID和对象ID；
（2）CRUSH获得对象ID并对其进行Hash运算；
（3）CRUSH计算OSD的个数，Hash取模获得PG的ID，比如0x48；
（4）CRUSH取得该Pool的ID，比如是1；
（5）CRUSH预先考虑到Pool ID相同的PG ID，比如1.48。
对象的寻址过程
查找对象在集群中的存储的位置，具体分为两步：
第一步，对象到PG的映射；将对象的id 通过hash映射，然后用PG总数对hash值取模得到pg
id：
| pg_
id = hash( object_ id ) % pg_num |
第二步，PG到osd列表映射; 通过crush算法计算PG上的对象分布到哪些OSD硬盘上；
CRUSH算法是 ceph的精华所在；
crush的目标
先看看crush算法的希望达成的目标：
数据均匀的分布到集群中；
需要考虑各个OSD权重的不同（根据读写性能的差异，磁盘的容量的大小差异等设置不同的权重）
当有OSD损坏需要数据迁移时，数据的迁移量尽可能的少；
crush算法过程
简单说下crush算法的过程：
第一步输入PG id、可供选择的OSD id 列表，和一个常量，通过一个伪随机算法，得到一个随机数，伪随机算法保证了同一个key总是得到相同的随机数，从而保证每次计算的存储位置不会改变；
| CRUSH_HASH(
PG_ID, OSD_ID, r ) = draw! |
第二步将上面得到的随机数和每个OSD的权重相乘，然后挑出乘积最大的那个OSD；
|
( draw &0xffff ) * osd_weight = osd_straw |
在样本容量足够大之后，这个随机数对挑中的结果不再有影响，起决定性影响的是OSD的权重，也就是说，OSD的权重越大，被挑中的概率越大。
到这里了我们再看看crush算法如何达成的目标：
通过随机算法让数据均衡分布，乘以权重让挑选的结果考虑了权重；而如果出现故障OSD，只需要恢复这个OSD上的数据，不在这个节点上的数据不需移动；
crush优缺点
聊到这里，crush算法的优缺点就明显了：
优点：
输入元数据（ cluster map、 placement rule）
较少， 可以应对大规模集群。
可以应对集群的扩容和缩容。
采用以概率为基础的统计上的均衡，在大规模集群中可以实现数据均衡
缺点
在小规模集群中， 会有一定的数据不均衡现象（权重的影响低，主要起作用的是伪随机算法）。
看清楚了寻址的过程，就明白为啥PG不能轻易变更了；PG是寻址第一步中的取模参数，变更PG会导致对象的PG
id 都发生变化，从而导致整个集群的数据迁移；
Ceph 是Sega本人的博士论文作品, 其博士论文被整理成三篇短论文，其中一篇就是
CRUSH
CRUSH论文标题为《CRUSH: Controlled, Scalable,
Decentralized Placement of Replicated Data》，介绍了CRUSH的设计与实现细节。
（PS：另外两篇是 RADOS和 CephFS, 分别讲 Ceph
的服务器实现和 Ceph 文件系统的细节实现）
错误检测和恢复
错误检测
利用心跳
上报monitor
更新map
错误恢复
主osd主持恢复工作
若主osd挂掉，二级osd选择一个顶上
数据条带化
由于存储设备吞吐量的限制，影响性能和可伸缩性。
跨多个存储设备的连续块条带化存储信息，以提高吞吐量和性能
Ceph条带化相似于RAID0
注意：ceph条带化属于client端，不在RADOS范畴
注意：条带化是独立于对象副本的。由于CRUSH副本对象跨越OSDs，所以条带自动的被复制。
条带化参数
Object Size:
足够大可以容纳条带单元，必须容纳一个或者多个条带单元。（如2MB，4MB）
Stripe Width:
一个条带单元的大小，除了最后一个，其他必须一样大（如64K）
Stripe Count:
连续写入一系列的对象的个数（如4个）
注意：
参数一旦设置不可改变，提前做好性能测试
Ceph的高级功能
Ceph支持丰富的存储功能，从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等，到生产环境滚动升级、多存储池、延迟删除等，再到高大上的Ceph集群、快照、EC纠删码、跨存储池缓存等，下面我们简单介绍几个关键特性。
Ceph基于统一存储系统设计，支持三种接口。File文件系统支持POSIX、HDFS、NFS、CIFS服务接口，Block块服务支持精简配置、COW快照、克隆，对象服务支持原生的Object
API、也兼容Swift和S3的API。
在Ceph storage 2中，提供全球对象存储集群，支持单个命名空间，并支持在多Region地区运行的集群之间提供了数据同步，包含Region内主Zone到从Zone数据同步(可同步数据和元数据)和不同Region间数据同步(只能同步元数据，包含网关用户和桶信息、但不包含桶内的对象)。
哪些公司在使用Ceph
红帽
美国预测分析公司FICO
澳大利亚的莫纳什大学 500PB
乐视，一点资讯，今日头条，滴滴，青云等
Ceph仅仅是OpenStack后端存储标配，目前很多存储厂商、大企业都基于Ceph技术开发或搭建存储系统，我们首先看看几家存储厂商的产品，如HopeBay和SanDisk。
Hope Bay科技是一家专注于云平台的科技公司，拥有ArkEase
Pro存储服务平台、ArkFlex数据存储平台、Ark Express存储网关和ArkVoice企业云端语音录制平台。在ArkFlex数据存储平台中，Hope
Bay对Ceph文件系统进行改良，将CIFS、NFS、iSCSI建构在Ceph RBD之上。
SanDisk收购Fusion-io之后相继推出ioControl混合式存储阵列和InfiniFlash系列闪存。剥离相关业务到新成立新NextGen公司，SanDisk通过InfiniFlash系列闪存主攻闪存市场，其中就有一款机型InfiniFlash
System IF500采用Ceph技术(IF100硬件和InfiniFlash OS Ceph横向扩展软件)，同时提供对象存储与块存储服务。SanDisk的存储策略是比较开放，低端存储IF100(纯硬件形态)整合了Nexenta的基于ZFS文件系统开源NexentaStor软件(支持NAS和iSCSI)，而高端的IF700则使用了Fusion-io时期的
ION Accelerator数据库加速软件。
此外，很多大型企业也采用Ceph构建构建云平台和分布式存储解决方案，也正是因为Ceph和OpenStack的深度集成，使得Ceph和OpenStack配合被互联网公司用来搭建云平台。
乐视基于OpenStack 和Ceph(RBD块存储和RADOSGW对象)搭建乐视云平台；宝德云也基于OpenStack、Ceph(RBD块存储和CephFS)
和Docker构建。电商eBay也采用Ceph和 OpenStack 建设私有云，每个Ceph集群容量都高达数
PB 级别，这些集群主要为 OpenStack 服务。同时，eBay 团队在NAS云化投入逐渐加大，CephFS有可能作为NAS
云化的不二之选。
携程基于Ceph搭建PB级云对象存储，浪潮AS13000系列存储也是基于Ceph开发，思科UCS流媒体服务存储也是基于Ceph对象存储，雅虎基于Ceph搭建云对象存储。联通研究院、CERN实验室、United
Stack等也基于Ceph搭建了开发环境。
Ceph已经支持云Ready: 随着云计算的发展，首先Ceph搭上了OpenStack这只大船，预示着Ceph已经完全云Ready。接着Ceph受到Intel、SanDisk、思科、Yahoo等公司支持，尤其是RedHat以重金收购Inktank公司，将其作为发展的主方向。通过多年发展，RadHat也明确了Ceph和Gluster侧重点和发展方向，Gluster更专注于文件，Ceph更专注于块和对象。
Ceph社区力量支持:Ceph社区现在已经有很多厂商参入进来，从Intel、思科、SanDisk等这样的巨头，到United
Stack这样的Startup公司，再到电信、大学、研究所这类非存储领域的公司或单位，Ceph的参与队伍越来越庞大。
Ceph功能的不断完善: Ceph的性能不断得到提升，存储特性也不断丰富，甚至可以与传统专业存储媲美，完备的存储服务和低廉的投资成本，使得越来越多的企业和单位选用Ceph提供存储服务。
SDS和分布式架构: Ceph软件与硬件平台之间完全解耦，对企业来说搭建Ceph存储系统的门槛是逐渐变低，部署简单基于Linux
Ubuntu和标准X86平台。Ceph与存储Sandisk、宝德，云计算United Stack、携程和乐视等公司的成功实践，也为Ceph的广泛应用打下参考基础。
更多详细方案可参考:
其他公司应用Ceph的具体方案
相关使用经验
预先设置PG不更改
一个Pool里设置的PG数量是预先设置的，PG的数量不是随意设置，需要根据OSD的个数及副本策略来确定：
| Total
PGs = ((Total_number_of_OSD * 100) / max_replication_count)
/ pool_count |
线上尽量不要更改PG的数量，PG的数量的变更将导致整个集群动起来（各个OSD之间copy数据），大量数据均衡期间读写性能下降严重；
良好的工程实践建议（掉坑后的教训）：
预先规划Pool的规模，设置PG数量；一旦设置之后就不再变更；后续需要扩容就以
Pool 为维度为扩容，通过新增Pool来实现（Pool通过 crushmap实现故障域隔离）；
故障域的划分
刚开始接触 Ceph，通常会忽略 crushmap，因为即使对它不做任何设置，也不影响我们的正常使用；
一旦集群大了，没有它集群就处于一个危险的运行状态中；
没有故障域的划分，整个集群就处于一个未隔离的资源池中；
一个对象存过去，可能落在 500个OSD硬盘的任意三个上；
如果一块硬盘坏了，可能带来的是全局影响（副本copy，这个硬盘上丢失的PG副本可能分布在全局各个硬盘上）；
使用crushmap 将整个集群的OSD 划分为一个个故障域，类似将一个集群按业务划分成为了多个小集群；每个Pool
只会用到特定的 OSD，这样，一旦某个OSD 损坏，影响的只是某个业务的某个Pool，将故障的范围控制在一个很小的范围内。
良好的工程实践建议：
使用crushmap 划分故障域，将pool限制在特定的osd list上，osd的损坏只会引起这个pool内的数据均衡，不会造成全局影响；
服务端对象的存储
对象是数据存储的基本单元， 一般默认 4MB 大小（这里指的是RADOS的底层存储的对象，非RGW接口的对象）。
对象的组成分为3部分：key 、value、元数据；
元数据可直接存在文件的扩展属性中（必须是标准的文件属性），也可存到levelDb中；
value 就是对象数据，在本地文件系统中用一个文件存储；
对于大文件的存储，Ceph 提供的客户端接口会对大文件分片（条带化）后存储到服务端；这个条带化操作是在客户端接口程序完成的，在
Ceph 存储集群内存储的那些对象是没条带化的。客户端通过 librados 直接写入 Ceph 存储的数据不会分片。
良好的工程实践建议：
对于对象存储，只使用 Ceph 提供的 RGW 接口， 不使用 librados原生接口；不仅有分片功能，扩展也更容易（RGW是无状态的，可水平扩展）；大量大对象直接存放到
Ceph中会影响 Ceph 稳定性（存储容量达到60%后）；
Ceph二次开发可优化的地方
内网传输的加密安全问题
优化Ceph对levelDB迭代器的使用
|
