Ceph 心得分享

Ceph

ceph :统一开、分布式的云存储
统一指的是 ceph 在业内同 openstack 、swift 一样可以当作 块存储、文件存储、对象存储来使用。并自带了分布式的特性,保证了生产业务的高可用。其主要核心高频的使用点就是 Ceph 的块存储以及对象存储,我们逐一介绍。

块存储特性

  • 通过 ceph clients 使用块设备
  • 精简配置
  • 动态扩容
  • 快照、克隆
  • 写实拷贝技术
  • caching
  • RBD 驱动已经集成到 Linux 内核中
  • 支持计算模块 kvm Qemu and libvirt
  • 支持虚拟和物理服务器
  • 支持 format-1 和 format-2 两种类型

对象存储

不能直接当问文件系统使用,只能通过 API 访问,面向 restfull 的 API 或者第三方的命令行,目前兼容了。
RESTful S3、RESTful Swift-compatible API、interfaces

Ceph 心得分享

Ceph 块设备基本操作

以下操作是在 Ubuntu 系统执行
安装 ceph 客户端
ceph-deploy install ceph-client 或者 apt-get install ceph

创建块设备
rbd create {image-name} --size {mebytes} --pool {pool-name}

列出块设备
rbd ls {poolname}

检索块信息
rbd --iamge {iamge-name} info

更改块大小
rbd resize --image {image-name} --size {mebytes}

删除块设备
rbd rm {image-name}

对象存储的关键组建

Ceph RADOS 组成

1、OSD,负责存储所有 objects 数据

2、Monitors 保存集群中所有 OSD 状态信息,以及负责管理 Cluster Map ,其中 Cluster Map 是整个 RADOS 系统的关键数据结构,管理集群中所有的成员、关系、属性 等信息以及数据的分发。多 Monitors 时,使用 paxos 算法来选择 leader ,避免单点故障;

RADOS

可靠的,独立自主的,分布式对象存储

  • 地位 cepth 存储集群的基石
  • 功能 存储数据,维护数据的一致性、可靠性
  • 执行策略 数据复制、故障检测和恢复、以及跨集群节点的数据迁移和重平衡等

OSD 底层存储设备

  • 数据存储
  • 数据复制
  • 数据回填(backfilling 一般触发在有新的 osd 加入时)
  • 重平衡(触发在新 OSD 加入 crush map 时)
  • 心跳、OSD 需要和与其共同承载同一个 PG 的其他 OSD 交换信息以确定各自是否工作正常,是否需要进行维护操作。

RADOS 设计思想

大前提是基于的对象寻址机制,流程图如下

Ceph 心得分享

RADOS 寻址流程解读

映射、映射、再映射...

File -> object 映射:

将用户态的 file ,映射成 RADOS 能够处理的 object ,是指以统一大小进行切块,并分配 ID ,便于管理以及方便对多个 object 并行处理。

Object -> PG 映射:

利用静态哈希函数得到 objectID 的伪随机值,再 “位与” mask 上使得每个 Object 获取属于自己的 PG;

PG -》 OSD 映射

将 PG 映射到数据的实际存储单元 OSD,RADOS 利用 crush 算法,由 pgid 得到一组 n 个 OSD ,再由 OSD deaemon 执行映射到本地 object 在本地系统中存储,访问、云数据维护等操作。
特别注意的是:该次映射功能性特别强;直接收到 cluster map 以及 rule 的影响,只有在 cluster map 和存储策略均不发生改变时,PG 和 OSD 映射关系才固定。

计算 PG 的 ID 示例

  • client 输入 pool ID 和对象 ID (如 pool = 'chenlu',object-id = ‘sanqian')
  • crush 获得对象 ID 对其 hash
  • crush 计算 osd 个数 hash 取模获取得 PG 的 ID
  • crush 获取已命名 pool 的 ID (如 chenlu=4)
  • crush 预先考虑到 pool id 相同的 pgid

Ceph 心得分享

对象存储的写入流程

以 3 副本的例子画图介绍
Ceph 心得分享

写流程解读(数据副本强一致性)

  • 某个 client 需要向 Ceph 集群写入 file 时,将 file 分割为 N 个 object 之后,确定存储该 N 个 Object 的 N 组 OSD 。假设副本书为 3 ,下面取其中一个 object 以及对应的一组 OSD 来说明,这一组中 3 个 OSD 具有各自不同的序号,第一序号 OSD 为这一组的 Primary OSD ,而后两个则一次是 Secondary OSD 和 tertiary OSD
  • 确定三个 OSD 之后,client 直接与 Primary OSD 通信,发起写入操作,primary OSD 收到请求后,分别向 Secondary OSD 和 Tertiary OSD 发起写入操作做。当 Secondary OSD 和 Tertiary OSD 各自完成写入操作后,将分别向 Primary OSD 发送确认信息。当 Primary OSD 确信其他两个 OSD 的写入完成后,则自己也完成数据写入,并向 client 确认 object 写入操作完成。
  • 采用这样的写入流程,本质上是为了保证写入过程中的可靠性,尽可能避免造成数据丢失。

对象存储的 CRUSH 机制

CRUSH 是整个 object 落盘分配的核心

CRUSH 算法根据每个设备的权重经可能概率平均地分配数据,分布算法是由集群可用存储资源以及其逻辑单元的 map 控制的,这个 map 的描述类似于一个大型服务器的描述:服务器由一系列的机柜组成,机柜装满服务器,服务器装满磁盘,数据分配的策略是由定位规则来定义的,定位规则指定了集群中将保存多少个副本,以及数据副本的放置有什么限制。

例如,可以制定数据有三个副本,这三个副本必须放置在不同的机柜中,是的三个数据副本不公用一个物理电路。

例如,一个机架上有 20 个服务器,每个服务器有 2 个 disk ,一排有 8 个机架,有 10 排;担心其中一个服务器宕机,可以设定 crush map ,确保这个服务器熵的数据至少复制到其他 2 个服务器上;担心其中一个机架上断电,确保副本存储在其他机架上,独立于主复制。

Ceph 集群容灾

1、primary 从其他 osd 收集 pg log ,获得一份完整、全序的操作表,并让其他 osd 认同这份操作表,该过程叫做 peering;在该过程中,primary osd 负责协调 peering 过程,若 primary out 或 down,则 second osd来充当 primary osd;

2、peering 之后进入 active+ recovering 状态;迁移以及同步 object 到所有副本上,确保 object 副本为 N

3、扩容的形态分为 scale up 和 scale out

上一篇:【100个 Unity小知识点】 | Unity中的 eulerAngles、localEulerAngles细节剖析


下一篇:静态 CDN 加速,命中率过低