一生万物——RADOS导论
文章目录
前言
已经有三个月（好像不止3个月）没怎么看书学习了，要重新开始好好做人TAT。用写读书笔记的方法监督自己看书~~
要多看书才能进步，每天搬砖是没有前途的。
一. ceph简述
- ceph是软件定义存储：ceph可以运行在几乎所有主流的linux发行版和其他UNIX操作系统。
- ceph是分布式存储：分布式基因可以使其可以轻易管理成百上千个节点，PB级及以上存储容量的大规模集群，基于计算寻址则让ceph客户端可以直接与服务端任意节点通信，从而避免因为存在访问热点而产生性能瓶颈。
- ceph是统一存储：ceph既支持传统的块，文件存储协议，也支持新兴的对象存储协议。
二. 元数据
我一直以为元数据就是原始对象呢。今天才明白。。。
元数据是描述数据的数据，主要描述数据属性的信息，如：存储位置，历史数据，资源查找，文件记录等功能。是用于描述一个文件的特征的系数数据，比如：访问权限，文件拥有者以及文件数据库的分布信息。在集群文件系统中，分布信息包括文件在磁盘上的位置以及磁盘在集群中的位置。用户需要操作一个文件就必须先得到它的元数据，才能定位到文件的位置并且得到文件的内容、相关属性。
在linux中使用stat命令，可以显示文件的元数据。
[root@ceph-node1 ~]# stat 1.txt
File: ‘1.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 802h/2050d Inode: 33889728 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2018-08-05 16:38:22.137566272 +0800
Modify: 2018-08-05 16:38:22.137566272 +0800
Change: 2018-08-05 16:38:22.137566272 +0800
Birth: -
File：文件名
Size：文件大小（单位：B）
Blocks：文件所占扇区个数，为8的倍数（通常的Linux扇区大小为512B，连续八个扇区组成一个block）
IO Block：每个数据块的大小（单位：B）
regular file：普通文件（此处显示文件的类型）
Inode：文件的Inode号
Links：硬链接次数
Access：权限
Uid：属主id/属主名
Gid：属组id/属组名
Access：最近访问时间
Modify：数据改动时间
Change：元数据改动时间
三.ceph的核心组件
ceph核心组件有：OSD，Monitor，MDS
OSD：赋予底层物理设备（一般来说指得是磁盘）一些CPU，内存资源等，使之成为一个抽象对象存储设备(即OSD)，它能够独立的完成一些低级别的文件系统操作（如：空间分配，磁盘IO调度等），以实现客户端IO操作（如：读、写）与系统调用（如：打开文件，关闭文件）之间的解耦。
Monitor：Monitor是集群的大脑，负责维护和分发集群的关键元数据。同时也是客户端与RADOS集群建立连接的桥梁。它是基于Paxos兼职议会算法构建的，具有分布式强一致性的小型集群，主要负责维护和传播集群表的权威副本。采用负荷分担的方式工作，因此任何时刻，任意类型的客户端或者OSD都可以通过和集群中任意一个Monitor进行交互，以索取或者请求更新集群表。基于Paxos的分布式一致性算法可以保证所有Monitor的行为自始至终都是正确和自治的。
MDS（我一直都不清楚它的作用。。。）全程是Ceph MetaData Server，主要保存文件系统服务的元数据，但对象存储和块存储设备是不需要使用该服务的。
四. ceph架构
RADOS是ceph的核心，基于RADOS及其派生的librados标准库可以开发任意类型的存储应用，典型如ceph的三大核心应用——RBD，RGW和cephFS。如图所示。
五. RADOS概述
一个RADOS集群由大量OSD和少量的Monitor组成。
RADOS使用一张紧凑的集群表对集群拓扑结构和数据映射规则进行描述。任何时刻，任何持有该表的合法客户端都可以独立地与位于任意位置的OSD直接通信。
当集群拓扑结构发生变化时，RAODS确保这些变化能够及时地被Monitor捕获，并通过集群表高效传递至所有受影响的OSD和客户端，以保证对外提供不中断的业务和服务。
数据复制、故障检测和数据恢复都是由每个OSD自动进行，因此不存在明显的调度和处理瓶颈。
RADOS另辟蹊径地以基于可扩展哈希的受控副本分布算法——CRUSH作为衔接客户端和OSD的桥梁。说白了CRUSH是利用计算代替查表。CRUSH包含了获取集群当前数据分布形态所需的全部信息，所以OSD之间通过交互即可智能地完成诸如故障、扩容等引起的数据重新分布。
六. RODOS工作原理
寻址流程
RADOS并不是直接将数据写入OSD的本地存储设备，而是引入了一个中间结构，称为PG，执行两次映射。如图：
第一次：File -> object
将客户端数据按照固定的大小进行切割，编号
- ino：待操作file的元数据，可以简单理解为该file的唯一id
- ono：file切分产生的object的序号。
- oid：将ino、ono连接起来得到的。
举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到的oid就依次为filename0、filename1和filename2。
第二次： object -> PG映射
- hash(oid) & mask -> pgid
使用Ceph系统指定的一个静态哈希函数计算oid的哈希值，将oid映射成为一个近似均匀分布的伪随机值。然后，将这个伪随机值和mask按位相与，得到最终的PG序号（pgid）。根据RADOS的设计，给定PG的总数为m（m应该为2的整数幂），则mask的值为m-1。因此，哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。基于这一机制，当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的size相同，因而，这一映射最终保证了，各个PG中存储的object的总数据量近似均匀。
第三次：PG -> OSD 映射
- 实现PG到OSD的映射，仍然采用伪随机哈希函数（以保证PG在OSD之间分布的均匀性），输入除了全局唯一的PG身份标识外（pid），还引入了集群拓扑，并且使用CRUSH规则对映射过程进行调整，以帮助PG在不同OSD之间灵活迁移，进而实现数据可靠性、自动平衡等高级特性。
数据的操作流程
以file写入过程为例，对数据操作流程进行说明。
为简化说明，便于理解，此处进行若干假定。首先，假定待写入的file较小，无需切分，仅被映射为一个object。其次，假定系统中一个PG被映射到3个OSD上。
基于上述假定，则file写入流程可以被下图表示：
如图所示，当某个client需要向Ceph集群写入一个file时，首先需要在本地完成上面叙述的寻址流程，将file变为一个object，然后找出存储该object的一组三个OSD。这三个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次是Secondary OSD和Tertiary OSD。
找出三个OSD后，client将直接和Primary OSD通信，发起写入操作（步骤1）。Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写入操作（步骤2、3）。当Secondary OSD和Tertiary OSD各自完成写入操作后，将分别向Primary OSD发送确认信息（步骤4、5）。当Primary OSD确信其他两个OSD的写入完成后，则自己也完成数据写入，并向client确认object写入操作完成（步骤6）。
之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免造成数据丢失。同时，由于client只需要向Primary OSD发送数据，因此，在Internet使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。
这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向client发送确认信号，则整体延迟可能难以忍受。因此，Ceph可以分两次向client进行确认。当各个OSD都将数据写入内存缓冲区后，就先向client发送一次确认，此时client即可以向下执行。待各个OSD都将数据写入磁盘后，会向client发送一个最终确认信号，此时client可以根据需要删除本地数据。
七. 对象演进与排序 （待更新）
八. stable_mod与客户端寻址（待更新）
九. PG分裂与扩容（待更新）
参考文献
- https://www.cnblogs.com/linuxk/p/9413928.html
- 《ceph之RADOS设计原理与实现》谢型果 严军 著
