Ceph分布式存储底层实现原理

Server SAN (分布式存储) 概念

由多个独立的服务器自带的存储组成一个存储资源池 同时融合的存储和计算资源

SDS(软件定义存储)

将硬盘资源整合起来 并通过软件编程来定义这些资源

软件定义的存储

• 可编程、策略驱动
• 存储虚拟化，资源池化
• 异构存储资源管理
• API呈现系统能力

​​存储资源层​​

• 传统软硬件一体的存储资源
• 基于软件的/标准硬件的存储

SDS与传统存储对比

​​传统的存储系统设计​​

自低向上

首先把很多磁盘组Disk Group配RAID
在RAID上配存储池
再存储池上配LUN
把LUN映射为上层业务主机来用
即先创建500G的LUN 映射给主机使用

​​SDS存储系统设计​​

自顶向下

首先会做一个大的存储池 比如500T
在虚拟化层面或云平台对接这个存储池
创建一个虚拟机 比如占用500G空间磁盘
默认会在存储池中创建一个vDisks
而不需要在之前先创建一个vDisks给应用来用
而是把整个存储池给应用来用
通过云平台创建一个500G的硬盘 
会自动在存储池中创建一个500G的虚拟硬盘

存储池底下有很多硬盘组合在一起
所有服务器通常不配置RAID
不配置RAID那如何硬盘故障了怎么办？
所有的分布式存储有2种解决方案
1、副本机制（比如3复制 一份数据在3台服务器的硬盘中）
2、EC算法
2种机制保证数据的可靠性

​​数据副本​​

数据以及副本是不在一台服务器中的
也有可能不在同一个机柜里面
也有可能不在同一个机房里面

新业务催生新资源供给模式

​​传统烟囱式​​

SAN:提供一个裸设备 从存储上划一个空间映射到主机上
主机上看到的是一个硬盘 
需要在主机上对这个硬盘进行分区格式化

NSA:相当于在Windows中把一个文件夹共享出去
在另外一个Windows上可以访问到这个共享
以文件的形式共享

烟囱式：每一个存储提供给自己的业务
比如SAN存储提供给数据库使用
没有办法做到弹性扩展

劣势

• 资源利用不均衡

烟囱式存储比如一个LUN 500G硬盘 这个LUN特别忙 这个LUN所在的硬盘就会出现瓶颈
另一个LUN 500G硬盘 这个LUN很空闲

而分布式存储所有的数据存储都均衡的存储在后端的各个硬盘中
是所有服务器 所有硬盘一起参与 所以不可能出现烟囱式的这种瓶颈

• 扩展性差
• 多系统平台管理

​​新架构-云​​

Ceph

​​Ceph统一存储架构​​

相当于原来买三台不一样的存储
现在买一台存储就可以提供3种不一样的接口

可以划分不同的存储池 
一个存储池用来对象存储
一个存储池用来块存储
一个存储池用来文件存储 把存储池格式化成Ceph文件系统
用来存放文件即CephFS
一个存储池只能做一个事情

CephFS组件

​​存储数据的过程​​

假设有5台服务器
每台服务器上有12个硬盘
每个硬盘1TB
那么共有60TB的硬盘
数据3副本的话 那么共有200TB的磁盘空间

假设客户端需要存储100M的文件
1、首先客户端会进行分片 
2、通过业务网络上传到ceph
3、ceph通过DHT算法进行hash运算 找到一个节点如node1
4、通过后端网络 对在node1上的数据进行备份 
如图在node2上有一个备份数据

​​mon(monitor角色)​​

存放切片的元数据
记录所有的映射表关系 里面保存的是元数据metadata也需要3个副本

当下次读取数据的时候 通过映射表就可以知道这个文件的数据存储在哪个节点上

比如100M的文件 分2片 
一片数据50M记为A 
另外一片数据也是50M记为B
A数据ceph通过hash算法指向了node1记为D1
同时通过后端网络在node2上有一个备份D1‘
B数据ceph通过hash算法指向了node3记为D2
同时通过后端网络在node4上有一个备份D2’

那么这个映射关系在monitor中会记录

客户端想要获取该数据的时候 就会从monitor中获取映射关系
然后进行整合各个节点上的分片数据

​​ceph集群至少3个节点​​

