适用于 SUSE Enterprise Storage 5

1 Salt 集群管理

部署 Ceph 集群后,有些时候可能还需要对它执行若干修改。这些修改包括添加或删除新的节点、磁盘或服务。本章介绍该如何完成这些管理任务。

1.1 添加新的集群节点

为集群添加新节点的过程与第 4 章 “使用 DeepSea/Salt 部署中所述的初始集群节点部署过程几乎完全相同。

  1. 在新节点上安装 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
  2. 在 Salt Master 上接受所有 Salt 密钥:

    root@master # salt-key --accept-all
  3. 校验 /srv/pillar/ceph/deepsea_minions.sls 是否也以新的 Salt Minion 为目标。有关更多详细信息,请参见过程 4.1 “运行部署阶段”第 4.2.2.1 节 “匹配 Minion 名称”

  4. 运行准备阶段。该阶段会同步模块和 Grains 数据,以便新的 Minion 可以提供 DeepSea 需要的所有信息:

    root@master # salt-run state.orch ceph.stage.0
  5. 运行发现阶段。该阶段将在 /srv/pillar/ceph/proposals 目录中写入新的文件项,您可在其中编辑相关的 .yml 文件:

    root@master # salt-run state.orch ceph.stage.1
  6. (可选)如果新添加的主机与现有命名模式不匹配,请更改 /srv/pillar/ceph/proposals/policy.cfg。有关详细信息,请参见第 4.5.1 节 “policy.cfg 文件”

  7. 运行配置阶段。该阶段会读取 /srv/pillar/ceph 下的所有内容,并相应地更新 Pillar:

    root@master # salt-run state.orch ceph.stage.2

    Pillar 用于存储可以使用以下命令访问的数据:

    root@master # salt target pillar.items
  8. 配置和部署阶段包含新添加的节点:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

1.2 为节点添加新的角色

您可通过 DeepSea 部署所有受支持的角色类型。有关受支持角色类型的更多信息以及匹配示例,请参见第 4.5.1.2 节 “角色指定”

提示
提示:必需的与可选的角色和阶段

一般而言,在将新角色添加到集群节点时,建议您运行全部部署阶段 0 到 5。为了节省一些时间,可根据要部署的角色类型,跳过阶段 3 或 4。OSD 和 MON 角色包含核心服务,是 Ceph 的必要组成部分,而其他角色(例如对象网关)则是可选项。DeepSea 部署阶段是分层的:阶段 3 部署核心服务,而阶段 4 则部署可选服务。

因此,部署核心角色(例如在现有 OSD 节点上部署 MON)时需要运行阶段 3,可以跳过阶段 4。

同样,部署可选服务(例如对象网关)时可以跳过阶段 3,但需要运行阶段 4。

要将新服务添加到现有节点,请执行下列步骤:

  1. 修改 /srv/pillar/ceph/proposals/policy.cfg,以使现有主机与新角色匹配。有关详细信息,请参见第 4.5.1 节 “policy.cfg 文件”。例如,如果您需要在 MON 节点上运行对象网关,命令行类似下方所示:

    role-rgw/xx/x/example.mon-1.sls
  2. 运行阶段 2 以更新 Pillar:

    root@master # salt-run state.orch ceph.stage.2
  3. 运行阶段 3 以部署核心服务,或者运行阶段 4 以部署可选服务。同时运行这两个阶段也没有问题。

提示
提示

将 OSD 添加到现有集群时请注意,集群将在此后的一段时间内进行重新平衡。为了尽可能缩短重新平衡的时间,建议您同时添加所有要添加的 OSD。

1.3 删除和重新安装集群节点

要从集群中删除角色,请编辑 /srv/pillar/ceph/proposals/policy.cfg 并删除相应的行。然后按第 4.3 节 “集群部署”中所述运行阶段 2 和 5。

注意
注意:从集群中删除 OSD

如果您需要从集群中删除特定 OSD 节点,请确保集群的可用磁盘空间多于要删除的磁盘空间。切记,删除 OSD 会导致整个集群进行重新平衡。

从 Minion 中删除角色时,其目的是撤销与该角色相关的所有更改。对于大部分角色,要实现该任务都很简单,但可能会存在包依赖项问题。如果包被卸装,其依赖项并不会被卸装。

删除的 OSD 会显示为空白驱动器。相关任务除了会擦除分区表外,还会覆盖文件系统的开头并删除备份分区。

注意
注意:保留通过其他方法创建的分区

先前通过其他方法(例如 ceph-deploy)配置的磁盘驱动器可能仍然包含分区。DeepSea 不会自动销毁这些分区。管理员必须回收这些驱动器。

例 1.1︰ 从集群中删除 Salt Minion

举例来说,如果您的存储 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.2
root@master # salt-run state.orch ceph.stage.5
例 1.2︰ 迁移节点

假设出现下面的情况:在全新安装集群期间,您(管理员)在等待网关硬件就绪时,将其中一个存储节点分配为独立的对象网关。现在,当网关的永久硬件就绪时,您就可以将所需角色最终指定给备用存储节点并删除网关角色。

在针对新硬件运行阶段 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 中删除对象网关角色。

1.4 重新部署监视器节点

一个或多个监视器节点发生故障且不响应时,您需要将发生故障的监视器从集群中删除,然后再添加回集群(如有需要)。

重要
重要:至少须有三个监视器节点

监视器节点的数量不能少于 3。如果某个监视器节点发生故障,导致您的集群中只有一个或两个监视器节点,您需要临时将监视器角色指定给其他集群节点,然后再重新部署发生故障的监视器节点。重新部署发生故障的监视器节点后,便可以卸装临时监视器角色。

