dev2dev 首页 > 资源中心 > 技术文章
BEA WebLogic JMS和JTA迁移过程指南
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(可迁移的)”。
您可以使用WebLogic Server创建JTA Transaction Recovery Service和JMS
Servers的单独的可迁移目标。这也允许您将每个服务在集群中的不同WebLogic Server实例上保持运行。相反,您可以在服务器组中为JTA和JMS选择相同的服务器作为可迁移目标,以保证服务仍然共同位于集群中的相同服务器上。
迁移工具
WebLogic Server提供了基础件和工具,仅用于执行这些服务的手工迁移。这就意味着WebLogic管理员必须手工执行这一过程以便将服务成功地从一个服务器实例迁移到另一个服务器实例。
管理员可以使用WebLogic管理控制台或者命令行界面工具来执行迁移过程。这将在本指南的后续内容中详细介绍。
4.1 预迁移准备条件
WebLogic Server在子系统配置方面加入了某些约束和先决条件,以此来支持服务迁移。这些约束是针对特定子系统的,同时也取决于顾客的企业应用程序架构。
4.1.1 WebLogic 服务器级先决条件
一个可迁移目标的所有受约束候选服务器必须属于相同的集群。
4.1.2 JMS子系统级先决条件
JMS存储必须进行配置,以使源服务器和目标服务器可以访问它们。如果应用程序使用基于JDBC的持久性(JMSJDBC存储),那么对于数据库实例的JDBC连接信息,例如数据源和连接池,必须在两个服务器上都存在。
如果应用程序使用基于文件的持久性(JMS文件存储),那么推荐使用SAN(存储区域网络)或者双端口的SCSI磁盘。
4.1.3 JTA子系统级先决条件
与JMS存储相似,JTA TLOG文件都必须以迁移过程中的源服务器和目标服务器都可以访问的方式进行配置。
警告:JTA Transaction Recovery
Service只在源服务器实例结束时才可以迁移。
4.1.4 服务器运行时状态和迁移支持
表2 服务器状态和迁移
4.2 迁移后步骤
4.2.1 当前活动主机无法连接时的迁移
当您将服务从出现故障的或者管理员服务器无法访问的服务器实例中迁移出来时,还需要考虑一些特殊的问题。如果管理员服务器在您执行迁移时不能连接到该服务的以前活动主机,那么那个受控服务器的本地配置信息将不会更新以反映出它已不是宿主服务的活动主机。这种情况下,您必须在重启之前释放此无法连接到的受控服务器的本地配置缓存。然后启动服务器,这就会防止以前活动主机重新激活已经被迁移至另一个受控服务器的服务。
更多信息请参见“Migrating
When the Currently Active Host Is Unavailable”,
网址为:http://e-docs.bea.com/wls/docs81/cluster/setup.html。
5.迁移过程指南
本节介绍了实际迁移过程的分步指导,并配以此过程中使用不同实用程序和工具的屏幕截图。本过程执行的环境是在装有Service Pack5的Windows 2000上使用WebLogic
Server release 7.0。使用WebLogic Server release 8.1也可以完成相同操作。本节的操作指导假定您熟悉Windows环境。同时,本迁移过程通过具有两个节点集群的简单WebLogic Server域和一个设计精巧的管理服务器来解释。WebLogic Server实例被命名为“ManageServer1”和“ManageServer2”。
整个迁移过程根据活动的逻辑分组,共为五个部分,如下图所示:
第一部分:可迁移目标的配置
第二部分:与迁移过程有关的JMS配置
第三部分:使用WebLogic管理控制台的迁移过程
第四部分:使用命令行工具的迁移过程
第五部分:使用JMX的编程方式迁移过程
5.1第一部分:可迁移目标配置
这是在整个服务迁移过程中第一步也是主要的一步。理解它是很重要的。管理员应该在创建WebLogic Server实例之后的任何时间执行此步,但是需要在定位任何JMS服务器或者进行JTA
Transaction Recovery Service迁移之前进行。
在WebLogic域中的任何WebLogic Server实例在默认情况下可以看作是可迁移的目标。正如本文开始定义的那样,一个可迁移目标是一个虚拟的目标,具有一个或多个候选服务器,其中的一个可以作为活动服务器。
默认情况下,创建每一个物理服务器实例并命名为“X”,也就同样创建了两个命名为“X”的配置实体。这两个配置实体将拥有相同的服务器实例“X”作为活动(用户偏好)的服务器,也就不会有任何的“候选服务器”。
该可迁移“X(可迁移)”服务器的一个实例可以看作是在配置等级中的WebLogic Server实例的等价物。它与WebLogic Server实例(使用域作为其上级)保持在相同的水平,并且它也被用于定位JMS服务器。更进一步,该可迁移服务器的另一个实例可以看作是服务器实例(因此WebLogic
Server实例作为其上级)的一个元素,并且可用于进行JTA迁移。因此,配置可迁移目标的任务仅仅意味着将候选服务器列表加入到一个选定的WebLogic Server实例中。对于任何另外的管理任务,本步也通过使用管理控制台执行。
将候选服务器加入到任何WebLogic Server实例的JMS迁移目标中,您必须如图1所示选定服务器的控制台标签。

