部署 Ceph 集群后,有些时候可能还需要对它执行若干修改。这些修改包括添加或删除新的节点、磁盘或服务。本章介绍该如何完成这些管理任务。
为集群添加新节点的过程与第 4 章 “使用 DeepSea/Salt 部署”中所述的初始集群节点部署过程几乎完全相同。
在新节点上安装 SUSE Linux Enterprise Server 12 SP3、配置其网络设置使它能够正确解析 Salt Master 主机名,并安装 salt-minion
包:
root@minion >
zypper in salt-minion
如果 Salt Master 的主机名不是 salt
,请编辑 /etc/salt/minion
并添加下面一行:
master: DNS_name_of_your_salt_master
如果您对上面提到的配置文件进行了任何更改,请重启动 salt.minion
服务:
root@minion >
systemctl restart salt-minion.service
在 Salt Master 上接受所有 Salt 密钥:
root@master #
salt-key --accept-all
校验 /srv/pillar/ceph/deepsea_minions.sls
是否也以新的 Salt Minion 为目标。有关更多详细信息,请参见过程 4.1 “运行部署阶段”的第 4.2.2.1 节 “匹配 Minion 名称”。
运行准备阶段。该阶段会同步模块和 Grains 数据,以便新的 Minion 可以提供 DeepSea 需要的所有信息:
root@master #
salt-run state.orch ceph.stage.0
运行发现阶段。该阶段将在 /srv/pillar/ceph/proposals
目录中写入新的文件项,您可在其中编辑相关的 .yml 文件:
root@master #
salt-run state.orch ceph.stage.1
(可选)如果新添加的主机与现有命名模式不匹配,请更改 /srv/pillar/ceph/proposals/policy.cfg
。有关详细信息,请参见第 4.5.1 节 “policy.cfg
文件”。
运行配置阶段。该阶段会读取 /srv/pillar/ceph
下的所有内容,并相应地更新 Pillar:
root@master #
salt-run state.orch ceph.stage.2
Pillar 用于存储可以使用以下命令访问的数据:
root@master #
salt target pillar.items
配置和部署阶段包含新添加的节点:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
您可通过 DeepSea 部署所有受支持的角色类型。有关受支持角色类型的更多信息以及匹配示例,请参见第 4.5.1.2 节 “角色指定”。
一般而言,在将新角色添加到集群节点时,建议您运行全部部署阶段 0 到 5。为了节省一些时间,可根据要部署的角色类型,跳过阶段 3 或 4。OSD 和 MON 角色包含核心服务,是 Ceph 的必要组成部分,而其他角色(例如对象网关)则是可选项。DeepSea 部署阶段是分层的:阶段 3 部署核心服务,而阶段 4 则部署可选服务。
因此,部署核心角色(例如在现有 OSD 节点上部署 MON)时需要运行阶段 3,可以跳过阶段 4。
同样,部署可选服务(例如对象网关)时可以跳过阶段 3,但需要运行阶段 4。
要将新服务添加到现有节点,请执行下列步骤:
修改 /srv/pillar/ceph/proposals/policy.cfg
,以使现有主机与新角色匹配。有关详细信息,请参见第 4.5.1 节 “policy.cfg
文件”。例如,如果您需要在 MON 节点上运行对象网关,命令行类似下方所示:
role-rgw/xx/x/example.mon-1.sls
运行阶段 2 以更新 Pillar:
root@master #
salt-run state.orch ceph.stage.2
运行阶段 3 以部署核心服务,或者运行阶段 4 以部署可选服务。同时运行这两个阶段也没有问题。
将 OSD 添加到现有集群时请注意,集群将在此后的一段时间内进行重新平衡。为了尽可能缩短重新平衡的时间,建议您同时添加所有要添加的 OSD。
要从集群中删除角色,请编辑 /srv/pillar/ceph/proposals/policy.cfg
并删除相应的行。然后按第 4.3 节 “集群部署”中所述运行阶段 2 和 5。
如果您需要从集群中删除特定 OSD 节点,请确保集群的可用磁盘空间多于要删除的磁盘空间。切记,删除 OSD 会导致整个集群进行重新平衡。
从 Minion 中删除角色时,其目的是撤销与该角色相关的所有更改。对于大部分角色,要实现该任务都很简单,但可能会存在包依赖项问题。如果包被卸装,其依赖项并不会被卸装。
删除的 OSD 会显示为空白驱动器。相关任务除了会擦除分区表外,还会覆盖文件系统的开头并删除备份分区。
先前通过其他方法(例如 ceph-deploy
)配置的磁盘驱动器可能仍然包含分区。DeepSea 不会自动销毁这些分区。管理员必须回收这些驱动器。
举例来说,如果您的存储 Minion 名为“data1.ceph”、“data2.ceph”...“data6.ceph”,则 policy.cfg
中的相关行类似下方所示:
[...] # Hardware Profile profile-default/cluster/data*.sls profile-default/stack/default/ceph/minions/data*.yml [...]
要删除 Salt Minion“data2.ceph”,请将这些行更改为:
[...] # Hardware Profile profile-default/cluster/data[1,3-6]*.sls profile-default/stack/default/ceph/minions/data[1,3-6]*.yml [...]
然后运行阶段 2 和 5:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.5
假设出现下面的情况:在全新安装集群期间,您(管理员)在等待网关硬件就绪时,将其中一个存储节点分配为独立的对象网关。现在,当网关的永久硬件就绪时,您就可以将所需角色最终指定给备用存储节点并删除网关角色。
在针对新硬件运行阶段 0 和 1(请参见过程 4.1 “运行部署阶段”)之后,您将新网关命名为 rgw1
。如果节点 data8
需要删除对象网关角色并添加存储角色,且当前的 policy.cfg
类似下方所示:
# Hardware Profile profile-default/cluster/data[1-7]*.sls profile-default/stack/default/ceph/minions/data[1-7]*.sls # Roles role-rgw/cluster/data8*.sls
则将它更改为:
# Hardware Profile profile-default/cluster/data[1-8]*.sls profile-default/stack/default/ceph/minions/data[1-8]*.sls # Roles role-rgw/cluster/rgw1*.sls
运行阶段 2 到 5。阶段 3 会将 data8
添加为存储节点。稍候片刻,data8
将同时具有两个角色。阶段 4 会将对象网关角色添加到 rgw1
,而阶段 5 会从 data8
中删除对象网关角色。
一个或多个监视器节点发生故障且不响应时,您需要将发生故障的监视器从集群中删除,然后再添加回集群(如有需要)。
监视器节点的数量不能少于 3。如果某个监视器节点发生故障,导致您的集群中只有一个或两个监视器节点,您需要临时将监视器角色指定给其他集群节点,然后再重新部署发生故障的监视器节点。重新部署发生故障的监视器节点后,便可以卸装临时监视器角色。
有关向 Ceph 集群添加新节点/角色的详细信息,请参见第 1.1 节 “添加新的集群节点”和第 1.2 节 “为节点添加新的角色”。
有关删除集群节点的详细信息,请参见第 1.3 节 “删除和重新安装集群节点”。
Ceph 节点故障分为以下两种基本程度:
Salt Minion 主机发生硬件或 OS 级别损坏,无法响应 salt 'minion_name' test.ping
调用。在此情况下,您需要按照第 4.3 节 “集群部署”中的相关说明,对服务器进行彻底的重新部署。
监视器相关服务失败并拒绝恢复,但主机会响应 salt 'minion_name' test.ping
调用。在此情况下,请执行以下步骤:
编辑 Salt Master 上的 /srv/pillar/ceph/proposals/policy.cfg
,删除或更新发生故障的监视器节点对应的行,使它们现在指向正常工作的监视器节点。
运行 DeepSea 阶段 2 到 5 以应用这些更改:
root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3root@master #
deepsea
stage run ceph.stage.4root@master #
deepsea
stage run ceph.stage.5
要向现有 OSD 节点添加磁盘,请校验是否已删除并擦除磁盘上的所有分区。有关详细信息,请参见第 4.3 节 “集群部署”中的步骤 13。磁盘变为空磁盘后,将磁盘添加到节点的 YAML 文件。该文件的路径是 /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/node_name.yml
。保存文件后,运行 DeepSea 阶段 2 和 3:
root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3
您无需手动编辑 YAML 文件,DeepSea 可创建新的配置。要让 DeepSea 创建新的配置,需要移走现有的配置:
root@master #
old
/srv/pillar/ceph/proposals/profile-default/root@master #
deepsea
stage run ceph.stage.1root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3
您可以通过运行以下命令从集群中删除 Ceph OSD:
root@master #
salt-run
disengage.safetyroot@master #
salt-run
remove.osd OSD_ID
OSD_ID 需为 OSD 的编号,不含 osd
一词。例如,对于 osd.3
,仅使用数字 3
。
使用 salt-run remove.osd
命令无法同时删除多个 OSD。要自动删除多个 OSD,您可以使用以下循环(5、21、33、19 是要删除的 OSD 的 ID 号):
for i in 5 21 33 19 do echo $i salt-run disengage.safety salt-run remove.osd $i done
有时会出现无法正常删除 OSD 的情况(请参见第 1.6 节 “删除 OSD”)。例如,如果 OSD 或其快速缓存中止、I/O 操作挂起或 OSD 磁盘无法卸载。在上述情况下,您需要强制删除 OSD:
root@master #
target osd.remove OSD_ID force=True
此命令不仅会删除数据分区,还会删除日记或 WAL/DB 分区。
要识别可能处于孤立状态的日记/WAL/DB 设备,请执行以下步骤:
选择可能存在孤立分区的设备,并将其分区列表保存到文件中:
root@minion >
ls /dev/sdd?* > /tmp/partitions
针对所有 block.wal、block.db 和日记设备运行 readlink
,并将输出与之前保存的分区列表进行比较:
root@minion >
readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
| sort | comm -23 /tmp/partitions -
输出内容为 Ceph 未使用的分区列表。
使用您首选的命令(例如 fdisk
、parted
或 sgdisk
)删除不属于 Ceph 的孤立分区。
如果您的某个 OSD 节点上的操作系统损坏且无法恢复,请执行以下步骤恢复该节点,并在集群数据保持不变的情况下重新部署该节点的 OSD 角色:
在节点上重新安装操作系统。
在 OSD 节点上安装 salt-minion 包,删除 Salt Master 上的旧 Salt Minion 密钥,并向 Salt Master 注册新 Salt Minion 的密钥。有关 Salt Minion 部署的详细信息,请参见第 4.3 节 “集群部署”。
不要运行整个阶段 0,而是运行以下部分:
root@master #
salt 'osd_node' state.apply ceph.syncroot@master #
salt 'osd_node' state.apply ceph.packages.commonroot@master #
salt 'osd_node' state.apply ceph.minesroot@master #
salt 'osd_node' state.apply ceph.updates
运行 DeepSea 阶段 1 到 5:
root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@master #
salt-run state.orch ceph.stage.5
运行 DeepSea 阶段 0:
root@master #
salt-run state.orch ceph.stage.0
重引导相关的 OSD 节点。系统将重新发现并重新使用所有 OSD 磁盘。
通过使用 Salt 反应器可让安装自动进行。对于虚拟环境或一致的硬件环境,此配置将允许创建具有指定行为的 Ceph 集群。
Salt 无法根据反应器事件执行依赖项检查。存在可能使 Salt Master 过载而无法响应的风险。
自动安装需要:
正确创建的 /srv/pillar/ceph/proposals/policy.cfg
。
准备好并已放入 /srv/pillar/ceph/stack
目录中的自定义配置。
默认反应器配置只会运行阶段 0 和 1。如此不必等待后续阶段完成即可测试反应器。
第一个 salt-minion 启动时,阶段 0 即会开始。使用锁定可阻止多个实例。所有 Minion 都完成阶段 0 后,阶段 1 将会开始。
如果该操作正确执行,请将 /etc/salt/master.d/reactor.conf
中的最后一行:
- /srv/salt/ceph/reactor/discovery.sls
更改为
- /srv/salt/ceph/reactor/all_stages.sls
最好定期对您的集群节点应用滚动更新。要应用更新,请运行阶段 0:
root@master #
salt-run state.orch ceph.stage.0
如果 DeepSea 检测到正在运行的 Ceph 集群,它会按顺序应用更新并重启动节点。DeepSea 会遵照 Ceph 的官方建议,先更新监视器,然后更新 OSD,最后更新其他服务,例如 MDS、对象网关、iSCSI 网关或 NFS Ganesha。如果 DeepSea 检测到集群中存在问题,会停止更新过程。触发问题的因素可能是:
Ceph 报告“HEALTH_ERR”的持续时长超过 300 秒。
查询 Salt Minion,以了解所指定的服务在更新后是否仍然启动且正在运行。如果服务处于关闭状态超过 900 秒,更新即会失败。
如此安排可确保即使更新损坏或失败,Ceph 集群仍可以运作。
DeepSea 阶段 0 通过 zypper update
更新系统,并重引导系统(如果更新了内核)。如果您想避免发生将所有可能的节点强制重引导的情况,请在启动 DeepSea 阶段 0 之前,确保最新的内核已安装且正在运行。
zypper patch
如果您更想使用 zypper patch
命令来更新系统,请编辑 /srv/pillar/ceph/stack/global.yml
,添加下面一行:
update_method_init: zypper-patch
您可以通过将下面几行添加到 /srv/pillar/ceph/stack/global.yml
,更改 DeepSea 阶段 0 的默认重引导行为:
stage_prep_master: default-update-no-reboot stage_prep_minion: default-update-no-reboot
stage_prep_master
用于设置 Salt Master 的阶段 0 行为,stage_prep_minion
用于设置所有 Minion 的行为。所有可用的参数如下:
安装更新并在更新之后重引导。
安装更新而不重引导。
重引导而不安装更新。
不安装更新,也不重引导。
在某些情况下,可能需要停止或重引导整个集群。建议您仔细检查运行中服务的依赖项。下列步骤概要说明如何停止和启动集群:
告知 Ceph 集群不要将 OSD 标记为 out:
root #
ceph
osd set noout
按下面的顺序停止守护进程和节点:
存储客户端
网关,例如 NFS Ganesha 或对象网关
元数据服务器
Ceph OSD
Ceph Manager
Ceph Monitor
根据需要执行维护任务。
以与关闭过程相反的顺序启动节点和服务器:
Ceph Monitor
Ceph Manager
Ceph OSD
元数据服务器
网关,例如 NFS Ganesha 或对象网关
存储客户端
删除 noout 标志:
root #
ceph
osd unset noout
ceph.conf
文件 #
如果您需要将自定义设置放入 ceph.conf
文件中,可通过修改 /srv/salt/ceph/configuration/files/ceph.conf.d
目录中的配置文件来实现:
global.conf
mon.conf
mgr.conf
mds.conf
osd.conf
client.conf
rgw.conf
rgw.conf
与 ceph.conf
的其他段落相比,对象网关具有很强的灵活性,并且是唯一的。所有其他 Ceph 组件都包含静态标题,例如 [mon]
或 [osd]
。对象网关的标题是唯一的,例如 [client.rgw.rgw1]
。也就是说,rgw.conf
文件需要有标题项。请参见 /srv/salt/ceph/configuration/files/rgw.conf
查看示例。
对上述配置文件进行自定义更改之后,运行阶段 3 以将这些更改应用到集群节点:
root@master #
salt-run state.orch ceph.stage.3
这些文件通过 /srv/salt/ceph/configuration/files/ceph.conf.j2
模板文件加入,与 Ceph 配置文件接受的不同段落相对应。将配置片段放入正确的文件,可让 DeepSea 将其放入正确的段落。您不需要添加任何段落标题。
要将任何配置选项仅应用于守护进程的特定实例,请添加标题,例如 [osd.1]
。以下配置选项将只应用于 ID 为 1 的 OSD 守护进程。
段落中位于后面的语句会覆盖前面的语句。因此,可以按照 /srv/salt/ceph/configuration/files/ceph.conf.j2
模板中指定的内容来覆盖默认配置。例如,要关闭 cephx 身份验证,可将下面三行添加到 /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf
文件:
auth cluster required = none auth service required = none auth client required = none
如果您需要应用许多自定义配置,请在自定义配置文件中使用以下 include 语句来让文件管理更轻松。下面是 osd.conf
文件的示例:
[osd.1] {% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %} [osd.2] {% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %} [osd.3] {% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %} [osd.4] {% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}
在前面的示例中,osd1.conf
、osd2.conf
、osd3.conf
和 osd4.conf
文件包含特定于相关 OSD 的配置选项。
第 1.11 节 “自定义 ceph.conf
文件”介绍如何更改 Ceph 配置文件 ceph.conf
。但是,实际的集群行为并不是由 ceph.conf
文件的当前状态决定,而是由正在运行的 Ceph 守护进程的配置(存储在内存中)决定。
要查询单个 Ceph 守护进程以了解特定的配置设置,您可以在运行守护进程的节点上使用 admin socket。例如,以下命令可从名为 osd.0
的守护进程获取 osd_max_write_size
配置参数的值:
root #
ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \
config get osd_max_write_size
{
"osd_max_write_size": "90"
}
您还可以在运行时更改守护进程的设置。请注意,此更改是暂时的,守护进程下次重启动时,更改将会丢失。例如,以下命令可针对集群中的所有 OSD 将 osd_max_write_size
参数更改为“50”:
root #
ceph tell osd.* injectargs --osd_max_write_size 50
injectargs
并非百分百可靠
有时,使用 injectargs
命令可能无法成功更改集群设置。如果您需要确保启用更改的参数,请在配置文件中进行更改并重启动集群中的所有守护进程。