5 升级群集和更新软件包 #
摘要#
本章介绍两种不同方案：将群集升级为 SUSE Linux Enterprise High Availability Extension 的另一个版本（主要版本或服务包），以及更新群集节点上的单个包。请参见第 5.2 节 “将群集升级到最新产品版本”与第 5.3 节 “更新群集节点上的软件包”。
如果您要升级群集，请在开始升级之前查看第 5.2.1 节 “SLE HA 和 SLE HA Geo 支持的升级路径”和第 5.2.2 节 “升级前必须满足的先决条件”。
5.1 术语 #
下面介绍本章中使用的最重要术语的定义：
- 主要版本, 正式发布 (GA) 版本
SUSE Linux Enterprise（或任何软件产品）的主要版本是一个新版本，其中会引入一些新功能和工具，去除之前弃用的组件，并进行一些不向后兼容的更改。
- 脱机迁移
如果新的产品版本包含不向后兼容的重大更改，则需要通过脱机迁移来升级群集：您需要将所有节点脱机，升级整个群集，然后才能将所有节点重新联机。
- 滚动升级
在滚动升级过程中，每次会升级一个群集节点，其余的群集节点将保持运行状态：您需要将第一个节点脱机，将它升级，再将它重新联机以加入群集。然后，需要逐个对其余节点重复上述过程，直到所有群集节点都升级为主要版本。
- 服务包 (SP)
将几个增补程序合并到便于安装或部署的一个组织体中。服务包是有编号的并通常包含安全性修复、更新、升级或程序增强。
- 更新
安装包的更新次要版本。
- 升级
5.2 将群集升级到最新产品版本 #
至于支持哪种升级路径以及如何执行升级，取决于当前产品版本，以及您要迁移到的目标版本。
采用滚动升级方式，只能从产品版本 GA 滚动升级到下一个服务包，以及从一个服务包滚动升级到下一个服务包。
从一个主要版本升级到下一个主要版本（例如，从 SLE HA 11 升级到 SLE HA 12），或者从属于一个主要版本的服务包升级到下一个主要版本（例如，从 SLE HA 11 SP3 升级到 SLE HA 12），需要执行脱机迁移。
有关升级基础系统 (SUSE Linux Enterprise Server) 的信息，请参见您要升级到的目标版本的《SUSE Linux Enterprise Server 部署指南》。https://documentation.suse.com/#sles/ 上提供了该指南。
第 5.2.1 节概述了 SLE HA (Geo) 支持的升级路径，并提供了其他文档供您参考。
重要：升级后不支持混合群集和逆转
不支持在 SUSE Linux Enterprise High Availability Extension 11/SUSE Linux Enterprise High Availability Extension 12 上运行混合群集。
完成到产品版本 12 的升级过程后，不支持再还原到产品版本 11。
5.2.1 SLE HA 和 SLE HA Geo 支持的升级路径 #
|
升级前版本和目标版本 |
升级路径 |
有关细节请参见 |
|---|---|---|
|
从 SLE HA 11 SP3 升级到 SLE HA (Geo) 12 |
脱机迁移 |
|
|
从 SLE HA (Geo) 11 SP4 升级到 SLE HA (Geo) 12 SP1 |
脱机迁移 |
|
|
从 SLE HA (Geo) 12 升级到 SLE HA (Geo) 12 SP1 |
滚动升级 |
|
|
从 SLE HA (Geo) 12 SP1 升级到 SLE HA (Geo) 12 SP2 |
滚动升级 |
|
|
从 SLE HA (Geo) 12 SP2 升级到 SLE HA (Geo) 12 SP3 |
滚动升级 |
|
|
从 SLE HA (Geo) 12 SP3 升级到 SLE HA (Geo) 12 SP4 |
滚动升级 |
|
|
从 SLE HA (Geo) 12 SP4 升级到 SLE HA (Geo) 12 SP5 |
滚动升级 |
|
https://documentation.suse.com 上提供了有关细节请参见列中所列的全部文档。
5.2.2 升级前必须满足的先决条件 #
- 备份
确保系统备份为最新的且可恢复。
- 测试
请先在群集设置的临时实例上测试升级过程，然后再在生产环境中执行该过程。
这样，您便可以估算出维护期所需的时间段。这还有助于检测和解决可能会出现的任何意外问题。
5.2.3 脱机迁移 #
本节内容适用于以下方案：
从 SLE HA 11 SP3 升级到 SLE HA 12
从 SLE HA 11 SP4 升级到 SLE HA 12 SP1
如果您的群集仍旧基于早期的产品版本而不是上面所列的版本，请先将它升级到 SUSE Linux Enterprise Server 和 SUSE Linux Enterprise High Availability Extension 的某个版本，该版本必须可用作升级到所需目标版本的源。
High Availability Extension 12 群集堆栈的各个组件包含了重大更改（例如 /etc/corosync/corosync.conf、OCFS2 的磁盘格式）。因此，不能从任何 SUSE Linux Enterprise High Availability Extension 11 版本滚动升级到该版本。必须将所有群集节点脱机，并根据过程 5.1 “执行群集范围的脱机迁移”中所述迁移整个群集。
过程 5.1︰ 执行群集范围的脱机迁移 #
登录到每个群集节点，并使用以下命令停止群集堆栈：
root #rcopenaisstop将每个群集节点都升级到 SUSE Linux Enterprise Server 和 SUSE Linux Enterprise High Availability Extension 的所需目标版本。如果您有现有的 Geo 群集设置且想升级它，请参见《Geo Clustering for SUSE Linux Enterprise High Availability Extension Geo 群集快速入门》中的附加指导。要了解各个升级过程的细节，请参见第 5.2.1 节 “SLE HA 和 SLE HA Geo 支持的升级路径”。
完成升级过程后，请重引导装有 SUSE Linux Enterprise Server 和 SUSE Linux Enterprise High Availability Extension 升级版的每个节点。
如果在群集设置中使用了 OCFS2，请执行以下命令以更新设备上的结构：
root #o2cluster--update PATH_TO_DEVICE该命令会向磁盘添加附加的参数，SUSE Linux Enterprise High Availability Extension 12 和 12 SPx 随附的 OCFS12 更新版本需要这些参数。
要更新 Corosync 2 的
/etc/corosync/corosync.conf，请执行以下操作：登录到某个节点，然后启动 YaST 群集模块。
切换到类别并输入以下新参数的值：和。有关细节，请分别参见过程 4.1 “定义第一个通讯通道（多路广播）”或过程 4.2 “定义第一个通讯通道（单路广播）”。
如果 YaST 检测到对 Corosync 2 无效或缺失的任何其他选项，它会提示您进行更改。
确认在 YaST 中所做更改。YaST 会将配置写入
/etc/corosync/corosync.conf。如果为群集配置了 Csync2，请使用以下命令将更新的 Corosync 配置推送到其他群集节点：
root #csync2-xv有关 Csync2 的细节，请参见第 4.5 节 “将配置传送到所有节点”。
或者，也可以通过将
/etc/corosync/corosync.conf手动复制到所有群集节点，来同步更新的 Corosync 配置。
登录到每个节点，并使用以下命令启动群集堆栈：
root #systemctlstart pacemaker使用
crm status或 Hawk2 检查群集状态。将以下服务配置为在引导时启动：
root #systemctl enable pacemakerroot #systemctl enable hawkroot #systemctl enable sbd
注意：升级 CIB 语法版本
标记（用于对资源分组）和某些 ACL 功能仅适用于 pacemaker-2.0 或更高的 CIB 语法版本（要检查版本，请使用 cibadmin -Q |grep validate-with 命令）。如果您是从 SUSE Linux Enterprise High Availability Extension 11 SPx 升级的，CIB 版本默认不会升级。要手动升级到最新的 CIB 版本，请使用以下命令之一：
root #cibadmin--upgrade --force
或者
root #crmconfigure upgrade force
5.2.4 滚动升级 #
本节内容适用于以下方案：
从 SLE HA 12 升级到 SLE HA 12 SP1
从 SLE HA 12 SP1 升级到 SLE HA 12 SP2
从 SLE HA (Geo) 12 SP2 升级到 SLE HA (Geo) 12 SP3
从 SLE HA (Geo) 12 SP3 升级到 SLE HA (Geo) 12 SP4
从 SLE HA (Geo) 12 SP4 升级到 SLE HA (Geo) 12 SP5
警告：活动的群集堆栈
在开始升级某个节点之前，请停止该节点上的群集堆栈。
如果在软件更新期间，群集资源管理器所在节点处于活动状态，可能会导致不可预料的结果，例如活动的节点被屏蔽。
过程 5.2︰ 执行群集范围的滚动升级 #
以
root用户身份登录要升级的节点，并停止群集堆栈：root #systemctlstop pacemaker升级到 SUSE Linux Enterprise Server 和 SUSE Linux Enterprise High Availability Extension 的所需目标版本。要了解各个升级过程的细节，请参见第 5.2.1 节 “SLE HA 和 SLE HA Geo 支持的升级路径”。
在升级后的节点上重启动群集堆栈，使该节点重新加入群集：
root #systemctlstart pacemaker使下一个节点处于脱机状态，并对此节点重复上述过程。
使用
crm status或 Hawk2 检查群集状态。
重要：滚动升级的时间限制
只有在将所有群集节点都升级到最新产品版本之后，最新产品版本提供的新功能才可用。对于采用混合版本的群集，其在滚动升级期间受支持的时间非常短暂。请在一周内完成滚动升级。
如果检测到您的群集节点有不同的 CRM 版本，Hawk2 屏幕还会显示一条警告。
5.3 更新群集节点上的软件包 #
警告：活动的群集堆栈
启动某节点的更新之前，请停止该节点上的群集堆栈，或将该节点置于维护模式，具体取决于群集堆栈是否受影响。有关详细信息，请参见步骤 1。
如果在软件更新期间，群集资源管理器所在节点处于活动状态，可能会导致不可预料的结果，例如活动的节点被屏蔽。
在节点上安装任何包更新之前，请先确认以下问题：
这种更新是否会影响属于 SUSE Linux Enterprise High Availability Extension 或 Geo Clustering Extension 的任何包？如果
是，请先在节点上停止群集堆栈，然后再开始软件更新：root #systemctlstop pacemaker包更新操作是否需要重引导计算机？如果
是，请先在节点上停止群集堆栈，然后再开始软件更新：root #systemctlstop pacemaker如果不属于上述任何一种情况，则不需要停止群集堆栈。在这种情况下，请先将节点置于维护模式，然后再开始软件更新：
root #crmnode maintenance NODE_NAME有关维护模式的更多细节，请参见第 16.2 节 “用于维护任务的不同选项”。
使用 YaST 或 Zypper 来安装包更新。
在成功安装更新后：
启动相应节点上的群集堆栈（如果在执行步骤 1 时已将它停止）：
root #systemctlstart pacemaker或者去除维护标志，使节点恢复正常模式：
root #crmnode ready NODE_NAME
使用
crm status或 Hawk2 检查群集状态。
5.4 更多信息 #
有关您要升级到的产品的任何更改和新功能的详细信息，请参见其发行说明，所在网址为 https://www.suse.com/releasenotes/。