图1 受控服务器1的控制标签
注意:当WebLogic Server管理控制台附着于管理服务器(我们案例中的AdminServer)时,整个域的信息可以被管理,而不管域中所有的其他服务器实例是否处于运行状态。
5.1.1配置JMS可迁移目标
在我们的例子中,相同的集群中具有两个WebLogic Server实例,ManagedServer1与ManagedServer2可以互相作为候选服务器。
为将候选服务器加入“ManagedServer1”,您必须选择ManagedServer1的Migration Config标签,如图2所示。

图2 ManagedServer1
- Control->Migration Config(JMS)
正如您所看到的,所有的可用WebLogic
Server实例的名称列于Available标题下,所有的候选服务器列于Chosen标题下。在这个例子中,因为我们没有选择任何服务器,所以Chosen列表为空。
下一步就是选择Available列表中的候选服务器。为完成此项操作,选择(高亮显示)左边的服务器名称(我们例子中的ManagedServer1和ManagedServer2),然后单击右箭头按钮。控制台屏幕将如图3所示。

图3 ManagedServer1-Control ->Migration
Config(JMS)
此时,如果您想从Chosen的候选服务器列表中删除任何一个WebLogic Server实例,您可以高亮显示那个服务器的名称,然后单击左箭头按钮。
一旦您已经决定选择候选服务器,然后即可单击Apply按钮以创建“ManagedServer1(可迁移的)”候选列表。此时,ManagedServer1的可迁移目标被创建,同时候选服务器列表变为有效并且可以作为迁移服务器的主机。
注意:即使名称为“ManagedServer1(可迁移的)”, ManagedServer1和ManagedServer2都作为候选服务器。为使迁移过程有效工作,您应该在候选服务器列表中设置至少两个WebLogic Server实例。
5.1.2 配置JTA可迁移目标
为启动给定WebLogic
Server实例的JTA迁移,您需要将候选服务器添加到其可迁移的目标服务器。JTA迁移的Config标签/页可以完成这一操作。该过程与先前已经在5.1.1部分解释过的配置JMS可迁移目标相似。
本步骤中的config.xml文件的片断在附录1中提供。
5.2 第二部分:JMS子系统的配置
5.2.1 配置JMS存储
如4.1.2和4.1.3中所示,对于支持迁移的JMS持久性存储配置需要一些特殊要求,也就是说,这些存储必须被配置以使一个可迁移目标中的所有候选服务器可以访问该存储。
在这个指南中,JMS文件存储是用于持久存储信息的,因此文件存储文件夹创建于共享的磁盘驱动器如c:\myfilestore并且命名为MyJMSFileStore,如图4所示。

图4 配置一个JMS文件存储
注意:在真实的产品环境中,推荐使用基于SAN的磁盘阵列或者双端口的SCSI磁盘,它们可以提供高真实度和高性能。
5.2.2 配置JMS服务器
又如前所述,JMS服务器必须被配置才能参加迁移。两个重要的配置步骤为“存储选择”和“设定目标”。
5.2.2.1 为JMS服务器存储选择
当JMS服务器经配置以支持消息持久储存和/或消息分页时,您必须选择特殊配置以支持5.2.1部分所提及的“JMS服务器迁移”。因此,在本指南中,经配置的MyJMSServer在一个共享磁盘上使用MyJMSFileStore作为持久储存,如图5所示。

