注意
本文档适用于 Ceph 的开发版本。
BlueStore 配置参考
设备
BlueStore 管理一个、两个,在某些情况下是三个存储设备。这些设备在 Linux/Unix 意义上是“设备”。这意味着它们是在 /dev 或 /devices 下列出的资源。这些设备中的每一个都可以是整个存储驱动器、存储驱动器的分区或逻辑卷。BlueStore 不会在它使用的设备上创建或挂载传统的G文件系统;BlueStore 以“原始”方式直接读写设备。
在最简单的情况下,BlueStore 占用单个存储设备的所有空间。此设备称为主设备。主设备由数据目录中的 block 符号链接标识。
数据目录是一个 tmpfs 挂载。当 ceph-volume 启动或激活此数据目录时,它会填充元数据文件和链接,其中包含有关 OSD 的信息:例如,OSD 的标识符、OSD 所属集群的名称以及 OSD 的私钥环。
在更复杂的情况下,BlueStore 会部署在一个或两个附加设备上
预写日志 (WAL) 设备(在数据目录中标识为
block.wal)可用于分离 BlueStore 的内部日志或预写日志。仅当 WAL 设备快于主设备(例如,如果 WAL 设备是 SSD 而主设备是 HDD)时,使用 WAL 设备才有利。DB 设备(在数据目录中标识为
block.db)可用于存储 BlueStore 的内部元数据。BlueStore(更准确地说是嵌入式 RocksDB)会将尽可能多的元数据放在 DB 设备上,以提高性能。如果 DB 设备满了,元数据将溢出回主设备(在没有 DB 设备的情况下,它将位于此处)。同样,仅当 DB 设备快于主设备时,配置 DB 设备才有利。
如果只有少量快速存储可用(例如,小于一千兆字节),我们建议将可用空间用作 WAL 设备。但是,如果有更多快速存储可用,则配置 DB 设备更有意义。因为 BlueStore 日志始终放置在最快的可用设备上,所以使用 DB 设备可提供与使用 WAL 设备相同的优势,同时还允许将额外的元数据存储在主设备之外(前提是它适合)。DB 设备之所以能实现这一点,是因为只要指定了 DB 设备但未指定显式 WAL 设备,WAL 就会隐式地与 DB 共同位于更快的设备上。
要配置单设备(共同定位)BlueStore OSD,请运行以下命令
ceph-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 OSD。但是,通过检查以下两种常见安排,可以阐明 BlueStore 的总体部署策略
仅 block(数据)
如果所有设备都是相同类型(例如,它们都是 HDD),并且没有可用于存储元数据的快速设备,那么仅指定块设备并将 block.db 和 block.wal 分离是合理的。单个 /dev/sda 设备的 lvm 命令如下
ceph-volume lvm create --bluestore --data /dev/sda
如果用于 BlueStore OSD 的设备是预先创建的逻辑卷,则名为 ceph-vg/block-lv 的逻辑卷的 lvm 调用如下
ceph-volume lvm create --bluestore --data ceph-vg/block-lv
block 和 block.db
如果您混合使用快速和慢速设备(例如 SSD 或 HDD),我们建议将 block.db 放置在快速设备上,而将 block(即数据)存储在慢速设备上(即旋转驱动器)。
您必须手动创建这些卷组和逻辑卷。 ceph-volume 工具目前无法自动执行此操作 [创建它们?]。
以下过程演示了手动创建卷组和逻辑卷。对于此示例,我们将假设有四个旋转驱动器(sda、sdb、sdc 和 sdd)和一个(快速)SSD(sdx)。首先,要创建卷组,请运行以下命令
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 逻辑卷
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
最后,要创建四个 OSD,请运行以下命令
ceph-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
完成此过程后,应该有四个 OSD,block 应该位于四个 HDD 上,并且每个 HDD 应该在共享 SSD 上有一个 50GB 逻辑卷(特别是 DB 设备)。
大小调整
当使用混合旋转驱动器和固态驱动器设置时,重要的是为 BlueStore 创建足够大的 block.db 逻辑卷。与 block.db 关联的逻辑卷应该具有尽可能大的逻辑卷。
通常建议 block.db 的大小在 block 大小的 1% 到 4% 之间。对于 RGW 工作负载,建议 block.db 至少为 block 大小的 4%,因为 RGW 大量使用 block.db 来存储元数据(特别是 omap 键)。例如,如果 block 大小为 1TB,则 block.db 的大小应至少为 40GB。然而,对于 RBD 工作负载,block.db 通常只需要 block 大小的 1% 到 2%。
在较旧的版本中,内部级别大小使得 DB 只能充分利用那些对应于 L0、L0+L1、L1+L2 等总和的特定分区/逻辑卷大小——即,在默认设置下,大小约为 3GB、30GB 和 300GB 等。大多数部署不会从容纳 L3 和更高版本的大小调整中获得实质性好处,尽管通过将这些数字加倍到 6GB、60GB 和 600GB 可以促进 DB 压缩。
Nautilus 14.2.12、Octopus 15.2.6 和后续版本中的改进允许更好地利用任意大小的 DB 设备。此外,Pacific 版本带来了实验性动态级别支持。由于这些进步,旧版本的用户可能希望通过立即配置更大的 DB 设备来提前计划,以便在将来进行升级时实现规模效益。
当不混合使用快速和慢速设备时,无需为 block.db 或 block.wal 创建单独的逻辑卷。BlueStore 将在 block 空间内自动共同定位这些设备。
自动缓存大小调整
BlueStore 可以配置为自动调整其缓存大小,前提是满足某些条件:TCMalloc 必须配置为内存分配器,并且必须启用 bluestore_cache_autotune 配置选项(请注意,目前默认启用)。当自动缓存大小调整生效时,BlueStore 会尝试将 OSD 堆内存使用量保持在某个目标大小以下(由 osd_memory_target 确定)。此方法使用尽力而为的算法,缓存不会缩小到小于 osd_memory_cache_min 值定义的大小。缓存比例是根据优先级层次结构选择的。但是,如果优先级信息不可用,则使用 bluestore_cache_meta_ratio 和 bluestore_cache_kv_ratio 选项中指定的值作为回退缓存比例。
- bluestore_cache_autotune
自动调整分配给各种 BlueStore 缓存的空间比例,同时尊重最小值。
- 类型:
bool- 默认值:
true- 另请参阅:
- osd_memory_target
当 TCMalloc 可用且启用缓存自动调整时,尝试将这么多字节映射到内存中。注意:这可能与进程的 RSS 内存使用量不完全匹配。虽然进程映射的堆内存总量通常应接近此目标,但不能保证内核会实际回收已取消映射的内存。在最初的开发过程中,发现某些内核会导致 OSD 的 RSS 内存超过映射内存高达 20%。然而,假设当内存压力很高时,内核通常会更积极地回收未映射的内存。您的结果可能会有所不同。
- 类型:
大小- 默认值:
4Gi- min:
896_M- 另请参阅:
bluestore_cache_autotune,osd_memory_cache_min,osd_memory_base,osd_memory_target_autotune
- bluestore_cache_autotune_interval
启用缓存自动调整时,在重新平衡之间等待的秒数。bluestore_cache_autotune_interval 设置 Ceph 重新计算各种缓存分配比例的速度。注意:将此间隔设置得太小可能会导致 CPU 使用率高和性能降低。
- 类型:
float- 默认值:
5.0- 另请参阅:
- osd_memory_base
当启用 TCMalloc 和缓存自动调整时,估计 OSD 将需要的最小内存量(以字节为单位)。这用于帮助自动调整器估计缓存的预期总内存消耗。
- 类型:
大小- 默认值:
768Mi- 另请参阅:
- osd_memory_expected_fragmentation
当启用 TCMalloc 和缓存自动调整时,估计内存碎片的百分比。这用于帮助自动调整器估计缓存的预期总内存消耗。
- 类型:
float- 默认值:
0.15- 允许范围:
[0, 1]- 另请参阅:
- osd_memory_cache_min
当启用 TCMalloc 和缓存自动调整时,设置用于缓存的最小内存量。注意:将此值设置得太低可能会导致严重的缓存颠簸。
- 类型:
大小- 默认值:
128Mi- min:
128_M- 另请参阅:
- osd_memory_cache_resize_interval
当启用 TCMalloc 和缓存自动调整时,在调整缓存大小之间等待的秒数。此设置更改 BlueStore 可用于缓存的内存总量。请注意,将此间隔设置得太小可能会导致内存分配器颠簸和性能降低。
- 类型:
float- 默认值:
1.0- 另请参阅:
手动缓存大小调整
每个 OSD 用于其 BlueStore 缓存的内存量由 bluestore_cache_size 配置选项确定。如果未指定该选项(即,如果它保持为 0),则 Ceph 使用不同的配置选项来确定默认内存预算:如果主设备是 HDD,则使用 bluestore_cache_size_hdd;如果主设备是 SSD,则使用 bluestore_cache_size_ssd。
BlueStore 和 Ceph OSD 守护程序的其余部分会尽一切努力在此内存预算内工作。请注意,除了配置的缓存大小之外,OSD 本身还会消耗内存。由于内存碎片和其他分配器开销,还会产生额外的利用率。
配置的缓存内存预算可用于存储以下类型的内容
键/值元数据(即 RocksDB 的内部缓存)
BlueStore 元数据
BlueStore 数据(即最近读取或最近写入的对象数据)
缓存内存使用由配置选项 bluestore_cache_meta_ratio 和 bluestore_cache_kv_ratio 管理。保留用于数据的缓存部分由有效的 BlueStore 缓存大小(取决于相关 bluestore_cache_size[_ssd|_hdd] 选项和主设备的设备类)以及“meta”和“kv”比例共同决定。此数据部分可以使用以下公式计算:<effective_cache_size> * (1 - bluestore_cache_meta_ratio - bluestore_cache_kv_ratio)。
- bluestore_cache_size
BlueStore 将用于其缓存的内存量。如果为零,则将使用
bluestore_cache_size_hdd或bluestore_cache_size_ssd。- 类型:
大小- 默认值:
0B
- bluestore_cache_size_hdd
当由 HDD 支持时,BlueStore 将用于其缓存的默认内存量。
- 类型:
大小- 默认值:
1Gi- 另请参阅:
- bluestore_cache_size_ssd
当由 SSD 支持时,BlueStore 将用于其缓存的默认内存量。
- 类型:
大小- 默认值:
3Gi- 另请参阅:
- bluestore_cache_meta_ratio
BlueStore 缓存中用于元数据的比例
- 类型:
float- 默认值:
0.45- 另请参阅:
- bluestore_cache_kv_ratio
BlueStore 缓存中用于键/值数据库 (RocksDB) 的比例
- 类型:
float- 默认值:
0.45- 另请参阅:
校验和
BlueStore 对写入磁盘的所有元数据和所有数据进行校验和。元数据校验和由 RocksDB 处理,并使用 crc32c 算法。相比之下,数据校验和由 BlueStore 处理,可以使用 crc32c、xxhash32 或 xxhash64。尽管如此,crc32c 是默认的校验和算法,适用于大多数用途。
完整数据校验和增加了 BlueStore 必须存储和管理的元数据量。只要有可能(例如,当客户端提示数据按顺序写入和读取时),BlueStore 将校验和更大的块。然而,在许多情况下,它必须为每 4 KB 数据块存储一个校验和值(通常为 4 字节)。
可以通过将校验和截断为一到两个字节来获得较小的校验和值,从而减少元数据开销。这种方法的缺点是它增加了随机错误未被检测到的概率:对于 32 位(4 字节)校验和,大约为四亿分之一;对于 16 位(2 字节)校验和,为 65,536 分之一;对于 8 位(1 字节)校验和,为 256 分之一。要使用较小的校验和值,请选择 crc32c_16 或 crc32c_8 作为校验和算法。
校验和算法可以通过按池 csum_type 配置选项或全局配置选项指定。例如
ceph osd pool set <pool-name> csum_type <algorithm>
- bluestore_csum_type
要使用的默认校验和算法。
- 类型:
str- 默认值:
crc32c- 有效选项:
nonecrc32ccrc32c_16crc32c_8xxhash32xxhash64
内联压缩
BlueStore 支持使用 snappy、zlib、lz4 或 zstd 进行内联压缩。
BlueStore 中的数据是否压缩由两个因素决定:(1) 压缩模式和 (2) 与写入操作相关的任何客户端提示。压缩模式如下
none: 从不压缩数据。
passive: 除非写入操作设置了可压缩提示,否则不压缩数据。
aggressive: 除非写入操作设置了不可压缩提示,否则压缩数据。
force: 无论如何都尝试压缩数据。
有关可压缩和不可压缩 I/O 提示的更多信息,请参阅 rados_set_alloc_hint()。
请注意,BlueStore 中的数据仅在数据块大小足够减小(由 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
如果未设置按池属性
compression_algorithm,则使用的默认压缩器(如果有)。请注意,由于压缩少量数据时 CPU 开销高,因此不建议将zstd用于 BlueStore。- 类型:
str- 默认值:
snappy- 有效选项:
<空字符串>
snappyzlibzstdlz4
- bluestore_compression_mode
如果未设置按池属性
compression_mode,则使用压缩的默认策略。none表示从不使用压缩。passive表示当clients hint数据可压缩时使用压缩。aggressive表示使用压缩,除非客户端提示数据不可压缩。force表示在所有情况下都使用压缩,即使客户端提示数据不可压缩。- 类型:
str- 默认值:
none- 有效选项:
nonepassiveaggressiveforce
- bluestore_compression_required_ratio
压缩后数据块大小与原始大小的比率必须至少小到这个程度才能存储压缩版本。
- 类型:
float- 默认值:
0.875
- bluestore_compression_min_blob_size
小于此值的块永远不会被压缩。按池属性
compression_min_blob_size覆盖此设置。- 类型:
大小- 默认值:
0B
- bluestore_compression_min_blob_size_hdd
旋转介质的
bluestore compression min blob size默认值。- 类型:
大小- 默认值:
8Ki- 另请参阅:
- bluestore_compression_min_blob_size_ssd
非旋转(固态)介质的
bluestore compression min blob size默认值。- 类型:
大小- 默认值:
64Ki- 另请参阅:
- bluestore_compression_max_blob_size
大于此值的块在压缩之前会分解为最多
bluestore_compression_max_blob_size字节的小 blob。按池属性compression_max_blob_size覆盖此设置。- 类型:
大小- 默认值:
0B
- bluestore_compression_max_blob_size_hdd
旋转介质的
bluestore compression max blob size默认值。- 类型:
大小- 默认值:
64Ki- 另请参阅:
- bluestore_compression_max_blob_size_ssd
非旋转(SSD、NVMe)介质的
bluestore compression max blob size默认值。- 类型:
大小- 默认值:
64Ki- 另请参阅:
RocksDB 分片
BlueStore 维护几种内部键值数据类型,所有这些都存储在 RocksDB 中。BlueStore 中的每种数据类型都分配有一个唯一的前缀。在 Pacific 版本之前,所有键值数据都存储在一个 RocksDB 列族中:“default”。然而,在 Pacific 及更高版本中,BlueStore 可以将键值数据划分为几个 RocksDB 列族。当键相似时,BlueStore 可实现更好的缓存和更精确的压缩:具体来说,当键具有相似的访问频率、相似的修改频率和相似的生命周期时。在这种情况下,性能会得到改善,并且在压缩期间所需的磁盘空间更少(因为每个列族更小,并且能够独立于其他列族进行压缩)。
在 Pacific 或更高版本中部署的 OSD 默认使用 RocksDB 分片。但是,如果 Ceph 已从早期版本升级到 Pacific 或更高版本,则在 Pacific 之前创建的任何 OSD 上都会禁用分片。
要启用分片并将 Pacific 默认设置应用于特定 OSD,请停止 OSD 并运行以下命令
ceph-bluestore-tool \ --path <data path> \ --sharding="m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P" \ reshard
- bluestore_rocksdb_cf
启用 BlueStore 的 RocksDB 分片。当为
true时,使用bluestore_rocksdb_cfs。仅当 OSD 执行--mkfs时才应用。- 类型:
bool- 默认值:
true
- bluestore_rocksdb_cfs
BlueStore 的 RocksDB 分片定义。最佳值取决于多个因素,不建议修改。此设置仅在 OSD 执行
--mkfs时使用。OSD 的后续运行从磁盘检索分片。- 类型:
str- 默认值:
m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L=min_write_buffer_number_to_merge=32 P=min_write_buffer_number_to_merge=32
限流
- bluestore_throttle_bytes
在限流 IO 提交之前,最大传输中的字节数
- 类型:
大小- 默认值:
64Mi
- bluestore_throttle_deferred_bytes
在限流 IO 提交之前,延迟写入的最大字节数
- 类型:
大小- 默认值:
128Mi
- bluestore_throttle_cost_per_io
添加到每个 IO 的事务成本(以字节为单位)的开销
- 类型:
大小- 默认值:
0B
- bluestore_throttle_cost_per_io_hdd
旋转介质 (HDD) 的默认 bluestore_throttle_cost_per_io
- 类型:
uint- 默认值:
670000- 另请参阅:
- bluestore_throttle_cost_per_io_ssd
非旋转 (SSD) 介质的默认 bluestore_throttle_cost_per_io
- 类型:
uint- 默认值:
4000- 另请参阅:
SPDK 用法
要将 SPDK 驱动程序用于 NVMe 设备,您必须首先准备系统。请参阅 SPDK 文档。
SPDK 提供了一个脚本,可以自动配置设备。以 root 权限运行此脚本
sudo src/spdk/scripts/setup.sh
您需要为 bluestore_block_path 指定主题 NVMe 设备的设备选择器,并带有“spdk:”前缀。
在以下示例中,您首先通过运行以下命令查找 Intel NVMe SSD 的设备选择器
lspci -mm -n -D -d 8086:0953
设备选择器的形式为 DDDD:BB:DD.FF 或 DDDD.BB.DD.FF。
接下来,假设 0000:01:00.0 是在 lspci 命令输出中找到的设备选择器,您可以通过运行以下命令指定设备选择器
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 内存,方法是为每个实例指定实例将使用的 DPDK 内存量(以 MB 为单位)。
在大多数情况下,单个设备可用于数据、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。
最小分配大小
BlueStore 在底层存储设备上配置了最小存储分配量。实际上,这是即使是很小的 RADOS 对象在每个 OSD 的主设备上也可以消耗的最少容量。有问题的配置选项 bluestore_min_alloc_size 根据 OSD 的 rotational 属性从 bluestore_min_alloc_size_hdd 或 bluestore_min_alloc_size_ssd 的值派生其值。因此,如果 OSD是在 HDD 上创建的,BlueStore 将使用 bluestore_min_alloc_size_hdd 的当前值进行初始化;但是对于 SSD OSD(包括 NVMe 设备),Bluestore 使用 bluestore_min_alloc_size_ssd 的当前值进行初始化。
在 Mimic 及更早版本中,旋转介质 (HDD) 的默认值为 64KB,非旋转介质 (SSD) 的默认值为 16KB。Octopus 版本将非旋转介质 (SSD) 的默认值更改为 4KB,Pacific 版本将旋转介质 (HDD) 的默认值更改为 4KB。
这些更改是由托管大量小文件(S3/Swift 对象)的 Ceph RADOS GateWay (RGW) 部署所经历的空间放大驱动的。
例如,当 RGW 客户端存储一个 1 KB S3 对象时,该对象将写入单个 RADOS 对象。根据默认的 min_alloc_size 值,分配了 4 KB 的底层驱动器空间。这意味着分配了大约 3 KB(即 4 KB 减去 1 KB)但从未使用过:这对应于 300% 的开销或 25% 的效率。同样,一个 5 KB 的用户对象将存储为两个 RADOS 对象,一个 4 KB RADOS 对象和一个 1 KB RADOS 对象,结果是 4KB 的设备容量被搁置。然而,在这种情况下,开销百分比要小得多。将此视为模运算的余数。因此,随着对象大小的增加,开销百分比迅速减小。
还有一个很容易被忽略的微妙之处:刚刚描述的放大现象发生在每个副本上。例如,当使用默认的三份数据副本 (3R) 时,一个 1 KB S3 对象实际上会搁置大约 9 KB 的存储设备容量。如果使用纠删码 (EC) 而不是复制,放大可能会更高:对于 k=4, m=2 池,我们的 1 KB S3 对象分配 24 KB(即 4 KB 乘以 6)的设备容量。
当 RGW 存储桶池包含许多相对较大的用户对象时,这种现象的影响通常可以忽略不计。但是,对于那些可能预期有相当一部分相对较小的用户对象的部署,应考虑这种影响。
4KB 的默认值与传统 HDD 和 SSD 设备非常吻合。然而,某些新型粗 IU(间接单元)QLC SSD 在 bluestore_min_alloc_size_ssd 在 OSD 创建时指定以匹配设备的 IU 时,性能和磨损最佳:这可能是 8KB、16KB 甚至 64KB。这些新型存储驱动器可以实现与传统 TLC SSD 相当的读取性能和比 HDD 更快的写入性能,具有比 TLC SSD 更高的密度和更低的成本。
请注意,在这些新型设备上创建 OSD 时,必须小心仅将非默认值应用于适当的设备,而不是传统 HDD 和 SSD 设备。可以通过仔细安排 OSD 创建顺序、使用自定义 OSD 设备类,尤其是使用中心配置掩码来避免错误。
在 Quincy 及更高版本中,您可以使用 bluestore_use_optimal_io_size_for_min_alloc_size 选项,以便在创建每个 OSD 时自动发现正确的值。请注意,使用 bcache、OpenCAS、dmcrypt、ATA over Ethernet、iSCSI 或其他设备分层和抽象技术可能会混淆正确值的确定。此外,有时发现部署在 VMware 存储之上的 OSD 报告的 rotational 属性与底层硬件不匹配。
我们建议在启动时通过日志和管理套接字检查此类 OSD,以确保它们的行为正确。请注意,这种检查可能无法像旧内核那样按预期工作。要检查此问题,请检查 /sys/block/<drive>/queue/optimal_io_size 的存在和值。
注意
当运行 Reef 或更高版本的 Ceph 时,每个 OSD 中内置的 min_alloc_size 会方便地由 ceph osd metadata 报告。
要检查特定的 OSD,请运行以下命令
ceph osd metadata osd.1701 | egrep rotational\|alloc
这种空间放大可能表现为 ceph df 报告的原始数据与存储数据之比异常高。可能还会出现 ceph osd df 报告的 %USE / VAR 值与其他表面上相同的 OSD 相比异常高。最后,使用具有不匹配 min_alloc_size 值的 OSD 的池中可能存在意外的均衡器行为。
此 BlueStore 属性仅在 OSD 创建时生效;如果以后更改该属性,除非 OSD 被销毁并使用适当的选项值重新部署,否则特定 OSD 的行为不会改变。升级到更高版本的 Ceph 不会更改旧版本下或使用其他设置部署的 OSD 使用的值。
- bluestore_min_alloc_size
较小的分配大小通常意味着当触发写时复制操作时(例如,当写入最近快照的内容时),读取和重写的数据较少。同样,在执行覆盖之前(小于 min_alloc_size 的写入必须首先通过 BlueStore WAL),日志记录的数据较少。较大的 min_alloc_size 值会减少描述磁盘布局所需的元数据量并减少总体碎片。将此值设置为 0 表示根据底层设备的内核旋转属性从 bluestore_min_alloc_size_hdd 或 bluestore_min_alloc_size_ssd 中获取有效值。请注意,这在创建时内置到每个 OSD 中。必须重建 OSD 才能使用不同的值。
- 类型:
uint- 默认值:
0
- bluestore_min_alloc_size_hdd
旋转介质的默认 min_alloc_size 值
- 类型:
大小- 默认值:
4Ki- 另请参阅:
- bluestore_min_alloc_size_ssd
非旋转(固态)介质的默认 min_alloc_size 值
- 类型:
大小- 默认值:
4Ki- 另请参阅:
- bluestore_use_optimal_io_size_for_min_alloc_size
发现介质最佳 IO 大小并用于 min_alloc_size。当 OSD 在粗 IU QLC SSD 或其他新型底层块设备上创建时,这非常有用。对于传统介质,它是一个 no-op。
- 类型:
bool- 默认值:
false- 另请参阅:
DSA(数据流加速器)用法
如果要使用 DML 库来驱动 DSA 设备以在 BlueStore 中卸载对持久内存 (PMEM) 的读/写操作,则需要安装 DML 和 idxd-config 库。这仅适用于具有 SPR (Sapphire Rapids) CPU 的机器。
安装 DML 软件后,参考以下 WQ 配置示例配置共享工作队列 (WQ)
accel-config config-wq --group-id=1 --mode=shared --wq-size=16 --threshold=15 --type=user --name="MyApp1" --priority=10 --block-on-fault=1 dsa0/wq0.1
accel-config config-engine dsa0/engine0.1 --group-id=1
accel-config enable-device dsa0
accel-config enable-wq dsa0/wq0.1