SES 7.1 | 管理和操作指南

13.1 修改集群配置 #

要修改现有 Ceph 集群的配置，请执行以下步骤：

将集群的当前配置导出到文件：

cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml

编辑包含配置的文件并更新相关行。可在第 8 章 “使用 cephadm 部署其余核心服务”和第 13.4.3 节 “使用 DriveGroups 规范添加 OSD。”中找到规范示例。

应用新配置：

cephuser@adm > ceph orch apply -i cluster.yaml

13.2 添加节点 #

要向 Ceph 集群添加新节点，请执行以下步骤：

在新主机上安装 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage。有关更多信息，请参考第 5 章 “安装和配置 SUSE Linux Enterprise Server”。
将主机配置为已存在 Salt 主控端的 Salt 受控端。有关更多信息，请参考第 6 章 “部署 Salt”。

将新主机添加到 ceph-salt 并让 cephadm 能识别它，例如：

root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.com
root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

有关更多信息，请参考第 7.2.2 节 “添加 Salt 受控端”。

确认节点是否已添加到 ceph-salt：

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
[...]
  o- ses-min5.example.com .................................... [no roles]

将配置应用于新集群主机：

root@master # ceph-salt apply ses-min5.example.com

确认新添加的主机现在是否属于 cephadm 环境：

cephuser@adm > ceph orch host ls
HOST                   ADDR                    LABELS   STATUS
[...]
ses-min5.example.com   ses-min5.example.com

13.3 删除节点 #

提示：删除 OSD

如果您要删除的节点运行有 OSD，请先从中删除 OSD，然后检查该节点上是否未运行任何 OSD。有关删除 OSD 的更多详细信息，请参见第 13.4.4 节 “删除 OSD”。

要从集群中删除节点，请执行以下操作：

对于除 node-exporter 和 crash 之外的所有 Ceph 服务类型，请从集群归置规范文件（例如 cluster.yml）中删除节点的主机名。有关更多详细信息，请参见第 8.2 节 “服务和归置规范”。例如，如果您要删除名为 ses-min2 的主机，请从所有 placement: 部分中删除所有出现的 - ses-min2：
更新
```
service_type: rgw
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min2
  - ses-min3
```
更改为
```
service_type: rgw
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min3
```
将您的更改应用于配置文件：
```
cephuser@adm > ceph orch apply -i rgw-example.yaml
```

从 cephadm 的环境中删除节点：

cephuser@adm > ceph orch host rm ses-min2

如果节点正在运行 crash.osd.1 和 crash.osd.2 服务，请通过在主机上运行以下命令将其删除：

root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

例如：

root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2

从您要删除的受控端中删除所有角色：

cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

如果您要删除的受控端是引导受控端，则还需要删除引导角色：

cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset

删除单个主机上的所有 OSD 后，从 CRUSH 索引中删除该主机：
```
cephuser@adm > ceph osd crush remove bucket-name
```
注意
存储桶名称应该与主机名相同。

现在您便可以从集群中删除受控端：

cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2

重要

如果发生故障，并且您尝试删除的受控端处于永久断电状态，则需要从 Salt 主控端中删除节点：

root@master # salt-key -d minion_id

然后，手动将节点从 pillar_root/ceph-salt.sls 中删除。它通常位于 /srv/pillar/ceph-salt.sls 中。

13.4 OSD 管理 #

本节介绍如何在 Ceph 集群中添加、擦除或删除 OSD。

13.4.1 列出磁盘设备 #

要识别所有集群节点上已使用和未使用的磁盘设备，请通过运行以下命令列出这些设备：

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 擦除磁盘设备 #

要重新使用磁盘设备，需要先将其擦除（或清除）：

ceph orch device zap HOST_NAME DISK_DEVICE

例如：

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

注意

如果您之前在未设置 unmanaged 标志的情况下使用 DriveGroups 或 --all-available-devices 选项部署 OSD，cephadm 将在您擦除这些 OSD 后再自动部署它们。

13.4.3 使用 DriveGroups 规范添加 OSD。 #

