Ceph基本原理介绍

– 在集群空闲时，很有可能需要更长的时间完成新 Map的更新。
重要概念
• PG(Placement group)
– Pool内部的虚拟概念，无实体对应， Pool中的PG number是可配置的； – Object与osd的中间逻辑分层，object固定属于某个PG（由crush算法决 定），PG与osd存在对应关系； – PG和OSD之间是多对多的对应关系，即一个PG对应多个OSD，同时一个 OSD可能对应不同的PG； – 每一个PG都有一个primary OSD和多个Secondary OSD，object会被分发到 这些osd上进行存储； – PG中primary osd负责写操作，读操作可由replica osd完成； – PG中primary osd默认为pg中第一个osd，当 OSD 发生故障时(意外 crash 或 者存储设备损坏)，Monitor 会将该 OSD 上的所有角色为 Primary 的 PG 的 Replicated 角色的 OSD 提升为 Primary PG，这个 OSD 所有的 PG 都会处于 Degraded 状态； – PG中处于degraded状态的PG若无法恢复，该OSD 会被踢出集群，这些 PG 会被 Monitor 根据 OSD 的情况分配到新的 OSD 上 – PG作为 Object 的拥有者，负责维护 Object 的信息； – PG 的数据和相关故障恢复、迁移所必须的记录都是由每个 PG 自己维护， 也就是存在于每个 PG 所在的 OSD 上。
关键处理流程
• Rebalance(PG迁移)
– 新加入的OSD会导致OSDMap的更新； – OSDMap的更新传播采用按需和慢传播两种模式； – Ceph会根据集群的当前负载情况选择是否进行PG的迁移，决策依据是空 间利用率、带宽负载以及集群闲忙状况等； – 若选择迁移的OSD是Primary OSD，Monitor会首先将其它Replicated且不做 迁移的OSD设为Primary OSD； – 更新PGMap信息，并将更新后的PGMap直接push到相关的OSD（包括迁移 出的OSD）；
–
第二种情况是故障 OSD 所拥有的 Replicate PG
• • •
– –
PG 开始接受 IO 请求，但是 PG 所属的故障节点仍存在过时数据，故障节点的 Primary PG 会发起 Pull 请求从 Replicate 节 点获得最新数据，Replicate PG 会得到其他 OSD 节点上的 Primary PG 的 Push 请求来恢复数据 恢复完成后标记自己 Clean
– PGLog 通常只保存 PG 最近几千条的操作记录，但是在 PG 处
于 Degraded 状态时，PGLog 会保存更多的日志条目期望能 在故障 PG 重新上线后用来恢复数据。
关键处理流程
• 新osd的加入
– OSD 会向 Monitor 申请加入，Monitor 验证其信息后会将其加入 OSDMap 并标记为IN； – 同时monitor将申请加入的osd放在 Pending Proposal 中，并会在下 一次 Monitor “讨论”中提出； – OSD 在得到 Monitor 的回复信息后发现自己仍然没在 OSDMap 中 会继续尝试申请加入； – 接下来 Monitor 会发起一个 Proposal ，申请将这个 OSD 加入 OSDMap 并且标记为 UP ； – 按照 Paxos 的流程，从 proposal->accept->commit 到最后达成一致， OSD 最后成功加入 OSDMap ，OSD状态变为UP； – 新的 OSD 获得最新 OSDMap 发现其已经在其中时，不再向Monitor 发起加入申请； – OSD开始建立与其他OSD的连接，Monitor 开始给其分配PG，进入 PG迁移即rebalance流程。
操作，主动将该 IO 涉及的数据从 Replicate PG 拉过来，提前
恢复该部分数据，此种情形的延时一般在几十毫秒。
关键处理流程
• OSD永久故障处理
– 若OSD故障无法短期，Ceph将其视为永久性故障； – 对于永久性故障的OSD，Ceph会将其从OSDMap中 剔除，并利用CRUSH算法对落在其上的PG重新进行 数据分布的计算，包括重新为PG分配OSD以及计算 Primary OSD； – 新加入的OSD将从同PG的其它节点pull数据，恢复 自己的PG信息。
重要概念
• OSDMap
– Cluster所有osd的信息，包括拓扑、状态等信息；
– OSD加入和退出或者节点权重的变化会引起osdmap的变化； – Monitor, ceph client以及osd均存有OSDMap信息，且彼此版本可能不同， monitor维持最新的权威版本的OSDMap。
• OSDMap的同步——慢传播
重要概念
• PGLog
– PGLog主要设计用户osd临时故障恢复后pg的恢复； – PGLog 由 PG 维护并且记录了该 PG 所有的操作，其非常类似
于关系型数据库领域的 undo log；
– PGLog 与 Journal 概念不同，Journal 是底层单机存储模块用 来维护事务一致性的，它是数据库领域的 redo log；
关键处理流程
• OSD临时故障的恢复
– 在恢复过程中，PG的Primary OSD出现故障且未重新选举出 新的Primary OSD的时候，是 PG 唯一不处理请求的阶段，但
这个阶段通常会在1s内结束；
– 在恢复期间故障 OSD 会维护 missing 列表，如果 IO 正好是处 于 missing 列表的数据，那么 PG 会进行恢复数据的“插队”
OSD的逻辑结构
• 系统部分（Object Storage Device）
本质上是安装了操作系统及文件系统的计算机， 并带有存储介质。
• 守护进程（ OSD Daemon ）
OSD系统平台的守护进程，主要负责存储和查找 对象，并且负责向该对象的复制节点分发和恢复。
重要概念
• Pool
– 每个cluster可创建多个pool； – Pool是逻辑上的隔离单位，不同的pool可以具 有完全不同的数据处理方式，如replica size， PG numbers，CRUSH rules，Snapshots， ownership等配置均通过pool进行隔离； – Ceph中的任何操作必须先指定pool，无论是块 存储或对象存储； – Pool具体的OSD没有mapping的对应关系；
关键处理流程
• OSD临时故障的恢复
– 某一个 OSD 下线； – 如果 OSD 主动下线它会通知 Monitor 自己下线，请做好相关 通知工作； – 如果是异常下线，那么其他 OSD 和 Monitor 会通过 Heartbeat 来得知 OSD 下线同样让 Monitor 知晓； – Monitor 重新计算该 OSD 所属PG的Primary OSD，并将结果 主动通知这些 PG 所在的 OSD； – PG 将自己设为 Degraded 状态后，将会减小自己的副本数， 并增加保存的 PGLog 条目数。
– Monitor 随机的挑选一些 OSD 更新 OSDMap； – Monitor仅直接通知需要了解该变化的节点，如一个新的 OSD 加入会导致 一些 PG 的迁移，那么这些 PG 的 OSD 会得到通知； – 同一个PG中的OSD进行通信时会附带osdmap的epoch，若版本不一致，则 具有更高版本osdmap的osd会将其拥有的osdmap信息push到低版本 osdmap的osd；
– Reliable, Automatic, Distributed, Object Store – Rados提供对象存储接口； – Rados负责维护集群状态及数据分发。
• Ceph底层采用对象存储，其它存储接口基 于对象存储接口进行二次封装。
Rados基本组件
• Rados由两类组件构成
– OSD（Object Storage Device） 负责数据的存储和维护。 – Monitor 负责集群状态的维护及检测。 为消除单点故障，monitor组件也是集群形式。
•
• • •
它作为这部分数据“权责”主体，需要发送查询 PG 元数据请求给所有属于该 PG 的 Replicate 角色节点；
该 PG 的 Replicate 角色节点实际上在故障 OSD 下线时期间成为了 Primary 角色并维护了“权威”的 PGLog，该 PG 在得到故障 OSD 的 Primary PG 的查询请求后会发送回应； Primary PG 通过对比 Replicate PG 发送的元数据和 PG 版本信息后发现处于落后状态，因此它会合并得到的 PGLog并建立“权 威” PGLog，同时会建立 missing 列表来标记过时数据； Primary PG 在完成“权威” PGLog 的建立后就可以标志自己处于 Active 状态； 这时上线后故障 OSD 的 Replicate PG 会得到 Primary PG 的查询请求，发送自己这份“过时”的元数据和 PGLog； Primary PG 对比数据后发现该 PG 落后并且过时，比通过 PGLog 建立了 missing 列表； Primary PG 标记自己处于 Active 状态。
Ceph基本原理介绍
目录
• • • • Why Ceph Ceph Cluster的基本结构 Ceph的几个重要概念 Ceph Cluster中的关键流程
Why Ceph?
• 大数据时代企业级存储产品需求
Why Ceph
• Ceph的定位
基本结构
• 模块架构
基本结构
• 底层Rados模块是Ceph分布式存储的根本
– 新加入的从PG的其它节点获取PG中objects数据；
– 迁移出PG的OSD将删除不属于自己所拥有的PG中的objects； – 迁移过程会造成IO性能的下降。
关键处理流程
• 块设备数据写流程
– librbd根据image id、data offset 和data length，以及striping配置参数，计 算数据快对应的object set； – Rados对计算得到的object将其映射到PG，得到pgid； – Rados利用CRUSH算法计算得到object所在PG的osd up set； – Client直接与up set中的primary osd通信，发起写入操作（对于读操作，可 以采用replicated osd）； – Primary OSD收到写请求后，分别向其余的replicated OSD发起写操作；
重要概念
• PG Map
– PGMap 是由 Monitor 维护的所有 PG 的状态； – OSD仅维护自己所拥有的PG状态； – Monitor会根据所掌握的所有PG的状态确定是否需要进行PG迁移， 即rebalance； – 当monitor根据cluster配置值及集群状态决定对某个PG进行迁移时， 首先会更新其对应的PGMap，并将该PGMap push到相关的OSD； – OSD 启动并加入 OSDMap 后，Monitor 会通知这个OSD需要创建和 维护的 PG ，当存在多个副本时，PG 的 Primary OSD 会主动与 Replicated 角色的 OSD 通信并且沟通 PG 的状态，其中包括 PG 的 最近历史记录，新的 OSD 会得到其他 PG 的全部数据然后逐渐达 成一致，或者 OSD 已经存在该 PG 信息，那么 Primary PG 会比较 该 PG 的历史记录然后达成 PG 的信息的一致（peering）； – 对于新加入集群的osd，没有pg需要同步（peering），monitor决 定pg的迁移。
关Leabharlann Baidu处理流程
• OSD临时故障恢复 故障发生后，如果一定时间后重新上线故障 OSD，那么 PG 会进行以下流程:
– – – – 故障 OSD 上线，通知 Monitor 并注册，该 OSD 在上线前会读取存在持久设备的 PGLog； Monitor 得知该 OSD 的旧有 id，因此会继续使用以前的 PG 分配，之前该 OSD 下线造成的 Degraded PG 会被通知该 OSD 已重新加入； 这时候分为两种情况，注意这个情况下 PG 会标志自己为 Peering 状态并暂时停止处理请求； 第一种情况是故障 OSD 所拥有的 Primary PG