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

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

适用于 SUSE Enterprise Storage 6

6 从旧版本升级 #

6.1 升级前需考虑的要点
6.2 备份集群数据
6.3 从 ntpd 迁移到 chronyd
6.4 升级前对集群应用增补程序
6.5 确认当前环境
6.6 检查集群的状态
6.7 CTDB 集群的脱机升级
6.8 按节点升级 - 基本过程
6.9 升级管理节点
6.10 升级 Ceph Monitor/Ceph Manager 节点
6.11 升级元数据服务器
6.12 升级 Ceph OSD
6.13 将 OSD 迁移到 BlueStore
6.14 升级应用节点
6.15 更新 policy.cfg 并使用 DeepSea 部署 Ceph Dashboard
6.16 从基于配置的部署迁移到 DriveGroups

本章说明将 SUSE Enterprise Storage 5.5 升级到版本 6 的步骤。请注意，版本 5.5 是在版本 5 的基础上应用了所有最新增补程序后的版本。

注意：不支持从更早的版本升级

不支持从低于 5.5 的 SUSE Enterprise Storage 版本升级。您需要先升级到 SUSE Enterprise Storage 5.5 的最新版本，然后再按照本章中所述的步骤操作。

6.1 升级前需考虑的要点 #

阅读发行说明 - 发行说明提供了有关自 SUSE Enterprise Storage 上一个版本发行后所进行的更改的其他信息。检查发行说明以了解：
- 您的硬件是否有特殊的注意事项。
- 所用的任何软件包是否已发生重大更改。
- 是否需要对您的安装实施特殊预防措施。
发行说明还提供未能及时编入手册中的信息。它们还包含有关已知问题的说明。
安装包 release-notes-ses之后，可在本地的 /usr/share/doc/release-notes 目录中或 https://www.suse.com/releasenotes/ 网页上找到发行说明。
如果您先前是从版本 4 升级的，请确认升级到版本 5 的过程已成功完成：
- 检查以下文件是否存在
```
/srv/salt/ceph/configuration/files/ceph.conf.import
```
  从 SES 4 升级到 5 的过程中，engulf 进程会创建该文件。另外，会在以下文件中设置 configuration_init: default-import 选项
```
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
```
  如果 configuration_init 仍设为 default-import，则表示集群是使用 ceph.conf.import 而非 DeepSea 的默认 ceph.conf 作为其配置文件的，后者是通过对以下目录中的文件进行编译而生成的
```
/srv/salt/ceph/configuration/files/ceph.conf.d/
```
  因此，您需要检查 ceph.conf.import 中是否有任何自定义配置，并根据需要将相应配置移到以下目录中的其中一个文件中
```
/srv/salt/ceph/configuration/files/ceph.conf.d/
```
  然后，从下面的文件中删除 configuration_init: default-import 一行
```
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
```
  警告：默认 DeepSea 配置
  如果您未合并 ceph.conf.import 中的配置，并删除了 configuration_init: default-import 选项，那么我们随 DeepSea 一并提供的任何默认配置设置（存储在 /srv/salt/ceph/configuration/files/ceph.conf.j2 中）都不会应用到集群。