DriveGroups 用于指定 Ceph 集群中 OSD 的布局。它们在单个 YAML 文件中定义。在本节中，我们将使用 drive_groups.yml 作为示例。

管理员应手动指定一组相关的 OSD（部署在 HDD 和 SDD 组合上的混合 OSD）或一组使用相同部署选项的 OSD（例如，对象存储、加密选项相同的各独立 OSD）。为了避免明确列出设备，DriveGroups 会使用与 ceph-volume 库存报告中的几个所选字段对应的过滤项列表。cephadm 将提供一些代码，用于将这些 DriveGroups 转换为供用户检查的实际设备列表。

将 OSD 规范应用于集群的命令是：

cephuser@adm > ceph orch apply osd -i drive_groups.yml

要查看操作预览并测试您的应用，可以将 --dry-run 选项与 ceph orch apply osd 命令一起使用。例如：

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

如果 --dry-run 输出符合您的预期，则只需重新运行命令而无需使用 --dry-run 选项。

13.4.3.1 非受管 OSD #

将符合 DriveGroups 规范的所有可用正常磁盘设备添加到集群后，它们将自动用作 OSD。此行为称为受管模式。

要禁用受管模式，请将 unmanaged: true 行添加到相关规范，例如：

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

提示

要将已部署的 OSD 从受管模式更改为非受管模式，请于第 13.1 节 “修改集群配置”中所述的过程期间在适当位置添加 unmanaged: true 行。

13.4.3.2 DriveGroups 规范 #

下面是 DriveGroups 规范文件的示例：

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

注意

之前在 DeepSea 中名为“加密”的选项已被重命名为“已加密”。在 SUSE Enterprise Storage 7 中应用 DriveGroups 时，请确保在服务规范中使用此新术语，否则 ceph orch apply 操作将失败。

13.4.3.3 匹配磁盘设备 #

您可以使用以下过滤器描述规格：

按磁盘型号：
```
model: DISK_MODEL_STRING
```

按磁盘供应商：

vendor: DISK_VENDOR_STRING

提示

始终以小写形式输入 DISK_VENDOR_STRING。

要获取有关磁盘型号和供应商的详细信息，请检查以下命令的输出：

cephuser@adm > ceph orch device ls
HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
[...]

磁盘是否为旋转硬盘。SSD 和 NVMe 驱动器不属于旋转硬盘。
```
rotational: 0
```
部署将所有可用驱动器都用于 OSD 的节点：
```
data_devices:
  all: true
```
还可通过限制匹配磁盘的数量来过滤：
```
limit: 10
```

13.4.3.4 按大小过滤设备 #

您可以按磁盘设备大小对其过滤，可以按确切大小也可以按大小范围来过滤。size: 参数接受使用下列格式的参数：

'10G' - 包括大小为该值的磁盘。
'10G:40G' - 包括大小在该范围内的磁盘。
':10G' - 包括大小小于或等于 10 GB 的磁盘。
'40G:' - 包括大小等于或大于 40 GB 的磁盘。

例 13.1︰按磁盘大小匹配 #

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

注意：需要引号

如果使用“:”分隔符，您需要用引号括住大小，否则“:”符号将被解释为新的配置哈希。

提示：单位缩写

您可以指定以兆字节 (M) 或太字节 (T) 为单位的大小，而不能指定以千兆字节 (G) 为单位的大小。

13.4.3.5 DriveGroups 示例 #

本节包含其他 OSD 设置的示例。

例 13.2︰简单设置 #

下面的示例说明了使用相同设置的两个节点：

20 个 HDD
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
2 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB

对应的 drive_groups.yml 文件如下所示：

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

这样的配置简单有效。但问题是管理员将来可能要添加来自不同供应商的磁盘，而这样的磁盘不在可添加范围内。您可以通过减少针对驱动器核心属性的过滤器来予以改进。

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

在上面的示例中，我们强制将所有旋转设备声明为“data devices”，所有非旋转设备将被用作“shared devices”（wal、db）。

