您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
Ceph分布式存储 原理+架构图详解
 
作者:我的紫霞辣辣

  4562  次浏览      17 次
2023-6-6
 
编辑推荐:

本文对Ceph分布式存储 原理+架构图进行了详解, 希望对您的学习有所帮助 。
本文来自于CSDN,由火龙果软件Linda编辑、推荐。

分布式存储Ceph

ceph介绍

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

统一性 :

意味着我们可以仅凭ceph这一套存储系统,同时提供块存储和文件系统存储、对象存储。这三种功能,这极大地简化了不同应用需求下地部署和运维工作。

分布式 :

传统集群架构: 集群规模增大,mysql数据的集群规模必然也要随之增大,这完全是集中分布是思想带来的弊端。

ceph内部集群的数据共享完全通过算法算出来,根本不需要数据库这个组件,完全分布式的。

ceph分布式的缺点: 耗费cpu。

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

块级与文件级概念

块级

磁盘的最小读写单位为扇区,1个或多个连续的扇区组成一个block块,也称之为物理块,是操作系统的读写单位。

一个逻辑文件对应一个物理块。

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

 

文件级

文件是文件系统提供的功能,单个文件可能由一个或者多个逻辑块组成,且逻辑块之间是不连续分布的,逻辑块大于或等于物理块整数倍。

物理块与文件系统之间的映射关系为: 扇区–>物理块–>文件系统

注意 : 这么多层的转换,是需要耗费效率。

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

特点 :

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

用途 :

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

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

特点 :

客户端主要操作的是文件和文件夹,客户端无法格式化制作自己的文件系统,使用的是现成文件系统,定制性差。

文件检索与存储过程都是在存储设备中完成的,意味着随着客户端数目的增多,存储设备的压力会越来越大,所以文件存储会限制集群的扩展规模。

用途:

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

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

特点 :

基于多服务器之间的数据共享,保证数据一致,并且没有文件系统的概念,

没有文件系统的概念,服务端不会随着客户端数目的增多而压力成倍增大。

用途:

适用于分布式存储,云存储。

为何要用ceph

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

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

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

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

Ceph系统的层次结构

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

基础存储系统RADOS

基础库LIBRADOS

高层应用接口,包括三个部分:

对象存储接口(RADOS GW)

块存储接口(RBD)

