聚沙成塔-小哈的记事薄

有了最早的安装WAS6.0和上两篇文章的介绍，接下来安装集群的过程其实很简单。

对于新安装的集群：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个Custom profile，建立过程中就完成联合节点工作
4. 启动两个node中的nodeagent
5. 进入控制台，新建集群，分别在两个节点添加application server

如果新建Custom profile时出现问题，或者更多的情况是想把原来已经建立好的，带有应用的application server profiles联合到DM中来建立集群，那么：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个application server profile（或者原先已经有了）
4. 到profiles/bin目录下执行addnode命令：addnode DM所在IP或主机名 8879（端口）-includeapps（如果有应用的话）-username {用户名} -password {密码}
5. 启动app profiles下的nodeagent
6. 进入控制台，新建集群，用已经存在的application转化为cluster的member

复习一下安装profile的过程

安装DM profile

建立application server profiles

看一下如何新建集群：注意先运行addnode命令，然后启动node agent

看明白了么？没琢磨清的来这里：WebSphere v5 ND在AIX环境中安装和配置

WebSphere V7.0在Windows下的集群配置

还有一份在Unix/Linux下配置V6.1的集群文件比较大，Google Docs无法上传，其实和V7.0没有差别，照着V7做就可以了。传到了纳米盘，《WebSphere v6.1 ND在Unix&Linux环境中安装和配置》，由IBM应用开发合作中心撰写。步骤清晰，图文并茂，最重要是中文。从WebSphere Application Server、IHS、Plugins的安装配置，到WebSphere集群的搭建、节点代理程序（Node agent）的起停方法、如何生存和传播Webserver插件，回话（Session）复制，如何安装补丁。居家旅行必备文档啊

WebSphere v6.1 ND在Unix_Linux环境中安装和配置.pdf

微软的SkyDrive的嵌入方式使用的是iframe，wordpress在2.2之后就不支持iframe语法，所以大家点进去下吧。

紧接上文，我们了解了Application Server，profiles，Managed Node、Umanaged Node等概念，知道了最简单的stand-alone拓扑结构。那为了弥补stand-alone模式的可扩展性（Scalability）可靠性（reliability）要求，有必要提出Cluster的解决方案。

       这副图里我们可以看到分布在两台Machine上的两个Node，每个Node含有三个Application Server，其中两个Server与另一个Node中的两个Server构成了Cluster，这个Cluster通过Node agent被一个Deployment Manager管理。同时我们可以看到每个Node另有一个单独的Application Server，这个Server和之前介绍的Stand-alone application server可以看作是等价的，只是现在被加入到Network Deployment中，接受DM的统一管理。整个的绿色大背景则是一个单元（Cell）。

术语四 Deployment Manager（DMgr）：在分布式拓扑中管理一个或多个节点的特殊profile，通过Node agent把配置和管理动作传达到每个Node中的Server上。可以通过PMT工具建立DM profile，它包含了主配置库，以及各个节点上有的配置文件——启动这个节点所需的XML配置和应用程序文件 。由此可见，各个节点的配置文件是DM上有的子集，所以当我们修改节点上应用里WEB-INF下的诸如web.xml文件，除了在节点上的config目录中要做相应修改，DM节点上config目录里同样要修改，否则重启dm后，一切配置信息将同步到和DM里有的状态。

术语五 单元（Cell）：是一个逻辑上的管理域的称呼，提供了对节点的单独管理入口，这个域由跨多台主机上的Node和一个DM组成，

了解了以上这些术语，那集群的概念就很简单：集群就是一组多个Application Server组成的group，运行着同样的应用程序。一个集群可以运行在一个Node上，或者同一台机器的不同node上（垂直集群），可以运行在不同机器的不同Node上（水平集群）。由此提供故障转移。配合web server，则能做到负载均衡。

有了这些概念，再大的Topology都不怕。

下文将讲述建集群的详细操作步骤。

/**   下文是我根据自己一年多的工作经验，结合IBM的PPT写成，如果你觉得表述的不是很明白，可以前往阅读IBM官方文档IBM WAS ND 分布式网络环境的理解与集群的实现。**/