如果您知道大小超过 2 TB 的驱动器将始终充当较慢的数据设备，则可以按大小过滤：

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

例 13.3︰高级设置 #

下面的示例说明了两种不同的设置：20 个 HDD 将共享 2 个 SSD，而 10 个 SSD 将共享 2 个 NVMe。

20 个 HDD
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
12 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB
2 个 NVMe
- 供应商：Samsung
- 型号：NVME-QQQQ-987
- 大小：256 GB

这样的设置可使用如下两个布局定义：

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

例 13.4︰包含非一致节点的高级设置 #

上述示例假设所有节点的驱动器都相同，但情况并非总是如此：

节点 1-5：

20 个 HDD
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
2 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB

节点 6-10：

5 个 NVMe
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
20 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB

您可以在布局中使用“target”键来定位特定节点。Salt 定位标记可让事情变得简单：

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

后接

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

例 13.5︰专家设置 #

上述所有案例都假设 WAL 和 DB 使用相同设备，但也有可能会在专用设备上部署 WAL：

20 个 HDD
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
2 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB
2 个 NVMe
- 供应商：Samsung
- 型号：NVME-QQQQ-987
- 大小：256 GB

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

例 13.6︰复杂（和不太可能的）设置 #

在以下设置中，我们尝试定义：

由 1 个 NVMe 支持 20 个 HDD
由 1 个 SSD (db) 和 1 个 NVMe (wal) 支持 2 个 HDD
由 1 个 NVMe 支持 8 个 SSD
2 个独立 SSD（加密）
1 个 HDD 作为备用，不应部署

共使用如下数量的驱动器：

23 个 HDD
- 供应商：Intel
- 型号：SSD-123-foo
- 大小：4 TB
10 个 SSD
- 供应商：Micron
- 型号：MC-55-44-ZX
- 大小：512 GB
1 个 NVMe
- 供应商：Samsung
- 型号：NVME-QQQQ-987
- 大小：256 GB

DriveGroups 定义如下所示：

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

在文件的整个分析过程中，将始终保留一个 HDD。

13.4.4 删除 OSD #

在从集群中删除 OSD 节点之前，请确认该集群中的可用磁盘空间是否比您要删除的 OSD 磁盘大。请注意，删除 OSD 会导致整个集群进行重新平衡。

通过获取其 ID 来识别要删除的 OSD：

cephuser@adm > ceph orch ps --daemon_type osd
NAME   HOST            STATUS        REFRESHED  AGE  VERSION
osd.0  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
osd.1  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
osd.2  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
osd.3  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...

从集群中删除一个或多个 OSD：

cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...

例如：

cephuser@adm > ceph orch osd rm 1 2

您可以查询删除操作的状态：

cephuser@adm > 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

13.4.4.1 停止 OSD 删除 #

安排 OSD 删除后，您可以视需要停止删除。以下命令将重置 OSD 的初始状态并将其从队列中删除：

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 替换 OSD #

有多种原因会导致您可能需要替换 OSD 磁盘。例如：

根据 SMART 信息，OSD 磁盘已发生故障或很快将发生故障，并且将不再能用来安全地存储数据。
您需要升级 OSD 磁盘，例如增加其大小。
您需要更改 OSD 磁盘布局。
您打算从非 LVM 布局转为基于 LVM 的布局。

要在保留其 ID 的情况下替换 OSD，请运行：

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

例如：

cephuser@adm > ceph orch osd rm 4 --replace

替换 OSD 与删除 OSD 基本相同（有关更多详细信息，请参见第 13.4.4 节 “删除 OSD”），只不过 OSD 不是从 CRUSH 层次结构中永久删除，而是被指定了一个 destroyed 标志。

destroyed 标志用于确定将在下一次 OSD 部署期间重复使用的 OSD ID。新添加的符合 DriveGroups 规范的磁盘（有关更多详细信息，请参见第 13.4.3 节 “使用 DriveGroups 规范添加 OSD。”）将被指定其所替换磁盘的 OSD ID。

提示

追加 --dry-run 选项不会执行实际替换，而会预览通常会发生的步骤。

