BEA WebLogic JMS和JTA迁移过程指南.doc

BEA WebLogic JMS和JTA迁移过程指南 浏览次数： 768 时间：2004-09-08 作者：Kathiravan Sengodan 1. 简介 本文详细解释了WebLogic Server迁移过程，并且通过提供详细的指导，配以过程中每个关键步骤的截图，为执行手工迁移过程的WebLogic Server管理员提供了指导。本文还提供了在WebLogic Server NodeManager的帮助下使用JMX以编程方式执行迁移过程的指导和例子。 下载作者提供的与本文相关的文件。 2. 范围 本文详细描述了有关JMS与JTA服务迁移的过程。不涉及任何其他服务迁移过程。 3. 术语和定义 术语 定义 可迁移服务 可以从一个WebLogic Server实例迁移到另一个实例并且不会丢失服务相关数据的任何服务。 目标 可以做为主机并充当不同J2EE子系统服务容器的WebLogic Server的被管理实体。 集群目标 一个或多个服务器集群在一起，作为一个通过复制和共享公共资源（例如JNDI等）来提供集群服务的实体。 服务器目标 单个WebLogic Server实例。 可迁移目标 包含一个或多个候选服务器，但任何时侯都只有一个活动服务器的虚拟目标。 候选服务器* 在迁移过程中可以作为用户首选服务器的备用服务器列表。 用户首选服务器 宿主已部署J2EE服务的当前活动服务器。 源服务器 服务迁移“出”的服务器实例。 目标服务器 服务迁移“到”的服务器实例。 JMS Java消息服务 JTA Java事务服务 JDBC Java数据库连接 JMX Java管理扩展 SAN 存储区域网络 TLOG 事务日志 ?????? *列表中作为可迁移目标的服务器属于相同的集群。 4. WebLogic Server迁移与相关基础件 某些特定的WebLogic Server服务，例如JMS与JTA Transaction Recovery Service，都遵照这样一个假设进行设计，即：在任何给定时刻只有一个服务的活动实例运行于特定集群节点。这些类型的服务被称为“置顶（pinned）”服务，因为它们在某一时刻只在一个服务器实例上保持活动。 WebLogic Server允许管理员将这些置顶服务从集群中的一个服务器实例迁移到另一个实例上，以解决服务器故障或者部分日常维护问题。这一能力提高了这些置顶服务在集群中的可用性，因为一旦主服务器出现故障，那么其上的服务就可以在一台冗余服务器上重启。 注意：目前，WebLogic Server不支持对于置顶服务的自动迁移（故障恢复）。参见本文5.2.5节，其中介绍了执行编程方式迁移的无文档记载的方法。 目前，迁移仅仅支持JMS服务器和JTA Transaction Recovery Service。本文中将这两种服务统称为可迁移服务。 JMS服务器的迁移可以独立于JTA Transaction Recovery Service。不过，既然JTA Transaction Recovery Service给其他子系统服务提供了事务控制，那么它也常常随着其他子系统服务而迁移。这就在子系统服务迁移之前和之后都保证了事务的完整性。 WebLogic Server迁移基础件包括不同的服务器组件和工具，如下所示： 可迁移目标 默认状态下，WebLogic Server可以将JTA Transaction Recovery Service或者JMS服务器迁移至同一集群中的任何其他WebLogic Server实例。您可以有选择地配置集群中的服务器列表，以使其具备潜在的宿主置顶服务的能力。服务器列表即指一个可迁移的目标，并且它控制您可以迁移的服务器，即服务。 定义集群中的可迁移目标服务器 例如，下图展示了具有两个集群的WebLogic Server域配置。集群1包括配置好的WebLogic Server实例MS1、MS2和MS3。集群2包括配置好的WebLogic Server实例MS4、MS5、MS6和MS7。ManagedServer1 (MS1) 使用ManagedServer2 (MS2)作为迁移时的候选服务器，同时ManagedServer2 (MS2) 使用ManagedServer1 (MS1)作为迁移时的候选服务器。 图1一个典型的WebLogic域配置 在上例中，当置顶的JMS服务器部署为ManageServer1(MS1)或者ManageServer2(MS2)的可迁移目标时，管理员可以将它们迁移。例如，如果管理员想要执行JMS服务器的迁移，那么他/她必须将该JMS服务器作为“ManagedServer1(可迁移的)”或者“ManagedServer2(可迁移的)”。 您可以使用Web