Ceph 服務管理之OSD服務

列出設備

ceph-volume不時掃描集群中的每個主機，以確定哪些設備存在以及它們是否有資格用作 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

使用該--wide選項可提供與設備相關的所有詳細信息，包括設備可能不適合用作 OSD 的任何原因。

在上面的示例中，您可以看到名為“Health”、“Ident”和“Fault”的字段。此信息通過與libstoragemgmt集成提供。默認情況下，此集成被禁用（因為libstoragemgmt可能不是 100% 與您的硬件兼容）。要cephadm包含這些字段，請啟用 cephadm 的“增強設備掃描”選項，如下所示；

ceph config set mgr mgr/cephadm/device_enhanced_scan true

**警告：盡管 libstoragemgmt 庫執行標准 SCSI 查詢調用，但不能保證您的固件完全實現這些標准。這可能會導致行為不穩定，甚至在某些較舊的硬件上發生總線重置。因此，建議您在啟用此功能之前，先測試您的硬件與 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) 的官方支持

部署 OSD

列出存儲設備

為了部署 OSD，必須有一個可用於部署 OSD 的存儲設備。

運行以下命令以顯示所有集群主機上的存儲設備清單：

ceph orch device ls

如果滿足以下所有條件，則認為存儲設備可用：

• 設備不能有分區。

• 設備不得具有任何 LVM 狀態。

• 不得掛載該設備。

• 設備不得包含文件系統。

• 設備不得包含 Ceph BlueStore OSD。

• 設備必須大於 5 GB。

Ceph 不會在不可用的設備上配置 OSD。

創建新的 OSD

有幾種方法可以創建新的 OSD：

• 告訴 Ceph 使用任何可用和未使用的存儲設備：

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 服務規范根據設備的屬性對設備進行分類。這可能有助於更清楚地了解哪些設備可供使用。屬性包括設備類型（SSD 或 HDD）、設備型號名稱、大小以及設備所在的主機：

ceph orch apply -i spec.yml

試運行

該--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參數：

如果您想避免這種行為（禁用在可用設備上自動創建 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 涉及兩個步驟：

1. 從集群中撤出所有歸置組 (PG)
2. 從集群中移除無 PG OSD

以下命令執行這兩個步驟：

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

例子：

ceph orch osd rm 0

預期輸出：

Scheduled OSD(s) for removal

無法安全銷毀的 OSD 將被拒絕。

監控 OSD 狀態

您可以使用以下命令查詢 OSD 操作的狀態：

ceph orch osd rm status

預期輸出：

OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
2       cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
3       cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
4       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

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

例子：

ceph orch osd rm 4 --replace

預期輸出：

Scheduled OSD(s) for replacement

這與“刪除 OSD”部分中的過程相同，但有一個例外：OSD 不會從 CRUSH 層次結構中永久刪除，而是分配一個“已銷毀”標志。

筆記: 將替換已移除 OSD 的新 OSD 必須與已移除的 OSD 在同一主機上創建。

保留 OSD ID

'destroyed' 標志用於確定在下一次 OSD 部署中將重用哪些 OSD id。

如果您使用 OSD Specs 進行 OSD 部署，您新添加的磁盤將被分配其替換對應的 OSD id。這假定新磁盤仍然與 OSD Specs 匹配。

使用該--dry-run標志來確保該 ceph orch apply osd 命令執行您想要的操作。該--dry-run標志向您顯示命令的結果將是什么，而不進行您指定的更改。當您對命令將執行您想要的操作感到滿意時，請運行不帶--dry-run標志的命令。

提示: 您的 OSD Spec 的名稱可以使用命令ceph orch ls檢索

或者，您可以使用您的 OSD Spec 文件：

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

預期輸出：

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

當此輸出反映您的意圖時，請省略該--dry-run標志以執行部署。

擦除設備（ZAPPING 設備）

擦除（zap）設備，以便可以重復使用。zap調用遠程主機ceph-volume zap。

ceph orch device zap <hostname> <path>

示例命令：

ceph orch device zap my_hostname /dev/sdx

筆記: 如果未設置 unmanaged 標志，cephadm 會自動部署與 OSD Spec 匹配的驅動器。例如，如果您在創建 OSD 時使用該all-available-devices選項，則當您zap使用設備時，cephadm orchestrator 會自動在設備中創建新的 OSD。要禁用此行為，請參閱聲明狀態。