- 检查集群是否使用了新存储桶类型“straw2”：
```
cephadm@adm > ceph osd crush dump | grep straw
```
- 检查是否使用了 Ceph“jewel”配置：
```
cephadm@adm > ceph osd crush dump | grep profile
```
如果使用的是旧 RBD 内核客户端（低于 SUSE Linux Enterprise Server 12 SP3），请参见第 12.9 节 “使用旧内核客户端映射 RBD”。如果可能，建议升级旧 RBD 内核客户端。
如果 openATTIC 位于管理节点上，当您升级该节点后，openATTIC 将不可用。在您使用 DeepSea 部署新 Ceph Dashboard 前，该仪表盘将不可用。
升级集群可能需要花很长时间 - 所需时间大约为升级一台计算机的时间乘以集群节点数。
如果某个节点运行的是先前的 SUSE Linux Enterprise Server 版本，则无法进行升级，需要将其重引导到新版本的安装程序。因此，该节点提供的服务将在一段时间内不可用。内核集群服务将仍然可用，例如，如果在升级期间有一个 MON 停用，至少还有两个 MON 处于活跃状态。但不幸的是，单一 iSCSI 网关这样的单一实例服务将不可用。
某些类型的守护进程依赖于其他守护进程。例如，Ceph 对象网关依赖于 Ceph MON 和 Ceph OSD 守护进程。建议按以下顺序升级：
1. 管理节点
2. Ceph Monitor/Ceph Manager
3. 元数据服务器
4. Ceph OSD
5. 对象网关
6. iSCSI 网关
7. NFS Ganesha
8. Samba 网关
如果您之前是在“控诉”或“强制”模式下使用 AppArmor 的，则需要在升级前设置 Salt Pillar 变量。由于 SUSE Linux Enterprise Server 15 SP1 默认随附了 AppArmor，因此 DeepSea 阶段 0 中已集成 AppArmor 管理。SUSE Enterprise Storage 6 默认会删除 AppArmor 和相关配置。如果您要保留在 SUSE Enterprise Storage 5.5 中配置的行为，请在开始升级前确认 /srv/pillar/ceph/stack/global.yml 文件中是否存在以下其中一行：
```
apparmor_init: default-enforce
```
或者
```
apparmor_init: default-complain
```
自 SUSE Enterprise Storage 6 起，不再允许使用以数字开头的 MDS 名称，否则 MDS 守护进程将拒绝启动。您可以通过运行 ceph fs status 命令来检查守护进程是否使用了此类名称，也可以通过重启动 MDS，然后检查其日志中是否存在以下讯息来确认：
```
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in
a future version.  MDS names may not start with a numeric digit.
```
如果您看到上述讯息，则需要在尝试升级到 SUSE Enterprise Storage 6 前迁移 MDS 名称。DeepSea 提供了一种编制流程来自动完成此迁移。它会在以数字开头的 MDS 名称前加上“mds.”前缀：
```
root@master # salt-run state.orch ceph.mds.migrate-numerical-names
```
提示：与 MDS 名称绑定的自定义配置
如果您有与 MDS 名称绑定的配置设置，且 MDS 守护进程的名称以数字开头，请确认您的配置设置是否同样适用于新名称（带有“mds.”前缀）。假设 /etc/ceph/ceph.conf 文件中包含以下示例段落：
```
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit
mds cache memory limit = 1073741824
mds standby for name = 456-another-mds
```
ceph.mds.migrate-numerical-names 协调程序会将 MDS 守护进程名称“123-my-mds”更改为“mds.123-my-mds”。您需要调整配置以反映新名称：
```
[mds.mds,123-my-mds] # config setting specific to MDS name with the new name
mds cache memory limit = 1073741824
mds standby for name = mds.456-another-mds
```
如此将会在删除旧 MDS 守护进程前添加使用新名称的 MDS 守护进程。因此，短时间内 MDS 守护进程的数量会翻倍。系统将会有一个短时暂停来进行故障转移，然后客户端才能访问 CephFS。因此，请将迁移安排在预期只有少量或没有 CephFS 负载的时段进行。

6.2 备份集群数据 #

虽然创建集群配置和数据的备份并非强制性操作，但我们仍强烈建议备份重要的配置文件和集群数据。有关更多详细信息，请参见第 3 章 “备份集群配置和数据”。

6.3 从 `ntpd` 迁移到 `chronyd` #

SUSE Linux Enterprise Server 15 SP1 不再使用 ntpd 来同步本地主机时间，而是使用 chronyd。您需要迁移每个集群节点上的时间同步守护进程。您可以在升级集群前迁移到 chronyd，也可以先升级集群，然后再迁移到 chronyd。

过程 6.1︰在升级集群前迁移到 `chronyd` #

安装 chrony 包：
```
root@minion > zypper install chrony
```
编辑 chronyd 配置文件 /etc/chrony.conf，并添加在 /etc/ntp.conf 中的当前 ntpd 配置中指定的 NTP 源。
提示：有关 chronyd 配置的更多详细信息
有关如何在 chronyd 配置中添加时间源的更多详细信息，请参见 https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html。

禁用并停止 ntpd 服务：

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

启动并启用 chronyd 服务：

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

确认 chrony 的状态：
```
root@minion > chronyc tracking
```

过程 6.2︰在升级集群后迁移到 `chronyd` #

在集群升级期间，请添加以下软件储存库：
- SLE-Module-Legacy15-SP1-Pool
- SLE-Module-Legacy15-SP1-Updates
将集群升级到版本 6。
编辑 chronyd 配置文件 /etc/chrony.conf，并添加在 /etc/ntp.conf 中的当前 ntpd 配置中指定的 NTP 源。
提示：有关 chronyd 配置的更多详细信息
有关如何在 chronyd 配置中添加时间源的更多详细信息，请参见 https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html。

禁用并停止 ntpd 服务：

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

启动并启用 chronyd 服务：

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

从 ntpd 迁移到 chronyd。
确认 chrony 的状态：
```
root@minion > chronyc tracking
```
删除您在升级过程中为了在系统中保留 ntpd 而添加的旧版软件储存库。

