10 从 SUSE Enterprise Storage 6 升级到版本 7.1 #
本章说明将 SUSE Enterprise Storage 6 升级到版本 7.1 的步骤。
升级包括以下任务：
从 Ceph Nautilus 升级到 Pacific。
从通过 RPM 软件包安装和运行 Ceph 切换到在容器中运行。
完全删除 DeepSea 并以
ceph-salt和 cephadm 替代。
本章中的升级信息仅适用于从 DeepSea 到 cephadm 的升级。如果您要在 SUSE CaaS 平台上部署 SUSE Enterprise Storage，请不要尝试按照这些说明操作。
不支持从低于 6 的 SUSE Enterprise Storage 版本升级。您需要先升级到 SUSE Enterprise Storage 6 的最新版本，然后再按照本章中所述的步骤操作。
10.1 升级前 #
开始升级之前，必须完成以下任务。在 SUSE Enterprise Storage 6 生命周期内可随时执行这些任务。
必须在升级前执行从 FileStore 到 BlueStore 的 OSD 迁移，因为 FileStore 在 SUSE Enterprise Storage 7.1 中不受支持。有关 BlueStore 以及如何从 FileStore 迁移的更多详细信息，请参见 https://documentation.suse.com/ses/6/single-html/ses-deployment/#filestore2bluestore。
如果您运行的是仍在使用
ceph-diskOSD 的旧集群，则需要在升级前切换到ceph-volume。有关详细信息，请参见https://documentation.suse.com/ses/6/single-html/ses-deployment/#upgrade-osd-deployment。
10.1.1 需考虑的要点 #
升级前，请务必通读以下内容，确保您了解所有需要执行的任务。
阅读发行说明。在发行说明中，可以找到更多有关自 SUSE Enterprise Storage 的上一个版本发行后所进行的更改的信息。检查发行说明以了解：
您的硬件是否有特殊注意事项。
所使用的任何软件包是否发生了重大更改。
是否需要对您的安装实施特殊预防措施。
发行说明还提供未能及时编入手册中的信息。它们还包含有关已知问题的说明。
您可以在 https://www.suse.com/releasenotes/ 上找到联机 SES 7.1 发行说明。
此外，安装 SES 7.1 软件源中的 release-notes-ses 软件包之后，可在本地的
/usr/share/doc/release-notes目录中或 https://www.suse.com/releasenotes/ 网页上找到发行说明。阅读第 II 部分 “部署 Ceph 集群”，熟悉
ceph-salt和 Ceph orchestrator，尤其要了解有关服务规范的信息。升级集群可能需要花很长时间 - 所需时间大约为升级一台计算机的时间乘以集群节点数。
您需要先升级 Salt 主控端，然后将 DeepSea 替换为
ceph-salt和 cephadm。至少要等到所有 Ceph Manager 节点都升级后，您才能开始使用 cephadm orchestrator 模块。从使用 Nautilus RPM 升级到使用 Pacific 容器需要一步到位。这意味着您需要一次升级整个节点，而不是一次仅升级一个守护进程。
核心服务（MON、MGR、OSD）的升级是有序进行的。每个服务在升级期间都可用。升级核心服务后需要重新部署网关服务（元数据服务器、对象网关、NFS Ganesha、iSCSI 网关）。下面每个服务都有特定的停机时间：
- 重要
元数据服务器和对象网关的停机时间自节点从 SUSE Linux Enterprise Server 15 SP1 升级到 SUSE Linux Enterprise Server 15 SP3 开始，直到升级过程结束时重新部署这些服务为止。特别是在这些服务与 MON、MGR 或 OSD 共置时更要考虑到这一点，因为它们可能会在整个集群升级过程中都处于停用状态。如果这对您是个问题，请考虑在升级前在另外的节点上分别部署这些服务，以尽可能缩短它们处于停用状态的时间。如此，停机时间便将是网关节点升级的持续时间，而不是整个集群升级的持续时间。
从 SUSE Linux Enterprise Server 15 SP1 升级到 SUSE Linux Enterprise Server 15 SP3 期间，NFS Ganesha 和 iSCSI 网关仅会在节点重引导时处于停用状态，并会在以容器化模式重新部署每个服务时再次短暂处于停用状态。
10.1.2 备份集群配置和数据 #
强烈建议您在开始升级到 SUSE Enterprise Storage 7.1 之前备份所有集群配置和数据。有关如何备份所有数据的说明，请参见 https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup。
10.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 行。
10.1.4 更新集群节点并确认集群健康状况 #
确认 SUSE Linux Enterprise Server 15 SP1和 SUSE Enterprise Storage 6 的所有最新更新是否已应用到所有集群节点：
# zypper refresh && zypper patch
有关更新集群节点的详细信息，请参见 https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates。
应用更新后，重启动 Salt 主控端，同步新 Salt 模块，然后检查集群健康状况：
root@master #systemctl restart salt-master.serviceroot@master #salt '*' saltutil.sync_allcephuser@adm >ceph -s
10.1.4.1 禁用不安全的客户端 #
从 Nautilus v14.2.20 起，引入了新的健康状况警告来告知您允许了不安全的客户端加入集群。此警告默认会打开。Ceph Dashboard 会表明集群处于 HEALTH_WARN 状态。命令行会按如下所示校验集群状态：
cephuser@adm > ceph status
cluster:
id: 3fe8b35a-689f-4970-819d-0e6b11f6707c
health: HEALTH_WARN
mons are allowing insecure global_id reclaim
[...]此警告表示 Ceph Monitor 仍在允许未增补的旧版客户端连接集群。这样可确保在升级集群时，现有客户端仍可连接集群，但会警告您存在需要解决的问题。当集群和所有客户端都升级到最新版本的 Ceph 后，运行以下命令禁用未增补的客户端：
cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false10.1.5 确认对软件源和容器映像的访问权限 #
确认是否每个集群节点都能访问 SUSE Linux Enterprise Server 15 SP3 和 SUSE Enterprise Storage 7.1 软件源以及容器映像注册表。
10.1.5.1 软件源 #
如果所有节点都已在 SCC 中注册，您便可以使用 zypper migration 命令进行升级。有关更多详细信息，请参见 https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper。
如果节点未在 SCC 中注册，请禁用所有现有软件源，并为以下每个扩展添加 Pool 和 Updates 软件源：
SLE-Product-SLES/15-SP3
SLE-Module-Basesystem/15-SP3
SLE-Module-Server-Applications/15-SP3
SUSE-Enterprise-Storage-7.1
10.1.5.2 容器映像 #
所有集群节点都需要访问容器映像注册表。在大多数情况下，您将使用 registry.suse.com 上的公共 SUSE 注册表。您需要以下映像：
registry.suse.com/ses/7.1/ceph/ceph
registry.suse.com/ses/7.1/ceph/grafana
registry.suse.com/ses/7.1/ceph/prometheus-server
registry.suse.com/ses/7.1/ceph/prometheus-node-exporter
registry.suse.com/ses/7.1/ceph/prometheus-alertmanager
或者，例如对于实体隔离部署，请配置本地注册表并确认您是否有一组正确的容器映像可用。有关配置本地容器映像注册表的更多详细信息，请参见第 7.2.10 节 “使用容器注册表”。
10.2 升级 Salt 主控端 #
以下过程描述了升级 Salt 主控端的过程：
将底层操作系统升级到 SUSE Linux Enterprise Server 15 SP3：
对于所有节点都已在 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
如果您需要为注册表指定身份验证信息，请添加
ses7_container_registry_auth:块，例如：ses7_container_image: 192.168.121.1:5000/my/ceph/image ses7_container_registries: - location: 192.168.121.1:5000 ses7_container_registry_auth: registry: 192.168.121.1:5000 username: USER_NAME password: PASSWORD
保存文件并应用更改：
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 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable) os: SUSE Linux Enterprise Server 15 SP3 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)
10.3 升级 MON、MGR 和 OSD 节点 #
每次升级一个 Ceph Monitor、Ceph Manager 和 OSD 节点。对于每个服务，请执行以下步骤：
采用任何 OSD 节点之前，需要执行 OSD 节点的格式转换以改进 OMAP 数据的核算。您可以通过在管理节点上运行以下命令来执行此操作：
cephuser@adm >ceph config set osd bluestore_fsck_quick_fix_on_mount trueOSD 节点将会在采用过程完成后自动进行转换。
注意转换所需的时间可能从数分钟到数小时不等，具体时长取决于相关硬盘包含的 OMAP 数据量。有关详细信息，请参考 https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clusters。
如果您要升级的是 OSD 节点，请通过运行以下命令避免在升级过程中将 OSD 标记为
out：cephuser@adm >ceph osd add-noout SHORT_NODE_NAME将 SHORT_NODE_NAME 替换为
ceph osd tree命令输出中显示的节点的简短名称。在以下输入中，主机简短名称为ses-min1和ses-min2root@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 SP3：
如果集群的节点都已在 SCC 中注册，请运行
zypper migration。如果集群的节点具有手动指定的软件源，请运行
zypper dup，然后再运行reboot。
重引导节点后，通过在 Salt 主控端上运行以下命令，将该节点上所有现有 MON、MGR 和 OSD 守护进程进行容器化：
root@master #salt MINION_ID state.apply ceph.upgrade.ses7.adopt将 MINION_ID 替换为您要升级的受控端的 ID。您可以通过在 Salt 主控端上运行
salt-key -L命令来获取受控端 ID 的列表。提示要查看采用的状态和进度，请检查 Ceph Dashboard 或在 Salt 主控端上运行下面其中一个命令：
root@master #ceph statusroot@master #ceph versionsroot@master #salt-run upgrade.status成功完成采用后，如果您要升级的节点是 OSD 节点，请取消设置
noout标志：cephuser@adm >ceph osd rm-noout SHORT_NODE_NAME
10.4 升级网关节点 #
接下来，需升级各个网关节点（Samba 网关、元数据服务器、对象网关、NFS Ganesha 或 iSCSI 网关）。针对每个节点将底层操作系统升级到 SUSE Linux Enterprise Server 15 SP3：
如果集群的节点都已在 SUSE Customer Center 中注册，请运行
zypper migration命令。如果集群的节点具有手动指定的软件源，请运行
zypper dup，然后再运行reboot命令。
此步骤也适用于属于集群但尚未指定任何角色的任何节点（如有疑问，请查看通过 salt-key -L 命令提供的 Salt 主控端上的主机列表，并将其与 salt-run upgrade.status 命令的输出进行比较）。
升级集群中所有节点上的操作系统后，下一步是安装 ceph-salt 软件包并应用集群配置。升级过程结束时，会以容器化模式重新部署实际的网关服务。
从升级到 SUSE Linux Enterprise Server 15 SP3 开始，直至升级过程结束时重新部署元数据服务器和对象网关服务为止，这段期间这些服务将不可用。
10.5 安装 ceph-salt 并应用集群配置 #
在开始安装 ceph-salt 并应用集群配置这一过程前，请先通过运行以下命令查看集群和升级状态：
root@master #ceph statusroot@master #ceph versionsroot@master #salt-run upgrade.status
删除 DeepSea 创建的
rbd_exporter和rgw_exporter定时任务 (cron job)。在 Salt 主控端上，以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.jsonroot@master #salt-run upgrade.generate_service_specs > specs.yaml卸装 DeepSea，并在 Salt 主控端上安装
ceph-salt：root@master #zypper remove 'deepsea*'root@master #zypper install ceph-salt重启动 Salt 主控端并同步 Salt 模块：
root@master #systemctl restart salt-master.serviceroot@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有关集群配置的完整描述，请参见第 7.2 节 “配置集群属性”。
应用配置并启用 cephadm：
root@master #ceph-salt apply如果您需要提供本地容器注册表 URL 和访问身份凭证，请按照第 7.2.10 节 “使用容器注册表”中所述的步骤操作。
如果您使用的不是
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-crashroot@master #salt '*' service.disable ceph-crash
10.6 升级并采用监控堆栈 #
以下过程会采用监控堆栈的所有组件（有关更多详细信息，请参见第 16 章 “监控和告警”）。
暂停 orchestrator：
cephuser@adm >ceph orch pause在运行 Prometheus、Grafana 和告警管理器（默认为 Salt 主控端）的节点上，运行以下命令：
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/ses/7.1/ceph/prometheus-server:2.32.1 \ adopt --style=legacy --name prometheus.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \ adopt --style=legacy --name alertmanager.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \ adopt --style=legacy --name grafana.$(hostname)第 16.1 节 “配置自定义或本地映像”中列出了需要的容器映像及相应版本。
从所有节点中删除 Node-ExporterNode-Exporter 不需要迁移，将在应用
specs.yaml文件时作为容器重新安装。>sudozypper rm golang-github-prometheus-node_exporter或者，您可以在管理节点上使用 Salt 同时从所有节点中删除 Node-Exporter：
root@master #salt '*' pkg.remove golang-github-prometheus-node_exporter应用您之前从 DeepSea 导出的服务规范：
cephuser@adm >ceph orch apply -i specs.yaml提示如果您运行的不是默认容器映像注册表
registry.suse.com，而是本地容器注册表，请在部署 Node-Exporter 前对 cephadm 进行配置，以便为 Node-Exporter 部署使用本地注册表中的容器映像。否则，您可以放心跳过此步骤并忽略以下警告：cephuser@adm >ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATH确保监控服务的所有容器映像都指向本地注册表，而不仅仅是 Node-Exporter 的映像。此步骤只要求您对 Node-Exporter 执行此操作，但建议您此时在 cephadm 中将所有监控容器映像都设置为指向本地注册表。
如果您未这样做，监控服务的新部署以及重新部署过程将使用默认的 cephadm 配置，您最终可能无法部署服务（如果是实体隔离部署），或者最终会部署混合版本的服务。
第 16.1 节 “配置自定义或本地映像”中介绍了需如何配置 cephadm 以使用本地注册表中的容器映像。
继续 orchestrator：
cephuser@adm >ceph orch resume
10.7 重新部署网关服务 #
10.7.1 升级对象网关 #
在 SUSE Enterprise Storage 7.1 中，对象网关始终配置有一个领域，以为未来使用多站点提供支持（有关更多详细信息，请参见第 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_NAMEcephuser@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 --rgw-zone=ZONE_NAME。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
要将对象网关服务容器化，请按第 8.3.4 节 “部署对象网关”中所述创建其规范文件，然后应用该文件。
cephuser@adm > ceph orch apply -i RGW.yml10.7.2 升级 NFS Ganesha #
NFS Ganesha 支持 NFS 4.1 和更高版本，不支持 NFS 3 版本。
下面演示如何将运行 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; donecephuser@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-ganeshacephuser@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
有关创建归置规范的详细信息，请参见第 8.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.1/ceph/ceph:latest 8b4be7c42abd c8b75d7c8f0d针对每个 NFS Ganesha 节点重复上述步骤。您不需要为每个节点创建单独的服务规范。您只需将每个节点的主机名添加到现有 NFS 服务规范中，然后重新应用该规范。
现有的导出可以通过两种方法进行迁移：
使用 Ceph Dashboard 手动重新创建或重新指定。
手动将每个守护进程 RADOS 对象的内容复制到新创建的 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; donecephuser@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_IDcephuser@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
10.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 守护进程的主机，如第 8.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 守护进程。
10.7.4 升级 iSCSI 网关 #
要升级 iSCSI 网关，您需要使用 Ceph orchestrator 在容器中重新部署该网关。如果您有多个 iSCSI 网关，则需要逐个重新部署，以减少服务停机时间。
停止并禁用每个 iSCSI 网关节点上的现有 iSCSI 守护进程：
>sudosystemctl stop rbd-target-gw>sudosystemctl disable rbd-target-gw>sudosystemctl stop rbd-target-api>sudosystemctl disable rbd-target-api按第 8.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
10.8 升级后清理 #
升级后，请执行以下清理步骤：
通过检查当前的 Ceph 版本，确认集群是否已成功升级：
cephuser@adm >ceph versions确保没有旧的 OSD 加入集群：
cephuser@adm >ceph osd require-osd-release pacific根据需要设置现有存储池的
pg_autoscale_mode：重要默认情况下，在 SUSE Enterprise Storage 6 中存储池的
pg_autoscale_mode设置为warn。这会导致在 PG 数量未达到最佳时出现警报消息，但实际上并未发生自动扩展。在 SUSE Enterprise Storage 7.1 中，新存储池的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 upmapcephuser@adm >ceph balancer on有关详细信息，请参见第 29.1 节 “平衡器”。
（可选）启用遥测模块：
cephuser@adm >ceph mgr module enable telemetrycephuser@adm >ceph telemetry on有关详细信息，请参见第 29.2 节 “启用遥测模块”。