Kubernetes Ceph 工作原理详解

理解不了太多请直接看1.6

一、Ceph概述

这里简单的说一下相关的组件，只是简单介绍

Ceph 介绍

1. ceph是一个Linux PB级分布式文件系统，Linux持续不断进军可扩展计算空间，特别是可扩展存储空间。Ceph加入到Linux中令人印象深刻的文件系统备选行列，它是一个分布式文件系统，能够在维护POSIX兼容性的同时加入了复制和容错功能。
2. ceph 可以提供 对象存储RODOSGW、块存储RBD、文件系统存储Ceph FS 三种功能，以此满足不同场景的应用需求
3. 优点： 可轻松扩展到PB容量，对多种工作负载的高性能(每秒输入/输出操作[IOPS]和带宽),高可靠性。Ceph开发了一些非常有趣的概念(例如，动态元数据分区，数据分布和复制)。ceph的设计还保护单一点的故障容错功能，它假设大规模(PB级别存储)存储故障是常见现象而不是例外情况。它的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负载，提供最佳性能的能力。它利用POSIX的兼容性完成所有这些任务，允许它对当前依赖POSIX语义

自下向上，可以将Ceph系统分为四个层次 (1) 基础存储系统RADOS(Reliable，Autonomic,Distributed,Object Store,即可靠、自动化、分布式的对象存储) 顾名思义，这一层本身就是一个完整的对象对象存储系统，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。因此，理解RADOS是理解Ceph的关键与基础

(2)基础库librados 这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS(而不是整个Ceph)进行应用开发。需要注意的是RADOS是一个对象存储系统。因此，librados实现的API也只是针对对象存储功能的

RADOS采用C++开发，所提供的原生librados API包括C和C++两种，物理上，librados和基于其上开发的应用位于同一台机器，因而也被成为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

(3)高层应用接口 这一层包括了三个部分：RADOS GWRADOS Gateway 、RBD Reliable Block Device和Ceph FS Ceph File System其作用是在librados库的基础上提供抽象层次更高的，更便于应用或客户端使用的上层接口

其中,RADOS GW是一个提供Amazon S3和Swift(内置大容量硬盘的分布式服务器)兼容的RESTful API的Gateway，以提供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更好，但功能则不如librados强大，应为开发者针对自己的需求选择使用

RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建Volume。目前，Red Hat 已经将RBD驱动集成在KVM/QEMU中，以提供虚拟机访问性能

Ceph FS是一个POSIX兼容的分布式文件系统,Ceph提供了POSIX接口，用户可以直接通过客户端挂载使用。它是内核态的程序，所以无需调用用户空间的librados库。通过内核中的net模块来和Rados进行交互

1.1 RADOS逻辑架构

在使用RADOS系统时，大量的客户端程序通过OSD或者Monitor的交互获取cluster map，然后再本地进行计算，得出对象的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。 只要我们保证cluster map不频繁更新，则客户端显然可以不依赖任何元数据服务器，不进行任何查表操作，便完成数据访问流程。在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种：OSD出现故障，或者RADOS规模扩大。而正常应用场景下，这俩种事件发生的频率显然远远低于客户端对数据进行访问的频率。

1.2 OSD逻辑结构

根据定义，OSD可以被抽象为两个组成部分，即系统部分和守护进程(OSD daemon)部分

OSD的系统部分本质上就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。

由于这么小的规模的x86架构服务器并不实用,因而实际应用中通常将多个OSD集中部署在一台更大规模的服务器上。在选择系统配件时，应当能够保证每个OSD占用一定的计算能力、一定量的内存和一块硬盘。同时，应当保证该服务器具备足够的网络带宽

每个OSD拥有一个自己的OSD deamon。这个deamon负责完成OSD所有逻辑功能，包括与monitor和其他OSD(事实上是其他OSD的daemon)通信以维护更新系统状态，与其他OSD共同完成数据的存储和维护，与client通信完成各种数据对象操作等

