罗列一下有关oprocd的知识点
oprocd是oracle在rac中引入用来fencing io的
在unix系统下,假设我们没有採用oracle之外的第三方集群软件,才会存在oprocd进程
在linux系统下,仅仅有在10.2.0.4版本号后,才会具有oprocd进程
在window下,不会存在oprocd 进程,可是会存在一个oraFenceService服务,用来实现同样的功能,该服务採用的技术是基于windows的,与oprocd不同
oprocd进程能够执行在两者模式下:fatal和no fatal,在fatal模式下,假设系统hang住,或者其它原因触发oprocd则oprocd进程会自己主动重新启动server。在no fatal模式下,假设系统hang住,或者其它原因触发oprocd进程,则oprocd进程会在日志中记录警告信息,可是不会重新启动系统。
oprocd进程具有两个參数:timeout 指定oprocd进程调用的时间间隔 margin 指定同意的时间偏差,假设时间偏差超过margin,则oprocd进程会重新启动系统或者记录错误信息到日志。
oprocd进程的日志文件位于:/etc/oracle/oprocd 或者 /var/opt/oracle/oprocd
oprocd进程从cssd进程派生而来,而且以root用户身份同意
[root@node2 init.d]# ps -ef | grep oprocd
root 5109 11227 0 20:37 pts/0 00:00:00 grep oprocd
root 5758 4849 0 19:14 ? 00:00:00 /bin/sh /etc/init.d/init.cssd oprocd
root 6084 5758 0 19:14 ? 00:00:00 /u01/app/crs_home/bin/oprocd.bin run -t 1000 -m 10000 -hsi 5:10:50:75:90 -f
假设一个节点被hang住了非常长时间,那么集群中的其它节点会把该节点剔除出去,在这样的情况下,我们须要採取措施重新启动被hang住的节点,以便达到fencing io的目的。oprocd被设置了两个參数:timeout 和margin,进程会每间隔timeout时间被唤醒一次,假设本次被唤醒的时间与上次被唤醒的时间间隔超过timeout+margin,那么oprocd进程会觉得oracle 节点被hang住,因此会自己主动重新启动节点或者将警告信息写入日志。
通常情况下,我们能够将oprocd进程重新启动系统的原因归为四类:
1::操作系统的调度问题
2:操作系统的存在硬件或者驱动问题
3:系统具有大量负载,导致调度程序无法及时调入oprocd进程
4:oracle bug
Bug 5015469 – OPROCD may reboot the node whenever the system date is moved
backwards.
Fixed in 10.2.0.3+
Fixed in 10.1.0.3 + One off patch for Bug 4206159.
Fixed in 10.2.0.4+
Fixed in 10.2.0.3+
Bug 4206159 – Oprocd is prone to time regression due to current API used (AIX only)
Diagnostic Fixes (VERY NECESSARY IN MOST CASES):
Bug 5137401 – Oprocd logfile is cleared after a reboot
Bug 5037858 – Increase the warning levels if a reboot is approaching
oprocd进程的两个參数:timeout和margin,其默认值在init.cssd 文件里指定,如
[root@node2 init.d]# cat init.cssd | grep ^OPROCD_DEFAULT_
OPROCD_DEFAULT_TIMEOUT=1000
OPROCD_DEFAULT_MARGIN=500
OPROCD_DEFAULT_HISTORGRAM=
因此,默认情况下,假设两次唤醒oprocd进程的时间间隔超过1.5s,oprocd进程就会重新启动系统。这往往是不合适的,假设我们手工改动init.cssd文件里的默认值,须要oracle support才干够。
假设须要突破1.5s的限制,我们能够调用init.cssd来实现目的,通过调用init.cssd能够改动两个參数:reboottime 和 diagwait,假设diagwait> reboottime,那么margin=diagwait-reboottime。在设置diagwait时,须要将集群中全部节点的全部进程停掉,都在能够造成数据损坏,仅仅需在rac中的一个节点改动就可以。建议将diagwait改动为13
[root@node2 bin]# ./crsctl get css reboottime
3
[root@node2 bin]# ./crsctl get css diagwait
13
[root@node2 bin]# ./crsctl set css diagwait 13 -force
在11.2.0.1后,我们不再须要改动diagwait,因此架构已经发生了改变。
在windows下我们也能够改动diagwait,可是与在linux下不同,改动diagwait不会造成上面的变化。
以下再来看一下有关hangcheck_timer的有关信息,hangcheck_timer与oprocd能够实现同样的功能,可是两者之间没有必定的联系
Hangcheck-Timer Module
Hangcheck-Timer Module Requirements for Oracle 9i, 10g, and 11g RAC on Linux
Starting in release 9.2.0.2 and later, Oracle RAC environments required using a new I/O fencing model, named the hangcheck-timer module. This module was implemented to replace the Watchdog module, which provided similar fencing functionality. Hangcheck-timer was subsequently delivered as part of the standard kernel distribution for Linux kernel releases 2.4 and above.
Hangcheck-timer should be loaded at boot time, and monitors the Linux kernel for long operating system hangs that could affect the reliability of a RAC node. It runs in kernel mode and uses the Time Stamp Counter (TSC) to catch scheduling delays or node hangs. This is done by setting a timer, then checking when the timer fires as to whether it was delayed by more than the allowed margin of error. If the duration exceeds the allowed time of (hangcheck_tick + hangcheck_margin seconds), the machine is restarted. Hangcheck-timer will not cause reboots to occur due to CPU starvation.
Hangcheck-timer requires three configuration parameters:
hangcheck_tick - defines how often, in seconds, the hangcheck-timer checks the node for hangs. The default value is 60 seconds.
hangcheck_margin - defines how much margin is allowed, in seconds, between expected scheduling and real scheduling time. The default value is 180 seconds.
hangcheck_reboot - determines if the hangcheck-timer restarts the node if the kernel fails to respond within the sum of the hangcheck_tick and hangcheck_margin parameter values. If the value of hangcheck_reboot is equal to or greater than 1, then the hangcheck-timer module restarts the system. If the hangcheck_reboot parameter is set to zero, then the hangcheck-timer module will not reboot the node, even if a hang is detected. The default value varies by kernel version. In the 2.4 kernel, the default is 1. In 2.6 kernels, the default is 0.
Hangcheck-timer will provide message logging to the system messages log when a failure is detected, and a node restart is initiated by the module:
When Hangcheck-timer reboots it may leave "Hangcheck: hangcheck is restarting the machine" message in /var/log/messages
If you see the following message in /var/log/messages: "Hangcheck: hangcheck value past margin!" this means a reboot was required but was not performed, because hangcheck_reboot was not set to 1. If this message is seen, you must reload the hangcheck module as described earlier in this note, with the hangcheck_reboot value set to 1.
Note : Hangheck timer is not required starting with Oracle Clusterware 11gR2