Ceph分布式存储 原理+架构图详解

分布式存储Ceph

ceph介绍

ceph是一个统一的、分布式的存储系统，设计初衷式提供较好的性能(io)、可靠性(没有单点故障)和可扩展性(未来可以理论上无限扩展集群规模)，这三点也是集群架构所追求的。

• 统一性 :
  意味着我们可以仅凭ceph这一套存储系统，同时提供块存储和文件系统存储、对象存储。这三种功能，这极大地简化了不同应用需求下地部署和运维工作。
• 分布式 :
  传统集群架构: 集群规模增大，mysql数据的集群规模必然也要随之增大，这完全是集中分布是思想带来的弊端。
  ceph内部集群的数据共享完全通过算法算出来，根本不需要数据库这个组件，完全分布式的。
  ceph分布式的缺点: 耗费cpu。

什么是块存储、文件存储、对象存储

块级与文件级概念

1. 块级
   磁盘的最小读写单位为扇区，1个或多个连续的扇区组成一个block块，也称之为物理块，是操作系统的读写单位。
   一个逻辑文件对应一个物理块。

blockdev --getbsz /dev/sda1					查看block块大小(一个block块默认512字节)
# 512		

2. 文件级
   文件是文件系统提供的功能，单个文件可能由一个或者多个逻辑块组成，且逻辑块之间是不连续分布的，逻辑块大于或等于物理块整数倍。
   物理块与文件系统之间的映射关系为: 扇区–>物理块–>文件系统
   注意 : 这么多层的转换，是需要耗费效率。
   

块存储 : 存储设备共享给客户端的是一块裸盘，那么该存储设备提供的就是块存储

• 特点 :

1. 客户端可定制性强，可以自己制作文件系统，然后挂载使用，或者直接把操作系统安装在块存储里面。

• 用途 :
  适用于给vm(虚拟机)的本地硬盘。虚拟机是用软件模拟出来的，存在不稳定因素，如果虚拟机出现down机了，可能会导致数据丢失，使用块存储有利于保护虚拟机数据的安全。
  

文件存储 : 存储设备共享给客户端的是文件夹，那么该存储设备提供的就是文件存储

• 特点 :

1. 客户端主要操作的是文件和文件夹，客户端无法格式化制作自己的文件系统，使用的是现成文件系统，定制性差。
2. 文件检索与存储过程都是在存储设备中完成的，意味着随着客户端数目的增多，存储设备的压力会越来越大，所以文件存储会限制集群的扩展规模。

• 用途:
  适用于中小型规模集群的多服务器之间数据共享，并且保证一致。
  

对象存储 : 数据的存储分为两部分: inode(元数据) + block(真实数据) ( 数据存储的形式为key:value的形式 )。

• 特点 :

1. 基于多服务器之间的数据共享，保证数据一致，并且没有文件系统的概念，
2. 没有文件系统的概念，服务端不会随着客户端数目的增多而压力成倍增大。

• 用途:
  适用于分布式存储，云存储。
  

为何要用ceph

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

- 高可用 : 
1. 副本数可以灵活控制
2. 支持故障域分隔，数据强一直性
3. 多故障场景自动进行修复自愈
4. 没有单点故障，自动管理，高可扩展性

- 去中心化 : 
1. 扩展灵活
2. 随着节点增加而线性增长

- 特性丰富 : 
1. 支持三种存储接口 : 块存储、文件存储、对象存储
2. 支持自定义接口，支持多种语言驱动。

Ceph系统的层次结构

自下而上，可以将Ceph系统分为四个层次

• 基础存储系统RADOS
• 基础库LIBRADOS
• 高层应用接口，包括三个部分:
  1. 对象存储接口(RADOS GW)
  2. 块存储接口(RBD)
  3. 文件存储接口(Ceph FS)
• 应用层 : 基于高层接口或者基础库librados开发出来的各种APP，或者主机，VM等诸多客户端
  
• ceph集群称之为Rados
• Rados集群是ceph的服务端，依据高层接口封装的应用则是客户端。

基础存储系统RADOS

ceph集群架构类似于一个网络版本的raid10模式

