注意

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

OSD 服务

列出设备

ceph-volume定期扫描集群中的每个主机，以确定哪些设备存在且响应。同时确定每个设备是否适合用于块、DB或WAL角色。

要打印由cephadm发现的设备列表，请运行此命令：

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

Example:

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, and Fault的字段。libstoragemgmt集成提供。默认情况下，此集成是禁用的，因为libstoragemgmt可能与您的硬件不兼容。要指示Ceph包含这些字段，请按照以下方式启用cephadm的“增强设备扫描”选项：

ceph config set mgr mgr/cephadm/device_enhanced_scan true

请注意，ceph orch device ls报告的列可能在不同版本之间有所不同。

The --wide选项显示设备详细信息，包括设备可能不适合用作OSD的原因。

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的兼容性，以避免服务中断。

测试兼容性的方法有很多，但最简单的方法是使用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交互的更多信息，请参阅设备管理.

Note

当前版本的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] 邮件列表上。

部署 OSDs

列出存储设备

为了部署OSD，必须在集群所有主机上有一个或多个可用的存储设备，OSD将部署在这些设备上。

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

ceph orch device ls

如果满足以下所有条件，则存储设备被视为不可用的设备上配置OSD。：

设备不能有任何分区。
设备不能有任何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

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

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

您可以使用

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

例如：

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

You can use 高级 OSD 服务规范中进行了描述根据设备的属性对设备进行分类。这有助于澄清哪些设备可用于消费。属性包括设备类型（SSD或HDD）、设备型号名称、大小以及设备所在的宿主机：
```
ceph orch apply -i spec.yml
```

警告

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

使用ceph orch daemon add osd创建的新OSD将作为osd.default的受管理OSD添加，并具有有效的spec。

要将现有的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

The --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  -   -

Declarative State

的效果是持久的。这意味着在ceph orch apply is persistent. This means that drives that are added to the system after the 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

Note

请记住以下三点：

的默认行为会导致ceph orch apply不断协调。这意味着cephadm to constantly reconcile. This means that cephadm在检测到新驱动器时立即创建OSD。
设置unmanaged: True将禁用OSD的创建。如果unmanaged: True设置，即使应用新的OSD服务，也不会发生任何事情。
ceph orch daemon add创建OSD，但不会添加OSD服务。

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

移除一个 OSD

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

从OSD中撤离所有放置组（PGs）
从集群中删除无PG的OSD

以下命令执行这两个步骤：

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

Example:

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

预期输出：

Scheduled OSD(s) for removal

不安全的OSD将被拒绝。添加--zap标志会指示协调器从OSD的驱动器中删除所有LVM和分区信息，使其成为空白，以便重新部署或重复使用。

Note

删除OSD后，如果OSD的驱动器变得可用，cephadm可能会自动尝试在这些驱动器上部署更多OSD，如果它们与现有的驱动器组spec匹配。如果您使用spec删除OSD，并且不希望在删除后在这些驱动器上部署任何新的OSD，最好在删除前修改驱动器组spec。设置unmanaged: true以防止它拾取新的驱动器，或者以某种方式修改它，使其不再与您希望删除的OSD使用的驱动器匹配。然后重新应用spec。有关驱动器组spec的更多信息，请参阅高级 OSD 服务规范中进行了描述。有关cephadm在参考部署OSD时声明性质的更多信息，请参阅Declarative State

监控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时，它将被停用并从集群中删除。

Note

删除OSD后，如果您擦除用于已删除OSD的设备中的LVM物理卷，将创建新的OSD。unmanaged在Declarative State.

停止OSD删除中的参数。

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

ceph orch osd rm stop <osd_id(s)>

Example:

ceph orch osd rm stop 4

预期输出：

Stopped OSD(s) removal

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

替换OSD

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

Example:

ceph orch osd rm 4 --replace

预期输出：

Scheduled OSD(s) for replacement

这与“删除OSD”部分中的过程相同，只有一个例外：OSD不会永久从CRUSH层次结构中删除，而是会被分配destroyed标志指示 cephadm 移除主机以及 CRUSH 桶。

Note

新的OSD必须在与已删除的OSD相同的主机上创建。

保留OSD ID

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

如果您使用OSDSpecs进行OSD部署，您新添加的驱动器将分配给它们替换的对应OSD ID。这假设新的驱动器仍然与OSDSpecs匹配。

使用--dry-run标志以确保ceph orch apply osd命令将按您的意图执行。标志--dry-run显示命令执行结果而不执行任何更改。当您满意命令将按您想要的方式执行时，请不带--dry-run标志指示 cephadm 移除主机以及 CRUSH 桶。

提示

运行命令。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设备）

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

ceph orch device zap <hostname> <path>

示例命令：

ceph orch device zap my_hostname /dev/sdx

Note

如果未设置unmanaged标志，cephadm会自动部署与OSDSpec匹配的驱动器。例如，如果您在创建OSD时指定了all-available-devices选项，当您zap设备时，cephadm协调器会自动在设备上创建新的OSD。要禁用此行为，请参阅Declarative State.

自动调整 OSD 内存

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

警告

Cephadm默认设置osd_memory_target_autotunetotrue，这通常不适用于聚合架构，其中特定节点既用于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。服务规范s 使它成为可能，即使Ceph集群管理员不知道与这些磁盘相关联的特定设备名称和路径，也可以将驱动器定位为转换为OSD。

