注意

本文档适用于 Ceph 的开发版本。

OSD 服务

列出设备

ceph-volume 会定期扫描集群中的每个主机，以确定当前存在且响应的设备。它还会确定每个设备是否符合在块、DB 或 WAL 角色中用于新 OSD 的条件。

要打印 cephadm 发现的设备列表，请运行以下命令

ceph orch device ls [--hostname=...] [--wide] [--refresh]

示例

Hostname  Path      Type  Serial              Size   Health   Ident  Fault  Available
srv-01    /dev/sdb  hdd   15P0A0YFFRD6         300G  Unknown  N/A    N/A    No
srv-01    /dev/sdc  hdd   15R0A08WFRD6         300G  Unknown  N/A    N/A    No
srv-01    /dev/sdd  hdd   15R0A07DFRD6         300G  Unknown  N/A    N/A    No
srv-01    /dev/sde  hdd   15P0A0QDFRD6         300G  Unknown  N/A    N/A    No
srv-02    /dev/sdb  hdd   15R0A033FRD6         300G  Unknown  N/A    N/A    No
srv-02    /dev/sdc  hdd   15R0A05XFRD6         300G  Unknown  N/A    N/A    No
srv-02    /dev/sde  hdd   15R0A0ANFRD6         300G  Unknown  N/A    N/A    No
srv-02    /dev/sdf  hdd   15R0A06EFRD6         300G  Unknown  N/A    N/A    No
srv-03    /dev/sdb  hdd   15R0A0OGFRD6         300G  Unknown  N/A    N/A    No
srv-03    /dev/sdc  hdd   15R0A0P7FRD6         300G  Unknown  N/A    N/A    No
srv-03    /dev/sdd  hdd   15R0A0O7FRD6         300G  Unknown  N/A    N/A    No

在上述示例中，您可以看到名为 Health、Ident 和 Fault 的字段。此信息由与 libstoragemgmt 的集成提供。默认情况下，此集成是禁用的，因为 libstoragemgmt 可能与您的硬件不完全兼容。要指示 Ceph 包含这些字段，请按如下方式启用 cephadm 的“增强设备扫描”选项

ceph config set mgr mgr/cephadm/device_enhanced_scan true

请注意，ceph orch device ls 报告的列可能因版本而异。

--wide 选项显示设备详细信息，包括设备可能不适合用作 OSD 的任何原因。示例（Reef）

HOST               PATH          TYPE  DEVICE ID                                      SIZE  AVAILABLE  REFRESHED  REJECT REASONS
davidsthubbins    /dev/sdc       hdd   SEAGATE_ST20000NM002D_ZVTBJNGC17010W339UW25    18.1T  No         22m ago    Has a FileSystem, Insufficient space (<10 extents) on vgs, LVM detected
nigeltufnel       /dev/sdd       hdd   SEAGATE_ST20000NM002D_ZVTBJNGC17010C3442787    18.1T  No         22m ago    Has a FileSystem, Insufficient space (<10 extents) on vgs, LVM detected

警告

尽管 libstoragemgmt 库发出标准的 SCSI (SES) 查询调用，但不能保证您的硬件和固件正确实现了这些标准。这可能导致某些旧硬件上出现不稳定行为，甚至总线重置。因此，建议在启用此功能之前，首先测试您的硬件与 libstoragemgmt 的兼容性，以避免服务意外中断。

有多种方法可以测试兼容性，但最简单的方法是使用 cephadm shell 直接调用 libstoragemgmt：cephadm shell lsmcli ldl。如果您的硬件受支持，您应该会看到类似以下内容

Path     | SCSI VPD 0x83    | Link Type | Serial Number      | Health Status
----------------------------------------------------------------------------
/dev/sda | 50000396082ba631 | SAS       | 15P0A0R0FRD6       | Good
/dev/sdb | 50000396082bbbf9 | SAS       | 15P0A0YFFRD6       | Good

启用 libstoragemgmt 支持后，输出将如下所示

# ceph orch device ls
Hostname   Path      Type  Serial              Size   Health   Ident  Fault  Available
srv-01     /dev/sdb  hdd   15P0A0YFFRD6         300G  Good     Off    Off    No
srv-01     /dev/sdc  hdd   15R0A08WFRD6         300G  Good     Off    Off    No
:

在此示例中，libstoragemgmt 已确认驱动器的健康状况以及与驱动器外壳上的识别和故障 LED 交互的能力。有关与这些 LED 交互的更多信息，请参阅设备管理。

注意

当前版本的 libstoragemgmt` (1.8.8) 仅支持基于 SCSI、SAS 和 SATA 的本地驱动器。没有对 NVMe 设备 (PCIe)、SAN LUN 或复杂元设备的官方支持。

检索块设备的精确大小

运行以下形式的命令以发现块设备的精确大小。编排器在根据大小进行过滤时会使用此返回的值

cephadm shell ceph-volume inventory </dev/sda> --format json | jq .sys_api.human_readable_size

以 GB 为单位的精确大小是 TB 中报告的大小乘以 1024。

示例

以下是基于上述命令一般形式的特定命令示例

cephadm shell ceph-volume inventory /dev/sdc --format json | jq .sys_api.human_readable_size

"3.64 TB"

这表明精确设备大小为 3.64 TB，即 3727.36 GB。

此过程由 Frédéric Nass 开发。有关此事的讨论，请参阅[ceph-users] 邮件列表上的此主题。

部署 OSD

列出存储设备

为了部署 OSD，必须有一个或多个可用的存储设备来部署 OSD。

运行此命令可显示所有集群主机上的存储设备清单

ceph orch device ls

如果满足以下所有条件，则存储设备被认为是可用的

设备不得有分区。
设备不得有任何 LVM 状态。
设备不得被挂载。
设备不得包含文件系统。
设备不得包含 Ceph BlueStore OSD。
设备必须 >= 5 GB。

Ceph 不会在非可用设备上配置 OSD。

创建新 OSD

有多种方法可以创建新 OSD

使用任何可用且未使用的存储设备

ceph orch apply osd --all-available-devices

从特定主机上的特定设备创建 OSD

ceph orch daemon add osd *<host>*:*<device-path>*

例如

ceph orch daemon add osd host1:/dev/sdb

从特定主机上的特定设备高级创建 OSD

ceph orch daemon add osd host1:data_devices=/dev/sda,/dev/sdb,db_devices=/dev/sdc,osds_per_device=2

在特定主机上的特定 LVM 逻辑卷上创建 OSD

ceph orch daemon add osd *<host>*:*<lvm-path>*

例如

ceph orch daemon add osd host1:/dev/vg_osd/lvm_osd1701

您可以使用高级 OSD 服务规范根据设备的属性对其进行分类。这对于阐明哪些设备可供使用非常有用。属性包括设备类型（SSD 或 HDD）、设备型号名称、大小以及设备所在的主机
```
ceph orch apply -i spec.yml
```

警告

使用 cephadm 部署新 OSD 时，请确保目标主机上未安装 ceph-osd 软件包。如果已安装，可能会在 OSD 的管理和控制中产生冲突，从而导致错误或意外行为。

使用 ceph orch daemon add osd 创建的新 OSD 将作为托管 OSD 添加到 osd.default 下，并具有有效的规范。

要将现有 OSD 附加到不同的托管服务，可以使用 ceph orch osd set-spec-affinity 命令
```
ceph orch osd set-spec-affinity <service_name> <osd_id(s)>
```
例如
```
ceph orch osd set-spec-affinity osd.default_drive_group 0 1
```

空运行

--dry-run 标志使编排器显示即将发生的事情的预览，而无需实际创建 OSD。

例如

ceph orch apply osd --all-available-devices --dry-run

NAME                  HOST  DATA      DB  WAL
all-available-devices node1 /dev/vdb  -   -
all-available-devices node2 /dev/vdc  -   -
all-available-devices node3 /dev/vdd  -   -

声明性状态

ceph orch apply 的效果是持久的。这意味着在 ceph orch apply 命令完成后添加到系统的驱动器将根据规范自动检测并添加到集群中。这也意味着在 ceph orch apply 命令完成后变得可用（例如通过 zapping）的驱动器将自动找到并添加到集群中。

我们将检查以下命令的效果

ceph orch apply osd --all-available-devices

运行上述命令后

当您向集群添加新驱动器时，它们将自动用于创建新 OSD。
当您移除 OSD 并清理 LVM 物理卷时，将自动创建新 OSD。

如果您想避免这种行为（禁用在可用设备上自动创建 OSD），请使用 unmanaged 参数

ceph orch apply osd --all-available-devices --unmanaged=true

注意

请记住这三个事实

ceph orch apply 的默认行为导致 cephadm 不断协调。这意味着 cephadm 一旦检测到新驱动器就会创建 OSD。
设置 unmanaged: True 会禁用 OSD 的创建。如果设置了 unmanaged: True，即使您应用新的 OSD 服务，也不会发生任何事情。
ceph orch daemon add 创建 OSD，但不添加 OSD 服务。

有关 cephadm 的更多信息，另请参阅禁用守护程序自动部署。

移除 OSD

从集群中移除 OSD 涉及两个步骤

从 OSD 疏散所有放置组 (PG)
从集群中移除无 PG 的 OSD

以下命令执行这两个步骤

ceph orch osd rm <osd_id(s)> [--replace] [--force] [--zap]

示例

ceph orch osd rm 0
ceph orch osd rm 1138 --zap

预期输出

Scheduled OSD(s) for removal

不安全销毁的 OSD 将被拒绝。添加 --zap 标志指示编排器从 OSD 的驱动器中移除所有 LVM 和分区信息，使其成为用于重新部署或其他重用的空白状态。

注意

移除 OSD 后，如果 OSD 的驱动器变得可用，并且它们与现有的 drivegroup 规范匹配，cephadm 可能会自动尝试在这些驱动器上部署更多 OSD。如果您使用规范部署要移除的 OSD，并且不希望在移除后在驱动器上部署任何新的 OSD，最好在移除之前修改 drivegroup 规范。您可以将 unmanaged: true 设置为停止它接收新驱动器，或者以某种方式修改它，使其不再匹配用于要移除的 OSD 的驱动器。然后重新应用该规范。有关 drivegroup 规范的更多信息，请参阅高级 OSD 服务规范。有关 cephadm 在部署 OSD 方面的声明性质的更多信息，请参阅声明性状态

移除 OSD 期间监控 OSD 状态

您可以通过运行以下命令在移除 OSD 的过程中查询 OSD 操作的状态

ceph orch osd rm status

预期输出

OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
     cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
     cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
     cephadm-dev  started                  42        False    True   2020-07-17 13:01:45.162158

当 OSD 上没有剩余 PG 时，它将被退役并从集群中移除。

注意

移除 OSD 后，如果您擦除被移除 OSD 使用的设备中的 LVM 物理卷，将创建新的 OSD。有关此内容的更多信息，请阅读声明性状态中关于 unmanaged 参数的内容。

停止移除 OSD

可以使用以下命令停止排队的 OSD 移除

ceph orch osd rm stop <osd_id(s)>

示例

ceph orch osd rm stop 4

预期输出

Stopped OSD(s) removal

这将重置 OSD 的状态并将其从移除队列中取出。

替换 OSD

ceph orch osd rm <osd_id(s)> --replace [--force]

示例

ceph orch osd rm 4 --replace

预期输出

Scheduled OSD(s) for replacement

这与“移除 OSD”部分中的过程相同，但有一个例外：OSD 不会从 CRUSH 层次结构中永久移除，而是被分配 destroyed 标志。

注意

将替换被移除 OSD 的新 OSD 必须在与被移除 OSD 相同的主机上创建。

保留 OSD ID

destroyed 标志用于确定在下一次 OSD 部署中将重用哪些 OSD ID。

如果您使用 OSDSpecs 部署 OSD，则新添加的驱动器将分配其替换对应项的 OSD ID。这假设新驱动器仍与 OSDSpecs 匹配。

使用 --dry-run 标志确保 ceph orch apply osd 命令将执行您想要的操作。 --dry-run 标志显示命令的结果，而不执行任何更改。当您确信命令将执行您想要的操作时，运行不带 --dry-run 标志的命令。

提示

您的 OSDSpec 的名称可以通过命令 ceph orch ls 检索

或者，您可以使用 OSDSpec 文件

ceph orch apply -i <osd_spec_file> --dry-run

预期输出

NAME                  HOST  DATA     DB WAL
<name_of_osd_spec>    node1 /dev/vdb -  -

当此输出反映您的意图时，省略 --dry-run 标志以执行部署。

擦除设备 (Zapping Devices)

擦除（zap）设备以便可以重用它。 zap 在远程主机上调用 ceph-volume zap。

ceph orch device zap <hostname> <path>

示例命令

ceph orch device zap my_hostname /dev/sdx

注意

如果未设置 unmanaged 标志，cephadm 会自动部署与 OSDSpec 匹配的驱动器。例如，如果在创建 OSD 时指定 all-available-devices 选项，当您 zap 设备时，cephadm 编排器会自动在该设备上创建新的 OSD。要禁用此行为，请参阅声明性状态。

自动调优 OSD 内存

OSD 守护程序将根据 osd_memory_target 配置选项调整其内存消耗。如果 Ceph 部署在不与其他服务共享内存的专用节点上，cephadm 将根据总 RAM 量和已部署 OSD 的数量自动调整每个 OSD 的内存消耗目标。这允许充分利用可用内存，并在添加或移除 OSD 或 RAM 时进行调整。

警告

Cephadm 默认将 osd_memory_target_autotune 设置为 true，这对于融合架构通常不合适，在融合架构中，给定节点既用于 Ceph 也用于计算目的。

Cephadm 将使用可用内存的一部分 mgr/cephadm/autotune_memory_target_ratio，减去非自动调优守护程序（非 OSD 和 osd_memory_target_autotune 为 false 的 OSD）消耗的内存，然后将余额除以 OSD 的数量。

最终目标反映在配置数据库中，选项如下所示

WHO   MASK      LEVEL   OPTION              VALUE
osd   host:foo  basic   osd_memory_target   126092301926
osd   host:bar  basic   osd_memory_target   6442450944

每个守护程序的限制和当前消耗的内存都可以在 ceph orch ps 输出的 MEM LIMIT 列中看到

NAME        HOST  PORTS  STATUS         REFRESHED  AGE  MEM USED  MEM LIMIT  VERSION                IMAGE ID      CONTAINER ID
osd.1       dael         running (3h)     10s ago   3h    72857k     117.4G  17.0.0-3781-gafaed750  7015fda3cd67  9e183363d39c
osd.2       dael         running (81m)    10s ago  81m    63989k     117.4G  17.0.0-3781-gafaed750  7015fda3cd67  1f0cc479b051
osd.3       dael         running (62m)    10s ago  62m    64071k     117.4G  17.0.0-3781-gafaed750  7015fda3cd67  ac5537492f27

要将 OSD 排除在内存自动调优之外，请对该 OSD 禁用 autotune 选项，并设置特定的内存目标。例如，

ceph config set osd.123 osd_memory_target_autotune false
ceph config set osd.123 osd_memory_target 16G

高级 OSD 服务规范

类型为 osd 的服务规范提供了一种利用驱动器属性来描述 Ceph 集群布局的方法。服务规范是一种抽象，用于告诉 Ceph 将哪些驱动器转换为 OSD 以及对这些 OSD 应用哪些配置。服务规范使得即使 Ceph 集群操作员不知道与这些磁盘相关的特定设备名称和路径，也可以定位要转换为 OSD 的驱动器。

服务规范使得可以定义 .yaml 或 .json 文件，可用于减少创建 OSD 所涉及的手动工作量。

注意

我们建议高级 OSD 规范包括 service_id 字段。使用 ceph orch daemon add 或 ceph orch apply osd --all-available-devices 创建的 OSD 放置在纯 osd 服务中。未在 OSD 规范中包含 service_id 会导致 Ceph 集群将您的规范中的 OSD 与这些 OSD 混合在一起，这可能会导致覆盖 cephadm 创建用于跟踪它们的服务规范。较新版本的 cephadm 会阻止不包含 service_id 的 OSD 规范。

例如，与其对每个设备和每个主机运行以下命令

ceph orch daemon add osd *<host>*:*<path-to-device>*

我们可以创建一个 .yaml 或 .json 文件来描述布局。这是最基本的示例

创建一个名为（例如）osd_spec.yml 的文件

service_type: osd
service_id: default_drive_group  # custom name of the osd spec
placement:
  host_pattern: '*'              # which hosts to target
spec:
  data_devices:                  # the type of devices you are applying specs to
    all: true                    # a filter, check below for a full list

这意味着

将任何可用设备（ceph-volume` 决定哪些是 _available_）转换为所有匹配 glob 模式 '*' 的主机上的 OSD。 glob 模式匹配来自 `ceph orch host ls` 的已注册主机。有关使用 ``host_pattern 匹配来使用设备作为 OSD 的更多信息，请参阅 :ref:`cephadm-services-placement-by-pattern-matching`。
使用以下命令将 osd_spec.yml 传递给 osd create
```
ceph orch apply -i /path/to/osd_spec.yml
```
此规范应用于所有匹配的主机以部署 OSD。

