适用于 SUSE Enterprise Storage 5

5 从旧版本升级

本章介绍将 SUSE Enterprise Storage 从旧版本升级到最新版本的步骤。

5.1 阅读发行说明

在发行说明中,可以找到有关自 SUSE Enterprise Storage 的上一个版本发行后所进行的更改的其他信息。检查发行说明以了解:

  • 您的硬件是否有特殊的注意事项。

  • 所用的任何软件包是否已发生重大更改。

  • 是否需要对您的安装实施特殊预防措施。

发行说明还提供未能及时编入手册中的信息。它们还包含有关已知问题的说明。

安装包 release-notes-ses 之后,可在本地的 /usr/share/doc/release-notes 目录中或 https://www.suse.com/releasenotes/ 网页上找到发行说明。

5.2 一般升级过程

开始升级过程之前,请考虑以下几项:

升级顺序

在升级 Ceph 集群之前,需要针对 SCC 或 SMT 正确注册底层 SUSE Linux Enterprise Server 和 SUSE Enterprise Storage。当集群已联机并正在运行时,可以升级集群中的守护进程。某些类型的守护进程依赖于其他守护进程。例如,Ceph Object Gateway 依赖于 Ceph Monitor 和 Ceph OSD 守护进程。建议按以下顺序升级:

  1. Ceph Monitor

  2. Ceph Manager

  3. Ceph OSD

  4. 元数据服务器

  5. 对象网关

  6. iSCSI 网关

  7. NFS Ganesha

删除不需要的操作系统快照

删除节点操作系统分区上不需要的文件系统快照。如此可确保升级期间有足够的可用磁盘空间。

检查集群运行状况

建议在开始升级过程之前先检查集群运行状况。

逐个升级

建议逐个升级特定类型的所有守护进程(例如,所有监视器守护进程或所有 OSD 守护进程),以确保它们全部采用相同的版本。另外,建议在尝试体验某个版本的新功能之前,升级集群中的所有守护进程。

升级特定类型的所有守护进程之后,请检查守护进程的状态。

确保在升级所有监视器之后,每个监视器已重新加入仲裁:

root # ceph mon stat

确保在升级所有 OSD 之后,每个 Ceph OSD 守护进程已重新加入集群:

root # ceph osd stat
设置 require-osd-release luminous 标识

将最后一个 OSD 升级到 SUSE Enterprise Storage 5 之后,监视器节点会检测所有 OSD 是否正在运行“luminous”版本的 Ceph,并可能会指出未设置 require-osd-release luminous osdmap 标识。在这种情况下,您需要手动设置此标识,以确认由于集群已升级到“luminous”,无法将它降级回 Ceph“jewel”。运行以下命令来设置该标识:

root@minion > sudo ceph osd require-osd-release luminous

该命令完成后,警告将会消失。

在全新安装的 SUSE Enterprise Storage 5 上,当 Ceph Monitor 创建初始 osdmap 时,会自动设置此标识,因此最终用户无需执行任何操作。

5.3 升级期间加密 OSD

从 SUSE Enterprise Storage 5 开始,默认会使用 BlueStore 而非 FileStore 来部署 OSD。虽然 BlueStore 支持加密,但默认以非加密模式部署 Ceph OSD。下面的过程介绍了在升级过程中加密 OSD 的步骤。我们假设部署 OSD 时使用的数据和 WAL/DB 磁盘都是干净的,且没有分区。如果磁盘曾经使用,请执行步骤 13中所述的过程进行擦除。

重要
重要:一次一个 OSD

