MYSQL-Ceph的使用

Ceph
Ceph是一个开源的、统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。其中“统一”是说Ceph可以一套存储系统同时提供块设备存储、文件系统存储和对象存储三种存储功能。
Ceph项目最早起源于加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统，其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性，并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。
Ceph是一个开源的分布式文件系统。因为它还支持块存储、对象存储，所以很自然的被用做云计算框架openstack或cloudstack整个存储后端。当然也可以单独作为存储，例如部署一套集群作为对象存储、SAN存储、NAS存储等。
官网：http://docs.ceph.org.cn/start/intro/
ceph支持的3种存储方式
1、块存储
首先，什么是块设备？块设备是i/o设备中的一类，是将信息存储在固定大小的块中，每个块都有自己的地址，还可以在块设备的任意位置读取一定长度的数据。例如，硬盘就是块设备。
当给计算机连接块设备（硬盘）后，系统检测的有新的块设备，该类型块设备的驱动程序就在/dev/下创建个对应的块设备设备文件，用户就可以通过设备文件使用该块设备了。
它们怎么有的叫 sda？有的叫 sdb？有的叫 hda？
以sd开头的块设备文件对应的是scsi接口的硬盘，而以hd开头的块设备文件对应的是IDE接口的硬盘。而sda和sdb的区别呢？当系统检测到多个scsi硬盘时，会根据检测到的顺序对硬盘设备进行字母顺序的命名。注：系统按检测顺序命名硬盘会导致了盘符漂移的问题。
怎么还有的叫 rbd1 和 rbd2 呢?
rbd就是由Ceph集群提供出来的块设备。可以这样理解，sda和hda都是通过数据线连接到了真实的硬盘，而rbd是通过网络连接到了Ceph集群中的一块存储区域，往rbd设备文件写入数据，最终会被存储到Ceph集群的这块区域中。
总结一下，块设备可理解成一块硬盘，用户可以直接使用不含文件系统的块设备（裸设备），也可以将其格式化成特定的文件系统，由文件系统来组织管理存储空间，从而为用户提供丰富而友好的数据操作支持。
综上所述，块存储，即rbd。有kernel rbd和librbd两种使用方式。支持快照、克隆。相当于一块硬盘挂到本地，用法和用途和硬盘一样。比如在OpenStack项目里，Ceph的块设备存储可以对接OpenStack的后端存储。

2、文件系统存储
Ceph文件系统（CEPH FS）是一个POSIX兼容的文件系统，可以将ceph集群看做一个共享文件系统挂载到本地，使用Ceph的存储集群来存储其数据，同时支持用户空间文件系统FUSE。它可以像 NFS 或者 SAMBA 那样，提供共享文件夹，客户端通过挂载目录的方式使用 Ceph 提供的存储。
在CEPH FS中，与对象存储与块存储最大的不同就是在集群中增加了文件系统元数据服务节点MDS(Ceph Metadata Server)。MDS也支持多台机器分布式的部署，以实现系统的高可用性。文件系统客户端需要安装对应的Linux内核模块Ceph FS Kernel Object或者Ceph FS FUSE组件。
还记得上面说的块设备上的文件系统吗，用户可以在块设备上创建xfs文件系统，也可以创建ext4等其他文件系统。如下图所示，Ceph集群实现了自己的文件系统来组织管理集群的存储空间，用户可以直接将Ceph集群的文件系统挂载到用户机上使用。

ceph有了块设备接口，在块设备上完全可以构建一个文件系统，那么Ceph为什么还需要文件系统接口呢？
主要是因为应用场景的不同，Ceph的块设备具有优异的读写性能，但不能多处挂载同时读写，目前主要用在OpenStack上作为虚拟磁盘，而Ceph的文件系统接口读写性能较块设备接口差，但具有优异的共享性。
为什么Ceph的块设备接口不具有共享性，而Ceph的文件系统接口具有呢？
对于Ceph的块设备接口，如下图，文件系统的结构状态是维护在各用户机中的，假设Ceph块设备同时挂载到了用户机1和用户机2，当在用户机1上的文件系统中写入数据后，更新了用户机1的中文件系统状态，最终数据存储到了Ceph集群中，但是此时用户机2中的文件系统并不能得知底层Ceph集群数据已经变化而维持数据结构不变，因此用户无法从用户机2上读取用户机1上新写入的数据。

对于Ceph的文件系统接口，如下图，文件系统的结构状态是维护在远端Ceph集群中的，Ceph文件系统同时挂载到了用户机1和用户机2，当往用户机1的挂载点写入数据后，远端Ceph集群中的文件系统状态结构随之更新，当从用户机2的挂载点访问数据时会去远端Ceph集群取数据，由于远端Ceph集群已更新，所有用户机2能够获取最新的数据。

