1.1 基础知识
1.1.1 存储基础
学习目标
这一节，我们从 基础知识、文件系统、小结 三个方面来学习。
基础知识
存储基础
我们知道，对于一个计算机设备来说，其存储功能是非常重要的，也就是说，任何一台电脑上，必须包含一个设备--磁盘。这个磁盘就是用于数据存储的目的的。
常见的存储设备接口：
DAS设备：IDE、SATA、SCSI、SAS、USB
无论是那种接口，他都是存储设备驱动下的磁盘设备，而磁盘设备其实就是一种存储，这种存储是直接接入到主板总线上去的。
- 基于数据块来进行访问
- 基于服务器方式实现互联访问，操作简单、成本低。
NAS设备：NFS、CIFS
几乎所有的网络存储设备基本上都是以文件系统样式进行使用，无法进一步格式化操作。
- 基于文件系统方式访问
- 没有网络区域限制，支持多种协议操作文件。
SAN:scsi协议、FC SAN、iSCSI
基于SAN方式提供给客户端操作系统的是一种块设备接口，所以这些设备间主要是通过scsi协议来完成正常的通信。
scsi的结构类似于TCP/IP协议，也有很多层，但是scsi协议主要是用来进行存储数据操作的。既然是分层方式实现的，那就是说，有部分层可以被替代。比如将物理层基于FC方式来实现，就形成了FCSAN，如果基于以太网方式来传递数据，就形成了iSCSI模式。
- 基于数据块来实现访问
- 不受服务器约束，通过存储池实现资源的高效利用，扩展性好
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iCRWOy9s-1667795960422)(image/image-20220923150326956.png)]
存储使用
对于存储的使用，我们需要借助于文件系统的方式来实现，而存储在使用前往往需要进行格式化。
文件系统
简介
文件系统的基本数据单位是文件，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同，就会形成不同的文件系统。 Linux 文件系统会为每个文件分配两个数据结构：索引节点(index node)和目录项(directory entry)，它们主要用来记录文件的元信息和目录层次结构。
索引节点
- 用来记录文件的元信息，比如 inode 编号、文件大小、访问权限、创建时间、等信息。
- 索引节点是文件的唯一标识，它们之间一一对应，也同样都会被存储在硬盘中，所以索引节点同样占用磁盘空间。
- 用户查找的时候，会根据inode的信息，找到对应的数据块，我们可以将inode理解为数据块的路由信息。
目录项
- 用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，形成目录结构
- 它与索引节点不同，目录项是由内核维护的一个数据结构，不存放于磁盘，而是缓存在内存。
- 目录项和索引节点的关系是多对一
数据存储
数据块
磁盘读写的最小单位是扇区，扇区的大小只有 512B 大小，文件系统把多个扇区组成了一个逻辑块，每次读写的最小单位就是逻辑块（数据块），Linux 中的逻辑块大小为 4KB，也就是一次性读写 8 个扇区，这将大大提高了磁盘的读写的效率。
磁盘想要被文件系统使用，需要进行格式化，此时磁盘会被分成三个存储区域
- 超级块，用来存储文件系统的详细信息，比如块个数、块大小、空闲块等等。
- 索引节点区，用来存储索引节点；
- 数据块区，用来存储文件或目录数据；
存储应用的基本方式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VoJ6JEct-1667795960423)(image/1636079494896.png)]
为了加速文件的访问，通常会把相关信息加载到内存中，但是考虑到内存的容量限制，它们加载进内存的时机是不同的：
超级块：当文件系统挂载时进入内存；
索引节点区：当文件被访问时进入内存；
数据块：文件数据使用的时候进入内；
文件存储
文件的数据是要存储在硬盘上面的，数据在磁盘上的存放方式，有两种方式：
连续空间存放方式
- 同一个文件存放到一个连续的存储空间
- 一旦文件删除可能导致磁盘空间碎片
- 文件内容长度扩展不方便，综合效率是非常低的。
非连续空间存放方式
- 同一个文件存放到一个不连续的存储空间，每个空间会关联下一个空间
- 可以消除磁盘碎片，可大大提高磁盘空间的利用率，同时文件的长度可以动态扩展。
- 查找效率低，需要额外的资源消耗。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JValOu5p-1667795960423)(image/image-20220923154844319.png)]
小结
1.1.2 DFS概述
学习目标
这一节，我们从 DFS简介、原理解读、小结 三个方面来学习。
DFS简介
存储基础
存储处理能力不足：
传统的IDE的io值是100次/秒，SATA固态磁盘500次/秒，NVMe固态硬盘达到2000-4000次/秒。即时磁盘的io能力再大数十倍，难道能够抗住网站访问高峰期数十万、数百万甚至上亿用户的同时访问么？这还受到网络io能力的限制。
存储空间能力不足：
单块磁盘的容量再大，也无法满足用户的正常访问所需的数据容量限制。
需求：
可以实现横向扩展的存储系统，这种存储系统在市面中的表现样式很多，不过他们有一个统一的称呼 -- 分布式存储系统。
分布式文件系统
随着传输技术发展，操作系统读写数据的方式，不再局限于本地I/O技术，开始支持远距离的TCP/IP方式获取数据。它相当于新增一种可以远距离传输的I/O技术，使得分散的存储设备和用户操作系统可以通过网络方式接入联合在一起，形成更大容量，更易于拓展伸缩的存储系统，对此人们引入分布式文件系统的概念。
分布式文件系统（Distributed File System，DFS）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。
分布式文件系统的发展现后经历了三个阶段：网络文件系统、共享SAN文件系统、面向对象的并行文件系统。
从本质上来说，分布式文件系统跟传统的文件系统没本质的差别，只不过是需要额外考虑多节点网络连接的可靠性、接入的存储设备的复杂性，需要文件系统、网络环境、存储策略共同协作而已。
由于文件系统与传统一致，网络环境不受控制，所以，我们平常所说的分布式文件系统，也等同于分布式存储系统。
DSS简介
分布式存储系统，是将数据分散存储在多台独立的设备上，从而解决传统的存储系统的容量和性能限制。所以如果存储服务器的可靠性和安全性无法满足大规模存储应用的需要，那么它就会成为分布式文件系统的性能瓶颈。
其实，分布式存储系统可以理解为多台单机存储系统的各司其职、协同合作，统一的对外提供存储的服务。
分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
按照分布式存储系统的作用场景，我们可以将其划分为 存储非结构化数据的分布式文件系统、存储结构化数据的分布式数据库、存储半结构化数据的分布式NoSQL数据库等。
常见的文件系统
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MNB2cIXP-1667795960424)(image/image-20220923162020799.png)]
原理解读
分布式数据存储
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NMFyTQGL-1667795960424)(image/1636082742521.png)]
存储角色
节点角色
当我们将数据存储到分布式系统上的时候，就需要有一个路由机制，能够将我们的请求转交给对应的存储节点上。所以，根据我们对数据在单节点上的存储原理，我们就需要有一个单独的节点来存储所有数据的元数据信息，然后，分布式存储就作为block的存储区域，专门用户数据存储。
存储元素据的节点我们把它称为NameNode，存储具体数据的节点我们称为DataNode。
数据拆分：
当我们要存储的数据非常大，比如说5个G，所以我们在存储的时候，将存储的数据信息发送给元数据控制节点，然后元数据控制节点根据自定义的存储策略，将要存储的数据进行拆分(64M一块)--也就是数据切片，将切分后的数据作为一个独立的文件，然后基于同样的路由逻辑，将其分散存储到不同的存储节点上。
元数据控制节点，在进行数据切分的时候，还需要能够组合起来，所以拆分后的数据块大小、组合时候的偏移信息、路由到的节点等信息都应该有针对性的记录。
在切片的时候，还可以实现并行的存储逻辑效果。每一个数据块都称为一个shard。
数据高可用
元数据高可用
由于NameNode保存了非常重要的数据信息，所以为了避免因为NameNode故障导致的问题，我们一定要对NameNode进行高可用处理。
由于元数据非常小(几k)，所以NameNode上的数据是 非常密集而且io量非常小的。所以为了提高数据的查询和存储效率，我们一般将这些数据保存到内存中。所以为了防止主机断电导致数据丢失，所以我们需要随时的进行数据同步到磁盘中，因为没有办法判断每一次到底是哪种数据被访问或更改，所以在磁盘数据同步的时候，随机io是非常大的。
同时，为了避免单节点的数据文件丢失，我们需要通过共享存储的方式将数据保存在第三方的存储设备上，同时还需要对数据存储主机进行高可用
数据高可用
由于我们对元数据进行了数据切片的方式，实现了数据的高效率存取，但是我们知道，一旦这些数据块中，任意丢弃一块，就会导致所有的数据无法正常的使用。所以有必要对这些数据进行高可用的操作。对于高可用的方式，我们一般会有两种方式来实现数据的冗余。
节点级：
通过对主机节点进行高可用，从而实现数据的冗余，这种机制，成本太高了，不值得。
数据级：
我们对拆分后的数据块进行副本操作，而且还可以根据节点的数量，自定义冗余的副本数量。这是推荐的。
主角色的数据块称为 primary shard，副本数据块称为 replica shard。
在进行数据块数据冗余的时候，这些副本的策略机制是有元数据节点来进行控制的，当一个DataNode故障的时候：
- 如果主shard没有了，从所有的副本shard中选择一个主。
- 如果副本shard没有了，再创建一个副本shard即可。
- 一旦DataNode节点数量多于副本数量，控制副本数据在另一个DataNode节点上复制一个新的副本
从而保证副本的总体是满足预期的。
为了防止数据副本节点在同一个物理机架上的时候，因为机架故障，导致所有副本无效，所以我们在考虑冗余的时候，还需要考虑地理位置区域的冗余。
小结
1.1.3 存储简介
学习目标
这一节，我们从 存储类型、ceph简介、小结 三个方面来学习。
存储类型
三种存储
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mfFIBfIw-1667795960425)(image/1636084901961.png)]
块存储
块存储是将裸磁盘空间整个映射给主机使用的，主机层面操作系统识别出硬盘，与我们服务器内置的硬盘没有什么差异,可以自由的进行磁盘进行分区、格式化，
块存储不仅仅是直接使用物理设备，间接使用物理设备的也叫块设备，比如虚机创建虚拟磁盘、虚机磁盘格式包括raw、qcow2等。
常见解决方案：
ABS(Azure Block Storage)、GBS(Google Block Storage)、EBS(Elastic Block Storag)
Cinder、Ceph RBD、sheepdog
文件系统存储
最常见、最容易、最经典实现的一种存储接口。它可以直接以文件系统挂载的方式，为主机提供存储空间资源。它有别于块存储的特点就在于，可以实现共享效果，但是有可能受网络因素限制导致速度较慢。
常见解决方案：
AFS(Azure FileStorage)、GFS(Google FileStorage)、EFS(Elastic File Storage)
Swift、CephFS、HDFS、NFS、CIFS、Samba、FTP
对象存储
其核心是将 数据读或写 和 元数据 分离，并且基于对象存储设备(Object-based Storage Device，OSD)构建存储系统，然后借助于对象存储设备的管理功能，自动管理该设备上的数据分布。
对象存储主要包括四部分：对象、对象存储设备、元数据服务器、对象存储系统的客户端
简单地说，块存储读写块，不利于共享，文件存储读写慢，利于共享，而对象存储综合了两者的优点。
常见的解决方案：
AS(Azure Storage)、GCS(Google Cloud Storage)、S3(Simple Storage Service)
Swift、Ceph OSD
Ceph简介
官方介绍
Ceph is the future of storage; where traditional(传统的) systems fail to deliver, Ceph is designed to excel(出色). Leverage(利用) your data for better business(业务) decisions(决策) and achieve(实现) operational(运营) excellence(卓越) through scalable, intelligent(智能), reliable(可靠) and highly available(可用) storage software. Ceph supports object, block and file storage, all in one unified(统一) storage system.
来源：
Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表，论文发表于2006年），并随后贡献给开源社区。
参考资料：
官方地址：https://ceph.com/en/
官方文档：https://docs.ceph.com/en/latest/#
github地址：https://github.com/ceph/ceph
最新版本：Quincy-17.2.3(2022-04-19)、Pacific-16.2.10(2021-03-31)、Octopus-15.2.17(2020-03-23)
系统支持：
全系列最好的系统支持是Ubuntu
Ceph的发展对于Centos系列和Redhat系列不友好，新版本不支持旧版本系统。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cifpa3us-1667795960425)(image/image-20220923170114091.png)]
软件特点
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VNIjVSJJ-1667795960425)(image/image-20220923163720189.png)]
为什么很多人用ceph？
1 创新，Ceph能够同时提供对象存储、块存储和文件系统存储三种存储服务的统一存储架构
2 算法，Ceph得以摒弃了传统的集中式存储元数据寻址方案，通过Crush算法的寻址操作，有相当强大的扩展性。
3 可靠，Ceph中的数据副本数量可以由管理员自行定义，并可以通过Crush算法指定副本的物理存储位置以分隔故障域，支持数据强一致性的特性也使Ceph具有了高可靠性，可以忍受多种故障场景并自动尝试并行修复。
基本结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bglrvqyA-1667795960425)(image/1636088249032.png)]
Ceph是一个多版本存储系统，它把每一个待管理的数据流（例如一个文件） 切分为一到多个固定大小的对象数据，并以其为原子单元完成数据存取。
对象数据的底层存储服务是由多个主机（host）组成的存储集群，该集群也被称之为 RADOS（Reliable Automatic Distributed Object Store）存储集群，即可靠、自动化、 分布式对象存储系统
librados是RADOS存储集群的API，它支持C、C++、Java、Python、Ruby和PHP等编程语言。
应用场景
Ceph uniquely(独特的) delivers object, block, and file storage in one unified(统一) system.
注意：这个介绍在官网这几年基本没有变化
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FLLK0dK8-1667795960426)(image/1636099032730.png)]
RadosGW、RBD和CephFS都是RADOS存储服务的客户端，它们把RADOS的存储服务接口(librados)分别从不同的角度做了进一步抽象，因而各自适用于不同的应用场景。
也就是说，ceph将三种存储类型统一在一个平台中，从而实现了更强大的适用性。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h5NNN0Xu-1667795960426)(image/1636089258096.png)]
LIBRADOS - 通过自编程方式实现数据的存储能力
RADOSGW - 通过标准的RESTful接口，提供一种云存储服务
RBD - 将ceph提供的空间，模拟出来一个一个的独立块设备使用。
而且，ceph环境部署完毕后，服务端就准备好了rbd接口
CFS - 通过一个标准的文件系统接口来进行数据的存储
参考图例：https://docs.ceph.com/en/pacific/_images/stack.png
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NPysTbU7-1667795960426)(image/image-20211110140906074.png)]
小结
1.1.4 组件解析
学习目标
这一节，我们从 组件介绍、流程解读、小结 三个方面来学习。
组件介绍
组件简介
无论您是想向云平台提供 Ceph 对象存储和 Ceph 块设备服务、部署 Ceph 文件系统还是将 Ceph 用于其他目的，所有 Ceph 存储集群部署都从设置每个 Ceph 节点、您的网络和 Ceph 开始 存储集群。
一个 Ceph 存储集群至少需要一个 Ceph Monitor、Ceph Manager 和 Ceph OSD（对象存储守护进程）。 运行 Ceph 文件系统客户端时也需要 Ceph 元数据服务器。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1LRuqpzU-1667795960427)(image/1636099270839.png)]
| 组件 | 解析 |
|---|---|
| Monitors | Ceph Monitor (守护进程ceph-mon) 维护集群状态的映射，包括监视器映射、管理器映射、OSD 映射、MDS 映射和 CRUSH 映射。 这些映射是 Ceph 守护进程相互协调所需的关键集群状态。 监视器还负责管理守护进程和客户端之间的身份验证。 通常至少需要三个监视器才能实现冗余和高可用性。基于 paxos 协议实现节点间的信息同步。 |
| Managers | Ceph 管理器 (守护进程ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前性能指标和系统负载。 Ceph 管理器守护进程还托管基于 Python 的模块来管理和公开 Ceph 集群信息，包括基于 Web 的 Ceph 仪表板和 REST API。 高可用性通常至少需要两个管理器。基于 raft 协议实现节点间的信息同步。 |
| Ceph OSDs | Ceph OSD（对象存储守护进程，ceph-osd）存储数据，处理数据复制、恢复、重新平衡，并通过检查其他 Ceph OSD 守护进程的心跳来向 Ceph 监视器和管理器提供一些监控信息。 通常至少需要 3 个 Ceph OSD 来实现冗余和高可用性。本质上osd就是一个个host主机上的存储磁盘。 |
| MDSs | Ceph 元数据服务器（MDS[Metadata Server]、ceph-mds）代表 Ceph 文件系统存储元数据。 Ceph 元数据服务器允许 POSIX（为应用程序提供的接口标准） 文件系统用户执行基本命令（如 ls、find 等），而不会给 Ceph 存储集群带来巨大负担。 |
| PG | PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。写数据的时候，写入主osd，冗余两份。 |
流程解读
综合效果图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8xOONXVG-1667795960427)(image/1636104082951.png)]
Ceph 将数据作为对象存储在逻辑存储池中，主要包括两步：
把对象数据 映射给 PG
- 计算出哪个归置组应该包含该对象
- 这部分功能是由Hash算法实现的
把 PG 映射到 host的OSD
- 计算出哪个 Ceph OSD Daemon 应该存储该归置组
- 这部分由 CRUSH算法来决定的，CRUSH 算法使 Ceph 存储集群能够动态扩展、重新平衡和恢复。
数据存储逻辑
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4KuUa57z-1667795960427)(image/1636103641572.png)]
小结
1.1.5 存储原理
学习目标
这一节，我们从 存储解读、案例解读、小结 三个方面来学习。
存储解读
存储数据
Ceph 存储集群从 Ceph 客户端接收数据,无论是通过 Ceph 块设备、Ceph 对象存储、Ceph 文件系统还是您使用 librados 创建的自定义实现, 这些数据存储为 RADOS 对象, 每个对象都存储在一个对象存储设备上。
Ceph OSD 守护进程处理存储驱动器上的读、写和复制操作。它主要基于两种文件方式实现：
- Filestore方式，每个 RADOS 对象都作为一个单独的文件存储在传统文件系统（通常是 XFS）上。
- BlueStore方式，对象以类似整体数据库的方式存储，这是新版本ceph默认的存储方式。
注意：在Ceph中，每一个文件都会被拆分为多个独立的object，然后按照上面的逻辑进行持久化。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bO36bbpl-1667795960428)(image/1636104261047.png)]
Ceph OSD 守护进程将"数据"作为对象存储在平面命名空间中,该对象包括如下部分：
标识符 - 在内存中唯一查找的标识
二进制数据 - 每个对象的真实数据
属性数据 - 由一组名称/值对组成的元数据，语义完全取决于 Ceph 客户端。
例如，CephFS 使用元数据来存储文件属性，例如文件所有者、创建日期、上次修改日期等。
注意：
对象 ID 在整个集群中是唯一的，而不仅仅是本地文件系统.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VwAhA3g3-1667795960428)(image/1636104309671.png)]
案例解读
存储示例
存储一个大小为16M的文件，存储的时候，需要首先进行切割，假设每个对象(object)大小为4M,然后通过hash方式将object存储到对应的PG上，然后通过 CRUSH 策略将对应的数据关联到不同的host上。
这个时候遇到一个问题：osd是一个磁盘设备，那么如何来进行存储数据
常见的处理措施主要有两种：
第一种：将osd格式化为文件系统，然后挂载到对应目录，然后就可以使用了
第二种：osd有自己的守护进程，那么直接在守护进程空间中实现数据的处理
方法1 - FileStore
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nflMv58X-1667795960428)(image/1636105592444.png)]
这个时候，osd就变成一个文件系统中的文件(目录)了。
因此，OSD需要维护object的对象属性信息，object的元数据保存到 osd(文件系统)的元数据区。
但是文件系统的元数据区只能存放文件的 属主、属组、权限、时间戳等信息。对于ceph来说，object的元数据信息却包含很多相关信息，那么这些数据保存到哪里？
那么为了保存文件系统默认能够保存的数据之外的元数据(object对象的其他元数据信息)，我们就需要将OSD做成一个XFS文件系统，在这个文件系统中，需要有一个单独的数据库(LevelDB)，来维护ceph的元数据信息，效果如下
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t2cqCDqU-1667795960429)(image/1636106662704.png)]
由于这种方式是基于文件系统映射的方式来实现 ceph的属性存储，所以我们把这种文件的存储方式称为 FiltStore。
劣势：
由于我们的object本来已经称为对象了，而在FileStore中，我们需要将其转换为文件方式来进行数据属性的存储，所以效率有些慢
附注：
XFS是被开发用于高容量磁盘以及高性能文件系统之用的。主要规划为三个部分：
资料区（data section）- 存储包括inode、block、superblock等数据
文件系统活动登录区（log section） - 用来记录文件系统的变化
实时运作（realtime section）- 数据真正存储的地方
方法2 - BlueStore
因为osd对象是由一个ceph-osd守护进程来实现存储数据、处理数据复制、恢复、重新平衡等管理操作的。所以新版的Ceph的osd进程中，维护了一个RocksDB用于存储objects的元数据属性信息.
RocksDB为了实现数据的存储还需要一个文件系统，所以Ceph就为它开发了一个文件系统 BlueFS。
RocksDB + BlueFS 共同实现了objects的元数据的存储，所以我们把这种存储方式称为 BlueStore。新版的Ceph的存储机制，默认采用的就是 BlueStore机制。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lExsd2aT-1667795960430)(image/1636107225026.png)]
小结