【前言】

這是一部個人記錄的成長雜記，既然步入到oracle的這片藍海，免不了一路的奔波與不斷的考驗。

借由此雜記與庫友們分享藍的成長歷程。

不知何時起對藍有了一種說不出來的癡迷，癡迷其廣博。癡迷其深邃，癡迷於近在咫尺卻又遙不可及。

而又說不清從何時起。註視於oracle的紅色耀眼。照亮出眼前的一道光，未知與迷惑在自己的腳下開始初露些許人生的充實與青春的回饋。

在追逐於DBA夢想的道路上步步前行。

暫時救火。兩天兩夜。在煎熬中積累經驗值。

——深藍

這次是初碰AIX上的WAS集群，開始的時候沒有預料到問題的復雜性，而在一步一步的排查錯誤、解決錯誤的過程中。包含到最後無計可施時，決定又一次部署環境的這個煎熬過程中。讓我感受到，一個良性架構在設計之初是何等的重要。

以下記錄一下這次排查的經歷。

（1）、混亂的布局

收到領導的緊急通知後，聯系了駐地的project師，開始介入本次故障處理。

這次故障背景為：

AIX系統上的WAS集群，在更換兩臺server的IP後，WAS集群節點掛起。無法訪問。

WAS的架構設計：

AIXserver1。上面部署了DM管理節點。四個應用節點；

AIXserver2，上面部署了三個應用節點。

共同組成一個七節點的WAS集群環境。

當我登陸到操作系統後，已經感覺到了些許的不安。AIX！由於之前都是在LINUX或WINODWS下進行部署、調試、優化。在小型機上，這還是頭一次。於是登陸後，首先查看了WAS的安裝文件夾。

發現了不同系統下默認的文件夾的差別：

WAS安裝默認文件夾：

Win2008：/opt/IBM/WebSphere/

linux：/opt/IBM/WebSphere/

AIX：/usr/IBM/WebSphere/

找到了文件夾以後。有個疑問突然出現了，這裏的架構有些奇怪。就是在根安裝文件夾下，即/usr/IBM/WebSphere/下不僅僅是有一個AppServer/。而是有好幾個如以下這樣子：

AppServer/ AppServer02/ AppServer03/ AppServer04/

這個時候的反應是似乎這個WAS被安裝了四遍。

然後進去每一個文件夾以後。也相同發現了，的確是每一個以下都有一套完整的WAS文件，例如以下這樣：

於是開始分別的進入到每一個AppServer/profiles/以下，去查看AppSrv01/文件夾，由於這才是節點信息的存放位置。

同一時候，通過WAS管理控制臺，發現了部分節點的node agent並沒有啟動。於是到指定的文件夾下，對其進行手工啟動。這裏須要再提一下這個WAS的架構設計：

AIXserver1。上面部署了DM管理節點，四個應用節點。

AIXserver2，上面部署了三個應用節點。

共同組成一個七節點的WAS集群環境。

發現了一個問題：

對於AIXserver1上的全部節點node agent後臺啟動後均啟動正常；

對於AIXserver2上的全部節點node agent後臺啟動後，進程正常，可是在管理控制臺查看卻是異常的狀態；

於是首先想查看一下日誌裏有沒有實用的信息，可是日誌裏記錄的啟動node agent進程是正常的。

關於查看日誌的路徑：

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1

補充：對於WAS啟動的檢查順序正常是這種：

先看一下node agent狀態，再看節點同步的狀態，再看server狀態（即集群的狀態），再看一下IHS狀態。再看應用程序啟動狀態。

補充完成。

（2）、無法啟動的服務

在日誌中沒有查看到實用的信息，而AIXserver1是正常的，於是想嘗試先僅僅對AIXserver1進行修復。

於是在管理控制臺中在節點完畢同步後，嘗試啟動server。這個時候，問題出現了：

即使在node agent、節點同步顯示狀態正常的AIXserver1上，server服務居然是無法啟動的。界面卡住了。等待了20分鐘後。依舊卡在啟動提示界面。

於是到server查看進程啟動情況：

ps -ef|grep java |grep -v grep

僅僅是發現了啟動的nodeagent，並沒有發現server的啟動。

（3）、等待客戶的回饋

等我已經對安裝架構了解的差點兒相同後，已經近8點多了。就在困擾於無法啟動server的問題時。與駐地project師經過一番溝通，由其另找了一臺服務器。暫時安裝了一個單點的WAS。暫時攻克了應用無法訪問的問題。

