咕咕

Crimson 是 Crimson OSD 的代码名称，它是下一代用于多核心可扩展性的 OSD 。它通过快速网络和存储设备提高性能，采用包括 DPDK 和 SPDK 的顶级技术。BlueStore 继续支持 HDD 和 SSD。Crimson 旨在与早期版本的 OSD 守护进程与类 Ceph OSD 兼容。 Crimson 基于 SeaStar C++ 框架构建，是核心 Ceph 对象存储守护进程 OSD 组件的新实现，并替换了 Ceph OSD 。Crimson OSD 最小化延迟并增加 CPU 处理器用量。它使用高性能异步 IO 和新的线程架构，旨在最小化上下文切换和用于跨通信的操作间的线程通信。 以下分析基于 v19.2.1 进行分析。 一、架构对比Ceph OSD 是 Ceph 集群的一部分，负责通过网络提供对象访问、维护冗余和高可用性，并将对象持久化到本地存储设备。作为 Classic OSD 的重写版本，Crimson OSD 从客户端和其他 OSD 的角度兼容现有的 RADOS 协议，提供相同的接口和功能。Ceph OSD 的模块（例如 Messenger、OSD...

当前 ceph 集群搭建部署的方式主要有三种: ceph-ansible ，vstart.sh ， cephadm 。 其中 vstart.sh 脚本用于在开发环境中快速搭建测试集群； ceph-ansible 是一种部署 ceph 集群的老方式，支持在宿主机及容器部署的方式，目前社区已不推荐使用；cephadm 是当前最新的支持部署生产集群的方式，仅支持容器部署。接下来主要介绍通过 vstart.sh 和 cephadm 部署 crimson 集群的方式。以下测试基于 v19.2.1 版本进行。 一、vstart.sh 搭建集群vstart.sh 常用于在开发环境环境中快速搭建集群，且在部署集群前我们需要编译出对应的二进制包。由于编译环境可能会有各种依赖缺失，版本异常等问题，这里推荐使用 bugwz/ceph-images 中提供的 CentOS Stream 9 的编译打包环境。同时后续的集群的搭建也可以在容器内部进行。 搭建集群操作步骤如下: 软件编译: 使用开发容器镜像，编译对应的 ceph 代码，产出对应的二进制运行文件； 集群部署: 在开发容器内部使用...

一、CephFS QoS社区的相关实现： 基于 tokenbucket 算法的目录 QoS : https://github.com/ceph/ceph/pull/29266 基于 dmclock 算法的 subvolume QoS : 来自日本的 line 公司提出的想法，https://github.com/ceph/ceph/pull/38506 ， https://github.com/ceph/ceph/pull/52147 1.1、基于 TokenBucket 算法的目录 QoS该实现并未合并到主分支。 相关材料： 社区的原始PR: https://github.com/ceph/ceph/pull/29266 实现特点： 基于 TokenBucketThrottle 类在客户端侧实现的 TokenBucket 类型的 QoS，用于约束每个独立的客户端的访问请求； QoS 的限制粒度为每个独立的客户端，没有全局的QoS限制； 用于限制目录级别的操作 QoS； 支持 IOPS 和 BPS 的 QoS 限制，且支持突发流量； 仅支持 FUSE...

CRUSH（Controlled Replication Under Scalable Hashing）是 Ceph 存储系统中用于数据分布和复制的算法。关于 CRUSH 的论文解析参考: 译 - CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data 。CRUSH map 是 Ceph 集群中一个关键的配置组件，它定义了数据如何在集群的物理硬件上分布。 CRUSH 算法使得 Ceph 能够在无需中心化或者分布式元数据管理器的情况下，高效、可靠地进行数据复制和恢复。 一、CRUSH map 解析CRUSH map 包含了集群的层次结构和各种规则，这些规则定义了数据应该如何在集群中分布。 CRUSH map 主要包含以下几个部分： Tunables : 一组可用于调整 CRUSH 算法行为的参数。 Devices : 定义集群中所有可用的存储设备的列表。 Types : 定义存储层次结构中的不同层级类型。 Buckets : 组织和管理存储设备（如 OSDs ）的逻辑容器。 Rules :...