您需要逐个部署加密的 OSD,不能同时部署。这是因为 OSD 的数据会用完,集群将数次重复经历重新平衡的过程。

  1. 为您的部署确定 bluestore block db sizebluestore block wal size 的值,并在 Salt Master 上的 /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf 文件中添加这些值。需要以字节指定这些值。

    [global]
    bluestore block db size = 48318382080
    bluestore block wal size = 2147483648

    有关自定义 ceph.conf 文件的详细信息,请参见第 1.11 节 “自定义 ceph.conf 文件”

  2. 运行 DeepSea 阶段 3 来分发更改:

    root@master # salt-run state.orch ceph.stage.3
  3. 确认相关 OSD 节点上是否已更新 ceph.conf 文件:

    root@minion > cat /etc/ceph/ceph.conf
  4. /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions 目录下与您要加密的 OSD 相关的 *.yml 文件进行编辑。检查它们的路径是否与 /srv/pillar/ceph/proposals/policy.cfg 文件中定义的路径一致,以确保您修改的是正确的 *.yml 文件。

    重要
    重要:长磁盘标识符

    /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml 文件中标识 OSD 磁盘时,请使用长磁盘标识符。

    下面显示了一个 OSD 配置示例。请注意,由于我们需要加密,因此删除了 db_sizewal_size 选项:

    ceph:
     storage:
       osds:
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
  5. 运行 DeepSea 阶段 2 和 3 以加密模式部署新的块存储 OSD:

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

    您可以运行 ceph -sceph osd tree 来监控进度。在下一个 OSD 节点上重复该过程前,请务必使集群重新平衡。

5.4 从 SUSE Enterprise Storage 4(DeepSea 部署)升级到版本 5

重要
重要:软件要求

您需要在要升级的所有 Ceph 节点上安装以下软件并将其更新到最新的包版本,然后才能开始升级过程:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

此外,在开始升级之前,需要通过运行 zypper migration(或偏好的升级方式)将 Salt Master 节点升级到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5。

警告
警告:升级前需考虑的要点
  • 检查 AppArmor 服务是否正在运行,并在每个集群节点上禁用该服务。启动 YaST AppArmor 模块,选择设置,然后取消选择启用 Apparmor 复选框。点击完成进行确认。

    请注意,在启用 AppArmor 的情况下,SUSE Enterprise Storage 将无法正常工作。

  • 尽管集群在升级期间可完全正常运行,但 DeepSea 会设置“noout”标识,用于阻止 Ceph 在停机期间重新平衡数据,从而避免不必要的数据传输。

  • 为了优化升级过程,DeepSea 会根据节点的指定角色并遵循 Ceph 上游的建议,按以下顺序升级节点:MON、MGR、OSD、MDS、RGW、IGW 和 NFS Ganesha。

    请注意,如果节点运行多个服务,DeepSea 将无法防止未按上述顺序执行升级。

  • 尽管 Ceph 集群在升级期间可正常运行,但节点可能需要重引导才能应用新内核版本等设置。为了减少等待中的 I/O 操作,建议在升级过程中拒绝传入请求。

  • 集群升级可能要花费很长时间 — 所需时间大约为升级一台计算机的时间乘以集群节点数。

  • 从 Ceph Luminous 开始,不再支持 osd crush location 配置选项。请在升级前更新您的 DeepSea 配置文件,以使用 crush location