由於是周五晚間接到的故障問題。既然已經有了暫時的救急方案，本以為能夠下周再找時間解決時。這時候領導來了電話，告知了本次故障的緊急性及嚴重性。

由於近日在與客戶另有一個大單子要談，原本這套WAS集群不是我們進行的安裝，可是出於商務上的考慮還是希望盡最大力對其進行救援。

於是，這個周末對問題進行一下跟蹤。僅僅能在加班中度過了。

（4）、嘗試重建節點

經過周六的跟蹤後，在幾次與駐地project師溝通之後。

更進一步的了解了這套環境的背景。原來這套AIX上安裝的WAS集群是由客戶部門的一個老師在非常早之前，邊摸索邊學習自己裝上去的，所以裏面難免有些規劃混亂的現象。

令人感到詫異的是，在經過一個晚上無人幹預後。AIX服務器1上的節點server服務居然都啟動了。這個有些不解，於是開始跟蹤各節點的node agent、同步狀態。令人不解的是這幾個節點頻繁的掛起。每次手工啟動一個進程、服務居然要接近30-40分鐘。

在經過漫長的現象跟蹤後，考慮對集群節點進行重建。由於嘗試了在AIX服務器1上對節點進行加入，加入後的節點不管是node agent、節點同步、server啟停操作狀態均正常。

就在決定對節點重建時，駐地負責人來了電話，經過進一步溝通後，了解到客戶這邊當初的安裝的老師，會在周一到達現場，親自查看一下問題。假設那時不能解決再由我們來處理。於是我們全部的狀態恢復到最初介入的時候，等待希望能從客戶那傳來好消息。

周一上午，經過較為平靜的上午後。

駐地負責人來了電話。

“客戶這邊。無法解決這個問題。須要我們全權處理。”

這時，最終能夠正大光明的對節點進行重建了。因為考慮到DM受管節點僅僅起到節點間的管理。而且眼下狀態均正常，於是決定臨時未對受管節點進行重建。

於是。開始刪除全部應用節點，然後加入新應用節點。

在刪除全部節點的過程中，一直無法通過控制臺管理的AIXserver2上的節點。不能正常刪除，於是採取了一些強制刪除的操作。

加入節點時。又遇到了問題。

AIXserver1上的應用節點，4個節點成功加入。

AIXserver2上的應用節點。3個節點無法完畢8879port聯合；

於是。在經過一番嘗試後。依舊未果。

為了把問題縮小化。考慮到服務緊急啟動的必要性。經過與領導溝通後，決定思路上先對AIXserver1進行修復，完畢集群應用功能。而對於AIXserver2不能完畢聯合的問題，在之後再對其進行研究、測試。

秉承著這個觀點，我開始針對AIXserver1進行調試。在AIXserver1上的四個應用節點node agent、節點同步、server都正常後，部署了DefaultApplication.ear測試程序用以驗證。

可是問題。重新出現了。

（5）、IHS無法分發

對於又一次加入的節點，使用was測試程序居然無法訪問。

即訪問路徑：http://10.53.105.30/snoop

而通過節點進行訪問時。是能夠訪問測試應用的。例如以下通過9080port進行訪問節點1。

這個說明IHS是不正常的。

於是開始嘗試看IHS的日誌，希望能夠發現些蛛絲馬跡。

首先查看一下IHS的日誌，例如以下路徑：

# cd /usr/IBM/HTTPServer1/logs

# ls

access_log cgisock.10879230 cgisock.11010058 cgisock.11141214 cgisock.8257668 cgisock.9306176 error_log httpd.pid install

對error_log進行了查看，發現了部分異常信息，但也沒有太好的思路進一步解決，例如以下部分截取：

截取1：

截取2：

截取3：

看到上面報出非常多文件不存在。想到在WAS集群中會通過IHS進行插件傳播。不能完畢傳播難到是由於插件沒有被傳播到各個節點上？帶著些疑惑進行傳播操作。例如以下：

註意：截圖均是來自於後期測試，並非現場的真實圖片，僅供參考之用。

嘗試完畢插件傳播後，而且重新啟動了IHS，可是問題依然。

想進一步查看插件的配置信息。懷疑可能插件並沒有真正意義上得到傳播，不知是否能通過手動運行。於是嘗試去查看一下配置信息：

# cd /usr/IBM/HTTPServer1

# ls

Plugins build conf gsk7 include lib man readme

