免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123下一页
最近访问板块 发新帖
查看: 34417 | 回复: 23

[故障求助] 我的征文投稿,大家给点意见啊!(全文已完成) [复制链接]

论坛徽章:
0
发表于 2006-07-20 02:20 |显示全部楼层
修炼之路
最近在朋友的推荐下看了热播剧集《prison break》,确实精彩,片中无处不在的细节让人不得不佩服男主人公的schedule实在是做得完美。感慨之余想起到相关论坛上看看大家的评论,这才发现很多我捕捉到的细节和心领神会的method居然没几个人看懂了。不由得让我凭空多了一层念想,是自己也能够适应fox river那样的牢狱生活,还是多年来AIX service的工作经历让我已与往日不同。嘿嘿,我情愿相信是后者。

hacmp.棍子.灵异现象
     hacmp是IBM在P系列服务器上使用的群集管理软件,安装配置很方便,在实际使用中可处理一些系统单点故障,从而提高整套系统的可用性。但是使用hacmp的环境也常常出现奇怪的现象,从而让维护的技术人员头疼不已,我们称之为“灵异现象”……
     2002年的夏天,湖南长沙,XX医院,hacmp互备。
     这个医院的财务系统用的是IBM H85的双机,hacmp互备模式,DB2数据库,2台机器分管住院部和门诊部的财务系统。不知道从哪一天开始,这套系统也碰上了让人头疼的“灵异”。医院的系统管理员说他们在正常使用中突然发现住院部的财务系统运行突然变慢了,经检查才发现住院部那台机器已经宕机,住院部业务已经由门诊部那台顺利接管,只不过由于系统资源紧张,所以才让窗口的业务人员发现速度有异。接下来,系管重新开机,重新启动hacmp,一套流程走下来,住院部主机重新担负起了自己的任务,业务窗口速度也恢复了正常。
看上去一切都挺好,系统环境又恢复了正常,只不过……
      三天以后,住院部主机又挂了。再来一次恢复流程,住院部主机起死回生……
      三天以后,“挂”就一个字……
         如此反复,这家医院的系管已经可以掐指算出住院部主机即将到来的“死亡时间”,误差不超过3小时。在这家医院信息部领导精神全面崩溃之前,他们找到了我所在的公司。
     老板给我交代任务的时候,附带告诉我在此之前已经有资深的软硬件工程师到现场全面检查过了,每个人都是拍拍胸脯告诉可怜的系管自己这一块绝对没问题然后以尽可能快的速度离开了现场,留下系管一人绝望的面对即将到来的宕机时间……死亡无法避免。
     说实话,这附带信息对当时只有一年AIX经验的我来说不是什么很有用的消息,除了凭空多出许多压力之外。
     到了现场,我一直在想一个问题——系管的头发是一直这么少,还是这段时间才发生了变化。问题没有答案,我只希望能够帮到这个可怜的同行,看上去他虽然很热情,但是和遍访名医的重症病人家属一样,眼神中已经失去了“求生”的信念。
     排除杂念,对着住院部的主机我砍出三板斧——df,errpt,diag。无效。一切看上去都很正常。细想想,这也正常,这三斧头是个人就会砍。想必在我之前来的那些资深已经都砍过三十几斧头了。再看看hacmp.out文件,顿时有了点不敢相信自己眼睛的感觉——已经生成了近50MB的文本文件。原本想从里面找点信息的想法一瞬间也去了大洋对岸。难怪资深们都闪人了,我似乎有点明白了。
    口中默念着高中班主任留给我的名人名言——“人啊!不能在一棵树上吊死,让我们一起来换棵树吧!”——我杀向门诊部主机。
     系管有些惊讶,但还是尽量委婉的告诉我:“严工,这台机器是好的”。
    “知道”,回应:“我看看”
      同样无效的三斧头过后,总算hacmp.out给了我一线希望,这台机器的hacmp.out相比较而言还算正常,虽然也过分的达到了11MB的大小。
      在“尽量”仔细的阅读hacmp.out之后,我开始深刻理解资深们的难处了。巨量的事件脚本记录给“阅读”带来了麻烦,2个小时的仔细阅读之后,除了感觉眼睛有点疼,我暂时没有别的新见解。