要将 SUSE Enterprise Storage 4 集群升级到版本 5,请执行以下步骤:

  1. 运行以下命令设置新的内部对象排序顺序:

    root # ceph osd set sortbitwise
    提示
    提示

    要校验命令是否成功,我们建议运行以下命令

    root # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. 使用 rpm -q deepsea 校验 Salt Master 节点上的 DeepSea 包版本是否至少以 0.7 开头。例如:

    root # rpm -q deepsea
    deepsea-0.7.27+git.0.274c55d-5.1

    如果 DeepSea 包版本号以 0.6 开头,请再次确认是否已成功将 Salt Master 节点迁移到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5(请参见本节开头的重要:软件要求)。在开始升级过程之前,必须满足此先决条件。

    1. 如果已将系统注册到 SUSEConnect 并使用 SCC/SMT,则不需要执行进一步的操作。继续 步骤 4

    2. 如果您使用的不是 SCC/SMT 而是媒体 ISO 或其他包来源,请手动添加以下储存库:SLE12-SP3 基础、SLE12-SP3 更新、SES5 基础和 SES5 更新。您可以使用 zypper 命令来执行此操作。首先,删除所有现有的软件储存库,然后添加所需的新储存库,最后刷新储存库来源:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      之后,更改您的 Pillar 数据以使用另一个策略。编辑

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      并添加下行:

      upgrade_init: zypper-dup
      提示
      提示

      zypper-dup 策略要求您手动添加最新的软件储存库,而默认的 zypper-migration 则依赖于 SCC/SMT 提供的储存库。

  3. 更新 Pillar:

    root@master # salt target saltutil.sync_all

    有关 Salt Minion 定位的详细信息,请参见第 4.2.2 节 “定位 Minion”

  4. 校验是否已成功写入 Pillar:

    root@master # salt target pillar.get upgrade_init

    该命令的输出应会镜像您添加的项。

  5. 升级 Salt Minion:

    root@master # salt target state.apply ceph.updates.salt
  6. 校验是否已升级所有 Salt Minion:

    root@master # salt target test.version
  7. 包含集群的 Salt Minion。有关更多详细信息,请参见过程 4.1 “运行部署阶段”第 4.2.2 节 “定位 Minion”

  8. 开始升级 SUSE Linux Enterprise Server 和 Ceph:

    root@master # salt-run state.orch ceph.maintenance.upgrade
    提示
    提示:重引导后重新运行

    如果升级过程导致 Salt Master 重引导,请重新运行该命令,以再次启动 Salt Minion 的升级过程。

  9. 升级后,检查所有节点上的 AppArmor 是否已禁用并已停止:

    root # systemctl disable apparmor.service
    systemctl stop apparmor.service
  10. 升级后,Ceph Manager 暂时还未安装。要让集群保持正常状态,请执行以下操作:

    1. 运行阶段 0 以启用 Salt REST API:

      root@master # salt-run state.orch ceph.stage.0
    2. 运行阶段 1 以创建 role-mgr/ 子目录:

      root@master # salt-run state.orch ceph.stage.1
    3. 根据第 4.5.1 节 “policy.cfg 文件”中所述编辑 policy.cfg,并将一个 Ceph Manager 角色添加到部署了 Ceph Monitor 的节点。此外,请为集群的某个节点添加 openATTIC 角色。有关更多详细信息,请参见第 15 章 “openATTIC

    4. 运行阶段 2 以更新 Pillar:

      root@master # salt-run state.orch ceph.stage.2
    5. DeepSea 现在用另一种方法来生成 ceph.conf 配置文件,有关更多详细信息,请参见第 1.11 节 “自定义 ceph.conf 文件”

    6. 运行阶段 3 以部署 Ceph Manager:

      root@master # salt-run state.orch ceph.stage.3
    7. 运行阶段 4 以正确配置 openATTIC:

      root@master # salt-run state.orch ceph.stage.4
    注意
    注意:Ceph 密钥功能不匹配

    如果 ceph.stage.3 失败并出现“错误 EINVAL:实体 client.bootstrap-osd 存在,但功能不匹配”,则表示现有集群的 client.bootstrap.osd 密钥的密钥功能 (caps) 与 DeepSea 尝试设置的功能不匹配。在红色错误讯息的上方,可以看到失败命令 ceph auth 的转储。请查看此命令,检查所用的密钥 ID 和文件。对于 client.bootstrap-osd,该命令是

    root # ceph auth add client.bootstrap-osd \
     -i /srv/salt/ceph/osd/cache/bootstrap.keyring

    要解决密钥功能不匹配问题,请检查 DeepSea 正在尝试部署的密钥环文件的内容,例如:

    cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mgr = "allow r"
         caps mon = "allow profile bootstrap-osd"

    将此内容与 ceph auth get client.bootstrap-osd 的输出进行比较:

    root # ceph auth get client.bootstrap-osd
    exported keyring for client.bootstrap-osd
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mon = "allow profile bootstrap-osd"

    可以看到,后一个密钥缺少 caps mgr = "allow r"。要解决此问题,请运行:

    root # ceph auth caps client.bootstrap-osd mgr \
     "allow r" mon "allow profile bootstrap-osd"

    现在,运行 ceph.stage.3 应该会成功。

    运行 ceph.stage.4 时,元数据服务器和对象网关密钥环可能会出现相同的问题。可以运用上述相同的过程:检查失败的命令、要部署的密钥环文件,以及现有密钥的功能。然后运行 ceph auth caps 更新现有的密钥功能,使之与 DeepSea 正在部署的功能匹配。

重要
重要:升级失败

如果集群处于“HEALTH_ERR”状态的持续时间超过 300 秒,或者每个指定角色的服务之一处于停机状态的持续时间超过 900 秒,则表示升级失败。在这种情况下,请尝试找出并解决问题,然后重新运行升级过程。请注意,在虚拟化环境中,超时会更短。