Plugins1 cgi-bin error htdocs java license modules uninstall

bin codeset example_module icons lafiles logs properties version.signature

# cd Plugins1

# ls

bin etc lafiles plugins uninstall

config gsk7 lib properties

configuration java logs roadmap

導出了例如以下這些文件，進一步查看，例如以下：

截取出例如以下信息：

再次查看一下Plugins1\config\webserver1以下的plugin-cfg.xml文件，發現了部分節點名稱問題，例如以下：

發現了命名很奇怪，並非依照實際的情況進行的命名，實際是這種：

AIXserver1的主機名：yingyong1

AIXserver2的主機名：yingyong2

而這裏多次出現了loopback作為主機名標識的情況。

問題似乎逐漸被暴露出來。

而在嘗試手工改動配置文件，來對這些主機名設置進行改動的過程中，又得到了駐地project師的回饋，由於之前我們沒有AIX上的IHS安裝介質，所以根本沒想過又一次安裝。

而駐地告知了我們安裝文件存在在/tmp/was71/ihs以下的時候。感覺是黑暗中看到了一雙援手一樣。於是放棄了手工改動配置文件的想法，對IHS進行了卸載、重裝。

這裏卸載文件所在路徑為：/usr/IBM/HTTPServer1/uninstall。

其他平臺路徑一般為：/opt/IBM/HTTPServer/uninstall

在對IHS進行重裝後，再次重建webserver，又一次生成插件、傳播插件，然後驗證測試程序。

這一次對於AIXserver1上的全部節點。已經能夠實現集群80port的訪問方式了。

（6）、節點無法聯合

於是。開始嘗試將AIXserver2的節點加入至DM受管server（8879port聯合）。

可是，在聯合時報出了無法與server進行聯合。

首先驗證了一下telnet服務。#telnet IP地址 8879

telnet遭到拒絕，進一步驗證了port8879無法進行聯合。

就在對AIXserver2節點聯合問題無法解決的時候，領導下了命令。表示希望讓server1的集群先用起來，對於server2上的節點無法聯合，稍後再解決，先給客戶一個初步的交待。於是開始部署正式應用程序、建立jdbc、配置數據源。

可是問題重新出現了：

在部署完應用程序後，啟動正常、生成插件、傳播插件正常。但最後應用程序無法訪問，而這時應用程序通過單節點port是能夠訪問的，說明單節點是正常的，而問題還是處在IHS上面。

跟領導匯報過此時情況後，領導表示繼續排查錯誤，再給一個晚上的時間。

（7）、又一次部署

就在無計可施之時。註意到了一個問題。DM受管節點所建立的管理組命為：loopbackcell01。

而AIX主機名應該是app1cell01。

開始利用互聯網查看資料，查看IBM官網部分文檔，發現了AIX上部署WAS集群時的一個註意事項：

在AIX安裝WAS時。必須對host文件中將主機名放在該文件中的前兩行，要先於loopback這行。例如以下這樣：

而不應該是之前的設置，例如以下是之前的設置：

原來。在AIX上進行WAS安裝時。默認的WAS會到hosts文件裏找到第一行的信息，也就是會默認把loopback作為主機名。

假設要搭建WAS集群，這將給興許cell或節點聯合帶來一些列的問題。

於是以下，對整個WAS集群進行了又一次部署。

關閉關閉應用程序，關閉IHS；

在節點node agent啟動狀態下，移除各節點；

最後移除DM受管節點；

然後到WAS安裝文件下，profiles文件夾中，刪除全部節點概要文件，使用指令舉比例如以下：

舉例：在windows環境下（其他平臺方法同樣）

如：到D:\IBM\WebSphere\bin\下

（1）、刪除所有概要文件：

第一步：運行：manageprofiles -deleteAll

第二步：到路徑下刪除物理文件文件夾

圖例：

（2）、刪除某一個概要文件

第一步：運行：manageprofiles -delete -profileName AppSrv01

第二步：到路徑下刪除物理文件文件夾

最後卸載IHS。

舉例完成。

當全部節點都被移除後，開始又一次部署。

這次我們選擇一個WAS文件的安裝路徑，在一個/AppServer/下載一個profiles文件夾下創建多個節點的概要文件、DM受管概要文件。

操作流程：

⒈改動hosts文件配置。

⒉安裝IHS軟件；

⒊創建DM概要文件、創建應用概要文件（server1各節點、server2各節點）；

⒋啟動DM(進入到Dmgr路徑下運行)、啟動server1（進入到AppSrv01路徑下運行）；