RADOS集群主要两种节点：一种是为数众多的、负责完成数据存储和维护功能的OSD(Object Storage Device),另一种则是若干负责完成系统状态监测和维护的monitor。OSD和monitor之间相互传输节点状态信息，共同得出系统的总工作状态，并形成一个全局系统状态记录数据结构，即所谓的cluster nao。这个数据结构与RADOS提供的特定的算法相配合，便实现了Ceph无需查表，算算就好的核心机制以及若干优秀特性。

1.2 Ceph 基本组件

1.OSD 用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他OSD守护进程发送心跳，然后向Mon提供一些监控信息。 当Ceph存储集群设定数据有两个副本时(一共存2份),则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态

2.MSD 为Ceph文件提供元数据计算、缓存与同步。在Ceph中，元数据也是存储在osd节点中的，马上到！类似于元数据的代理缓存服务器。msd进程并不是必须的进程，只有使用Cephfs时，才需要配置msd

3.Monitior 监控整个集群的状态，维护集群的cluster MAP二进制表，保证集群数据的一致性。Cluster MAP描述了对象存储的物理位置，以及将一个设备聚合到服务位置的桶列表。

1.3 Ceph存储过程 (Ceph IO算法流程)

1.File----此处的File就是用户要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个File也就是对应于应用中的对象，也就是用户直接操作的对象

2.Objects----此处的Objects是RADOS所看到的对象。Object与上面提到的File的区别是，Object的最大Size由RADOS限定(通常为2MB或4MB),以便实现底层存储的组织管理。因此，当上层应用向RADOS存储size很大的file时，需要将file切分统一大小的一系列object(最后一个的大小可以不同)进行存储。

3.PG (Placement Group)----顾名思义，PG的用途是对object的存储进行组织和位置映射。一个PG负责若干个object(可以为数前个甚至更多)，但一个object只能被映射到一个PG中，即，PG和object之间是一对多映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是多对多映射关系。如果用于生产环境，OSD至少为3.一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均衡性问题。

4.OSD ----即object storage device 需要说明的是OSD的数量事实上也关系到系统的数据分布均衡性，因此数量不能太少。

5.Failure domain ----这个概念在论文中并没有进行定义，此处不过多解释

基于上述定义，Ceph中的寻址至少要经历下面三次映射✌️

1️⃣ File->object 这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分。这种切分的好处有2点。一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为多个object实施并行化处理

每一个切分后产生的object将获得唯一的oid，即object id。其产生方式也是线性映射，图中ino是待操作file的元数据，可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该file id之后得到的。

举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到oid就依次为filename0、filename1和filename2. 这里隐含的问题是，ino的唯一性必须得到保障，否则后续无法正常进行

2️⃣ Object->PG映射 在file映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去

计算公式如下

hash(oid) & mask -> pgid

由此可见，其计算由两步组成。首先是使用Ceph系统指定的静态哈希函数计算oid的哈希值，将oid映射成一个近似均衡分布的伪随机值。然后，将这个随机值和mask按位相与，得到最终的PG序号(pgid)。根据RADOS的设计，给定PG的总数为m(m应该是为2的整数)，则mask的值为-1。因此，哈希值计算和操作结果事实上是从所有m个PG中近似均匀的随机选择一个。基于这个机制，当有大量的object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的soze相同，因而这一映射最终保证了，各个PG中存储的object的总数据量近似均匀

只有当object和PG的数量较多时，这种伪随机关系的近似均匀性才能成立，Ceph的数据存储均匀性才有保证。为保证大量成立，以方便，object的最大size应该被合理配置，以使得同样数量的file能够被切分更多的object；另一方面，Ceph推荐PG总数应该为OSD总数的数百倍，以保证有足够数量的PG可供映射。

3️⃣PG->OSD映射 第三次映射就是作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD,RADOS采用一个名为CRUSH的算法，将pgid带入其中，然后得到一共n个OSD。这n个OSD即共同负责存储和维护一个PG中所有的object。前面已经描述，n的数值可以根据实际应用中对于可靠性的需求而配置，生产环境通常为3.具体到每个OSD。则由其上的OSD daemon负责执行映射到本地的object在本地文件系统中的存储、访问、元数据维护等操作

