适用范围 SUSE Enterprise Storage 7

7 从先前的版本升级 #

本章说明将 SUSE Enterprise Storage 6 升级到版本 7 的步骤。

升级包括以下任务：

从 Ceph Nautilus 升级到 Octopus。
从通过 RPM 包安装和运行 Ceph 切换到在容器中运行。
完全删除 DeepSea 并以 ceph-salt 和 cephadm 替代。

警告

本章中的升级信息仅适用于从 DeepSea 到 cephadm 的升级。如果您要在 SUSE CaaS 平台上部署 SUSE Enterprise Storage，请不要尝试遵循这些说明。

重要

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

7.1 升级前 #

开始升级之前，必须完成以下任务。在 SUSE Enterprise Storage 6 生命周期内可随时执行这些操作。

必须在升级前执行从 FileStore 到 BlueStore 的 OSD 迁移，因为 FileStore 在 SUSE Enterprise Storage 7 中不受支持。有关 BlueStore 以及如何从 FileStore 迁移的更多详细信息，请参见 https://documentation.suse.com/ses/6/html/ses-all/cha-ceph-upgrade.html#filestore2bluestore。
如果您运行的是仍在使用 ceph-disk OSD 的旧集群，则需要在升级前切换到 ceph-volume。有关详细信息，请参见https://documentation.suse.com/ses/6/html/ses-all/cha-ceph-upgrade.html#upgrade-osd-deployment。

7.1.1 需考虑的要点 #

升级前，请务必通读以下内容，确保您了解所有需要执行的任务。

阅读发行说明 - 发行说明提供了有关自 SUSE Enterprise Storage 上一个版本发行后所进行的更改的其他信息。检查发行说明以了解：
- 您的硬件是否有特殊注意事项。
- 所使用的任何软件包是否发生了重大更改。
- 是否需要对您的安装实施特殊预防措施。
发行说明还提供未能及时编入手册中的信息。它们还包含有关已知问题的说明。
您可以在 https://www.suse.com/releasenotes/ 上找到联机 SES 7 发行说明。
此外，安装 SES 7 储存库中的 release-notes-ses 包之后，可在 /usr/share/doc/release-notes 目录中找到本地发行说明，或在 https://www.suse.com/releasenotes/ 上找到联机发行说明。
阅读第 5 章 “使用 cephadm 进行部署”，熟悉 ceph-salt 和 Ceph orchestrator，尤其要了解有关服务规范的信息。
升级集群可能需要花很长时间 - 所需时间大约为升级一台计算机的时间乘以集群节点数。
您需要先升级 Salt Master，然后将 DeepSea 替换为 ceph-salt 和 cephadm。至少要等到所有 Ceph Manager 都升级后，您才能开始使用 cephadm orchestrator 模块。
从使用 Nautilus RPM 到 Octopus 容器的升级需要一步到位。这意味着您需要一次升级整个节点，而不是一次仅升级一个守护进程。
核心服务（MON、MGR、OSD）的升级是有序进行的。每个服务在升级期间都可用。升级核心服务后需要重新部署网关服务（元数据服务器、对象网关、NFS Ganesha、iSCSI 网关）。下面每个服务都有特定的停机时间：
- 重要
  元数据服务器和对象网关的停机时间自节点从 SUSE Linux Enterprise Server 15 SP1 升级到 SUSE Linux Enterprise Server 15 SP2 开始，直到升级过程结束时重新部署这些服务为止。如果这些服务与 MON、MGR 或 OSD 并置，则尤其要考虑到这一点，因为在这种情况下，它们可能会在集群升级的整个过程中处于停机状态。如果这对您是个问题，请考虑在升级之前于其他节点上分别部署这些服务，以尽可能缩短它们的停机时间。如此，停机时间便将是网关节点升级的持续时间，而不是整个集群升级的持续时间。
- NFS Ganesha 和 iSCSI 网关仅在从 SUSE Linux Enterprise Server 15 SP1 升级到 SUSE Linux Enterprise Server 15 SP2 期间重引导节点时处于停机状态，并会在以容器化模式重新部署每个服务时再次短暂处于停机状态。

7.1.2 备份集群配置和数据 #

强烈建议您在开始升级到 SUSE Enterprise Storage 7 之前备份所有集群配置和数据。有关如何备份所有数据的说明，请参见 https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html。