⒌確認兩臺server時間同步；

⒍server1、2上依據創建的應用概要文件，分別加入節點。通過8879port進行聯合。

⒎重新啟動DM；

⒏重新啟動各節點server；

⒐驗證http服務的啟動狀態（在IHS安裝路徑下）；

⒑登陸管理控制臺，檢查node agent狀態、節點同步狀態；

⒒新建webserver；

⒓設置控制臺首選項。

⒔新建websphere集群；

⒕安裝實驗程序、啟動實驗程序。

⒖生成插件、傳播插件；

⒗驗證公布程序，集群正常；

在之後，將應用程序的ear包公布到了WAS集群上。創建jdbc、數據源，測試應用系統，訪問正常。

看看時間，已經23：50了。該回家睡覺了。

這裏註意：公布ear包時。假設是來自於開發生成的，一般公布不會有太大問題。可是假設是從生產環境導出的ear包，當我們再公布時。公布設置必須和最初ear包公布時全部的配置都是同樣的，否則將會出現部署完後不能訪問的問題，常會報出404錯誤。

（8）、回想對於問題的推測

經過這麽漫長的排錯、各種修復的嘗試，最後解決這個問題的方法是通過環境的又一次部署，還是得益於最後發現了安裝介質的源文件,因此對於各種刪除也就大膽起來。

這次也讓我積累了點教訓，就是假設生產環境自己沒能找到安裝源文件，一定要嘗試聯系相關人員，由於有時候，又一次部署將是解決這個問題最為快捷的方法。

而對於本次技術問題。最後猜測，有可能就是處在AIX的主機名這裏。在客戶最初安裝WAS軟件時，並沒有註意到AIX上hosts文件裏對於主機名的特別改動。而是在受管節點上自己主動識別了默認主機名LOOPBACK，而在對server2節點進行聯合時，非常有可能使用的是IP地址加port號的聯合方式。在沒有更換兩機IP的時候，這個問題不會出現，而在更換IP之後。server2找不到了原有的IP，而會嘗試去通過主機名尋找，而這時的主機名loopback又會被server2識別為本地主機。因此是無法完畢節點聯合的。

所以。假設在安裝初期對於管理單元（即主機名）沒有正常配置的話，更換IP是須要又一次部署的。否則。繼續延用原環境。將會出現一些列的未知問題。

（9）、實驗驗證更換IP

盡管，本次更換IP引起了WAS一些列的問題，可是問題極有可能是出在主機名配置上。而單出的針對於WAS集群server改動IP這件事，是否每次改動IP都會對WAS集群造成影響呢。是每次更換IP都須要又一次部署環境嘛？帶著這個疑問，我們做個實驗驗證一下。

實驗環境：

⒈停止node agent。

⒉停止ADMIN服務、停止HTTP服務；

例如以下：

⒊停止DM節點；

⒋更換server1IP、更換server2IP，改動server上hosts文件。

⒌啟動DM節點；

⒍啟動ADMIN服務、啟動HTTP服務；

例如以下：

⒎啟動各應用節點node agnet、server服務。

⒏生成插件、傳播插件。

⒐驗證測試程序，訪問正常。

小結：

在一個合理的WAS集群規劃結構下。在改動各server的IP後，將部分配置同步改動後，將不影響原WAS集群使用。

（10）、興許配置：字符集

在與駐地興許對WAS進行配置優化時。遇到了程序訪問部分亂碼的問題。在排除了數據庫的問題以後。鎖定問題應該是來自於中間件設置。

在駐地project師和開發者經過交涉以後。駐地project師回饋了關於字符集的設置，這裏我也是學習了一下。

大概的配置GBK字符集的方法例如以下：

路徑：server——應用程序server——server1——進程定義——Java 虛擬機：

通用JVM參數＝-Dfile.encoding=GBK -Ddefault.client.encoding=GBK

補充一個問題：

假設在小機部署完畢WAS後，設置支持中文字符集，從WORD文檔中直接COPY的通用參數後WAS啟動失敗，總是提示找不到 Java Class -Dfile.encoding=GBK錯誤的解決方法。

解決：

找到配置文件server1.xml進行改動genericJvmArguments為空。正常啟動後再從管理控制臺改動配置。

然後再依照上面所說的設置方法。設置參數以支持中文字符集。

關於一些配置細節：

配置文件路徑：\usr\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\yingyong1Node01Cell\nodes\loushangaixNode01\servers\server1.xml

