原文链接： 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问题可能很有帮助。
Leave a Reply