注意

如果发生故障后替换 OSD，我们强烈建议对归置组触发一次深层洗刷。有关详细信息，请参见第 17.6 节 “洗刷归置组”。

运行以下命令可启动深层洗刷：

cephuser@adm > ceph osd deep-scrub osd.OSD_NUMBER

重要：共享设备故障

如果 DB/WAL 的共享设备发生故障，您需要对共享该故障磁盘的所有 OSD 执行替换过程。

13.5 将 Salt 主控端移至新节点 #

如果需要用新 Salt 主控端主机替换 Salt 主控端主机，请执行以下步骤：

导出集群配置并备份导出的 JSON 文件。有关详细信息，请参见第 7.2.14 节 “导出集群配置”。
如果旧的 Salt 主控端也是集群中的唯一管理节点，则需要将 /etc/ceph/ceph.client.admin.keyring 和 /etc/ceph/ceph.conf 手动移至新的 Salt 主控端。

停止并禁用旧的 Salt 主控端节点上的 Salt 主控端 systemd 服务：

root@master # systemctl stop salt-master.service
root@master # systemctl disable salt-master.service

如果旧的 Salt 主控端节点不再位于集群中，还要停止并禁用 Salt 受控端 systemd 服务：
```
root@master # systemctl stop salt-minion.service
root@master # systemctl disable salt-minion.service
```
警告
如果旧的 Salt 主控端节点上有任何正在运行的 Ceph 守护进程（MON、MGR、OSD、MDS、网关、监控），请不要停止或禁用 salt-minion.service。
按照第 5 章 “安装和配置 SUSE Linux Enterprise Server”中所述的过程在新的 Salt 主控端上安装 SUSE Linux Enterprise Server 15 SP3。
提示：转换 Salt 受控端
为便于将 Salt 受控端转换为新的 Salt 主控端，请从每个 Salt 受控端中删除原来的 Salt 主控端的公共密钥：
```
root@minion > rm /etc/salt/pki/minion/minion_master.pub
root@minion > systemctl restart salt-minion.service
```
在新的 Salt 主控端上安装 salt-master 软件包和 salt-minion 软件包（如果适用）。
在新的 Salt 主控端节点上安装 ceph-salt：
```
root@master # zypper install ceph-salt
root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
```
重要
确保在继续之前运行所有三个命令。这些命令是幂等的；是否重复并不重要。
在集群中包含新的 Salt 主控端，如第 7.1 节 “安装 ceph-salt”、第 7.2.2 节 “添加 Salt 受控端”和第 7.2.4 节 “指定管理节点”中所述。
导入备份的集群配置并应用该配置：
```
root@master # ceph-salt import CLUSTER_CONFIG.json
root@master # ceph-salt apply
```
重要
导入之前，请在导出的 CLUSTER_CONFIG.json 文件中重命名 Salt 主控端的 minion id。

13.6 更新集群节点 #

定期应用滚动更新，以使 Ceph 集群节点保持最新。

13.6.1 软件源 #

使用最新的软件包增补集群之前，请确认集群的所有节点均可访问相关的软件源。有关所需软件源的完整列表，请参见第 10.1.5.1 节 “软件源”。

13.6.2 软件源暂存 #

如果您使用向集群节点提供软件源的暂存工具（例如 SUSE Manager、订阅管理工具或 RMT），请确认 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage 的“更新”软件源的阶段都是在同一时刻创建的。

强烈建议您使用暂存工具来应用补丁级别为 frozen 或 staged 的补丁。这样可确保加入集群的新节点具有与已在集群中运行的节点相同的补丁级别。通过这种方法，您无需向集群的所有节点都应用最新补丁，新节点也能加入集群。

13.6.3 Ceph 服务停机时间 #

集群节点可能会在更新期间重引导，具体视配置而定。如果对象网关、Samba 网关、NFS Ganesha 或 iSCSI 等服务存在单一故障点，客户端计算机可能会暂时与相应节点正在重引导的服务断开连接。

13.6.4 运行更新 #