在配置文件裏。能夠找到以下的信息：

genericJvmArguments="-Dfile.encoding=GBK -Ddefault.client.encoding=GBK"

（11）、再挺一挺，就過去了

在面對此次故障處理初期。在面對很規的現象時，感受到過無助，並且再一系列的嘗試都未能解決這個問題時，自信有些收到影響，也曾有過放棄的想法。

好在中途，在通過與我們部門領導超哥多次交流、請教後，把放棄的念頭逐漸的消散了。

而是不斷的告訴自己，再挺一挺。再嘗試嘗試，方法總比問題多，在研究研究終會有答案。就帶著這樣的信念，在體驗了兩天兩夜的精神煎熬下，最終最後問題得以解決。

並且在經歷了這次在小型機的平臺下的探究過程中，讓我對於WAS有了進一步的認識。

同一時候讓我想到，曾任阿裏數據庫架構師的數據庫專家馮大輝在講述他的成長經歷時提到過，記不清原話了，大概的意思就是當我們面對壓力、困難時。非常多時候，僅僅要再挺一挺、再熬一熬。終會發現問題的解決方法，並且必將從中受益匪淺。

我想這樣的挺一挺的生活態度，不僅局限於技術問題上，即使是我們面對的生活，每天都會有各種各樣的考驗、困難、問題等著我們去解決，而我們不必退縮、畏懼，要做的事實上非常easy，就是再挺一挺，熬過去，沒有坎是過不去的。

深藍，記於哈爾濱

2015年8月16日星期日 陣雨

*******************************************藍的成長記系列_20150817*************************************

原創作品，出自 “深藍的blog” 博客，歡迎轉載，轉載時請務必註明出處（http://blog.csdn.net/huangyanlong）。

藍的成長記——追逐DBA（1）：奔波於路上，挺進山東

藍的成長記——追逐DBA（2）：安裝！安裝！

久違的記憶。引起我對DBA的又一次認知

藍的成長記——追逐DBA（3）：古董上操作，數據導入導出成了問題

藍的成長記——追逐DBA（4）：追憶少年情愁，再探oracle安裝（Linux下10g、11g）

藍的成長記——追逐DBA（5）：不談技術談業務，惱人的應用系統

藍的成長記——追逐DBA（6）： 做事與做人：小技術。大為人

藍的成長記——追逐DBA（7）：基礎命令。地基之石

藍的成長記——追逐DBA（8）：重拾SP報告，回顧oracle的STATSPACK實驗

藍的成長記——追逐DBA（9）：國慶漸去，追逐DBA。新規劃，新啟程

藍的成長記——追逐DBA（10）：飛刀防身。熟絡而非專長：擺弄中間件Websphere

藍的成長記——追逐DBA（11）：回家後的安逸。暈暈乎乎醒了過來

藍的成長記——追逐DBA（12）：七天七收獲的SQL

藍的成長記——追逐DBA（13）：協調硬件廠商，六個故事：所見所感的“server、存儲、交換機......”

藍的成長記——追逐DBA（14）：難忘的“雲”端，起步的hadoop部署

藍的成長記——追逐DBA（15）：以為FTP非常“簡單”，誰成想一波三折

藍的成長記——追逐DBA（16）：DBA也喝酒，被捭闔了

藍的成長記——追逐DBA（17）：是分享，還是消費。在後IOE時代學會成長

藍的成長記——追逐DBA（18）：小機上WAS集群故障。由一次更換IP引起

******************************************************************************************************************

********************************************足球與oracle系列_20150528***********************************

原創作品，出自 “深藍的blog” 博客，歡迎轉載，轉載時請務必註明出處（http://blog.csdn.net/huangyanlong）。

足球與oracle系列（1）：32路諸侯點兵，oracle32進程聯盟 之A組巴西SMON進程的大局觀

足球與oracle系列（2）：巴西揭幕戰預演，oracle體系結構雜談

足球與oracle系列（3）：oracle進程排名，世界杯次回合即將戰罷！

足球與oracle系列（4）：從巴西慘敗於德國，想到，差異的RAC拓撲對照！

足球與oracle系列（5）：fifa14遊戲缺失的directX庫類比於oracle的rpm包！

足球與oracle系列（6）：伴隨建庫的亞洲杯——加油中國隊

******************************************************************************************************************

藍的成長記——追逐DBA（18）：小機上WAS集群故障，由一次更換IP引起