从旧版本升级 | 部署指南 | SUSE Enterprise Storage 5

documentation.suse.com › SUSE Enterprise Storage 5 文档 › 部署指南 › 集群部署和升级 › 从旧版本升级

适用于 SUSE Enterprise Storage 5

5 从旧版本升级 #

5.1 阅读发行说明
5.2 一般升级过程
5.3 升级期间加密 OSD
5.4 从 SUSE Enterprise Storage 4（DeepSea 部署）升级到版本 5
5.5 从 SUSE Enterprise Storage 4（ceph-deploy 部署）升级到版本 5
5.6 从 SUSE Enterprise Storage 4（Crowbar 部署）升级到版本 5
5.7 从 SUSE Enterprise Storage 3 升级到版本 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 守护进程。建议按以下顺序升级：

Ceph Monitor
Ceph Manager
Ceph OSD
元数据服务器
对象网关
iSCSI 网关
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 的数据会用完，集群将数次重复经历重新平衡的过程。

为您的部署确定 bluestore block db size 和 bluestore 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 文件”。

运行 DeepSea 阶段 3 来分发更改：

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

确认相关 OSD 节点上是否已更新 ceph.conf 文件：
```
root@minion > cat /etc/ceph/ceph.conf
```

对 /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_size 和 wal_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

运行 DeepSea 阶段 2 和 3 以加密模式部署新的块存储 OSD：
```
root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
```
您可以运行 ceph -s 或 ceph 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，请执行以下步骤：

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

root # ceph osd set sortbitwise

提示

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

root # ceph osd dump --format json-pretty | grep sortbitwise
 "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

使用 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 提供的储存库。
更新 Pillar：
```
root@master # salt target saltutil.sync_all
```
有关 Salt Minion 定位的详细信息，请参见第 4.2.2 节 “定位 Minion”。
校验是否已成功写入 Pillar：
```
root@master # salt target pillar.get upgrade_init
```
该命令的输出应会镜像您添加的项。

升级 Salt Minion：

root@master # salt target state.apply ceph.updates.salt

校验是否已升级所有 Salt Minion：
```
root@master # salt target test.version
```
包含集群的 Salt Minion。有关更多详细信息，请参见过程 4.1 “运行部署阶段”的第 4.2.2 节 “定位 Minion”。
开始升级 SUSE Linux Enterprise Server 和 Ceph：
```
root@master # salt-run state.orch ceph.maintenance.upgrade
```
提示：重引导后重新运行
如果升级过程导致 Salt Master 重引导，请重新运行该命令，以再次启动 Salt Minion 的升级过程。
升级后，检查所有节点上的 AppArmor 是否已禁用并已停止：
```
root # systemctl disable apparmor.service
systemctl stop apparmor.service
```
升级后，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

迁移硬件配置：
```
root@master # salt-run state.orch ceph.migrate.policy
```
此运行程序会迁移 policy.cfg 文件当前正在使用的所有硬件配置。它会处理 policy.cfg，查找使用原始数据结构的任何硬件配置，并将其转换为新的数据结构。这样会产生名为“migrated-original_name”的新硬件配置。policy.cfg 也会更新。
如果原始配置包含单独的日记，BlueStore 配置将对该 OSD 的“wal”和“db”使用相同的设备。
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 节点） #

安装 SLE-12-SP2/SES4 中的 salt 包：
```
root # zypper install salt
```

安装 SLE-12-SP2/SES4 中的 salt-minion 包，然后启用并启动相关的服务：

root # zypper install salt-minion
root # systemctl enable salt-minion
root # systemctl start salt-minion

确保主机名“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
```

如果已将系统注册到 SUSEConnect 并使用 SCC/SMT，则不需要执行进一步的操作。

如果您使用的不是 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 节点应用的步骤 #

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

root@master # ceph osd set sortbitwise

提示

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

root@master # ceph osd dump --format json-pretty | grep sortbitwise
 "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

将 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 的储存库处于活动状态（且已刷新），然后再继续。

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

root@master # zypper install salt-master
root@master # systemctl enable salt-master
root@master # systemctl start salt-master

通过列出所有 Salt Minion 的密钥来校验这些 Minion 是否存在：
```
root@master # salt-key -L
```
将所有 Salt Minion 密钥添加到 Salt Master（包括 Minion Master）：
```
root@master # salt-key -A -y
```
确保所有 Salt Minion 的密钥已被接受：
```
root@master # salt-key -L
```
确保 Salt Master 节点上的软件是最新的：
```
root@master # zypper migration
```
安装 deepsea 包：
```
root@master # zypper install deepsea
```
包含集群的 Salt Minion。有关更多详细信息，请参见过程 4.1 “运行部署阶段”的第 4.2.2 节 “定位 Minion”。
导入 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/
```
salt-run populate.engulf_existing_cluster 命令不会处理 openATTIC 配置的导入过程。您需要手动编辑 policy.cfg 文件，并添加 role-openattic 一行。有关更多详细信息，请参见第 4.5.1 节 “policy.cfg 文件”。
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 以创建所有可能的角色：
```
root@master # salt-run state.orch ceph.stage.1
```
在 /srv/pillar/ceph/stack 下生成所需的子目录：
```
root@master # salt-run push.proposal
```
确认有正常运行的受 DeepSea 管理集群且为其正确指定了角色：
```
root@master # salt target pillar.get roles
```
将输出与集群的实际布局进行比较。
Calamari 会持续运行一个安排的 Salt 作业来检查集群状态，请删除该作业：
```
root@minion > salt target schedule.delete ceph.heartbeat
```
然后，执行第 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，请执行以下步骤：

