记Exadata上的一个简单的时间同步问题

原文链接: http://www.dbaleet.org/a_simple_case_of_ntp_on_exadata

 

 

某客户反映其Exadata服务器的系统时间和NTP服务器不一致,不仅如此,Exadata集群内部的时间甚至也有较大的差异。曾经还发生过由于节点时间不一致导致节点被驱逐的情况。

以下简单的记录一下分析过程:

首先, 通过查看操作系统日志来确认各节点上一次时间同步的时间点:

[root@dm02db01 onecommand]# dcli -g all_group -l root "grep ntp /var/log/messages | grep synchronized"

发现很多节点上一次与NTP服务器进行时间同步的日期竟然还是去年。。。

再来看下ntp服务是否正常启动:

[root@dm01db01 ~]# ps -ef | grep ntp | grep -v grep
ntp    7223     1 0     2012 ?     00:00:39     ntpd -u ntp:ntp -p /var/run/ntpd.pid -x
[root@dm01db01 ~]#   /etc/init.d/ntp status
 * NTP server is running
[root@dm01db01 ~]#ntpq -pn
localhost.localdomain: timed out, nothing received
***Request timed out

ntpd服务显示正常,但是ntpq -n提示超时,无法查询到ntp服务器。 使用dcli来执行,发现所有的节点都是同样的输出结果。

接下来, 查看NTP的网络状态:

[root@dm01db01 ~]# netstat -anltup | grep ntp

udp        0      0 192.168.10.1:123            0.0.0.0:*            7226/ntpd           
udp        0      0 10.48.28.2:123              0.0.0.0:*            7226/ntpd           
udp        0      0 10.48.29.2:123              0.0.0.0:*            7226/ntpd           
udp        0      0 10.48.27.2:123              0.0.0.0:*            7226/ntpd           
udp        0      0 127.0.0.1:123               0.0.0.0:*            7226/ntpd           
udp        0      0 0.0.0.0:123                 0.0.0.0:*            7226/ntpd           
udp        0      0 fe80::221:2800:1ef:95cf:123 :::*                 7226/ntpd           
udp        0      0 fe80::221:28ff:fefb:123     :::*                 7226/ntpd           
udp        0      0 fe80::221:28ff:fefb:123     :::*                 7226/ntpd           
udp        0      0 ::1:123                     :::*                 7226/ntpd           
udp        0      0 fe80::221:28ff:fefb:123     :::*                 7226/ntpd           
udp        0      0 :::123                      :::*                 7226/ntpd

从上可知: NTP服务使用的是123端口对外进行通信,那么接下来,我们需要对这个123端口进行测试,看是否是因为端口没有打开的缘故。接下来进行简单的端口测试

查看telnet或者nc是否有安装。

[root@dm01db01 ~]# which telnet
which: no telnet in
(/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/oracle/monitor:/root/bin)
[root@dm01db02 ~]# which nc
which: no nc in
(/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/oracle/monitor:/root/bin)

telnet和netcat默认在Exadata上没有安装于是在public-yum上找到Oracle Linux 5.7对应的telnet和netcat的rpm包,进行安装: (注意: Cell节点不支持用户自行安装任何软件)

[root@dm01db01 ~]# rpm -ivh telnet-0.17-39.el5.x86_64.rpm
Preparing... ########################################### [100%]
1:telnet ########################################### [100%]

[root@dm01db01 ~]# rpm -ivh  nc-1.84-10.fc6.x86_64.rpm
Preparing... ########################################### [100%]
1:nc ########################################### [100%]

使用telnet对tcp 123端口进行测试,发现tcp 123端口没有打开;

[root@dm01db01 ~]# telnet 10.48.28.62 123
Trying 10.48.28.62...
telnet: connect to address 10.48.28.62: Connection refused

OK, never mind, 因为telnet只能对tcp端口进行测试,上文可以看到ntp服务默认使用的端口为udp 123,需要进一步使用netcat对udp 123端口进行测试:

[root@dm01db01 ~]# nc -zu 10.48.28.62 123

这条命令一直处于挂起状态,可见udp 123端口根本就没有打开,-_-!!! ,找到客户的网络管理员,要求打开这个这个端口。

一段时间后,得到客户网络管理员通知已经关闭了操作系统防火墙,这时使用netcat的测试结果如下:

[root@dm01db01 ~]# nc -zu 10.48.28.62 123
Connection to 10.48.28.62 123 port [udp/ntp] succeeded!

重启了一遍ntp服务,结果有些出人意料,时间还是没有同步。。。

看来还不仅仅是端口没有打开,难道问题出在配置文件不正确?

于是我登上系统检查了一下ntp.conf配置文件:

[root@dm01db01 onecommand]# cat /etc/ntp.conf | grep -v '#' | tr -s '\n'

restrict default mask 0.0.0.0 noquery nomodify notrap
restrict 172.20.200.143 mask 255.255.255.255 nomodify notrap noquery
server 172.20.200.143 prefer

看上去并没有多大问题, 但是我也不记得这是否是标准配置,好在还有之前安装的Exadata我有保留过某客户的NTP配置文件,

[steven@Debian backup]% cat ntp.conf.bak | grep -v '#' | tr -s '\n' 

restrict default ignore
restrict -6 default ignore
restrict 127.0.0.1
restrict -6 ::1
fudge   127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys
restrict default mask 0.0.0.0 noquery nomodify notrap
restrict 169..200.143 mask 255.255.255.255 nomodify notrap noquery
server 172.20.200.143 prefer

看来还是有一些差异,不过这个差异令人很费解,因为Exadata的安装都是标准化流程进行的,不大可能有人人为的去修改过ntp的配置。Anyway,将以下内容添加到配置文件,然后重启ntp服务。

restrict default ignore
restrict -6 default ignore
restrict 127.0.0.1
restrict -6 ::1
fudge   127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys

重启完成,发现所有节点的时间都是一致的了。

[root@dm01db01 onecommand]# dcli -g all_group -l root 'date' 

dm01db01: Thu Apr 18 16:48:30 CST 2013
dm01db02: Thu Apr 18 16:48:30 CST 2013
dm01db03: Thu Apr 18 16:48:30 CST 2013
dm01db04: Thu Apr 18 16:48:30 CST 2013
dm01db05: Thu Apr 18 16:48:30 CST 2013
dm01db06: Thu Apr 18 16:48:30 CST 2013
dm01db07: Thu Apr 18 16:48:30 CST 2013
dm01db08: Thu Apr 18 16:48:30 CST 2013
dm01cel01: Thu Apr 18 16:48:30 CST 2013
dm01cel02: Thu Apr 18 16:48:30 CST 2013
dm01cel03: Thu Apr 18 16:48:30 CST 2013
dm01cel04: Thu Apr 18 16:48:30 CST 2013
dm01cel05: Thu Apr 18 16:48:30 CST 2013
dm01cel06: Thu Apr 18 16:48:30 CST 2013
dm01cel07: Thu Apr 18 16:48:30 CST 2013
dm01cel08: Thu Apr 18 16:48:30 CST 2013
dm01cel09: Thu Apr 18 16:48:30 CST 2013
dm01cel10: Thu Apr 18 16:48:30 CST 2013
dm01cel11: Thu Apr 18 16:48:30 CST 2013
dm01cel12: Thu Apr 18 16:48:30 CST 2013
dm01cel13: Thu Apr 18 16:48:30 CST 2013
dm01cel14: Thu Apr 18 16:48:30 CST 2013

然后使用ntpq -pn确认所有节点与NTP server的offset都非常小。

总结一下:

1. 用户修改过NTP服务器,新时间服务器的端口没有打开,可以通过一些工具进行测试;
2. ntpd默认使用差分的模式进行时间同步, 如果客户端与服务端的时间相差太大,则无法进行时间同步;
3. 如果使用ntpd无法进行时间同步,那么需要使用ntpdate来手工进行同步,因为修改的时间跨度较大,并且有可能产生时间回调(backward),使用ntpdate调整时间这个过程可能导致RAC的实例被驱逐;
4. ntp的配置文件与标准的配置文件不一致的原因已经不可考证了,问题应该主要是在于注释了restrict 127.0.0.1从而关闭本地回路的访问。在Exadata下,这一行是必不可少的;
5. 一般来说NTP的问题都比较简单,稍微复杂一点的问题可以使用使用ntptrace/ntpstat/ntpq等系统自带的工具进行诊断;
6. NTP的官方文档(https://support.ntp.org/bin/view/Support/ConfiguringNTP)对于诊断和配置NTP问题可能很有帮助。

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号