之前很少接触集群，准确地说是很少接触项目现场的实施工作，或者说接触到的都是比较简单的实施工作，安装Linux、WAS、Oracle相对来说都比较简单。一直埋头干着研发的活，干着不要紧，一干就是好几年。之前也想多了解点儿研发之外的技术，只是工作中也一直没有涉及，迟迟没有迈开历史性的第一步。最近一个项目部署WAS集群环境，需要去现场支持一段时间，正好可以有机会接触一下，虽然没有经验，但还是主动请缨，开始研究WAS集群。
为了掌握WAS集群的知识，去项目现场之前先在自己的笔记本上完成WAS集群演示环境的搭建。
操作系统：Win7 64位
WAS版本：WAS ND 7.0 64位
集群节点：1个IHS + 1个Dmgr + 2个AppSrv
部署方式：单机模拟，并且没有用虚拟机
整个演示环境搭建还算比较顺利，主要是参考了前辈分享的经验。
参考资料：http://blog.csdn.net/lifetragedy/article/details/7897922?utm_source=tuicool
这篇帖子里的过程可以说非常详细，有图有真相，只是有一小部分不够清楚，就是IHS和WASND的整合过程，没有体现出IHS和WAS Web插件的安装，不过也不算很难，网上搜点儿资料也能搞定，只是第一次尝试可能会蒙圈。
这里补充一些WAS集群的操作参考资料：http://www.it165.net/admin/serverfzjh/
另外需要注意的是，64位的Windows无法通过 Profile Management 工具创建AppSrv，只能通过命令搞定。
参考资料：http://www.ibm.com/developerworks/cn/websphere/library/redbooks/was_profileconfig/was_profileconfig.html
演示集群环境搭建好之后，还进行了一些相关的测试，主要包括：
1、负载均衡测试
2、节点故障测试
3、session共享测试
4、节点扩展测试
5、应用同步升级测试
6、业务系统集群功能点测试
以上测试都顺利通过，以为是心中有数了。事实证明，还有很多新的问题可能会出现。
项目现场的环境比较复杂，操作系统都是Linux，并且都不是自己安装的，可能会缺少很多东西。另外，实际的集群环境节点数量多，这也就意味着操作过程会更加繁琐。
万事开头难，之前做的工作都很顺利，以为后面不会遇到太大的问题了呢。不然，还是有新的问题接踵而至。小问题就不贴出来了，网上一搜一大堆，主要说下一个比较复杂的不一样的问题。
AppSrv节点联合到Dmgr之后，为了验证是否成功，试图启动cluster，可是失败了，提示如下：
集群成员 server1将不能启动，因为节点 Node01 上的 Node Agent 不活动。集群成员可从集群成员集合面板单独地启动。所有的节点都提示相同的错误，竟然没有一个成功的。
问题出现之后，首先想到的是回忆之前Windows的部署过程，看看是不是Linux步骤有问题，最后发现步骤无误。
然后，网上搜罗了一番，也有一些帖子，比如：
https://www.ibm.com/developerworks/community/forums/html/topic?id=5f08fd5f-8e3d-4237-a70c-542cc5eebc4c
没有讨论出具体解决办法
http://m.blog.csdn.net/blog/i_am_rookie/38885989
7277端口没开，但是开了也没有解决我的问题
http://xjsunjie.blog.51cto.com/999372/1151425
提供了两种解决办法，都尝试了，但是也未果
Linux防火墙默认开启着，WAS的关键端口都添加进去测试，发现也于事无补。
之前也遇到过一些WAS的问题，但总是能找到解决的办法。这次有些费劲了，过了大半天，也没找到具体的原因和解决办法。甚至之前有些问题没有找到问题原因，也能尝试出解决办法，而这次看起来貌似不那么容易了。
刚好赶上周五，下周就要完成任务，可是遇到关键问题卡住了，怎么能安心呢？于是晚上回到家，继续战斗。
连不上项目现场环境，就自己用VMware虚拟了两个Linux进行测试，重来一遍预期问题能够得到解决，这样就算没有找到具体原因，去项目现场重新安装一遍也算是搞定了。可是实践证明，问题依然存在，并且项目现场的问题在我的虚拟机里重现了。有喜有悲，悲的是问题没有被搞定，喜的是重现了项目现场的问题，可以继续研究。
网上搜罗了一些相关的问题，尝试了一些推荐的解决办法一直都没有搞定，打算还是自己静下心来好好研究研究。
WAS算是非常成熟的产品了，日志做的非常棒，出现问题在日志里总能找到线索，于是分析了dmgr、nodeagent和ffdc的日志，虽然都是英文的，但都是一些程序相关的，看着还算有亲切感。
经过日志分析，dmgr和nodeagent的日志都没有明显的error，顶多有几个warning，但都提示启动成功。在最后分析的ffdc日志里，发现了异常，关键异常信息如下：
FFDC Exception:com.ibm.websphere.management.exception.AdminException SourceId:com.ibm.ws.management.sync.NodeSyncTask.doSync ProbeId:8891 Reporter:com.ibm.ws.management.sync.NodeSyncTask@39223922
com.ibm.websphere.management.exception.AdminException: java.lang.NullPointerException
at com.ibm.websphere.management.exception.AdminException.getAdminException(AdminException.java:50)
at com.ibm.ws.management.sync.NodeSync.invokeGetModifiedFolders(NodeSync.java:435)
at com.ibm.ws.management.sync.NodeSyncTask.doSync(NodeSyncTask.java:244)
at com.ibm.ws.management.sync.NodeSyncTask.run(NodeSyncTask.java:157)
at java.lang.Thread.run(Thread.java:735)
Caused by: java.lang.NullPointerException
at com.ibm.ws.management.sync.NodeSync.invokeGetModifiedFolders(NodeSync.java:410)
... 3 more虽然没有明确说明是什么问题，但通过日志里的关键字NodeSyncTask.doSync猜到是节点同步异常了，可能还是网络通信出了问题。奇怪的是，之前使用syncNode命令同步节点都成功了，为何启动的时候又会报错呢？
既然是网络通信出了问题，WAS很多地方用到TCP协议，于是想到检查一下serverindex.xml文件。
不看不知道，一看吓一跳啊，Dmgr的serverindex.xml文件里，竟然很多的localhost，既然是多台服务器集群，localhost肯定是不行的，受管节点怎么和管理节点进行通信呢？继续检查了下AppSrv的serverindex.xml文件，里面竟然也有很多localhost，看来问题并非偶然。改成实际的ip地址试试先
在修改完serverindex.xml文件之后使用命令重启WAS服务的时候，发现了关键的线索
[root@localhost bin]# Linux命令行前的提示符中，计算机名竟然都是localhost，一下恍然大悟的感觉，因为项目现场搭建环境的时候，刚开始我就注意到这个奇怪的地方，所有的服务器计算机名都是奇怪的localhost。
将localhost都修改为实际的ip地址并且重启WAS服务之后，重新测试cluster，顺利通过~
至于那个localhost是怎么来的，我本机的VMware虚拟机中，Linux本来只有一个，克隆出了另一个，出现相同的问题不足为怪。而项目现场好多个服务器，也有可能是通过“克隆”的方式安装的Linux。
至此，Node Agent不活动问题告一段落，等下周一到项目上再验证下现场的问题是否也能迎刃而解。