6.4 升级前对集群应用增补程序 #

在升级前，需要对所有集群节点应用最新的增补程序。

6.4.1 所需的软件储存库 #

检查是否已在每个集群节点上配置所需储存库。要列出所有可用储存库，请运行以下命令

root@minion > zypper lr

SUSE Enterprise Storage 5.5 需要：

SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates

SUSE Linux Enterprise Server 12 SP3 上运行的 SLE-HA 上的 NFS/SMB 网关需要：

SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates

6.4.2 储存库暂存系统 #

如果您在使用某个储存库暂存系统（SMT、RMT；或SUSE Manager），请为当前和新的 SUSE Enterprise Storage 版本创建新的冻结增补程序级别。

有关详细信息，请参见：

6.4.3 对整个集群应用最新的增补程序 #

对每个 Ceph 集群节点应用 SUSE Enterprise Storage 5.5 和 SUSE Linux Enterprise Server 12 SP3 的最新增补程序。确认已将正确的软件储存库连接到每个集群节点（请参见第 6.4.1 节 “所需的软件储存库”），然后运行 DeepSea 阶段 0：
```
root@master # salt-run state.orch ceph.stage.0
```
阶段 0 运行完成后，确认每个集群节点的状态是否包含“HEALTH_OK”。如果未包含，请先解决问题，然后再进行后续步骤中可能的重引导。
运行 zypper ps 以检查是否存在可能使用过时的库或二进制运行的进程，如果存在，则进行重引导。
确认运行中的内核是否为最新版本，如果不是，则进行重引导。检查以下命令的输出：
```
cephadm@adm > uname -a
cephadm@adm > rpm -qa kernel-default
```
确认是否已安装 ceph 包为 12.2.12 或更新版本。确认是否已安装 deepsea 包为 0.8.9 或更新版本。
如果您之前使用了任何 bluestore_cache 设置，从 ceph 12.2.10 版本开始，这些设置将不再有效。新设置 bluestore_cache_autotune（默认设为“true”）会禁止手动调整缓存大小。要启用旧行为，您需要设置 bluestore_cache_autotune=false。有关详细信息，请参见第 16.2.1 节 “自动调整缓存大小”。

6.5 确认当前环境 #

如果系统存在明显问题，请修复后再开始升级。升级过程并不会修复现有的系统问题。
检查集群性能。您可以使用 rados bench、ceph tell osd.* bench 或 iperf3 等命令。
确认对网关（如 iSCSI 网关或对象网关）和 RADOS 块设备的访问权限。
记录系统设置的特定部分，如网络设置、分区或安装详细信息。
使用 supportconfig 收集重要的系统信息，并将其保存在集群节点之外。有关详细信息，请参见 https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html。
确保每个集群节点上都有充足的可用磁盘空间。请使用 df -h 检查可用磁盘空间。必要时，请通过删除不需要的文件/目录或过时的 OS 快照来释放磁盘空间。如果没有足够的可用磁盘空间，在释放出充足的磁盘空间前，请不要继续升级。

6.6 检查集群的状态 #

开始升级过程前，请使用 cluster health 命令检查集群健康状况。除非所有集群节点都报告“HEALTH_OK”，否则请不要开始升级。
确认所有服务都在运行：
- Salt Master 和 Salt Master 守护进程。
- Ceph Monitor 和 Ceph Manager 守护进程。
- 元数据服务器守护进程。
- Ceph OSD 守护进程。
- 对象网关守护进程。
- iSCSI 网关守护进程。

以下命令提供集群状态以及特定配置的详细信息：

ceph -s

列显 Ceph 集群健康状况、正在运行的服务、数据使用率以及 I/O 统计数据的简短摘要。请在开始升级前确认该命令是否报告了“HEALTH_OK”。

ceph health detail

如果 Ceph 集群健康状况并非报告为 OK，该命令可列显详细信息。

ceph versions

列显正在运行的 Ceph 守护进程版本。

ceph df

列显集群上的总磁盘空间和可用磁盘空间。如果集群的可用磁盘空间不到总磁盘空间的 25%，请不要开始升级。

salt '*' cephprocesses.check results=true

列显正在运行的 Ceph 进程及其 PID（按 Salt Minion 排序）。

ceph osd dump | grep ^flags

确认是否存在“recovery_deletes”和“purged_snapdirs”标志。如果不存在，您可以通过运行以下命令强制对所有归置组执行洗刷。请注意，此强制洗刷可能会对您 Ceph 客户端的性能造成负面影响。

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 CTDB 集群的脱机升级 #