比 all 过滤器指定的策略更复杂的策略是可能的。有关详细信息，请参阅过滤器。

可以将 --dry-run 标志传递给 apply osd 命令，以显示拟议布局的概要。

示例

ceph orch apply -i /path/to/osd_spec.yml --dry-run

过滤器

注意

过滤器默认使用 AND 操作。这意味着驱动器必须匹配所有过滤条件才能被选中。可以通过在 OSD 规范中设置 filter_logic: OR 来调整此行为。

过滤器用于根据各种属性选择用于 OSD 数据或 WAL+DB 卸载的驱动器集。这些属性由 ceph-volume 的驱动器清单收集。使用此命令检索这些属性

ceph-volume inventory </path/to/drive>

供应商或型号

可以通过供应商品牌、制造商）或型号（SKU）定位特定驱动器

model: drive_model_name

或

vendor: drive_vendor_name

大小

可以使用 size 定位特定驱动器容量

size: size_spec

大小规范

大小规范可以采用以下形式

LOW:HIGH
:HIGH
LOW
EXACT

我们将在下面探讨示例。

仅匹配具有精确容量的驱动器

size: '10T'

请注意，驱动器容量通常不是单位的精确倍数，因此最好匹配一定范围内的驱动器，如下所示。这可以处理同一类别中将来可能具有不同型号且大小略有不同的驱动器。或者假设您今天有 10 TB 驱动器，明年可能会添加 16 TB 驱动器

