之前很少接觸集群，准確地說是很少接觸項目現場的實施工作，或者說接觸到的都是比較簡單的實施工作，安裝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不活動問題告一段落，等下周一到項目上再驗證下現場的問題是否也能迎刃而解。
版權聲明：本文為博主原創文章，未經博主允許不得轉載。