蓝的成长记——追逐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