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对象存储