无奈中,我开始快速翻屏,现在回想起来,当时这么做可能是潜意识中的放弃。如《骇客帝国》中飞快滚动的黑底绿字由下而上的掠过屏幕,除了更加不可阅读之外,似乎没有别的什么好处了。
等等……这是什么……
      由于快速翻屏和每个事件纪录长度大致相等的2个重要因素,加上视觉暂留效应,我在屏幕上的特定位置看到了近乎稳定的事件名称fail_standby_adapter和join_standby_adapter。这两个事件记录名称如此显眼的出现在我面前,确实让我精神为之一振。这样的情况下我还能看到这两个事件,只能说明这两个事件出现的次数特别多。详细检查了这两个事件发生的时间点,得到了让我开始感觉兴奋的消息——每秒钟要发生4到5次的fail_standby和join_standby。这说明有块standby的网卡不断的退出和加入到standby状态。顺着思路往下想,如此高频率发生的事件记录除了要写入本机的hacmp.out还要通过网络写入到另外节点的hacmp.out,这样会直接导致另外节点的hacmp.out处于持续打开的状态,同时也会占用相当大空间的file buffer且由于不断的写入而不会释放。物理实存用完之后开始使用paging,加上业务压力,paging用完之后,主机必死无疑。这样一个内存耗尽的过程,三天都算是撑得够长了。
      带着激动的心情我检查了不断fail和join的standby网卡的物理位置——门诊部主机的standby网卡,这就可以解释为什么一旦住院部主机宕机,门诊部主机可以接管住院部业务除了速度慢之外而不会再宕机。因为这个接管时间点之后,原门诊部主机standby网卡已经接管了住院部主机的service地址,当然也就不存在fail_standby和join_standby的事件发生了,取而代之的是住院部业务系统的service网卡有丢包——表现出来的现象就是住院部窗口业务运行慢。
      因为做过diag没有发现网卡损坏,所以问题发生的原因如果不是网线就是交换机端口。
      等我告诉那个心灰意冷的人问题原因就在一根网线上时,你完全可以想象他当时的表情。而我当时脑海里出现的场景则是我父亲当年用一根木棍就修好了我母亲厂里的巨型空调并且赢得了她的芳心,他只是用棍子敲了敲那台不肯工作的机器一切就恢复了正常。多年以后,我父亲每每提起此事,总是得意地告诉我“关键不在用什么棍子,在于你要知道敲哪里”

微码.警察.跑路

Oracle.球.世界杯


——————————————————

还没写完,,继续中,,看到的朋友给点意见,谢谢了!

[ 本帖最后由 yanbing 于 2006-7-31 18:50 编辑 ]

论坛徽章:
0
发表于 2006-07-20 09:17 |显示全部楼层
很有启发意义,比如做故障分析时有时候来点换位思考会有很好的效果.

论坛徽章:
1
荣誉会员
日期:2011-11-23 16:44:17
发表于 2006-07-20 14:52 |显示全部楼层
prison break```````
i want it`

i have just watched  lost``     
give u a suggestion!
so good!

论坛徽章:
0
发表于 2006-07-21 09:47 |显示全部楼层
冰动三尺,非一日之寒啊!

论坛徽章:
0
发表于 2006-07-21 16:05 |显示全部楼层
很受启发,收藏,顶

论坛徽章:
0
发表于 2006-07-21 16:31 |显示全部楼层
精华!!

论坛徽章:
0
发表于 2006-07-28 10:06 |显示全部楼层
据可靠消息透露,楼主这篇征文很有可能得冠啊!!恭喜先

论坛徽章:
0
发表于 2006-07-28 11:40 |显示全部楼层
顶一下,球

论坛徽章:
0
发表于 2006-07-28 11:44 |显示全部楼层
顶一下,球?

论坛徽章:
0
发表于 2006-07-28 13:21 |显示全部楼层
顶个球!?
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP