没有合适的资源?快使用搜索试试~ 我知道了~
首页ceph工作原理和安装
ceph工作原理和安装
需积分: 12 141 浏览量
更新于2023-05-25
评论
收藏 852KB PDF 举报
ceph工作原理和安装,可以知道ceph的工作原理,方便用户后续去安装ceph和使用它
资源详情
资源评论
资源推荐

ceph 工作原理和安装
一 、 概 述
Ceph
是一个分布式存储系统,诞生于
2004
年,最早致力于开发下一代高性能分布式文
件系统的项目。随着云计算的发展,
ceph
乘上了
OpenStack
的春风,进而成为了开源社区
受关注较高的项目之一。
Ceph
有以下优势:
1. CRUSH 算法
Crush
算法是
ceph
的两大创新之一,简单来说,
ceph
摒弃了传统的集中式存储元数据
寻址的方案,转而使用
CRUSH
算法完成数据的寻址操作。
CRUSH
在一致性哈希基础上很好
的考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。
Crush
算法有相当强大的扩展性,理论上支持数千个存储节点。
2. 高可用
Ceph 中的数据副本数量可以由管理员自行定义,并可以通过 CRUSH 算法指定副本的物
理存储位置以分隔故障域,支持数据强一致性; ceph 可以忍受多种故障场景并自动尝试并
行修复。
3. 高扩展性

Ceph
不同于
swift
,客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时,
代理节点很容易成为单点瓶颈。
Ceph
本身并没有主控节点,扩展起来比较容易,并且理论
上,它的性能会随着磁盘数量的增加而线性增长。
4. 特性丰富
Ceph
支持三种调用接口:对象存储,块存储,文件系统挂载。三种方式可以一同使用。
在国内一些公司的云环境中,通常会采用
ceph
作为
openstack
的唯一后端存储来提升数据
转发效率。
二 、 CEPH 的 基 本 结 构
Ceph 的基本组成结构如下图:
Ceph 的底层是 RADOS,RADOS 本身也是分布式存储系统,CEPH 所有的存储功能都是基
于 RADOS 实现。RADOS 采用 C++开发,所提供的原生 Librados API 包括 C 和 C++两种。Ceph

的上层应用调用本机上的
librados API
,再由后者通过
socket
与
RADOS
集群中的其他节点通
信并完成各种操作。
RADOS GateWay
、
RBD
其作用是在
librados
库的基础上提供抽象层次更高、更便于应用
或客户端使用的上层接口。其中,
RADOS GW
是一个提供与
Amazon S3
和
Swift
兼容的
RESTful
API
的
gateway
,以供相应的对象存储应用开发使用。
RBD
则提供了一个标准的块设备接口,
常用于在虚拟化的场景下为虚拟机创建
volume
。目前,
Red Hat
已经将
RBD
驱动集成在
KVM/QEMU
中,以提高虚拟机访问性能。这两种方式目前在云计算中应用的比较多。
CEPHFS
则提供了
POSIX
接口,用户可直接通过客户端挂载使用。它是内核态的程序,
所以无需调用用户空间的
librados
库。它通过内核中的
net
模块来与
Rados
进行交互。
三、Ceph 的基本组件

如上图所示,Ceph 主要有三个基本进程
Osd
用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向
其他 osd 守护进程发送心跳,然后向 Mon 提供一些监控信息。
当 Ceph 存储集群设定数据有两个副本时(一共存两份),则至少需要两个 OSD 守护进程
即两个 OSD 节点,集群才能达到 active+clean 状态。
MDS(可选)
为 Ceph 文件系统提供元数据计算、缓存与同步。在 ceph 中,元数据也是存储在 osd
节点中的,mds 类似于元数据的代理缓存服务器。MDS 进程并不是必须的进程,只有需要
使用 CEPHFS 时,才需要配置 MDS 节点。
Monitor
监控整个集群的状态,维护集群的 cluster MAP 二进制表,保证集群数据的一致性。
ClusterMAP 描述了对象块存储的物理位置,以及一个将设备聚合到物理位置的桶列表。
四 、 OSD
首先描述一下 ceph 数据的存储过程,如下图:

无论使用哪种存储方式(对象、块、挂载),存储的数据都会被切分成对象(
Objects
)。
Objects size
大小可以由管理员调整,通常为
2M
或
4M
。每个对象都会有一个唯一的
OID
,
由
ino
与
ono
生成,虽然这些名词看上去很复杂,其实相当简单。
ino
即是文件的
File ID
,
用于在全局唯一标示每一个文件,而
ono
则是分片的编号。比如:一个文件
FileID
为
A
,它
被切成了两个对象,一个对象编号
0
,另一个编号
1
,那么这两个文件的
oid
则为
A0
与
A1
。
Oid
的好处是可以唯一标示每个不同的对象,并且存储了对象与文件的从属关系。由于
ceph
的所有数据都虚拟成了整齐划一的对象,所以在读写时效率都会比较高。
但是对象并不会直接存储进
OSD
中,因为对象的
size
很小,在一个大规模的集群
中可能有几百到几千万个对象。这么多对象光是遍历寻址,速度都是很缓慢的;并且如果将
对象直接通过某种固定映射的哈希算法映射到
osd
上,当这个
osd
损坏时,对象无法自动迁
移至其他
osd
上面(因为映射函数不允许)。为了解决这些问题,
ceph
引入了归置组的概
念,即
PG
。
PG
是一个逻辑概念,我们
linux
系统中可以直接看到对象,但是无法直接看到
PG
。
它在数据寻址时类似于数据库中的索引:每个对象都会固定映射进一个
PG
中,所以当我们
要寻找一个对象时,只需要先找到对象所属的
PG
,然后遍历这个
PG
就可以了,无需遍历所
有对象。而且在数据迁移时,也是以
PG
作为基本单位进行迁移,
ceph
不会直接操作对象。
对象时如何映射进
PG
的?还记得
OID
么?首先使用静态
hash
函数对
OID
做
hash
取出特征码,用特征码与
PG
的数量去模,得到的序号则是
PGID
。由于这种设计方式,
PG
的数量多寡直接决定了数据分布的均匀性,所以合理设置的
PG
数量可以很好的提升
CEPH
集群的性能并使数据均匀分布。
剩余36页未读,继续阅读














安全验证
文档复制为VIP权益,开通VIP直接复制

评论0