重要
重要:重引导 OSD

升级到 SUSE Enterprise Storage 5 之后,FileStore OSD 启动所需的时间大约会多五分钟,因为 OSD 将对其磁盘中的文件执行一次性转换。

提示
提示:检查集群组件/节点的版本

如果您需要确定单个集群组件和节点的版本(例如,确定所有节点在升级后是否真正处于相同的增补程序级别),可以运行

root@master # salt-run status.report

该命令将会遍历所有连接的 Salt Minion,并扫描 Ceph、Salt 和 SUSE Linux Enterprise Server 的版本号,最后提供一份报告,其中会列出大多数节点的版本,并显示其版本与大多数节点不相同的节点。

5.4.1 将 OSD 迁移到 BlueStore

OSD BlueStore 是 OSD 守护进程的新后端。从 SUSE Enterprise Storage 5 开始,它是默认的选项。与以文件形式将对象存储在 XFS 文件系统中的 FileStore 相比,BlueStore 可提供更高的性能,因为它直接将对象存储在底层块设备中。BlueStore 还能实现 FileStore 所不能提供的其他功能,例如内置压缩和 EC 覆盖。

具体而言,在 BlueStore 中,OSD 包含一个“wal”(预写式日志)设备和一个“db”(RocksDB 数据库)设备。RocksDB 数据库会保存 BlueStore OSD 的元数据。默认情况下,这两个设备驻留在 OSD 所在的同一台设备上,但也可以将它们放置在更快/不同的媒体上。

在 SES5 中,FileStore 和 BlueStore 均受支持,FileStore 和 BlueStore OSD 可在单个集群中共存。在 SUSE Enterprise Storage 升级过程中,FileStore OSD 不会自动转换到 BlueStore。请注意,在尚未迁移到 BlueStore 的 OSD 上,将无法使用特定于 BlueStore 的功能。

在转换到 BlueStore 之前,OSD 需要运行 SUSE Enterprise Storage 5。转换是个缓慢的过程,因为所有数据需要重新写入两次。尽管迁移过程可能需要很长时间才能完成,但在此期间,集群的工作不会中断,所有客户端都可继续访问集群。但是,迁移期间的性能势必会下降,原因是需要重新平衡和回填集群数据。

请执行以下过程将 FileStore OSD 迁移到 BlueStore:

提示
提示:关闭安全措施

运行迁移所需的 Salt 命令会被安全措施阻止。要关闭这些预防措施,请运行下面的命令:

root@master # salt-run disengage.safety
  1. 迁移硬件配置:

    root@master # salt-run state.orch ceph.migrate.policy

    此运行程序会迁移 policy.cfg 文件当前正在使用的所有硬件配置。它会处理 policy.cfg,查找使用原始数据结构的任何硬件配置,并将其转换为新的数据结构。这样会产生名为“migrated-original_name”的新硬件配置。policy.cfg 也会更新。

    如果原始配置包含单独的日记,BlueStore 配置将对该 OSD 的“wal”和“db”使用相同的设备。

  2. DeepSea 通过将 OSD 的权重设置为 0(“抽取”数据,直到 OSD 已空)来迁移 OSD。您可以逐个迁移 OSD,也可以一次性迁移所有 OSD。在任一情况下,当 OSD 已空时,编制进程会删除该 OSD,然后使用新配置重新创建 OSD。

    提示
    提示:建议的方法

    如果您有大量的物理存储节点,或几乎没有任何数据,请使用 ceph.migrate.nodes。如果一个节点占用的容量小于总容量的 10%,则使用 ceph.migrate.nodes 同时移动这些 OSD 中的所有数据的速度可能略微快一点。

    如果您不确定要使用哪种方法,或者站点包含的存储节点较少(例如,每个节点包含的数据大于集群数据的 10%),请选择 ceph.migrate.osds

    1. 要逐个迁移 OSD,请运行:

      root@master # salt-run state.orch ceph.migrate.osds
    2. 要同时迁移每个节点上的所有 OSD,请运行:

      root@master # salt-run state.orch ceph.migrate.nodes
    提示
    提示

    编制进程不提供有关迁移进度的反馈,您可以使用

    root # ceph osd tree

    定期查看哪些 OSD 的权重为 0。

