Ceph分布式存储核心概念以及架构原理（二）

Ceph分布式存储核心概念以及架构原理

1.Ceph分布式存储介绍

Ceph存储官方文档地址：https://docs.ceph.com/en/pacific/

Ceph是一个统一的分布式存储，支持对象存储、块存储以及文件存储，既可以通过API接口存储一些静态文件，也可以提供通过块存储映射一块裸磁盘到操作系统中进行分区格式化使用，还可以像NAS这种文件存储直接将一个目录挂在到服务器中进行使用。

Ceph的块存储与SAN存储相同，Ceph走的协议类型是IP-SAN。

Ceph的特点：

• 高可靠性，Ceph是分布式存储集群，副本数可以灵活控制，不会存在单点故障，并且多种故障场景下可以自动进行故障资源。
• 高扩展性，扩展灵活，随着节点的增加而线性增长。
• 开源免费，Ceph是开源社区的明星产品。
• 特性丰富，支持三种存储接口：对象存储、块存储、文件存储。

Ceph对象存储符合S3类型和Swift类型的API，并且还有自己的用户认证机制。

Ceph块存储最大可以支持到16EB的空间。

Ceph文件存储支持内核级别挂载和用户空间的挂载。

2.Ceph分布式存储架构

Ceph存储的对象存储、块存储、文件存储是根据不同的应用场景来配置的。

对象存储是通过Radosgw方式将数据写入到Ceph存储中的，支持S3和Swift风格的接口类型。

块存储是通过RBD的方式写入到Ceph存储中的，主要是对云主机的QEMU和KVM提供存储。

文件存储有两种方式分布式内核级别的客户端存储和用户空间FUSE的文件存储。

Ceph也可以使用原生的Librados库，支持c、c++、java、python、ruby、php等语言将数据写入到存储中。

Ceph是分布式存储，保证数据的一致性主要是通过RADOS来实现的。

RADOS的特点就是可靠性高，避免单点出现的问题，并且还支持健康检查机制，主动将监控数据上报给monitor，当RADOS故障时，还会将自身的数据进行迁移，可以做到自我管理。

Ceph是基于RADOS动态分布的算法来实现的分布式存储。

3.Ceph集群中核心组件以及作用

RADOS组件：

• RADOS组件（Reliable Autonomic Distributed Object Store 可靠、自动，分布式对象存储）是Ceph存储组件的基础，存储组件是在RADOS组件之上建立的，Ceph中的特性都是由RADOS组件提供。
• Ceph存储中的一切都以对象的方式存储，RADOS组件就负责存储这些对象，不需要考虑他们的数据类型。
• RADOS组件可以确保数据的一致性、可靠性，包括数据的复制、故障监测和恢复，数据节点的迁移和平衡分配。
• RADOS由大连的存储设备和节点集群组成，RADOS采用C++语言开发。

LIBRADOS组件：

• LIBRADOS（基础库，又叫做RADOS库）主要功能是对RADOS进行抽象和封装，并向上提供API，一边直接基于RADOS进行应用开发。
• RADOS是管理存储的系统，LIBRADOS是实现以API形式操作存储系统的功能，支持C++、C、JAVA、Python、Ruby、PHP。
• RADOS组件是RBD、RGW等服务的基础组件。

RADOSGW组件：

• RADOSGW(CEPH对象网关,也叫做RADOS网关RGW) 简称RGW，RGW提供了S3和Swift风格兼容的RESTful API的网关组件，支持多租户的身份验证功能，相对于LIBRADOS，RGW提供的API更加抽象，能在S3和Swift场景下更加便捷的管理。

RBD组件：

• RBD（Reliable Block Device）组件主要是通过块存储类型的一个设备接口，对外提供块存储服务，提供的块存储服务可以形成一个裸磁盘，提供格式化、映射的功能，挂载到服务器中。
• 常用于虚拟化场景下创建volume、云硬盘等，目前RedHat已经将RBD的驱动集成到KVM/QEMU中。

CephFS组件：

• CephFS（Ceph的文件系统）是一种兼容POSIX的分布式文件系统，使用MDS作为守护进程，libcephfs拥有对本地Linux内核驱动程序支持，可以使用mount命令进行挂载操作，能与支持CIFS和SMB协议。

4.Ceph RADOS中的核心组件

RADOS是Ceph存储系统中的核心组件，Ceph的所有优秀特性都是由RADOS提供的，在RADOS中最核心的组件的就是Monitor和OSD。

4.1.Ceph Monitor监控组件

Ceph Monitor是负责监控整个集群的运行状态，Monitor组件非常关键，需要确保它的高可靠性，客户端通过Monitor组件就可以获取整个集群的状态，可以通过Monitor在集群中读取和写入数据。

在Ceph集群中，为了实现Monitor组件的高可用性，通常会部署成一个集群模式，Monitor集群通常以一个Leader节点和两个Slave节点组成，当Leader故障后，通过选举的方式产生新的Leader，因此集群节点数奇数组成，最少三个节点。

Monitor组件中的信息都是集群各节点的守护进程来上报的，包含了各个节点之间的状态以及集群的配置信息，当集群中某个节点产生了异常，会根据Monitor的监控信息，自动将该节点中的数据迁移至正常的节点中。

Monitor组件会保存集群状态的Cluster Map一个信息表，包含以下几种信息表：