服务规范s 使它成为可能，定义一个.yaml或.json文件，可以减少创建OSD时涉及的手动工作量。

Note

我们建议高级OSD spec包括service_id字段。ceph orch daemon add或ceph orch apply osd --all-available-devices创建的OSD将放置在普通的osd服务中。如果您在OSD spec中未包含service_id，则Ceph集群会将您的spec中的OSD与那些OSD混合，这可能会导致cephadm创建的service spec被覆盖。较新版本的cephadm会阻止不包含service_id.

的块OSD spec。

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` decides which are _available_) into an OSD on all hosts that match the glob pattern '*'. The glob pattern matches registered hosts from `ceph orch host ls`. See :ref:`cephadm-services-placement-by-pattern-matching` for more on using ``host_pattern匹配) 来使用设备作为OSD。
通过使用以下命令传递osd_spec.ymltoosd create：
```
ceph orch apply -i /path/to/osd_spec.yml
```
此规范应用于所有匹配的主机以部署OSD。

比指定all过滤器更复杂的策略是可能的。有关过滤器 for details.

A --dry-run flag can be passed to the apply osd command to display a synopsis of the proposed layout.

示例

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

过滤器

Note

默认情况下，过滤器使用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'

To match only drives that are less than or equal to 1701 GB in size:

size: ':1701G'

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

size: '666G:'

支持的容量单位是兆字节(M)、吉字节(G)和太字节(T)。B(_byte_) 后缀也是可接受的：MB, GB, TB.

旋转

这基于每个驱动器的“旋转”属性进行门控，如内核所示。此属性通常对于每个节点上安装的裸HDD和SSD符合预期。然而，异构或分层设备表示可能报告与预期或期望不同的行为：

网络访问的SAN LUN连接到节点
由dCache, Bcache, OpenCAS, etc.

在这种情况下，您可以通过添加一个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"

Spec文件语法：

rotational: 0 | 1

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

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

所有

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

Note

这可能仅指定为data_devices.

all: true

限制器

如果指定了过滤器，但您希望限制它们匹配的驱动器数量，请使用limit属性。这在某些特定场景中通常适用。

limit: 2

For example, when using vendor to match all drives branded VendorA but you wish to use at most two of them per host as OSDs, specify a limit:

data_devices:
  vendor: VendorA
  limit: 2

Note

limit is usually appropriate in only certain specific scenarios.

其他选项

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

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

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

Ceph Squid及更高版本支持LUKS2设备的TPM2令牌注册。在OSD spec中添加tpm2属性：

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

请参阅

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

以与

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

block_wal_size: int | 字符串 | 无: 设置（或覆盖）“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 | 字符串 | 无: 以字节设置journal_size

网络: 列表[字符串]: 一个网络标识符列表，指示守护进程仅在列表中的特定网络上绑定。如果集群分布在多个网络上，您可以添加多个网络。请参阅网络和端口, 指定网络和指定网络.

objectstore: filestore或bluestore

osd_id_claims: 可选：主机 -> 应该被替换的osd_ids列表映射OSD替换

osds_per_device: 每个DATA设备上的OSD守护进程数量。

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

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

tpm2: true或false

wal_devices: A ceph.deployment.drive_group.DeviceSelection

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

示例

简单情况

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

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

Note

上述所有OSD spec都是有效的。您使用哪个取决于您的喜好以及您预期节点布局会发生变化多少。

单个主机上的多个OSD spec

在这里，我们指定了两种不同的策略来跨多种媒体类型部署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卸载

这可以使用同一文件中的两个服务spec指定：

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数据设备，并将VendorCNVMEs SSD分配为专用的DB/WAL设备，每个设备服务于两个SATA/SATA OSD。我们称这些为_hybrid OSDs。

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

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

The service_id必须是唯一的：如果应用了已经应用的service_id的新OSD spec，则现有的OSD spec将被取代。Declarative State.

Example:

节点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

这会将不同的OSD spec应用于通过ceph orch标签标记的主机。placement过滤器与守护进程放置

Note

假设每个主机都有一个唯一的磁盘布局，每个OSD spec都必须有一个唯一的service_id.

专用WAL + DB

所有前面的情况都将WAL与DB放在同一位置。

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 spec如下，使用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过滤器匹配的设备：

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

The 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是操作系统最近重新安装的主机。

在将要成为 RGW 节点的节点上安装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
```
的权限：ceph04fromceph01登录到
```
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。如果需要登录到注册表以拉取缺失守护程序的镜像，则直到完成登录到注册表的过程，缺失守护程序的部署才会失败。

Note

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

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

Note

通常不建议在正在运行的集群上运行ceph orch restart osd.myosdservice，因为不会关注 CRUSH 故障域，并且并行 OSD 重启可能导致临时数据不可用，或在极少数情况下导致数据丢失。

OSD 服务

列出设备

获取块设备的精确大小

示例

部署 OSDs

列出存储设备

创建新的OSD

Dry Run

Declarative State

移除一个 OSD

监控OSD删除期间的OSD状态

停止OSD删除中的参数。

替换OSD

擦除设备（Zapping设备）

自动调整 OSD 内存

高级 OSD 服务规范中进行了描述

过滤器

厂商或型号

容量

容量规范

旋转

所有

限制器

其他选项

示例

简单情况

单个主机上的多个OSD spec

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

专用WAL + DB

激活现有的OSD

更多阅读