图5 配置JMS服务器并且与JMS文件存储相连
为迁移的JMS服务器配置的第二步就是“设定目标”。JMS服务器是可部署的实体,可以设定为WebLogic
Server的实例或者可迁移目标。当该可迁移目标的目前活动服务器被迁移时,只有设定为“可迁移目标”的JMS服务器会迁移至目的服务器。为设定可迁移目标,您必须单击Targets标签,然后单击Migratable
Target标签,从下拉框中选择一个项目,如图6所示。

图6 可用迁移目标列表
在本指南中,可迁移目标ManagedServer1(可迁移的)作为JMS服务器MyJMSServer的部署目标选定,如图7所示。

图7 可迁移目标的选择
5.3 第三部分:使用管理员控制台的迁移过程
5.3.1 JMS迁移过程
如上面所讨论,手工迁移过程可以通过使用管理控制台或者命令行工具而执行。
如第7页上的图2所示,JMS迁移过程可以在没有运行状态的源或者目标服务器而执行。因此,该例只有“管理服务器”处于运行状态,而源服务器(ManagedServer1)和目标服务器(ManagedServer2)并不处于运行状态。
下一步,转至源服务器(ManagedServer1)的Control Migrate标签,如下图8所示。

图8 ManagedServer1-Migrate标签(为使用JMS)
此时,通过单击Destination Server列表框,您可以验证所有可能的目标服务器。由于只有两个服务器配置为候选服务器,在任何给定时刻,可把一个服务器看作当前服务器而另一个为目标服务器。
单击“Migrate”按钮,启动迁移过程,屏幕中可见显示进度的状态,如图9所示。

图9 过程中的JMS迁移
在JMS迁移过程中,该服务器检查是否目标服务器处于运行或者非运行状态。如本例,如果目标服务器处于“非运行”状态,警告信息提示这一状态,如图10所示。

图10 目标服务器出现故障时的警告信息
此时,您可以通过单击“Continue”按钮继续迁移过程。图11至13展示了JMS服务器迁移过程的不同状态。

图11 目标服务器出现故障时的警告信息
图12 迁移状态-过程中

图13 JMS迁移状态-完成
5.3.2 JTA恢复服务的迁移过程
当源服务器出现故障而目标服务器启动时,使用控制台进行JTA迁移,该过程与JMS服务器迁移过程相似,如图14至18。

图14 ManagedServer1-JTA迁移的控制标签

图15 JTA迁移过程中

图16 警告源服务器出现故障
图17 JTA迁移过程中