CTDB 提供 Samba 网关使用的集群化数据库。CTDB 协议非常简单，不支持节点之间使用不同协议版本进行通讯的集群。因此需要先将 CTDB 节点脱机才能执行升级。

6.8 按节点升级 - 基本过程 #

为了确保内核集群服务在升级期间可用，您需要按顺序逐一升级集群节点。您可以使用两种方式执行节点升级：使用安装程序 DVD，或者使用发行套件迁移系统。

升级每个节点后，我们建议运行 rpmconfigcheck 命令来检查是否存在任何在本地编辑过的已更新配置文件。如果命令返回后缀为 .rpmnew、.rpmorig 或 .rpmsave 的文件名列表，请将这些文件与当前配置文件进行比较，以确保没有丢失任何本地更改。如果需要，请更新受影响的文件。有关处理 .rpmnew、.rpmorig 和 .rpmsave 文件的详细信息，请参见 https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-sw-cl.html#sec-rpm-packages-manage。

提示：孤立包

升级一个节点后，有一些包将处于“孤立”状态，没有父储存库。这是因为与 python3 相关的包不会废弃 python2 包。

有关列出孤立包的详细信息，请参见 https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned。

6.8.1 使用安装程序 DVD 手动升级节点 #

从 SUSE Linux Enterprise Server 15 SP1 安装程序 DVD/映像重引导节点。
从引导菜单中选择升级。
在选择迁移目标屏幕上，确认选择了“SUSE Linux Enterprise Server 15 SP1”，然后激活手动调整用于迁移的储存库复选框。
图 6.1︰选择迁移目标 #
选择以下扩展模块加以安装：
- SUSE Enterprise Storage 6 x86_64
- Basesystem Module 15 SP1 x86_64
- Desktop Applications Module 15 SP1 x86_64
- Legacy Module 15 SP1 x86_64
- Server Applications Module 15 SP1 x86_64
在以前使用过的储存库屏幕上，确认选择了正确的储存库。如果未在 SCC/SMT 中注册系统，您需要手动添加储存库。
SUSE Enterprise Storage 6 需要：
- SLE-Module-Basesystem15-SP1-Pool
- SLE-Module-Basesystem15-SP1-Updates
- SLE-Module-Server-Applications15-SP1-Pool
- SLE-Module-Server-Applications15-SP1-Updates
- SLE-Module-Desktop-Applications15-SP1-Pool
- SLE-Module-Desktop-Applications15-SP1-Updates
- SLE-Product-SLES15-SP1-Pool
- SLE-Product-SLES15-SP1-Updates
- SLE15-SP1-Installer-Updates
- SUSE-Enterprise-Storage-6-Pool
- SUSE-Enterprise-Storage-6-Updates
如果您要在迁移 SES 后将 ntpd 迁移到 chronyd（请参见第 6.3 节 “从 ntpd 迁移到 chronyd”），请包含以下储存库：
- SLE-Module-Legacy15-SP1-Pool
- SLE-Module-Legacy15-SP1-Updates
SUSE Linux Enterprise Server 15 SP1 上运行的 SLE-HA 上的 NFS/SMB 网关需要：
- SLE-Product-HA15-SP1-Pool
- SLE-Product-HA15-SP1-Updates
检查安装设置，然后点击更新开始安装过程。

6.8.2 使用 SUSE 发行套件迁移系统升级节点 #

发行套件迁移系统 (DMS) 提供将安装的 SUSE Linux Enterprise 系统从一个主要版本升级到另一个主要版本的升级路径。以下过程使用 DMS 将 SUSE Enterprise Storage 5.5 升级到版本 6，其中包括从基础 SUSE Linux Enterprise Server 12 SP3 迁移到 SUSE Linux Enterprise Server 15 SP1。

有关 DMS 的一般和详细信息，请参见 https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/。

安装迁移 RPM 包。它们会调整 GRUB 引导加载程序，以在下次重引导时自动触发升级。安装 SLES15-SES-Migration 和 suse-migration-sle15-activation 包：
```
root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
```
1. 如果已在储存库暂存系统（如 SCC、SMT、RMT 或 SUSE Manager）中注册要升级的节点，请创建包含以下内容的 /etc/sle-migration-service.yml 文件：
```
use_zypper_migration: true
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules
```
2. 如果未在储存库暂存系统（如 SCC、SMT、RMT 或 SUSE Manager）中注册要升级的节点，请进行以下更改：
  1. 创建包含以下内容的 /etc/sle-migration-service.yml 文件：