在Websphere入门篇（一）-was6.0安装中，我们配置了一个Websphere Application Server，前端联合了一个Http Server，后端连接Oracle数据库。这是WebSphere最简单的拓扑结构——带Web服务器的单机环境（Stand-alone Application Server Topology with Web Server ）

Stand-alone Application Server拓扑方式的安装是指在一个单独的节点上（Node）运行一个（仅能一个）Application Server进程的安装方式。如果你需要多个Application Server，那么你就要起多个profiles，而在ND环境中一个Profile可以起多个Application Server。在Stand-alone的环境下，Web服务器只能定义一个，ND环境下则无此限制。

术语一 Application Server：一个为J2EE应用提供了web容器、EJB容器、Naming、JMS等服务，同时提供配置和管理功能的运行平台。在Windows、Unix等分布式操作系统上，一个Server单只一个JVM实例，我们看到的就是一个java进程；但在z/OS平台上，一个Server可以包含多个操作系统进程，每个进程都单独运行一个JVM实例。

术语二 WebSphere profiles：一个application server所需要用到的User files的集合，包括诸如环境变量是如何设定的、各种资源是如何配置的、日志文件的记录格式……所有的这些构成了application server的运行时环境。

与之相对应的是Product files——运行application server所需要的二进制文件，这些二进制文件是各个profiles共享的。因为只有这一份二进制文件集，所以websphere代码的变更，比如补丁的升级，可以被旗下所有的profiles享用到，无需为每一个Profiles单独操作，节省了磁盘空间。

由此可知，如果需要为不同的应用使用不同的补丁版本，或者为某个应用打一个小fix，那么只能重新安装一个完整的WAS程序，而不仅仅是单独建立一个profile。而不同机器间WAS的迁移，也必然不能简简单单的拷贝WAS安装目录了事，至少需要安装WAS程序，profiles因为是配置的集合，和机器的相关性比较小——主机名、端口号等配置还是需要注意的——可以“偷懒”拷贝一下。

术语三 节点（Node）：节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。

分为Managed Node：可以被Deployment manager管理，在ND环境下的application server必然是Managed Node，同时也会有一个对应的Node agent，通过在profile name/bin目录下运行startNode命令，可以让DM来管理application server。当一个Stand-alone的application server联合到ND环境下时，Node agent会自动生成，当然之前是没有的。

与之对应的是Unmanaged Node：顾名思义是无法直接通过DM来管理的节点，一般是作为Web Server所在节点存在的，特别是当Web server位于DMZ区，而app server位于防火墙之后。虽然是Unmanaged Node，但是生成插件、传播插件是可以的，只是起停web server需要手动执行。

摘自WebSphere Application Server 常见问题及解答：什么是单元（Cell）？什么是节点（Node）？Node、Profile 与 Server 之间的关系是什么？

如果stand-alone的结构无法满足应用程序的可扩展性（Scalability），可靠性（reliability）要求，那么我们就需要使用Network Deployment Topology，进而配置Cluster来满足以上两个要求。具体见下文。

Wii是WebSphere Information Integrator的简称，原先是DB2中的一个组件，现在是单独的软件包，包括Websphere Federation Server，Websphere Replication Server和Websphere Data Event Publisher。现在WII又改名成Infosphere information Integrator，所以搜索找资料的时候，注意关键词的选用。

我这次装的版本是RepServ_9.5_Win_32-bit，补丁打到了sp2，sp3补丁地址见文中。

安装主机

192.16.29.234

Oracle 9.2.0.7，本地建立客户端并配置好

192..16.29.235:1521 sid:reposity

选择安装目录

选择需要安装的包装器

勾上简体中文语音

填入本地以创建的一个具有管理员权限的用户

安装完成。

阅读全文…

最近一个项目在做压力测试的时候，压力测试人员设置完脚本运行8小时后，第二天总会发现虽然脚本运行正常，但是有一个节点上的Server没有相应。查看日志说日志没有任何报错，记录的最后一条总是前一天的半夜。因为半夜正好是做批处理的时候，一开始怀疑是否是这导致的宕机，但是停掉批处理程序后依旧发生这种现象（而且是在下班时刻发生），也就排除了这个可能。

