蓝的成长记——追逐DBA（18）：小机上WAS集群故障，由一次更换IP引起

原创作品。出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处。否则追究版权法律责任。

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

【简单介绍】

个人在oracle路上的成长记录，当中以蓝自喻。分享成长中的情感、眼界与技术的变化与成长。敏感信息均以其他形式去掉，不会泄露不论什么企业机密，纯为技术分享。

创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。

欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（[email protected]）指明。不胜感激。

【前言】

这是一部个人记录的成长杂记，既然步入到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都须要又一次部署环境嘛？带着这个疑问，我们做个实验验证一下。

实验环境：

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	应用节点2、应用节点3	centos 6.4