• 单台机器可插硬盘的总数是有限的，如果能通过网络通信，那么就可以打破单台机器的限制：一堆硬盘+软件控制起来
  做成硬盘的集群，相当于一个大的网络raid，这就是分布式存储，比如ceph。
  

ceph集群的子集群

1. OSD(osd daemon)集群

• 一个osd daemon就是一个套接字应用程序，一个osd daemon唯一对应一块数据盘( 数据盘的组成可以是一块机械硬盘 + 一块固态盘的两个分区 )。
• 综合算下来，OSD集群由一定数目的osd daemon组成(osd daemon数量从几十个到几十万个不等，也有可能会更多)。
  

ceph的不同版本osd daemon与disk(数据盘)之间的对应关系

hammer(老版本): osd daemon --> xfs文件系统 --> disk
- xfs文件系统叫日志文件系统,先写入日志,再写入数据内容。一个disk = 一个机械盘 + 一个固态盘
- 性能优化 : 固态盘负责存文件系统日志,机械盘负责写入数据内容。

luminous(新版本): osd daemon --> 裸盘disk
- 一个disk搭配固态盘的两个分区,一个固态盘分两个分区,一个分区存日志，一个分区存元数据
- 一个固态盘两个分区下面搭配一个机械盘。

• 对比hammer版本和luminous版本，luminous版本的osd daemon是直接传输数据给数据盘的。因此，不需要经历物理块与文件系统之间的转换，读写数据效率要高于hammer版本。

osd daemon节点主要负责:

1. 负责控制数据盘上的文件读写操作，与client通信完成各种数据对象操作等等
2. 负责数据的拷贝和恢复
3. 每一个osd daemon守护进程监视它自己的状态，以及别的osd deamon的状态，并且报告给Monitor(监控节点，控制了ceph集群的行为)

pg_temp状态

• pg组中的osd daemon也有主次之分，一个pg组里面有多个osd daemon，crush算法会默认把其中一个osd damon作为primary osd(主osd daemon)，主osd daemon主要负责接收数据的读写；其余的作为replication osd(从osd daemon)，从osd daemon主要负责数据的备份。

1. 如果pg组中的replication osd挂了，crush算法会默认将primary osd的数据备份一份到新加入的replication osd中。
2. 如果pg组中的primary osd挂了，crush算法将一个新的osd deamon划分到这个pg组中作为primary osd，那么crush算法会先将pg组里面原来的replication osd暂时先作为主osd daemon。等到新划分的primary osd备份了这个pg组里面的数据，会正式作为主osd daemon负责接收这个pg组的数据读写。发生这种现象，pg状态会短暂处于pg_temp状态。

2. MON(Montior)集群

Montior节点主要负责 :

1. 监控全局状态(cluster map)

cluster map负责监控:
	1. osd daemon map
	2. monitor map
	3. pg map
	4. crush map

2. 负责管理集群内部状态(osd daemon挂掉，数据恢复等操作)
3. 负责授权，客户端在访问时会先通过monitor集群验证操作权限
   客户端需要先跟monitor要到cluster map
   

ps : monitor节点的个数 = 2*n+1

1. 必须为奇数个
2. 一个monitor存在单点故障的问题，所以最少三个起

MON集群为何monitor节点个数应该为奇数个

• monitor节点同步数据用的是paxos算法(分布式强一致性算法)，paxos算法规定至少有三个节点。
• paxos算法的作用，一个monitor节点只要数据不一致，就会通过paxos算法保证该节点的数据保持一致。

MON集群可以挂掉几个monitor节点

• monitor节点之间使用paxos算法来保持各节点cluster map的一致性；各mon节点的功能总体上是一样的，相互间的关系可以被简单理解为主备关系。如果主mon节点损坏，其他mon存活节点超过半数时，集群还可以正常运行。当故障mon节点恢复时，会主动向其他mon节点拉取最新的cluster map。

monitor进程与osd daemon进程能否在同一个物理节点上

• 可以，但是不好。但是这就是一种集中式的思想，如果可以考虑到成本，可以这么做。

Ceph集群的核心逻辑概念

ceph的特性

1. 伪数据平衡，是通过算法达到的

