标签：rgb bin agent 疑惑 功能 不能 padding 安装源 图片
原创作品。出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处。否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/47720043
【简单介绍】
个人在oracle路上的成长记录，当中以蓝自喻。分享成长中的情感、眼界与技术的变化与成长。敏感信息均以其他形式去掉，不会泄露不论什么企业机密，纯为技术分享。
创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。
欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明。不胜感激。
【前言】
这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。
借由此杂记与库友们分享蓝的成长历程。
不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博。痴迷其深邃，痴迷于近在咫尺却又遥不可及。
而又说不清从何时起。注视于oracle的红色耀眼。照亮出眼前的一道光，未知与迷惑在自己的脚下開始初露些许人生的充实与青春的回馈。
在追逐于DBA梦想的道路上步步前行。
暂时救火。两天两夜。在煎熬中积累经验值。
——深蓝
这次是初碰AIX上的WAS集群，開始的时候没有预料到问题的复杂性，而在一步一步的排查错误、解决错误的过程中。包含到最后无计可施时，决定又一次部署环境的这个煎熬过程中。让我感受到，一个良性架构在设计之初是何等的重要。
以下记录一下这次排查的经历。
收到领导的紧急通知后，联系了驻地的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状态。再看应用程序启动状态。
补充完成。
在日志中没有查看到实用的信息，而AIXserver1是正常的，于是想尝试先仅仅对AIXserver1进行修复。
于是在管理控制台中在节点完毕同步后，尝试启动server。这个时候，问题出现了：
即使在node agent、节点同步显示状态正常的AIXserver1上，server服务居然是无法启动的。界面卡住了。等待了20分钟后。依旧卡在启动提示界面。
于是到server查看进程启动情况：
ps -ef|grep java |grep -v grep
仅仅是发现了启动的nodeagent，并没有发现server的启动。
等我已经对安装架构了解的差点儿相同后，已经近8点多了。就在困扰于无法启动server的问题时。与驻地project师经过一番沟通，由其另找了一台服务器。暂时安装了一个单点的WAS。暂时攻克了应用无法訪问的问题。
由于是周五晚间接到的故障问题。既然已经有了暂时的救急方案，本以为能够下周再找时间解决时。这时候领导来了电话，告知了本次故障的紧急性及严重性。
由于近日在与客户另有一个大单子要谈，原本这套WAS集群不是我们进行的安装，可是出于商务上的考虑还是希望尽最大力对其进行救援。
于是，这个周末对问题进行一下跟踪。仅仅能在加班中度过了。
经过周六的跟踪后，在几次与驻地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測试程序用以验证。
可是问题。重新出现了。
对于又一次加入的节点，使用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的訪问方式了。
于是。開始尝试将AIXserver2的节点加入至DM受管server（8879port联合）。
可是，在联合时报出了无法与server进行联合。
首先验证了一下telnet服务。#telnet IP地址 8879
telnet遭到拒绝，进一步验证了port8879无法进行联合。
就在对AIXserver2节点联合问题无法解决的时候，领导下了命令。表示希望让server1的集群先用起来，对于server2上的节点无法联合，稍后再解决，先给客户一个初步的交待。于是開始部署正式应用程序、建立jdbc、配置数据源。
可是问题重新出现了：
在部署完应用程序后，启动正常、生成插件、传播插件正常。但最后应用程序无法訪问，而这时应用程序通过单节点port是能够訪问的，说明单节点是正常的，而问题还是处在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概要文件、创建应用概要文件（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错误。
经过这么漫长的排错、各种修复的尝试，最后解决这个问题的方法是通过环境的又一次部署，还是得益于最后发现了安装介质的源文件,因此对于各种删除也就大胆起来。
这次也让我积累了点教训，就是假设生产环境自己没能找到安装源文件，一定要尝试联系相关人员，由于有时候，又一次部署将是解决这个问题最为快捷的方法。
而对于本次技术问题。最后猜測，有可能就是处在AIX的主机名这里。在客户最初安装WAS软件时，并没有注意到AIX上hosts文件里对于主机名的特别改动。而是在受管节点上自己主动识别了默认主机名LOOPBACK，而在对server2节点进行联合时，非常有可能使用的是IP地址加port号的联合方式。在没有更换两机IP的时候，这个问题不会出现，而在更换IP之后。server2找不到了原有的IP，而会尝试去通过主机名寻找，而这时的主机名loopback又会被server2识别为本地主机。因此是无法完毕节点联合的。
所以。假设在安装初期对于管理单元（即主机名）没有正常配置的话，更换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 |
⒈停止node agent。
⒉停止ADMIN服务、停止HTTP服务；
例如以下：
⒊停止DM节点；
⒋更换server1IP、更换server2IP，改动server上hosts文件。
⒌启动DM节点；
⒍启动ADMIN服务、启动HTTP服务；
例如以下：
⒎启动各应用节点node agnet、server服务。
⒏生成插件、传播插件。
⒐验证測试程序，訪问正常。
小结：
在一个合理的WAS集群规划结构下。在改动各server的IP后，将部分配置同步改动后，将不影响原WAS集群使用。
在与驻地兴许对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"
在面对此次故障处理初期。在面对很规的现象时，感受到过无助，并且再一系列的尝试都未能解决这个问题时，自信有些收到影响，也曾有过放弃的想法。
好在中途，在通过与我们部门领导超哥多次交流、请教后，把放弃的念头逐渐的消散了。
而是不断的告诉自己，再挺一挺。再尝试尝试，方法总比问题多，在研究研究终会有答案。就带着这样的信念，在体验了两天两夜的精神煎熬下，最终最后问题得以解决。
并且在经历了这次在小型机的平台下的探究过程中，让我对于WAS有了进一步的认识。
同一时候让我想到，曾任阿里数据库架构师的数据库专家冯大辉在讲述他的成长经历时提到过，记不清原话了，大概的意思就是当我们面对压力、困难时。非常多时候，仅仅要再挺一挺、再熬一熬。终会发现问题的解决方法，并且必将从中受益匪浅。
我想这样的挺一挺的生活态度，不仅局限于技术问题上，即使是我们面对的生活，每天都会有各种各样的考验、困难、问题等着我们去解决，而我们不必退缩、畏惧，要做的事实上非常easy，就是再挺一挺，熬过去，没有坎是过不去的。
深蓝，记于哈尔滨
2015年8月16日星期日 阵雨
*******************************************蓝的成长记系列_20150817*************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。
蓝的成长记——追逐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）：协调硬件厂商，六个故事：所见所感的“server、存储、交换机......”
蓝的成长记——追逐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引起
标签：rgb bin agent 疑惑 功能 不能 padding 安装源 图片
原文地址：http://www.cnblogs.com/cxchanpin/p/6979601.html