图18 JTA迁移完成
5.4 第四部分:使用命令行工具的迁移过程
作为管理控制台的替代品,WebLogic
Server提供了命令行界面以执行管理任务。这一工具被称为webLogic.Admin。该工具的典型的命令行调用语法如下:
语法
java weblogic.Admin [-url URL] -username username
[-password password] COMMAND arguments
参数
许多WebLogic
Server命令需要下列参数。
|
参数
|
定义
|
|
URL
|
详见下述内容:
域的管理服务器的监听地址。在许多情况下,我们推荐您使用URL,因为它在管理服务器的安全环境中运行命令。
WebLogic Server的监听地址是命令的目标。如果您不能访问管理服务器而您想要设定受控服务器时,可以使用此URL。格式是主机名:端口。默认是localhost:7001。
注意:如果您想要指定一个管理端口,确定您的系统管理员已经创建了一个域中所有服务器实例的管理端口,请参见创建与配置WebLogic Server域指南中的“配置一个整个域的管理端口”
|
|
Username
|
用户名赋予用户完成服务器上特定URL参数请求的许可。更多有关系统管理任务许可的信息,请参见保护系统管理操作。
|
|
Password
|
密码与用户名相关联。如果您不设定密码参数,weblogic.Admin会要求您设定密码。如果WL_HOME\server\bin在PATH环境变量中指定,weblogic.Admin使用一套WebLogic
Server库来防止密码回响。更多有关设置环境变量的信息,请参见设置Classpath。
|
|
COMMAND
|
WebLogic管理命令的名称,配有适当的参数。一个这样的命令“MIGRATE”,可以使用户执行迁移任务,如下所示。
|
|
arguments
|
控制执行中的COMMAND行为的参数。
|
注意:如果管理客户端不能连接到服务器,那么对于所有的命令,退出代码为“1”。
表2 WebLogic Admin 命令行参数定义
这是MIGRATE命令与其参数的详细解释。
MIGRATE
-JMS服务和/或JTA
Transaction Recovery Service迁移至服务器集群中的设定服务器。
语法
java weblogic.Admin [-url URL] \
-username username \
-password password \
MIGRATE -jta \
-migratabletarget (migratabletarget_name|servername) \
-destination servername \
[-sourcedown] \
[-destinationdown]
|
参数
|
定义
|
|
-jta
|
指定迁移为JTA服务的迁移。
|
|
-migratabletarget
|
定义标志为服务迁出的服务器的配置文件。对于每个服务器,WebLogic Server都可以自动创建一个可迁移目标,命名为: “(服务器名称)_migratable” 面向JTA的JMS服务器名称。
这个可迁移目标是一个配置实体,指定了JMS服务与JTA
Transaction Recovery Service的偏好服务器。
|
|
-destination
|
服务将要转移至的服务器名称。
|
|
-sourcedown
|
指定源服务器出现故障。
警告:此命令应该谨慎使用。如果源服务器事实上没有故障,而只是由于网络原因连接不上,那么服务将会在目标服务器上被激活而不从源服务器移除,导致相同服务的两个同时运行版本。这将导致事务日志或者JMS消息的崩溃。
|
|
-destinationdown
|
指定目标服务器出现故障。迁移至非运行服务器的JMS服务将被丢失。当将JTA
Transaction Recovery Service迁移至非运行服务器时,目标服务器启动时将恢复服务。
|
表3 WebLogic Admin MIGRATE命令参数定义
例子
在下述例子中,一个JMS服务从myserver2迁移至myserver3。
|
java weblogic.Admin \
-url AdminHost:7001 \
-username adminuser \
-password adminpassword \
MIGRATE \
-migratabletarget myserver2(migratable)
\
-destination myserver3
|
在下列例子中,一个JTA Transaction Recovery Service与JMS服务(如果有的话)一起从myserver2迁移至myserver3。
|
java weblogic.Admin \
-url AdminHost:7001 \
-username adminuser \
-password adminpassword \
MIGRATE -jta \
-migratabletarget myserver2(migratable)
\
-destination myserver3 \
-sourcedown
|
5.4.1 JMS迁移过程
命令行迁移过程的第一步是设定环境。这可以通过使用如下所示的配置向导创建的脚本“setenv.cmd”实现。
|
C:\wls700sp5\user_projects\mydomain>setenv.cmd
|
环境设置完成后,我们如下调用命令行工具进行JMS迁移。注意:此时,假定我们想要迁移的JMS服务器运行于服务器“ManagedServer2”,它是可迁移目标“ManagedServer1(可迁移的)”的一部分。
|
C:\wls700sp5\user_projects\mydomain>java
weblogic.Admin -url t3://localhost:9001 -username wls_admin
-password wls_admin MIGRATE -migratabletarget
"ManagedServer1 (migratable)" -destination ManagedServer1
-destinationdown
|
下列消息将在从ManagedServer2到ManagedServer1成功迁移JMS服务器后打印出来。
|
Started attempt to migrate service(s)
for ManagedServer1 (migratable) to destination server ManagedServer1
…"
Migration succeeded.
Ok
|
5.5 第五部分:使用JMX的编程方式迁移过程
免责声明:本过程在其他任何地方没有文字记载,此处也没有任何技术支持或者担保。其作者或者BEA没有要求此解决方案的完整性与/或正确性的权利。此处解释的过程展示了用来发现错误情况以及执行JMS和JTA子系统服务编程迁移的技术。随着WebLogic Server后续版本的发布,此过程也可能改变。
有些情况下,用户想要在错误发现的同时自动将JMS服务从一个集群节点迁移到另一个节点。这就大大减少了迁移过程中管理员的手工介入。
就像手工迁移过程,同样也需要一些先决条件才能进行编程迁移过程。
第一步与(自动)编程迁移过程的先决条件都是通过发现JMS服务器的运行状况来查找JMS子系统故障。
本过程的第二步就是通过使用WebLogic节点管理器联合服务器生命周期的子系统机器编程来启动和关闭任何候选(源和/或目标)服务器。节点管理器是单独的“代理过程”,可以独立于WebLogic
Server而使用。一个单个的节点管理器实例/过程可以用来控制且监控其机器上的一个或多个WebLogic Server实例。启动节点管理器的命令行语法如下所示:
图19 节点管理器命令行语法
使用JMX监控JMS服务器运行状况以处理错误与迁移
WebLogic Server为所有子系统提供JMS运行时MBean,这些子系统包含关于该子系统的不同运行时的统计数据。
JMS子系统服务的运行时MBean包含该JMS子系统的重要统计信息,例如活动连接总数、JMS服务器总数以及在某一WebLogic
Server实例上的JMS子系统的整个运行时状态。
相似地,JTA子系统服务的运行时MBean包含该JTA子系统的重要统计信息,例如活动事务总数、不同原因下发生的回滚事务的总数以及JTA子系统的运行时状态。
用户利用JMS和JTA子系统的JMX运行时MBean的优势发现故障的情况并且采取正确的行动。
在这一部分,我将使用实例代码讲述,如何通过使用JMX发现JMS和JTA子系统的运行时状况,并且通过编程方式迁移那些子系统服务以防止/减少服务器故障时间。
示例代码
清单 1:
AutomaticMigration.java
这是主程序,监控服务器健康状况并且在状况不好的情况下执行迁移。
清单 2. HealthMonitor.java
本程序使用JMX运行时MBean发现并且报告JMS与JTA子系统的健康状况。
清单 3. MigrationHelper.java
本程序执行JMS和/或JTA子系统的实际迁移过程。
|
//-----------------------------------------------------------------------------//
// Listing 1. AutomaticMigration
//-----------------------------------------------------------------------------//
public class AutomaticMigration
{
public static
void main(String[] args) {
if
(args.length < 8) {
System.out.println(
"Usage: AutomaticMigration <admin url><source server>
" +
"<username> <password> " +
"<destination
server> " +
" <source up><dest up> " +
" <migrate jta>");
System.exit(1);
}
String
adminurl
= args[0];
String
sourceServerName = args[1];
String
username
= args[2];
String
password
= args[3];
String
destination
= args[4];
boolean
sourceup
= new Boolean(args[5]).booleanValue();
boolean
destup
= new Boolean(args[6]).booleanValue();
boolean
migrateJTA
= new Boolean(args[7]).booleanValue();
HealthMonitor
hm = null;
try
{
hm = new HealthMonitor(sourceServerName, /* server name */
adminurl, /*
url */
username, /*
username */
password
/* password */
);
}
catch(Exception e) {
System.out.println("Error creating HealthMonitor, "
+ e.getMessage());
System.exit(1);
}
while
(hm.checkHealth()) {
try {
Thread.sleep(5000);
} catch (InterruptedException ignore) {}
Thread.yield();
}
//
prepare for migration
String
mtName = sourceServerName + " (migratable)";
try
{
MigrationHelper.migrate(adminurl, /* admin
url */
username, /* admin username */
password, /* admin password */
mtName, /* migratable target */
destination, /* destination server */
sourceup, /* source server up */
destup, /* destination server up
*/
migrateJTA /* migrate JTA */
);
}
catch (Exception e) {
e.printStackTrace();
System.out.println("Migration failed" + e);
}
}
}
|
清单 1. AutomaticMigration.java
|
//-----------------------------------------------------------------------------//
// Listing 2. HealthMonitor
//-----------------------------------------------------------------------------//
import java.util.Hashtable;
import java.util.Date;
import java.net.URL;
import java.net.HttpURLConnection;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.management.InstanceNotFoundException;
import weblogic.management.MBeanHome;
import weblogic.management.configuration.ServerMBean;
import weblogic.management.runtime.JMSRuntimeMBean;
import weblogic.management.runtime.JTARuntimeMBean;
import weblogic.health.HealthState;
public class HealthMonitor
{
private String
serverName;
private String
adminurl;
private String
username;
private String
password;
private InitialContext
adminIC; // admin server initial context
private MBeanHome
adminMH; // admin server mbean home
private InitialContext
ic; // managed server mbean home
private MBeanHome
mh; // managed server mbean home
private boolean
debug = false;
private ServerMBean
server = null;
private JTARuntimeMBean
jta = null;
private JMSRuntimeMBean
jms = null;
public HealthMonitor(
String
serverName,
String
adminurl,
String
username,
String
password
) throws
Exception {
this.serverName
= serverName;
this.adminurl
= adminurl;
this.username
= username;
this.password
= password;
try
{
this.ic = getInitialContext(adminurl, username, password);
}
catch(NamingException ne) {
System.out.println(
"Cannot get Initial Context with " + adminurl + "\n"
+ ne);
throw new Exception(ne.getMessage());
}
try
{
this.adminMH = (MBeanHome)ic.lookup(MBeanHome.ADMIN_JNDI_NAME);
}
catch(NamingException ne) {
System.out.println("Admin MBean Home could not be found\n"
+ ne);
throw new Exception(ne.getMessage());
}
try
{
this.server = (ServerMBean) adminMH.getMBean(serverName, "Server");
}
catch(InstanceNotFoundException infe) {
System.out.println("JMSRuntimeMBean could not be found\n"
+ infe);
throw new Exception(infe.getMessage());
}
try
{
String managedURL = new String("t3://"+
server.getListenAddress()+":"+
server.getListenPort());
this.adminIC = getInitialContext(managedURL, username, password);
}
catch(NamingException ne) {
System.out.println(
"Cannot get Initial Context with " + adminurl + "\n"
+ ne);
throw new Exception(ne.getMessage());
}
try
{
mh = (MBeanHome)ic.lookup(MBeanHome.JNDI_NAME+"."+serverName);
}
catch(NamingException ne) {
System.out.println("Admin MBean Home could not be found\n"
+ ne);
throw new Exception(ne.getMessage());
}
try
{
jms = (JMSRuntimeMBean) mh.getRuntimeMBean(serverName+".jms",
"JMSRuntime");
}
catch(InstanceNotFoundException infe) {
System.out.println("JMSRuntimeMBean
could not be found\n" + infe);
throw new Exception(infe.getMessage());
}
try
{
jta = (JTARuntimeMBean) mh.getRuntimeMBean("JTARuntime",
"JTARuntime");
}
catch(InstanceNotFoundException infe) {
System.out.println("JTARuntimeMBean could not be found\n"
+ infe);
throw new Exception(infe.getMessage());
}
}
public boolean
checkHealth() {
HealthState
jmshs = jms.getHealthState();
HealthState
jtahs = jta.getHealthState();
boolean
isJMSOk = (jmshs.getState() == HealthState.HEALTH_OK);
boolean
isJTAOk = (jtahs.getState() == HealthState.HEALTH_OK);
System.out.println("JMS
Health is checked on " + serverName +
" @ " + new Date(System.currentTimeMillis()) +
", and the health "
+ jmshs);
System.out.println("JTA
Health is checked on " + serverName +
" @ " + new Date(System.currentTimeMillis()) +
", and the health "
+ jtahs);
if
(isJMSOk && isJTAOk) {
return true;
}
else {
return false;
}
}
private
InitialContext getInitialContext(
String
ur,
String
user,
String
pwd
) throws
NamingException {
Hashtable
env = new Hashtable();
env.put(Context.PROVIDER_URL,
ur);
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL,
user);
env.put(Context.SECURITY_CREDENTIALS,
pwd);
return
new InitialContext(env);
}
}
|
清单 2. HealthMonitor.java
|
//-----------------------------------------------------------------------------//
// Listing 3. Migration Helper
//-----------------------------------------------------------------------------//
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;
/**
* This class
forms the weblogic.Admin command line syntax for
* MIGRATE
command from the arguments and executes
* java weblogic.Admin
[-url URL] -username username -password password \
*
MIGRATE -jta -migratabletarget (migratabletarget_name|servername) \
* -destination
servername [-sourcedown] [-destinationdown]
*/
public class MigrationHelper
{
public static
void migrate(String adminURL, String adminUsername,
String
adminPassword, String migratableTargetName,
String destinationServerName, boolean sourceUp,
boolean destUp, boolean migrateJTA) throws Exception {
//
form the command line syntax for weblogic.Admin MIGRATE command
StringBuffer
sb = new StringBuffer();
sb.append("java
weblogic.Admin");
sb.append("
-url " + adminURL);
sb.append("
-username " + adminUsername);
sb.append("
-password " + adminPassword);
sb.append("
MIGRATE ");
sb.append("
-migratabletarget " + migratableTargetName);
sb.append("
-destination " + destinationServerName);
if
(!sourceUp) sb.append(" -sourcedown ");
if
(!destUp) sb.append(" -destinationdown ");
if
(migrateJTA) sb.append(" -jta ");
Runtime
runtime = Runtime.getRuntime();
Process
proc = runtime.exec(sb.toString());
//
put a BufferedReader on the weblogic.Admin output
InputStream
is = proc.getInputStream();
InputStreamReader
isr = new InputStreamReader(is);
BufferedReader
br = new BufferedReader(isr);
//
read the weblogic.Admin output
String
output;
while
((output = br.readLine()) != null) {
System.out.println(output);
}
//
check for weblogic.Admin command execution failure
try
{
if (proc.waitFor() != 0) {
System.err.println("weblogic.Admin MIGRATE command exit
value = " + proc.exitValue());
}
}
catch (InterruptedException e) {
System.err.println(e);
}
}
}
|
清单 3. MigrationHelper.java
6. 参考资料
1.WebLogic文档——集群中的故障恢复和复制,网址为:http://e-docs.bea.com/wls/docs81/cluster/failover.html#DefiningMigratableTargetServersinaCluster
7. 附录1:配置可迁移目标的Config.xml代码片断
|
<MigratableTarget Cluster="mycluster"
ConstrainedCandidateServers="ManagedServer2,ManagedServer1"
Name="ManagedServer1
(migratable)"
Notes="This
is a system generated default migratable target for a
server. Do
not delete manually."
UserPreferredServer="ManagedServer1"/>
<Server Cluster="mycluster"
ExpectedToRun="false"
ListenAddress="localhost"
ListenPort="7001"
Name="ManagedServer1"
NativeIOEnabled="true"
ServerVersion="7.0.5.0">
<COM Name="ManagedServer1"/>
<ExecuteQueue
Name="default" ThreadCount="15"/>
<IIOP Name="ManagedServer1"/>
<JTAMigratableTarget
Cluster="mycluster"
ConstrainedCandidateServers="ManagedServer2,ManagedServer1"
Name="ManagedServer1"
UserPreferredServer="ManagedServer1"/>
<TARecoveryService
Name="ManagedServer1"/>
<KernelDebug
Name="ManagedServer1"/>
<Log Name="ManagedServer1"/>
<SSL Enabled="true"
HostnameVerificationIgnored="true"
ListenPort="7002"
Name="ManagedServer1"
ServerCertificateFileName="democert.pem"
ServerPrivateKeyAlias="demokey"
ServerPrivateKeyPassPhrase="{3DES}qmMR/wLVNPjGmnLz/kxKEg=="/>
<ServerDebug
Name="ManagedServer1"/>
<ServerStart
Name="ManagedServer1"/>
<WebServer
Name="ManagedServer1"/>
</Server>
<MigratableTarget Cluster="mycluster"
Name="ManagedServer2
(migratable)"
Notes="This
is a system generated default migratable target for a
server. Do
not delete manually."
UserPreferredServer="ManagedServer2"/>
<Server Cluster="mycluster"
ListenAddress="localhost"
ListenPort="8001"
Name="ManagedServer2" NativeIOEnabled="true"
ServerVersion="7.0.5.0">
<COM Name="ManagedServer2"/>
<ExecuteQueue
Name="default" ThreadCount="15"/>
<IIOP Name="ManagedServer2"/>
<JTAMigratableTarget
Cluster="mycluster" Name="ManagedServer2"
UserPreferredServer="ManagedServer2"/>
<JTARecoveryService
Name="ManagedServer2"/>
<KernelDebug
Name="ManagedServer2"/>
<Log Name="ManagedServer2"/>
<SSL Enabled="true"
HostnameVerificationIgnored="true"
ListenPort="8002"
Name="ManagedServer2"
ServerCertificateFileName="democert.pem"
ServerPrivateKeyAlias="demokey"
ServerPrivateKeyPassPhrase="{3DES}qmMR/wLVNPjGmnLz/kxKEg=="/>
<ServerDebug
Name="ManagedServer2"/>
<ServerStart
Name="ManagedServer2"/>
<WebServer
Name="ManagedServer2"/>
</Server>
|

| 作者简介 |
|
Kathiravan Sengodan具有超过11年的载软件行业经验。目前,他是BEA WebLogic JMS/Messaging组的一名软件工程师。 |
作者其它文章
|