某金融行业客户,业务系统采用P550小机双机HA+共享存储模式,一天业务高峰期准备切换窗口,业务报怎么也切换不过去,业务无法进行。运维接报后赶紧上P550去看,errpt查看错误日志,报其中一台光纤通道卡硬件故障,造成无法连接共享存储,马上上HACMP,准备先把资源切换到另一台服务器上去,这时候怪事出现了,无论怎么操作,资源就是切换不过去。这时候时间已经过去20分钟了,领导们听说这个事都赶过来了,围在周围商讨如何解决,同时急电IBM厂家技术支持立即赶往现场救火。
在等待厂家技术支持的时间里,我们一面重新想办法切换,一边查阅系统建设时的设计方案跟拓扑图,检查是不是当时建设方案有什么纰漏,仔细排查系统问题,厂家技术支持到达后也跟着一起检查设计方案,细细检查了设计方案拓扑,终于发现问题:当初建设方案小机光纤通道卡存在单点故障,造成该卡故障以后依然占用资源未释放,热备机无法接管,以致业务系统宕机,无法处理业务请求。
找出问题后,商定处理办法,重启光纤卡故障那台小机,释放占用资源,切换到另一台P550,重新接管资源,起应用系统,恢复业务处理,万幸的是业务终于可以运行了。看看时间,这时间已经过去一个小时了,相关外联单位的打来的电话已经打爆了,耽误了业务系统的处理,大家都走不了,万幸业务最终处理完了。后面在一个月食之夜对该业务系统进行升级变更,最终彻底解决了这个问题。
我个人感觉针对此案例:1、方案出来后,方案评审不能走过场。2、灾难切换演练必须进行,应充分测试。3、单点故障是系统管理员及相关负责人对整体方案必需考虑的因素,必须加以重视。4、此故障案例缺乏监控手段,未有效快速故障定位。
收起1.关于案例分享,有时候未必就是很高深的问题或BUG影响。现场工程师往往因为各方面的压力会存在一些判断盲区,保持思路清晰才能使问题不扩散影响最小化。一方面也是在提醒大家,要注意在规划或者在问题判断时候一些的细节(管理和技术逻辑上)。
2.本次卷组磁盘疑似存在属性设置问题,诸如:fast_fail等参数。
收起几个方向:
1系统无多路径管理,只配置一块光纤卡,没有冗余,造成本机访问存储异常,业务异常,这是设计缺陷。
2光纤卡及磁盘参数没正确设置,光纤卡故障后,造成time out时间过长,使数据库及应用异常,存储资源释放不掉,备机hacmp没有正常接管。
3存储Vg资源释放不了,应该检查hacmp日志,检查具体造成无发接管的原因,而不是临时看所谓的设计方案。
4重启主节点,恢复业务后还是没有查明hacmp切换失败根本原因,也没说清架构上的设计缺陷,对hacmp的掌握程度可想而知。
收起这个案例比较和谐,没有出现厂商之间扯皮互相推诿,直接找了替死鬼立马大事化小,也是个做法.毕竟事情搞大了对谁没有好处。但是事出了,到底是谁估计都想知道,越是诡异的事情往往原因很简单。最终没有靠日志有罪推论HBA而靠查看拓扑证明实在过于牵强
收起项目实施之前的规划方案都设计的不合理!如果当初把规划设计调研搞好也不会出现这种问题!可悲!
收起这样的单点绝对是说不过去的,根本原因是什么?单点不是才出的概念,懂架构设计的一定会考虑。除非资源不够。
收起生产系统这种情况下能上线也是一种胸怀。
前天:有一个客户双hba卡,突然掉了一般的链路,主机和存储各自检查,最后定位hba卡不工作了,啥叫不工作了,就是所谓的hang死了。还好是双hba卡,协调窗口,重启,链路恢复,后续再说是否考虑替换hba卡的事。
金融客户我们的理解不差钱啊,这个有明显单点的情况下怎么就上了呢。
引以为戒吧
收起