13 操作任务 #
13.1 修改集群配置 #
要修改现有 Ceph 集群的配置,请执行以下步骤:
将集群的当前配置导出到文件:
cephuser@adm >
ceph orch ls --export --format yaml > cluster.yaml编辑包含配置的文件并更新相关行。可在第 5.4 节 “部署服务和网关”和第 13.4.3 节 “使用 DriveGroups 规范添加 OSD。”中找到规范示例。
应用新配置:
cephuser@adm >
ceph orch apply -i cluster.yaml
13.2 添加节点 #
要向 Ceph 集群添加新节点,请执行以下步骤:
在新主机上安装 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage。有关更多信息,请参考第 5.1 节 “安装和配置 SUSE Linux Enterprise Server”。
将主机配置为已存在 Salt Master 的 Salt Minion。有关更多信息,请参考第 5.2 节 “部署 Salt”。
将新主机添加到
ceph-salt
并让 cephadm 能识别它,例如:root@master #
ceph-salt config /ceph_cluster/minions add ses-min5.example.comroot@master #
ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com有关更多信息,请参考第 5.3.2.2 节 “添加 Salt Minion”。
确认节点是否已添加到
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 的更多详细信息,请参见第 13.4.4 节 “删除 OSD”。
要从集群中删除节点,请执行以下操作:
对于除
node-exporter
和crash
之外的所有 Ceph 服务类型,请从集群归置规范文件(例如cluster.yml
)中删除节点的主机名。有关更多详细信息,请参见第 5.4.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.1root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2从您要删除的 Minion 中删除所有角色:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/admin remove ses-min2如果您要删除的 Minion 是引导 Minion,则还需要删除引导角色:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/bootstrap reset删除单个主机上的所有 OSD 后,从 CRUSH 索引中删除该主机:
cephuser@adm >
ceph osd crush remove bucket-name注意存储桶名称应该与主机名相同。
现在您便可以从集群中删除 Minion:
cephuser@adm >
ceph-salt config /ceph_cluster/minions remove ses-min2
如果发生故障,并且您尝试删除的 Minion 处于永久断电状态,则需要从 Salt Master 中删除节点:
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 -idrive_groups.yml
要查看操作预览并测试您的应用,可以将 --dry-run
选项与 ceph orch apply osd
命令一起使用。例如:
cephuser@adm >
ceph orch apply osd -idrive_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 的磁盘。
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 设置的示例。
下面的示例说明了使用相同设置的两个节点:
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'
下面的示例说明了两种不同的设置: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
上述示例假设所有节点的驱动器都相同,但情况并非总是如此:
节点 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
上述所有案例都假设 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
在以下设置中,我们尝试定义:
由 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 #
要在保留其 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
选项不会执行实际替换,而会预览通常会发生的步骤。
13.5 将 Salt Master 移至新节点 #
如果需要用新 Salt Master 主机替换 Salt Master 主机,请执行以下步骤:
导出集群配置并备份导出的 JSON 文件。有关详细信息,请参见第 5.3.2.15 节 “导出集群配置”。
如果旧的 Salt Master 也是集群中的唯一管理节点,则需要将
/etc/ceph/ceph.client.admin.keyring
和/etc/ceph/ceph.conf
手动移至新的 Salt Master。停止并禁用旧的 Salt Master 节点上的 Salt Master
systemd
服务:root@master #
systemctl stop salt-master.serviceroot@master #
systemctl disable salt-master.service如果旧的 Salt Master 节点不再位于集群中,还要停止并禁用 Salt Minion
systemd
服务:root@master #
systemctl stop salt-minion.serviceroot@master #
systemctl disable salt-minion.service警告如果旧的 Salt Master 节点上有任何正在运行的 Ceph 守护进程(MON、MGR、OSD、MDS、网关、监控),请不要停止或禁用
salt-minion.service
。按照第 5.1 节 “安装和配置 SUSE Linux Enterprise Server”中所述的过程在新的 Salt Master 上安装 SUSE Linux Enterprise Server 15 SP2。
提示:转换 Salt Minion为便于将 Salt Minion 转换为新的 Salt Master,请从每个 Salt Minion 中删除原来的 Salt Master 的公共密钥:
root@minion >
rm /etc/salt/pki/minion/minion_master.pubroot@minion >
systemctl restart salt-minion.service在新的 Salt Master 上安装 salt-master 包和 salt-minion 包(如适用)。
在新的 Salt Master 节点上安装
ceph-salt
:root@master #
zypper install ceph-saltroot@master #
systemctl restart salt-master.serviceroot@master #
salt '*' saltutil.sync_all重要确保在继续之前运行所有三个命令。这些命令是幂等的;是否重复并不重要。
在集群中包含新的 Salt Master,如第 5.3.1 节 “安装
ceph-salt
”、第 5.3.2.2 节 “添加 Salt Minion”和第 5.3.2.4 节 “指定管理节点”中所述。导入备份的集群配置并应用该配置:
root@master #
ceph-salt import CLUSTER_CONFIG.jsonroot@master #
ceph-salt apply重要导入之前,请在导出的
CLUSTER_CONFIG.json
文件中重命名 Salt Master 的minion id
。
13.6 更新集群节点 #
定期应用滚动更新,以使 Ceph 集群节点保持最新。
13.6.1 软件储存库 #
使用最新的软件包增补集群之前,请确认集群的所有节点均可访问相关的储存库。有关所需储存库的完整列表,请参见第 7.1.5.1 节 “软件储存库”。
13.6.2 储存库暂存 #
如果您使用向集群节点提供软件储存库的暂存工具(例如 SUSE Manager、储存库管理工具或 RMT),请确认 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage 的“Updates”储存库的阶段都是在同一时刻创建的。
强烈建议您使用暂存工具来应用增补程序级别为 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/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/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按下面的顺序停止守护进程和节点:
存储客户端
网关,例如 NFS Ganesha 或对象网关
元数据服务器
Ceph OSD
Ceph Manager
Ceph Monitor
根据需要执行维护任务。
以与关闭过程相反的顺序启动节点和服务器:
Ceph Monitor
Ceph Manager
Ceph OSD
元数据服务器
网关,例如 NFS Ganesha 或对象网关
存储客户端
删除 noout 标志:
cephuser@adm >
ceph
osd unset noout
13.9 删除整个 Ceph 集群 #
ceph-salt purge
命令可删除整个 Ceph 集群。如果部署了更多的 Ceph 集群,则将清除 ceph -s
报告的集群。这样,您便可以在测试不同的设置时清理集群环境。
为防止意外删除,编制流程会检查是否解除了安全措施。您可以通过运行以下命令来解除安全措施并删除 Ceph 集群:
root@master #
ceph-salt disengage-safetyroot@master #
ceph-salt purge