《BEA WebLogic JMS和JTA迁移过程指南》由会员分享，可在线阅读，更多相关《BEA WebLogic JMS和JTA迁移过程指南（41页珍藏版）》请在金锄头文库上搜索。
1、BEA WebLogic JMS 和 JTA 迁移过程指南 浏览次数： 768 时间： 2004-09-08作者：Kathiravan Sengodan1. 简介本文详细解释了 WebLogic Server迁移过程，并且通过提供详细的指导，配以过程中每个关键步骤的截图，为执行手工迁移过程的 WebLogic Server管理员提供了指导。本文还提供了在 WebLogic Server NodeManager的帮助下使用 JMX以编程方式执行迁移过程的指导和例子。下载作者提供的与本文相关的文件。2. 范围本文详细描述了有关 JMS 与 JTA 服务迁移的过程。不涉及任何其他服务迁移过程。3.
2、术语和定义术语 定义可迁移服务 可以从一个 WebLogic Server实例迁移到另一个实例并且不会丢失服务相关数据的任何服务。目标 可以做为主机并充当不同 J2EE子系统服务容器的 WebLogic Server的被管理实体。集群目标 一个或多个服务器集群在一起，作为一个通过复制和共享公共资源（例如 JNDI等）来提供集群服务的实体。服务器目标 单个 WebLogic Server实例。可迁移目标 包含一个或多个候选服务器，但任何时侯都只有一个活动服务器的虚拟目标。候选服务器* 在迁移过程中可以作为用户首选服务器的备用服务器列表。用户首选服务器 宿主已部署 J2EE服务的当前活动服务器。源
3、服务器 服务迁移“出”的服务器实例。目标服务器 服务迁移“到”的服务器实例。JMS Java消息服务JTA Java事务服务JDBC Java数据库连接JMX Java管理扩展SAN 存储区域网络TLOG 事务日志*列表中作为可迁移目标的服务器属于相同的集群。4. WebLogic Server 迁移与相关基础件某些特定的 WebLogic Server 服务，例如 JMS 与 JTA Transaction Recovery Service，都遵照这样一个假设进行设计，即：在任何给定时刻只有一个服务的活动实例运行于特定集群节点。这些类型的服务被称为“置顶（pinned）”服务，因为它们在某一
4、时刻只在一个服务器实例上保持活动。WebLogic Server 允许管理员将这些置顶服务从集群中的一个服务器实例迁移到另一个实例上，以解决服务器故障或者部分日常维护问题。这一能力提高了这些置顶服务在集群中的可用性，因为一旦主服务器出现故障，那么其上的服务就可以在一台冗余服务器上重启。注意：目前，WebLogic Server 不支持对于置顶服务的自动迁移（故障恢复）。参见本文 5.2.5 节，其中介绍了执行编程方式迁移的无文档记载的方法。目前，迁移仅仅支持 JMS 服务器和 JTA Transaction Recovery Service。本文中将这两种服务统称为可迁移服务。JMS 服务器的
5、迁移可以独立于 JTA Transaction Recovery Service。不过，既然 JTA Transaction Recovery Service 给其他子系统服务提供了事务控制，那么它也常常随着其他子系统服务而迁移。这就在子系统服务迁移之前和之后都保证了事务的完整性。WebLogic Server 迁移基础件包括不同的服务器组件和工具，如下所示：可迁移目标默认状态下，WebLogic Server 可以将 JTA Transaction Recovery Service 或者 JMS 服务器迁移至同一集群中的任何其他WebLogic Server 实例。您可以有选择地配置集群中的
6、服务器列表，以使其具备潜在的宿主置顶服务的能力。服务器列表即指一个可迁移的目标，并且它控制您可以迁移的服务器，即服务。定义集群中的可迁移目标服务器例如，下图展示了具有两个集群的 WebLogic Server 域配置。集群 1 包括配置好的 WebLogic Server 实例 MS1、MS2 和MS3。集群 2 包括配置好的 WebLogic Server 实例 MS4、MS5、MS6 和 MS7。ManagedServer1 (MS1) 使用 ManagedServer2 (MS2)作为迁移时的候选服务器，同时 ManagedServer2 (MS2) 使用 ManagedServer1
7、(MS1)作为迁移时的候选服务器。图 1一个典型的 WebLogic域配置在上例中，当置顶的 JMS服务器部署为 ManageServer1(MS1)或者 ManageServer2(MS2)的可迁移目标时，管理员可以将它们迁移。例如，如果管理员想要执行 JMS服务器的迁移，那么他/她必须将该 JMS服务器作为“ManagedServer1(可迁移的)”或者“ManagedServer2(可迁移的)”。您可以使用 WebLogic Server创建 JTA Transaction Recovery Service和 JMS Servers的单独的可迁移目标。这也允许您将每个服务在集群中的不同
8、WebLogic Server实例上保持运行。相反，您可以在服务器组中为 JTA和 JMS选择相同的服务器作为可迁移目标，以保证服务仍然共同位于集群中的相同服务器上。迁移工具WebLogic Server提供了基础件和工具，仅用于执行这些服务的手工迁移。这就意味着 WebLogic管理员必须手工执行这一过程以便将服务成功地从一个服务器实例迁移到另一个服务器实例。管理员可以使用 WebLogic管理控制台或者命令行界面工具来执行迁移过程。这将在本指南的后续内容中详细介绍。4.1 预迁移准备条件WebLogic Server 在子系统配置方面加入了某些约束和先决条件，以此来支持服务迁移。这些约束是
9、针对特定子系统的，同时也取决于顾客的企业应用程序架构。4.1.1 WebLogic 服务器级先决条件一个可迁移目标的所有受约束候选服务器必须属于相同的集群。4.1.2 JMS 子系统级先决条件JMS 存储必须进行配置，以使源服务器和目标服务器可以访问它们。如果应用程序使用基于 JDBC 的持久性（JMSJDBC存储），那么对于数据库实例的 JDBC 连接信息，例如数据源和连接池，必须在两个服务器上都存在。如果应用程序使用基于文件的持久性（JMS 文件存储），那么推荐使用 SAN（存储区域网络）或者双端口的 SCSI 磁盘。4.1.3 JTA 子系统级先决条件与 JMS 存储相似，JTA TLO
10、G 文件都必须以迁移过程中的源服务器和目标服务器都可以访问的方式进行配置。警告：JTA Transaction Recovery Service 只在源服务器实例结束时才可以迁移。4.1.4 服务器运行时状态和迁移支持表 2 服务器状态和迁移4.2 迁移后步骤4.2.1 当前活动主机无法连接时的迁移当您将服务从出现故障的或者管理员服务器无法访问的服务器实例中迁移出来时，还需要考虑一些特殊的问题。如果管理员服务器在您执行迁移时不能连接到该服务的以前活动主机，那么那个受控服务器的本地配置信息将不会更新以反映出它已不是宿主服务的活动主机。这种情况下，您必须在重启之前释放此无法连接到的受控服务器的本地
11、配置缓存。然后启动服务器，这就会防止以前活动主机重新激活已经被迁移至另一个受控服务器的服务。更多信息请参见“Migrating When the Currently Active Host Is Unavailable”，网址为：http:/e- Service Pack5 的 Windows 2000 上使用 WebLogic Server release 7.0。使用 WebLogic Server release 8.1 也可以完成相同操作。本节的操作指导假定您熟悉 Windows 环境。同时，本迁移过程通过具有两个节点集群的简单 WebLogic Server 域和一个设计精巧的管理服
12、务器来解释。WebLogic Server 实例被命名为“ManageServer1”和“ManageServer2 ”。整个迁移过程根据活动的逻辑分组，共为五个部分，如下图所示：第一部分：可迁移目标的配置 第二部分：与迁移过程有关的 JMS 配置第三部分：使用 WebLogic 管理控制台的迁移过程第四部分：使用命令行工具的迁移过程第五部分：使用 JMX 的编程方式迁移过程51 第一部分：可迁移目标配置这是在整个服务迁移过程中第一步也是主要的一步。理解它是很重要的。管理员应该在创建 WebLogic Server 实例之后的任何时间执行此步，但是需要在定位任何 JMS 服务器或者进行 JTA
13、 Transaction Recovery Service 迁移之前进行。在 WebLogic 域中的任何 WebLogic Server 实例在默认情况下可以看作是可迁移的目标。正如本文开始定义的那样，一个可迁移目标是一个虚拟的目标，具有一个或多个候选服务器，其中的一个可以作为活动服务器。默认情况下，创建每一个物理服务器实例并命名为“X”，也就同样创建了两个命名为“X”的配置实体。这两个配置实体将拥有相同的服务器实例“X”作为活动（用户偏好）的服务器，也就不会有任何的“候选服务器”。该可迁移“X（可迁移）”服务器的一个实例可以看作是在配置等级中的 WebLogic Server 实例的等价物
14、。它与 WebLogic Server 实例（使用域作为其上级）保持在相同的水平，并且它也被用于定位 JMS 服务器。更进一步，该可迁移服务器的另一个实例可以看作是服务器实例（因此 WebLogic Server 实例作为其上级）的一个元素，并且可用于进行 JTA 迁移。因此，配置可迁移目标的任务仅仅意味着将候选服务器列表加入到一个选定的 WebLogic Server 实例中。对于任何另外的管理任务，本步也通过使用管理控制台执行。将候选服务器加入到任何 WebLogic Server 实例的 JMS 迁移目标中，您必须如图 1 所示选定服务器的控制台标签。图 1 受控服务器 1 的控制标签注
15、意：当 WebLogic Server管理控制台附着于管理服务器（我们案例中的 AdminServer）时,整个域的信息可以被管理，而不管域中所有的其他服务器实例是否处于运行状态。511 配置 JMS 可迁移目标在我们的例子中，相同的集群中具有两个 WebLogic Server 实例，ManagedServer1 与 ManagedServer2 可以互相作为候选服务器。为将候选服务器加入“ManagedServer1”，您必须选择 ManagedServer1 的 Migration Config 标签，如图 2 所示。图 2 ManagedServer1 Control-Migratio
16、n Config（JMS）正如您所看到的，所有的可用 WebLogic Server实例的名称列于 Available标题下，所有的候选服务器列于 Chosen标题下。在这个例子中，因为我们没有选择任何服务器，所以 Chosen列表为空。下一步就是选择 Available列表中的候选服务器。为完成此项操作，选择（高亮显示）左边的服务器名称（我们例子中的 ManagedServer1和 ManagedServer2），然后单击右箭头按钮。控制台屏幕将如图 3所示。图 3 ManagedServer1-Control -Migration Config(JMS)此时，如果您想从 Chosen的候选服务器列表中删除任何一个 WebLogic Server实例，您可以高亮显示那