```
use_zypper_migration: false
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules
```
  2. 禁用或删除 SLE 12 SP3 和 SES 5 储存库，并添加 SLE 15 SP1 和 SES 6 储存库。第 6.4.1 节 “所需的软件储存库”中列出了相关的储存库。
重引导以开始升级。当升级运行期间，您可以从主机系统上使用现有 SSH 密钥通过 ssh 以迁移用户身份登录已升级节点（如 https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ 中所述）。对于 SUSE Enterprise Storage，如果您能够亲身访问计算机或可直接通过控制台访问，则还可以在系统控制台上使用密码 sesupgrade 以 root 身份登录。节点将在升级后自动重引导。
提示：升级失败
如果升级失败，请检查 /var/log/distro_migration.log。修复问题，重新安装迁移 RPM 包，然后重引导节点。

6.9 升级管理节点 #

虽然 Salt Minion 运行的是旧版 Ceph 和 Salt，但下列命令仍有效：salt '*' test.ping 和 ceph status
升级管理节点后，将不再安装 openATTIC。
如果管理节点之前托管着 SMT，请将其迁移到 RMT（请参见 https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html）。
按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。

提示：集群节点的状态

升级管理节点后，您可以运行 salt-run upgrade.status 命令来查看有关集群节点的有用信息。该命令会列出所有节点的 Ceph 和 OS 版本，并会建议应按何顺序升级仍在运行旧版本的所有节点。

root@master # salt-run upgrade.status
The newest installed software versions are:
  ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
  os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:
  admin.ceph (assigned roles: master)
  mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order:
   1: mon1.ceph (assigned roles: admin, mon, mgr)
   2: mon3.ceph (assigned roles: admin, mon, mgr)
   3: data1.ceph (assigned roles: storage)
[...]

6.10 升级 Ceph Monitor/Ceph Manager 节点 #

如果您的集群未使用 MDS 角色，请逐一升级 MON/MGR 节点。
如果您的集群使用 MDS 角色，且 MON/MGR 与 MDS 角色共置，您需要收缩 MDS 集群，然后升级共置的节点。有关更多详细信息，请参见第 6.11 节 “升级元数据服务器”。
如果您的集群使用 MDS 角色，且它们在专用服务器上运行，请逐一升级所有 MON/MGR 节点，然后收缩 MDS 集群并进行升级。有关更多详细信息，请参见第 6.11 节 “升级元数据服务器”。

注意：Ceph Monitor 升级

由于 Ceph Monitor 设计存在局限性，一旦有两个 MON 已升级到 SUSE Enterprise Storage 6 且构成了仲裁，那么第三个 MON（仍在运行 SUSE Enterprise Storage 5.5）出于某种原因重启动（包括节点重引导）后将不会重新加入 MON 集群。因此，当有两个 MON 升级后，最好尽快升级其余 MON。

按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。

6.11 升级元数据服务器 #

您需要收缩元数据服务器 (MDS) 集群。由于 SUSE Enterprise Storage 版本 5.5 与 6 之间的功能不兼容，较旧版本的 MDS 守护进程一旦发现有 SES 6 级别的 MDS 加入集群，他们即会关停。因此，在 MDS 节点升级期间，必须将 MDS 集群收缩至只有一个主动 MDS（没有待机 MDS）。升级第二个节点后，就可以再次扩充 MDS 集群。

提示

在负载过重的 MDS 集群上，您可能需要降低负载（例如通过停止客户端），以便单个主动 MDS 就足以处理工作负载。

记下 max_mds 选项的当前值：

cephadm@adm > ceph fs get cephfs | grep max_mds

如果您有多个主动 MDS 守护进程（即 max_mds > 1），请收缩 MDS 集群。要收缩 MDS 集群，请运行以下命令
```
cephadm@adm > ceph fs set FS_NAME max_mds 1
```
其中，FS_NAME 是您 CephFS 实例的名称（默认为“cephfs”）。

找到托管某个待机 MDS 守护进程的节点。查看 ceph fs status 命令的输出，然后开始升级此节点上的 MDS 集群。

cephadm@adm > ceph fs status
cephfs - 2 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State  |  MDS   |    Activity   |  dns  |  inos |
+------+--------+--------+---------------+-------+-------+
|  0   | active | mon1-6 | Reqs:    0 /s |   13  |   16  |
+------+--------+--------+---------------+-------+-------+
+-----------------+----------+-------+-------+
|       Pool      |   type   |  used | avail |
+-----------------+----------+-------+-------+
| cephfs_metadata | metadata | 2688k | 96.8G |
|   cephfs_data   |   data   |    0  | 96.8G |
+-----------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
|    mon3-6   |
|    mon2-6   |
+-------------+