因为数据需要3副本
mon（monitor）的metadata映射关系数据也需要3副本
所以ceph集群至少需要部署3个节点

如果有100个节点 也需要部署3个节点的monitor即可
其他节点都是OSD角色

​​OSD(object Storage Device) 对象存储设备​​

一个硬盘对应一个OSD
一个OSD其实是一个进程 对应一个物理硬盘
OSD相对于Ceph来说 它是一个逻辑硬盘
OSD会存储真正的数据

​​3节点能解决脑裂​​

在集群中通过投票机制来防治脑裂
每个节点投一票

分布式集群下面有4个节点

如果由于网络原因导致 

node1和node2在一个网络 记为A

node3和node4在另外一个网络 记为B

网络A和网络B是隔绝的

所以就可能出现2个网络的节点往共享存储池中针对同一份数据存储多次
并且由于node和node2不知道其他节点的存在 所以就会尽可能的抢占集群资源

为了解决这个问题 就采用投票机制

SUM/2+1即总票数/2+1 

如上图 4/2+1=3票

如果集群中4个节点有3个节点是存活的 就会工作

如果在集群中有3个节点 3/2+1=2 如果有2个节点就会继续工作

如果出现了脑裂即 node1和node2在一个网络 记为网络A
node3和node4在另外一个网络 记为网络B

网络A中还剩2个节点 那么就自杀了 

因为这个时候死掉比活着更安全

死掉充其量业务宕掉了

如果不死 那么就会把数据搞乱了

所以一半不会部署双数的节点 而是部署单数的节点 

​​MDS (MetaData Server)​​

只有CephFS才会有这个角色
这个是存放文件系统的元数据（比如把文件系统格式成NTFS或EXT4 往EXT4写数据）
但因为是分布式文件系统 它有一个专门的角色来存放这个元数据
所以这个不是必须的 是可选的
而monitor是存放切片的元数据

Ceph关键概念

mon会计算数据存放在哪个osd 最后写到哪个硬盘中去
mds也可以存放多份

Ceph数据存储过程

一个文件进行切片
每一小块对应一个对象编号oid
对oid尽性hash计算 并加上一个掩码 得到一个gpid

"gp类似于一个文件夹 里面存放的是一个一个小的切片"

gpid是文件夹编号

然后通过crush算法 知道了 gpid这个文件夹里面的文件存放在哪些osd中

​​PG数量规划​​

Placement Group 归置组

不管通过什么方式写入数据进来
通过crushmap映射表路由到某一个pg
然后有pg把数据写入到osd中
osd写入到硬盘中

​​Crushmap算法​​

​​假设一个存储池有10个唯一数据的分片​​

如果算上副本的话 那么有30个分片
crushmap就是把pg数据打散写到各个硬盘中
monitor会管理crushmap

​​Hash环​​

在创建存储池的一刹那 会把硬盘切分成很多分 放在一个map中
一个文件被切了10个分片 那么就会有10个oid
对oid进行hash计算 则一定会在hash环上找到一个位置

​​缺点：数据量特别多 每次寻址特别慢​​

假设有1000万个对象 monitor记录的映射数据就特别多
每次查询的时候就特别慢
为了解决这个问题 就引入了pg 归置组的概念

​​hash(oid) & mask 得到一个pgid​​

比如有128个pg 
hash(oid)值加上一个掩码得到一个pgid
所以把数据写入到pg来
pg是一个逻辑的概念 
相当于一个文件夹 文件夹里面放了很多文件
通过文件夹找文件就很方便
没有文件夹的话 直接找文件 就会很慢

然后通过crush算法把gp数据写入到一些osd中

​​pg优势​​

缩小搜索区域 提高查询速度

不用PG用PG

​​pg的数量越多越好？​​

取值是2的n次方
计算公式：（osd的数量 * 每个osd的pg数）/ 副本数 / 存储池的数量

每个osd的pg数量 默认是100
存储池的数量比如是2

比如 9个osd
9*100/3/2=150
pg的取值是2的n次方
比150大的就是256
所以pg的数量是256

pg数量是在创建的时候规划的

​​OSD写流程​​

客户端写到主的缓存中
主的缓存写到2个副本的缓存
2个副本的缓存写入成功之后再回应给主
主副本在回应给客户端

​​oracle数据库后端存储可以用ceph​​

​​ceph也可以对接RGW对象存储​​