和object->PG映射中采用的哈希算法不同，这个CCRUSH算法的结果不是绝对不变的，而是受到其他因素的影响。其影响因素主要有二点：

一是当前系统状态，也就是上文逻辑结构中曾经提及的cluster map。当系统中的OSD状态、数量发生变化时，cluster map可能发生变化，而这种变化会影响到PG与OSD之间的映射

二是存储策略配置。这里的策略主要与安全相关，利用策略配置，系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上，从而进一步改善存储的可靠性。

因此，只有在系统状态cluster map和存储策略都不发生变化的时候，PG和OSD之间的映射关系才是稳定不变的。在实际使用中，策略已经配置通常不会改变。而系统状态的改变或者是由于设备损坏，或者是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持。因而，即便PG与OSD之间的映射关系发生了变化，也并不会对应用造成困扰。事实上，Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性，Ceph可以将一个PG根据需要动态迁移到不同的OSD组合上，从而自动化地实现高可靠性、数据分布性等。

至此为止，Ceph通过三次映射，完成了从file到object、PG和OSD整个映射过程。通过整个过程可以看到没有任何的全局性查表操作需求。至于唯一的全局性数据结构cluster map的维护和操作都是轻量级的，不会对系统的可扩展性、性能等因素造成不良的影响

一个可能出现困惑的问题：为什么需要同时设计出第二次和第三次映射？难道不重复吗

如果没有PG这一层映射，通过算法将object直接映射到一组OSD上。如果这种算法是某种固定映射的哈希算法，则意味着一个object将被固定在一组OSD上，当其中一个或多个OSD损坏时，object无法被自动迁移至其他OSD上(因为映射函数不允许)，当系统为了扩容新增了OSD时，object也无法被re-balance到新的OSD上(同样因为函数不允许）这些限制都违背了Ceph系统的高可靠性、高自动化的设计初衷

例如，在Ceph的现有机制中，一个OSD平时需要和与其共同承载一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个OSD上约承载数百个PG，每个PG内通常有3个OSD，因此，一个OSD大约需要进行数百至数千次OSD信息交换

然后，如果没有PG的存在，则一个OSD需要和与其共同承载同一个object的其他OSD交换信息。由于每个OSD上承载的object很可能高达数百万个，因此同样长度的一段时间内，一个OSD大约需要进行的OSD间信息交换将暴涨至数百万乃至数千万次。而这种状态维护成本显然过高

总结：引入PG的好处有两种，一方面实现了object和OSD之间的动态映射，从而为Ceph的可靠性、自动化性等特征的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。

1.4 Ceph集群

前面说过，monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client 使用cluster map进行数据的寻址。

在集群中，各个monitor的功能总体上是一样的，其相互间的关系可以简单理解为主从备份关系。monitor并不主动轮询各个OSD的当前状态。正相反，OSD需要向monitor上报信息状态。常见的上报情况有两种：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息，monitor将更新cluster map的信息并加以扩散。

Cluster map包含如下内容 命令:ceph -s （1) Eposh 即版本号。Cluster map的epoch是一个单调递增序列。Epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单的通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态。在进行后续状态

(2) health 集群内部健康状态，显示这台服务器在集群内部的状态

(3) monmap 各个OSD的网络地址

(4) osdmap 各个OSD的状态。OSD状态分为两个维度：up或者down (表示OSD是否正常工作)，in或者out (表示OSD是否在至少一个PG中)。因此，对于任意一个OSD，共有四种可能的状态

(5) pgmap 集群中pg、pools、磁盘大小等信息

1.5 Ceph特点

介绍这么ceph的信息，我们这里做一个总结

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

• 高可用性 a.副本数可以灵活控制。 b.支持故障域分隔，数据强一致性。 c.多种故障场景自动进行修复自愈。 d.没有单点故障，自动管理。

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