7.1.3 确认先前升级的步骤 #

如果您先前是从版本 5 升级的，请确认升级到版本 6 的过程已成功完成：

检查 /srv/salt/ceph/configuration/files/ceph.conf.import 文件是否存在。

此文件是在从 SUSE Enterprise Storage 5 升级到 6 期间由 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/ 中的其中一个文件中。

然后从 /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml 中删除 configuration_init: default-import 行。

7.1.4 更新集群节点并确认集群健康状况 #

确认 SUSE Linux Enterprise Server 15 SP1和 SUSE Enterprise Storage 6 的所有最新更新是否已应用到所有集群节点：

root # zypper refresh && zypper patch

应用更新后，请检查集群健康状况：

cephuser@adm > ceph -s

7.1.5 确认对软件储存库和容器映像的访问权限 #

确认每个集群节点是否拥有对 SUSE Linux Enterprise Server 15 SP2 和 SUSE Enterprise Storage 7 软件储存库以及容器映像注册表的访问权限。

7.1.5.1 软件储存库 #

如果所有节点都已在 SCC 中注册，您便可以使用 zypper migration 命令进行升级。有关更多详细信息，请参见 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper。

如果节点未在 SCC 中注册，请禁用所有现有软件储存库，并为以下每个扩展添加 Pool 和 Updates 储存库：

SLE-Product-SLES/15-SP2
SLE-Module-Basesystem/15-SP2
SLE-Module-Server-Applications/15-SP2
SUSE-Enterprise-Storage-7

7.1.5.2 容器映像 #

所有集群节点都需要访问容器映像注册表。在大多数情况下，您将使用 registry.suse.com 上的公共 SUSE 注册表。您需要以下映像：

registry.suse.com/ses/7/ceph/ceph
registry.suse.com/ses/7/ceph/grafana
registry.suse.com/caasp/v4.5/prometheus-server
registry.suse.com/caasp/v4.5/prometheus-node-exporter
registry.suse.com/caasp/v4.5/prometheus-alertmanager

或者，例如对于实体隔离部署，请配置本地注册表并确认您是否有一组正确的容器映像可用。有关配置本地容器映像注册表的更多详细信息，请参见第 5.3.2.11 节 “配置容器注册表”。

7.2 升级 Salt Master #

以下过程描述了升级 Salt Master 的过程：

将底层操作系统升级到 SUSE Linux Enterprise Server 15 SP2：
- 对于所有节点都已在 SCC 中注册的集群，请运行 zypper migration。
- 对于节点具有手动指定软件储存库的集群，请运行 zypper dup，然后再运行 reboot。

禁用 DeepSea 阶段以避免意外使用。将以下内容添加到 /srv/pillar/ceph/stack/global.yml：

stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

保存文件并应用更改：

root@master # salt '*' saltutil.pillar_refresh

如果您未使用 registry.suse.com 中的容器映像，而是使用本地配置的注册表，请编辑 /srv/pillar/ceph/stack/global.yml 以告知 DeepSea 要使用哪个 Ceph 容器映像和注册表。例如，要使用 192.168.121.1:5000/my/ceph/image，请添加下面几行：
```
ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
```
保存文件并应用更改：
```
root@master # salt '*' saltutil.refresh_pillar
```

同化现有配置：

cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

确认升级状态。您的输出可能因集群配置而异：

root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable)
 os: SUSE Linux Enterprise Server 15 SP2
Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)
Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

7.3 升级 MON、MGR 和 OSD 节点 #

每次升级一个 Ceph Monitor、Ceph Manager 和 OSD 节点。对于每个服务，请执行以下步骤：

如果您要升级的是 OSD 节点，请通过运行以下命令避免在升级过程中将 OSD 标记为 out：

cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

将 SHORT_NODE_NAME 替换为 ceph osd tree 命令输出中显示的节点的简短名称。在以下输入中，主机简短名称为 ses-min1 和 ses-min2

root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

将底层操作系统升级到 SUSE Linux Enterprise Server 15 SP2：
- 如果集群的节点都已在 SCC 中注册，请运行 zypper migration。
- 如果集群的节点具有手动指定的软件储存库，请运行 zypper dup，然后再运行 reboot。
重引导节点后，通过在 Salt Master 上运行以下命令，将该节点上所有现有 MON、MGR 和 OSD 守护进程进行容器化：
```
root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt
```
将 MINION_ID 替换为您要升级的 Minion 的 ID。您可以通过在 Salt Master 上运行 salt-key -L 命令来获取 Minion ID 的列表。
提示
要查看采用的状态和进度，请检查 Ceph Dashboard 或在 Salt Master 上运行下面其中一个命令：
```
root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status
```
成功完成采用后，如果您要升级的节点是 OSD 节点，请取消设置 noout 标志：
```
cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME
```