size: '10T:40T'

仅匹配大小小于或等于 1701 GB 的驱动器

size: ':1701G'

包括大小大于或等于 666 GB 的驱动器

size: '666G:'

支持的大小单位是 Megabyte(M)、Gigabyte(G) 和 Terabyte(T)。单位的 B (_byte_) 后缀也是可接受的：MB、GB、TB。

旋转

这根据内核指示的每个驱动器的“旋转”属性进行门控。此属性通常与安装在每个节点中的裸 HDD 和 SSD 的预期一致。然而，异国情调或分层设备呈现可能与您期望或希望的不同

连接到节点的网络访问 SAN LUN
dCache、Bcache、OpenCAS 等呈现的复合设备。

在这种情况下，您可以通过添加 udev 规则来覆盖默认行为，以使内核报告与您的期望保持一致。下面的规则用于此目的，以覆盖没有本地物理驱动器且仅连接 SAN LUN 的 OSD 节点上的 rotational 属性。它并非旨在用于所有场景；您必须确定什么适合您的系统。如果您通过设置此类规则召唤了来自时空之外的怪异恐怖，那将由您承担责任。

ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="dm*", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="nbd*", ATTR{queue/rotational}="0"

规范文件语法

rotational: 0 | 1

1 匹配内核指示为旋转的所有驱动器

