群集升级
在群集系统中,可以执行滚动升级,这样在执行升级时将无需停机。本节假设您熟悉 Oracle ZFS Storage Appliance 群集模型:如果您不熟悉群集概念和术语,请首先阅读Oracle ZFS Storage Appliance 管理指南
中的第 10 章 群集配置。为了描述滚动升级过程,此文档将引用两个群集存储控制器 A 和 B,其中将首先更新 A 控制器,然后更新 B 控制器。滚动升级的一项重要的最佳做法是,每个控制器应该在未对客户机提供服务时进行升级。此处描述的过程符合这一要求。此外,上述所有常规升级最佳做法也适用于滚动升级。
执行群集升级
重要提示:请勿在升级期间执行接管操作。
-
使用 CLI 或 BUI 将软件更新映像同时上载到两个存储控制器中。
-
选择要首先更新的控制器。将首先更新没有存储池的控制器。在下面的步骤中,控制器 A 将首先更新,这样,使用控制器 A 的存储池的客户机将先体验到由接管操作引入的可用性延迟。
-
登录到控制器 A,使用 CLI maintenance system reboot 命令或 BUI 标头中的电源图标
,选择重新引导选项来重新引导控制器 A。控制器 B 将接管控制器 A 的资源。
-
登录到控制器 A,然后使用 CLI 或 BUI 向控制器 A 应用软件更新。在升级结束时,控制器 A 再次重新引导,此时会运行新版本的软件。
注 -
请勿针对正在提供服务的控制器执行升级。
-
登录到控制器 B,使用 CLI maintenance system reboot 命令或 BUI 标头中的电源图标
,选择重新引导选项来重新引导控制器 B。控制器 A 将接管所有的资源并使用新版本的软件提供服务。
-
验证控制器 A 上的新软件版本,并确保客户机系统上的所有服务均正常工作。
-
如果出现严重问题,则回滚控制器 A。控制器 A 将重新引导,控制器 B 将接管所有的资源并运行先前版本的软件。当控制器 A 恢复时,它也将运行先前版本的软件。
-
如果未出现严重问题,请登录到控制器 B,然后使用 CLI 或 BUI 向控制器 B 应用软件更新。控制器 B 将重新引导并运行新版本的软件。
-
确认所有固件都完成更新。
注 -
如果两个控制器运行不同版本的系统软件,将不会进行控制器固件更新。
-
要恢复正常操作并使资源返回给为其各自分配的控制器,请登录到控制器 A,然后使用 CLI 或 BUI 针对控制器 A 执行故障恢复。有关故障恢复操作的信息,请参见Oracle ZFS Storage Appliance 管理指南
中的群集的接管和故障恢复。
升级期间的群集状态
下表介绍了在执行上述过程的每个步骤之后,群集的状态。
表 3-4 升级期间的群集状态
|
|
|
|
|
1,2
|
CLUSTERED
|
V
|
CLUSTERED
|
V
|
3
|
STRIPPED
|
V
|
OWNER
|
V
|
4
|
STRIPPED
|
V+1
|
OWNER
|
V
|
5, 6, 7
|
OWNER
|
V+1
|
STRIPPED
|
V
|
8, 9
|
OWNER
|
V+1
|
STRIPPED
|
V+1
|
10
|
CLUSTERED
|
V+1
|
CLUSTERED
|
V+1
|
|
注 -
请勿在升级过程中对任何存储控制器进行配置更改。控制器运行不同版本的软件时,对一个控制器所做的更改将不会传播到对等控制器。
当控制器运行不同版本的软件时,访问 BUI 或登录到 CLI 会生成警告,说明将不会传播配置更改。可以将该设备配置为当群集中的不同控制器运行不同版本的软件时生成警报(事件 "Cluster rejoin mismatch" 和 "Cluster rejoin mismatch on peer")。
如果在升级过程中更改了 root 用户密码,然后对群集进行回滚,则节点将无法在回滚后重新加入群集。