自動調整 OSD 內存

OSD 守護進程將根據 osd_memory_target配置選項調整它們的內存消耗（默認為幾千兆字節）。如果 Ceph 部署在不與其他服務共享內存的專用節點上，cephadm 可以根據 RAM 總量和部署的 OSD 數量自動調整每個 OSD 的內存消耗。

警告: Cephadm 默認設置osd_memory_target_autotune為true不適合超融合基礎架構。

Cephadm 將從系統總 RAM 的 一小部分osd_memory_target_autotune（mgr/cephadm/autotune_memory_target_ratio默認為.7）

最終目標反映在配置數據庫中，選項如下：

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 的自動調整選項並設置特定的內存目標。例如，

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

高級 OSD 服務規范

Service Specification類型osd是一種描述集群布局的方法，使用磁盤的屬性。服務規范為用戶提供了一種抽象的方式來告訴 Ceph 哪些磁盤應該以哪些配置變成 OSD，而無需知道設備名稱和路徑的細節。

服務規范使得定義 yaml 或 json 文件成為可能，這些文件可用於減少創建 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

這意味着 ：

1.將任何可用設備（ceph-volume 決定 'available' 是什么）轉換為匹配 glob 模式 '*' 的所有主機上的 OSD。（glob 模式與來自主機 ls的注冊主機匹配）下面提供了有關 host_pattern 的更詳細的部分。

2.然后像這樣將它傳遞創建osd：

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 來調整此行為。

過濾器用於將磁盤分配給組，使用它們的屬性對它們進行分組。

這些屬性基於 ceph-volume 的磁盤查詢。您可以使用以下命令檢索有關屬性的信息：

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

供應商或型號

供應商或型號可以針對特定磁盤：

model: disk_model_name

要么:

vendor: disk_vendor_name

尺寸

特定磁盤可以通過Size定位：

size: size_spec

尺寸規格

尺寸規格可以有以下幾種形式：

• LOW:HIGH

• :HIGH

• LOW:

• EXACT

具體例子：

包含精確大小的磁盤

size: '10G'

要包含給定大小范圍內的磁盤：

size: '10G:40G'

要包含大小小於或等於 10G 的磁盤：

size: ':10G'

要包含大小等於或大於 40G 的磁盤：

size: '40G:'

大小不必專門以千兆字節 (G) 為單位指定。

支持其他大小單位：兆字節(M)、千兆字節(G) 和太字節(T)。還支持為字節附加 (B)：MB, GB, TB.

ROTATIONAL（旋轉）

這對磁盤的“ROTATIONAL”屬性起作用。

rotational: 0 | 1

• 1匹配所有旋轉的磁盤
• 0匹配所有非旋轉磁盤（SSD、NVME 等）

ALL（全部）

這將占用所有“可用”的磁盤

筆記: 這是 data_devices 部分獨有的。

all: true

限制器

如果您指定了一些有效的過濾器，但想限制它們匹配的磁盤數量，請使用該limit指令：

limit: 2

例如，如果您使用vendor來匹配來自VendorA 但只想使用前兩個的所有磁盤，則可以使用limit：

data_devices:
  vendor: VendorA
  limit: 2

筆記: 限制是最后的手段，如果可以避免，則不應使用。

附加選項

您可以使用多種可選設置來更改 OSD 的部署方式。您可以將這些選項添加到 OSD 規范的基本級別以使其生效。

這個例子將部署所有啟用加密的 OSD。

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

在 DriveGroupSpecs 中查看完整列表

類 ceph.deployment.drive_group.DriveGroupSpec(*args: Any, **kwargs: Any)
以 ceph-volume 理解的相同形式描述驅動器組。

block_db_size: 可選[Union[int, str]]
設置（或覆蓋）“bluestore_block_db_size”值，以字節為單位

block_wal_size: 可選[Union[int, str]]
設置（或覆蓋）“bluestore_block_wal_size”值，以字節為單位

data_devices
一種ceph.deployment.drive_group.DeviceSelection

data_directories
字符串列表，包含應該支持 OSD 的路徑

db_devices
一種ceph.deployment.drive_group.DeviceSelection