0 匹配所有非旋转驱动器（SATA、SATA、NVMe SSD、SAN LUN 等）

所有

这匹配所有可用的驱动器，即它们没有分区、GPT 标签等。

注意

这只能为 data_devices 指定。

all: true

限制器

如果指定了过滤器但您希望限制它们匹配的驱动器数量，请使用 limit 属性。这在将一些驱动器用于非 Ceph 目的时，或者当需要多种 OSD 策略时非常有用。

limit: 2

例如，当使用 vendor 匹配所有品牌为 VendorA 的驱动器，但您希望每个主机最多使用其中两个作为 OSD 时，请指定一个 limit

data_devices:
  vendor: VendorA
  limit: 2

注意

limit 通常只适用于某些特定场景。

附加选项

有多个可选设置可指定 OSD 的部署方式。将这些选项添加到 OSD 规范中以使其生效。

此示例在所有未使用的驱动器上部署加密 OSD。请注意，如果 Linux MD 镜像用于启动、/var/log 或其他卷，此规范可能会在您将其用于非 OSD 目的之前获取替换或添加的驱动器。可以设置 unmanaged 属性以暂停自动部署，直到您准备好为止。

service_type: osd
service_id: example_osd_spec
placement:
  host_pattern: '*'
spec:
  data_devices:
    all: true
  encrypted: true

Ceph Squid 及更高版本支持 LUKS2 设备的 TPM2 令牌注册。将 tpm2 属性添加到 OSD 规范中

service_type: osd
service_id: example_osd_spec_with_tpm2
placement:
  host_pattern: '*'
