Oracle 11G R2 RAC 在Red Hat 7.4上的NTP服务配置问题

Oracle一体机用户组 2019-12-26

4075

作者简介

王伟，目前就职于北京海天起点技术服务股份有限公司，提供Oracle技术支持。拥有5年服务于电信，联通，移动，医院，政府相关单位等行业核心系统oracle数据库运维经验，并获得Oracle 12C OCP证书，擅长Oracle数据库方面的故障诊断和问题处理。

概述

近期在一个客户现场搭建了一套运行在Red Hat 7.4上的Oracle 11G R2 RAC(4节点)，业务在应用测试阶段出现了1次2节点被驱逐的问题，通过一系列的检查和分析，最终确认是NTP服务配置不正确导致的节点驱逐问题。

问题描述

平台环境

操作系统：Red Hat 7.4

数据库版本：Oracle 11.2.0.4.190416 RAC (4节点)

报错信息

–gi的alert日志报错信息：

2019-09-25 19:24:18.420
[cssd(6192)]CRS-1612:Network communication with node racnode02 (2) missing for 50% of timeout interval.  Removal of this node from cluster in 14.500 seconds
2019-09-25 19:24:25.422
[cssd(6192)]CRS-1611:Network communication with node racnode02 (2) missing for 75% of timeout interval.  Removal of this node from cluster in 7.500 seconds
2019-09-25 19:24:30.424
[cssd(6192)]CRS-1610:Network communication with node racnode02 (2) missing for 90% of timeout interval.  Removal of this node from cluster in 2.500 seconds
2019-09-25 19:24:32.925
[cssd(6192)]CRS-1607:Node racnode02 is being evicted in cluster incarnation 179915229; details at (:CSSNM00007:) in u01/app/gridhome/log/racnode01/cssd/ocssd.log.

复制

问题说明

从上面的报错可以看出是私有网络异常导致的节点驱逐，这也是一个很常见的节点驱逐报错。

从主机层面/var/log/message上查看没有错误的硬件信息输出。

从OSW上的oswprvtnet中可以看到2节点和4节点在问题时间段有很大的延迟出现

在1和3节点手动ping 2和4节点的priv IP,都没有问题，time都在1ms以下，属于正常的现象。

找网络工程师查看私有网络是否有延迟问题，经过排除没有任何问题。

由于4台数据库服务器采用的时间同步方式是ntp服务，检查ntp服务状态都是actived的，没有问题，但是使用date命令检查主机时间时，却发现2节点和4节点都比正确的时间慢了将近20分钟，这就有问题了。

问题分析

检查NTP服务状态是否正常

使用systemctl 检查ntp服务状态是active (running)

# systemctl status ntpd
 ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: active (running) since 二 2019-11-05 19:46:11 CST; 3 weeks 1 days ago
 Main PID: 6944 (ntpd)
   CGroup: system.slice/ntpd.service
           └─6944 usr/sbin/ntpd -g -x
 
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 14 enp130s0f1 fe80::6701:8e10:1e45:5c26 UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 15 bond0 fe80::aaf1:a837:9bd1:634e UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 16 enp2s0f0 fe80::1882:9b39:f851:6db4 UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listening on routing socket on fd #33 for interface updates
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c016 06 restart
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c012 02 freq_set ntpd 7.473 PPM
11月 05 19:49:29 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c615 05 clock_sync
11月 05 20:12:23 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 17 bond0:2 10.238.11.68 UDP 123
11月 05 20:12:23 nanhudb04.db.xjmc ntpd[6944]: new interface(s) found: waking up resolver
11月 06 17:10:55 nanhudb04.db.xjmc ntpd[6944]: Deleting interface #17 bond0:2, 10.238.11.68#123, interface stats: received=0, sent=...12 secs
Hint: Some lines were ellipsized, use -l to show in full.

复制

使用cluvfy命令检查NTP服务

可以看出NTP服务检查失败，集群启动默认的CTSS进程进行时间同步校验。

$ cluvfy comp clocksync -n all -verbose

验证 各集群节点上的时钟同步
 
正在检查是否在所有节点上安装了集群件…
集群件的安装检查通过
 
正在检查 CTSS 资源是否在所有节点上运行…
检查: CTSS 资源是否正在所有节点上运行
  节点名 状态                    
  ------------------------------------ ------------------------
  racnode01 通过                    
  racnode04 通过                    
  racnode03 通过                    
  racnode02 通过                    
结果:CTSS 资源检查通过
 
正在查询所有节点上时间偏移量的 CTSS…
结果:时间偏移量的 CTSS 查询通过
 
检查 CTSS 状态已启动…
检查: CTSS 状态
  节点名 状态                    
  ------------------------------------ ------------------------
  racnode01 观察程序                  
  racnode04 观察程序                  
  racnode03 观察程序                  
  racnode02 观察程序                  
CTSS 处于观察程序状态。使用 NTP 切换到时钟同步检查
 
正在使用网络时间协议 (NTP) 启动时钟同步检查…
 
NTP 配置文件检查开始…
NTP 配置文件 “/etc/ntp.conf” 在所有节点上可用
NTP 配置文件检查通过
 
正在检查守护程序的活动性…
 
检查: “ntpd” 的活动性
  节点名 正在运行?                  
  ------------------------------------ ------------------------
  racnode01 否                      
  racnode04 否                      
  racnode03 否                      
  racnode02 否                      