• 特性丰富 a.支持三种存储接口：块存储、文件存储、对象存储 b.支持自定义接口，支持多种语言驱动

1.6 Ceph架构

Ceph支持三种接口

• Object:有原生的API，并且也兼容Swift和S3的api
• Block:支持精简配置、快照和克隆
• File:Posix接口、支持快照

1.7 Ceph核心组件及概念✌️✌️

二、三种存储类型

2.1 块存储 rbd

典型设备：磁盘阵列，硬盘 主要是将裸磁盘空间映射给主机使用的

优点

• 通过Raid与LVM等手段，对数据提供了保护
• 多块廉价的硬盘组合起来，提高容量
• 多块磁盘组合出来的逻辑盘，提高读写效率

缺点

• 采用SAN架构组网时，光纤交换机，造价成本高
• 主机之间无法共享数据

使用场景

• docker容器、虚拟机磁盘存储分配
• 日志存储
• 文件存储
• 等等....

2.2 文件存储 fs

典型设备：FTP、NFS服务器 为了克服块存储文件无法共享的问题，所以有了文件存储。在服务器上架设FTP与NFS服务，就是文件存储

优点

• 造价低，随便一台机器就可以了
• 方便文件共享

缺点

• 读写速度低
• 传输速度慢

使用场景

• 日志存储
• 有目录结构的文件存储

2.3 对象存储 rgw

典型设备：内置大容量硬盘的分布式服务器(swift、s3) 多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。

优点

• 具备块存储的读写高速
• 具备文件存储的共享等特性

使用场景 (适合更新变动比较少的数据)

• 图片存储
• 视频存储

三、Ceph IO流程及数据发布

3.1 正常io流程图

解释：

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

3.2 新主io流程图

如果有新加入的OSD1取代了原有的OSD4成为Primary OSD，由于OSD1上未创建PG，不存在数据，那么PG上的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变成副本

3.3 Ceph IO算法流程

在1.3Ceph存储过程 (Ceph IO算法流程)中我们已经详细介绍了，这里只是简单过一下

1.File用户需要读写的文件。 File->映射成Object

• a.ino（File的元数据，File的唯一ID）
• b.ono (File切分产生的某个Object的序号，默认以4M切分一个块大小
• c.oid （object id：ino+one）

2.Object是RADOS需要的对象。Ceph指定一个静态的hash函数计算oid的值，将oid映射成一个近似均匀分布的伪随机值，然后和mask按位相与，得到pgid。 Object->映射PG

• a.bash (oid) & mask ->pgid
• b.mask=PG总数m(m为2的整数幂)-1

3.PG (Placement Group)用途是对object的存储进行组织和位置映射（类似于Redis cluster里面的slot的概念）一个PG里面会有很多object。采用CRUSH，将pgid代入其中，然后得到一组OSD。PG->OSD映射

• a.CRUSH（pgid）->（osd1,osd2,osd3）

3.4 Ceph RBD IO 流程 & Ceph RBD IO框架图

流程 1.客户端创建一个pool，需要为这个pool指定pg的数量 2.创建pool/image rdb设备进行挂载 3.用户写入的数据进行切块，每个块的大小默认为4M，并且每个块都有一个名字，名字就是object+序号 4.将每个object通过pg进行副本位置的分配 5.pg根据cursh算法会寻找3个osd，把这个object分别保存在这三个osd上 6.osd上实际是把底层disk进行了格式化操作，一般部署工具会将它格式化为xfs文件系统 7.object的存储就变成了存储一个文rbd0.object1.file

Ceph RBD IO框架图

客户端写数据OSD过程

1.采用的是librados的形式，使用librbd创建一个块设备，向这个块设备中写入数据 2.在客户端本地通过调用librados接口，然后经过pool、rdb、pg进行层层映射，在PG这一层，可以知道数据保存在哪3个OSD上，这3个OSD分为主从的关系 3.客户端primay OSD简历SOCKET通信，将要写入的数据传给primary OSD，由primary OSD再讲数据发送给其他replica OSD数据节点

3.5 Ceph Pool和PG分布情况

说明：

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

Ceph数据扩容PG分布

• 现状3个OSD，4个PG
• 扩容到4个OSD，4个PG

现状 扩容后

每个OSD上分布很多PG，并且每个PG会自动散落在不同的OSD上。如果扩容那么相应的PG会进行迁移到新的OSD上，保证PG数量的均衡。

3.6 Ceph 心跳机制

1.心跳介绍 心跳是用于节点间检测对方是否故障的，以便及时发现故障节点进入相应的故障处理流程。

问题

• 故障时间和心跳报文带来的负载之间做权衡
• 心跳频率太高则过多的心跳会影响系统性能。
• 心跳频率过低则会延长发现故障点的时间，从而影响系统的可用性。

故障检测策略优点

• 及时：节点发生异常如宕机或网络中断时，集群可以在可接受的时间范围内感知
• 适当的压力：包括对节点的压力，和对网络的压力
• 容忍网络抖动：网络偶尔延迟
• 扩散机制：节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。

2.心跳检测 OSD节点会监听public、cluster、front和back四个端口

• public端口：监听来自Monitor和Client的连接
• cluster端口：监听来自OSD Peer的连接
• front端口：供客户端连接集群使用的网卡，这里临时给集群内部之间进行心跳
• back端口：供集群内部使用的网卡。集群内部之间进行心跳
• hbclient：发送ping心跳的messenger

3.Ceph OSD之间互相心跳检测

1).同一个PG内OSD互相心跳，他们互相发送PING/PONG信息。 2).每隔6s检测一次 (实际会在这个基础上加上一个随机时间来避免峰值) 3).20s没有检测到心跳回复，加入failure队列 (失败)