译作: 可控的、可扩展的、分布式的副本数据放置算法，论文原文 。 该论文于 2006 年 11 月发布于 SC2006 。 CRUSH 是一种用于大规模分布式存储系统的数据分布算法，它通过伪随机函数将数据对象映射到存储设备上，无需依赖中央目录。CRUSH 算法设计考虑了系统的动态性，支持在添加或移除存储设备时高效地重组数据，并最小化不必要的数据移动。此外，CRUSH 支持多种数据复制和可靠性机制，并允许根据用户定义的策略进行数据分布，这些策略能够在故障域之间有效地分离副本，增强数据安全性。 CRUSH 的核心是其层级集群图，该图描述了存储集群的物理和逻辑结构，并通过一系列规则来确定数据的放置位置。CRUSH 算法通过将数据均匀分布在加权设备上，保持存储和设备带宽资源的平衡利用。算法还考虑了设备的故障和过载情况，能够在设备发生故障或过载时重新分配数据，避免数据丢失并优化系统性能。 CRUSH 的映射性能高效，计算复杂度为 O(logn) ，适用于管理大规模（多 PB...

译作: 可扩展哈希下的复制: 可扩展分散数据分布的算法家族 , 原文地址 ，该论文发表于 2004 年 4 月在新墨西哥州圣达菲举行的第 18 届国际并行和分布式处理研讨会 (IPDPS 2004) 论文集。这篇论文介绍了一系列名为 RUSH(Replication Under Scalable Hashing) 的算法，用于在去中心化的存储系统中分配和管理数据。每种 RUSH...

本文详细介绍了包括 rados bench、rbd bench、dd 、fio 、vdbench 、mdtest 、iozone、cosbench、cbt 等测试工具对于 Ceph 集群的性能压测的使用。对于每个工具都提供了压测命令参数、示例命令等使用说明，实现了对 Ceph 块存储、文件存储、对象存储、rados 对象存储等存储类别的性能压测。文中重点阐述了各命令的使用格式、基本功能和参数选择，为用户在 Ceph 环境中进行性能评估提供了实用指南。 一、rados bench以下基于 v19.2.1 版本进行测试。 用途: 测试 ceph rados 对象存储性能； 1.1、测试配置参数命令格式: rados bench $seconds $type [args...] $seconds : 压测运行时间； $type : 压测类型，可选值为 write/seq/rand （分别代表写/连续读/随机读）； -p : 指定压测的目标 pool ； -b : 只有当压测类型为 write 时可用，用于设置写入 block...

本文详细介绍了使用 ceph-ansible 部署和运维 Ceph 集群的过程，包括各版本及其依赖的 Ansible 版本的对应关系、自定义模块与任务的结构、集群部署、运维操作及相关示例。特别强调了环境配置、节点连通性验证、MDS 和 OSD 组件的管理，以及安全和性能优化注意事项。 一、项目介绍以下分析基于 ceph-ansible stable-6.0 分支代码。 1.1、版本与对应关系目前 ceph-ansible 采用不同的代码分支来支持部署不同版本的 ceph 集群，且每个代码分支需要特定的 ansible 版本支持，具体的对应关系如下（以下对应关系更新于 2025/05/23 ）： ceph-ansible 分支 支持的 ceph 版本 依赖的 ansible 核心版本 依赖的 ansible 发布版本包 stable-3.0 Jewel(V10), Luminous(V12) 2.4 - stable-3.1 Luminous(V12), Mimic(V13) 2.4 - stable-3.2 Luminous(V12),...

《The Google File System》 是由 Google 公司开发的分布式文件系统，旨在解决存储海量数据的问题。GFS 采用了一些独特的设计，如基于大块的文件存储、多副本存储和自动故障恢复等。GFS 能够支持高并发、高吞吐量的数据访问，并且具有良好的扩展性和可靠性。GFS 的设计思想已经被广泛应用于其他分布式存储系统的开发中，是分布式存储领域的重要里程碑之一。 摘要We have designed and implemented the Google File System, a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients. 我们设计并实现了...

Redis 的异地多活是一种跨地域容灾、并提供低延迟访问的部署方案。业界提供了很多的构建思路，这里将对比一下这里方案，并详细介绍一下业界的设计与实现。 一、简介二、思考2.1、Redis异地多活的定位在使用 Redis 的异地多活部署方案之前，为了提供 Redis 集群的高可用，我们也会提供跨地域主从的部署方式，通过这种方式我们也能实现地域级别的容灾能力。考虑到业务在使用 Redis 前的关注点一般是：性能、延迟、可用性以及数据一致性，我们将通过这四个关键点来对比一下这两种方案的不同： 性能（高性能， QPS ）： 跨地域主从：跨地域写性能较差，本地域读性能较好； 异地多活：本地域读写性能较好； 延迟（低延迟， Avg ， P99 等）： 跨地域主从：跨地域写延迟交高，本地域读延迟较低； 异地多活：本地域读写延迟较低； 可用性（高可用）： 跨地域主从：集群间的容灾切换，存在主从切换的瞬时访问问题，满足高可用需求； 异地多活：集群内的主从故障切换，满足高可用需求； 数据一致性： 跨地域主从：提供 Redis...