当前位置： 首页 > news >正文

详解 Ceph 存储——CRUSH 算法

news 2025/10/24 13:27:10

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

  • 目录

    文章目录

    前言

    一、ceph集群对外提供的三种存储方式

    二、ceph分布式架构

    三、osd拆解

    四、CRUSH算法

    一、有中心节点的存储：查表式分布

    二、无中心节点的存储：计算式分布

    三、引出 CRUSH

    四、过半原则

    五、数据切片存储

    PG归置组

    主 OSD 的核心作用

    客户端请求入口

    数据写入协调与确认

    负责 PG 状态管理

    负责数据恢复与同步调度

    副本 OSD（Secondary OSD）的作用

    主 OSD 的选举机制

    总结对比

    六、存储池

    什么是 Ceph 存储池（Pool）

    存储池的作用

    数据隔离

    存储策略控制

    数据生命周期管理

    存储池的类型

    七、读写详解

    八、最终的访问如下图 

    附：PG选择OSD的具体算法

    总结

前言

在分布式存储的世界里，数据放在哪里，从来都是最核心、最复杂、也最考验架构设计的问题。
Ceph 作为目前最成熟的开源分布式存储系统之一，能够在成百上千台节点之间实现高可用、高扩展、无单点故障的存储能力，而这一切的底层逻辑支撑，都离不开一个关键算法——CRUSH（Controlled Replication Under Scalable Hashing）。

很多人初次接触 Ceph，会被它的“自我修复”“自动均衡”“无中心调度”这些特性所吸引，却鲜少深入思考：为什么 Ceph 能在不依赖中心目录或元数据服务器的情况下，快速而精准地定位数据？
答案，正是 CRUSH。

CRUSH 不仅是一种数据分布算法，更是一种哲学：它将“如何存储”和“存到哪里”这两个问题交给数学和逻辑去解决，而非依赖繁琐的查表机制。通过伪随机的可控映射、层次化的存储拓扑、权重控制与容错设计，Ceph 实现了真正意义上的 去中心化数据分布。

一、ceph集群对外提供的三种存储方式

底层是一个名为RADOS的基于对象的存储后端(和正常理解的对象存储还不太一样RADOS(Reliable Autonomic Distributed Object Store)可靠的自动分布式对象存储RADOS是具有自我检查、自我修复的基于软件的对象存储。

访问RADOS的方法很多：

  • 通过C，C++，Java，Python，Ruby，PHP调用LIBRADOS库访问
  • 通过RGW(RADOSGW)对象存储网关访问，RADOSGW可以提供RESTAPI变成接口(对象存储:Object Storage)
  • 通过RBD块方式访问，一般可以为虚拟机提供磁盘镜像文件(块存储:Block Storage)
  • 通过POSIX兼容的文件系统方式访问(文件系统存储:FilesystemStorage)

二、ceph分布式架构

MON(monitor):集群地图(maps)，帮助其他服务器之间的协同(coordinate)。

OSD(Object Storage Deivces):存储数据(store data)、处理数据复制(datareplication)、恢复数据(recovery)、重新平衡数据(rebalancing)

MDS(Metadata Servers):为文件系统共享存储元数据，允许客户端POSIX命令访问.。

RGW:对象存储网关，为原始的对象存储提供RestAPI接口。

三、osd拆解

每个OSD进程为ceph集群提供存储设备，通常存储设备都会被格式化为文件系统，目前红帽的Ceph存储仅支持XFS文件系统ACLs扩展数据xattrs用来存储对象的状态，快照信息，对象存储网关的访问控制列表等信息。attrs是XFS文件系统默认开启的功能。

四、CRUSH算法

有中心节点的存储：查表式分布

传统的分布式存储系统往往依赖一个**中心节点（或元数据服务器，MDS）**来维护整个集群的数据分布表。
当客户端要读写一个对象时，首先需要向中心节点请求该对象对应的存储位置，再由中心节点返回结果，客户端据此访问目标存储节点。

这种架构的优点在于：

  • 数据位置明确，逻辑简单；

  • 易于实现访问控制与数据统计；

  • 对小规模集群而言，性能尚可。

但随着节点规模扩张，问题也随之暴露：

  • 中心节点成为性能瓶颈与单点故障源；

  • 每次数据扩容、迁移都需要频繁更新全局分布表；

  • 查询路径过长，访问延迟明显增加；

  • 元数据同步和一致性维护成本高昂。

在这种模式下，整个系统的可扩展性被“中心”牢牢限制住了。

无中心节点的存储：计算式分布

Ceph 的设计理念恰恰相反——它彻底抛弃了中心目录结构。
客户端不再依赖元数据服务器去查询数据位置，而是通过一套分布式的计算算法，直接根据对象名、集群拓扑结构、权重信息等要素，自行计算出数据的存储位置。

这意味着：

  • 每个客户端都能独立得出一致的分布结果；

  • 新增或移除节点时无需大规模迁移数据；

  • 集群具备天然的负载均衡与容错能力；

  • 系统真正实现了去中心化的数据调度。

实现这一切的关键，就是 CRUSH（Controlled Replication Under Scalable Hashing）算法。

引出 CRUSH

CRUSH 的核心思想在于：
通过一种可控的伪随机映射机制，让同一份输入（对象 ID + 集群映射表）在任何节点上都能得到相同的输出结果（存储位置）。
它以数学的优雅取代了人工的调度，以算法的确定性取代了中心节点的脆弱性。

在接下来的内容中，我们将深入解析 CRUSH 的设计原理、数据映射过程，以及它如何让 Ceph 实现“无中心化”的高效数据分布与自我修复。

过半原则

客户端如果有一个test.txt文件，他可以直接连接OSD存储集群为了保障数据的安全，ceph默认3副本，所以最少3台主机，三个OSD(3块硬盘)

为了保障地图和集群通信的安全，MON最少3台(MON的设计，使用的是过半原则)

当有2台主机做MON，坏1台，剩1/2，没有过半(集群瘫痪)

当有3台主机做MON，坏1台，剩2/3，过半了(集群正常)

当有3台主机做MON，坏2台，剩1/3，没有过半(集群瘫痪)

当有5台主机做MON，坏2台，剩3/5，过半了(集群正常)所以，使用过半原则设计的集群，服务器个数都是奇数台

五、数据切片存储

数据的一个切片：foo  假设ceph有3台主机集群、每台主机两个硬盘，osd的数据从osd0到osd5，共6个硬盘

1.对foo进行计算hash值、hash（foo）%6=2  #这里假设计算结果是2

2.数据直接写入node2节点的第一块硬盘

• 缺点：当增加节点或删除节点，需要对所有数据重新计算HASH值，重新均衡数据(rebalancing)

PG归置组

增加PG归置组（可以理解为虚拟节点，逻辑概念）
对foo计算hash值，hash(foo)%3=3       #此时不在直接对osd进行取余计算、而是对pg数量取余
数据映射到PG3中（第二个PG），PG3下面对的是OSD0、OSD2、OSD5，其中第一个OSD为主OSD（primary），其他OSD为SecondOSD，数据写入主OSD，然后自动同步给其他Second OSD


CRUSH 算法会为每个对象计算出一个 Placement Group（PG），再由 PG 决定它的若干个副本应分布在哪几个 OSD（对象存储守护进程）上。

主 OSD 的核心作用

主 OSD（Primary OSD）在一个 PG 副本组中扮演“协调者”的角色。
它的主要职责包括以下几个方面：

客户端请求入口

客户端（Ceph Client）向 Ceph 读写数据时，只与主 OSD 通信。

  • 客户端通过 CRUSH 算法计算 PG → 主 OSD；

  • 所有写入操作都先发送给主 OSD；

  • 主 OSD 再负责同步数据到副本 OSD。

优点：
这样客户端就不需要同时与多个 OSD 通信，简化了通信逻辑与一致性控制。

数据写入协调与确认

当主 OSD 收到写入请求后：

  1. 写入本地数据；

  2. 将同样的数据请求转发给其他副本 OSD；

  3. 等待所有副本返回“写入成功”；

  4. 向客户端返回“操作完成”。

这保证了 Ceph 的强一致性（默认情况下）。

负责 PG 状态管理

每个 PG 由一个主 OSD 负责“代表整个 PG 汇报状态”。
包括：

  • 维护 PG 的最新映射关系；

  • 协调副本之间的数据对齐；

  • 参与恢复（recovery）与重平衡（rebalancing）操作；

  • 向 MON 报告 PG 的健康状态。

换句话说，主 OSD 就像这个 PG 的“队长”。

负责数据恢复与同步调度

当某个副本 OSD 宕机或恢复上线时：

  • 主 OSD 会检测到副本状态变化；

  • 触发恢复流程；

  • 将缺失的数据从健康副本同步过去。

副本 OSD（Secondary OSD）的作用

副本 OSD 主要是：

  • 接收主 OSD 的同步请求；

  • 存储相同的数据副本；

  • 在主 OSD 故障时，通过选举机制自动提升为新的主 OSD。

Ceph 的高可用机制正是建立在这种主从动态切换之上。

主 OSD 的选举机制

主 OSD 的选定是由 CRUSH 算法确定的，而非动态投票产生。
也就是说：

  • 每个 PG 都有固定的 OSD 列表（例如 [1,5,7]）；

  • 第一位永远是 Primary；

  • 如果 Primary 宕机，则第二位（osd.5）自动接管，成为新的 Primary；

  • 恢复后会根据权重重新分配。

总结对比

角色功能与客户端通信负责协调可被提升为主
主 OSD负责写入协调、PG 状态、同步、副本管理✅ 是✅ 是✅ 是
副本 OSD负责存储副本、响应主 OSD 同步请求❌ 否❌ 否✅ 可在主故障后提升

总结：

主 OSD 是某个 PG 副本组的“调度中枢”和“数据一致性协调者”，负责客户端交互与副本写入同步；副本 OSD 则是它的“后盾”，在主 OSD 故障时随时接手，确保 Ceph 集群的高可用与数据安全。

六、存储池

什么是 Ceph 存储池（Pool）

在 Ceph 中，存储池（Pool） 是逻辑上的数据分区或命名空间（Namespace），用于管理一组对象的存储策略。

你可以把 Pool 理解为：

一个拥有独立配置（副本数、存储规则、PG 数量、数据类型等）的逻辑“桶”，
Ceph 会把对象数据放进不同的桶里进行隔离和管理。

从上层看：

RBD（块设备）、CephFS（文件系统）、RGW（对象网关）等，
都是把数据存储在特定的 Pool 里。

存储池的作用

存储池在 Ceph 集群中主要承担以下职责：

数据隔离

不同业务、不同应用可以使用不同的存储池，互不影响。

例如：

一个 Pool 用于虚拟机镜像（高性能）

一个 Pool 用于归档存储（低成本）

每个 Pool 都有自己独立的数据分布规则和副本策略。

存储策略控制

每个 Pool 可以独立设置以下策略参数：

配置项    说明
size    副本数量（例如 3 表示 3 份副本）
pg_num    PG 数量（影响数据分布粒度）
crush_rule    使用哪条 CRUSH 规则（决定数据放在哪类设备上）
min_size    最小副本数，低于此数则不允许写入
compression    是否启用压缩
erasure_code_profile    若是纠删码池，使用哪种编码方案


数据生命周期管理

你可以针对 Pool 进行：

独立的配额（quota）设置；

快照（snapshot）管理；

数据迁移与回收策略控制。

这让 Ceph 可以灵活支持多租户、多业务并行运行。

存储池的类型

Ceph 支持两种主要类型的 Pool：

类型特点使用场景
副本池（Replicated Pool）多份完整副本（默认）通用存储、高可靠性
纠删码池（Erasure Coded Pool）分片 + 校验块，节省空间对可靠性要求高但读写不频繁的归档类场景

七、读写详解

当计算一个对象的位置时，Ceph 首先会根据对象名称、放置组（Placement Group，简称 PG）的总数（假设为32个），以及目标存储池（pool），来确定该对象应该属于哪个放置组。
一旦确定了放置组，Ceph 就会使用 CRUSH 算法 来计算出目标的 OSD（对象存储守护进程），也就是具体存放该对象的存储节点。

参数解释：32是PG的数量、生产环境中PG数量一旦确定就不要改动、初始数量设计可参考ceph官方文档的建议设计

picture=1 :表示一个池子名字叫picture 编号为1

1.21  表示后续进行CRUSH算法时候的初始值、真正存在哪个osd还要对1.21这个数，进行CRUSH计算

以下参数详解：

  • 9 表示的就是 rack9这个中间层（一个 bucket）表示一台主机的id或者一个机架；

  • 3   6   9  是最终的 OSD（真正存放对象数据的节点）。其中第一个作为主OSD，共3个副本的存储结构

所以：

“9” 表示 CRUSH 算法选择的中间存储位置（机架或主机），不是一个具体的 OSD。

过程如下：

Ceph 客户端会从监视器（Monitor）获取一份最新的集群地图（Cluster Map）。

这份地图包含了集群中所有 MON（监视器）、OSD（对象存储守护进程）以及 MDS（元数据服务器）的信息。

但这份地图不会直接告诉客户端每个对象存放在哪个 OSD 上。

客户端必须使用 CRUSH 算法 自行计算出需要访问的对象在集群中的位置。

客户端会对对象的 ID 进行哈希运算，然后对哈希结果取模（模数为该存储池的 PG 数量），以得到对象所属的 PG（Placement Group，放置组）编号。

接着，CRUSH 算法会根据 PG ID 计算出哪些 OSD 负责该 PG，这组 OSD 就是 Acting Set（执行集）。
在 Acting Set 中，当前状态为“up”（运行中）的那些 OSD 组成 Up Set（在线集）。
如果某个 OSD 宕机，它会被临时排除，直到恢复。

Up Set 中的第一个 OSD 是该 PG 的 主 OSD（Primary），其余的是 从 OSD（Secondary）。
主 OSD 负责协调写入、同步副本及一致性控制。

最后，客户端会直接与主 OSD 通信，以读取或写入对象数据。
客户端不需要经过 Monitor，也无需查询对象目录，完全依赖算法计算位置。

八、最终的访问如下图 

附：PG选择OSD的具体算法

第一个OSD：
hash(pg_id,osd_id,r) =draw    #拿pg_id和osd_id以及r求hash值，r为常数
draw*osd权重=straw               #取最大值，osd权重根据硬盘大小定义，1T权重为1，100G权重为0.1
第二个OSD
r=r+1
hash(pg_id,osd_id,r) =draw    #r为常数
draw*osd权重=straw               #取最大值
第三个OSD
r=r+1
hash(pg_id,osd_id,r) =draw    #r为常数
draw*osd权重=straw               #取最大值
这个计算整理为一个表

总结

以上的所有内容共同构成CRUSH计算、得到最终存储节点、中间osd之间的数据复制和纠删码计算略

http://www.dtcms.com/a/521308.html

相关文章：

  • 淘宝商品规格API接口：快速查询商品SKU价格及优惠信息
  • 深圳做网站乐云seo费用优惠wordpress如何设置分类目录
  • 全球蜂窝物联网模组市场格局与区域需求分析
  • 公司怎么做网站企业自建网站平台有哪些
  • 安徽网站开发费用住总集团公司宣传册设计样本
  • 【03】C语言 强制类型转换 与 进制转换
  • 【解决】Post “http://xxx/api/v1/query“: dial tcp xxx:9090: connect: ...
  • 做门户网站可以用的字体网站建设中常见的问题
  • pc网站建设和推广免费个人简历模板表格下载
  • lesson74：Vue条件渲染与列表优化：v-if/v-show深度对比及v-for key最佳实践
  • 网站页面设计工具wordpress微信查看密码
  • 商城站济宁建设局官方网站
  • 企业网站规范贴吧高级搜索
  • 厦门网站建设小程序开发宁波网站制作与推广价格
  • 做网站防护的网站新冠疫苗公司
  • 网站标题如何修改北京美的网站
  • 沈阳网站选禾钻科技seo销售
  • 像Linux的systemd一样创建一个windows系统服务，让nginx服务随windows系统启动而自动启动服务
  • lesson75：Vue 数据绑定实战：v-model 表单处理与 v-bind 样式控制全解析
  • 图的基本概念与操作
  • **发散创新：深度解析错误处理机制的设计与实现**在软件开发过程中，错误处理是不
  • app大全软件网站中国建筑网官网监理工程师网站
  • 三明网站建设公司免费秒开小游戏
  • 宿迁华夏建设集团网站东莞网络科技公司排名
  • NVIDIA NCCL 源码学习（十五）- Symmetric Memory
  • 3.无重复字符的最长子串
  • 网站开发范例文档wordpress新建页面慢
  • 什么是 Spring IOC 容器？
  • 重庆网站建设的好处网站建设不好
  • wordpress做游戏网站做logo赚钱的网站