基于WAS 6.1的WebSphere Portal 6.1 Cluster配置详解

基于WAS 6.1的WebSphere Portal 6.1 Cluster配置详解

文档选项 <noscript></noscript> <noscript><tr valign="top"> <td width="8"><img alt="" height="1" width="8" src="//www.ibm.com/i/c.gif"></td> <td width="16"><img alt="" width="16" height="16" src="//www.ibm.com/i/c.gif"></td> <td class="small" width="122"><p><span class="ast">未显示需要 JavaScript 的文档选项</span></p></td> </tr></noscript> 打印本页 将此页作为电子邮件发送 <!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas --><!--END RESERVED FOR FUTURE USE INCLUDE FILES--> 级别： 初级 崔 烨 (yecui@cn.ibm.com), 软件工程师, IBM 郭 亮 (guoliang@cn.ibm.com), 软件工程师, IBM 2008 年 12 月 11 日 集群是搭建高可用性环境的有效解决方案之一，因此也成为 WebSphere Portal 支持的一项重要功能。本文将向您介绍 WebSphere Portal V6.1 集群的搭建过程，配置过程中经常遇到的问题及其解决方法。 <!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES--> Portal 集群简介 Portal集群基本结构 在 WebSphere Application Server 中，集群由应用程序服务器的多个相同副本组成，WebSphere Portal 服务器架设在WebSphere Application Server 基础结构之上，WebSphere Application Server 基础结构中可用的所有集群特性也适用于 WebSphere Portal。因此，WebSphere Portal 集群就是配置相同的多个 WebSphere Portal 服务器一起进行管理，并参与负载均衡的集合。 使用集群的优点具体表现在： 提高资源利用率 较高的可用性 提高容错能力 灵活负载均衡（负载均衡器设置负载均衡策略） 易于管理 良好的可扩展性 图 1. Portal 集群基本结构示意图 图1 是 Portal 集群的拓扑结构，包括单元（cell）、节点（node）、服务器（server）等基本概念。 在分布式 Portal V6.1 环境中，单元是一个单独的管理域。在一个单元中，我们通过部署管理器对单元中的所有资源进行集中管理。一个单元中可以包含多个集群。 集群是一起进行管理的多个服务器的逻辑集合，在集群中可以进行负载均衡和失效转移，每个集群可以包括多个节点。节点是服务器的逻辑组，每台物理机器 上只能有一个节点。每个节点可以包含一个或多个服务器。节点被单元中的部署管理器统一管理，并且它们的配置文件被中心化到单元主配置文件中。每个节点包含 一个节点代理，负责管理这些集中配置文件，并会将任何配置变化同步到每个节点上。 部署管理器用于在单元中保存所有的配置信息，并负责管理节点、服务器和各种资源的服务。 Portal 集群的主要类型 Portal 垂直集群 垂直集群是指让集群成员服务器位于同一节点或物理机器上（如图 2）。能够在现有设备上，充分利用硬件资源，提供更好的服务质量。 图 2.垂直集群示意图： Portal 水平集群 水平集群让集群成员位于单元中多台物理机器的节点上（如图 3）。水平集群利用多台机器资源，每台机器部署相同的应用。本文主要侧重水平集群，但是其中的很多概念也适用于垂直集群。 图 3.水平集群示意图： 回页首 集群的搭建过程 本文的目的是搭建一个如图 4 所示拓扑结构的水平集群。在这个集群中包括两个 Portal 节点（pvcent108 和 pvcent），一个远程部署管理器（pvcent123）和一个远程 Web 服务器（pvcent104）。 图 4.本文的集群拓扑结构图 步骤 1: 准备部署管理器 安装部署管理器 按照图 4 的拓扑结构，我们选用服务器 pvcent123.cn.ibm.com 作为创建部署管理器概要的主机。在目录”<wp_profile>/firststeps”使用命令”firststeps.sh”安装部署管理器概要文件。 从控制台选择“概要管理工具”选项，选择创建的部署管理器概要表，选择类型为[部署管理单元] Deployment Manager。 选择典型安装，并输入用户名和密码。 点击 Next，查看图 5 所示的部署管理器的信息。 图 5.用概要管理工具创建部署管理器概要文件 其中”Administrative console port”和”Deployment manager SOAP connect port”，在后续步骤中会用到。 点击 Create 按钮，创建部署管理器。 设置部署管理器超时时间 （1）增加超时时间 在 Portal 集群搭建的过程中，有些任务后台会进行较多的处理工作，为防止处理请求的时间过长导致请求失败，需要增加超时时间。在部署管理器安装完成后通过 http://pvcent123.cn.ibm.com:9060/ibm/console访问部署管理器控制台（9060 为上文记录的 Administrative console port）。 更改 HTTP 连接的最大时间，分别点击如下路径，更改时限读超时时间和写超时时间分别为 180 秒。 System Administration > Deployment Manager > Web container transport chains > WCInboundAdmin System Administration > Deployment Manager > Web container transport chains > WCInboundAdminSecure （2）进入以下路径更改“Java Management Extensions（JMX）connector”的请求时限为 6000 秒。 System administration > Deployment Manager > Administration Services > JMX connectors > SOAPConnector > Custom Propertie （3）在某些实例中，部署管理器响应 addNode 命令的时间可能比预期的长。缺省超时值（它确定客户机将等待服务器响应多长时间）适合于大多数情况。然而，您可能需要更多时间以便服务器在更繁重的处理条 件下响应。例如，如果您包括 -includeapps 选项并具有大量应用程序，或者应用程序非常大，那么缺省值 180 秒可能不够。要更改缺省超时值，在任何 ASCII 文本编辑器中打开文件“$WAS_HOME/profiles/<profile_name>/properties /soap.client.props”并查找以下行（此处显示了缺省值 180 秒） com.ibm.SOAP.requestTimeout=180 设置安全性 WebSphere Application Server V6.1 的安全性由 WebSphere Member Manager 管理，在部署管理器的控制台设置”Enable administrative security”和”Enable application security”。 Enable applications security Security > Secure administration, applications and infrastructure > Enable Applacation。 步骤 2: 准备 Portal 服务器 在需要搭建集群的节点上分别安装和配置 WebSphere Portal V6.1。 设置 Portal 用户名和密码 我们使用 wpsadmin 作为 Portal 和应用服务器的管理用户名和密码。 检查远程数据库链接 搭建集群需要配置使用远程数据库。Portal 安装时的缺省数据库是 derby，由于 derby 不能进行远程操作，所以 derby 不能作为集群环境的数据库。为了保证搭建集群时所有节点都可以和远程数据库进行连接，需要在每个节点执行以下步骤： 用文本编辑器打开 wkplc_dbtype.properties，并进行如下设置： db2.DbDriver = com.ibm.db2.jcc.DB2Driver db2.DbLibrary=<SQLLIB>/java/db2jcc.jar;<SQLLIB>/java/db2jcc_license_cu.jar db2.JdbcProviderName=wpdbJDBC_db2 用文本编辑器打开 wkplc_comp.properties，并进行设置。需要填写如下 6 个数据库域的信息： release customization community jcr feedback likeminds 对于上述六个数据库域分别设置以下属性信息： dbdomain.DbType dbdomain.DbName dbdomain.DbSchema dbdomain.DataSourceName dbdomain.DbUrl dbdomain.DbUser dbdomain.DbPassword 用文本编辑器打开 wkplc.propeties，并设置 wasAdminPwd 和 portalAdminPwd。 进入目录 <wp_profile>/ConfigEngine，执行如下命令验证填写的属性信息： ./ConfigEngine.sh validate-database-driver ./ConfigEngine.sh validate-database-connection 步骤 3: 创建集群并添加主节点 在配置集群时，ConfigEngine 配置任务能够根据属性文件 wkplc.properties 中 PrimaryNode 的值是 true 还是 false 来识别当前所配置的服务器是主节点还是从节点，从而执行不同的配置任务。 本节将分别对主节点和从节点的不同行为进行分析。 在主节点上配置远程数据库 数据库资源同其他资源一样，在创建到集群时，都是以主节点为模板同步到部署管理器中的。所以需要首先配置主节点上的远程数据库。 按照图 1 的拓扑结构，我们选用服务器 pvcent108.cn.ibm.com 作为主节点。进入目录 <wp_profile>/ConfigEngine，通过如下命令在其上配置远程数据库： ./ConfigEngine.sh database-transfer 收集并上传主节点信息 集群的配置是以主节点为模板的，所以我们需要收集主节点的配置信息，并上传到部署管理器中。 进入目录<wp_profile>/ConfigEngine 使用如下命令收集主节点信息： ./ConfigEngine.sh collect-files-for-dmgr 在主节点收集与集群相关的一些配置文件，并在”wp_profile_root/filesForDmgr”目录生成filesForDmgr.zip 文件包。 将 filesForDmgr.zip 文件包解压并上传到部署管理器相应的目录，然后重启部署管理器。 修改主节点的配置文件 wkplc.properties 表 1.修改主节点属性信息 Property Value WasUserid WebSphere Application Server administrator ID WasPassword WebSphere Application Server password PortalAdminId WebSphere Portal administrator ID PortalAdminPwd WebSphere Portal password WasRemoteHostName pvcent123 WasSoapPort 8879 PrimaryNode true ClusterName PortalCluster 为了能够同部署管理器进行通信，需要在主节点的 wkplc.properties 中填写部署管理器的机器名和 SOAP 端口，即WasRemoteHostName和WasSoapPort属性。 将主节点加入单元中 进入目录 <wp_profile>/ConfigEngine，使用命令”./ConfigEngine.sh cluster-node-config-pre-federation”将主节点加入到单元中。 如果WebSphere Application Server 与 Deployment Manager 的用户名密码不同，则需要指定 Deployment Manager 的用户名密码： -DDMgrUserid=dmgr_userid -DDMgrPassword=dmgr_pw。 cluster-node-config-pre-federation 主要执行了四个子任务： action-cluster-update-http-timeouts action-update-soap-client-props action-cluster-update-setupcmdline action-cluster-node-federation （1）action-cluster-update-http-timeouts 和 action-update-soap-client-props 完成了更改 HTTP 和 SOAP 的超时时间。当把节点加入到集群中时，需要将节点中所有的应用程序传送到部署管理器并以远程方式将它们安装到单元中。这个过程通常需要较长的时间，为了保证任务顺利完成需要增加超时时间。 （2）action-cluster-update-setupcmdline，通过编辑 setupCmdline.sh 文件，增加 Java 堆的大小。增大 Java 堆能够保证在做诸如添加大应用程序这样的操作时不会失败。增加的内容如清单 1： 清单1.增加 Java 堆的大小 JVM_EXTRA_CMD_ARGS=" -Djava.security.properties=$WAS_HOME/java/jre/lib/security/java.security -Xms256m -Xmx1024m " export JVM_EXTRA_CMD_ARGS （3）action-cluster-node-federation，将使用 WebSphere Application Server 提供的 addNode 命令将 Portal 节点加入到单元中。 当添加的节点为主节点时，cluster-node-config-pre-federation 任务会自动给 addNode 命令添加 –includeapps 参数，从而将主节点的应用程序传播到部署管理器中。当添加的节点为从节点时，将不使用 –includeapps 参数。 当完成 cluster-node-config-pre-federation 任务后，可以登陆部署管理器的管理控制台，查看节点已经加入到单元中了，如图 6 图 6.增加主节点到单元 并且所有资源也已同步到了单元中，如JDBC驱动程序，数据源和环境变量等。如图 7，进入Resources > JDBC > Data source，查看数据源： 图 7.同步数据源到单元 准备创建集群 进入目录 <wp_profile>/ConfigEngine，执行如下命令： ./ConfigEngine.sh cluster-node-config-post-federation。 此命令用于在节点的拓扑结构发生变化时清除主节点的预定任务。 更新 Portal 的管理员帐号 保证当前 Portal 的管理员用户名和组名在部署管理器中是有效的。否则，使用以下命令更改 Portal 的管理员用户名和组名。 执行下列任务更改 Portal 的管理员帐号： ./ConfigEngine.sh wp-change-portal-admin-user -DnewAdminId=uid=wpsadmin,o=defaultWIMFileBasedRealm –DnewAdminPw=wpsadmin -DnewAdminGroupId=cn=wpsadmins,o=defaultWIMFileBasedRealm 创建集群 进入目录<wp_profile>/ConfigEngine 执行下列任务创建集群。 ./ConfigEngine.sh cluster-node-config-cluster-setup （1）创建集群。将集群命名为 PortalCluster。 （2）移除节点级的资源。为避免重复资源对以后的资源定位带来的混淆，需要删除节点本身的资源，如 DataSource，cache，Workmanagers，Schedulers 和 URL Provider 等。 （3）主节点加入集群以后，将 JCR 的配置文件将移动到集群的路径中。 可以通过控制台看到图 8 中显示的拓扑结构的变化。 图 8.增加主节点作为集群成员 图 9 显示数据源 wpdbJDBC_sqlserver2005 的有效范围由构建前的 “Node=pvcen,Server=WebSphere_Portal”变为现在的“Cluster=PortalCluster”。 图 9.删除本地资源 步骤 4: 添加从节点 将从节点 pvcen 加入到配置管理器 进入目录<wp_profile>/ConfigEngine,执行下面的任务将从节点加入配置管理器中： ./ConfigEngine.sh cluster-node-config-pre-federation –DDMgrUserid=dmuser –DDMgrPassword=passw0rd 注意此时节点还没有加入到集群中。由于节点 pvcen 当前的数据库为 Derby，所以此时将 JDBC 提供者“Derby_JDBC_Provider”和 Derby 的数据源一起加入到集中管理器中。 从节点与主节点同步资源 执行命令 cluster-node-config-post-federation。 登录部署管理器控制台，如图 10 可以查看到此时在从节点上已经创建好了与主节点相同的 JDBC 提供者。 同时，这个任务还修改了 PortalServer 的名字。例如将之前的名字“PortalServerName”修改为“PortalServerName_nodeName”。 图 10.在从节点创建JDBC Provider 将从节点 pvcen 加入到集群 执行命令./ConfigEngine cluster-node-config-cluster-setup。 与主节点不同，执行任务cluster-node-config-cluster-setup 之前集群已经创建好。任务不需要再创建集群，只是把从节点 pvcen 加入到集群中，部署应用程序，删除本地资源，保存修改结果并且与集群中的所有其他节点同步。 如图 11 为加入节点 pvcen 后集群的拓扑结构图。 图 11.加入两个节点的集群拓扑结构 步骤 5: 安装和配置远程 Web 服务器和 Web 服务器插件 安装 Web 服务器 本文使用远程 IBM HTTP Server，远程 Web 服务器拓扑结构如图 12 所示 图 12.远程 Web 服务器拓扑结构 在部署管理器中加入 Web 服务器 （1）在 Web Servers 列表中，点击 New 按钮。 （2）输入 Web 服务器的节点信息，点击 Next按钮。 图 13.输入Web 服务器的节点信息 （3）选择 IBM HTTP Server 模板，点击 Next按钮。 （4）输入IBM HTTP Server 的管理认证端口和用户名密码，单击下一步。 上述步骤执行完后，可以在 Web 服务器列表中看到添加的 Web 服务器。 如图 14 单击 “Generate Plug-in”，生成用于 Web 服务器端的 plugin-cfg.xml。 接下来单击 “Propagate Plug-in” 按钮，将 plugin-cfg.xml 传播到 Web 服务器端相应的目录中。 图 14.生成 web 服务器插件 回页首 配置过程中的主要问题和解决方案 关于集群的安全配置的注意事项 （1）在 Portal 主节点加入部署管理器之前，部署管理器就已经配置好了安全性。缺省情况下，部署管理器利用 WAS 概要管理文件配置了基于文件的联合存储库。在搭建集群之前，这个基于文件的联合存储库可以对部署管理器的管理员帐户进行安全配置。 一个独立 Portal 节点在安装过程中就缺省配置了基于文件联合存储库。 搭建集群时，集群可以与 Portal 节点设置相同的安全配置，如选择下列的安全配置之一： filesysystem 联合存储库 LDAP 联合存储库 Database 联合存储库 CUR 联合存储库 LDAP 单机安全配置 CUR 单机安全配置 （2）在搭建集群之前，推荐的配置安全性的方法是保持基于文件的联合存储库直至集群搭建完毕。有两点需要注意的地方： 第一，在加入主节点之前要确认节点的应用服务器管理员，Portal 管理员和管理员组在部署管理器中已经创建好。 第二，基于文件联合存储库尽量不要设置成单用户或者是单组的存储库，创建至少两个用户和组。 （3）在集群搭建完毕以后，在主节点上配置联合存储库或者单机安全配置。 在配置过程中，如果更改节点的管理员或管理员组为部署管理器里新创建的用户或组，需要使用命令 wp-change-portal-admin-user 更新Portal 管理员/组，wp-change-was-admin-user 更新应用服务器管理员。 （4）如果单元所需要的安全性在搭建集群之前已经配置好，在集群搭建完毕后，这些 Portal 节点都会将继承部署管理器的配置，丢失自己的安全性配置。 任务 cluster-node-config-pre-federation 要求用户指定的应用服务器的用户名和密码能够通过部署管理器认证，随后会将 Portal 节点的用户名和密码更新为命令中所指定的信息。 单元的安全性为 LDAP 联合数据库和 LDAP单机安全配置时情况会有些不同： 首先，如果单元的安全性配置为 LDAP 联合数据库，那么主节点和从节点都不需要做任何工作，因为它们都可以从部署管理器概要下的文件 wimconfig.xml 中获得所需要的信息。 而如果单元当前为 LDAP 单机安全配置，那么就需要做一些额外的事情来获取信息。原因在于应用服务器不会将LDAP单机安全配置信息写入部署管理器概要下的文件 wimconfig.xml，所以在加入主节点之前，需要将所有需要的安全配置信息写入主节点的 wkplc.properties 文件中以备后用。在主节点加入部署管理器以后，部署管理器的 wimconfig.xml 也因为主节点的加入而包含了存储库的信息，这时再配置从节点就不需要做任何工作了。 按照如下步骤检查问题 （1）对于安装和配置过程中出现的问题，需要分别检查 <portal_server_root>/log/wpsinstalllog.txt 和 <portal_server_root>/log/configTrace.log。 （2）检查 HTTP 服务器插件的日志确认其没有问题。 （3）确认问题是出在一个集群成员上，还是整个集群当中。 （4）检查集群成员的 SystemOut.log 与 SystemErr.log。日志包含 WAS 和 Portal的信息。 （5）使用部署管理器的管理控制台检查配置情况。 （6）对于Portlet的部署和同步错误，需要检查节点代理和部署管理器的日志文件。 节点代理日志的缺省路径为“<profile_root>/logs/nodeagent”。 部署管理器的日志的缺省路径为“<profile_root>/logs/dmgr”。 常见问题及其解决方案 （1）由于单元安全配置的改变导致节点不能与部署管理器同步。 首先，在改变任何配置之前，作好部署管理器的备份工作。 当单元更改了安全配置以后，必须要在部署管理器重新启动之前将所有的节点同步，否则，当部署管理器的安全配置生效以后，节点却没有获得安全性的更新信息，此时节点将无法和部署管理器同步。 如果在部署管理器与节点同步之前，部署管理器已经重启，有如下两种解决的办法： 将部署管理器的安全性取消，恢复之前的备份。 将所有已经无法同步的节点从单元中删除，重新搭建集群。 （2）在集群搭建完成后，Portal 因为安全认证的问题不能启动。 按照以下步骤排查问题： 确认 Portal 管理员的用户名在部署管理器使用的用户存储库里是有效的。 确认 Portal 的管理员组在部署管理器的用户存储库中定义并且生效。 查看管理控制台此时是否可以增删查改用户和组，如果不能再查其原因。 如果 Portal 的用户名或者组名需要更改，不要只是把配置文件 wkplc.properties 中相应的值设置好，而是要用命令 wp-change-portal-admin-user，这个命令会同时同步所有的 Portal 配置如 icm.properties 和 Resource Environment Providers。 （3）不能使用 Portal 创建用户。 检查当前安全配置是不是使用的缺省的基于文件的联合存储库。 如果是，那么这只是应用服务器的使用限制，要求在使用基于文件的联合存储库时，只能通过管理控制台来管理用户。 （4）节点的配置信息丢失。 在加入某个集群以后，节点的配置都由部署管理器掌控，如果节点的本地配置做了更改，比如更改了“<was_root>/profiles/wp_profile/config”的一些信息，那么在下一次集群同步后，这些信息就会丢失。 因此，对于本地节点配置的更改，只可以作为本地的测试使用。如果希望是永久性的更改，就只能通过 DM 配置。 还有需要注意的一点是：对于文件的更改，部署管理器是“视而不见”的，所以部署管理器本身并不能自动同步所有的节点，所以更改以后，需要用户在部署管理器的控制台手动点“full Resynchronize”，如图 15 所示。 图 15. 部署管理器的 sync 按钮 （5）其他注意事项。 如果搭建的平台为 window 操作系统，需要注意的问题是很多平台都有对路径名的长度限制 - 最大长度为 256 个字节。因此单元名称，节点名称和包名要尽量使用短名。 时间同步问题，配置集群前要求各个节点的时间差在 5 分钟以内，否则不能进行同步。 回页首 结束语 随着电子商务的广泛应用，越来越多的企业希望搭建 Portal 集群环境以提高应用的扩展性和性能。本文针对用户的实际需求，详细介绍了如何搭建 Portal 集群环境以及搭建集群过程中的主要配置任务。 参考资料 WebSphere Portal 新手入门：您可以将这里作为学习 WebSphere Portal 的入口 。 Hello World: WebSphere Portal V6： 通过本教程，您将学会如何使用 Rational Application Developer 和 WebSphere Portal Test Environment 开发和测试您的第一个 Portlet。然后，您将使用 WebSphere Portal 将 Portlet 部署到生产环境中。 WebSphere Portal V6.1 信息中心：您可在这里找到 WebSphere Portal 有关规划、安装、配置、管理、开发和故障诊断的信息。 Web Application Server 产品专题：您可以在这里找到关于 WebSphere Application Server 的最新文章、教程等资源。 Web Application Server V6.1 信息中心：您可以在这里找到应用程序服务器的各种版本的文档。 WebSphere Portal 专区：为您提供了关于 WebSphere Portal 相关的文章、教程等资源。 developerWorks 中国网站 WebSphere 专区：为您提供了关于 WebSphere 产品相关的文章、教程等资源。 作者简介 崔烨于 2007 年加入 IBM CSDL WebSphere Portal 组工作，主要负责 Portal Configure wizard 的开发工作，目前的工作主要关注于 WebSphere Portal 的配置，并且用 wizard 帮助用户实现配置工作。 郭亮于 2007 年加入 IBM CSDL WebSphere Portal 组工作，主要负责 WCM WebSphere Portal 的测试工作。