7.4 升级网关节点 #

接下来，请升级各网关节点（元数据服务器、对象网关、NFS Ganesha 或 iSCSI 网关）。针对每个节点将底层操作系统升级到 SUSE Linux Enterprise Server 15 SP2：

如果集群的节点都已在 SUSE Customer Center 中注册，请运行 zypper migration 命令。
如果集群的节点具有手动指定的软件储存库，请运行 zypper dup，然后再运行 reboot 命令。

此步骤也适用于属于集群但尚未指定任何角色的任何节点（如有疑问，请查看通过 salt-key -L 命令提供的 Salt Master 上的主机列表，并将其与 salt-run upgrade.status 命令的输出进行比较）。

升级集群中所有节点上的操作系统后，下一步是安装 ceph-salt 包并应用集群配置。升级过程结束时，会以容器化模式重新部署实际的网关服务。

注意

从升级到 SUSE Linux Enterprise Server 15 SP2 开始，直至升级过程结束时重新部署元数据服务器和对象网关服务为止，这段期间这些服务将不可用。

7.5 安装 `ceph-salt` 并应用集群配置 #

在开始安装 ceph-salt 并应用集群配置这一过程前，请先通过运行以下命令查看集群和升级状态：

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

删除 DeepSea 创建的 rbd_exporter 和 rgw_exporter 定时任务 (cron job)。在 Salt Master 上，以 root 身份运行 crontab -e 命令以编辑 crontab。删除下列项目（如果存在）：

# SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

通过运行以下命令从 DeepSea 导出集群配置：

root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

卸装 DeepSea，并在 Salt Master 上安装 ceph-salt：

root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

重启动 Salt Master 并同步 Salt 模块：

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

将 DeepSea 的集群配置导入 ceph-salt：

root@master # ceph-salt import ceph-salt-config.json

为集群节点通讯生成 SSH 密钥：
```
root@master # ceph-salt config /ssh generate
```
提示
确认是否已从 DeepSea 导入集群配置，并指定可能缺失的选项：
```
root@master # ceph-salt config ls
```
有关集群配置的完整描述，请参见第 5.3.2 节 “配置集群属性”。
应用配置并启用 cephadm：
```
root@master # ceph-salt apply
```
如果您需要提供本地容器注册表 URL 和访问身份凭证，请按照第 5.3.2.11 节 “配置容器注册表”中所述的步骤操作。
如果您未使用 registry.suse.com 中的容器映像，而是使用本地配置的注册表，请运行以下命令告知 Ceph 要使用的容器映像
```
root@master # ceph config set global container_image IMAGE_NAME
```
例如：
```
root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
```
停止并禁用 SUSE Enterprise Storage 6 ceph-crash 守护进程。将于稍后自动启动这些守护进程的新容器化格式。
```
root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash
```

7.6 升级并采用监控堆栈 #

以下过程会采用监控堆栈的所有组件（有关更多详细信息，请参见第 16 章 “监控和告警”）。

暂停 orchestrator：
```
cephuser@adm > ceph orch pause
```

在运行 Prometheus、Grafana 和告警管理器（默认为 Salt Master）的节点上，运行以下命令：

cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)

提示

如果您未运行默认容器映像注册表 registry.suse.com，则需要指定要使用的映像，例如：

cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \
 adopt --style=legacy --name grafana.$(hostname)

有关使用自定义或本地容器映像的更多详细信息，请参见第 16.1 节 “配置自定义或本地映像”。

删除 Node-Exporter。它不需要进行迁移，将在应用 specs.yaml 文件时作为容器重新安装。
```
tux > sudo zypper rm golang-github-prometheus-node_exporter
```
应用您之前从 DeepSea 导出的服务规范：
```
cephuser@adm > ceph orch apply -i specs.yaml
```
继续 orchestrator：
```
cephuser@adm > ceph orch resume
```

7.7 重新部署网关服务 #

7.7.1 升级对象网关 #