在此示例中，您需要在节点“mon3-6”或“mon2-6”上开始升级过程。

升级具有待机 MDS 守护进程的节点。经过升级的 MDS 节点启动后，过时的 MDS 守护进程将自动关停。此时，客户端可能会经历一段短暂的 CephFS 服务停机时间。
按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。
升级其余 MDS 节点。

将 max_mds 重设置为所需配置：

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 升级 Ceph OSD #

针对每个存储节点执行以下步骤：

识别特定节点上正在运行的 OSD 守护进程：
```
cephadm@osd > ceph osd tree
```

为要升级的节点上的每个 OSD 守护进程设置“noout”标志：

cephadm@osd > ceph osd add-noout osd.OSD_ID

例如：

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

使用以下命令进行验证：

cephadm@osd > ceph health detail | grep noout

或者

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
      6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

通过在待升级节点上运行以下命令，为所有现有 OSD 创建 /etc/ceph/osd/*.json 文件：
```
cephadm@osd > ceph-volume simple scan --force
```
升级 OSD 节点。按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。

激活系统中发现的所有 OSD：

cephadm@osd > ;ceph-volume simple activate --all

提示：分别激活各数据分区

如果您要分别激活各数据分区，则需要知道用于激活相应分区的正确 ceph-volume 命令。请将 X1 替换为分区的正确盘符/编号：

 cephadm@osd > ceph-volume simple scan /dev/sdX1

例如：

cephadm@osd > ceph-volume simple scan /dev/vdb1
[...]
--> OSD 8 got scanned and metadata persisted to file:
/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
--> To take over management of this scanned OSD, and disable ceph-disk
and udev, run:
-->     ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

输出的最后一行包含用于激活该分区的命令：

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
[...]
--> All ceph-disk systemd units have been disabled to prevent OSDs
getting triggered by UDEV events
[...]
Running command: /bin/systemctl start ceph-osd@8
--> Successfully activated OSD 8 with FSID
d7bd2685-5b92-4074-8161-30d146cd0290

确认 OSD 节点在重引导后是否将会正常启动。

解决“Legacy BlueStore stats reporting detected on XX OSD(s)”讯息：

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

在将 Ceph 升级到 14.2.2 时通常会出现该警告。您可以通过以下设置来禁用它：

bluestore_warn_on_legacy_statfs = false

正确的修复方法是在所有由于该问题而停止的 OSD 上运行以下命令：

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

下面的帮助程序脚本将会对 NODE_NAME 节点上的所有 OSD 运行 ceph-bluestore-tool repair 命令：

OSDNODE=OSD_NODE_NAME;\
 for OSD in $(ceph osd ls-tree $OSDNODE);\
 do echo "osd=" $OSD;\
 salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\
 salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
 salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\
 done

对已升级节点上的每个 OSD 守护进程取消设置“noout”标志：

cephadm@osd > ceph osd rm-noout osd.OSD_ID

例如：

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

使用以下命令进行验证：

cephadm@osd > ceph health detail | grep noout

注意：

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

确认集群状态。其输出将如下所示：

cephadm@osd > ceph status
cluster:
  id:     e0d53d64-6812-3dfe-8b72-fd454a6dcf12
  health: HEALTH_WARN
          3 monitors have not enabled msgr2

services:
  mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
  mgr: mon2(active, since 22m), standbys: mon1, mon3
  osd: 30 osds: 30 up, 30 in

data:
  pools:   1 pools, 1024 pgs
  objects: 0 objects, 0 B
  usage:   31 GiB used, 566 GiB / 597 GiB avail
  pgs:     1024 active+clean

确认所有 OSD 节点均已重引导，且重引导后 OSD 已自动启动。

6.13 将 OSD 迁移到 BlueStore #

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

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

在 SUSE Enterprise Storage 5 中，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 rebuild.node TARGET

您也可以选择单独重构建每个节点。例如：

root@master #  salt-run rebuild.node data1.ceph

rebuild.node 始终会先删除节点上的所有 OSD，然后再重新创建这些 OSD。

重要

如果一个 OSD 无法转换，重新运行重构建会销毁已转换的 BlueStore OSD。如果不想重新运行重构建，您可以运行以下命令：

root@master # salt-run disks.deploy TARGET

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

6.14 升级应用节点 #

请按以下顺序升级应用节点：

对象网关
- 如果对象网关基于负载平衡器，便可以在服务不中断的情况下进行对象网关的滚动升级。
- 每次升级后，验证对象网关守护进程是否正在运行，并使用 S3/Swift 客户端进行测试。
- 按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。
iSCSI 网关
- 如果为 iSCSI 授权人配置了多路径，便可以在服务不中断的情况下进行 iSCSI 网关的滚动升级。
- 每次升级后，验证 lrbd 守护进程是否正在运行，并使用授权人进行测试。
- 按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。
NFS Ganesha。按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。
Samba 网关。按照第 6.8 节 “按节点升级 - 基本过程”中所述的过程操作。

6.15 更新 `policy.cfg` 并使用 DeepSea 部署 Ceph Dashboard #

在管理节点上编辑/srv/pillar/ceph/proposals/policy.cfg，并应用以下更改：

重要：无新服务

在集群升级期间，请勿向 policy.cfg 文件添加新服务。请仅在升级完成后再更改集群体系结构。

删除 role-openattic。
将 role-prometheus 和 role-grafana 添加到安装了 Prometheus 和 Grafana 的节点（通常是管理节点）。
现在，系统会忽略 profile-PROFILE_NAME 角色。添加新的相应角色，即 role-storage 一行。例如，针对现有
```
profile-default/cluster/*.sls
```
添加
```
role-storage/cluster/*.sls
```

同步所有 Salt 扩展模块：

root@master # salt '*' saltutil.sync_all

运行 DeepSea 阶段 1 和阶段 2 来更新 Salt Pillar：

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

清理 openATTIC：

root@master # salt OA_MINION state.apply ceph.rescind.openattic
root@master # salt OA_MINION state.apply ceph.remove.openattic

取消设置“restart_igw”粒度，以防阶段 0 重启动尚未安装的 iSCSI 网关：
```
Salt mastersalt '*' grains.delkey restart_igw
```

最后，运行完整的 DeepSea 阶段 0-4：

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
root@master # salt-run state.orch ceph.stage.4

提示：阶段 3 运行期间发生“subvolume missing”错误

DeepSea 阶段 3 可能会失败，显示如下错误：

subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \
'/var/lib/ceph subvolume missing on 4510-1', \
[...]
'See /srv/salt/ceph/subvolume/README.md']

在此情况下，您需要编辑 /srv/pillar/ceph/stack/global.yml，并添加下面一行：

subvolume_init: disabled

然后刷新 Salt Pillar 并重新运行 DeepSea stage.3：

root@master # salt '*' saltutil.refresh_pillar
 root@master # salt-run state.orch ceph.stage.3

DeepSea 成功完成 stage.3 后，Ceph Dashboard 即会运行。有关 Ceph Dashboard 功能的详细概述，请参见第 22 章 “Ceph Dashboard”。

要列出运行仪表盘的节点，请运行以下命令：

cephadm@adm > ceph mgr services | grep dashboard

要列出管理员身份凭证，请运行以下命令：

root@master # salt-call grains.get dashboard_creds

按顺序重启动对象网关服务，以使用“beast”Web 服务器取代过时的“civetweb”：
```
root@master # salt-run state.orch ceph.restart.rgw.force
```
继续之前，我们强烈建议先启用 Ceph 遥测扩展模块。有关详细信息和说明，请参见第 10.2 节 “遥测扩展模块”。

6.16 从基于配置的部署迁移到 DriveGroups #

在 SUSE Enterprise Storage 5.5 中，DeepSea 提供了一个称为“配置”的方法来描述您的 OSD 布局。自 SUSE Enterprise Storage 6 起，我们改用另一种称为 DriveGroups 的方法（有关更多详细信息，请参见第 5.5.2 节 “DriveGroups”）。

注意

您不必立即就迁移到新方法。如 salt-run osd.remove、salt-run osd.replace 或 salt-run osd.purge 之类的破坏性操作仍然可用。但如果要添加新 OSD，便需要迁移到新方法。

由于这些实施的方法不同，我们未提供自动迁移路径。不过，我们提供了各种工具（Salt 运行程序）来尽可能使迁移变得简单。

6.16.1 分析当前布局 #

要查看有关当前部署的 OSD 的信息，请使用以下命令：

root@master # salt-run disks.discover

另外，您可以检查 /srv/pillar/ceph/proposals/profile-*/ 目录中的文件内容。其结构如下所示：

