阿尔卡特MFS MIB数据库异常的处理.doc

MFS MIB数据库异常的处理 近期现场多次发生MFS的两个STATION同时CRASH,无法启动的情况，通过分析及最终的解决过程来看，这些案例基本都有类似的情况，即SHARE DISK中的MIB数据库遭到了破坏。本文的目的是提供现场对于此类故障的应急措施及解决方法的一个参考，并提出一些预防措施，来尽量避免该故障的发生。 故障现象： OMCR上观察到MFS的连接中断，在MFS本端发现两个STATION不断重启，或登录至STATION A或B后，发现两个STATION的mfs及nectar进程都异常（通过ps –ef |grep mfs或ps –ef | grep nectar命令检查）。 故障的影响： 由于两个STATION同时CRASH,因此同GPRS相关的一些维护操作将无法在OMCR上进行操作，只要GPU状态正常，GPRS的通信业务不会受影响，但GPU一旦发生RESET操作时，由于GPU无法从MIB数据库中下载数据，因此GPU的状态将无法恢复正常状态，导致相关的GPRS资源无法恢复，从而造成GPRS通信业务的中断。 故障分析： 从现场的三个案例来看，两个STATION的操作系统都能够正常启动，但在启动应用进程的时候，STATION会突然CRASH并自动重启。收取usrfile.log文件观察启动信息我们一般能够发现“mib error”，在包含panic字段的文本中出现scim字段的现象，此时一般可认为是share disk中的mib数据库出现了异常，硬件上需排查与share disk相关的硬件故障，软件上需重建mib数据库。 故障的应急措施： 由于发生该故障时，GPU一旦发生RESET,将无法恢复而影响GPRS的通信，且在STATION的进程启动过程当中会触发所有GPU的RESET,因此为了保障GPRS的通信，需按如下步骤进行应急处理： 立刻中断每个JAETI上ETH端口的连线。目的是为了把MFS的TELCOM部分同STATION部分隔离开，以避免后续对STATION的操作引起GPU的RESET。 用终端登陆至MFS的两个STATION,并利用ps –ef | grep mfs的命令确认进程异常。同时通过df –k命令检查文件系统的占用情况并无异常。 若进程异常则在两个STATION上分别利用/usr/mfs/bin/mfs_stop_nectar命令重启STATION,已避免STATION自动重启进程而造成STATION不断自动重启。 在STATION A上登录至/var/adm/nectar/data/目录，删除counter文件（该文件中记录了一个计数器，对station自动的异常重启进行计数，当计数超过4以后，STATION重启时将不再对mfs的进程重启，检查该计数器可使用od –d counter命令。在删除该文件后，station在重启时会重新生成该文件，并把计数清零），该步骤的目的是为了后续的操作中，在重启STATION的时候，正常重启相关的进程。 在STATION A上利用/usr/mfs/bin/mfs_start_nectar –site 命令，单独重启STATION A,并观察现象，若是MIB数据库发生异常，则STATION的操作系统能够起来，但在进程重启时，会引起STATION的重启。 把STATION A的nectar stop掉，在STATION B上重复4,5两步步骤，验证STATION B的重启异常现象。 说明：步骤3，4，5，6是验证故障的现象 在两个STATION上分别收取usrfile1.log和usrfile2.log,并发给公司支持分析，是否有硬件上的故障，同时在OMC的历史告警中检查是否有SHARE DISK的告警，以此作初步的判断SHARE DISK是否存在异常。近期的3个案例中有1个案例是在usrfile.log文件能够发现share disk硬件故障的，在更换share disk硬件并重建MIB数据库后，故障解决。 重建MIB数据库 目前MIB数据库的重建一般有两种方法： 把STATION A启动至CONFIG模式，利用IMT终端重新打BUL FILE，完成该操作后利用/usr/mfs/bin/mfs_start_nectar –site 命令重启两个station。具体操作请严格参照 EVOLIUM A9135 MFS Maintenance Handbook（3BK 20835 AAAA PCZZA Ed.10）中的7.1.4章节 重建LSM系统，详细步骤可参考MFS TROUBLE SHOOTING GUIDE中5.5.9章节 简要步骤如下，供参考： 把当前版本的MFS的软件的光盘插入STATION A的光驱 在AS800上 执行: mount -r -t cdfs