有关向 Ceph 集群添加新节点/角色的详细信息,请参见第 1.1 节 “添加新的集群节点”第 1.2 节 “为节点添加新的角色”

有关删除集群节点的详细信息,请参见第 1.3 节 “删除和重新安装集群节点”

Ceph 节点故障分为以下两种基本程度:

  • Salt Minion 主机发生硬件或 OS 级别损坏,无法响应 salt 'minion_name' test.ping 调用。在此情况下,您需要按照第 4.3 节 “集群部署”中的相关说明,对服务器进行彻底的重新部署。

  • 监视器相关服务失败并拒绝恢复,但主机会响应 salt 'minion_name' test.ping 调用。在此情况下,请执行以下步骤:

  1. 编辑 Salt Master 上的 /srv/pillar/ceph/proposals/policy.cfg,删除或更新发生故障的监视器节点对应的行,使它们现在指向正常工作的监视器节点。

  2. 运行 DeepSea 阶段 2 到 5 以应用这些更改:

    root@master # deepsea stage run ceph.stage.2
    root@master # deepsea stage run ceph.stage.3
    root@master # deepsea stage run ceph.stage.4
    root@master # deepsea stage run ceph.stage.5

1.5 为节点添加 OSD

要向现有 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.2
root@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.1
root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

1.6 删除 OSD

您可以通过运行以下命令从集群中删除 Ceph OSD:

root@master # salt-run disengage.safety
root@master # salt-run remove.osd OSD_ID

OSD_ID 需为 OSD 的编号,不含 osd 一词。例如,对于 osd.3,仅使用数字 3

提示
提示:删除多个 OSD

使用 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

1.6.1 强制删除已中止的 OSD

有时会出现无法正常删除 OSD 的情况(请参见第 1.6 节 “删除 OSD”)。例如,如果 OSD 或其快速缓存中止、I/O 操作挂起或 OSD 磁盘无法卸载。在上述情况下,您需要强制删除 OSD:

root@master # target osd.remove OSD_ID force=True

此命令不仅会删除数据分区,还会删除日记或 WAL/DB 分区。

要识别可能处于孤立状态的日记/WAL/DB 设备,请执行以下步骤:

  1. 选择可能存在孤立分区的设备,并将其分区列表保存到文件中:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. 针对所有 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 使用的分区列表。

  3. 使用您首选的命令(例如 fdiskpartedsgdisk)删除不属于 Ceph 的孤立分区。

1.7 恢复重新安装的 OSD 节点

如果您的某个 OSD 节点上的操作系统损坏且无法恢复,请执行以下步骤恢复该节点,并在集群数据保持不变的情况下重新部署该节点的 OSD 角色:

  1. 在节点上重新安装操作系统。

  2. 在 OSD 节点上安装 salt-minion 包,删除 Salt Master 上的旧 Salt Minion 密钥,并向 Salt Master 注册新 Salt Minion 的密钥。有关 Salt Minion 部署的详细信息,请参见第 4.3 节 “集群部署”

  3. 不要运行整个阶段 0,而是运行以下部分:

    root@master # salt 'osd_node' state.apply ceph.sync
    root@master # salt 'osd_node' state.apply ceph.packages.common
    root@master # salt 'osd_node' state.apply ceph.mines
    root@master # salt 'osd_node' state.apply ceph.updates
  4. 运行 DeepSea 阶段 1 到 5:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    root@master # salt-run state.orch ceph.stage.5
  5. 运行 DeepSea 阶段 0:

    root@master # salt-run state.orch ceph.stage.0
  6. 重引导相关的 OSD 节点。系统将重新发现并重新使用所有 OSD 磁盘。

1.8 通过 Salt 实现自动安装

通过使用 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

1.9 更新集群节点

最好定期对您的集群节点应用滚动更新。要应用更新,请运行阶段 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 的行为。所有可用的参数如下:

default

安装更新并在更新之后重引导。

default-update-no-reboot

安装更新而不重引导。

default-no-update-reboot

重引导而不安装更新。

default-no-update-no-reboot

不安装更新,也不重引导。

1.10 停止或重引导集群

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

  1. 告知 Ceph 集群不要将 OSD 标记为 out:

    root # ceph osd set noout
  2. 按下面的顺序停止守护进程和节点:

    1. 存储客户端

    2. 网关,例如 NFS Ganesha 或对象网关

    3. 元数据服务器

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. 根据需要执行维护任务。

  4. 以与关闭过程相反的顺序启动节点和服务器:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. 元数据服务器

    5. 网关,例如 NFS Ganesha 或对象网关

    6. 存储客户端

  5. 删除 noout 标志:

    root # ceph osd unset noout

1.11 自定义 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

对上述配置文件进行自定义更改之后,运行阶段 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 守护进程。

1.11.1 覆盖默认值

段落中位于后面的语句会覆盖前面的语句。因此,可以按照 /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

1.11.2 包括配置文件

如果您需要应用许多自定义配置,请在自定义配置文件中使用以下 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.confosd2.confosd3.confosd4.conf 文件包含特定于相关 OSD 的配置选项。

提示
提示:运行时配置

对 Ceph 配置文件所做的更改将在相关 Ceph 守护进程重启动之后生效。有关更改 Ceph 运行时配置的详细信息,请参见第 1.12 节 “运行时 Ceph 配置”

1.12 运行时 Ceph 配置

第 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 命令可能无法成功更改集群设置。如果您需要确保启用更改的参数,请在配置文件中进行更改并重启动集群中的所有守护进程。

打印此页