在 SUSE Enterprise Storage 7 中，对象网关始终配置有一个领域，以为未来使用多站点提供支持（有关更多详细信息，请参见第 21.13 节 “多站点对象网关”）。如果您在 SUSE Enterprise Storage 6 中使用了单站点对象网关配置，请按照以下步骤添加领域。如果您实际上并不打算使用多站点功能，则可以为领域、区域组和区域名称使用 default 值。

创建新领域：

cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

（可选）重命名默认区域和区域组。

cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

配置主区域组：

cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

配置主区域。为此，您将需要启用了 system 标志的对象网关用户的 ACCESS_KEY 和 SECRET_KEY。这通常是 admin 用户。要获取 ACCESS_KEY 和 SECRET_KEY，请运行 radosgw-admin user info --uid admin。

cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default

提交更新后的配置：

cephuser@adm > radosgw-admin period update --commit

要将对象网关服务容器化，请按第 5.4.3.4 节 “部署对象网关”中所述创建其规范文件，然后应用该文件。

cephuser@adm > ceph orch apply -i RGW.yml

7.7.2 升级 NFS Ganesha #

下面演示如何将运行 Ceph Nautilus 的现有 NFS Ganesha 服务迁移到运行 Ceph Octopus 的 NFS Ganesha 容器。

警告

以下文档要求您已成功升级了核心 Ceph 服务。

NFS Ganesha 会在 RADOS 存储池中存储额外的守护进程特定配置并导出配置。所配置的 RADOS 存储池可在 ganesha.conf 文件的 RADOS_URLS 块的 watch_url 行上找到。默认情况下，此存储池将重命名为 ganesha_config

在尝试任何迁移之前，强烈建议您复制 RADOS 存储池中的导出和守护进程配置对象。要查找所配置的 RADOS 存储池，请运行以下命令：

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

列出 RADOS 存储池的内容：

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

复制 RADOS 对象：

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

基于每个节点，停止现有的 NFS Ganesha 服务，然后将其替换为由 cephadm 管理的容器。

停止并禁用现有的 NFS Ganesha 服务：

cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

停止现有的 NFS Ganesha 服务之后，可以使用 cephadm 在容器中部署一个新的服务。为此，您需要创建一个服务规范，其中包含将用于标识此新 NFS 集群的 service_id、在归置规范中作为主机列出的所要迁移节点的主机名，以及包含所配置 NFS 导出对象的 RADOS 存储池和名称空间。例如：
```
service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha
```
有关创建归置规范的详细信息，请参见第 5.4.2 节 “服务和归置规范”。

应用归置规范：

cephuser@adm > ceph orch apply -i FILENAME.yaml

确认主机上是否运行有 NFS Ganesha 守护进程：

cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

针对每个 NFS Ganesha 节点重复上述步骤。您不需要为每个节点创建单独的服务规范。您只需将每个节点的主机名添加到现有 NFS 服务规范中，然后重新应用该规范。

现有的导出可以通过两种方法进行迁移：

使用 Ceph Dashboard 手动重新创建或重新指定。
手动将每个守护进程 RADOS 对象的内容复制到新创建的 NFS Ganesha 通用配置中。

过程 7.1︰手动将导出复制到 NFS Ganesha 通用配置文件 #

确定每个守护进程 RADOS 对象的列表：

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

复制每个守护进程的 RADOS 对象：

cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

排序并合并到单个导出列表中：

cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

写入新的 NFS Ganesha 通用配置文件：

cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

通知 NFS Ganesha 守护进程：
```
cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
```
注意
此操作将导致守护进程重新加载配置。

成功迁移服务后，可以删除基于 Nautilus 的 NFS Ganesha 服务。

删除 NFS Ganesha：

cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

从 Ceph Dashboard 中删除旧的集群设置：

cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

7.7.3 升级元数据服务器 #

与 MON、MGR 和 OSD 不同，无法就地采用元数据服务器。您需要使用 Ceph orchestrator 在容器中进行重新部署。

运行 ceph fs ls 命令以获取您文件系统的名称，例如：

cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

通过使用文件系统名称作为 service_id，并指定将要运行 MDS 守护进程的主机，如第 5.4.3.3 节 “部署元数据服务器”中所述创建新服务规范文件 mds.yml。例如：
```
service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
```
运行 ceph orch apply -i mds.yml 命令以应用服务规范并启动 MDS 守护进程。