结果:”ntpd” 的活动性检查失败
PRVF-5494 : NTP 守护程序或服务并非在所有节点上均处于活动状态
PRVF-5415 : 检查以确定 NTP 守护程序或服务是否运行失败
结果:使用网络时间协议 (NTP) 进行时钟同步检查失败
 
PRVF-9652 : 集群时间同步服务检查失败
 
在所有指定节点上验证 各集群节点上的时钟同步 失败。

复制

分析NTP问题

这个问题就奇怪了，明明NTP服务是actived的状态，而且NTP 配置文件 "/etc/ntp.conf"在所有节点上可用，检查ntp配置文件/etc/sysconfig/ntpd，也已经从默认值OPTIONS="-g"修改成OPTIONS="-x -g"，但是在使用命令$ cluvfy comp clocksync -n all –verbose检查时为什么会失败呢？

通过MOS文档《Linux:CVU NTP Prerequisite check fails with PRVF-7590, PRVG-1024 and PRVF-5415 (Doc ID2126223.1)》分析可以看出：If var/run/ntpd.pid does not existon the server, the CVU command fails. This is due to unpublished bug 19427746 which has been fixed in Oracle 12.2.（意思是：如果服务器上不存在/var/run/ntpd.pid，则CVU命令失败。这是由于未发布的错误BUG 19427746，该错误已在Oracle 12.2中修复。）

处理建议

启用CTSS

Configure CTSSD to start master mode so that ntp is no longer used.

[root_user@<hostname> ~]# crsctl stop crs
[root_user@<hostname> ~]# systemctl stop ntpd
[root_user@<hostname> ~]# systemctl disable ntpd
[root_user@<hostname> ~]# rm var/run/ntpd.pid
[root_user@<hostname> ~]# crsctl start crs

复制

或者

Configure NTPD service to start with a pidfile so that CVU properly detects NTP service to be running. To do so, edit/etc/sysconfig/ntpd and modify the below line

OPTIONS="-g"

复制

OPTIONS="-g -p var/run/ntpd.pid"

复制

and restart NTPD service

说明：我们采用第2种方式进行修改，把/etc/sysconfig/ntpd从默认值OPTIONS="-g"修改成OPTIONS="-x -p/var/run/ntpd.pid"。

重启NTP服务器使之生效

# systemctl status ntpd
 ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: active (running) since 二 2019-11-05 19:46:11 CST; 3 weeks 1 days ago
 Main PID: 6944 (ntpd)
   CGroup: system.slice/ntpd.service
           └─6944 usr/sbin/ntpd -u ntp:ntp -x -p var/run/ntpd.pid
 
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 14 enp130s0f1 fe80::6701:8e10:1e45:5c26 UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 15 bond0 fe80::aaf1:a837:9bd1:634e UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 16 enp2s0f0 fe80::1882:9b39:f851:6db4 UDP 123
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: Listening on routing socket on fd #33 for interface updates
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c016 06 restart
11月 05 19:46:11 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c012 02 freq_set ntpd 7.473 PPM
11月 05 19:49:29 nanhudb04.db.xjmc ntpd[6944]: 0.0.0.0 c615 05 clock_sync
11月 05 20:12:23 nanhudb04.db.xjmc ntpd[6944]: Listen normally on 17 bond0:2 10.238.11.68 UDP 123
11月 05 20:12:23 nanhudb04.db.xjmc ntpd[6944]: new interface(s) found: waking up resolver
11月 06 17:10:55 nanhudb04.db.xjmc ntpd[6944]: Deleting interface #17 bond0:2, 10.238.11.68#123, interface stats: received=0, sent=...12 secs
Hint: Some lines were ellipsized, use -l to show in full.

复制

使用命令$ cluvfy comp clocksync -n all –verbose检查，NTP检查校验成功。

总结

在Red Hat 6上配置NTP时，配置文件/etc/sysconfig/ntpd的默认值就是：OPTIONS="-untp:ntp -p /var/run/ntpd.pid -g"，我们只需要再加上一个"-X"就行，所以不会出现配置了NTP而没有进行时间同步的问题。

到了Red Hat 7时，配置文件/etc/sysconfig/ntpd的默认值变成了OPTIONS="-g"，我们就习惯性的添加一个"-x"，以为这样就没有问题了，其实不然，反而因为没有使用pidfile文件配置NTP来启动，触发了未发布的bug 19427746，导致NTP假同步。

结束语

此次节点驱逐问题，主要是RedHat7上的NTP配置文件/etc/sysconfig/ntpd默认值变了，修改时未添加pidfile文件，启动NTP服务后触发未发布的bug 19427746(此BUG在12.2中修复完成)，造成一种NTP服务已启动但是时间未同步的假象，处理方式是按照Redhat6上的配置信息进行配置。

题外话，其实从Red Hat 7开始，默认使用chrony进行时间同步，但是因为现在几乎100%的生产环境都使用了NTP服务器，成熟且稳定，故操作系统就算升级到Redhat7，依然还是用ntp服务进行时间同步。

切记，chrony服务和NTP服务不可同时运行。一个启动，另外一个就需要disable。

原创文章，版权归本文作者所有，如需转载请注明出处

喜欢本文请长按下方的二维码订阅Oracle一体机用户组

oracle

最后修改时间：2019-12-27 09:32:21

文章转载自Oracle一体机用户组，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle 11G R2 RAC 在Red Hat 7.4上的NTP服务配置问题

评论

相关阅读