• Monitor Map：核心信息表，记录了Monitor集群各节点的信息以及各节点的ID。
• OSD Map：记录OS集群各节点的信息以及各节点的ID。
• PG Map：可以理解成是数据存储的载体，类似于一个在OSD中的目录，所有该OSD下的数据都会存储在这个PG目录中，这样做的目的是为了当OSD故障时，可以很方便的将数据迁移到其他OSD中，迁移一个目录比迁移一大堆文件消耗的性能要低。
  • PG是在创建Ceph存储池的时候指定的，同时也与OSD副本数有关系，比如3个副本节点就会有3个相同的PG存放在不同的OSD中，每一个副本都会有一个PG。
  • PG的使用情况也反映了当前集群的存储状态，不同的中泰也反映了集群当前的健康状态。
• CRUSH Map：包含集群存储设备OSD的信息以及存储数据便利的层次结构，包括OSD的设备列表，可以将数据写入到不同的OSD存储中，对应的每个OSD都会有副本节点，保障数据的高可用性，也可以将按照机柜分类，每一个OSD在不同的机柜中，保障数据安全性。
• MDS Map：只有在使用Ceph FS文件存储时才会使用MDS，MDS是Ceph FS的元数据服务，主要用于记录在存储中每个文件的元数据信息，在读取数据时，首先会从MDS中读取该文件的Metadata元数据信息，从而知道从哪里读取和写入文件，集群中至少要包含一个MDS服务。

4.2.Ceph OSD组件

OSD组件是Ceph集群中真正存放数据的组件，OSD会定期将自身的状态上报给Monitor组件，无论是OSD故障还是OSD故障恢复等等，都会将这种状态上报给Monitor组件，同样Monitor组件也会定期检测OSD组件，当检测到OSD异常无法连接时，就会将该OSD中的数据自动重新分配，做到一个自我修复，确保数据的完整性。

客户端在使用Ceph集群时，首先会从Monitor中拿到集群的一个信息表，然后通过CRUSH算法计算出数据要存放在哪一个OSD中，客户端就可以直接读写OSD中的数据，不需要连接到Monitor在进行读取OSD中的数据。

当集群中节点越来越多时，Ceph的OSD也会越来越多，性能也会呈直线上升。

一般来说一个Ceph节点就是一个OSD存储。

OSD需要做数据备份，也就是OSD副本。

在Ceph中，一个文件会被拆分成多个Object对象，这些对象会存储在OSD中，每个OSD都会有副本节点，最终数据写入到磁盘中。

每一个Object对象都有三种信息：Object ID、Binary Date、Metadata。每一个Object都会自己的一份数据信息和Metadata元数据信息。

5.Ceph分布式存储数据写入流程

如下图所示，主要分为四层：File—>Objects—>PGS—>OSDS。

File：想要存储在Ceph中的具体文件，面向用户的直观操作对象。

Object：面向RADOS的对象，一个文件存储在Ceph中，这个文件首先会被拆分成多个Object对象，Object也是Ceph中的基本单位，Object的大小由RADOS指定，通常为2M或者4M，也就是说一个100M的文件，存储到Ceph的OSD后，会被拆分成25个对象文件。

PG：扩及概念，可以理解成是装载Object的容器，每一个OSD中都有一个PG，可以更好的分配和定位数据。

OSD：数据最后存储的位置。

一个文件写入到Ceph OSD的流程：

首先一个文件会被拆分成多个Object对象文件，一个Object文件大小为4M，每一个Object文件都会有一个oid进行记录，然后通过hash算法和mask掩码计算出Object文件要存储在哪一个PG中，存储到PG之后，再通过CRUSH计算出数据最终写入的OSD节点，会随机写入到集群中不同的OSD节点上。

PG和Object是一对多的关系，一个PG里面会有若干个Object，但是一个Object只能存放在一个PG中。

PG与OSD是多堆多的关系，一个PG可以被映射到多个OSD中，大于等于2就是副本机制，每个OSD会承载大量的PG。

下面细化每一个步流程的详细细节：

File—>Object：

在这一步中文件会被切分成多个Object，每个Object都有唯一的id也就是oid，这个oid是根据文件名称得到的，如图中所示，ino是文件的唯一id（比如filename+timestamp），ono就是切分后某一个Object的序号（例如1,2,3,4,5），根据该文件的大小就可以得到一系列的oid号。

将文件切分为大小一致的object可以被RADOS高效管理，而且可以将对单一file的处理变成并行化处理提高处理效率。

Object—>PG

这一步中主要是将拆分的Object映射到一个PG中去，实现的方式就是对oid进行hash计算，然后得出某个PG的pid，mask掩码的值是PG的总数量-1。

PG—>OSD

最后一步就是将PG中的Object存储在实际的OSD中，通过CRUSH算法根据pgid计算出多个OSD存储设备，数据都会均匀分布。

6.Ceph分布式集群架构原理图

Ceph存储依托于RADOS之上，数据真正存储在OSD中，OSD会定期上报信息到Monitor集群，Monitor集群也会定期检测OSD的运行状态，当OSD出现故障时，会将异常OSD中的数据迁移到正常的OSD中，一个数据文件会拆分成多个Object对象，这些Object对象不会直接存储在OSD中，而是存放在PG中，PG相当于OSD中的一个目录，存放Object的载体。

客户端根据需求使用不同存储类别，数据首先被拆分成多个Object对象，然后存储在PG中，PG实际上是OSD的一个目录，数据还是在OSD中，客户端可以直接从OSD中读取、写入数据。

Ceph集群的总存储容量为：所有OSD关联硬盘的总大小/3，因为OSD有副本节点，一份数据通常会写入到3个副本中。