迁移到 BlueStore 之后,对象计数将保持不变,磁盘使用率也几乎相同。

5.5 从 SUSE Enterprise Storage 4(ceph-deploy 部署)升级到版本 5

重要
重要:软件要求

您需要在要升级的所有 Ceph 节点上安装以下软件并将其更新到最新的包版本,然后才能开始升级过程:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

为集群选择 Salt Master。如果集群部署了 Calamari,则 Calamari 节点已经 Salt Master。否则,您用来运行 ceph-deploy 命令的管理节点将成为 Salt Master。

在开始以下过程之前,您需要运行 zypper migration(或偏好的升级方式)将 Salt Master 节点升级到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5。

要将使用 ceph-deploy 部署的 SUSE Enterprise Storage 4 集群升级到版本 5,请执行以下步骤:

过程 5.1︰ 要对所有集群节点应用的步骤(包括 Calamari 节点)
  1. 安装 SLE-12-SP2/SES4 中的 salt 包:

    root # zypper install salt
  2. 安装 SLE-12-SP2/SES4 中的 salt-minion 包,然后启用并启动相关的服务:

    root # zypper install salt-minion
    root # systemctl enable salt-minion
    root # systemctl start salt-minion
  3. 确保主机名“salt”可解析成 Salt Master 节点的 IP 地址。如果无法通过主机名 salt 访问 Salt Master,请编辑文件 /etc/salt/minion,或创建包含以下内容的新文件 /etc/salt/minion.d/master.conf

    master: host_name_of_salt_master
    提示
    提示

    现有 Salt Minion 的 /etc/salt/minion.d/calamari.conf 中已设置 master: 选项。使用什么配置文件名无关紧要,但 /etc/salt/minion.d/ 目录非常重要。

    如果对上述配置文件执行了任何更改,请在所有 Salt Minion 上重启动 Salt 服务:

    root@minion > systemctl restart salt-minion.service
    1. 如果已将系统注册到 SUSEConnect 并使用 SCC/SMT,则不需要执行进一步的操作。

    2. 如果您使用的不是 SCC/SMT 而是媒体 ISO 或其他包来源,请手动添加以下储存库:SLE12-SP3 基础、SLE12-SP3 更新、SES5 基础和 SES5 更新。您可以使用 zypper 命令来执行此操作。首先,删除所有现有的软件储存库,然后添加所需的新储存库,最后刷新储存库来源:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref
过程 5.2︰ 要对 Salt Master 节点应用的步骤
  1. 运行以下命令设置新的内部对象排序顺序:

    root@master # ceph osd set sortbitwise
    提示
    提示

    要校验命令是否成功,我们建议运行以下命令

    root@master # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. 将 Salt Master 节点升级到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5。对于在 SCC 中注册的系统,请使用 zypper migration。如果您是手动提供所需的软件储存库,请使用 zypper dup。升级后,请先确保 Salt Master 节点上只有 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5 的储存库处于活动状态(且已刷新),然后再继续。

  3. 如果该 Master 节点尚不存在,请安装 salt-master 包,然后启用并启动相关的服务:

    root@master # zypper install salt-master
    root@master # systemctl enable salt-master
    root@master # systemctl start salt-master
  4. 通过列出所有 Salt Minion 的密钥来校验这些 Minion 是否存在:

    root@master # salt-key -L
  5. 将所有 Salt Minion 密钥添加到 Salt Master(包括 Minion Master):

    root@master # salt-key -A -y
  6. 确保所有 Salt Minion 的密钥已被接受:

    root@master # salt-key -L
  7. 确保 Salt Master 节点上的软件是最新的:

    root@master # zypper migration
  8. 安装 deepsea 包:

    root@master # zypper install deepsea
  9. 包含集群的 Salt Minion。有关更多详细信息,请参见过程 4.1 “运行部署阶段”第 4.2.2 节 “定位 Minion”

  10. 导入 ceph-deploy 安装的现有集群:

    root@master # salt-run populate.engulf_existing_cluster

    该命令将执行以下操作:

    • 将全部所需的 Salt 和 DeepSea 模块分发到所有 Salt Minion。

    • 检查运行中的 Ceph 集群,并在 /srv/pillar/ceph/proposals 中填充集群的布局。

      将使用与所有检测到的运行中 Ceph 服务匹配的角色创建 /srv/pillar/ceph/proposals/policy.cfg。查看此文件以校验每个现有的 MON、OSD、RGW 和 MDS 节点是否具有适当的角色。OSD 节点将导入到 profile-import/ 子目录,因此您可以检查 /srv/pillar/ceph/proposals/profile-import/cluster//srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ 中的文件,以确认是否正确选取了 OSD。

      注意
      注意

      对于 Salt Master 节点,生成的 policy.cfg 只会应用检测到的 Ceph 服务的角色“role-mon”、“role-mgr”、“role-mds”、“role-rgw”、“role-admin”和“role-master”。如果需要其他角色,则需手动将其添加到该文件(请参见第 4.5.1.2 节 “角色指定”)。

    • 现有集群的 ceph.conf 将保存到 /srv/salt/ceph/configuration/files/ceph.conf.import

    • /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml 将包含集群的 fsid、集群网络和公共网络,并指定 configuration_init: default-import 选项,如此 DeepSea 将使用前面所述的 ceph.conf.import 配置文件,而不是使用 DeepSea 的默认模板 /srv/salt/ceph/configuration/files/ceph.conf.j2

      注意
      注意:自定义 ceph.conf

      如果您需要将 ceph.conf 文件与自定义更改相集成,请等待导入/升级过程成功完成。然后,编辑 /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml 文件,注释掉下面一行:

      configuration_init: default-import

      保存文件,然后按第 1.11 节 “自定义 ceph.conf 文件”中的信息操作。

    • 集群的各个密钥环将保存到以下目录:

      /srv/salt/ceph/admin/cache/
      /srv/salt/ceph/mon/cache/
      /srv/salt/ceph/osd/cache/
      /srv/salt/ceph/mds/cache/
      /srv/salt/ceph/rgw/cache/

      确认这些密钥环文件都存在,并且下面的目录中没有密钥环文件(低于 SUSE Enterprise Storage 5 的版本中不存在 Ceph Manager):

      /srv/salt/ceph/mgr/cache/
  11. salt-run populate.engulf_existing_cluster 命令不会处理 openATTIC 配置的导入过程。您需要手动编辑 policy.cfg 文件,并添加 role-openattic 一行。有关更多详细信息,请参见第 4.5.1 节 “policy.cfg 文件”

  12. salt-run populate.engulf_existing_cluster 命令不会处理 iSCSI 网关配置的导入过程。如果您的集群包含 iSCSI 网关,请手动导入其配置:

    1. 在其中一个 iSCSI 网关节点上,导出当前的 lrbd.conf,然后将其复制到 Salt Master 节点:

      root@minion > lrbd -o >/tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. 在 Salt Master 节点上,将默认 iSCSI 网关配置添加到 DeepSea 设置中:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. policy.cfg 中添加 iSCSI 网关角色,然后保存文件:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
  13. 运行阶段 1 以创建所有可能的角色:

    root@master # salt-run state.orch ceph.stage.1
  14. /srv/pillar/ceph/stack 下生成所需的子目录:

    root@master # salt-run push.proposal
  15. 确认有正常运行的受 DeepSea 管理集群且为其正确指定了角色:

    root@master # salt target pillar.get roles

    将输出与集群的实际布局进行比较。

  16. Calamari 会持续运行一个安排的 Salt 作业来检查集群状态,请删除该作业:

    root@minion > salt target schedule.delete ceph.heartbeat
  17. 然后,执行第 5.4 节 “从 SUSE Enterprise Storage 4(DeepSea 部署)升级到版本 5”中所述的过程。

5.6 从 SUSE Enterprise Storage 4(Crowbar 部署)升级到版本 5

重要
重要:软件要求

您需要在要升级的所有 Ceph 节点上安装以下软件并将其更新到最新的包版本,然后才能开始升级过程:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