db_slots
每個 DB 設備有多少個 OSD

encrypted
true或false

filter_logic
我們用來將磁盤與過濾器匹配的邏輯。默認為“and”

journal_devices
一種ceph.deployment.drive_group.DeviceSelection

journal_size: 可選[Union[int, str]]
以字節為單位設置 journal_size

objectstore
filestore或bluestore

osd_id_claims
可選：主機映射 -> 應替換的 osd_id 列表參見OSD 替換

osds_per_device
每個“DATA”設備的 osd 守護進程數。要充分利用 nvme 設備，需要多個 osd。

preview_only
如果這應該被視為“預覽”規范

wal_devices
一種ceph.deployment.drive_group.DeviceSelection

wal_slots
每個 WAL 設備有多少個 OSD

示例

簡單案例

具有相同設置的所有節點

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

2 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

但是，我們可以通過減少驅動器核心屬性的過濾器來改進它：

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

現在，我們強制將所有旋轉設備聲明為“數據設備”，所有非旋轉設備將用作 shared_devices (wal, db)

如果您知道超過 2TB 的驅動器將始終是較慢的數據設備，您還可以按大小過濾：

service_type: osd
service_id: osd_spec_default
placement:
  host_pattern: '*'
spec:
  data_devices:
    size: '2TB:'
  db_devices:
    size: ':2TB'

筆記: 上述所有 OSD 規范同樣有效。您要使用哪一個取決於您的品味以及您希望節點布局改變多少。

單個主機的多個 OSD 規范

這里我們有兩個不同的設置

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

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

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

• 20 個 HDD 應該共享 2 個 SSD
• 10 個 SSD 應該共享 2 個 NVMes

這可以用兩種布局來描述。

service_type: osd
service_id: osd_spec_hdd
placement:
  host_pattern: '*'
spec:
  data_devices:
    rotational: 1
  db_devices:
    model: MC-55-44-XZ
    limit: 2 # db_slots is actually to be favoured here, but it's not implemented yet
---
service_type: osd
service_id: osd_spec_ssd
placement:
  host_pattern: '*'
spec:
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    vendor: VendorC

這將通過將所有 HDD 用作 data_devices 並將兩個 SSD 分配為專用 db/wal 設備來創建所需的布局。剩余的 SSD(8) 將是 data_devices，它們將“VendorC”NVME 分配為專用的 db/wal 設備。

具有相同磁盤布局的多台主機

假設集群有不同類型的主機，每個主機具有相似的磁盤布局，建議應用僅匹配一組主機的不同 OSD 規范。通常，您將擁有多個具有相同布局的主機的規范。

服務 id 作為唯一鍵：如果應用了具有已應用服務 id 的新 OSD 規范，則現有 OSD 規范將被取代。cephadm 現在將根據新的規范定義創建新的 OSD 守護進程。現有的 OSD 守護進程不會受到影響。請參閱聲明性狀態。

節點 1-5

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

節點 6-10

5 NVMEs
Vendor: Intel
Model: SSD-123-foo
Size: 4TB
20 SSDs
Vendor: VendorA
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
  db_devices:
    rotational: 0
---
service_type: osd
service_id: disk_layout_b
placement:
  label: disk_layout_b
spec:
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo

這將根據放置鍵將不同的 OSD 規范應用於不同的主機。請參閱守護程序放置

筆記: 假設每台主機都有唯一的磁盤布局，每個 OSD 規范需要有不同的服務 id

專用 WAL + DB

所有以前的案例都將 WAL 與 DB 放在一起。但是，如果可行的話，也可以在專用設備上部署 WAL。

20 HDDs
Vendor: VendorA
Model: MC-55-44-ZX
Size: 4TB

2 SSDs
Vendor: VendorB
Model: SSD-123-foo
Size: 512GB

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

這種情況下的 OSD 規范如下所示（使用模型過濾器）：

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

這可以通過其他過濾器輕松完成，例如尺寸或供應商。

激活現有 OSD

如果主機的操作系統被重新安裝，現有的 OSD 需要重新激活。對於這個用例，cephadm 為 activate 提供了一個包裝器，用於激活主機上所有現有的 OSD。

ceph cephadm osd activate <host>...

這將掃描所有現有磁盤的 OSD 並部署相應的守護進程。