总结一下，Ceph的文件系统弥补了Ceph的块设备在共享性方面的不足，Ceph的文件系统符合POSIX标准，用户可以像使用本地存储目录一样使用Ceph的文件系统的挂载目录，即无需修改你的程序，就可以将程序的底层存储换成空间无限并可多处共享读写的Ceph集群文件系统。
3、对象存储
什么是对象存储
1）对象存储，也就是键值存储，通过其接口指令，也就是简单GET、PUT、DEL和其他扩展指令，向存储服务上传下载数据等
2）对象存储中所有数据都被认为是一个对象。所以，任何数据都可以存入对象存储服务器，如图片、视频、音频等
Ceph 对象存储的构成
Ceph 对象存储主要是通过RGW来实现，那么什么是 RGW 呢？
1）RGW 即 Rados Gateway 的全称。
2）RGW 是 Ceph 对象存储网关，用于向客户端应用程序提供存储界面，提供 RESTful API 访问接口。
3）RGW 可以部署多台做为 高可用和负载均衡

目前Ceph支持两种API接口：
(1) S3.compatible：S3兼容的接口，提供与Amazon S3大部分RESTfuI API接口兼容的API接口。
(2) Swift.compatible：提供与OpenStack Swift大部分接口兼容的API接口。
Ceph的块设备存储具有优异的存储性能但不具有共享性，而Ceph的文件系统具有共享性，然而性能较块设备存储差，对象存储具有共享性而存储性能好于文件系统存储的存储，对象存储就这样出现了。
总结一下，文件系统存储具有复杂的数据组织结构，能够提供给用户更加丰富的数据操作接口，而对象存储精简了数据组织结构，提供给用户有限的数据操作接口，以换取更好的存储性能。对象接口提供了REST API，非常适用于作为web应用的存储。
Ceph相比其它分布式存储有哪些优点？
统一存储
Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用ceph作为openstack的唯一后端存储来提升数据转发效率。所以在开源存储软件中，能够一统江湖。
CRUSH算法
Crush算法是ceph的两大创新之一，简单来说，ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。
高扩展性
扩容方便、容量大。能够管理数千台服务器、EB级的容量。
可靠性强（即高可用性）
Ceph中的数据副本数量可以由管理员自行定义，副本能够垮主机、机架、机房、数据中心存放。所以安全可靠。存储节点可以自管理、自动修复。无单点故障，容错性强。
高性能
因为是多个副本，因此在读写操作时候能够做到高度并行化。理论上，节点越多，整个集群的IOPS和吞吐量越高。另外一点ceph客户端读写数据直接与存储设备(osd) 交互。
Ceph各组件介绍：
Ceph OSD=MonitorsMDS=Mgr
Ceph OSD: （Object Storage Device）提供存储资源
Ceph OSD：功能是用于集群中所有数据与对象的存储，处理集群数据的复制、恢复、回填、再均衡，与其它OSD间进行心跳检查等，并将一些变化情况上报给Ceph Monitor。
一般情况下一块硬盘对应一个OSD，由OSD来对硬盘存储进行管理，当然一个分区也可以成为一个OSD。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，你可以调整副本数，active表示磁盘处于活动状态，clean表示主osd和副本osd成功同步）。
伴随OSD的还有一个概念叫做Journal盘，一般写数据到Ceph集群时，都是先将数据写入到Journal盘中，然后每隔一段时间再将Journal盘中的数据刷到文件系统中。一般为了使读写时延更小，Journal盘都是采用SSD，一般分配10G以上，当然分配多点那是更好。Ceph中引入Journal盘的概念是因为Journal允许Ceph OSD随机小块的写操作首先写入journal，然后合并成顺序IO刷到文件系统。
Monitors:
Ceph Monitor负责监视Ceph集群，维护Ceph集群的健康状态，同时维护着Ceph集群中的各种Map图，包括监视器图、OSD 图、归置组（ PG ）图、和 CRUSH 图。
还维护了monitor、OSD和PG的状态改变历史信息，这些Map统称为Cluster Map，Cluster Map是RADOS的关键数据结构，管理集群中的所有成员、关系、属性等信息以及数据的分发，比如当用户需要存储数据到Ceph集群时，OSD需要先通过Monitor获取最新的Map图，然后根据Map图和object id等计算出数据最终存储的位置。Ceph 存储集群至少需要一个 Ceph Monitor（服务器数量必须是奇数） 和两个 OSD 守护进程。而运行 Ceph 文件系统客户端时，则必须要有元数据服务器（ Metadata Server ）。
MDS:
Ceph 元数据服务器（MDS）为 Ceph 文件系统存储元数据，但对象存储和块存储设备是不需要使用该服务。元数据服务器使得 POSIX 文件系统的用户可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。
Mgr
ceph luminous版本中新增加了一个组件： Ceph Manager Daemon，简称ceph-mgr。 该组件的主要作用是分担和扩展monitor的部分功能，减轻monitor的负担，让更好地管理ceph存储系统。
mgr的实现与用途
ceph-mgr是由C/C++、python以及Cpython等共同编写完成的，mgr的实现使用了大量的Extending Python with C or C++的语法。
由ceph-mgr的实现其实大概可以猜到，其将ceph的部分C/C++实现的接口python化（即以前只能通过调用c/c++接口发送msg获取，比如osdmap、monmap等集群状态，现通过mgr可以很方便地拿到。同时，ceph-mgr支持用户自定义的plugin（插件纯python开发，特别方便），用以实现特殊功能。
Ceph Manager守护进程（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。Ceph Manager守护进程还基于python的插件来管理和公开Ceph集群信息，包括基于Web的Ceph Manager Dashboard（WEB界面的管理）和 RESTFUL API（API方式获取ceph信息，与之前的ceph-rest-api功能一致）、Zabbix、Prometheus、Influx（这三个实现了ceph的数据收集、监控等功能）。高可用性通常至少需要两个管理器。
Ceph架构

