我们在上篇文章已经对比了不同的存储系统之间的区别，本章开始逐步深入记录Ceph的学习和运用。

开源分布式存储系统的对比

Ceph简介

Ceph是一个分布式存储系统，提供对象，块和文件存储，是一个免费开源软件的存储解决方案，可以部署于普通的x86兼容服务器上，可用于解决统一存储的io问题。Ceph诞生于2004年，最早是SageWeil一项关于存储系统的PhD研究项目，致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源 区受关注较高的项目之一。
该系统被设计成自动修复和智能管理，希望减低管理员和预算开销。
想达到的目标：没有单点故障的完全分布式存储系统，使数据能容错和无缝的复制，可扩展EB水平(EB,PB,TB,GB)

Ceph同时支持块、文件、对象接口，支持PB级别扩展，规格上可部署到上千台通用服务器。对象S3和Swift写入的数据是相互可读取的。

官
https://ceph.com/
文档
http://docs.ceph.com/docs/master/#how-ceph-clients-stripe-data
ceph线下会议
https://ceph.com/cephdays/

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 集群主要由两种节点组成：一种是为数众多的、负责完成数据存储和维护功能的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的读写操作采用主从模型，客户端要读写数据时，只能向对象所对应的主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个端口，分别用于接收客户请求、传输数据、发送心跳、同步数据等操作。

默认大小为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版本较低，则把自己更新的版本发送给对方。

推荐使用以下的架构

在创建CEPHFS时，要至少创建两个POOL，一个用于存放数据，另一个用于存放元数据。Mds只是负责接受用户的元数据查询请求，然后从osd中把数据取出来映射进自己的内存中供客户访问。所以mds其实类似一个代理缓存服务器，替osd分担了用户的访问压力,如下图：

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数据分布算法

在分布式存储系统中比较关注的一点是如何使得数据能够分布得更加均衡，常见的数据分布算法有一致性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算法配合才能完成。

本质上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到osd列表映射; 通过crush算法计算PG上的对象分布到哪些OSD硬盘上；

CRUSH算法是 ceph的精华所在；

crush的目标

先看看crush算法的希望达成的目标：
数据均匀的分布到集群中；
需要考虑各个OSD权重的不同（根据读写性能的差异，磁盘的容量的大小差异等设置不同的权重）
当有OSD损坏需要数据迁移时，数据的迁移量尽可能的少；

crush算法过程

简单说下crush算法的过程：
第一步输入PG id、可供选择的OSD id 列表，和一个常量，通过一个伪随机算法，得到一个随机数，伪随机算法保证了同一个key总是得到相同的随机数，从而保证每次计算的存储位置不会改变；

第二步将上面得到的随机数和每个OSD的权重相乘，然后挑出乘积最大的那个OSD；

在样本容量足够大之后，这个随机数对挑中的结果不再有影响，起决定性影响的是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选择一个顶上

注意：条带化是独立于对象副本的。由于CRUSH副本对象跨越OSDs，所以条带自动的被复制。

条带化参数

Object Size:
足够大可以容纳条带单元，必须容纳一个或者多个条带单元。（如2MB，4MB）
Stripe Width:
一个条带单元的大小，除了最后一个，其他必须一样大（如64K）
Stripe Count:
连续写入一系列的对象的个数（如4个）
注意：
参数一旦设置不可改变，提前做好性能测试

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的个数及副本策略来确定：

线上尽量不要更改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迭代器的使用

参考链接:
https://www.cnblogs.com/me115/p/6366374.html
https://www.cnblogs.com/luohaixian/p/8087591.html
https://blog.csdn.net/i_chips/article/details/53487719