4.Ceph OSD与Mon心跳检测

OSD报告给Monitor

• OSD发生问题时 (比如故障、PG变更)
• 自身启动5秒内

• OSD周期性的上报给Monito 1️⃣ OSD检查failure_queue中的伙伴OSD失败信息 2️⃣ 向Monitor发送失效报告，并将失败信息加入failure_pending队列，然后将其从failure_queue移除 3️⃣ 收到来自failure_queue或者failure_pending中的OSD的心跳时，将其从两个队列中移除，并告知Monitor取消之前失效的报告 4️⃣ 当发生与Monitor网络重连时，将会failure_pending中的错误报告加回到failure_queue中，并再次发送给Monitor

• Monitor 统计下线OSD （1） Monitor收集来自OSD的伙伴无效报告 （2）当错误报告指向的OSD失效超过一定阈值，且有足够多的OSD报告其失效时，将该OSD下线

针对Ceph总结

• 及时：伙伴OSD可以在秒级发现节点失效并汇报Monitor，并在几分钟内由Monitor将失效OSD下线。

• 适当的压力：由于有伙伴OSD汇报机制，Monitor与OSD之间的心跳统计更像是一种保险措施，因此OSD向Monitor发送心跳的间隔可以长达600秒，Monitor的检测阈值也可以长达900秒。Ceph实际上是将故障检测过程中中心节点的压力分散到所有的OSD上，以此提高中心节点Monitor的可靠性，进而提高整个集群的可扩展性。

• 容忍网络抖动：Monitor收到OSD对其伙伴OSD的汇报后，并没有马上将目标OSD下线，而是周期性的等待几个条件：

1.目标OSD的失效时间大于通过固定量osd_heartbeat_grace和历史网络条件动态确定的阈值。 2.来自不同主机的汇报达到mon_osd_min_down_reporters。 3.满足前两个条件前失效汇报没有被源OSD取消。

• 扩散：作为中心节点的Monitor并没有在更新OSDMap后尝试广播通知所有的OSD和Client，而是惰性的等待OSD和Client来获取。以此来减少Monitor压力并简化交互逻辑。

文章参考： Ceph 浅析 史上最全的Ceph介绍、原理、架构

😔😳😘😭