原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/47720043
【简介】
个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以其它形式去掉，不会泄露任何企业机密，纯为技术分享。
创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。
欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。
【前言】
这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。
不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。
而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。
在追逐于DBA梦想的道路上步步前行。
临时救火，两天两夜，在煎熬中积累经验值。
——深蓝
这次是初碰AIX上的WAS集群，开始的时候没有预料到问题的复杂性，而在一步一步的排查错误、解决错误的过程中，包括到最后无计可施时，决定重新部署环境的这个煎熬过程中，让我感受到，一个良性架构在设计之初是何等的重要。
下面记录一下这次排查的经历。
收到领导的紧急通知后，联系了驻地的工程师，开始介入本次故障处理。
这次故障背景为：
AIX系统上的WAS集群，在更换两台服务器的IP后，WAS集群节点挂起，无法访问。
WAS的架构设计：
AIX服务器1，上面部署了DM管理节点，四个应用节点；
AIX服务器2，上面部署了三个应用节点；
共同组成一个七节点的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的架构设计：
AIX服务器1，上面部署了DM管理节点，四个应用节点；
AIX服务器2，上面部署了三个应用节点；
共同组成一个七节点的WAS集群环境。
发现了一个问题：
对于AIX服务器1上的所有节点node agent后台启动后均启动正常；
对于AIX服务器2上的所有节点node agent后台启动后，进程正常，但是在管理控制台查看却是异常的状态；
于是首先想查看一下日志里有没有有用的信息，但是日志里记录的启动node agent进程是正常的。
关于查看日志的路径：
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1
补充：对于WAS启动的检查顺序正常是这样的：
先看一下node agent状态，再看节点同步的状态，再看server状态（即集群的状态），再看一下IHS状态，再看应用程序启动状态。
补充完毕。
在日志中没有查看到有用的信息，而AIX服务器1是正常的，于是想尝试先只对AIX服务器1进行修复。于是在管理控制台中在节点完成同步后，尝试启动server。这个时候，问题出现了：
即使在node agent、节点同步显示状态正常的AIX服务器1上，server服务竟然是无法启动的。界面卡住了。等待了20分钟后，依然卡在启动提示界面。于是到服务器查看进程启动情况：
ps -ef|grep java |grep -v grep
只是发现了启动的nodeagent，并没有发现server的启动。
等我已经对安装架构了解的差不多后，已经近8点多了。就在困扰于无法启动server的问题时，与驻地工程师经过一番沟通，由其另找了一台服务器，临时安装了一个单点的WAS，临时解决了应用无法访问的问题。因为是周五晚间接到的故障问题，既然已经有了临时的救急方案，本以为可以下周再找时间解决时。这时候领导来了电话，告知了本次故障的紧急性及严重性。由于近日在与客户另有一个大单子要谈，原本这套WAS集群不是我们进行的安装，但是出于商务上的考虑还是希望尽最大力对其进行救援。于是，这个周末对问题进行一下跟踪，只能在加班中度过了。
经过周六的跟踪后，在几次与驻地工程师沟通之后。更进一步的了解了这套环境的背景。原来这套AIX上安装的WAS集群是由客户部门的一个老师在很早之前，边摸索边学习自己装上去的，所以里面难免有些规划混乱的现象。
令人感到诧异的是，在经过一个晚上无人干预后，AIX服务器1上的节点server服务竟然都启动了。这个有些不解，于是开始跟踪各节点的node agent、同步状态。令人不解的是这几个节点频繁的挂起，每次手工启动一个进程、服务竟然要接近30-40分钟。在经过漫长的现象跟踪后，考虑对集群节点进行重建。因为尝试了在AIX服务器1上对节点进行添加，添加后的节点无论是node agent、节点同步、server启停操作状态均正常。就在决定对节点重建时，驻地负责人来了电话，经过进一步沟通后，了解到客户这边当初的安装的老师，会在周一到达现场，亲自查看一下问题，如果那时不能解决再由我们来处理。于是我们所有的状态恢复到最初介入的时候，等待希望能从客户那传来好消息。
周一上午，经过较为平静的上午后。驻地负责人来了电话。
“客户这边，无法解决问题，需要我们全权处理。”
这时，终于可以正大光明的对节点进行重建了。由于考虑到DM受管节点只起到节点间的管理，并且目前状态均正常，于是决定暂时未对受管节点进行重建。
于是，开始删除所有应用节点，然后添加新应用节点。
在删除所有节点的过程中，一直无法通过控制台管理的AIX服务器2上的节点，不能正常删除，于是采取了一些强制删除的操作。
添加节点时，又遇到了问题。
AIX服务器1上的应用节点，4个节点成功添加；
AIX服务器2上的应用节点，3个节点无法完成8879端口联合；
于是，在经过一番尝试后，依然未果。为了把问题缩小化，考虑到服务紧急启动的必要性。经过与领导沟通后，决定思路上先对AIX服务器1进行修复，完成集群应用功能。而对于AIX服务器2不能完成联合的问题，在之后再对其进行研究、测试。
秉承着这个观点，我开始针对AIX服务器1进行调试。在AIX服务器1上的四个应用节点node agent、节点同步、server都正常后，部署了DefaultApplication.ear测试程序用以验证。
但是问题，又一次出现了。
对于重新添加的节点，使用was测试程序竟然无法访问。
即访问路径：http://10.53.105.30/snoop
而通过节点进行访问时，是可以访问测试应用的，如下通过9080端口进行访问节点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文件，发现了部分节点名称问题，如下：
发现了命名非常奇怪，并不是按照实际的情况进行的命名，实际是这样的：
AIX服务器1的主机名：yingyong1
AIX服务器2的主机名：yingyong2
而这里多次出现了loopback作为主机名标识的情况。
问题似乎逐渐被暴露出来。
而在尝试手工修改配置文件，来对这些主机名设置进行修改的过程中，又得到了驻地工程师的回馈，因为之前我们没有AIX上的IHS安装介质，所以根本没想过重新安装。而驻地告知了我们安装文件存在在/tmp/was71/ihs下面的时候，感觉是黑暗中看到了一双援手一样。于是放弃了手工修改配置文件的想法，对IHS进行了卸载、重装。
这里卸载文件所在路径为：/usr/IBM/HTTPServer1/uninstall。
其它平台路径一般为：/opt/IBM/HTTPServer/uninstall
在对IHS进行重装后，再次重建web服务器，重新生成插件、传播插件，然后验证测试程序。这一次对于AIX服务器1上的所有节点，已经可以实现集群80端口的访问方式了。
于是，开始尝试将AIX服务器2的节点添加至DM受管服务器（8879端口联合）。但是，在联合时报出了无法与服务器进行联合。
首先验证了一下telnet服务，#telnet IP地址 8879
telnet遭到拒绝，进一步验证了端口8879无法进行联合。
就在对AIX服务器2节点联合问题无法解决的时候，领导下了命令，表示希望让服务器1的集群先用起来，对于服务器2上的节点无法联合，稍后再解决，先给客户一个初步的交待。于是开始部署正式应用程序、建立jdbc、配置数据源。
但是问题又一次出现了：
在部署完应用程序后，启动正常、生成插件、传播插件正常，但最后应用程序无法访问，而这时应用程序通过单节点端口是可以访问的，说明单节点是正常的，而问题还是处在IHS上面。跟领导汇报过此时情况后，领导表示继续排查错误，再给一个晚上的时间。
就在无计可施之时，注意到了一个问题，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概要文件、创建应用概要文件（服务器1各节点、服务器2各节点）；
⒋启动DM(进入到Dmgr路径下执行)、启动server1（进入到AppSrv01路径下执行）；
⒌确认两台服务器时间同步；
⒍服务器1、2上根据创建的应用概要文件，分别添加节点，通过8879端口进行联合；
⒎重启DM；
⒏重启各节点server；
⒐验证http服务的启动状态（在IHS安装路径下）；
⒑登陆管理控制台，检查node agent状态、节点同步状态；
⒒新建web服务器；
⒓设置控制台首选项；
⒔新建websphere集群；
⒕安装实验程序、启动实验程序；
⒖生成插件、传播插件；
⒗验证发布程序，集群正常；
在之后，将应用程序的ear包发布到了WAS集群上，创建jdbc、数据源，测试应用系统，访问正常。看看时间，已经23：50了。该回家睡觉了。
这里注意：发布ear包时，如果是来自于开发生成的，一般发布不会有太大问题。但是如果是从生产环境导出的ear包，当我们再发布时，发布设置必须和最初ear包发布时所有的配置都是相同的，否则将会出现部署完后不能访问的问题，常会报出404错误。
经过这么漫长的排错、各种修复的尝试，最后解决问题的方法是通过环境的重新部署，还是得益于最后发现了安装介质的源文件,因此对于各种删除也就大胆起来。这次也让我积累了点教训，就是如果生产环境自己没能找到安装源文件，一定要尝试联系相关人员，因为有时候，重新部署将是解决问题最为快捷的方法。
而对于本次技术问题，最后推测，有可能就是处在AIX的主机名这里。在客户最初安装WAS软件时，并没有注意到AIX上hosts文件中对于主机名的特别修改。而是在受管节点上自动识别了默认主机名LOOPBACK，而在对服务器2节点进行联合时，很有可能使用的是IP地址加端口号的联合方式。在没有更换两机IP的时候，这个问题不会出现，而在更换IP之后，服务器2找不到了原有的IP，而会尝试去通过主机名寻找，而这时的主机名loopback又会被服务器2识别为本地主机，因此是无法完成节点联合的。所以，如果在安装初期对于管理单元（即主机名）没有正常配置的话，更换IP是需要重新部署的。否则，继续延用原环境，将会出现一些列的未知问题。
虽然，本次更换IP引起了WAS一些列的问题，但是问题极有可能是出在主机名配置上。而单出的针对于WAS集群服务器修改IP这件事，是否每次修改IP都会对WAS集群造成影响呢，是每次更换IP都需要重新部署环境嘛？带着这个疑问，我们做个实验验证一下。
实验环境：
|
WAS版本：7.0.0.0 |
||||
|
信息项 |
原IP |
新IP |
WAS节点分布 |
操作系统 |
|
服务器1 |
10.53.105.30 |
10.53.105.60 |
DM节点、应用节点1 |
windows 2008 |
|
服务器2 |
10.53.105.31 |
10.53.105.61 |
应用节点2、应用节点3 |
centos 6.4 |
⒈停止node agent；
⒉停止ADMIN服务、停止HTTP服务；
如下：
⒊停止DM节点；
⒋更换服务器1IP、更换服务器2IP，修改服务器上hosts文件；
⒌启动DM节点；
⒍启动ADMIN服务、启动HTTP服务；
如下：
⒎启动各应用节点node agnet、server服务；
⒏生成插件、传播插件；
⒐验证测试程序，访问正常。
小结：
在一个合理的WAS集群规划结构下，在修改各服务器的IP后，将部分配置同步修改后，将不影响原WAS集群使用。
在与驻地后续对WAS进行配置优化时，遇到了程序访问部分乱码的问题。在排除了数据库的问题以后，锁定问题应该是来自于中间件设置。
在驻地工程师和开发人员经过交涉以后，驻地工程师回馈了关于字符集的设置，这里我也是学习了一下。
大概的配置GBK字符集的方法如下：
路径：服务器——应用程序服务器——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"
在面对此次故障处理初期，在面对非常规的现象时，感受到过无助，而且再一系列的尝试都未能解决问题时，自信有些收到影响，也曾有过放弃的想法。好在中途，在通过与我们部门领导超哥多次交流、请教后，把放弃的念头逐渐的消散了。而是不断的告诉自己，再挺一挺，再尝试尝试，方法总比问题多，在研究研究终会有答案。就带着这种信念，在体验了两天两夜的精神煎熬下，终于最后问题得以解决。而且在经历了这次在小型机的平台下的探究过程中，让我对于WAS有了进一步的认识。
同时让我想到，曾任阿里数据库架构师的数据库专家冯大辉在讲述他的成长经历时提到过，记不清原话了，大概的意思就是当我们面对压力、困难时，很多时候，只要再挺一挺、再熬一熬，终会发现问题的解决方法，而且必将从中受益匪浅。
我想这种挺一挺的生活态度，不仅局限于技术问题上，即使是我们面对的生活，每天都会有各种各样的考验、困难、问题等着我们去解决，而我们不必退缩、畏惧，要做的其实很简单，就是再挺一挺，熬过去，没有坎是过不去的。
深蓝，记于哈尔滨
2015年8月16日星期日 阵雨
*******************************************蓝的成长记系列_20150817*************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。
蓝的成长记——追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知
蓝的成长记——追逐DBA（3）：古董上操作，数据导入导出成了问题
蓝的成长记——追逐DBA（4）：追忆少年情愁，再探oracle安装（Linux下10g、11g）
蓝的成长记——追逐DBA（5）：不谈技术谈业务，恼人的应用系统
蓝的成长记——追逐DBA（6）： 做事与做人：小技术，大为人
蓝的成长记——追逐DBA（8）：重拾SP报告，回忆oracle的STATSPACK实验
蓝的成长记——追逐DBA（9）：国庆渐去，追逐DBA，新规划，新启程
蓝的成长记——追逐DBA（10）：飞刀防身，熟络而非专长：摆弄中间件Websphere
蓝的成长记——追逐DBA（11）：回家后的安逸，晕晕乎乎醒了过来
蓝的成长记——追逐DBA（13）：协调硬件厂商，六个故事：所见所感的“服务器、存储、交换机......”
蓝的成长记——追逐DBA（14）：难忘的“云”端，起步的hadoop部署
蓝的成长记——追逐DBA（15）：以为FTP很“简单”，谁成想一波三折
蓝的成长记——追逐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引起
原文地址：http://blog.csdn.net/huangyanlong/article/details/47720043