object ---> pg组    	是通过hash算法实现的
pg组 ---> osd daemon    是通过crush算法实现的

2. ceph适用于海量小文件，或者单个容量大文件

pg和pool相关概念

ceph的逻辑单位

• pg(归置组) : pg是ceph中分配数据的最小单位，一个pg内包含多个osd daemon。
• pool(存储池）: 我们在创建pool存储池时需要指定pg的个数，来创建pg。创建pg需要用到crush算法，crush算法决定了pg与osd daemon的对应关系，所以说，在客户端往ceph中写入数据之前，pg与osd daemon的对应关系是已经确定的。虽然是确定的，但是pg与osd daemon的对应关系是动态的。

一个osd daemon应该属于多少个pg组呢

• 首先osd daemon不能只属于一个pg组。ceph是以pg组为单位分配数据的，如果一个osd daemon只属于一个pg组，那么该osd daemon将只能接收着一个pg组发来的数据。
• 如果该pg组没有被hash算法算到，那么就不会收到数据，于是该osd daemon就被闲置了。因此，pg组与osd daemon之间的关系为多对多关系。
• 官方建议 : 如果ceph集群很长一段时间都不会拓展，一个osd deamon属于100个pg组。否则，一个osd deamon属于200个pg组。

Ceph网络划分

Ceph推荐主要使用两个网络，这么做，注意从性能(OSD节点之间会有大量的数据拷贝操作)和安全性(两网分离)考虑。

• 前端(南北)网络 : 连接客户端和集群
• 后端(东西)网络 : 连接ceph各个存储节点
  

pool存储池详解

Ceph的pool有四大属性

1. 所有性和访问权限
2. 对象副本数目，默认pool池中的一个pg只包含两个osd daemon，即一份数据交给pg后会存下2个副本，生产环境推荐设置为3个副本。
3. pg数目，pg是pool的存储单位，pool的存储空间就由pg组成
4. crush规则集合

pg数与osd daemon之间对应关系的影响

创建pool时需要确定其pg的数目，在pool被创建后也可以调整该数字，但是增加池中的pg数是影响ceph集群的重大事件之一，在生产环境中应该避免这么做。因为pool中的pg的数目会影响到：

1. 数据的均匀分布性
2. 资源消耗：pg作为一个逻辑实体，它需要消耗一定的资源，包括内存，CPU和带宽，太多的pg的话，则占用资源会过多
3. 清理时间：Ceph的清理工作是以pg为单位进行的。如果一个pg内的数据太多，则其清理时间会很长
4. 数据的持久性：pool中的pg个数应该随着osd daemon的增多而增多，这样crush算法可以将pg和osd的对应关系尽量均匀一些，降低同一个osd属于很多个pg的几率，如果一个osd真的属于很多很多pg，这样可能会很糟糕，可能会出现如下情况：

假设我们pool副本的size为3，则表示每一个pg将数据存放在3个osd上。一旦某个osd daemon挂掉，因为一个osd daemon同时属于很多个pg，则此时会出现很多pg只有2个副本的情况，这个时候通过crush算法开始进行数据恢复。在数据恢复的过程中，因为数据量过大，又有一个osd daemon(也属于很多很多pg)扛不住压力也崩溃掉了，那么将会有一部分pg只有一个副本。这个时候通过crush算法再次开始进行数据恢复，情况继续恶化，如果再有第三个osd daemon挂掉，那么就可能会出现部分数据的丢失。

由此可见，osd daemon上的pg组数目:

1. 不能过小，过小则数据分布不均匀
2. 不能过大，过大则一个osd daemon挂掉影响范围会很广，这会增大数据丢失的风险

osd daemon上的pg组数目应该是在合理范围内的，我们无法决定pg组与osd daemon之间的对应关系，这个是由crush算法决定的。但是我们可以在创建pool池时，可以指定pool池内所包含pg的数量，只要把pg的数量设置合理，crush算法自然会保证数据均匀。

指定pool池中pg的数量

如何算出一个pool池内应该有多少个pg数？

• Target PGs per OSD：crush算法为每个osd daemon分配的pg数(官网建议100或200个)
• OSD#：osd daemon的总数
• %DATA：该存储池的空间占ceph集群整体存储空间的百分比
• Size：pool池中的副本数

计算公式：

(Target PGs per OSD)✖(OSD#)✖(%DATA)/Size

如果如果ceph集群很长一段时间都不会拓展,我们osd daemon的总数为9,该存储池占用整个ceph集群整体存储空间的百分比为1%(10G/1000G),
pool池中的副本数为3个,那么我们在pool池中设置pg的数量为多少合理?
100 * 9 * 0.01 / 3 = 3 (个)

官网也给出了一些参考原则

• osd daemon的总数少于5个，建议将pool中的pg数设为128
• osd daemon的总数5到10个，建议将pool中的pg数设为512
• osd daemon的总数10到50个，建议将pool中的pg数设为4093

osd daemon的总数为50个以上，我们可以使用官网的工具进行计算，来确定pool池中pg的个数。ceph官网计算工具网址：https://ceph.com/pgcalc/

Ceph中pool池的两种类型

1. Replicated pool(默认)
   副本型pool，通过生产对象的多份拷贝
   优点 : 保证了数据的安全
   缺点 : 浪费空间，如果设置的pg对应三个副本，那么空间只能用到原来空间的三分之一

2. Erasure-coded pool
   特点 : 没有副本，可以把空间百分之百利用起来，但是没有副本功能(无法保证数据的安全)
   不支持ceph的压缩，不支持ceph垃圾回收的功能等

pg逻辑单位详解

pg概念

• Acting set : 支持一个pg组所有osd daemon的有序列表，其中第一个osd是主osd，其余为次。acting set是crush算法分配的，但是不一定已经生效了。Acting set是由crush算法计算得出的。
• PG temp：Ceph正在往主osd daemon回填数据时，这个主osd是不能提供数据服务的，这个时候，它回向Monitor集群申请一个临时的Acting set，这就是PG temp。

举个例子，现在acting set是[0，1，2]，出现了一点事情后，它变为了[3，2，1]。此时，osd.3还是空的，它无法提供数据服务，因此它还需要等待回填数据过程结束。这时候，osd.3会向monitor集群申请一个临时的set [1，2，3]。此时，将由osd.1提供数据服务。回填数据过程结束后，该临时的set会被丢弃，重新由osd.3提供服务。

• 主(primary)OSD：在acting set中的首个OSD，负责接收客户端写入的数据；默认情况下，提供数据读服务，但是该行为可以被修改。它还负责peering过程，以及在需要的时候申请PG temp。
• 次(replica)OSD：在acting set中除了第一个以外的其余OSD。
• 流浪(stray)OSD：已经不是acting set中了，但是还没有被告知去删除数据的OSD。

pg的状态

其主要状态包括

1. Creating 创建中：pg组正在被创建。
2. Peering 对等互联：Peering就是一个pg组的所有的osd daemon都需要互相通信，pg组的对象及其元数据的状态达成一致的过程。
3. Active 活动的：Peering的过程完成之后，pg组的状态就是active的。此状态下，主次的osd daemon上的pg组数据都是可用的，即pg组内主osd daemon和从osd daemon都处于就绪状态，可正常提供客户端请求。
4. Clean 洁净的：此状态下，主次osd daemon都已经处于就绪状态，每个副本都就绪了。
5. Down：pg掉线了。
6. Degraded 降级的：某个osd daemon被发现停止服务(down)了之后，Ceph的Montior集群将该osd daemon上所有的pg的状态设置为degraded，即pg包含的osd数目不够，此时该osd daemon的对等osd daemon会继续提供数据服务。这时会有两种结果：
   1. down掉的osd daemon会重新起来，需要再经过Peering到clean的状态，而且Ceph会发起恢复过程(recovering 增量恢复)，使用该osd daemon上过期的数据被恢复到最新状态。
   2. osd daemon的down状态持续300秒后其状态被设置为out提出集群，Ceph会启动自恢复操作，选择其他的osd daemon加入acting set，并启动回填数据(backfilling 全量恢复)到新的osd daemon的过程。使pg副本数恢复到规定的数目，有时候崩溃的时候也会处于此状态。
7. Remapped 重映射：每当pg的acting set改变后，就会发生从旧的acting set到新的acting set的数据迁移。此过程结束前，旧的acting set中的主osd daemon将继续提供服务。一旦该过程结束，Ceph将使用新的acting set中的主osd dameon来提供服务。
8. Stale 过期的：每个osd daemon每隔0.5秒向monitor集群报告其状态。如果因为任何原因，主osd daemon报告状态失败了，或者其他osd daemon已经报告了主osd daemon状态为down了，monitor集群将会将他们的pg标记为stale状态。
9. Undersized: 当pg中副本数少于其他存储池指定的个数的时候，就为此状态。
10. Scrubbing：osd daemon会周期性的检查其持有的数据对象的完整性，以确保主osd daemon和从osd daemon数据的一致，这时候状态就为此状态。另外pg偶尔还需要检查确保一个对象的osd daemon能按位匹配，这时候状态为scrubbing + deep。
11. recovering：增量恢复。
12. backfilling：全量恢复。
13. unkown：表示pg不知道与哪些osd daemon对应。出现这种状态，表示指定的Crush规则错误了。

Crush规则详解

什么是Crush

• Crush是一种类似于一致性hash的算法，用于为Rados存储集群控制数据分布

Crush在ceph集群中的作用

• 负责数据从pg组到osd daemon的存取

Crush rules(规则)的三个作用

1. 指定从Crush Map中的哪个节点开始查找
2. 指定使用哪个节点作为故障隔离域
3. 指定定位副本的搜索模式(广度优先or深度优先)

自定义Crush规则

rule nana_rule {					# 规则集的命名,创建pool时可以指定rule集
	id 1							# id设置为1
	type replicated					# 定义pool池类型为replicated(还有esurecode模式)
		
	min_size 1						# pool中最小指定的副本数量不能小于1
	min_size 10						# pool中最大指定的副本数量不能大于10

	# pg到osd daemon的检索步骤
	step take datacenter0			# 定义pg查找副本的入口点datacenter0
									# 这一步选择一个根节点,这个节点不一定是root
									# 这个节点可以是任何一个故障域
									# 从指定选择的这个节点开始执行

	step chooseleaf firstn 0 type rack		# firstn 0表示算法(深度优先),type rack表示故障域设置为rack
	step emit						# 结束,返回结果
}

如果有三个osd 物理节点，然后他们都放在同一个机柜里，故障域应该设置为host；最好是放在三个不同的机柜里，然后故障域设置为rack。

故障域

Ceph集群中的默认的故障域，目的是为了防止单点故障

• osd：硬盘
• host：服务器
• chassis：机箱
• rack：机架(一个机架包含多个机箱)
• row：机排
• pdu：配电单元(有可能多个机排共用一个配电单元)
• pod：多个机排
• room：机房
• datacenter：数据中心(有可能多个机房组成一个数据中心)
• region：区域(华东区1，华东区2等)
• root：最顶级，必须存在
  

存储引擎

hammer版本的存储引擎 : filestore

filestore : osd daemon --> xfs文件系统 --> 磁盘

luminous版本的存储引擎 : bluestore

bluestore : osd daemon --> 裸磁盘

luminous版本我们通常会osd daemon --> lvm --> 裸磁盘，让osd daemon直接对应一个lvm。那么我们为什么要这么做？
如果我们在ceph集群即将用满的情况下进行扩容，那么该如何扩容？

1. osd daemon --> 裸磁盘
   新增一块磁盘，然后用osd daemon管理它。但问题是，新增的一个osd daemon，ceph会在该osd aemon上创建一个pg，说白了就是把该osd daemon划分到一些pg组里面。但凡osd daemon被分配到pg里，会发生数据迁移。生产环境中，pg的数量能不动则不动。
2. osd daemon --> lvm --> 裸磁盘
   从vg组里面划分更多的空间给lvm，不必新增osd daemon，后期的扩容，不会发生数据迁移。

考虑到集群日后的扩容，那么推荐使用方案：osd daemon --> lvm --> 裸磁盘