AIX系统宕机分析教程PPT!
- 格式:pptx
- 大小:1.63 MB
- 文档页数:61
RS/6000小型机故障的基本定位方法一故障的定义.弄清楚系统发生了什么问题.系统现在能做什么?不能做什么?.故障什么时候发生的?.有没有做平时不同的操作?.故障有没有规律?定时还是不定时?发生的频率有多高?.是一台机器出现故障还是多台机器故障?故障现象是否相同?.最近有没有做改动?如安装了新的硬件、软件,改变了系统的一些设臵。
二故障信息的收集1)收集故障信息对于判断、诊断故障原因,修复系统非常重要。
2)系统故障记录(errorlog)errdemon进程在系统启动时自动运行记录包括硬件、软件及其他操作信息故障记录文件为/var/adm/ras/errlog,可备份下来或拷贝到别的机器上分析 errpt 命令的使用(普通用户权限也可使用)#errpt |more 列出简短出错信息ERROR_ID TIMESTAMP T C RESOURCE_NAME ERROR_DESCRIPTION192AC071 0723100300 T 0 errdemon Error logging turned off0E017ED1 0720131000 P H mem2 Memory failure9DBCFDEE 0701000000 T 0 errdemon Error logging turned on038F2580 0624131000 U H scdisk0 UNDETERMINED ERRORAA8AB241 0405130900 T O OPERATOR OPERATOR NOTIFICATIONTIMESTAMP: MMDDHHMMYY (月日时分年)T(类型): P 永久; T 临时; U 未知(永久性的错误应引起重视)C(分类): H 硬件; S 软件; O 用户; U未知#errpt -d H 列出所有硬件出错信息#errpt -d S 列出所有软件出错信息#errpt -aj ERROR_ID 列出详细出错信息# errpt -aj 0502f666 <--- ERROR_ID用大小写均可例:LABEL: SCSI_ERR1ID: 0502F666Date/Time: Jun 19 22:29:51Sequence Number: 95Machine ID: 123456789012Node ID: host1Class: HType: PERMResource Name: scsi0Resource Class: adapterResource Type: hscsiLocation: 00-08VPD: <--- Virtal Product DataDevice Driver Level (00)Diagnostic Level (00)Displayable Message.........SCSIEC Level....................C25928FRU Number..................30F8834 Manufacturer................IBM97FPart Number.................59F4566Serial Number (00002849)ROS Level and ID (24)Read/Write Register Ptr (0120)DescriptionADAPTER ERRORProbable CausesADAPTER HARDWARE CABLECABLE TERMINATOR DEVICEFailure CausesADAPTERCABLE LOOSE OR DEFECTIVERecommended ActionsPERFORM PROBLEM DETERMINATION PROCEDURESCHECK CABLE AND ITS CONNECTIONSDetail DataSENSE DATA0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00003)控制面板上的LED 代码.8 位代码,通常系统故障灯会同时亮起。
多么痛的领悟:十三起惨痛宕机案例01AIX 下NTP 设置不当导致的多个集群宕机事情发生在一段时间之前,接到朋友电话,用户有三套oracle rac 集群运行在 aix 小机上,本地两套,同城机房两套,做完设备搬迁后的一天晚上,其中本地和同城的两套rac 突然就整个重启了,而且发生在同一时间点。
网络、小机、存储、数据库分属不同的维保厂商,这就开始了扯皮。
各家就开始从自己的方向自证无过错。
我去之前内心也比较倾向于 oracle 的网络心跳出了问题,crs 抢 vote disk 的时候触发了重启。
但由于是小机方的代表,仅从aix 层面做了排查,未发现明显原因。
对各主机宕机的时间做了一个梳理,去和oracle 的事件日志去比对。
暂时没查到什么东西。
宕机产生的dump 发到了IBM 原厂,IBM 后来出了个报告,根据dump 内容定位触发宕机的进程为cssd。
oracle dba 重点看了那个进程的日志,发现宕机时间前后,时间突然变更,提前了40多秒。
dba 确认,时间变更过多,cssd 进程会导致系统重启,怀疑和时间同步有关。
经检查,3套 aix 的 rac 集群使用了同一个 ntp server,但有一套没发生问题。
对比检查差异,发现没问题的那套主机集群使用xntpd 方式配置了时间同步。
出问题的主机则直接使用了ntpdate 命令做时间更新,并写入了 crontab 定期执行。
检查 /var/adm/cron/log 日志,发现定时任务的执行时间和 cssd 故障时间一致。
检查时间服务器,发现搬迁后,时间服务器的时间产生了较大偏差,xntpd 方式的时间同步在时间偏差大时不会去强制同步,ntpdate 命令的方式没有这个限制,会直接进行同步。
最终导致了 cssd 进程检测到过大时间偏差后触发了宕机。
经验分享:配置时间同步时,建议使用xntpd 服务的方式,不用直接在定时任务里写 ntpdate,因为 ntpdate 比较粗暴,发生故障时较大的时间偏差会导致应用出现问题,触发无法预知的后果。