存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载Ceph 分布式存储集群中数据最终落盘的形态取决于两类实体承载数据的存储守护进程OSD、Monitor、Manager以及 OSD 使用的存储后端BlueStore 或已弃用的 Filestore。本文基于 Ceph 官方文档 doc/rados/configuration/storage-devices.rst 的主干脉络结合 BlueStore 配置参考、Filestore 配置参考 与 BlueStore 迁移指南 以及仓库源码系统讲解存储集群中各守护进程的角色分工、两种 OSD 后端的设计差异、BlueStore 的设备布局block / block.db / block.wal与ceph-volume部署命令、缓存与校验和调优、内联压缩、最小分配粒度的空间放大问题以及 Filestore 向 BlueStore 的迁移路径。读完本文你将掌握存储设备在 Ceph 中的组织方式并能够独立规划、部署与调优 BlueStore OSD。存储集群中的守护进程与存储设备角色一个 Ceph 存储集群中存在多类守护进程它们对存储设备的需求与使用方式截然不同Ceph OSDObject Storage Daemon对象存储守护进程存储 Ceph 中绝大部分数据。通常每个 OSD 由一个独立的存储设备提供容量支持可以是传统机械硬盘HDD或固态硬盘SSDOSD 也可以由多个设备组合支撑例如用 HDD 承载大部分数据、用 SSD或 SSD 上的分区承载部分元数据。集群中 OSD 的数量通常取决于待存储数据量、每个存储设备的容量以及所配置的冗余级别与冗余类型副本复制或纠删码。Ceph Monitor 守护进程负责管理集群的关键状态包括集群成员关系和认证信息。小型集群只需几 GB 存储即可容纳 monitor 数据库而在大型集群中monitor 数据库可能达到数十 GB 乃至数百 GB。Ceph Manager 守护进程与 monitor 守护进程并行运行提供额外的监控能力并为外部监控与管理平台提供接口。从整体配置体系的视角看这些守护进程的存储相关参数统一由 doc/rados/configuration/index.rst 中的 “Configuring the Object Store” 与 “Reference” 两大部分组织其中“存储设备”一节正是本文所讲解的 storage-devices 文档。OSD 后端Back End总览OSD 管理其存储数据的方式有两种后端。自Luminous 12.2.z版本起默认且被推荐的 OSD 后端是BlueStore在 Luminous 之前默认也是唯一的后端是Filestore。这两种后端的设计哲学差异巨大理解它们之间的区别是规划存储集群的第一步。维度BlueStoreFilestore数据存储方式直接管理裸块设备或分区不创建传统文件系统依赖标准文件系统通常为 XFS元数据管理内嵌 RocksDB 键值数据库传统上使用 LevelDB后改用 RocksDB默认/支持状态Luminous 起为默认持续演进Reef 版本起弃用且不再支持校验和全量数据与元数据校验和依赖文件系统无内置全量校验部署工具ceph-volume lvm多策略部署传统 ceph-disk / ceph-deploy 方式Ceph 集群允许同时运行 Filestore OSD 与 BlueStore OSD混合状态但鉴于 Filestore 在 Reef 及以后版本不再受支持新部署应一律采用 BlueStore。BlueStore为 Ceph OSD 工作负载设计的专用存储后端BlueStore 是专门为 Ceph OSD 在磁盘上管理数据而设计的专用存储后端其设计建立在对 Filestore OSD 长达十年的支持与管理经验之上。在仓库源码中BlueStore 的核心实现位于 src/os/bluestore/BlueStore.h 与 src/os/bluestore/BlueStore.cc包括设备管理、分配器、RocksDB 集成BlueFS、校验和与压缩等模块所有 BlueStore 配置项在 src/common/options/global.yaml.in 中集中声明。BlueStore 的关键特性包括直接管理存储设备BlueStore 直接消费裸块设备或分区绕开了诸如 XFS 之类的本地文件系统抽象层从而避免这些中间层带来的性能限制与额外复杂度。使用 RocksDB 管理元数据内嵌 RocksDB 键值数据库用于管理内部元数据包括对象名到磁盘块位置的映射。全量数据与元数据校验和默认情况下写入 BlueStore 的所有数据与元数据都会由一个或多个校验和保护任何数据或元数据在被读回磁盘或返回给用户之前都必须经过校验。内联压缩数据在写入磁盘之前可被选择性地压缩。多设备元数据分层BlueStore 允许其内部日志写前日志 WAL写入独立的高速设备如 SSD、NVMe 或 NVDIMM以提升性能如果可用高速存储空间充裕内部元数据也可以存放在更快的设备上。高效的写时复制copy-on-writeRBD 与 CephFS 快照依赖写时复制clone机制BlueStore 高效地实现了该机制。这不仅使普通快照的 I/O 更高效也使得纠删码池依赖克隆实现高效的两阶段提交受益。BlueStore 的设备布局block、block.db 与 block.walBlueStore 可以管理一个、两个或在某些情况下三个存储设备。这里的“设备”指 Linux/Unix 意义上的设备即出现在/dev或/devices下的资源每个设备可以是整块存储盘、存储盘的一个分区或一个逻辑卷。BlueStore 不会在使用的设备上创建或挂载传统文件系统而是以“raw”方式直接读写设备。最简单的场景下BlueStore 消费单个存储设备的全部空间该设备被称为主设备primary device通过数据目录中的block符号链接标识。数据目录是一个tmpfs挂载点当该目录被ceph-volume引导或激活时会填充保存 OSD 信息的元数据文件与链接例如 OSD 标识符、OSD 所属集群的名称以及 OSD 的私有 keyring。在更复杂的场景下BlueStore 会横跨一至两个额外设备部署写前日志WAL设备数据目录中以block.wal标识用于分离 BlueStore 的内部日志/写前日志。仅当 WAL 设备比主设备更快时例如 WAL 设备为 SSD、主设备为 HDD使用 WAL 设备才有优势。DB 设备数据目录中以block.db标识用于存放 BlueStore 的内部元数据。BlueStore更准确地说是内嵌的 RocksDB会尽量将尽可能多的元数据放在 DB 设备上以提升性能当 DB 设备写满时元数据会回落到主设备上即没有 DB 设备时元数据的存放位置。同样只有 DB 设备比主设备快时才值得配置。WAL 设备与 DB 设备的取舍如果可用的高速存储很少例如不足 1 GB建议把空间用作 WAL 设备如果有较多高速存储则配置 DB 设备更合理。因为 BlueStore 的日志总是放在可用的最快设备上使用 DB 设备既能获得与 WAL 设备相同的收益日志自动与 DB 共置还能额外把元数据移出主设备——当指定了 DB 设备而未显式指定 WAL 设备时WAL 会隐式地与 DB 一起共置在较快设备上。使用ceph-volume部署单设备共置BlueStore OSDceph-volume lvm prepare --bluestore --data device指定 WAL 设备与 DB 设备ceph-volume lvm prepare --bluestore --data device --block.wal wal-device --block.db db-device注意--data参数可以接受以下任意设备使用vg/lv记法的逻辑卷、已存在的逻辑卷以及 GPT 分区。BlueStore 部署策略两种典型布局与 Filestore 不同BlueStore 有多种部署方式但通过两种常见布局即可把握整体策略。仅 block数据如果所有设备类型相同例如全部为 HDD且没有可用于元数据的高速设备则只需指定 block 设备不分离block.db与block.wal。单设备/dev/sda的命令如下ceph-volume lvm create --bluestore --data /dev/sda如果用于 BlueStore OSD 的设备是预先创建的逻辑卷则对名为ceph-vg/block-lv的逻辑卷执行ceph-volume lvm create --bluestore --data ceph-vg/block-lvblock block.db 混合布局如果同时拥有快设备与慢设备例如 SSD 与 HDD推荐将block.db放在较快的设备上而block数据放在较慢的旋转盘上。此时必须手动创建卷组volume group与逻辑卷logical volumeceph-volume目前无法自动完成这一步骤。以下示例展示手动创建卷组与逻辑卷的完整流程假设有四块旋转盘sda、sdb、sdc、sdd与一块高速 SSDsdx。首先创建卷组vgcreate ceph-block-0 /dev/sda vgcreate ceph-block-1 /dev/sdb vgcreate ceph-block-2 /dev/sdc vgcreate ceph-block-3 /dev/sdd然后为block创建逻辑卷lvcreate -l 100%FREE -n block-0 ceph-block-0 lvcreate -l 100%FREE -n block-1 ceph-block-1 lvcreate -l 100%FREE -n block-2 ceph-block-2 lvcreate -l 100%FREE -n block-3 ceph-block-3因为有四块 HDD将产生四个 OSD。假设/dev/sdx是一块 200GB 的 SSD可以创建四个 50GB 的逻辑卷作为 DB 设备vgcreate ceph-db-0 /dev/sdx lvcreate -L 50GB -n db-0 ceph-db-0 lvcreate -L 50GB -n db-1 ceph-db-0 lvcreate -L 50GB -n db-2 ceph-db-0 lvcreate -L 50GB -n db-3 ceph-db-0最后创建四个 OSDceph-volume lvm create --bluestore --data ceph-block-0/block-0 --block.db ceph-db-0/db-0 ceph-volume lvm create --bluestore --data ceph-block-1/block-1 --block.db ceph-db-0/db-1 ceph-volume lvm create --bluestore --data ceph-block-2/block-2 --block.db ceph-db-0/db-2 ceph-volume lvm create --bluestore --data ceph-block-3/block-3 --block.db ceph-db-0/db-3流程结束后将产生四个 OSDblock数据分布在四块 HDD 上每块 HDD 在共享 SSD 上拥有一个 50GB 的 DB 设备逻辑卷。block.db 容量规划Sizing部署混合 HDD/SSD OSD 时为 BlueStore 配置足够大的block.db逻辑卷至关重要将 WALDB 卸载到较快设备时block.db大小至少应为主设备较慢的block设备大小的 2.5%。在早于 Squid 的版本中RocksDB 压缩未启用官方建议更大的卸载比例。RGW 工作负载block.db应至少为block大小的4%因为 RGW 大量使用block.db存储元数据尤其是 omap 键。例如block为 1TB 时block.db至少应为 40GB。RBD 工作负载block.db通常只需block大小的1%2%。在旧版本中RocksDB 内部 level 大小决定了 DB 只能高效利用与 L0、L0L1、L1L2 等总和对应的分区/逻辑卷大小——即默认设置下约为 3GB、30GB、300GB 等。多数部署无需为 L3 及以上的规模特意规划将上述数值翻倍6GB、60GB、600GB可便于 DB 压缩compaction。Pacific 之前创建的 OSD 可通过ceph-bluestore-tool将 RocksDB 转换为 sharding 模式获益。Nautilus 14.2.12、Octopus 15.2.6 及后续版本允许更好地利用任意大小的 DB 设备Pacific 版本还引入了实验性的动态 level 支持。因此旧版本用户可提前规划更大的 DB 设备以便未来升级后享受规模化收益。当不采用快慢设备混合时无需为block.db或block.wal创建独立逻辑卷——BlueStore 会在block空间内自动共置这些组件。缓存内存管理自动调优与手动设置BlueStore 的缓存机制分为自动与手动两种模式。自动缓存大小调整Automatic Cache SizingBlueStore 可以在满足特定条件时自动调整缓存大小必须将 TCMalloc 配置为内存分配器并且启用bluestore_cache_autotune配置选项该选项当前默认启用。自动调整生效时BlueStore 会尽量将 OSD 堆内存使用控制在osd_memory_target所确定的目标值以下。该算法是尽力而为的缓存不会缩小到低于osd_memory_cache_min定义的大小。缓存比例按优先级层次选择当优先级信息不可用时则使用bluestore_cache_meta_ratio与bluestore_cache_kv_ratio指定的值作为回退缓存比例。自动缓存调整涉及的核心选项包括bluestore_cache_autotune、osd_memory_target、bluestore_cache_autotune_interval、osd_memory_base、osd_memory_expected_fragmentation、osd_memory_cache_min、osd_memory_cache_resize_interval。手动缓存大小设置Manual Cache Sizing每个 OSD 用于 BlueStore 缓存的内存量由bluestore_cache_size配置选项决定。如果该选项未指定保持为 0则 Ceph 根据主设备类型使用另一选项确定默认内存预算主设备为 HDD 时使用bluestore_cache_size_hdd主设备为 SSD 时使用bluestore_cache_size_ssd。BlueStore 与 OSD 内的其他子系统会尽力在此内存预算内工作。需要注意的是除配置的缓存大小外OSD 自身还会消耗内存另外还存在内存碎片与分配器开销带来的额外占用。配置的缓存内存预算可存放以下类型的数据键/值元数据即 RocksDB 的内部缓存BlueStore 元数据BlueStore 数据即最近读取或写入的对象数据缓存内存使用由bluestore_cache_meta_ratio与bluestore_cache_kv_ratio两个配置项控制。预留给数据的缓存比例由有效 BlueStore 缓存大小取决于相应的bluestore_cache_size[_ssd|_hdd]选项与主设备的设备类别以及 meta 和 kv 比例共同决定。数据比例可用如下公式计算有效缓存大小 * (1 - bluestore_cache_meta_ratio - bluestore_cache_kv_ratio)手动模式相关选项bluestore_cache_size、bluestore_cache_size_hdd、bluestore_cache_size_ssd、bluestore_cache_meta_ratio、bluestore_cache_kv_ratio。校验和ChecksumsBlueStore 对写入磁盘的所有元数据和所有数据都进行校验。元数据校验由 RocksDB 处理使用crc32c算法数据校验由 BlueStore 处理可使用crc32c、xxhash32或xxhash64之一。crc32c是默认校验算法适用于大多数场景。完整的数据校验会增加 BlueStore 必须存储和管理的元数据量。只要可能例如客户端提示数据为顺序读写BlueStore 会对更大的块进行校验但在许多情况下它必须为每 4KB 数据块存储一个校验值通常为 4 字节。可以通过将校验和截断为一字节或两字节来获得更小的校验值并降低元数据开销但代价是随机错误未被检测的概率上升校验和位数未检出错误概率近似32 位4 字节约 1 / 40 亿4,294,967,29616 位2 字节1 / 65,5368 位1 字节1 / 256要使用更小的校验值可将校验算法选为crc32c_16或crc32c_8。校验算法既可通过每池的csum_type配置选项指定也可通过全局配置选项指定。例如ceph osd pool set pool-name csum_type algorithm相关全局选项为bluestore_csum_type其定义见 src/common/options/global.yaml.in。内联压缩Inline CompressionBlueStore 支持使用snappy、zlib、lz4或zstd进行内联压缩。数据是否被压缩由两个因素决定(1)压缩模式compression mode与 (2) 与写操作关联的客户端提示client hints。压缩模式如下none从不压缩数据。passive仅当写操作带有compressible可压缩提示时才压缩数据。aggressive除非写操作带有incompressible不可压缩提示否则压缩数据。force无论如何都尝试压缩数据。关于compressible与incompressibleI/O 提示的更多信息可参阅rados_set_alloc_hint接口说明。注意只有数据块在尺寸上得到充分缩减时由bluestore compression required ratio设置决定才会被压缩。无论采用何种压缩模式如果压缩后的数据块仍然太大压缩结果将被丢弃转而存储原始未压缩数据。例如bluestore compression required ratio设为.7则仅当压缩后数据尺寸不超过原始数据的 70% 时才进行压缩。压缩模式、压缩算法、压缩所需比例、最小 blob 大小与最大 blob 大小既可通过每池属性指定也可通过全局配置选项指定。通过每池属性设置ceph osd pool set pool-name compression_algorithm algorithm ceph osd pool set pool-name compression_mode mode ceph osd pool set pool-name compression_required_ratio ratio ceph osd pool set pool-name compression_min_blob_size size ceph osd pool set pool-name compression_max_blob_size size相关全局选项bluestore_compression_algorithm、bluestore_compression_mode、bluestore_compression_required_ratio、bluestore_compression_min_blob_size、bluestore_compression_min_blob_size_hdd、bluestore_compression_min_blob_size_ssd、bluestore_compression_max_blob_size、bluestore_compression_max_blob_size_hdd、bluestore_compression_max_blob_size_ssd。RocksDB ShardingBlueStore 维护多种内部键值数据全部存放在 RocksDB 中每种数据类型被赋予唯一前缀。在 Pacific 之前所有键值数据都存放在单一 RocksDB 列族 default 中Pacific 及以后版本中BlueStore 可以将键值数据划分到多个 RocksDB 列族。当键相似时——具体而言当键具有相近的访问频率、相近的修改频率和相近的生命周期时——BlueStore 可以获得更好的缓存效果与更精确的压缩compaction。在此条件下性能提升压缩所需磁盘空间也更少因为每个列族更小且可以独立压缩。Pacific 及以后版本部署的 OSD 默认使用 RocksDB sharding。但从更早版本升级到 Pacific 或更高版本的集群中Pacific 之前创建的 OSD 不会自动启用 sharding。要为指定 OSD 启用 sharding 并应用 Pacific 默认设置先停止该 OSD然后执行ceph-bluestore-tool \ --path data path \ --shardingm(3) p(3,0-12) O(3,0-13)block_cache{typebinned_lru} L P \ reshard相关选项bluestore_rocksdb_cf、bluestore_rocksdb_cfs。I/O 节流ThrottlingBlueStore 提供若干节流选项用于控制内部队列与延迟写入行为bluestore_throttle_bytes、bluestore_throttle_deferred_bytes、bluestore_throttle_cost_per_io、bluestore_throttle_cost_per_io_hdd、bluestore_throttle_cost_per_io_ssd。这些选项在高速设备与旋转盘上的默认成本系数不同适合在高吞吐或高延迟敏感场景中按设备类别微调。SPDK 高速路径可选要针对 NVMe 设备使用 SPDK 驱动需要先准备系统可参考 SPDK 官方入门文档。SPDK 提供了自动配置设备的脚本需要以 root 权限运行sudo src/spdk/scripts/setup.sh随后需要用带 spdk: 前缀的设备选择器指定目标 NVMe 设备的bluestore_block_path。例如先用lspci查找 Intel NVMe SSD 的设备选择器lspci -mm -n -D -d 8086:0953设备选择器的形式为DDDD:BB:DD.FF或DDDD.BB.DD.FF。假设查到的设备选择器为0000:01:00.0则配置为bluestore_block_path spdk:trtype:PCIe traddr:0000:01:00.0也可以指定基于 TCP 传输的远程 NVMeoF 目标例如bluestore_block_path spdk:trtype:TCP traddr:10.67.110.197 trsvcid:4420 subnqn:nqn.2019-02.io.spdk:cnode1要在单节点上运行多个 SPDK 实例必须为每个实例指定各自使用的 DPDK 内存量单位 MB。大多数情况下单个设备可用于 data、DB 与 WAL即共置策略。为确保所有 I/O 都经由 SPDK 发出请设置bluestore_block_db_path bluestore_block_db_size 0 bluestore_block_wal_path bluestore_block_wal_size 0若不进行上述设置当前实现会以内核文件系统符号填充 SPDK 映射文件并使用内核驱动发起 DB/WAL I/O。最小分配大小与空间放大Minimum Allocation SizeBlueStore 在底层存储设备上存在一个配置的最小分配量实践中这是即使微小的 RADOS 对象在每个 OSD 主设备上也能占用的最小容量。该配置项bluestore_min_alloc_size根据 OSD 的rotational属性从bluestore_min_alloc_size_hdd或bluestore_min_alloc_size_ssd取值HDD 上创建的 OSD 使用bluestore_min_alloc_size_hddSSD包括 NVMe上创建的 OSD 使用bluestore_min_alloc_size_ssd。各版本默认值演进Mimic 及更早版本旋转介质HDD默认 64KB非旋转介质SSD默认 16KB。Octopus非旋转介质SSD默认值改为 4KB。Pacific旋转介质HDD默认值也改为 4KB。这一变化源于 Ceph RADOS GatewayRGW部署在承载大量小文件S3/Swift 对象时经历的空间放大问题。例如 RGW 客户端存储一个 1KB 的 S3 对象时该对象写入单个 RADOS 对象按默认min_alloc_size会分配 4KB 底层空间意味着约 3KB4KB 减 1KB被分配但从未使用——对应约 300% 的开销、25% 的效率。而一个 5KB 的用户对象会存为两个 RADOS 对象4KB 1KB导致 4KB 设备容量被搁置不过此时开销百分比小得多。可以将其理解为取模运算的余数效应随着对象尺寸增大开销百分比迅速下降。还有一个容易被忽略的细节上述放大现象对每个副本都会发生。例如默认三副本3R时一个 1KB 的 S3 对象实际会搁置约 9KB 的设备容量若改用纠删码EC放大可能更高对于k4, m2的池1KB 的 S3 对象会占用 24KB4KB × 6设备容量。当 RGW bucket 池中多为较大的用户对象时该现象的影响往往可忽略但若部署中预期有相当比例的小对象就必须将其纳入规划。4KB 默认值与常规 HDD/SSD 设备契合良好。但某些新型粗粒度 IUIndirection UnitQLC SSD 在创建 OSD 时将bluestore_min_alloc_size_ssd指定为与设备 IU 匹配可能是 8KB、16KB 甚至 64KB时性能与寿命表现最佳。这些新型设备能以高于 TLC SSD 的密度和更低的成本提供与传统 TLC SSD 相当的读性能和快于 HDD 的写性能。在这些设备上创建 OSD 时必须小心只对合适的设备应用非默认值避免误用于常规 HDD/SSD可通过精心安排 OSD 创建顺序、自定义 OSD 设备类别尤其是使用集中配置的masks来规避错误。在 Quincy 及以后版本中可使用bluestore_use_optimal_io_size_for_min_alloc_size选项让每个 OSD 创建时自动发现正确值。注意bcache、OpenCAS、dmcrypt、ATA over Ethernet、iSCSI 等设备分层/抽象技术可能干扰正确值的判定部署在 VMware 存储之上的 OSD 有时也会报告与底层硬件不符的rotational属性。官方建议在启动时通过日志与 admin socket 检查这类 OSD 的行为并检查/sys/block/drive/queue/optimal_io_size的存在与取值。注意运行 Reef 或更新版本时每个 OSD 内建baked-in的min_alloc_size可由ceph osd metadata便捷地报告。检查特定 OSDceph osd metadata osd.1701 | egrep rotational|alloc空间放大可能表现为ceph df报告的 raw 与已存数据比例异常偏高ceph osd df报告的%USE/VAR值可能高于其他看似相同的 OSD混合min_alloc_size值的池中也可能出现意外的 balancer 行为。重要约束min_alloc_size仅在 OSD 创建时生效此后即使修改该属性已创建的 OSD 行为也不会改变除非销毁并用适当的选项值重新部署。升级到更新的 Ceph 版本同样不会改变旧版本或旧配置下部署的 OSD 所用的值。相关选项bluestore_min_alloc_size、bluestore_min_alloc_size_hdd、bluestore_min_alloc_size_ssd、bluestore_use_optimal_io_size_for_min_alloc_size。Filestore已被弃用的传统后端警告Filestore 已在 Reef 版本中被弃用且不再受支持。请迁移至 BlueStore。Filestore 是 Ceph 存储对象的传统方法它依赖标准文件系统通常为 XFS结合键值数据库传统上为 LevelDB现为 RocksDB管理部分元数据。Filestore 经过了充分测试并广泛用于生产环境但由于其整体设计以及对传统文件系统的依赖存在诸多性能缺陷。尽管 Filestore 能够在大多数 POSIX 兼容文件系统包括 btrfs 与 ext4上运行官方仅推荐使用 XFS 文件系统与 Ceph 配合btrfs 与 ext4 都存在已知 bug 与缺陷使用它们可能导致数据丢失。默认情况下所有 Ceph 部署工具都使用 XFS。自 Luminous 起 Filestore 已不是 Ceph 的默认后端BlueStore 取而代之Filestore OSD 在 Quincy 及以前仍受支持但在 Reef 中不再支持。Filestore 的完整配置参考见 doc/rados/configuration/filestore-config-ref.rst要点如下扩展属性XATTRFilestore OSD 依赖扩展属性但底层文件系统存储 XATTR 存在局限部分文件系统对 XATTR 可存字节数有限制。若底层文件系统无大小限制Ceph XATTR 以内联 xattr 形式存储若有大小限制如 ext4 限制总计 4KB达到阈值后部分 XATTR 会转入键值数据库。关键参数包括filestore_max_inline_xattr_size默认 0表示使用文件系统特定值、filestore_max_inline_xattr_size_xfs默认 65536、filestore_max_inline_xattr_size_btrfs默认 2048、filestore_max_inline_xattr_size_other默认 512以及filestore_max_inline_xattrs系列数量上限参数。同步间隔Synchronization IntervalsFilestore 必须定期静默写操作并同步文件系统每次同步产生一个一致的提交点之后可释放该点之前的日志条目。filestore_max_sync_interval默认 5 秒与filestore_min_sync_interval默认 0.01 秒控制同步频率的取舍更频繁的同步减少同步时间与日志滞留量更稀疏的同步让底层文件系统合并小写入但可能增加尾部延迟。Flusher 与队列filestore_flusher默认 false自 v.65 起已弃用强制大写入在同步前通过sync_file_range落盘filestore_queue_max_ops默认 50限制在途操作数filestore_queue_max_bytes默认100 20限制每操作字节数。线程与超时filestore_op_threads默认 2为并行文件系统操作线程数filestore_op_thread_timeout默认 60 秒与filestore_op_thread_suicide_timeout默认 180 秒控制操作超时。btrfs 专用filestore_btrfs_snap与filestore_btrfs_clone_range默认均开启仅适用于 btrfs。日志模式filestore_journal_parallelbtrfs 默认与filestore_journal_writeaheadXFS 默认定义日志并行/写前模式filestore_journal_trailing已弃用官方明确“切勿使用”。其他杂项filestore_merge_threshold默认 -10负值表示禁用子目录合并、filestore_split_multiple默认 2与filestore_split_rand_factor默认 20控制 Filestore 目录分裂/合并filestore_fail_eio默认 true使 OSD 在 EIO 时崩溃filestore_blackhole、filestore_dump_file、filestore_kill_at等为调试/故障注入选项。从 Filestore 迁移到 BlueStore由于 BlueStore 在性能与健壮性上优于 Filestore且 Filestore 自 Reef 起不再受支持部署 Filestore OSD 的用户应迁移至 BlueStore。完整流程见 doc/rados/operations/bluestore-migration.rst。BlueStore 与 Filestore 差异巨大单个 OSD 无法原地转换必须借助以下两类途径之一(1) 集群正常的复制与自愈机制或 (2) 将 OSD 内容从旧Filestore设备复制到新BlueStore设备的工具与策略。新部署直接使用 BlueStore扩展集群或更换故障盘后重新部署时直接使用 BlueStore 即可这是默认行为无需额外变更。现有 OSD 转换——“mark-out”替换法在集群健康的前提下逐个处理 Filestore OSD标记 OSD 为out、等待数据在集群中完成复制迁移、重新部署该 OSD、标记回in并在处理下一个 OSD 前等待恢复完成。该方法易于自动化但会带来不必要的数据迁移时间成本与 SSD 磨损。关键步骤# 判断某 OSD 是 Filestore 还是 BlueStore ceph osd metadata $ID | grep osd_objectstore # 统计集群中 Filestore 与 BlueStore OSD 的数量 ceph osd count-metadata osd_objectstore # 将 Filestore OSD 标记为 out ceph osd out $ID # 等待数据迁出该 OSD while ! ceph osd safe-to-destroy $ID ; do sleep 60 ; done # 停止该 OSD systemctl kill ceph-osd$ID随后销毁/重新部署该 OSD 为 BlueStore 并标记回in等待恢复完成后再处理下一个 OSD。小结与配置入口存储设备在 Ceph 集群中的角色划分清晰OSD 承担绝大部分数据的落盘任务Monitor 保存关键集群状态Manager 提供监控与外部接口而 OSD 的数据管理方式则由后端决定。BlueStore 作为当前默认且唯一推荐的 OSD 后端通过直接管理裸设备、RocksDB 元数据、全量校验和、内联压缩、多设备分层与高效写时复制在性能与健壮性上全面超越了传统 Filestore。规划 BlueStore 部署时应重点把握三件事设备布局block / block.db / block.wal与ceph-volume部署命令、block.db的容量规划WALDB 卸载时至少为主设备 2.5%RGW 场景至少 4%以及min_alloc_size对小型对象工作负载的空间放大影响。所有相关配置的完整参考可进一步查阅 BlueStore 配置参考、Filestore 配置参考、BlueStore 迁移指南 以及 对象存储配置总览配置项的声明与默认值可在 src/common/options/global.yaml.in 中核对BlueStore 实现细节可深入阅读 src/os/bluestore/BlueStore.h 及其同目录下的实现文件。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Ceph 之 ceph-volume lvm prepare 完全指南LVM 元数据标记、BlueStore 设备布局与 OSD 部署流程Ceph 之 ceph volume lvm prepare 完全指南LVM 元数据标记、BlueStore 设备布局与 OSD 部署流程 ceph volu存储分布式文件系统对象存储后端高可用第50章一剑斩金丹第50章一剑斩金丹 开头: 金丹长老嘲讽林天不自量力 发展: 林天拔剑展示剑意 高潮: 一剑斩杀金丹长老全场震惊 结尾: 宗主现身有趣我要收你为亲传人工智能AI 应用AI 写作RAGAI 插件AI 技能OneUptime Ceph Agent 部署指南基于 OpenTelemetry 采集器监控 Ceph 集群健康、OSD、存储池与归置组OneUptime Ceph Agent 部署指南基于 OpenTelemetry 采集器监控 Ceph 集群健康、OSD、存储池与归置组 OneUptime可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ceph 存储设备与 OSD 存储后端：BlueStore 与 Filestore 架构、部署与配置全解
存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载Ceph 分布式存储集群中数据最终落盘的形态取决于两类实体承载数据的存储守护进程OSD、Monitor、Manager以及 OSD 使用的存储后端BlueStore 或已弃用的 Filestore。本文基于 Ceph 官方文档 doc/rados/configuration/storage-devices.rst 的主干脉络结合 BlueStore 配置参考、Filestore 配置参考 与 BlueStore 迁移指南 以及仓库源码系统讲解存储集群中各守护进程的角色分工、两种 OSD 后端的设计差异、BlueStore 的设备布局block / block.db / block.wal与ceph-volume部署命令、缓存与校验和调优、内联压缩、最小分配粒度的空间放大问题以及 Filestore 向 BlueStore 的迁移路径。读完本文你将掌握存储设备在 Ceph 中的组织方式并能够独立规划、部署与调优 BlueStore OSD。存储集群中的守护进程与存储设备角色一个 Ceph 存储集群中存在多类守护进程它们对存储设备的需求与使用方式截然不同Ceph OSDObject Storage Daemon对象存储守护进程存储 Ceph 中绝大部分数据。通常每个 OSD 由一个独立的存储设备提供容量支持可以是传统机械硬盘HDD或固态硬盘SSDOSD 也可以由多个设备组合支撑例如用 HDD 承载大部分数据、用 SSD或 SSD 上的分区承载部分元数据。集群中 OSD 的数量通常取决于待存储数据量、每个存储设备的容量以及所配置的冗余级别与冗余类型副本复制或纠删码。Ceph Monitor 守护进程负责管理集群的关键状态包括集群成员关系和认证信息。小型集群只需几 GB 存储即可容纳 monitor 数据库而在大型集群中monitor 数据库可能达到数十 GB 乃至数百 GB。Ceph Manager 守护进程与 monitor 守护进程并行运行提供额外的监控能力并为外部监控与管理平台提供接口。从整体配置体系的视角看这些守护进程的存储相关参数统一由 doc/rados/configuration/index.rst 中的 “Configuring the Object Store” 与 “Reference” 两大部分组织其中“存储设备”一节正是本文所讲解的 storage-devices 文档。OSD 后端Back End总览OSD 管理其存储数据的方式有两种后端。自Luminous 12.2.z版本起默认且被推荐的 OSD 后端是BlueStore在 Luminous 之前默认也是唯一的后端是Filestore。这两种后端的设计哲学差异巨大理解它们之间的区别是规划存储集群的第一步。维度BlueStoreFilestore数据存储方式直接管理裸块设备或分区不创建传统文件系统依赖标准文件系统通常为 XFS元数据管理内嵌 RocksDB 键值数据库传统上使用 LevelDB后改用 RocksDB默认/支持状态Luminous 起为默认持续演进Reef 版本起弃用且不再支持校验和全量数据与元数据校验和依赖文件系统无内置全量校验部署工具ceph-volume lvm多策略部署传统 ceph-disk / ceph-deploy 方式Ceph 集群允许同时运行 Filestore OSD 与 BlueStore OSD混合状态但鉴于 Filestore 在 Reef 及以后版本不再受支持新部署应一律采用 BlueStore。BlueStore为 Ceph OSD 工作负载设计的专用存储后端BlueStore 是专门为 Ceph OSD 在磁盘上管理数据而设计的专用存储后端其设计建立在对 Filestore OSD 长达十年的支持与管理经验之上。在仓库源码中BlueStore 的核心实现位于 src/os/bluestore/BlueStore.h 与 src/os/bluestore/BlueStore.cc包括设备管理、分配器、RocksDB 集成BlueFS、校验和与压缩等模块所有 BlueStore 配置项在 src/common/options/global.yaml.in 中集中声明。BlueStore 的关键特性包括直接管理存储设备BlueStore 直接消费裸块设备或分区绕开了诸如 XFS 之类的本地文件系统抽象层从而避免这些中间层带来的性能限制与额外复杂度。使用 RocksDB 管理元数据内嵌 RocksDB 键值数据库用于管理内部元数据包括对象名到磁盘块位置的映射。全量数据与元数据校验和默认情况下写入 BlueStore 的所有数据与元数据都会由一个或多个校验和保护任何数据或元数据在被读回磁盘或返回给用户之前都必须经过校验。内联压缩数据在写入磁盘之前可被选择性地压缩。多设备元数据分层BlueStore 允许其内部日志写前日志 WAL写入独立的高速设备如 SSD、NVMe 或 NVDIMM以提升性能如果可用高速存储空间充裕内部元数据也可以存放在更快的设备上。高效的写时复制copy-on-writeRBD 与 CephFS 快照依赖写时复制clone机制BlueStore 高效地实现了该机制。这不仅使普通快照的 I/O 更高效也使得纠删码池依赖克隆实现高效的两阶段提交受益。BlueStore 的设备布局block、block.db 与 block.walBlueStore 可以管理一个、两个或在某些情况下三个存储设备。这里的“设备”指 Linux/Unix 意义上的设备即出现在/dev或/devices下的资源每个设备可以是整块存储盘、存储盘的一个分区或一个逻辑卷。BlueStore 不会在使用的设备上创建或挂载传统文件系统而是以“raw”方式直接读写设备。最简单的场景下BlueStore 消费单个存储设备的全部空间该设备被称为主设备primary device通过数据目录中的block符号链接标识。数据目录是一个tmpfs挂载点当该目录被ceph-volume引导或激活时会填充保存 OSD 信息的元数据文件与链接例如 OSD 标识符、OSD 所属集群的名称以及 OSD 的私有 keyring。在更复杂的场景下BlueStore 会横跨一至两个额外设备部署写前日志WAL设备数据目录中以block.wal标识用于分离 BlueStore 的内部日志/写前日志。仅当 WAL 设备比主设备更快时例如 WAL 设备为 SSD、主设备为 HDD使用 WAL 设备才有优势。DB 设备数据目录中以block.db标识用于存放 BlueStore 的内部元数据。BlueStore更准确地说是内嵌的 RocksDB会尽量将尽可能多的元数据放在 DB 设备上以提升性能当 DB 设备写满时元数据会回落到主设备上即没有 DB 设备时元数据的存放位置。同样只有 DB 设备比主设备快时才值得配置。WAL 设备与 DB 设备的取舍如果可用的高速存储很少例如不足 1 GB建议把空间用作 WAL 设备如果有较多高速存储则配置 DB 设备更合理。因为 BlueStore 的日志总是放在可用的最快设备上使用 DB 设备既能获得与 WAL 设备相同的收益日志自动与 DB 共置还能额外把元数据移出主设备——当指定了 DB 设备而未显式指定 WAL 设备时WAL 会隐式地与 DB 一起共置在较快设备上。使用ceph-volume部署单设备共置BlueStore OSDceph-volume lvm prepare --bluestore --data device指定 WAL 设备与 DB 设备ceph-volume lvm prepare --bluestore --data device --block.wal wal-device --block.db db-device注意--data参数可以接受以下任意设备使用vg/lv记法的逻辑卷、已存在的逻辑卷以及 GPT 分区。BlueStore 部署策略两种典型布局与 Filestore 不同BlueStore 有多种部署方式但通过两种常见布局即可把握整体策略。仅 block数据如果所有设备类型相同例如全部为 HDD且没有可用于元数据的高速设备则只需指定 block 设备不分离block.db与block.wal。单设备/dev/sda的命令如下ceph-volume lvm create --bluestore --data /dev/sda如果用于 BlueStore OSD 的设备是预先创建的逻辑卷则对名为ceph-vg/block-lv的逻辑卷执行ceph-volume lvm create --bluestore --data ceph-vg/block-lvblock block.db 混合布局如果同时拥有快设备与慢设备例如 SSD 与 HDD推荐将block.db放在较快的设备上而block数据放在较慢的旋转盘上。此时必须手动创建卷组volume group与逻辑卷logical volumeceph-volume目前无法自动完成这一步骤。以下示例展示手动创建卷组与逻辑卷的完整流程假设有四块旋转盘sda、sdb、sdc、sdd与一块高速 SSDsdx。首先创建卷组vgcreate ceph-block-0 /dev/sda vgcreate ceph-block-1 /dev/sdb vgcreate ceph-block-2 /dev/sdc vgcreate ceph-block-3 /dev/sdd然后为block创建逻辑卷lvcreate -l 100%FREE -n block-0 ceph-block-0 lvcreate -l 100%FREE -n block-1 ceph-block-1 lvcreate -l 100%FREE -n block-2 ceph-block-2 lvcreate -l 100%FREE -n block-3 ceph-block-3因为有四块 HDD将产生四个 OSD。假设/dev/sdx是一块 200GB 的 SSD可以创建四个 50GB 的逻辑卷作为 DB 设备vgcreate ceph-db-0 /dev/sdx lvcreate -L 50GB -n db-0 ceph-db-0 lvcreate -L 50GB -n db-1 ceph-db-0 lvcreate -L 50GB -n db-2 ceph-db-0 lvcreate -L 50GB -n db-3 ceph-db-0最后创建四个 OSDceph-volume lvm create --bluestore --data ceph-block-0/block-0 --block.db ceph-db-0/db-0 ceph-volume lvm create --bluestore --data ceph-block-1/block-1 --block.db ceph-db-0/db-1 ceph-volume lvm create --bluestore --data ceph-block-2/block-2 --block.db ceph-db-0/db-2 ceph-volume lvm create --bluestore --data ceph-block-3/block-3 --block.db ceph-db-0/db-3流程结束后将产生四个 OSDblock数据分布在四块 HDD 上每块 HDD 在共享 SSD 上拥有一个 50GB 的 DB 设备逻辑卷。block.db 容量规划Sizing部署混合 HDD/SSD OSD 时为 BlueStore 配置足够大的block.db逻辑卷至关重要将 WALDB 卸载到较快设备时block.db大小至少应为主设备较慢的block设备大小的 2.5%。在早于 Squid 的版本中RocksDB 压缩未启用官方建议更大的卸载比例。RGW 工作负载block.db应至少为block大小的4%因为 RGW 大量使用block.db存储元数据尤其是 omap 键。例如block为 1TB 时block.db至少应为 40GB。RBD 工作负载block.db通常只需block大小的1%2%。在旧版本中RocksDB 内部 level 大小决定了 DB 只能高效利用与 L0、L0L1、L1L2 等总和对应的分区/逻辑卷大小——即默认设置下约为 3GB、30GB、300GB 等。多数部署无需为 L3 及以上的规模特意规划将上述数值翻倍6GB、60GB、600GB可便于 DB 压缩compaction。Pacific 之前创建的 OSD 可通过ceph-bluestore-tool将 RocksDB 转换为 sharding 模式获益。Nautilus 14.2.12、Octopus 15.2.6 及后续版本允许更好地利用任意大小的 DB 设备Pacific 版本还引入了实验性的动态 level 支持。因此旧版本用户可提前规划更大的 DB 设备以便未来升级后享受规模化收益。当不采用快慢设备混合时无需为block.db或block.wal创建独立逻辑卷——BlueStore 会在block空间内自动共置这些组件。缓存内存管理自动调优与手动设置BlueStore 的缓存机制分为自动与手动两种模式。自动缓存大小调整Automatic Cache SizingBlueStore 可以在满足特定条件时自动调整缓存大小必须将 TCMalloc 配置为内存分配器并且启用bluestore_cache_autotune配置选项该选项当前默认启用。自动调整生效时BlueStore 会尽量将 OSD 堆内存使用控制在osd_memory_target所确定的目标值以下。该算法是尽力而为的缓存不会缩小到低于osd_memory_cache_min定义的大小。缓存比例按优先级层次选择当优先级信息不可用时则使用bluestore_cache_meta_ratio与bluestore_cache_kv_ratio指定的值作为回退缓存比例。自动缓存调整涉及的核心选项包括bluestore_cache_autotune、osd_memory_target、bluestore_cache_autotune_interval、osd_memory_base、osd_memory_expected_fragmentation、osd_memory_cache_min、osd_memory_cache_resize_interval。手动缓存大小设置Manual Cache Sizing每个 OSD 用于 BlueStore 缓存的内存量由bluestore_cache_size配置选项决定。如果该选项未指定保持为 0则 Ceph 根据主设备类型使用另一选项确定默认内存预算主设备为 HDD 时使用bluestore_cache_size_hdd主设备为 SSD 时使用bluestore_cache_size_ssd。BlueStore 与 OSD 内的其他子系统会尽力在此内存预算内工作。需要注意的是除配置的缓存大小外OSD 自身还会消耗内存另外还存在内存碎片与分配器开销带来的额外占用。配置的缓存内存预算可存放以下类型的数据键/值元数据即 RocksDB 的内部缓存BlueStore 元数据BlueStore 数据即最近读取或写入的对象数据缓存内存使用由bluestore_cache_meta_ratio与bluestore_cache_kv_ratio两个配置项控制。预留给数据的缓存比例由有效 BlueStore 缓存大小取决于相应的bluestore_cache_size[_ssd|_hdd]选项与主设备的设备类别以及 meta 和 kv 比例共同决定。数据比例可用如下公式计算有效缓存大小 * (1 - bluestore_cache_meta_ratio - bluestore_cache_kv_ratio)手动模式相关选项bluestore_cache_size、bluestore_cache_size_hdd、bluestore_cache_size_ssd、bluestore_cache_meta_ratio、bluestore_cache_kv_ratio。校验和ChecksumsBlueStore 对写入磁盘的所有元数据和所有数据都进行校验。元数据校验由 RocksDB 处理使用crc32c算法数据校验由 BlueStore 处理可使用crc32c、xxhash32或xxhash64之一。crc32c是默认校验算法适用于大多数场景。完整的数据校验会增加 BlueStore 必须存储和管理的元数据量。只要可能例如客户端提示数据为顺序读写BlueStore 会对更大的块进行校验但在许多情况下它必须为每 4KB 数据块存储一个校验值通常为 4 字节。可以通过将校验和截断为一字节或两字节来获得更小的校验值并降低元数据开销但代价是随机错误未被检测的概率上升校验和位数未检出错误概率近似32 位4 字节约 1 / 40 亿4,294,967,29616 位2 字节1 / 65,5368 位1 字节1 / 256要使用更小的校验值可将校验算法选为crc32c_16或crc32c_8。校验算法既可通过每池的csum_type配置选项指定也可通过全局配置选项指定。例如ceph osd pool set pool-name csum_type algorithm相关全局选项为bluestore_csum_type其定义见 src/common/options/global.yaml.in。内联压缩Inline CompressionBlueStore 支持使用snappy、zlib、lz4或zstd进行内联压缩。数据是否被压缩由两个因素决定(1)压缩模式compression mode与 (2) 与写操作关联的客户端提示client hints。压缩模式如下none从不压缩数据。passive仅当写操作带有compressible可压缩提示时才压缩数据。aggressive除非写操作带有incompressible不可压缩提示否则压缩数据。force无论如何都尝试压缩数据。关于compressible与incompressibleI/O 提示的更多信息可参阅rados_set_alloc_hint接口说明。注意只有数据块在尺寸上得到充分缩减时由bluestore compression required ratio设置决定才会被压缩。无论采用何种压缩模式如果压缩后的数据块仍然太大压缩结果将被丢弃转而存储原始未压缩数据。例如bluestore compression required ratio设为.7则仅当压缩后数据尺寸不超过原始数据的 70% 时才进行压缩。压缩模式、压缩算法、压缩所需比例、最小 blob 大小与最大 blob 大小既可通过每池属性指定也可通过全局配置选项指定。通过每池属性设置ceph osd pool set pool-name compression_algorithm algorithm ceph osd pool set pool-name compression_mode mode ceph osd pool set pool-name compression_required_ratio ratio ceph osd pool set pool-name compression_min_blob_size size ceph osd pool set pool-name compression_max_blob_size size相关全局选项bluestore_compression_algorithm、bluestore_compression_mode、bluestore_compression_required_ratio、bluestore_compression_min_blob_size、bluestore_compression_min_blob_size_hdd、bluestore_compression_min_blob_size_ssd、bluestore_compression_max_blob_size、bluestore_compression_max_blob_size_hdd、bluestore_compression_max_blob_size_ssd。RocksDB ShardingBlueStore 维护多种内部键值数据全部存放在 RocksDB 中每种数据类型被赋予唯一前缀。在 Pacific 之前所有键值数据都存放在单一 RocksDB 列族 default 中Pacific 及以后版本中BlueStore 可以将键值数据划分到多个 RocksDB 列族。当键相似时——具体而言当键具有相近的访问频率、相近的修改频率和相近的生命周期时——BlueStore 可以获得更好的缓存效果与更精确的压缩compaction。在此条件下性能提升压缩所需磁盘空间也更少因为每个列族更小且可以独立压缩。Pacific 及以后版本部署的 OSD 默认使用 RocksDB sharding。但从更早版本升级到 Pacific 或更高版本的集群中Pacific 之前创建的 OSD 不会自动启用 sharding。要为指定 OSD 启用 sharding 并应用 Pacific 默认设置先停止该 OSD然后执行ceph-bluestore-tool \ --path data path \ --shardingm(3) p(3,0-12) O(3,0-13)block_cache{typebinned_lru} L P \ reshard相关选项bluestore_rocksdb_cf、bluestore_rocksdb_cfs。I/O 节流ThrottlingBlueStore 提供若干节流选项用于控制内部队列与延迟写入行为bluestore_throttle_bytes、bluestore_throttle_deferred_bytes、bluestore_throttle_cost_per_io、bluestore_throttle_cost_per_io_hdd、bluestore_throttle_cost_per_io_ssd。这些选项在高速设备与旋转盘上的默认成本系数不同适合在高吞吐或高延迟敏感场景中按设备类别微调。SPDK 高速路径可选要针对 NVMe 设备使用 SPDK 驱动需要先准备系统可参考 SPDK 官方入门文档。SPDK 提供了自动配置设备的脚本需要以 root 权限运行sudo src/spdk/scripts/setup.sh随后需要用带 spdk: 前缀的设备选择器指定目标 NVMe 设备的bluestore_block_path。例如先用lspci查找 Intel NVMe SSD 的设备选择器lspci -mm -n -D -d 8086:0953设备选择器的形式为DDDD:BB:DD.FF或DDDD.BB.DD.FF。假设查到的设备选择器为0000:01:00.0则配置为bluestore_block_path spdk:trtype:PCIe traddr:0000:01:00.0也可以指定基于 TCP 传输的远程 NVMeoF 目标例如bluestore_block_path spdk:trtype:TCP traddr:10.67.110.197 trsvcid:4420 subnqn:nqn.2019-02.io.spdk:cnode1要在单节点上运行多个 SPDK 实例必须为每个实例指定各自使用的 DPDK 内存量单位 MB。大多数情况下单个设备可用于 data、DB 与 WAL即共置策略。为确保所有 I/O 都经由 SPDK 发出请设置bluestore_block_db_path bluestore_block_db_size 0 bluestore_block_wal_path bluestore_block_wal_size 0若不进行上述设置当前实现会以内核文件系统符号填充 SPDK 映射文件并使用内核驱动发起 DB/WAL I/O。最小分配大小与空间放大Minimum Allocation SizeBlueStore 在底层存储设备上存在一个配置的最小分配量实践中这是即使微小的 RADOS 对象在每个 OSD 主设备上也能占用的最小容量。该配置项bluestore_min_alloc_size根据 OSD 的rotational属性从bluestore_min_alloc_size_hdd或bluestore_min_alloc_size_ssd取值HDD 上创建的 OSD 使用bluestore_min_alloc_size_hddSSD包括 NVMe上创建的 OSD 使用bluestore_min_alloc_size_ssd。各版本默认值演进Mimic 及更早版本旋转介质HDD默认 64KB非旋转介质SSD默认 16KB。Octopus非旋转介质SSD默认值改为 4KB。Pacific旋转介质HDD默认值也改为 4KB。这一变化源于 Ceph RADOS GatewayRGW部署在承载大量小文件S3/Swift 对象时经历的空间放大问题。例如 RGW 客户端存储一个 1KB 的 S3 对象时该对象写入单个 RADOS 对象按默认min_alloc_size会分配 4KB 底层空间意味着约 3KB4KB 减 1KB被分配但从未使用——对应约 300% 的开销、25% 的效率。而一个 5KB 的用户对象会存为两个 RADOS 对象4KB 1KB导致 4KB 设备容量被搁置不过此时开销百分比小得多。可以将其理解为取模运算的余数效应随着对象尺寸增大开销百分比迅速下降。还有一个容易被忽略的细节上述放大现象对每个副本都会发生。例如默认三副本3R时一个 1KB 的 S3 对象实际会搁置约 9KB 的设备容量若改用纠删码EC放大可能更高对于k4, m2的池1KB 的 S3 对象会占用 24KB4KB × 6设备容量。当 RGW bucket 池中多为较大的用户对象时该现象的影响往往可忽略但若部署中预期有相当比例的小对象就必须将其纳入规划。4KB 默认值与常规 HDD/SSD 设备契合良好。但某些新型粗粒度 IUIndirection UnitQLC SSD 在创建 OSD 时将bluestore_min_alloc_size_ssd指定为与设备 IU 匹配可能是 8KB、16KB 甚至 64KB时性能与寿命表现最佳。这些新型设备能以高于 TLC SSD 的密度和更低的成本提供与传统 TLC SSD 相当的读性能和快于 HDD 的写性能。在这些设备上创建 OSD 时必须小心只对合适的设备应用非默认值避免误用于常规 HDD/SSD可通过精心安排 OSD 创建顺序、自定义 OSD 设备类别尤其是使用集中配置的masks来规避错误。在 Quincy 及以后版本中可使用bluestore_use_optimal_io_size_for_min_alloc_size选项让每个 OSD 创建时自动发现正确值。注意bcache、OpenCAS、dmcrypt、ATA over Ethernet、iSCSI 等设备分层/抽象技术可能干扰正确值的判定部署在 VMware 存储之上的 OSD 有时也会报告与底层硬件不符的rotational属性。官方建议在启动时通过日志与 admin socket 检查这类 OSD 的行为并检查/sys/block/drive/queue/optimal_io_size的存在与取值。注意运行 Reef 或更新版本时每个 OSD 内建baked-in的min_alloc_size可由ceph osd metadata便捷地报告。检查特定 OSDceph osd metadata osd.1701 | egrep rotational|alloc空间放大可能表现为ceph df报告的 raw 与已存数据比例异常偏高ceph osd df报告的%USE/VAR值可能高于其他看似相同的 OSD混合min_alloc_size值的池中也可能出现意外的 balancer 行为。重要约束min_alloc_size仅在 OSD 创建时生效此后即使修改该属性已创建的 OSD 行为也不会改变除非销毁并用适当的选项值重新部署。升级到更新的 Ceph 版本同样不会改变旧版本或旧配置下部署的 OSD 所用的值。相关选项bluestore_min_alloc_size、bluestore_min_alloc_size_hdd、bluestore_min_alloc_size_ssd、bluestore_use_optimal_io_size_for_min_alloc_size。Filestore已被弃用的传统后端警告Filestore 已在 Reef 版本中被弃用且不再受支持。请迁移至 BlueStore。Filestore 是 Ceph 存储对象的传统方法它依赖标准文件系统通常为 XFS结合键值数据库传统上为 LevelDB现为 RocksDB管理部分元数据。Filestore 经过了充分测试并广泛用于生产环境但由于其整体设计以及对传统文件系统的依赖存在诸多性能缺陷。尽管 Filestore 能够在大多数 POSIX 兼容文件系统包括 btrfs 与 ext4上运行官方仅推荐使用 XFS 文件系统与 Ceph 配合btrfs 与 ext4 都存在已知 bug 与缺陷使用它们可能导致数据丢失。默认情况下所有 Ceph 部署工具都使用 XFS。自 Luminous 起 Filestore 已不是 Ceph 的默认后端BlueStore 取而代之Filestore OSD 在 Quincy 及以前仍受支持但在 Reef 中不再支持。Filestore 的完整配置参考见 doc/rados/configuration/filestore-config-ref.rst要点如下扩展属性XATTRFilestore OSD 依赖扩展属性但底层文件系统存储 XATTR 存在局限部分文件系统对 XATTR 可存字节数有限制。若底层文件系统无大小限制Ceph XATTR 以内联 xattr 形式存储若有大小限制如 ext4 限制总计 4KB达到阈值后部分 XATTR 会转入键值数据库。关键参数包括filestore_max_inline_xattr_size默认 0表示使用文件系统特定值、filestore_max_inline_xattr_size_xfs默认 65536、filestore_max_inline_xattr_size_btrfs默认 2048、filestore_max_inline_xattr_size_other默认 512以及filestore_max_inline_xattrs系列数量上限参数。同步间隔Synchronization IntervalsFilestore 必须定期静默写操作并同步文件系统每次同步产生一个一致的提交点之后可释放该点之前的日志条目。filestore_max_sync_interval默认 5 秒与filestore_min_sync_interval默认 0.01 秒控制同步频率的取舍更频繁的同步减少同步时间与日志滞留量更稀疏的同步让底层文件系统合并小写入但可能增加尾部延迟。Flusher 与队列filestore_flusher默认 false自 v.65 起已弃用强制大写入在同步前通过sync_file_range落盘filestore_queue_max_ops默认 50限制在途操作数filestore_queue_max_bytes默认100 20限制每操作字节数。线程与超时filestore_op_threads默认 2为并行文件系统操作线程数filestore_op_thread_timeout默认 60 秒与filestore_op_thread_suicide_timeout默认 180 秒控制操作超时。btrfs 专用filestore_btrfs_snap与filestore_btrfs_clone_range默认均开启仅适用于 btrfs。日志模式filestore_journal_parallelbtrfs 默认与filestore_journal_writeaheadXFS 默认定义日志并行/写前模式filestore_journal_trailing已弃用官方明确“切勿使用”。其他杂项filestore_merge_threshold默认 -10负值表示禁用子目录合并、filestore_split_multiple默认 2与filestore_split_rand_factor默认 20控制 Filestore 目录分裂/合并filestore_fail_eio默认 true使 OSD 在 EIO 时崩溃filestore_blackhole、filestore_dump_file、filestore_kill_at等为调试/故障注入选项。从 Filestore 迁移到 BlueStore由于 BlueStore 在性能与健壮性上优于 Filestore且 Filestore 自 Reef 起不再受支持部署 Filestore OSD 的用户应迁移至 BlueStore。完整流程见 doc/rados/operations/bluestore-migration.rst。BlueStore 与 Filestore 差异巨大单个 OSD 无法原地转换必须借助以下两类途径之一(1) 集群正常的复制与自愈机制或 (2) 将 OSD 内容从旧Filestore设备复制到新BlueStore设备的工具与策略。新部署直接使用 BlueStore扩展集群或更换故障盘后重新部署时直接使用 BlueStore 即可这是默认行为无需额外变更。现有 OSD 转换——“mark-out”替换法在集群健康的前提下逐个处理 Filestore OSD标记 OSD 为out、等待数据在集群中完成复制迁移、重新部署该 OSD、标记回in并在处理下一个 OSD 前等待恢复完成。该方法易于自动化但会带来不必要的数据迁移时间成本与 SSD 磨损。关键步骤# 判断某 OSD 是 Filestore 还是 BlueStore ceph osd metadata $ID | grep osd_objectstore # 统计集群中 Filestore 与 BlueStore OSD 的数量 ceph osd count-metadata osd_objectstore # 将 Filestore OSD 标记为 out ceph osd out $ID # 等待数据迁出该 OSD while ! ceph osd safe-to-destroy $ID ; do sleep 60 ; done # 停止该 OSD systemctl kill ceph-osd$ID随后销毁/重新部署该 OSD 为 BlueStore 并标记回in等待恢复完成后再处理下一个 OSD。小结与配置入口存储设备在 Ceph 集群中的角色划分清晰OSD 承担绝大部分数据的落盘任务Monitor 保存关键集群状态Manager 提供监控与外部接口而 OSD 的数据管理方式则由后端决定。BlueStore 作为当前默认且唯一推荐的 OSD 后端通过直接管理裸设备、RocksDB 元数据、全量校验和、内联压缩、多设备分层与高效写时复制在性能与健壮性上全面超越了传统 Filestore。规划 BlueStore 部署时应重点把握三件事设备布局block / block.db / block.wal与ceph-volume部署命令、block.db的容量规划WALDB 卸载时至少为主设备 2.5%RGW 场景至少 4%以及min_alloc_size对小型对象工作负载的空间放大影响。所有相关配置的完整参考可进一步查阅 BlueStore 配置参考、Filestore 配置参考、BlueStore 迁移指南 以及 对象存储配置总览配置项的声明与默认值可在 src/common/options/global.yaml.in 中核对BlueStore 实现细节可深入阅读 src/os/bluestore/BlueStore.h 及其同目录下的实现文件。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Ceph 之 ceph-volume lvm prepare 完全指南LVM 元数据标记、BlueStore 设备布局与 OSD 部署流程Ceph 之 ceph volume lvm prepare 完全指南LVM 元数据标记、BlueStore 设备布局与 OSD 部署流程 ceph volu存储分布式文件系统对象存储后端高可用第50章一剑斩金丹第50章一剑斩金丹 开头: 金丹长老嘲讽林天不自量力 发展: 林天拔剑展示剑意 高潮: 一剑斩杀金丹长老全场震惊 结尾: 宗主现身有趣我要收你为亲传人工智能AI 应用AI 写作RAGAI 插件AI 技能OneUptime Ceph Agent 部署指南基于 OpenTelemetry 采集器监控 Ceph 集群健康、OSD、存储池与归置组OneUptime Ceph Agent 部署指南基于 OpenTelemetry 采集器监控 Ceph 集群健康、OSD、存储池与归置组 OneUptime可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考