spec:
  data_devices:
    all: true
  encrypted: true
  tpm2: true

请参阅 DriveGroupSpecs 中的完整列表

class ceph.deployment.drive_group.DriveGroupSpec(placement=None, service_id=None, data_devices=None, db_devices=None, wal_devices=None, journal_devices=None, data_directories=None, osds_per_device=None, objectstore='bluestore', encrypted=False, tpm2=False, db_slots=None, wal_slots=None, osd_id_claims=None, block_db_size=None, block_wal_size=None, journal_size=None, service_type=None, unmanaged=False, filter_logic='AND', preview_only=False, extra_container_args=None, extra_entrypoint_args=None, data_allocate_fraction=None, method=None, config=None, custom_configs=None, crush_device_class=None, termination_grace_period_seconds=30)

描述驱动器组，格式与 ceph-volume 理解的相同。

block_db_size: int | str | None: 设置（或覆盖）“bluestore_block_db_size”值，以字节为单位

block_wal_size: int | str | None: 设置（或覆盖）“bluestore_block_wal_size”值，以字节为单位

crush_device_class: 分配给 OSD 的 Crush 设备类

data_allocate_fraction: 分配数据设备的一部分 (0,1.0]

data_devices: A ceph.deployment.drive_group.DeviceSelection

data_directories: 字符串列表，包含应支持 OSD 的路径

db_devices: A ceph.deployment.drive_group.DeviceSelection

db_slots: 每个 DB 设备的 OSD 数量

encrypted: true 或 false

filter_logic: 我们用于使用过滤器匹配磁盘的逻辑门。默认为“AND”

journal_devices: A ceph.deployment.drive_group.DeviceSelection

journal_size: int | str | None: 设置日志大小（以字节为单位）

networks: List[str]: 网络标识列表，指示守护进程只绑定在该列表中的特定网络上。如果集群分布在多个网络中，您可以添加多个网络。请参阅网络和端口、指定网络和指定网络。

objectstore: filestore 或 bluestore

osd_id_claims: 可选：主机到应替换的 osd_ids 列表的映射。请参阅OSD 替换

osds_per_device: 每个“DATA”设备的 osd 守护程序数量。为了充分利用 nvme 设备，需要多个 osd。通过将选项设置为 2，可用于在 2 个 OSD 之间拆分双执行器设备。

placement: PlacementSpec: 请参阅守护进程放置。

preview_only: 如果这应该被视为“预览”规范

tpm2: true 或 false

wal_devices: A ceph.deployment.drive_group.DeviceSelection

wal_slots: 每个 WAL 设备的 OSD 数量

示例

简单情况

当所有集群节点都具有相同的驱动器，并且我们希望将它们全部用作卸载 WAL+DB 的 OSD 时

10 HDDs
Vendor: VendorA
Model: HDD-123-foo
Size: 4TB

2 SAS/SATA SSDs
Vendor: VendorB
Model: MC-55-44-ZX
Size: 512GB

这是一种常见的安排，可以轻松描述

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    model: HDD-123-foo       # Note, HDD-123 would also be valid
  db_devices:
    model: MC-55-44-XZ       # Same here, MC-55-44 is valid

然而，我们可以通过根据驱动器的属性而不是特定型号进行过滤来改进 OSD 规范，因为随着驱动器的更换或添加，型号可能会随时间变化

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    rotational: 1            # The kernel flags as HDD
  db_devices:
    rotational: 0            # The kernel flags as SSD (SAS/SATA/NVMe)

这里指定所有 HDD 作为数据设备（OSD），所有 SSD 用于 WAL+DB 卸载。

如果您知道大于 2 TB 的驱动器应始终用作数据设备，而小于 2 TB 的驱动器应始终用作 WAL/DB 设备，则可以按大小过滤

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    size: '2TB:'           # Drives larger than 2 TB
  db_devices:
    size: ':2TB'           # Drives smaller than 2TB

注意

所有上述 OSD 规范同样有效。您使用哪一个取决于品味以及您期望节点布局发生变化的程度。

单个主机的多个 OSD 规范

这里我们指定了两种不同的策略，用于跨多种媒体类型部署 OSD，通常供单独的池使用

10 HDDs
Vendor: VendorA
Model: HDD-123-foo
Size: 4TB

12 SAS/SATA SSDs
Vendor: VendorB
Model: MC-55-44-ZX
Size: 512GB

