Ceph基本原理介绍

•
重要概念
• PGLog
• • PGLog主要设计用户osd临时故障恢复后pg的恢复； PGLog 由 PG 维护并且记录了该 PG 所有的操作，其非常类似于关
系型数据库领域的 undo log；
• PGLog 与 Journal 概念不同，Journal 是底层单机存储模块用来维护 事务一致性的，它是数据库领域的 redo log； • PGLog 通常只保存 PG 最近几千条的操作记录，但是在 PG 处于 Degraded 状态时，PGLog 会保存更多的日志条目期望能在故障 PG 重新上线后用来恢复数据。
• Reliable, Automatic, Distributed, Object Store • Rados提供对象存储接口； • Rados负责维护集群状态及数据分发。
• Ceph底层采用对象存储，其它存储 接口基于对象存储接口进行二次封装。
Rados基本组件
• Rados由两类组件构成
• OSD（Object Storage Device） 负责数据的存储和维护。 • Monitor 负责集群状态的维护及检测。 为消除单点故障，monitor组 件也是集群形式。
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的对应关系；
• •
重要概念
• OSDMap
• • • Cluster所有osd的信息，包括拓扑、状态等信息； OSD加入和退出或者节点权重的变化会引起osdmap的变化； Monitor, ceph client以及osd均存有OSDMap信息，且彼此版本可能不同，monitor维持最新的权威版本的 OSDMap。
•
关键处理流程
• OSD临时故障的恢复
• 在恢复过程中，PG的Primary OSD出现故障且未重新 选举出新的Primary OSD的时候，是 PG 唯一不处理请 求的阶段，但这个阶段通常会在1s内结束； • 在恢复期间故障 OSD 会维护 missing 列表，如果 IO 正好是处于 missing 列表的数据，那么 PG 会进行恢 复数据的“插队”操作，主动将该 IO 涉及的数据从 Replicate PG 拉过来，提前恢复该部分数据，此种情 形的延时一般在几十毫秒。
关键处理流程
• OSD永久故障处理
• 若OSD故障无法短期，Ceph将其视为永久性故障；
•
对于永久性故障的OSD，Ceph会将其从OSDMap
中剔除，并利用CRUSH算法对落在其上的PG重 新进行数据分布的计算，包括重新为PG分配OSD 以及计算Primary OSD；
•
新加入的OSD将从同PG的其它节点pull数据，恢 复自己的PG信息。
• • •
PG 开始接受 IO 请求，但是 PG 所属的故障节点仍存在过时数据，故障节点的 Primary PG 会发起 Pull 请求 从 Replicate 节点获得最新数据，Replicate PG 会得到其他 OSD 节点上的 Primary PG 的 Push 请求来恢复 数据 恢复完成后标记自己 Clean
•
OSDMap的同步——慢传播
• • Monitor 随机的挑选一些 OSD 更新 OSDMap； Monitor仅直接通知需要了解该变化的节点，如一个新的 OSD 加入会导致一些 PG 的迁移，那么这些 PG 的 OSD 会得到通知； 同一个PG中的OSD进行通信时会附带osdmap的epoch，若版本不一致，则具有更高版本osdmap的osd会将 其拥有的osdmap信息push到低版本osdmap的osd； 在集群空闲时，很有可能需要更长的时间完成新 Map的更新。
关键处理流程
• 块设备数据写流程
• • librbd根据image id、data offset 和data length，以及striping配置参数，计算 数据快对应的object set； Rados对计算得到的object将其映射到PG，得到pgid；
关键处理流程
• Rebalance(PG迁移)
• • • 新加入的OSD会导致OSDMap的更新； OSDMap的更新传播采用按需和慢传播两种模式； Ceph会根据集群的当前负载情况选择是否进行PG的迁移，决策依据是空间利用率、带宽负载以及集群闲忙 状况等； • • • • • 若选择迁移的OSD是Primary OSD，Monitor会首先将其它Replicated且不做迁移的OSD设为Primary OSD； 更新PGMap信息，并将更新后的PGMap直接push到相关的OSD（包括迁移出的OSD）； 新加入的从PG的其它节点获取PG中objects数据； 迁移出PG的OSD将删除不属于自己所拥有的PG中的objects； 迁移过程会造成IO性能的下降。
•
•
重要概念
• 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 上。
Ceph基本原理介绍
讲师 ： 景芳华
目录
• Why Ceph
• Ceph Cluster的基本结构
• Ceph的几个重要概念 • Ceph Cluster中的关键流
程
Why Ceph?
• 大数据时代企业级存储产 品需求
Why Ceph
• Ceph的定位
基本结构
• 模块架构
基本结构
• 底层Rados模块是Ceph分布式存储 的根本
关键处理流程
• OSD临时故障恢复 故障发生后，如果一定时间后重新上线故障 OSD，那么 PG 会进行以下流程:
• • 故障 OSD 上线，通知 Monitor 并注册，该 OSD 在上线前会读取存在持久设备的 PGLog； Monitor 得知该 OSD 的旧有 id，因此会继续使用以前的 PG 分配，之前该 OSD 下线造成的 Degraded PG 会 被通知该 OSD 已重新加入； 这时候分为两种情况，注意这个情况下 PG 会标志自己为 Peering 状态并暂时停止处理请求； 第一种情况是故障 OSD 所拥有的 Primary PG • 它作为这部分数据“权责”主体，需要发送查询 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的加入
• • • • • • • 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流 程。
• •
•
•
• •
第二种情况是故障 OSD 所拥有的 Replicate PG • 这时上线后故障 OSD 的 Replicate PG 会得到 Primary PG 的查询请求，发送自己这份“过 时”的元数据和 PGLog； Primary PG 对比数据后发现该 PG 落后并且过时，比通过 PGLog 建立了 missing 列表； Primary PG 标记自己处于 Active 状态。
关键处理流程
• OSD临时故障的恢复
• • • • • 某一个 OSD 下线； 如果 OSD 主动下线它会通知 Monitor 自己下线，请做好相关通知工 作； 如果是异常下线，那么其他 OSD 和 Monitor 会通过 Heartbeat 来得 知 OSD 下线同样让 Monitor 知晓； Monitor 重新计算该 OSD 所属PG的Primary OSD，并将结果主动 通知这些 PG 所在的 OSD； PG 将自己设为 Degraded 状态后，将会减小自己的副本数，并增加 保存的 PGLog 条目数。
• • •
重要概念
• 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的迁移。