7.7.4 升级 iSCSI 网关 #

要升级 iSCSI 网关，您需要使用 Ceph orchestrator 在容器中重新部署该网关。如果您有多个 iSCSI 网关，则需要逐个重新部署，以减少服务停机时间。

停止并禁用每个 iSCSI 网关节点上的现有 iSCSI 守护进程：

tux > sudo systemctl stop rbd-target-gw
tux > sudo systemctl disable rbd-target-gw
tux > sudo systemctl stop rbd-target-api
tux > sudo systemctl disable rbd-target-api

按第 5.4.3.5 节 “部署 iSCSI 网关”中所述，为 iSCSI 网关创建服务规范。为此，您需要现有 /etc/ceph/iscsi-gateway.cfg 文件中的 pool、trusted_ip_list 和 api_* 设置。如果您启用了 SSL 支持 (api_secure = true)，则还需要 SSL 证书 (/etc/ceph/iscsi-gateway.crt) 和密钥 (/etc/ceph/iscsi-gateway.key)。

例如，如果 /etc/ceph/iscsi-gateway.cfg 包含以下配置：

[config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true

则您需要创建以下服务规范文件 iscsi.yml：

service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

注意

pool、trusted_ip_list、api_port、api_user、api_password、api_secure 设置与 /etc/ceph/iscsi-gateway.cfg 文件中的相应设置相同。可从现有 SSL 证书和密钥文件中复制 ssl_cert 和 ssl_key 值。确认这些值是否缩进正确，并且 ssl_cert: 和 ssl_key: 行的末尾是否显示有竖线字符 |（请参见上述 iscsi.yml 文件的内容）。

运行 ceph orch apply -i iscsi.yml 命令以应用服务规范并启动 iSCSI 网关守护进程。
从每个现有 iSCSI 网关节点中删除旧的 ceph-iscsi 包：
```
cephuser@adm > zypper rm -u ceph-iscsi
```

7.8 升级后清理 #

升级后，请执行以下清理步骤：

通过检查当前的 Ceph 版本，确认集群是否已成功升级：
```
cephuser@adm > ceph versions
```

确保没有旧的 OSD 加入集群：

cephuser@adm > ceph osd require-osd-release octopus

启用自动扩展器模块：
```
cephuser@adm > ceph mgr module enable pg_autoscaler
```
重要
默认情况下，在 SUSE Enterprise Storage 6 中存储池的 pg_autoscale_mode 设置为 warn。这会导致在 PG 数量未达到最佳时出现警报讯息，但实际上并未发生自动扩展。在 SUSE Enterprise Storage 7 中，新存储池的 pg_autoscale_mode 选项默认设为 on，因此实际上会自动扩展 PG。而升级过程并不会自动更改现有存储池的 pg_autoscale_mode。如果您要将其更改为 on 以充分利用自动扩展器的功能，请参见第 17.4.12 节 “启用 PG 自动扩展器”中的说明。
有关详细信息，请参见第 17.4.12 节 “启用 PG 自动扩展器”。

阻止早于 Luminous 版本的客户端：

cephuser@adm > ceph osd set-require-min-compat-client luminous

启用平衡器模块：
```
cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on
```
有关详细信息，请参见第 29.1 节 “平衡器”。
（可选）启用遥测模块：
```
cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on
```
有关详细信息，请参见第 29.2 节 “启用遥测模块”。

7 从先前的版本升级 #

7.1 升级前 #

7.1.1 需考虑的要点 #

7.1.2 备份集群配置和数据 #

7.1.3 确认先前升级的步骤 #

7.1.4 更新集群节点并确认集群健康状况 #

7.1.5 确认对软件储存库和容器映像的访问权限 #

7.1.5.1 软件储存库 #

7.1.5.2 容器映像 #

7.2 升级 Salt Master #

7.3 升级 MON、MGR 和 OSD 节点 #

7.4 升级网关节点 #

7.5 安装 ceph-salt 并应用集群配置 #

7.6 升级并采用监控堆栈 #

7.7 重新部署网关服务 #

7.7.1 升级对象网关 #

7.7.2 升级 NFS Ganesha #

7.7.3 升级元数据服务器 #

7.7.4 升级 iSCSI 网关 #

7.8 升级后清理 #

7.5 安装 `ceph-salt` 并应用集群配置 #