本章介绍将 SUSE Enterprise Storage 从旧版本升级到最新版本的步骤。
在发行说明中,可以找到有关自 SUSE Enterprise Storage 的上一个版本发行后所进行的更改的其他信息。检查发行说明以了解:
您的硬件是否有特殊的注意事项。
所用的任何软件包是否已发生重大更改。
是否需要对您的安装实施特殊预防措施。
发行说明还提供未能及时编入手册中的信息。它们还包含有关已知问题的说明。
安装包 release-notes-ses 之后,可在本地的 /usr/share/doc/release-notes
目录中或 https://www.suse.com/releasenotes/ 网页上找到发行说明。
开始升级过程之前,请考虑以下几项:
在升级 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 时,会自动设置此标识,因此最终用户无需执行任何操作。
从 SUSE Enterprise Storage 5 开始,默认会使用 BlueStore 而非 FileStore 来部署 OSD。虽然 BlueStore 支持加密,但默认以非加密模式部署 Ceph OSD。下面的过程介绍了在升级过程中加密 OSD 的步骤。我们假设部署 OSD 时使用的数据和 WAL/DB 磁盘都是干净的,且没有分区。如果磁盘曾经使用,请执行步骤 13中所述的过程进行擦除。
您需要逐个部署加密的 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.2root@master #
salt-run state.orch ceph.stage.3
您可以运行 ceph -s
或 ceph osd tree
来监控进度。在下一个 OSD 节点上重复该过程前,请务必使集群重新平衡。
您需要在要升级的所有 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 的情况下,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(请参见本节开头的重要:软件要求)。在开始升级过程之前,必须满足此先决条件。
如果已将系统注册到 SUSEConnect 并使用 SCC/SMT,则不需要执行进一步的操作。继续 步骤 4。
如果您使用的不是 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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
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 暂时还未安装。要让集群保持正常状态,请执行以下操作:
运行阶段 0 以启用 Salt REST API:
root@master #
salt-run state.orch ceph.stage.0
运行阶段 1 以创建 role-mgr/
子目录:
root@master #
salt-run state.orch ceph.stage.1
根据第 4.5.1 节 “policy.cfg
文件”中所述编辑 ,并将一个 Ceph Manager 角色添加到部署了 Ceph Monitor 的节点。此外,请为集群的某个节点添加 openATTIC 角色。有关更多详细信息,请参见第 15 章 “openATTIC”。
运行阶段 2 以更新 Pillar:
root@master #
salt-run state.orch ceph.stage.2
DeepSea 现在用另一种方法来生成 ceph.conf
配置文件,有关更多详细信息,请参见第 1.11 节 “自定义 ceph.conf
文件”。
运行阶段 3 以部署 Ceph Manager:
root@master #
salt-run state.orch ceph.stage.3
运行阶段 4 以正确配置 openATTIC:
root@master #
salt-run state.orch ceph.stage.4
如果 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 秒,则表示升级失败。在这种情况下,请尝试找出并解决问题,然后重新运行升级过程。请注意,在虚拟化环境中,超时会更短。
升级到 SUSE Enterprise Storage 5 之后,FileStore OSD 启动所需的时间大约会多五分钟,因为 OSD 将对其磁盘中的文件执行一次性转换。
如果您需要确定单个集群组件和节点的版本(例如,确定所有节点在升级后是否真正处于相同的增补程序级别),可以运行
root@master #
salt-run status.report
该命令将会遍历所有连接的 Salt Minion,并扫描 Ceph、Salt 和 SUSE Linux Enterprise Server 的版本号,最后提供一份报告,其中会列出大多数节点的版本,并显示其版本与大多数节点不相同的节点。
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
。
要逐个迁移 OSD,请运行:
root@master #
salt-run state.orch ceph.migrate.osds
要同时迁移每个节点上的所有 OSD,请运行:
root@master #
salt-run state.orch ceph.migrate.nodes
编制进程不提供有关迁移进度的反馈,您可以使用
root #
ceph osd tree
定期查看哪些 OSD 的权重为 0。
迁移到 BlueStore 之后,对象计数将保持不变,磁盘使用率也几乎相同。
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,请执行以下步骤:
安装 SLE-12-SP2/SES4 中的 salt
包:
root #
zypper install salt
安装 SLE-12-SP2/SES4 中的 salt-minion
包,然后启用并启动相关的服务:
root #
zypper install salt-minionroot #
systemctl enable salt-minionroot #
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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
zypper ref
运行以下命令设置新的内部对象排序顺序:
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-masterroot@master #
systemctl enable salt-masterroot@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 网关,请手动导入其配置:
在其中一个 iSCSI 网关节点上,导出当前的 lrbd.conf
,然后将其复制到 Salt Master 节点:
root@minion >
lrbd -o >/tmp/lrbd.confroot@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.ymlroot@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 以创建所有可能的角色:
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”中所述的过程。
您需要在要升级的所有 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-clientroot@minion >
sudo systemctl disable chef-clientroot@minion >
sudo systemctl disable crowbar_joinroot@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-minionroot@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_clusterroot@master #
salt-run state.orch ceph.stage.1root@master #
salt-run push.proposal
salt-run populate.engulf_existing_cluster
命令不会处理 iSCSI 网关配置的导入过程。如果您的集群包含 iSCSI 网关,请手动导入其配置:
在其中一个 iSCSI 网关节点上,导出当前的 lrbd.conf
,然后将其复制到 Salt Master 节点:
root@minion >
lrbd -o > /tmp/lrbd.confroot@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.ymlroot@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 [...]
如果已将系统注册到 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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
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-0aroot@master #
salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2aroot@master #
salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bcroot@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.updatesroot@master #
salt target test.versionroot@master #
salt-run state.orch ceph.maintenance.upgrade
每个节点都将重引导。集群将再次启动,报告没有活动的 Ceph Manager 实例。这是正常的。此时,Calamari 应未安装/不再运行。
运行所有必要的部署阶段,以将集群置于健康状态:
root@master #
salt-run state.orch ceph.stage.0root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@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.2root@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
来删除。
您需要在要升级的所有 Ceph 节点上安装以下软件并将其更新到最新的包版本,然后才能开始升级过程:
SUSE Linux Enterprise Server 12 SP1
SUSE Enterprise Storage 3
要将 SUSE Enterprise Storage 3 集群升级到版本 5,请依次执行过程 5.1 “要对所有集群节点应用的步骤(包括 Calamari 节点)”和过程 5.2 “要对 Salt Master 节点应用的步骤”中所述的步骤。