Cephadm:在重新安装的服务器上重用 OSD
这是我关于 cephadm 的第二篇博文,cephadm 是部署和管理 Ceph 集群的(相对)新工具。我不时感到受到ceph用户邮件列表或客户问题的挑战,然后我试图找到特定问题的解决方案。例如,我关于cephadm的第一篇文章涉及更改显示器IP地址的选项。这篇文章将简要介绍如何从重新安装的服务器重新激活OSD。
这个(虚拟)实验室环境基于 SUSE Enterprise Storage 7 和 podman(Ceph Octopus 版本 15.2.8)。我不会详细介绍,也不会为您省去大部分命令行输出,本文旨在展示总体思路,而不是提供分步说明。这也只是一种方法,我还没有尝试其他方法(还没有),可能会有更顺畅的程序。如果您有更好的想法或其他意见,请发表评论,我很乐意尝试不同的方法并更新这篇博文。
背景
标题已经揭示了这个问题的背景。如果 OSD 服务器的操作系统 (OS) 之一中断,并且您需要重新安装它,则有两种选项可以处理该服务器上的 OSD。要么让集群重新平衡(这通常是要走的路,这就是 Ceph 的设计目的)并重新安装操作系统。然后擦除 OSD 并将节点添加回集群,这将再次触发归置群组 (PG) 的重新映射。
在 cephadm 和容器化服务(但不比 Luminous 早)之前,从重新安装的主机中带回 OSD 非常简单,“ceph-volume”几乎可以为您做所有事情,但在 Ceph 编排器中有一个解决方案之前,我目前只看到这种“黑客”的方式。
可能的问题
为了防止 Ceph 重新映射,您需要设置 noout 标志,假设您及时注意到服务器故障。这意味着您的 PG 将降级,并且如果其他磁盘或主机发生故障,数据丢失的风险会增加。根据安装机制,可以非常快速地执行服务器的新安装,这将降低数据丢失的风险。特别是如果您考虑到整个主机的重新映射也意味着集群在相当长的一段时间内降级。因此,重新安装服务器并重新激活其 OSD 实际上可能比等待重新映射完成更快。因此,基本上取决于群集的管理员对单个设置的最佳策略。
另请注意,根据集群详细信息(OSD 数量、存储的数据、集群 I/O、故障域等),关闭的 OSD 上的 PG 可能已过时,以至于将它们添加回集群可能会导致比添加新 OSD 更多的负载。
溶液
如果您决定保留这些关闭的 OSD 并使它们重新联机,则这些是实现这一目标的基本步骤。
我的虚拟实验室环境在 OpenStack 中运行,因此为了模拟节点故障,我只是删除了一个虚拟机 (VM),当然,OSD 卷没有被删除。然后,我启动了一个新的虚拟机,为使用 Ceph 做好了准备,并将 OSD 卷附加到其中。
将主机添加到 Ceph 后,已经成功部署了一个“崩溃”容器,因此 cephadm 似乎可以通过命令正确确认:ceph-volume
<span style="background-color:#ffffff"><span style="color:#333333"><span style="background-color:#f7f7f7"><span style="color:#222222">ses7-host1:~ # cephadm ceph-volume lvm list
Inferring fsid 7bdffde0-623f-11eb-b3db-fa163e672db2
Using recent ceph image registry.suse.com/ses/7/ceph/ceph:latest
[...]</span></span></span></span>
尽管 OSD 激活失败,但我有关于这些关闭的 OSD 的所需信息:ceph-volume
- 块设备的路径(数据、数据库、数据)
- OSD FSID
- OSD 标识
- Ceph FSID
- OSD 密钥环
可以从输出中收集这五个属性中的四个。OSD 密钥环可从 获取。cephadm ceph-volume lvm list
ceph auth get osd.<ID>
由于崩溃容器已经存在,因此所需的父目录也存在,对于其余的,我使用不同的 OSD 服务器作为模板。这些是我从其他服务器复制的文件(当然,块和块.db设备除外):
<span style="background-color:#ffffff"><span style="color:#333333"><span style="background-color:#f7f7f7"><span style="color:#222222">ses7-host1:~ # ls -1 /var/lib/ceph/7bdffde0-623f-11eb-b3db-fa163e672db2/osd.6/
block
block.db
ceph_fsid
config
fsid
keyring
ready
require_osd_release
type
unit.configured
unit.created
unit.image
unit.poststop
unit.run
whoami</span></span></span></span>
我只需要将这五个文件的内容替换为正确的密钥环,OSD FSID,OSD ID:
- 菲希德
- 钥匙圈
- 哇
- 单元运行
- 单位.邮站
下一步是创建指向正确的块和块.db设备的符号链接,并更改其所有权:
<span style="background-color:#ffffff"><span style="color:#333333"><span style="background-color:#f7f7f7"><span style="color:#222222">ses7-host1:/var/lib/ceph/<CEPH_FSID>/osd.<OSD_ID>/ # ln -s /dev/ceph-<VG>/osd-block-<LV> blockses7-host1:/var/lib/ceph/<CEPH_FSID>/osd.<OSD_ID>/ # ln -s /dev/ceph-<VG>/osd-block-<LV> block.dbses7-host1:~ # chown -R ceph.ceph /var/lib/ceph/<CEPH_FSID>/osd.<OSD_ID>/</span></span></span></span>
最后启动系统单元:
<span style="background-color:#ffffff"><span style="color:#333333"><span style="background-color:#f7f7f7"><span style="color:#222222">ses7-host1:~ # systemctl start ceph-@osd.<OSD_ID>.service</span></span></span></span>
第一个 OSD 成功启动后,我对该服务器上的所有剩余 OSD 重复此操作,所有这些 OSD 都恢复了在线,没有问题。不过,这还没有用加密的 OSD 进行测试,所以我不确定在这种情况下还需要什么,但也许这个过程有助于解决这个问题。我也不知道是否有更流畅甚至自动化的方法来实现这一目标,我认为目前没有。也许(希望)有人正在研究它。