2 NVME SSDs
Vendor: VendorC
Model: NVME-QQQQ-987
Size: 256GB

10 个 HDD OSD 使用 2 个 SATA/SAS SSD 进行 WAL+DB 卸载
10 个 SATA/SAS SSD OSD 共享 2 个 NVMe SSD 进行 WAL+DB 卸载

这可以在同一个文件中用两个服务规范来指定

service_type: osd
service_id: osd_spec_hdd
placement:
  host_pattern: '*'
spec:
  data_devices:             # Select all drives the kernel identifies as HDDs
    rotational: 1           #  for OSD data
  db_devices:
    model: MC-55-44-XZ      # Select only this model for WAL+DB offload
    limit: 2                # Select at most two for this purpose
  db_slots: 5               # Chop the DB device into this many slices and
                            #  use one for each of this many HDD OSDs
---
service_type: osd
service_id: osd_spec_ssd    # Unique so it doesn't overwrite the above
placement:
  host_pattern: '*'
spec:                       # This scenario is uncommon
  data_devices:
    model: MC-55-44-XZ      # Select drives of this model for OSD data
  db_devices:               # Select drives of this brand for WAL+DB. Since the
    vendor: VendorC         #   data devices are SAS/SATA SSDs this would make sense for NVMe SSDs
  db_slots: 2               # Back two slower SAS/SATA SSD data devices with each NVMe slice

这将通过使用所有 HDD 作为数据设备创建所需的布局，并分配两个 SATA/SAS SSD 作为专用 DB/WAL 设备，每个设备支持五个 HDD OSD。剩下的十个 SAS/SATA SSD 将用作 OSD 数据设备，分配 VendorC NVME SSD 作为专用 DB/WAL 设备，每个设备服务两个 SAS/SATA OSD。我们称这些为 _混合 OSD_。

具有相同磁盘布局的多个主机

当集群包含具有不同驱动器布局的主机，或具有复杂的多媒体类型组合时，建议应用多个 OSD 规范，每个规范仅匹配一组主机。通常，每种类型的主机都有一个规范。

service_id 必须是唯一的：如果应用了具有已应用 service_id 的新 OSD 规范，现有 OSD 规范将被取代。 Cephadm 将根据新规范定义在未使用的驱动器上创建新的 OSD 守护程序。现有 OSD 守护程序不会受到影响。请参阅声明性状态。

示例

节点 1-5

20 HDDs
Vendor: VendorA
Model: SSD-123-foo
Size: 4TB
2 SSDs
Vendor: VendorB
Model: MC-55-44-ZX
Size: 512GB

节点 6-10

5 NVMEs
Vendor: VendorA
Model: SSD-123-foo
Size: 4TB
20 SSDs
Vendor: VendorB
Model: MC-55-44-ZX
Size: 512GB

您可以指定一个 placement 来仅定位某些节点。

service_type: osd
service_id: disk_layout_a
placement:
  label: disk_layout_a
spec:
  data_devices:
    rotational: 1           # All drives identified as HDDs
  db_devices:
    rotational: 0           # All drives identified as SSDs
---
service_type: osd
service_id: disk_layout_b
placement:
  label: disk_layout_b
spec:
  data_devices:
    model: MC-55-44-XZ      # Only this model
  db_devices:
    model: SSD-123-foo      # Only this model

这通过 placement 过滤器将不同的 OSD 规范应用于与标记有 ceph orch 标签的主机匹配的不同主机。请参阅守护程序放置

注意

假设每个主机都有唯一的磁盘布局，则每个 OSD 规范必须具有唯一的 service_id。

专用 WAL + DB

前面所有情况都将 WAL 与 DB 放在一起。但是，如果需要，可以将 WAL 部署在单独的设备上。

20 HDDs
Vendor: VendorA
Model: SSD-123-foo
Size: 4TB

2 SAS/SATA SSDs
Vendor: VendorB
Model: MC-55-44-ZX
Size: 512GB

2 NVME SSDs
Vendor: VendorC
Model: NVME-QQQQ-987
Size: 256GB

这种情况下的 OSD 规范将如下所示，使用 model 过滤器

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
  wal_devices:
    model: NVME-QQQQ-987

也可以如下指定设备路径，前提是每个匹配的主机都应以相同方式呈现设备。

service_type: osd
service_id: osd_using_paths
placement:
  hosts:
    - node01
    - node02
