ceph分布式存储简介

一、Ceph简介：

什么是分布式存储？

　　我在一个环境当中，有很多很多的服务器，服务器上也有它自己很多的硬盘，我通过软件的形式把若干服务器都收集起来，部署成一个软件，在这个逻辑的软件里可以同时看到我若干服务器的磁盘的空间，这个逻辑的软件对外就像是一个整体一样，这个整体叫storage spool，用户呢有一天想用这个空间了，用户直接去对应这个存储池提供的接口，这用的话，用户保存一个文件，实际上保存在若干个服务器里，文件会随机存到第一个服务器的第一块硬盘里，下一次就可能存到第二个服务器的第三块硬盘里。它会把文件进行打散，分成不同的小块，每块存放的位置可能是不同的服务器上的不同硬盘里。

　　分布式存储还可以对文件进行安全备份，我这个文件存在后端的服务器里，可以保存多份，多份叫副本也可以叫镜像。就是说对我打散的每块文件做一个镜像在保存在不同服务器上的不同硬盘里，这样，如果后端有服务器宕掉了，我的文件还是完整的。ceph就可以做到这么一种功能。

Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。
    Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

官网

https://ceph.com/

官方文档

http://docs.ceph.com/docs/master/#

二、Ceph特点：

高性能：
a.摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架、感知等。
c.能够支持上千个存储节点的规模，支持TB到PB级的数据。

高可用性：
a.副本数可以灵活控制。（就是说让副本保存份数可以多份，在正常的生产环境是保存3副本）
b.支持故障域分隔，数据强一致性。
c.多种故障场景自动进行修复自愈。
d.没有单点故障，自动管理。（假如说我这个文件设置的是3副本，如果后端服务器坏掉，副本数不够3，它会自动补充至3副本）

高可扩展性：
a.去中心化。
b.扩展灵活。
c.随着节点增加而线性增长。

特性丰富：
a.　　支持三种存储接口：块存储（我得到的是硬盘）、文件存储（目录）、对象存储（有可能给你对接的是一个挂载的目录，但是后端怎么去存的，它会把数据打散，采用键值对形式存储）。
b.支持自定义接口，支持多种语言驱动。

三、Ceph应用场景：

　　Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

Ceph是一个高性能、可扩容的分布式存储系统，它提供三大功能：

对象存储（RADOSGW）：提供RESTful接口，也提供多种编程语言绑定。兼容S3（是AWS里的对象存储）、Swift（是openstack里的对象存储）；

块存储（RDB）：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制；

文件系统（CephFS）：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储；

什么是块存储/对象存储/文件系统存储？
1.对象存储：
　　也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL 和其他扩展，代表主要有
Swift 、S3 以及 Gluster 等；
2.块存储：
　　这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统，还有 Ceph 的 RBD（RBD是Ceph面向块存储的接口）。在常见的存储中 DAS、SAN 提供的也是块存储；
3.文件系统存储：
　　通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的，但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS (CephFS是Ceph面向文件存储的接口)，但是有时候又会把 GlusterFS ，HDFS 这种非POSIX接口的类文件存储接口归入此类。当然 NFS、NAS也是属于文件系统存储；

四、Ceph核心组件：

（1）Monitors（管理服务）：监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump"查看 monitor map。
（2）MDS（Metadata
Server）：Ceph 元数据，主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。

（3）OSD：即对象存储守护程序，但是它并非针对对象存储。是物理磁盘驱动器，将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回（Backfilling）、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候，建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor
（4）RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。

（5）librados：librados库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。
（6）RADOSGW：网关接口，提供对象存储服务。它使用librgw和librados来实现允许应用程序与Ceph对象存储建立连接。并且提供S3 和 Swift 兼容的RESTful API接口。
（7）RBD：块设备，它能够自动精简配置并可调整大小，而且将数据分散存储在多个OSD上。
（8）CephFS：Ceph文件系统，与POSIX兼容的文件系统，基于librados封装原生接口。

五、Ceph存储系统的逻辑层次结构：

六、RADOS的系统逻辑结构：

七、Ceph 数据存储过程：

一个文件在ceph里怎么做的读取和存储？

　　首先用户把一个文件放到ceph集群后，先把文件进行分割，分割为等大小的小块，小块叫object，让后这些小块跟据一定算法跟规律，算法是哈希算法，放置到PG组里，就是归置组，然后再把归置组放到OSD里面。

　　无论使用哪种存储方式（对象、块、文件系统），存储的数据都会被切分成Objects。Objects size大小可以由管理员调整，通常为2M或4M。每个对象都会有一个唯一的OID，由ino与ono生成，虽然这些名词看上去很复杂，其实相当简单。

ino：即是文件的File ID，用于在全局唯一标识每一个文件
ono：则是分片的编号

比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。

　　File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。
　　Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。
　　PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。
　　OSD —— 即object storage device，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。

基于上述定义，便可以对寻址流程进行解释了。具体而言， Ceph中的寻址至少要经历以下三次映射：
（1）File -> object映射
（2）Object -> PG映射，hash(oid) & mask -> pgid
（3）PG -> OSD映射，CRUSH算法
　　CRUSH，Controlled Replication
Under Scalable Hashing，它表示数据存储的分布式选择算法， ceph 的高性能/高可用就是采用这种算法实现。CRUSH 算法取代了在元数据表中为每个客户端请求进行查找，它通过计算系统中数据应该被写入或读出的位置。CRUSH能够感知基础架构，能够理解基础设施各个部件之间的关系。并CRUSH保存数据的多个副本，这样即使一个故障域的几个组件都出现故障，数据依然可用。CRUSH 算是使得 ceph 实现了自我管理和自我修复。

RADOS 分布式存储相较于传统分布式存储的优势在于:
　　1. 将文件映射到object后，利用Cluster Map 通过CRUSH 计算而不是查找表方式定位文件数据存储到存储设备的具体位置。优化了传统文件到块的映射和Block MAp的管理。
　　2. RADOS充分利用OSD的智能特点，将部分任务授权给OSD，最大程度地实现可扩展

八、Ceph IO流程及数据分布：

（1）正常IO流程图：

　　步骤：
　　  1. client 创建cluster
handler。
　　  2. client 读取配置文件。
　　  3. client 连接上monitor，获取集群map信息。
　　  4. client 读写io 根据crshmap 算法请求对应的主osd数据节点。
　　  5. 主osd数据节点同时写入另外两个副本节点数据。
　　  6. 等待主节点以及另外两个副本节点写完数据状态。
　　  7. 主节点及副本节点写入状态都成功后，返回给client，io写入完成。
（2）新主IO流程图：

说明：如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据，那么 PG 上的
I/O 无法进行，怎样工作的呢？
　　新主IO流程步骤：
　　  1. client连接monitor获取集群map信息。
　　  2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。
　　  3. 临时主osd2会把数据全量同步给新主osd1。
　　  4. client IO读写直接连接临时主osd2进行读写。
　　  5. osd2收到读写io，同时写入另外两副本节点。
　　  6. 等待osd2以及另外两副本写入成功。
　　  7. osd2三份数据都写入成功返回给client,
此时client io读写完毕。
　　  8. 如果osd1数据同步完毕，临时主osd2会交出主角色。
　　  9. osd1成为主节点，osd2变成副本。

九、Ceph Pool和PG分布情况：

　　pool：是ceph存储数据时的逻辑分区，它起到namespace的作用。每个pool包含一定数量(可配置) 的PG。PG里的对象被映射到不同的Object上。pool是分布到整个集群的。 pool可以做故障隔离域，根据不同的用户场景不统一进行隔离。