文件存储接口(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节点主要负责:

负责控制数据盘上的文件读写操作,与client通信完成各种数据对象操作等等

负责数据的拷贝和恢复

每一个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主要负责数据的备份。

如果pg组中的replication osd挂了,crush算法会默认将primary osd的数据备份一份到新加入的replication osd中。

如果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节点主要负责 :

监控全局状态(cluster map)

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

 

负责管理集群内部状态(osd daemon挂掉,数据恢复等操作)

负责授权,客户端在访问时会先通过monitor集群验证操作权限

客户端需要先跟monitor要到cluster map

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

必须为奇数个

一个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的特性

伪数据平衡,是通过算法达到的

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

 

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有四大属性

所有性和访问权限

对象副本数目,默认pool池中的一个pg只包含两个osd daemon,即一份数据交给pg后会存下2个副本,生产环境推荐设置为3个副本。

pg数目,pg是pool的存储单位,pool的存储空间就由pg组成

crush规则集合

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

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

数据的均匀分布性

资源消耗:pg作为一个逻辑实体,它需要消耗一定的资源,包括内存,CPU和带宽,太多的pg的话,则占用资源会过多

清理时间:Ceph的清理工作是以pg为单位进行的。如果一个pg内的数据太多,则其清理时间会很长

数据的持久性: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组数目:

不能过小,过小则数据分布不均匀

不能过大,过大则一个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池的两种类型

Replicated pool(默认)

副本型pool,通过生产对象的多份拷贝

优点 : 保证了数据的安全

缺点 : 浪费空间,如果设置的pg对应三个副本,那么空间只能用到原来空间的三分之一

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的状态

其主要状态包括

Creating 创建中:pg组正在被创建。

Peering 对等互联:Peering就是一个pg组的所有的osd daemon都需要互相通信,pg组的对象及其元数据的状态达成一致的过程。

Active 活动的:Peering的过程完成之后,pg组的状态就是active的。此状态下,主次的osd daemon上的pg组数据都是可用的,即pg组内主osd daemon和从osd daemon都处于就绪状态,可正常提供客户端请求。

Clean 洁净的:此状态下,主次osd daemon都已经处于就绪状态,每个副本都就绪了。

Down:pg掉线了。

Degraded 降级的:某个osd daemon被发现停止服务(down)了之后,Ceph的Montior集群将该osd daemon上所有的pg的状态设置为degraded,即pg包含的osd数目不够,此时该osd daemon的对等osd daemon会继续提供数据服务。这时会有两种结果:

down掉的osd daemon会重新起来,需要再经过Peering到clean的状态,而且Ceph会发起恢复过程(recovering 增量恢复),使用该osd daemon上过期的数据被恢复到最新状态。

osd daemon的down状态持续300秒后其状态被设置为out提出集群,Ceph会启动自恢复操作,选择其他的osd daemon加入acting set,并启动回填数据(backfilling 全量恢复)到新的osd daemon的过程。使pg副本数恢复到规定的数目,有时候崩溃的时候也会处于此状态。

Remapped 重映射:每当pg的acting set改变后,就会发生从旧的acting set到新的acting set的数据迁移。此过程结束前,旧的acting set中的主osd daemon将继续提供服务。一旦该过程结束,Ceph将使用新的acting set中的主osd dameon来提供服务。

Stale 过期的:每个osd daemon每隔0.5秒向monitor集群报告其状态。如果因为任何原因,主osd daemon报告状态失败了,或者其他osd daemon已经报告了主osd daemon状态为down了,monitor集群将会将他们的pg标记为stale状态。

Undersized: 当pg中副本数少于其他存储池指定的个数的时候,就为此状态。

Scrubbing:osd daemon会周期性的检查其持有的数据对象的完整性,以确保主osd daemon和从osd daemon数据的一致,这时候状态就为此状态。另外pg偶尔还需要检查确保一个对象的osd daemon能按位匹配,这时候状态为scrubbing + deep。

recovering:增量恢复。

backfilling:全量恢复。

unkown:表示pg不知道与哪些osd daemon对应。出现这种状态,表示指定的Crush规则错误了。

Crush规则详解

什么是Crush

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

Crush在ceph集群中的作用

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

Crush rules(规则)的三个作用

指定从Crush Map中的哪个节点开始查找

指定使用哪个节点作为故障隔离域

指定定位副本的搜索模式(广度优先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集群即将用满的情况下进行扩容,那么该如何扩容?

osd daemon --> 裸磁盘

新增一块磁盘,然后用osd daemon管理它。但问题是,新增的一个osd daemon,ceph会在该osd aemon上创建一个pg,说白了就是把该osd daemon划分到一些pg组里面。但凡osd daemon被分配到pg里,会发生数据迁移。生产环境中,pg的数量能不动则不动。

osd daemon --> lvm --> 裸磁盘

从vg组里面划分更多的空间给lvm,不必新增osd daemon,后期的扩容,不会发生数据迁移。

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

   
4562 次浏览       17
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训

最新活动计划
UAF架构体系与实践 5-17[北京]
用户体验与界面设计 5-22[北京]
MBSE(基于模型的系统工程)6-20[北京]
大模型微调原理与实操 6-20[厦门]
图数据库与知识图谱 6-27[北京]
Linux内核编程及设备驱动 7-25[北京]
 
 
最新文章
InfluxDB概念和基本操作
InfluxDB TSM存储引擎之数据写入
深度漫谈数据系统架构——Lambda architecture
Lambda架构实践
InfluxDB TSM存储引擎之数据读取
最新课程
Oracle数据库性能优化、架构设计和运行维护
并发、大容量、高性能数据库设计与优化
NoSQL数据库(原理、应用、最佳实践)
企业级Hadoop大数据处理最佳实践
Oracle数据库性能优化最佳实践
成功案例
某金融公司 Mysql集群与性能优化
北京 并发、大容量、高性能数据库设计与优化
知名某信息通信公司 NoSQL缓存数据库技术
北京 oracle数据库SQL优化
中国移动 IaaS云平台-主流数据库及存储技术