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

時間 2019-11-24

標籤藍的成長追逐 dba 機上集羣故障一次更換引發欄目 SQL 简体版

原文原文鏈接

原創做品。出自「深藍的blog」博客，歡迎轉載，轉載時請務必註明出處。不然追究版權法律責任。java

深藍的blog：http://blog.csdn.net/huangyanlong/article/details/47720043 node

【簡單介紹】linux

我的在oracle路上的成長記錄，當中以藍自喻。分享成長中的情感、眼界與技術的變化與成長。敏感信息均以其餘形式去掉，不會泄露不論什麼企業機密，純爲技術分享。web

創做靈感源於對本身的自省和記錄。若能對剛剛起步的庫友起到些許的幫助或共鳴，欣慰不已。數據庫

歡迎拍磚，若有關技術細節表述有錯誤之處，請您留言或郵件（hyldba@163.com）指明。不勝感激。windows

【前言】centos

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

藉由此雜記與庫友們分享藍的成長曆程。架構

不知什麼時候起對藍有了一種說不出來的癡迷，癡迷其廣博。癡迷其深邃，癡迷於近在咫尺卻又高不可攀。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時間同步；

⒍server一、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都需要又一次部署環境嘛？帶着這個疑問，咱們作個實驗驗證一下。

實驗環境：

WAS版本號：7.0.0.0
信息項	原IP	新IP	WAS節點分佈	操做系統
server1	10.53.105.30	10.53.105.60	DM節點、應用節點1	windows 2008
server2	10.53.105.31	10.53.105.61	應用節點二、應用節點3	centos 6.4