Credit故事之服务器换血
^^^^^^^^^^^^^^^^^^^^^^
- 作者：臭豆腐[trydofor.com]
- 日期：2009-04-19
- 授权：署名-非商业-保持一致 1.0 协议
- 声明：拷贝、分发、呈现和表演本作品，请保留以上全部信息。
0. 文档目录
^^^^^^^^^^
[[<=$INDEX]]
^^^^^^^^^^^^^^^^^^^^
1. 210的不祥之兆
^^^^^^^^^^^^^^^^
210是一个IP,是DB2 Server的所在,比我的工龄都大.
210上的服务器,换过2次,相当于内部职位调动,就是把209变成210这样的.
这一任210服务器,也兢兢业业的转了又4年的样子了.
然而从4月中旬开始,210不断地开了几个玩笑.
============================= txt CAFIS小插曲 =============================
[2009-4-11 20:42:41] 水 说： 说有三个，其中一个连接断了。
[2009-4-11 20:42:46] 水 说： 我再打电话确认看看
[2009-4-11 20:42:48] 水 说： 请稍等
[2009-4-11 20:43:06] A9 说：
netstat -an |grep 10.0.172.21:990|grep ESTABLISHED
tcp 0 0 ::ffff:10.0.172.2:32838 ::ffff:10.0.172.21:9901 ESTABLISHED
tcp 0 0 ::ffff:10.0.172.2:32837 ::ffff:10.0.172.21:9900 ESTABLISHED
tcp 0 0 ::ffff:10.0.172.2:32839 ::ffff:10.0.172.21:9902 ESTABLISHED
[2009-4-11 21:07:54] 水 说： 现在还是处于一个没连上的状态
[2009-4-11 21:16:32] A9 说： 启动完毕了,请与JRI确认一下吧
[2009-4-11 21:22:51] 水 说： 恩。。。在JRI那边就算重设了状况还是没有变化。
========================================================================
============================= txt 关机失败 =============================
[2009-4-12 16:31:11] 水 说： 等 [id：1584对应完之后，重新启动210和207吧
[2009-4-12 17:30:46] 水 说： OK
[2009-4-12 17:46:47] A9 说： 210重启遇到问题,可以ping通,但是不能ssh
[2009-4-12 17:47:11] A9 说： 不能确认是否重启完毕了,需要dh帮助重启一下
[2009-4-12 17:47:44] A9 说： reboot已经有5分钟的时间
[2009-4-13 10:40:41] A9 说： 210 ldcr db好像down了,刚才重新启动了
[2009-4-13 10:41:35] A9 说： 原因正在调查
[2009-4-13 10:42:03] 水 说： OK
[2009-4-13 10:53:25] A9 说： 没有发现原因,但210 最近不太稳当,
是否需要检查下硬件是否老化,或存在问题
[2009-4-13 11:08:46] 水 说： 我认为一定是因为从今天开始Promise的
转让债权的对应中，连接数增大而导致的。
========================================================================
============================= txt 无故宕机 =============================
[2009-4-13 14:35:44] A9 说： 210 db2 又down了
[2009-4-13 14:36:38] 水 说： 真的啊。。。
[2009-4-13 14:41:58] A9 说：
192.168.16.* 150 182
192.168.16.* 100 133
[2009-4-13 14:42:39] A9 说： down之前的现象是连接数持续增长
[2009-4-13 14:44:33] 水 说： 恩。。。有什么对策没有？
[2009-4-13 14:51:45] A9 说： 暂时还不知道down的具体原因
========================================================================
============================= txt 午夜凶铃 =============================
[2009-4-14 3:07:00] 吉 说： hi
[2009-4-14 3:08:03] 吉 说： 210的ssh没问题了，但是还是处于无法访问
db2的状态，请对应
[2009-4-14 3:08:44] A9 说： db2 启动了
[2009-4-14 3:09:07] A9 说： 正在检查相关批处理
[2009-4-14 3:09:36] 吉 说： ok
[2009-4-14 3:16:40] A9 说： db2 大于在2009-04-14_03-45-00和
2009-04-14_03-50-00之间down的
[2009-4-14 3:17:11] A9 说： 207 batch 执行完毕了,di启动成功
[2009-4-14 3:20:41] 吉 说： 现在CAFIS是连接着的状态吗？
[2009-4-14 3:20:52] 吉 说： 还有IVR。
[2009-4-14 3:22:16] A9 说： 正常
[2009-4-14 3:25:16] 吉 说： 然后，能否把
BO LOG BACKUP TO MYSQL処理完了通知【異常終了】
这个批处理也再执行一下?
[2009-4-14 3:32:28] A9 说： 了解
[2009-4-14 3:34:37] A9 说： 执行成功了,请查收邮件
[2009-4-14 3:35:48] 吉 说： 确认完了 OK了
========================================================================
============================= txt 祸不单行 =============================
[2009-4-14 9:52:50] 水 说： 210、现在正常运行吗？
[2009-4-14 9:53:23] 水 说： 5分钟前开始管理工具不能用了。
[2009-4-14 9:54:44] A9 说： 了解了
[2009-4-14 9:56:23] A9 说： 210 启动了
[2009-4-14 9:57:23] 水 说： 了解了
[2009-4-14 14:27:19] A9 说： 210 down
[2009-4-14 14:28:38] 水 说： oh...
========================================================================
============================= txt 好事成双 =============================
[2009-4-15 13:34:55] A9 说： 210 db2重启动完毕了。
[2009-4-15 13:36:21] 水 说： 没问题了
[2009-4-15 13:38:07] A9 说： 是否需要ibm协助调查210的db2问题
[2009-4-15 16:30:37] A9 说： 210 down
[2009-4-15 16:31:12] 水 说： 请重启
========================================================================
============================= txt 不堪重负 =============================
[2009-4-15 21:05:40] 吉 说： 210上现在在进行什么处理呢吗？
[2009-4-15 21:08:41] 吉 说： cpu01和cpu03是那个100%状态了,是指top的状态。
[2009-4-15 21:20:05] A9 说： 不清楚是否有问题,好像只有 01,03 是100% ,其他是0%
[2009-4-15 21:22:07] 吉 说： 是不是重启一下为好？
[2009-4-15 21:22:20] 吉 说： 把DB2。
[2009-4-15 21:22:30] A9 说： 好的
[2009-4-15 21:23:25] A9 说： dh调查出什么问题了么?
[2009-4-15 21:23:57] 吉 说： 还没消息
[2009-4-15 21:24:30] 吉 说： 关于这个对策，明天开会讨论一下吧
[2009-4-15 21:27:34] A9 说： 吉有什么好的建议么?
[2009-4-15 21:30:22] 吉 说： 我还没有什么好的建议，由于现在UDB8.2中IBM的支持
已经中止了，所以没法委托他们进行调查
[2009-4-15 21:31:03] A9 说： db2已经停止了,但还是100%
[2009-4-15 21:31:05] 吉 说： 所以，找个早一点的时机，升级至9.5之后，再观察观察
[2009-4-15 21:31:46] 吉 说： 那么重启２１０吧
[2009-4-15 21:31:58] A9 说： OK
[2009-4-15 21:33:26] A9 说： 有2个可能:
1. 服务器硬件问题
2. db2 软件问题
[2009-4-15 21:35:29] 吉 说： Yes
[2009-4-15 21:37:57] A9 说： 210 and db2 启动完毕了
[2009-4-15 21:38:42] 吉 说： 了解。
[2009-4-15 21:39:45] 吉 说： 所有服务都启动完了吗？
[2009-4-15 21:39:46] A9 说： 207 程序正在启动
[2009-4-15 21:40:11] 吉 说： ok
[2009-4-15 21:42:00] A9 说： 207程序正常了
[2009-4-15 21:43:50] 吉 说： 谢谢了
[2009-4-15 21:44:25] A9 说： welcome
========================================================================
============================= txt 不堪重负 =============================
[2009-4-17 3:15:13] 吉 说： >阿久
由于210出现了无法进行ssh的状态，所以拜托DH重启了。
看Console的话好像是Out of memory了。
等他们重启完之后，请启动各服务。
[2009-4-17 3:15:24] 吉 说： 他们重启完毕了。
[2009-4-17 3:17:47] A9 说： 了解
[2009-4-17 3:19:05] A9 说： 直接启动207上的程序就可以了吧
[2009-4-17 3:19:12] A9 说： 210现在好像正常了
[2009-4-17 3:20:08] 吉 说： Yes
[2009-4-17 3:23:50] 吉 说： BO LOG BACKUP TO MYSQL処理完了通知【異常終了】
[2009-4-17 3:24:30] 吉 说： 请重新执行上面的处理。
[2009-4-17 3:26:06] A9 说： 了解
[2009-4-17 3:29:26] 吉 说： 【210 BACKUP DB2 LDCR INCREMENTAL 処理完了通知】没收到。
[2009-4-17 3:29:51] 吉 说： 我觉得可能在备份途中down了。所以请重新执行
[2009-4-17 3:48:40] 吉 说： 上面两个批处理也执行完毕了吗？
[2009-4-17 3:49:27] A9 说： BO LOG BACKUP TO MYSQL処理完了通知<==done
[2009-4-17 3:49:36] A9 说： 210 BACKUP DB2 LDCR INCREMENTAL 処理完了通知<== running
========================================================================
2. 系统升级进行时
^^^^^^^^^^^^^^^^^
连续几次的午夜凶铃和营业时间内宕机,已经将问题升级到白热化.
调查,分析,并尝试的解决办法出炉了.
1. 安装64bit-OS和DB2U9.5
Out-of-memory,db有千万条记录,200多条连接.
2. 高性能服务器调换.
3. 附带其他网段调整,服务器分离作业.
============================= txt 作业步骤 =============================
时间:4/17(五) - 4/19(日) UDB 作业步骤
－ BO3(10.0.172.210), BO4(10.0.172.231)相关
[1] BO4 备份(DB2,MySQL etc) 【Edge】～ 4/17 17:00
[2] BO3 停止 【Edge】 4/17 23:00
[3] BO3 BuckUp 【Edge】 4/17 23:00 ～ 4/18 9:00AM
[4] [3]结束后 BO4 OS 安装 RHEL4(64Bit) 【DH】 ～ 4/18 9:00AM
[5] IP地址变更 【DH】 4/18 9:00AM～4/18 10:00AM
BO3 10.0.172.210--->10.0.172.231
BO4 10.0.172.231--->10.0.172.210
[6] BO4的UDB9.5(64Bit)安装和构建 【Edge】4/18 10:00AM～
- BO-SER(10.0.172.232) 相关
[1] BO-SER停止 【Edge】 4/17 23:00
[2] SER,GS BuckUp(DB2,Samba etc) 【Edge】 4/17 23:00 ～ 4/17 24:00AM
[3] [2]结束后
BO-SER OS 安装 RHEL4(64Bit) 【DH】～ 4/18 10:00AM
IP地址变更为10.180.3.156
[4] BO1-SER上UDB9.5(64Bit)安装和构建 【Edge】 4/18 10:00AM～
- BO-SFC(10.0.172.232) 相关
[1] BO1/2-SFC,MN1/2-SFC 的OS安装 【DH】 完毕
[2] BO1/2-SFC上UDB9.5(64Bit)安装和构建 【Edge】 ～ 4/17 21:00
[3] BO-SER的DB移植到 BO1/2-SFC 【Edge】 4/18 10:00AM～
- 做业目标 (SFC)
BO1-SFC 10.180.9.162 RHEL4.7(64Bit) + UDB9.5(64Bit)
BO2-SFC 10.180.9.163 RHEL4.7(64Bit) + UDB9.5(64Bit)
MN1-SFC 10.180.9.165 CentOS4(32Bit)
MN2-SFC 10.180.9.166 CentOS4(32Bit)
- 做业目标 (SER)
BO1-SER 10.180.3.156 RHEL4.7(64Bit) + UDB9.5(64Bit)
- 做业目标 (NLC)
BO3 10.0.127.231 RHEL3 + UDB8.2
BO4 10.0.127.210 RHEL4.7(64Bit) + UDB9.5(64Bit)
========================================================================
尽管手册看是很充分,实际上相当匆促了,可以用突发来形容.
17号白天被DNP card缠身,直到17:30 才松了口气,结果发现老头的这个安排.
死磕,硬抗,22:00中又把WQ电话呼叫回公司,干到凌晨1点多才走.
又当爹又当妈,加人不给加,有种晕倒的冲动.
不过熬过来就好了,有解脱的感觉.
64-bit果然效果明显,210 又飞起来了.
3. 难以琢磨的小插曲
^^^^^^^^^^^^^^^^^^^
总体来讲一切顺利,18号当天大部分环境构建完毕了.
但小插曲总还是有的,而且似乎不亚于主线工作量.
最麻烦的是恢复samba用户,文件,还有权限,好几十G,数百个用户.
主要是没经验,samba用户依赖于本地用户,而且未指定uid.
移植后,smbpasswd的uid和系统不一致.
SER和SFC的这部分工作大概敲了100多行命令,大概花了2小时.
在新的生成环境下调试程序大概花费了2小时.
目前的结构和部署方式真的有点落伍和需要重新规划了.
何时能给一个重生的机会和冲动,神啊.
IP变更导致SMTP信任的一个插曲.
================ txt batch log ================
2009-04-20 01:46:38,892 ERROR [main - ExceptionLogger.java:107 - BatchManager]
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.SendFailedException: Invalid Addresses;
nested exception is:
javax.mail.SendFailedException: 553 sorry,
that domain isn't in my list of allowed rcpthosts (#5.7.1)
========================================================
================ tty: root@10.0.172.110 ================
cd /home/vpopmail/etc
echo '10.180.3.:allow,RELAYCLIENT=""' >> tcp.smtp
echo '10.180.9.:allow,RELAYCLIENT=""' >> tcp.smtp
/usr/local/bin/tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp
========================================================
================ tty shirj@10.180.3.156 ================
telnet 10.0.172.110 25
>Trying 10.0.172.110...
>Connected to 10.0.172.110 (10.0.172.110).
>Escape character is '^]'.
>220 5a-w03-b1.data-hotel.net ESMTP
HELO trydofor.com
>250 5a-w03-b1.data-hotel.net
MAIL FROM: sys-ser@credit.xxx.xx
>250 ok
RCPT TO: support@xxxxx.xx
>250 ok
DATA
>354 go ahead
Subject:test mail
test email
.
>250 ok 1240191948 qp 21225
QUIT
>221 5a-w03-b1.data-hotel.net
>Connection closed by foreign host.
========================================================
4. 坏消息,病症转移了
^^^^^^^^^^^^^^^^^^^
210好了,但207开始又了不祥之兆.
先是java批处理出现zombie,进入内核态,kill不掉,cpu占90%多,只能reboot.
后是9900 CAFIS端口访问不了,JRI 调查无果.
11号的时候,还能看到3条连接,20号之后,就只有2条了.
Google了一下,9900是特殊端口,莫非 ... ...
再后来,发送次数有所增多.
动不动就挂在某一个批处理上,或把机器耗死.
午夜凶铃或是对应各种批处理异常状态的修复.
207 是主要的业务服务器,上面7*24运行这很多凶险的批处理.
工龄比我要长,一直没换过班的超级服务器.
拜托IBM诊治一番.