带你读《存储漫谈:Ceph原理与实践》——2.2.1 Ceph 寻址流程

简介: 带你读《存储漫谈:Ceph原理与实践》——2.2.1 Ceph 寻址流程

2.2  Ceph 数据寻址


在从方案演进及变迁的较为宏观角度对比了分布式存储系统的有中心架构与无中心架构寻址方式之后,本小节将深入 Ceph 存储系统的数据寻址方案,进行详细介绍。

在 PB 级数据存储和成百上千台存储服务器纳管的需求背景下,大规模分布式存储系统必须做到数据和负载的均衡分布,以此来提高资源利用率,最大化系统的性能输出,同时要处理好系统的扩展和硬件失效问题。Ceph 设计了一套 CRUSH 算法,用在分布式对象存储系统(RADOS)上,可以有效地将数据对象(Object)映射到存储设备(OSD)上。CRUSH 算法能够处理存储设备的添加和移除,并最小化由于存储设备的添加和移动而导致的数据迁移。

CRUSH 算法有两个关键优点。

(1)任何组件都可以独立计算出 Object 所在的位置(去中心化)。

(2)运算过程只需要很少的集群元数据(Cluster Map),只有当存储集群添加或删除设备时,这些元数据才会发生改变。

这些特性使得 CRUSH 适合管理对象分布非常大的(PB 级别)且要求可伸缩性、性能和可靠性非常高的存储系统。


2.2.1  Ceph 寻址流程


为了讲清楚 Ceph 寻址流程,这里先介绍一下常用术语。

File

File 是要存储和访问的文件,它是面向用户的,也是可直观操作的对象,在块存储使用场景,File 指挂载出去使用的 RBD 设备;在对象存储使用场景,File 指用户可见的音视频或其他格式的用户数据;在文件存储使用场景,File 指文件系统中存储的用户数据。

Object

Object 是 Ceph 底层 RADOS 所看到的对象,也是在 Ceph 中数据存储的基本单位,当 File 过大时,需要将 File 切分成统一大小的 Object 进行存储,每个 Object 应包含 ID、Binary Data 和 Metadata 信息。Object 的大小可由 RADOS 限定(通常为 4MB,可依据需要进行配置)。

PG

PG(Placement Group)是一个逻辑的概念,它的用途是对 RADOS 层 Object 的存储进行组织和位置的映射,通过 PG 概念的引入,Ceph 存储系统可以更好地分配数据和定位数据,PG 是 Ceph 存储系统数据均衡和恢复的最小单位。

Pool

Pool 规定了数据冗余的类型,如副本模式、纠删码模式,对于不同冗余类型的数据存储,需要单独的 Pool 划分,即每个 Pool 只能对应一种数据冗余类型的规则。每个 Pool 内可包含多个 PG。

OSD

如第 1 章介绍,OSD(Object Storage Device)服务负责数据的存取,并处理数据的复制、恢复、回填、再均衡等任务。

PG 和 Object 是一对多的关系,1 个 PG 里面组织若干个 Object,但是 1 个 Object 只能被映射到 1 个 PG 中。

PG 和 OSD 是多对多的关系,1 个 PG 会映射到多个 OSD 上(依照副本或者纠删码规则),每个 OSD 也会承载多个 PG。

PG 和 Pool 是多对一的关系,1 个 Pool 内包含多个 PG,Pool 创建时可指定其中 PG的数量(通常为 2 的指数次幂),Pool 创建之后,也可以通过命令对其进行调整。

图 2-1 展示了 Ceph 的寻址流程,可以看到,Ceph 的寻址需要经历 3 次映射。

image.png

图 2-1 Ceph 寻址流程

首先,将 File 切分成多个 Object

每个 Object 都有唯一的 ID(即 OID),OID 根据文件名称得到,由 ino 和 ono 构成,ino 为文件唯一 ID(比如 filename + timestamp),ono 则为切分后某个 Object 的序号(如 0、1、2、3、4、5 等),根据该文件的大小我们就会得到一系列的 OID。

其次,将每个 Object 映射到一个 PG 中去。

实现方式也很简单,对 OID 进行 Hash 运算,然后对运算结果进行按位与计算,即可得到某一个 PG 的 ID。图中的 mask 掩码设置为 PG 的数量减 1。