ceph:
  storage:
    osds:
      /dev/disk/by-id/scsi-drive_name: format: bluestore
      /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 创建与当前布局匹配的 DriveGroups #

有关 DriveGroups 规范的更多详细信息，请参见第 5.5.2.1 节 “明细单”。

全新部署与升级场景的不同之处在于要迁移的驱动器已“使用过”。由于

root@master # salt-run disks.list

仅会查找未使用的磁盘，因此请使用以下命令

root@master # salt-run disks.list include_unavailable=True

调整 DriveGroups，直至其与您当前的设置匹配。如需更直观地了解将要发生的情况，请使用以下命令。注意，如果没有可用磁盘，该命令将不会生成任何输出：

root@master # salt-run disks.report bypass_pillar=True

如果您确认 DriveGroups 配置正确且您要应用新方法，请从 /srv/pillar/ceph/proposals/profile-PROFILE_NAME/ 目录中删除文件，从 /srv/pillar/ceph/proposals/policy.cfg 文件中删除相应的 profile-PROFILE_NAME/cluster/*.sls 行，并运行 DeepSea 阶段 2 以刷新 Salt Pillar。

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

请运行以下命令确认结果：

root@master # salt target_node pillar.get ceph:storage
root@master # salt-run disks.report

警告：DriveGroups 配置不正确

如果您的 DriveGroups 未正确配置，且您的设置中有备用磁盘，系统将按您指定的方式部署这些磁盘。我们建议运行以下命令：

root@master # salt-run disks.report

6.16.3 OSD 部署 #

对于简单的情形（例如独立的 OSD），一段时间后将会发生迁移。每当您在集群中删除或替换 OSD 时，该 OSD 便会被基于 LVM 的新 OSD 替换。

提示：迁移到 LVM 形式

一旦节点上有一个“旧版”OSD 需要替换，所有与其共享设备的 OSD 都需要迁移到基于 LVM 的形式。

为确保完整性，请考虑迁移整个节点上的 OSD。

6.16.4 更复杂的设置 #

如果您使用的是比独立 OSD 更复杂的设置，例如专用 WAL/DB 或加密 OSD，则只有当指定给该 WAL/DB 设备的所有 OSD 都被删除时，才会发生迁移。这是因为 ceph-volume 命令会在部署前在磁盘上创建逻辑卷。这样可防止用户混用基于分区的部署和基于 LV 的部署。在此情况下，最好手动删除指定给 WAL/DB 设备的所有 OSD，并使用 DriveGroups 方法重新部署它们。

打印此页

部署指南

6 从旧版本升级 #

注意：不支持从更早的版本升级

6.1 升级前需考虑的要点 #

警告：默认 DeepSea 配置

提示：与 MDS 名称绑定的自定义配置

6.2 备份集群数据 #

6.3 从 ntpd 迁移到 chronyd #

过程 6.1︰ 在升级集群前迁移到 chronyd #

提示：有关 chronyd 配置的更多详细信息

过程 6.2︰ 在升级集群后迁移到 chronyd #

提示：有关 chronyd 配置的更多详细信息

6.4 升级前对集群应用增补程序 #

6.4.1 所需的软件储存库 #

6.4.2 储存库暂存系统 #

6.4.3 对整个集群应用最新的增补程序 #

6.5 确认当前环境 #

6.6 检查集群的状态 #

6.7 CTDB 集群的脱机升级 #

6.8 按节点升级 - 基本过程 #

提示：孤立包

6.8.1 使用安装程序 DVD 手动升级节点 #

图 6.1︰ 选择迁移目标 #

6.8.2 使用 SUSE 发行套件迁移系统升级节点 #

提示：升级失败

6.9 升级管理节点 #

提示：集群节点的状态

6.10 升级 Ceph Monitor/Ceph Manager 节点 #

注意：Ceph Monitor 升级

6.11 升级元数据服务器 #

提示

6.12 升级 Ceph OSD #

提示：分别激活各数据分区

6.13 将 OSD 迁移到 BlueStore #

提示：关闭安全措施

重要

6.14 升级应用节点 #

6.15 更新 policy.cfg 并使用 DeepSea 部署 Ceph Dashboard #

重要：无新服务

提示：阶段 3 运行期间发生“subvolume missing”错误

6.16 从基于配置的部署迁移到 DriveGroups #

注意

6.16.1 分析当前布局 #

6.16.2 创建与当前布局匹配的 DriveGroups #

警告：DriveGroups 配置不正确

6.16.3 OSD 部署 #

提示：迁移到 LVM 形式

6.16.4 更复杂的设置 #

6.3 从 `ntpd` 迁移到 `chronyd` #

过程 6.1︰在升级集群前迁移到 `chronyd` #

提示：有关 `chronyd` 配置的更多详细信息

过程 6.2︰在升级集群后迁移到 `chronyd` #

提示：有关 `chronyd` 配置的更多详细信息

图 6.1︰选择迁移目标 #

6.15 更新 `policy.cfg` 并使用 DeepSea 部署 Ceph Dashboard #