要将使用 Crowbar 部署的 SUSE Enterprise Storage 4 升级到版本 5,请执行以下步骤:

  1. 对每个 Ceph 节点(包括 Calamari 节点)停止并禁用与 Crowbar 相关的所有服务:

    root@minion > sudo systemctl stop chef-client
    root@minion > sudo systemctl disable chef-client
    root@minion > sudo systemctl disable crowbar_join
    root@minion > sudo systemctl disable crowbar_notify_shutdown
  2. 对每个 Ceph 节点(包括 Calamari 节点),确认软件储存库指向 SUSE Enterprise Storage 5 和 SUSE Linux Enterprise Server 12 SP3 产品。如果仍然存在指向较旧产品版本的储存库,请将其禁用。

  3. 对每个 Ceph 节点(包括 Calamari 节点),确认 salt-minion 已安装。如果未安装,请予以安装:

    root@minion > sudo zypper in salt salt-minion
  4. 对于未安装 salt-minion 包的 Ceph 节点,请创建 /etc/salt/minion.d/master.conf 文件,并在其中将 master 选项指向 Calamari 节点的完整主机名:

    master: full_calamari_hostname
    提示
    提示

    现有 Salt Minion 的 /etc/salt/minion.d/calamari.conf 中已设置 master: 选项。使用什么配置文件名无关紧要,但 /etc/salt/minion.d/ 目录非常重要。

    启用并启动 salt-minion 服务:

    root@minion > sudo systemctl enable salt-minion
    root@minion > sudo systemctl start salt-minion
  5. 在 Calamari 节点上接受其他所有 Salt Minion 密钥:

    root@master # salt-key -L
    [...]
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    [...]
    
    root@master # salt-key -A
    The following keys are going to be accepted:
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    Proceed? [n/Y] y
    Key for minion d52-54-00-16-45-0a.example.com accepted.
    Key for minion d52-54-00-70-ac-30.example.com accepted.
  6. 如果 Ceph 部署在公共网络上,且没有 VLAN 接口,请在 Crowbar 公共网络为 Calamari 节点添加一个 VLAN 接口。

  7. 使用 zypper migration 或您偏好的方法将 Calamari 节点升级到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5。此后,Calamari 节点便成为 Salt Master。升级后,重引导 Salt Master。

  8. 在 Salt Master 上安装 DeepSea:

    root@master # zypper in deepsea
  9. 指定 deepsea_minions 选项,以将正确的 Salt Minion 组添加到部署阶段。有关更多详细信息,请参见第 4.2.2.3 节 “设置 deepsea_minions 选项”

  10. DeepSea 期望所有 Ceph 节点都有相同的 /etc/ceph/ceph.conf。Crowbar 会为每个节点部署一个稍有差别的 ceph.conf,因此您需要使它们保持一致:

    • 删除 osd crush location hook 选项,它是由 Calamari 所添加。

    • [mon] 段落中删除 public addr 选项。

    • mon host 选项中删除端口号。

  11. 之前,如果您运行的是对象网关,Crowbar 会部署一个单独的 /etc/ceph/ceph.conf.radosgw 文件,以便将 Keystone 机密与常规 ceph.conf 文件区分开。Crowbar 还会添加一个自定义 /etc/systemd/system/ceph-radosgw@.service 文件。由于 DeepSea 不支持此文件,您需要将其删除:

    • 将所有 [client.rgw....] 段落(ceph.conf.radosgw 文件中)追加到所有节点上的 /etc/ceph/ceph.conf 中。

    • 在对象网关节点上运行下面的命令:

      root@minion > rm /etc/systemd/system/ceph-radosgw@.service
      systemctl reenable ceph-radosgw@rgw.public.$hostname
  12. 复查从 Salt Master 运行时 ceph status 是否起作用:

    root@master # ceph status
    cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
    health HEALTH_OK
    [...]
  13. 导入现有集群:

    root@master # salt-run populate.engulf_existing_cluster
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run push.proposal
  14. salt-run populate.engulf_existing_cluster 命令不会处理 iSCSI 网关配置的导入过程。如果您的集群包含 iSCSI 网关,请手动导入其配置:

    1. 在其中一个 iSCSI 网关节点上,导出当前的 lrbd.conf,然后将其复制到 Salt Master 节点:

      root@minion > lrbd -o > /tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. 在 Salt Master 节点上,将默认 iSCSI 网关配置添加到 DeepSea 设置中:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. policy.cfg 中添加 iSCSI 网关角色,然后保存文件:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
    1. 如果已将系统注册到 SUSEConnect 并使用 SCC/SMT,则不需要执行进一步的操作。

    2. 如果您使用的不是 SCC/SMT 而是媒体 ISO 或其他包来源,请手动添加以下储存库:SLE12-SP3 基础、SLE12-SP3 更新、SES5 基础和 SES5 更新。您可以使用 zypper 命令来执行此操作。首先,删除所有现有的软件储存库,然后添加所需的新储存库,最后刷新储存库来源:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      之后,更改您的 Pillar 数据以使用另一个策略。编辑

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      并添加下行:

      upgrade_init: zypper-dup
      提示
      提示

      zypper-dup 策略要求您手动添加最新的软件储存库,而默认的 zypper-migration 则依赖于 SCC/SMT 提供的储存库。

  15. 修复主机 Grain,以便让 DeepSea 在公共网络上为 Ceph 守护进程实例 ID 使用短主机名。对于每个节点,您需要使用新的(短)主机名运行 grains.set。运行 grains.set 前,请通过运行 ceph status 校验当前的监视器实例。下面是设置短主机名前后的示例:

    root@master # salt target grains.get host
    d52-54-00-16-45-0a.example.com:
        d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        d52-54-00-49-17-2a
    d52-54-00-76-21-bc.example.com:
        d52-54-00-76-21-bc
    d52-54-00-70-ac-30.example.com:
        d52-54-00-70-ac-30
    root@master # salt d52-54-00-16-45-0a.example.com grains.set \
     host public.d52-54-00-16-45-0a
    root@master # salt d52-54-00-49-17-2a.example.com grains.set \
     host public.d52-54-00-49-17-2a
    root@master # salt d52-54-00-76-21-bc.example.com grains.set \
     host public.d52-54-00-76-21-bc
    root@master # salt d52-54-00-70-ac-30.example.com grains.set \
     host public.d52-54-00-70-ac-30
    root@master # salt target grains.get host
    d52-54-00-76-21-bc.example.com:
        public.d52-54-00-76-21-bc
    d52-54-00-16-45-0a.example.com:
        public.d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        public.d52-54-00-49-17-2a
    d52-54-00-70-ac-30.example.com:
        public.d52-54-00-70-ac-30
  16. 运行升级:

    root@master # salt target state.apply ceph.updates
    root@master # salt target test.version
    root@master # salt-run state.orch ceph.maintenance.upgrade

    每个节点都将重引导。集群将再次启动,报告没有活动的 Ceph Manager 实例。这是正常的。此时,Calamari 应未安装/不再运行。

  17. 运行所有必要的部署阶段,以将集群置于健康状态:

    root@master # salt-run state.orch ceph.stage.0
    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
  18. 要部署 openATTIC(请参见第 15 章 “openATTIC),请在 /srv/pillar/ceph/proposals/policy.cfg 中添加合适的 role-openattic 行(请参见第 4.5.1.2 节 “角色指定”),然后运行:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.4
  19. 升级期间,您可能会收到“错误 EINVAL:项目 [...] 存在,但功能不匹配”错误。要修正这些错误,请参见第 5.4 节 “从 SUSE Enterprise Storage 4(DeepSea 部署)升级到版本 5”

  20. 执行剩余的清理操作:

    • Crowbar 会在每个 OSD 的 /etc/fstab 中创建一些条目。这些条目并不需要,因此请将其删除。

    • Calamari 会持续运行一个安排的 Salt 作业来检查集群状态,请删除该作业:

      root@master # salt target schedule.delete ceph.heartbeat
    • 同时还安装了一些不需要的包,大多为 ruby gem 以及 chef 相关的包。虽然删除它们并不是必需的,但您可能希望通过运行 zypper rm pkg_name 来删除。

5.7 从 SUSE Enterprise Storage 3 升级到版本 5

重要
重要:软件要求

您需要在要升级的所有 Ceph 节点上安装以下软件并将其更新到最新的包版本,然后才能开始升级过程:

  • SUSE Linux Enterprise Server 12 SP1

  • SUSE Enterprise Storage 3

要将 SUSE Enterprise Storage 3 集群升级到版本 5,请依次执行过程 5.1 “要对所有集群节点应用的步骤(包括 Calamari 节点)”过程 5.2 “要对 Salt Master 节点应用的步骤”中所述的步骤。

打印此页