要将所有集群节点上的软件包更新到最新版本，请运行以下命令：

root@master # ceph-salt update

13.7 更新 Ceph #

您可以指示 cephadm 将 Ceph 从一个 Bug 修复版本更新到另一个版本。Ceph 服务的自动更新遵循建议的顺序进行，即从 Ceph Manager、Ceph Monitor 开始更新，然后继续更新 Ceph OSD、元数据服务器和对象网关等其他服务。只有当 Ceph 指示集群将仍然可用之后，才会重启动每个守护进程。

注意

以下更新过程使用 ceph orch upgrade 命令。请注意，以下说明详细介绍了如何使用某个产品版本（例如维护更新）更新您的 Ceph 集群，但未提供如何将集群从一个产品版本升级到另一个产品版本的说明。

13.7.1 启动更新 #

开始更新之前，请确认所有节点当前都处于联机状态，并且集群是健康的：

cephuser@adm > cephadm shell -- ceph -s

更新到某个特定的 Ceph 版本：

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

例如：

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7.1/ceph/ceph:latest

升级主机上的软件包：

cephuser@adm > ceph-salt update

13.7.2 监控更新 #

运行以下命令可确定是否正在进行更新：

cephuser@adm > ceph orch upgrade status

如果正在进行更新，您将在 Ceph 状态输出中看到一个进度条：

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7.1/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

您还可以查看 cephadm 日志：

cephuser@adm > ceph -W cephadm

13.7.3 取消更新 #

您可以随时停止更新过程：

cephuser@adm > ceph orch upgrade stop

13.8 停止或重引导集群 #

在某些情况下，可能需要停止或重引导整个集群。建议您仔细检查运行中服务的依赖项。下列步骤概要说明如何停止和启动集群：

告知 Ceph 集群不要将 OSD 标记为 out：
```
cephuser@adm > ceph osd set noout
```
按下面的顺序停止守护进程和节点：
1. 存储客户端
2. 网关，例如 NFS Ganesha 或对象网关
3. 元数据服务器
4. Ceph OSD
5. Ceph Manager
6. Ceph Monitor
根据需要执行维护任务。
以与关闭过程相反的顺序启动节点和服务器：
1. Ceph Monitor
2. Ceph Manager
3. Ceph OSD
4. 元数据服务器
5. 网关，例如 NFS Ganesha 或对象网关
6. 存储客户端
删除 noout 标志：
```
cephuser@adm > ceph osd unset noout
```

13.9 删除整个 Ceph 集群 #

ceph-salt purge 命令可删除整个 Ceph 集群。如果部署了更多的 Ceph 集群，则将清除 ceph -s 报告的集群。这样，您便可以在测试不同的设置时清理集群环境。

为防止意外删除，编制流程会检查是否解除了安全措施。您可以通过运行以下命令来解除安全措施并删除 Ceph 集群：

root@master # ceph-salt disengage-safety
root@master # ceph-salt purge

13 操作任务 #

13.1 修改集群配置 #

13.2 添加节点 #

13.3 删除节点 #

13.4 OSD 管理 #

13.4.1 列出磁盘设备 #

13.4.2 擦除磁盘设备 #

13.4.3 使用 DriveGroups 规范添加 OSD。 #

13.4.3.1 非受管 OSD #

13.4.3.2 DriveGroups 规范 #

13.4.3.3 匹配磁盘设备 #

13.4.3.4 按大小过滤设备 #

13.4.3.5 DriveGroups 示例 #

13.4.4 删除 OSD #

13.4.4.1 停止 OSD 删除 #

13.4.5 替换 OSD #

13.5 将 Salt 主控端移至新节点 #

13.6 更新集群节点 #

13.6.1 软件源 #

13.6.2 软件源暂存 #

13.6.3 Ceph 服务停机时间 #

13.6.4 运行更新 #

13.7 更新 Ceph #

13.7.1 启动更新 #

13.7.2 监控更新 #

13.7.3 取消更新 #

13.8 停止或重引导集群 #

13.9 删除整个 Ceph 集群 #