我们认为得到的 pgid 是随机的,这与 PG 的数量和文件的数量有关系,在足够量级PG 数量的前提下,集群数据是均匀分布的。

最后,将 Object 所在的 PG 映射到实际的存储位置 OSD 上。

这里应用的就是 CRUSH 算法了,CRUSH 算法可以通过 pgid 得到多个 OSD(与副本或者纠删码的配置策略有关),数据最终的存放位置即为这些计算而来的 OSD 守护进程。

可以看到,Ceph 存储系统的数据寻址过程只需要输入文件的名称以及文件的大小等信息,所有计算过程都可以直接在客户端本地完成。Ceph 客户端只要获得了 Cluster Map,就可以使用 CRUSH 算法计算出某个 Object 所在 OSD 的 id,然后直接与它通信。Ceph 客户端在初始化时会从 Monitor 服务获取最新的 Cluster Map,随后采用反向订阅机制,仅当 Monitor 服务中记录的 Cluster Map 发生变化时,才主动向 Ceph 客户端进行推送。

相关文章
|
19天前
|
JSON JavaScript 前端开发
Vue3源码架构简析及Monorepo流程构建
【10月更文挑战第12天】Vue3源码架构简析及Monorepo流程构建
Vue3源码架构简析及Monorepo流程构建
|
3月前
|
存储 缓存 前端开发
Django 后端架构开发:存储层调优策略解析
Django 后端架构开发:存储层调优策略解析
50 2
|
8天前
|
开发者 容器
Flutter&鸿蒙next 布局架构原理详解
本文详细介绍了 Flutter 中的主要布局方式,包括 Row、Column、Stack、Container、ListView 和 GridView 等布局组件的架构原理及使用场景。通过了解这些布局 Widget 的基本概念、关键属性和布局原理,开发者可以更高效地构建复杂的用户界面。此外,文章还提供了布局优化技巧,帮助提升应用性能。
69 4
|
8天前
|
存储 Dart 前端开发
flutter鸿蒙版本mvvm架构思想原理
在Flutter中实现MVVM架构,旨在将UI与业务逻辑分离,提升代码可维护性和可读性。本文介绍了MVVM的整体架构,包括Model、View和ViewModel的职责,以及各文件的详细实现。通过`main.dart`、`CounterViewModel.dart`、`MyHomePage.dart`和`Model.dart`的具体代码,展示了如何使用Provider进行状态管理,实现数据绑定和响应式设计。MVVM架构的分离关注点、数据绑定和可维护性特点,使得开发更加高效和整洁。
143 3
|
20天前
|
容器
Flutter&鸿蒙next 布局架构原理详解
Flutter&鸿蒙next 布局架构原理详解
|
21天前
|
存储 监控 分布式数据库
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
本文介绍了百亿级数据存储架构的设计与实现,重点探讨了ElasticSearch和HBase的结合使用。通过ElasticSearch实现快速检索,HBase实现海量数据存储,解决了大规模数据的高效存储与查询问题。文章详细讲解了数据统一接入、元数据管理、数据一致性及平台监控等关键模块的设计思路和技术细节,帮助读者理解和掌握构建高性能数据存储系统的方法。
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
|
1月前
|
前端开发 Java 应用服务中间件
21张图解析Tomcat运行原理与架构全貌
【10月更文挑战第2天】本文通过21张图详细解析了Tomcat的运行原理与架构。Tomcat作为Java Web开发中最流行的Web服务器之一,其架构设计精妙。文章首先介绍了Tomcat的基本组件:Connector(连接器)负责网络通信,Container(容器)处理业务逻辑。连接器内部包括EndPoint、Processor和Adapter等组件,分别处理通信、协议解析和请求封装。容器采用多级结构(Engine、Host、Context、Wrapper),并通过Mapper组件进行请求路由。文章还探讨了Tomcat的生命周期管理、启动与停止机制,并通过源码分析展示了请求处理流程。
|
29天前
|
存储 分布式计算 druid
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
47 3
|
29天前
|
消息中间件 分布式计算 druid
大数据-154 Apache Druid 架构与原理详解 基础架构、架构演进
大数据-154 Apache Druid 架构与原理详解 基础架构、架构演进
27 2
|
29天前
|
消息中间件 监控 Java
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
56 1

热门文章

最新文章