RADOS
Ceph的底层是RADOS，RADOS本身也是分布式存储系统，CEPH所有的存储功能都是基于RADOS实现，Ceph的高可靠、高可拓展、高性能、高自动化都是由这一层来提供的，用户数据的存储最终也都是通过这一层来进行存储的，RADOS可以说就是Ceph的核心。
RADOS系统主要由两部分组成，分别是OSD和Monitor。
OSD： Object StorageDevice，提供存储资源。
Monitor：维护整个Ceph集群的全局状态。
LIBRADOS库
基于RADOS层的上一层是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。Ceph的上层应用调用本机上的librados API，再由后者通过socket与RADOS集群中的其他节点通信并完成各种操作。
三种存储类型
RADOSGW：对象存储接口，RADOSGW是一套基于当前流行的RESTFUL协议的网关，并且兼容S3和Swift。
RBD：是Ceph对外提供的块设备服务。
CEPH FS：是Ceph对外提供的文件系统服务

Ceph存储概念

存储数据与object的关系：
无论使用哪种存储方式（对象、块、挂载），当用户要将数据存储到Ceph集群时，存储数据都会被分割成多个object，每个object都有一个object id，每个object的大小是可以设置的，默认是4MB，object可以看成是Ceph存储的最小存储单元。
object与pg的关系：
由于object的数量很多，对象的size很小，在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址，速度都是很缓慢的，为了解决这些问题，ceph引入了归置组（Placcment Group即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]，很像我们高中数学学过的排列组合
存储池 pool
存储池(pool)：是对Ceph集群进行的逻辑划分，主要设置其中存储对象的权限、备份数目、PG数以及CRUSH规则等属性。

Pool是管理员自定义的命名空间，像其他的命名空间一样，用来隔离对象与PG。我们在调用API存储即使用对象存储时，需要指定对象要存储进哪一个POOL中。除了隔离数据，我们也可以分别对不同的POOL设置不同的优化策略，比如副本数、数据块及对象大小等。
Ceph数据存储过程
Ceph存储集群从客户端接收文件，每个文件都会被客户端切分成一个或多个对象，然后将这些对象进行分组，再根据一定的策略存储到集群的OSD节点中，其存储过程如图所示：

图中，对象的分发需要经过两个阶段的计算，才能得到存储该对象的OSD，然后将对象存储到OSD中对应的位置。
(1)对象到PG的映射。PG是对象的逻辑集合。PG是系统向OSD节点分发数据的基本单位，相同PG里的对象将被分发到相同的OSD节点中(一个主OSD节点多个备份OSD节点)。对象的PG是由对象ID号通过Hash算法，结合其他一些修正参数得到的。
(2)PG到相应的OSD的映射。RADOS系统利用相应的哈希算法根据系统当前的状态以及PG的ID号，将各个PG分发到OSD集群中。OSD集群是根据物理节点的容错区域(比如机架、机房等)来进行划分的。
正常IO流程图

步骤：

1. client 创建cluster handler（集群处理信息）。
2. client 读取配置文件。
3. client 连接上monitor，获取集群map信息。
4. client 读写io 根据crush map 算法请求对应的主osd数据节点。
5. 主osd数据节点同时写入另外两个副本节点数据。
6. 等待主节点以及另外两个副本节点写完数据状态。
7. 主节点及副本节点写入状态都成功后，返回给client，io写入完成。
   ceph生产环境推荐
   1、存储集群采用全万兆网络
   2、集群网络(不对外)与公共网络分离(使用不同网卡)
   3、mon、mds与osd分离部署在不同机器上
   4、journal推荐使用SSD,一般企业级IOPS可达40万以上
   5、OSD使用SATA亦可
   6、根据容量规划集群
   7、至强E5 2620 V3或以上cpu,64GB或更高内存
   8、最后，集群主机分散部署，避免机柜故障(电源、网络)