本文共 7943 字,大约阅读时间需要 26 分钟。
本文将对 WebSphere Process Server 的运行时系统升级和移植策略进行全面系统的介绍,并结合一些典型的拓扑结构给出相应的参考实现。通过阅读本文,读者可以根据自己生产环境目前的状况,清楚、准确的选择相应的升级策略并加深对 WebSphere Process Server 产品的认识。
随着面向服务的架构(SOA)的概念日渐深入人心,越来越多的企业采用面向服务的架构来改造企业的现有 IT 架构或者升级企业的现有服务。WebSphere Process Server(简称 WPS)作为 IBM 面向服务架构战略的核心产品之一拥有众多的客户,IBM 于 2005 年底推出该产品的第一个版本 WPS6.0,并在随后的几年中陆续推出了几个新版本和一些补丁包,目前最新的版本是 WPS6.1.0.1。随着新版本的不断推出,已经在以前的 WPS 版本上部署应用的客户也非常希望利用新版本提供的丰富功能,但同时又希望保留原有的配置信息和部署的应用程序以节省投资和降低系统当机时间。WPS 提供的运行时升级功能可以满足客户的这个需求。然而对于不同的升级路径和 WPS 版本,客户需要采用不同的升级策略,目前 WPS 提供本地升级(In-place upgrade)和版本移植 (Version-to-Version migration) 两种形式的运行时升级支持 , 但是升级支持的文档信息比较分散,给客户和支持人员带来了一些困扰。本文将对 WPS 的升级策略进行系统的阐述并结合一些常见的拓扑结构给出具体的建议。通过阅读本文,读者将对 WPS 的运行时升级支持有个清晰的理解,可以更加准确的应用该功能升级自己的系统本文将对这两种更新方式进行系统的介绍并结合一些典型的拓扑结构给出了运行时更新的参考实现。
1.1 本地升级WPS 的运行时本地升级基于 WebSphere Application Server Network Deployment 的运行时本地升级系统。本地升级的过程可以用一个图形工具(Update Installer)来交互的安装 WPS 的补丁包,也可以用补丁包中提供的命令行工具来自动完成运行时的本地升级。需要的 Update Installer 的版本和要安装的 WPS 补丁包的版本有对应关系,在实际执行本地升级时要注意检查相关的版本信息,否则本地升级有可能遇到问题而失败。运行时本地升级是通过更新已有的 WPS 安装目录下的文件来实现的,以单个的 WPS 安装目录为单位,每次本地升级操作会将某一个安装目录下所有的概要(Profile),节点(Node)和服务器(Server)进行更新。已部署的应用程序可以在更新后的系统上继续运行,无需进行任何更改或重新配置操作。
2.2 版本移植WPS 从 V6.1 开始提供版本移植(Version-to-Version migration)功能。同本地升级类似,WPS 提供了图形化工具和命令行工具供用户选择。在进行版本移植前,需要在装有要移植的 WPS 系统的机器上安装最新版的 WPS,而且新版本 不 能装在和原有的 WPS 相同的安装目录内。版本移植是以单个概要(Profile)为操作单位,依次进行的。版本移植的过程分成两个大的阶段:在第一个阶段,移植工具会将低版本 WPS 概要(Profile)上的应用程序及配置信息备份到本机的一个临时目录;在第二个阶段,移植工具从临时目录读取信息,将其中的应用程序自动安装到新版本的 WPS 概要(Profile)上,并根据临时目录中已保存的配置信息对新版本概要(Profile)进行相应配置。移植后的新系统仍旧使用原来的数据库来存储信息,但数据表的 Schema 有可能会更新。移植完成后,原有的 WPS 系统可以被完全卸载也可以原封不动,但原有系统不能再被启动。
在上一章节中多处提到了 WPS 的版本信息,本地升级时对升级工具和 WPS 的补丁包都有版本要求。本章节将对 WPS 的版本划分策略做一个简单介绍。WPS 产品是基于 WebSphere Application Server Network Deployment ( 简称 WAS ND) 产品的,所以 WPS 采用和 WAS ND 相同的版本演进策略。版本信息最长用四个数字表示,数字中间以点号分割,表示为 Vx.y.m.n。x 位指示版本号(version),y 指示发布版号(release),m 指示改进版号(modification),n 指示修正版号(fix)。
由 Vx.y 表示的发布版本含有重要的功能更新,可以独立安装例如:V6.1;由 Vx.y.m 表示的升级包版本含有少量功能更新,一般不能单独安装,只能基于相应的发布版进行安装例如:V6.0.2;由 Vx.y.m.n 表示的修正版例如:V6.0.2.2 是最近发布的补丁(ifix)以及一些小的改动的集合,一般也不能单独安装。升级包版本和修正版本统称补丁包。除此之外,WPS 还会经常的发布一些单个的补丁对已发布版本中发现的问题进行及时的纠正。所有的补丁包都能从 下载。
虽然 V6.0 是 WPS 的第一个版本,但 v6.0.1 是推荐的可以用来作为升级或移植的起点的版本,目前已经推出的最新版本是 v6.1.0.1。v6.1 是一个里程碑版本,v6.1 之前的版本,只能通过版本移植来更新到 v6.1。在下图 3 中,分界线两侧集合中的任一低版本 WPS 可以通过本地升级方式更新到本集合中的任何一个高版本的 WPS,而左侧集合中的任何一个版本只能通过版本移植方式更新到右侧集合中的任何一个版本中。版本移植后的 WPS 也可以继续进行本地升级,例如 WPS v6.0.2 -> WPS v6.1 -> WPS v6.1.0.1。
WPS 本地升级的具体操作步骤和现有系统的拓扑结构有紧密的联系。本章节将列出一些典型的拓扑结构并给出其参考实现。
4.1 本地升级的注意事项独立概要服务器的拓扑(如图 4 所示)是最简单的一种拓扑,一般用在开发环境中。该拓扑结构的特点是只含有一个概要(profile),且该概要(profile)中只有一个应用程序服务器。
独立概要服务器拓扑本地升级的参考实现
注意: 指的是 WPS 的安装根目录,下同。 指的是配置了业务流程编排器(Business Process Choreographer )的概要名称。
4.3 不含集群(Cluster)的网络部署(Network Deployment)不含集群的网络部署拓扑结构(如图 5 所示)的特点是,单元(cell)中有一个部署管理器节点(Deployment Manager),该节点负责管理其它的节点(node),且部署管理器节点和其它的节点不在同一个安装目录下,但是该单元中不含任何的集群(cluster)。
不含集群的网络部署拓扑本地升级的参考实现
含有集群的网络部署拓扑(如图 6 所示)是最常用的生产环境拓扑,也叫做黄金拓扑(Golden Topology)或 ND7。该拓扑的特点是在单元(cell)中有一个部署管理器节点, 且该部署管理器节点单独占用一个 WPS 安装目录 。在其它的节点上有多个集群,其中有一个专门的消息集群(MECluster)为整个单元提供消息服务。在单元中有一个应用集群(APPCluster)用来部署业务流程编排器(Business Process Choreographer),还有一个支持集群(CEICluster)用来提供 CBE(Common Base Event)事件服务。
当部署管理器和某一个节点创建在同一个安装目录下(如图 7 所示)时,升级步骤和 步骤大致相同,唯一的区别是升级部署管理器时需要同时停止 Node01 的节点代理(node agent)以及 Node01 上的应用服务器,当在部署管理器安装目录应用补丁包时,Node01 以及 Node01 上的应用服务器是被同时升级的。
客户的环境对于升级过程中的停机时间是非常敏感的,客户总是希望在升级过程中系统停机时间越短越好,WPS 的本地升级对于客户的这个需求提供了支持。停止服务时间敏感的升级是一种升级的方式,被升级的系统中需要有水平集群(horizontal cluster)。以 为例,实施停止服务时间敏感的升级过程需要如下关键步骤:
版本移植使用不同于本地升级的工具来完成,本章以 WPSv6.1 作为目标版本,给出了版本移植的典型拓扑结构和参考实现。
6.1 版本移植的注意事项版本移植中的独立概要服务器的拓扑示意图和本地升级的相同,如 。
独立概要服务器拓扑版本移植的参考实现
对于 WPS 独立概要服务器拓扑,还支持跨机器的移植(仅支持 Windows 操作系统平台和 RedHat Linux 操作系统平台),这就需要在迁移之前,用 WPS 发布包里特别提供的的命令行移植工具对以前的环境进行备份,然后将备份文件拷贝到目标机器,再利用 WBIPostUpgrade 命令进行迁移。
6.3 不含集群(Cluster)的网络部署(Network Deployment)版本移植中不含集群的网络部署拓扑示意图和本地升级的相应拓扑相同,如 。
不含集群的网络部署拓扑版本移植参考实现
版本移植中含有集群的网络部署拓扑示意图和本地升级的相应拓扑相同,如
含集群的网络部署拓扑版本移植参考实现
同服务停止时间敏感的本地升级类似,WPS 也支持服务停止时间敏感的版本移植。在进行此类版本移植之前,也需要对拓扑中的水平集群进行仔细分析,将概要分类成几个集合,然后对集合中的概要分别进行移植。
在目前版本的 WPS 中,进行本地升级或版本移植的时候都需要把服务器停掉,即使是服务停止时间敏感的升级方法也会有一段停机时间,在这段时间内客户的系统是没有办法给外界提供服务的。这种停机时间在银行,电信等对停机时间高度敏感的行业会带来很大的负面影响。联机热升级(不停机升级)可以解决这个问题,WPS 在这个方面还需加强。
目前的 WPS 并没有一个统一的工具对升级或移植之后的系统进行验证,用户只能通过检查升级或移植过程中生成的日志文件来对系统进行初步的验证。一个准确的验证工具将大大方便最终用户。
通过阅读上面的章节用户会发现,对 WPS 进行升级或移植是一个繁琐的过程,急需要分析目前的拓扑,又需要执行一些很琐碎的命令。如果能仅仅通过点击少量的按钮就能完成升级或移植,将大大提升产品的用户满意度。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-417711/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-417711/