对每个 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

对每个 Ceph 节点（包括 Calamari 节点），确认软件储存库指向 SUSE Enterprise Storage 5 和 SUSE Linux Enterprise Server 12 SP3 产品。如果仍然存在指向较旧产品版本的储存库，请将其禁用。
对每个 Ceph 节点（包括 Calamari 节点），确认 salt-minion 已安装。如果未安装，请予以安装：
```
root@minion > sudo zypper in salt salt-minion
```
对于未安装 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
```

在 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.

如果 Ceph 部署在公共网络上，且没有 VLAN 接口，请在 Crowbar 公共网络为 Calamari 节点添加一个 VLAN 接口。
使用 zypper migration 或您偏好的方法将 Calamari 节点升级到 SUSE Linux Enterprise Server 12 SP3 和 SUSE Enterprise Storage 5。此后，Calamari 节点便成为 Salt Master。升级后，重引导 Salt Master。
在 Salt Master 上安装 DeepSea：
```
root@master # zypper in deepsea
```
指定 deepsea_minions 选项，以将正确的 Salt Minion 组添加到部署阶段。有关更多详细信息，请参见第 4.2.2.3 节 “设置 deepsea_minions 选项”。
DeepSea 期望所有 Ceph 节点都有相同的 /etc/ceph/ceph.conf。Crowbar 会为每个节点部署一个稍有差别的 ceph.conf，因此您需要使它们保持一致：
- 删除 osd crush location hook 选项，它是由 Calamari 所添加。
- 从 [mon] 段落中删除 public addr 选项。
- 从 mon host 选项中删除端口号。
之前，如果您运行的是对象网关，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
```

复查从 Salt Master 运行时 ceph status 是否起作用：

root@master # ceph status
cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
health HEALTH_OK
[...]

导入现有集群：

root@master # salt-run populate.engulf_existing_cluster
root@master # salt-run state.orch ceph.stage.1
root@master # salt-run push.proposal

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

在其中一个 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

在 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

在 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 提供的储存库。

修复主机 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

运行升级：
```
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 应未安装/不再运行。

运行所有必要的部署阶段，以将集群置于健康状态：

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

要部署 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
```
升级期间，您可能会收到“错误 EINVAL：项目 [...] 存在，但功能不匹配”错误。要修正这些错误，请参见第 5.4 节 “从 SUSE Enterprise Storage 4（DeepSea 部署）升级到版本 5”。
执行剩余的清理操作：
- 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 节点应用的步骤”中所述的步骤。

打印此页

部署指南

5 从旧版本升级 #

5.1 阅读发行说明 #

5.2 一般升级过程 #

5.3 升级期间加密 OSD #

重要：一次一个 OSD

重要：长磁盘标识符

5.4 从 SUSE Enterprise Storage 4（DeepSea 部署）升级到版本 5 #

重要：软件要求

警告：升级前需考虑的要点

提示

提示

提示：重引导后重新运行

注意：Ceph 密钥功能不匹配

重要：升级失败

重要：重引导 OSD

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

5.4.1 将 OSD 迁移到 BlueStore #

提示：关闭安全措施

提示：建议的方法

提示

5.5 从 SUSE Enterprise Storage 4（ceph-deploy 部署）升级到版本 5 #

重要：软件要求

过程 5.1︰ 要对所有集群节点应用的步骤（包括 Calamari 节点） #

提示

过程 5.2︰ 要对 Salt Master 节点应用的步骤 #

提示

注意

注意：自定义 ceph.conf

5.6 从 SUSE Enterprise Storage 4（Crowbar 部署）升级到版本 5 #

重要：软件要求

提示

提示

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

重要：软件要求

5.5 从 SUSE Enterprise Storage 4（`ceph-deploy` 部署）升级到版本 5 #

过程 5.1︰要对所有集群节点应用的步骤（包括 Calamari 节点） #

过程 5.2︰要对 Salt Master 节点应用的步骤 #

注意：自定义 `ceph.conf`