核心组迁移注意事项
V6 和更高版本中提供了高可用性管理器和核心组功能。本主题讨论在从不包含此功能的产品版本(如 V5.1)迁移时可能影响迁移的核心组配置和拓扑注意事项。
- 高可用性管理器
- 何时使用高可用性管理器
- 核心组
- 核心组传输
- 核心组协调程序
- 核心组管理注意事项
- 核心组伸缩注意事项
因为在从不具有高可用性管理器的产品版本迁移至具有高可用性管理器的产品版本之前,您的环境可能需要执行特殊的规划和迁移活动,所以您应该知道下列问题的答案:
- 在完全迁移至 V7.0 之后,单元的合适核心组配置和拓扑是什么?
- 在混合环境中,是否要配置 V5.x 单元以使用内存到内存复制?如果是,将如何迁移复制环境?迁移过程期间如何影响复制?
- 如果 V5.x 单元中使用了 JMS 提供程序,使用的是哪个 JMS 提供程序?
- 如果 V7.0 单元中使用了 JMS 提供程序,使用的是哪个 JMS 提供程序?
- 如果 V7.0 单元中将使用 V7.0 缺省 IBM® 消息传递提供程序,是否应配置该消息传递提供程序以使其具有高可用性?
- 是否应在 V7.0 单元中配置事务日志恢复?
与缺省核心组相关的迁移活动
- 将 Deployment Manager 迁移至 V7.0。
- 迁移过程中,将创建 Deployment Manager V7.0 概要文件和名为 DefaultCoreGroup 的核心组。
- 将新的 Deployment Manager 进程添加至 DefaultCoreGroup。
- 将 V5.x 节点逐个迁移至 V7.0。迁移每个节点时,正在迁移的节点上的 Node Agent 和应用程序服务器将添加至 DefaultCoreGroup。
迁移完成后,V5.x 单元中的所有进程都是 V7.0 DefaultCoreGroup 的成员。因为 DefaultCoreGroup 是使用所有设置的缺省值配置的,所以迁移过程不会配置首选协调程序服务器,并且不会将协调程序分布到多个服务器中。迁移过程也不会创建新的高可用性策略,并且不会提供任何定制属性配置覆盖。
规划核心组拓扑
对于大多数 V5.x 拓扑来说,缺省迁移将会产生一个合适的可用 V7.0 核心组拓扑。在某些情况下,可能需要对拓扑进行少量更改,如设置非缺省传输或配置核心组以进行复制。如果 V5.x 单元大到要求 V7.0 拓扑中具有多个核心组,那么应该在启动迁移过程之前进行更仔细的规划,以防止在更改核心组配置时应用程序中断。
将较大的 V5.x 单元迁移至 V7.0 时,如果需要多个核心组,那么这可能是一项复杂的任务。当 V7.0 拓扑需要多个核心组时,您有多项选择,可以选择如何以及何时将单元分到多个核心组中。您使用的方法应基于一些因素,如单元中的进程数和提供连续应用程序可用性的要求。例如,虽然一般建议核心组中包含大约 50 个成员,但实际限制要略高于 50。对于高端机器(具有大量内存的大型 CPU)上安装了少量应用程序的拓扑来说,您可能可以拥有多达 200 个成员的核心组。如果单元中有 150 个进程并且应用程序可用性不存在问题,那么可以选择仅将整个单元迁移至 V7.0,然后创建其他核心组。如果应用程序可用性存在问题,那么应该在迁移过程中创建其他核心组,以便在迁移过程完成后,不必停止并重新启动核心组成员。
- 核心组大小
- 最重要的规划注意事项是核心组的大小。缺省情况下,每个单元通常有一个核心组。因为核心组无法扩充到较大大小,所以当 V5.x 单元较大时,您可能需要为 V7.0 拓扑创建其他核心组。如果多个核心组之间需要相互通信,那么您可能还需要设置核心组网桥。
- 核心组传输
- 如果对核心组传输配置进行了更改,那么必须重新启动所有核心组成员后,更改才会生效。因此,需要进行规划以最大程度减少更改传输所产生的影响。如果更改了 DefaultCoreGroup 的传输,那么由于该时间点只需要重新启动 Deployment Manager,因此最好在迁移 Deployment Manager 之后立即进行更改。如果创建其他核心组,那么在创建新核心组时应正确配置传输。
- 定制属性配置覆盖
- 通过“定制属性”覆盖可以更改许多核心组配置参数。在本节的其他信息中心文章中记录了可用的“定制属性”覆盖。
每次添加、除去或更改“定制属性”覆盖时,必须重新启动所有核心组成员,以便更改生效。因此,需要进行规划以最大程度减小更改“定制属性”所产生的影响。如果由于更改了 DefaultCoreGroup 而必须更改“定制属性”,那么最好在迁移 Deployment Manager 之后立即进行更改。如果创建其他核心组,那么在创建新核心组时应更改“定制属性”。
- 核心组协调程序
- 配置首选协调程序服务器是一种最佳实践。因为 HA 管理器可以动态重新读取并应用核心组协调程序配置更改,所以不需要重新启动所有核心组成员来使此更改生效
示例:迁移较大单元
以下示例说明了一些经过考虑的过程,当您计划和执行从较大的 V5.x 单元到 V7.0 的迁移时,如果需要多个核心组,那么应该完成这些过程。对于此示例,假定 V5.x 单元具有下列拓扑特征:
- 该单元包含 8 个节点,分别命名为 Node1、Node2、Node3、... 和 Node8,但不包括 Deployment Manager 节点。
- 该单元包含 10 个集群,分别命名为 Cluster1、Cluster2、Cluster3、... 和 Cluster10。
- 集群 Cluster1 到 Cluster9 中的每个集群都包含 32 个应用程序服务器。这些集群的集群成员平均地分布在所有节点中,每个节点包含 4 个应用程序服务器。
- Cluster10 包含 28 个应用程序服务器。Node1 上没有任何属于 Cluster10 的应用程序服务器。Cluster10 的应用程序服务器平均地分布在节点 Node2 到 Node8 中,每个节点包含 4 个应用程序服务器。
- 该单元中总共有 316 个应用程序服务器、8 个 Node Agent 和一个 Deployment Manager。
- 每个集群都部署了一个使用 EJB 的应用程序,并且这些应用程序可以相互通信。因此,工作负载管理 (WLM) 路由信息必须在单元中的任何位置都可用。
- 迁移期间,应用程序必须持续可用。
- 执行迁移要花几天或几周的时间。
规划 V7.0 核心组拓扑时首先要考虑的事情是该单元包含 325 个进程,并且要求应用程序持续可用。这些因素不允许我们简单地迁移整个单元,然后重新配置核心组。迁移过程中,必须将单元中包含的进程分布在多个核心组中。
确定将 V5.x 单元进程分布在新核心组中的方式时,请确保每个核心组都符合下列核心组规则:
- 每个核心组必须至少包含一个管理进程。因为此示例中的单元有 9 个管理进程、8 个 Node Agent 和一个 Deployment Manager,那么此拓扑中最多可以有 9 个核心组。
- 集群的所有成员必须是同一核心组的成员。
- 每个核心组中包含的进程数不能超过建议的大小(大约 50 个成员)。
- 其中至少有一个核心组必须包含两个集群,原因是最多只能将单元分割为 9 个核心组,但 V5.x 单元中有 10 个集群。
- 任何包含多个集群的核心组的成员数将超过 50,原因是每个集群包含 28 或 32 个应用程序服务器。
虽然至少一个核心组中的成员数将超过建议的限制,但符合实际限制的成员数,并且不会产生问题。
因为此示例中的应用程序需要单元中包含的每个集群的 WLM 路由信息,所以必须设置核心组网桥以便在所有核心组之间启用通信。(如果您不熟悉如何设置核心组网桥,请参阅核心组网桥主题。)适合此示例的核心组网桥拓扑包括:
- 每个核心组的核心组访问点。每个访问点包含为核心组提供网桥接口的进程集。网桥接口是实际与其他核心组中的进程通信的进程。
- 每个访问点有两个网桥接口,以便核心组网桥不会成为一个故障点。这两个网桥接口将放置在不同节点上,以进一步确保连续可用性。
选择充当网桥接口的进程时,请记住,网桥接口需要额外的内存和 CPU 周期。通常,由于在正常操作期间,Node Agent 的工作负载低于应用程序服务器或 Deployment Manager 的工作负载,因此 Node Agent 是适合用作网桥接口的进程。
但是,在此示例中,只有 8 个 Node Agent 可用于充当网桥接口。因为该拓扑希望每个访问点有两个网桥接口,所以,如果仅将 Node Agent 用作网桥接口,那么您将限制为使用 4 个访问点,从而只能使用 4 个核心组。因此,在启动迁移过程之前,您可能希望创建 8 个独立服务器来专门充当网桥接口,而不主管应用程序。然后,每个访问点可以包含一个 Node Agent 和一个独立的网桥接口服务器。此设置将为您提供总共 8 个访问点和 8 个核心组。
- 包含所有访问点的单个核心组访问点组。单个核心组访问点组确保所有网桥接口进程可以直接通信。这些网桥接口形成一个完全连接的网。
备用拓扑是使用多个访问点组,从而产生一个链式拓扑。在链式拓扑中,通信沿链中的中间网桥接口从一个网桥接口转发到另一个网桥接口。
既然确定了核心组网桥接口的设置,您现在就可以决定如何将 10 个集群、8 个 Node Agent、8 个独立的网桥接口服务器和 1 个 Deployment Manager 分布在 8 个核心组中。您希望尽可能地将进程均匀分布在 8 个核心组中。以下拓扑是一个很好的示例,它说明了如何均匀地分布 V5.x 单元中包含的进程:
- 第一个核心组 DefaultCoreGroup 包含 Node1 中的 Deployment Manager 和 Node Agent 以及 Node2 和 Cluster1 中的网桥服务器。
- 核心组 2 包含 Node2 中的 Node Agent 以及 Node3 和 Cluster2 中的网桥服务器
- 核心组 3 包含 Node3 中的 Node Agent 以及 Node4 和 Cluster3 中的网桥服务器
在此示例中,不需要更改缺省传输。
因为此示例没有表明您需要每个核心组有多个协调程序,所以您可以保持协调程序设置的缺省值 1 不变。但是,您可能要使每个核心组中包含的独立网桥接口服务器成为该核心组的首选协调程序服务器。这种指定方式最初使协调程序需要的工作负载与运行应用程序的集群应用程序服务器无关。
您的迁移计划
在查看上述示例并对要迁移的单元进行了初步规划后,如果您确定缺省迁移流程不适合目标 V7.0 拓扑,那么现在可以为实际迁移过程制订一个计划或路线图。该计划应包括从 V5.x 迁移至 V7.0 时与额外核心组相关的所有必要步骤以及下列问题的答案:
- 何时将创建新的核心组?
- 最好在 Deployment Manager 迁移完成后立即创建新核心组。创建新核心组时,应配置先前提到的定制属性。可以使用管理控制台或 createCoreGroup wsadmin 命令创建新的核心组。但是,必须使用管理控制台来配置定制属性。
- 迁移节点时需要执行什么操作?
- 迁移每个节点时,您应该:
- 创建将成为其中一个核心组网桥接口的新独立应用程序服务器。
- 调整节点上所有进程中的传输缓冲区大小。最好使用脚本执行此操作。
- 调整 Node Agent 和独立服务器上的堆大小,并对这些进程打开详细垃圾回收。
- 何时以及如何将进程移至新的核心组?
- 缺省情况下,迁移过程将所有进程放置在名为 DefaultCoreGroup 的核心组中。在某个时间点此核心组中包含的成员数将超过限制的大小,必须将进程重新分布到其他核心组。必须在停止进程后才能移动它们,了解这一点很重要。如果需要连续应用程序可用性,那么必须小心规划将进程移至不同核心组的顺序。
可以使用管理控制台或 moveServerToCoreGroup wsadmin 命令来移动 Deployment Manager、Node Agent 和独立的应用程序服务器。
移动集群应用程序服务器更复杂一些。在一般情况下,可以使用管理控制台或 moveServerToCoreGroup wsadmin 命令移动集群。但是,在迁移过程中,因为要移动的集群可能同时具有 V7.0 和 V5.x 成员,所以一般的命令将会失败,这是由于 V5.x 集群成员尚不是任何核心组的成员。要将混合集群移至新的核心组,必须使用带有可选 checkConfig 参数的 moveClusterToCoreGroup wsadmin 命令。
例如,假定 Cluster0 具有集群成员 A、B、C 和 D。成员 A 在已迁移至 V7.0 的节点上,并且是 DefaultCoreGroup 的成员,而 B、C 和 D 仍在 V5.x 节点上。要将 Cluster0 移至核心组 CG1,使用以下命令:$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1 –clusterName Cluster0 –checkConfig false}
迁移集群应用程序服务器时,迁移实用程序确定是否已迁移其他集群成员,并且会自动将迁移成员放在与同一个集群中已迁移的其他成员相同的核心组中。
在先前的示例中,成员 A 已移至核心组 CG1。迁移包含 B、C 和 D 的节点时,迁移会将这些集群成员放在 CG1 而不是 DefaultCoreGroup 中。因此,必须仅对每个集群运行一次 moveClusterToCoreGroup 命令。
- 何时需要配置核心组网桥?
- 将进程移至多个核心组之前,必须配置核心组网桥并使其运行。这表示最初需要那些要用作 V7.0 目标拓扑中网桥接口的进程时,由于尚未从 V5.x 节点进行迁移,所以它们可能不可用。因此,要确保应用程序的连续可用性,必须在迁移过程中将某些集群应用程序服务器配置为临时网桥接口。在将所有进程都迁移至 V7.0 之后,可以调整核心组网桥配置以与需要的 V7.0 拓扑匹配。
其他规划注意事项
如果目标 V7.0 配置需要多个核心组网桥,请使用 IBM_CS_WIRE_FORMAT_VERSION 核心组定制属性来改进伸缩功能。
此外,如果所有核心组都桥接在一起并且相互传递共享信息,那么在核心组成员之间共享的数据量可能比正常情况要大很多。因此,应使用下列设置来增加核心组内存设置,以允许更有效地传送数据:
- 将 IBM_CS_DATASTACK_MEG 设置为 100
- 将所有进程中的传输缓冲区大小设置为 100。
对于要用作网桥接口的任何 Node Agent 或应用程序服务器,以及要用作协调程序的任何独立服务器,还应该考虑调整诸如 JVM 堆大小之类的因素。建议从将堆大小增大 512 MB 开始。还可以对这些进程打开详细垃圾回收监视,以便可以随时间推移而调整这些堆大小。
可能的迁移流
可以使用许多迁移流来实现成功迁移。下列流假定一个公共起始点,即已完成 Deployment Manager 迁移并且创建了核心组,但未执行更多操作。
- 迁移流 1
- 在此流中,我们严格遵守规则。由于许多原因,此流并不令人满意。迁移每个节点时,将需要移动集群。这要求停止所有集群成员。这可能导致应用程序不可用。此外,每个步骤中都需要重新配置网桥。
- 迁移 Node1。DefaultCoreGroup 包含 Deployment Manager 和 Node1 中的所有进程。由于 DefaultCoreGroup 包含的成员数小于 50,所以不需要更多操作。
- 迁移 Node2。现在,DefaultCoreGroup 包含的进程数多于建议的进程数。通过将 Node2 中的一半集群和 Node Agent 移到 CoreGroup2 中,平衡 2 个核心组中的进程。由于现在使用多个核心组,所以需要配置核心组网桥。在节点 Node1 和 Node2 上创建网桥接口服务器。配置核心组网桥以将两个核心组桥接在一起。
- 迁移 Node3。通过将 DefaultCoreGroup 和 CoreGroup2 中的一些集群移至 CoreGroup3,平衡 3 个核心组中的进程。将 Node3 的 Node Agent 移至 CoreGroup3。在 Node3 上创建网桥接口服务器。重新配置核心组网桥以将所有三个核心组桥接在一起。
- 继续迁移节点,直到迁移完成为止。迁移每个节点时,可能需要对核心组网桥进行一些重新平衡和重新配置。
- 迁移流 2
- 在此流中,我们暂时遵守规则。由于不需要停止正在运行的应用程序服务器就可以将它们移至另一个核心组,所以此流产生更好的结果。迁移正在进行时,一些核心组在某段时间内不包含管理进程。这在技术上违反了规则,但只要在迁移正在进行时未更改核心组配置,就可以接受这种情况。
- 迁移 Node1。Node1 包含除 Cluster10 之外的所有集群中的成员
- 将所有可能的集群移至在最终目标拓扑中标识的核心组。Node1 和 Cluster1 的 Deployment Manager 和 Node Agent 已经在 DefaultCoreGroup 中,因此不需要对它们执行更多操作。将 Cluster2 移至 CoreGroup2,将 Cluster3 移至 CoreGroup3,以此类推。为 Node1 创建网桥服务器并将它放在 CoreGroup2 中。
- 配置核心组网桥以将所有 8 个核心组桥接在一起。为了简单起见,我们将暂时为每个访问点配置单个网桥接口。(这将在迁移正在进行时引入单个故障点)由于最终拓扑中的大多数网桥接口仍在 V5.x 上,所以需要将应用程序服务器用作 8 个核心组的其中 6 个的临时网桥接口。这可能需要暂时增加所选应用程序服务器的堆大小。
- 迁移 Node2。迁移会自动将 Node2 的集群应用程序服务器移至正确的核心组。因为 Node1 上没有任何属于 Cluster10 的应用程序服务器,所以应手动将 Cluster10 移至 CoreGroup8。将 Node2 的 Node Agent 移至 CoreGroup2。在 Node2 上创建网桥服务器。(可选)重新配置核心组网桥,以便某些临时网桥接口服务器位于 Node2 上,从而帮助将负载分布在这两个节点上。
- 使用相同模式继续迁移节点,直到迁移了所有节点为止。
- 迁移所有节点后,配置首选协调程序服务器。重新配置网桥接口以与最终目标拓扑(每个访问点中有两个网桥接口服务器)匹配。停止充当临时网桥接口的服务器,然后将其重新启动。重新启动新的网桥接口服务器。
- 迁移流 3
- 此流是迁移流 2 的变化形式。根据说明,此流是迁移流 2 的变化形式。该流的优点是初始网桥负载分布在三个节点而不是一个节上。缺点是在迁移 Node3 之后开始将集群重新分发至核心组。这要求必须停止在节点 Node1 和 Node2
上运行的服务器才能进行移动。这可能会影响应用程序可用性。
- 迁移 Node1。完成此步骤后,DefaultCoreGroup 将包含 38 个进程,这在限制内。
- 迁移 Node2。完成此步骤后,DefaultCoreGroup 将包含 79 个进程。虽然这大于建议的大小,但却在实际限制内。
- 迁移 Node3。将所有集群移至在最终拓扑中标识的核心组。将 Cluster2 移至 CoreGroup2,将 Cluster3 移至 CoreGroup3,以此类推。将三个 Node Agent 移至正确的核心组。创建三个网桥接口服务器并将它们移至正确的核心组。
- 选择集群应用程序服务器以充当尚未包含所指定网桥接口的核心组的临时网桥。暂时调整这些服务器上的堆大小。配置核心组网桥以将所有 8 个核心组桥接在一起。
- 继续迁移节点,直到迁移了所有节点为止。
- 迁移所有节点后,配置首选协调程序。重新配置网桥接口以与最终目标拓扑匹配。根据需要停止并重新启动进程。