spec:
  data_devices:
    paths:
    - /dev/sdb
  db_devices:
    paths:
    - /dev/sdc
  wal_devices:
    paths:
    - /dev/sdd

在大多数情况下，最好使用其他过滤器（包括 size 或 vendor）来完成此操作，以便 OSD 服务在 Linux 或 HBA 可能在不同引导时以不同方式枚举设备，或者在添加或更换驱动器时进行调整。

可以指定 crush_device_class 参数应用于在 paths 过滤器匹配的设备上创建的 OSD

service_type: osd
service_id: osd_using_paths
placement:
  hosts:
    - node01
    - node02
crush_device_class: ssd
spec:
  data_devices:
    paths:
    - /dev/sdb
    - /dev/sdc
  db_devices:
    paths:
    - /dev/sdd
  wal_devices:
    paths:
    - /dev/sde

crush_device_class 属性可以通过 paths 关键字以以下语法在 OSD 粒度上指定

service_type: osd
service_id: osd_using_paths
placement:
  hosts:
    - node01
    - node02
crush_device_class: ssd
spec:
  data_devices:
    paths:
    - path: /dev/sdb
      crush_device_class: ssd
    - path: /dev/sdc
      crush_device_class: nvme
  db_devices:
    paths:
    - /dev/sdd
  wal_devices:
    paths:
    - /dev/sde

激活现有 OSD

如果主机的操作系统已重新安装，则必须再次激活现有 OSD。 cephadm 为 activate 提供了一个包装器，可激活主机上的所有现有 OSD。

以下过程介绍了如何使用 cephadm 在重新安装了操作系统的主机上激活 OSD。

此示例适用于两个主机：ceph01 和 ceph04。

ceph01 是配备管理员密钥环的主机。
ceph04 是最近重新安装了操作系统的主机。

在主机上安装 cephadm 和 podman。安装这些实用程序的命令将取决于主机的操作系统。

检索公钥。

cd /tmp ; ceph cephadm get-pub-key > ceph.pub

将密钥（从 ceph01）复制到新重新安装的主机（ceph04）
```
ssh-copy-id -f -i ceph.pub root@<hostname>
```

检索私钥以测试连接

cd /tmp ; ceph config-key get mgr/cephadm/ssh_identity_key > ceph-private.key

从 ceph01，修改 ceph-private.key 的权限
```
chmod 400 ceph-private.key
```
从 ceph01 登录到 ceph04 以测试连接和配置
```
ssh -i /tmp/ceph-private.key ceph04
```
在登录到 ceph01 时，移除 ceph.pub 和 ceph-private.key
```
cd /tmp ; rm ceph.pub ceph-private.key
```
如果您运行自己的容器注册表，请指示编排器登录到每个主机上的注册表
```
ceph cephadm registry-login my-registry.domain <user> <password>
```
当编排器执行注册表登录时，它将尝试将任何丢失的守护程序部署到主机。这包括 crash、node-exporter 以及主机在重新安装操作系统之前运行的任何其他守护程序。

需要明确的是：当 cephadm 确定主机在线时，它会尝试将丢失的守护程序部署到由 cephadm 管理的所有主机。在这种情况下，“在线”意味着“存在于 ceph orch host ls 命令的输出中，并且状态不是 offline 或 maintenance。如果需要登录到注册表才能拉取丢失守护程序的镜像，则在完成登录注册表的过程之前，丢失守护程序的部署将失败。

注意

如果您不运行自己的容器注册表，则此步骤不是必需的。如果您的主机仍在“主机列表”中，可以通过运行命令 ceph orch host ls 检索，则无需运行此命令。
在最近重新安装了操作系统的主机上激活 OSD
```
ceph cephadm osd activate ceph04
```
此命令使 cephadm 扫描所有现有磁盘以查找 OSD。此命令将使 cephadm 将任何丢失的守护程序部署到指定的主机。

此过程由 Eugen Block 在 2025 年 2 月开发，有关其开发的博客文章可在此处查看： Eugen Block 的“Cephadm: Activate existing OSDs”博客文章。

注意

在运行中的集群上运行 ceph orch restart osd.myosdservice 通常是不安全的，因为没有考虑到 CRUSH 故障域，并行 OSD 重启可能导致暂时的数据不可用，在极少数情况下甚至导致数据丢失。

延伸阅读

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑立即加入。