下面是我的排错经过：

查看无法提供服务的app2的systemout.log日志，发现从昨天晚上5点09分后，没有新的日志输出。最后的日志为

查看system.err文件，没有发现有价值的内容

于是查看ffdc目录下的17：09生成的日志，在APP2_7b2c7b2c_09.04.15_17.09.27_0.txt中发现有Stack Dump = javax.imageio.IIOException: Can’t create output stream!信息。

于是使用ulimit –a命令查看AIX的limit参数

发现一个进程可以打开的最大文件数为2000.

用ps –ef | grep java命令找到app2的sid，然后用procfiles sid命令查看app2的进程现在打开了多少文件

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/bin#procfiles 815304

815304 : /was/IBM/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.sock

Current rlimit: 2000 file descriptors

………………

1993: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1994: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1995: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1999: S_IFREG mode:0444 dev:10,15 ino:164300 uid:0 gid:0 rdev:0,0

O_RDONLY size:1042

打开文件数已经到达2000，于是app2无法创建新的systemout.log日志文件，也就无法再提供服务。

由此分析得AIX的nofiles参数对于websphere来说不够大（对于Hp-ux，安装前调整系统参数时就需要把maxfiles调整为8192，但是AIX内核是自调整，所以IBM安装要求上没有提到需要手动修改什么参数）特别是在压力测试时候，短时间内的积累可能会达到2000的限制，实际生产环境中也可能会遇到如此情况，当然集群中另外一台APP跑的好好的也挺让人奇怪。

接下来就是调整ulimit中的nofiles限制到4096，然后重启nodeagent，再由控制台重启app即可。当然也可以直接用命令重启app，但是因为nodeagent没有重启过，环境变量没有生效，下次在控制台中重启app后nofiles依旧会被限制在2000。

1        WebSphere配置

1.1      通过 http://hostname:9060/admin进入Websphere 管理控制台，并用管理员用户登录

1.2      设置Oracle驱动环境变量（针对Oracle数据库）

1.2.1   将oracle的java驱动ojdbc14.jar复制到…/WebSphere/AppServer/lib/ext目录中。

1.2.2   修改数据库驱动环境变量

Ø        进入”环境àWebSphere变量”

Ø        修改ORACLE JDBC DRIVER PATH，值为1.2.1节中ojdbc14.jar 所在的目录，使用绝对路径。

Ø        确定并保存

1.3      新建J2C认证数据

Ø        进入”安全性——安全管理、应用程序和基础结构—— Java 认证和授权服务（JAAS）——J2C认证数据”

Ø        新建一个认证数据条目

Ø        别名为：取一个容易记住的，假设为bm1

Ø        用户标识为：  数据库连接用户

Ø        密码为：  数据库连接密码

1.4      新建JDBC提供者

Ø        进入”资源——JDBC——JDBC提供程序”

Ø        选择合适的作用域，一般选择server1

Ø        新建JDBC提供程序

Ø        数据库类型为：oracle

Ø        提供者类型为：Oracle JDBC Driver

Ø        实施类型为：连接池数据源

Ø        名称为：oracle92

Ø        点击下一步

Ø        类路径为：${ORACLE JDBC DRIVER PATH}/ojdbc14.jar

Ø        下一步

Ø        完成并保存

1.5      新建数据源

Ø        进入”资源——JDBC——数据源”

Ø        选择合适的作用域，一般选择server1（根据你要发布的Server来）

Ø        新建数据源

Ø        名称为：随便起

Ø        JNDI名称为：jdbc/需要使用的jndi name

Ø        组件管理的认证别名为：hostnameNode01/ bm1（还记得之前建立的J2C别名么）

Ø        下一步

Ø        选择刚才建立的JDBC提供程序，

Ø        设置URL：jdbc:oracle:thin:@ip:1521:sid

Ø        下一步

Ø        确定并保存

Ø        选择刚刚建立的数据源，测试连接，看看是否正常