星期三 三月 28, 2012

如何诊断节点重启问题

本文对如何诊断RAC环境中节点重启问题进行了介绍。适用于10gR2和11gR1.

首先我们对能够导致节点重启的CRS进程进行介绍。
1.ocssd : 它的主要功能是节点监控(Node Monitoring)和组管理(Group Management),它是CRS的核心进程之一。节点监控是指监控集群中节点的健康,监控的方法是通过网络心跳(network heartbeat)和磁盘心跳(disk heartbeat)实现的,如果集群中的节点连续丢失磁盘心跳或网络心跳,该节点就会被从集群中驱逐,也就是节点重启。组管理导致的节点重启,我们称之为node kill escalation(只有在11gR1以及以上版本适用),我们会在后面的文章进行详细介绍。重启需要在指定的时间(reboot time,一般为3秒)内完成。

网络心跳:ocssd.bin进程每秒钟向集群中的各个节点通过私网发送网络心跳信息,以确认各个节点是否正常。如果某个节点连续丢失网络心跳达到阀值,misscount(默认为30秒,如果存在其他集群管理软件则为600秒),集群会通过表决盘进行投票,使丢失网络心跳的节点被主节点驱逐出集群,即节点重启。如果集群只包含2个节点,则会出现脑裂,结果是节点号小的节点存活下来,即使是节点号小的节点存在网络问题。

磁盘心跳:ocssd.bin进程每秒钟都会向所有表决盘(Voting File)注册本节点的状态信息,这个过程叫做磁盘心跳。如果某个节点连续丢失磁盘心跳达到阀值,disk timeou(一般为200秒),则该节点会自动重启以保证集群的一致性。另外,CRS只要求[N/2]+1个表决盘可用即可,其中N为表决盘数量,一般为奇数。

2.oclsomon:这个进程负责监控ocssd是否挂起,如果发现ocssd.bin存在性能问题,则重启该节点。
3.oprocd:这个进程只在Linux和Unix系统,并且第三方集群管理软件未安装的情况下才会出现。如果它发现节点挂起,则重启该节点。

注意:以上的所有进程都是由脚本init.cssd产生的。

接下来是诊断节点重启问题是经常搜集的信息。
1.操作系统日志
2.<crs主目录>/log/<节点名称>/cssd/ocssd.log
3.oprocd.log(/etc/oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*)
4.<crs主目录>/log/<节点名称>/cssd/oclsomon/oclsomon.log
5. Oracle OSWatcher 报告

接下来我们讨论如何诊断节点重启问题。

1.由ocssd导致的节点重启。
如果在ocssd.log中出现以下错误,则表示节点重启是由于丢失网络心跳。接下来需要查看和网络相关的信息,如操作系统日志,OSW报表(traceroute的输出),以确定网络层面(cluster interconnect)是否存在问题,并确定最终的原因。
[ CSSD]2012-03-02 23:56:18.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 50% heartbeat fatal, eviction in 14.494 seconds
[ CSSD]2012-03-02 23:56:25.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 75% heartbeat fatal, eviction in 7.494 seconds
[ CSSD]2012-03-02 23:56:32.749 [3086] >WARNING: clssnmPollingThread: node <node_name>at 90% heartbeat fatal, eviction in 0.494 seconds
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmPollingThread: Eviction started for node <node_name>, flags 0x040d, state 3, wt4c 0
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmDiscHelper: <node_name>, node(4) connection failed, con (1128a5530), probe(0)
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmDiscHelper: node 4 clean up, con (1128a5530), init state 5, cur state 5
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE:   clssnmDoSyncUpdate: Initiating sync 196446491
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE:   clssnmDoSyncUpdate: diskTimeout set to (27000)ms

注意:如果在主节点的ocssd.log中出现以上信息的时间点要晚于节点的重启时间,则说明节点重启的原因不是丢失网络心跳。

如果ocssd.log中出现以下错误,则表示节点重启是由于丢失磁盘心跳。接下来需要查看操作系统日志,OSWatcher报告(iostat的输出),以确定i/o层面是否存在问题,并确定最终的原因。
2010-08-13 18:34:37.423: [    CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:34:37.423: [    CLSF][150477728]Opened hdl:0xf4336530 for dev:/dev/sdb8:
2010-08-13 18:34:37.429: [   SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:34:37.429: [    CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
2010-08-13 18:34:38.205: [    CSSD][4110736288](:CSSNM00058: )clssnmvDiskCheck: No I/O completions for 200880 ms for voting file /dev/sdb8)
2010-08-13 18:34:38.206: [    CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [    CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################

2. 由oclsomon导致的节点重启。
如果在oclsomon.log 中出现错误,则表示节点重启是由于ocssd进程挂起,由于ocssd进程拥有实时(RT)优先级,很可能此时操作系统存在资源(如cpu)竞争,接下来需要察看操作系统日志,OSW报表(vmstat,top的输出),以确定最终的原因。

3.由oprocd导致的节点重启。
如果在oprocd日志中出现以下信息,则表明节点重启是由oprocd进程导致。

Dec 21 16:15:30.369857 | LASTGASP | AlarmHandler:  timeout(2312 msec) exceeds interval(1000 msec)+margin(500 msec).   Rebooting NOW.

由于oprocd进程通过查看系统时间以确定操作系统是否挂起,正确的配置ntp(或其他时间同步软件),调整diagwait=13 可以避免节点重启,另外,如果需要大幅度修改系��时间,建议首先停止CRS,在修改完成之后再重新启动。当然,我们也不排除操作系统挂起导致oprocd重启节点,所以,也需要查看OSWatcher报告(vmstat,top的输出),以确定最终的原因。

本文只是对诊断节点重启问题的思路进行了介绍,在具体实际问题当中还需要灵活运用。



关于更多的信息,请阅读以下的MOS 文章。
Note 265769.1 :Troubleshooting 10g and 11.1 Clusterware Reboots
Note 1050693.1 :Troubleshooting 11.2 Clusterware Node Evictions (Reboots)

About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天