一、 问题背景
天威视讯项目3月底发生了一次点播出现节目请求超时的情况，在查询故障的过程中，发现MAP服务器操作系统的时钟被向前调整了11秒，姑且不论是否是这个原因导致的故障，但每台服务器在安装了NTP的情况下，为什么还会一次修改达到11秒情况的时间差，是需要查清的一个事情。
此文由博主徐徐原创，转载请指明出处欢乐世界http://www.happyworld.net.cn。
二、 问题分析
1、 现象分析
天威视讯项目目前部署的NTP服务是一台MYSQL服务器作为NSP系统的服务端，其他服务器如（IPG、AAA、MAP等）就同步这台服务器的时钟，而MYSQL则同步天威自己部署的一台NTP服务器。一个简单的三层的架构。
查看了8台MAP，每台MAP都有过调整11秒时钟的记录，且每台调整的时间都不一样，查看时钟源MYSQL的系统日志，发现是由于MYSQL1的时钟源调整了11秒的时间，进而引起NSP系统内所有服务器都做了一次同步操作。
MYSQL1: Mar 31 12:08:37 MYSQL1 ntpd[20241]: time reset -11.476554 s
MAP1: Mar 31 13:06:20 MAP1 ntpd[26731]: time reset -11.476079 s
MAP2: Mar 31 12:57:42 MAP2 ntpd[25106]: time reset -11.476056 s
IPG1: Mar 31 12:51:26 IPG1 ntpd[4426]: time reset -11.476588 s
AAA1: Mar 31 13:14:33 AAA1 ntpd[8932]: time reset -11.476668 s
从上面日志可以看出，在MYSQL时间修改后，其他服务器陆续进行了时钟校正。我们这里暂不讨论天威源头NTP时钟是否有过11秒的调整，这里讨论为何架设了NTP服务之后，时间会一次校正这么大的值。
2、 原因分析
经过查询资料，NTP的时间同步有两种方式，一种是通过ntpdate进行手动调整（也可以做成定时任务）；一种是通过ntpd服务进行自动调整。目前天威部署的NTP全是以第二种ntpd服务的方式配置的。
ntpdate就是执行该命令的时候就将客户端的时钟与服务器端的时钟做下同步，不管差异多大，都是一次调整到位。
而ntpd服务的方式，又有两种策略，一种是平滑、缓慢的渐进式调整（adjusts the clock in small steps所谓的微调）；一种是步进式调整（跳跃式调整）。两种策略的区别就在于，微调方式在启动NTP服务时加了个“-x”的参数，而默认的是不加“-x”参数。
假如使用了-x选项，那么ntpd只做微调，不跳跃调整时间，但是要注意，-x参数的负作用：当时钟差大的时候，同步时间将花费很长的时间。-x也有一个阈值，就是600s，当系统时钟与标准时间差距大于600s时，ntpd会使用较大“步进值”的方式来调整时间，将时钟“步进”调整到正确时间。
假如不使用-x选项，那么ntpd在时钟差距小于128ms时，使用微调方式调整时间，当时差大于128ms时，使用“跳跃”式调整。
这两种方式都会在本地时钟与远端的NTP服务器时钟相差大于1000s时，ntpd会停止工作。在启动NTP时加了参数“-g”就可以忽略1000S的问题。
以下是man ntpd里关于加参数“-x”的描述：
-x
Normally, the time is slewed if the offset is less than the step threshold, which is 128 msby default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the -g and -q options. See the tinker command for other options. Note: The kernel time discipline is disabled with this option.
|
Offset（与服务器的时间差） |
0-128ms |
128ms-600s |
600s-1000s |
1000s以上 |
|
使用-X参数 |
微调 |
微调（速度大约是0.5ms/s，调整600秒要14天左右） |
跳跃 |
退出（加-g参数可忽略） |
|
不使用-X参数 |
微调 |
跳跃 |
跳跃 |
退出（加-g参数可忽略） |
只有对于跳跃式的校正时间，系统日志才会记录。
天威视讯项目由于是按照跳跃式配置，所以就会一次有修改11秒的情况出现。
3、 验证测试
针对这两个策略，我们做了几个测试验证：
1、 未加参数“-x”时，如何调整：
将一台测试服务器的时钟，向前修改了大约6秒钟左右
[root@AAA3 ~]# date -s 16:15:28
2012年 04月 06日 星期五 16:15:28 CST
同时在NTP服务器端和客户端执行查询时间操作，两者相差6秒。
|
NTP客户端 |
NTP服务端 |
|
[root@AAA3 ~]# date |
[root@MYSQL1 ~]# date |
然后一直查看NTP客户端服务器的时钟同步效果：
刚开始，未检测到时间异常，下一次同步要512秒一个周期。
[root@AAA3 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*CC1 172.18.245.1 3 u 132 512 377 1.206 0.806 0.278
检测到与远端服务器的时间差offset 为6289.10（单位：ms）
[root@AAA3 ~]# date -R
Fri, 06 Apr 2012 16:30:44 +0800
[root@AAA3 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
CC1 172.18.245.1 3 u 1 512 377 1.208 6289.10 4446.22
经过几次时间的同步，客户端发现与服务器端时钟的确是有差异，不是偶然一次的行为，客户端须得进行相应的调整，于是就进行了一次step的跳跃式时间校正。同步周期poll也由之前的512秒一次，变成每64秒一次（同步不等于就立即调整时间）。同步完后，与服务器的时间差offset 为0ms。
remote refid st t when poll reach delay offset jitter
==============================================================================
*CC1 172.18.245.1 3 u 513 512 377 1.208 6288.98 0.771
[root@AAA3 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
CC1 .STEP. 16 u 225 64 0 0.000 0.000 0.001
此时再同时查询服务器端和客户端的时间：
|
NTP客户端 |
NTP服务端 |
|
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
目前时间已经同步正常，查看客户端的系统日志，可以发现：
[root@AAA3 ~]# tail -f /var/log/messages
Apr 6 16:39:01 AAA3 ntpd[2576]: synchronized to 172.16.100.81, stratum 3
Apr 6 16:56:16 AAA3 ntpd[2576]: time reset +6.288863 s
Apr 6 16:59:49 AAA3 ntpd[2576]: synchronized to 172.16.100.81, stratum 3
由此可以验证，在默认情况下，未加参数“-X”的情况下，NTP在时差大于128ms的情况，是进行的step跳跃式的时间同步。
2、 加参数“-x”时，如何调整：
将一台测试服务器的时钟，向前修改了大约10秒钟左右
15：02分修改时间
[root@AAA1 ~]# date -s 15:02:16
2012年 04月 06日 星期五 15:02:16 CST
|
查询时间 |
NTP客户端 |
NTP服务端 |
offset |
|
15:18 |
[root@AAA1 ~]# date |
[root@MYSQL1 ~]# date |
10秒 |
|
[root@AAA1 ~]# ntpq -p |
|||
|
|
|
||
|
15:33 |
[root@AAA1 ~]# date |
[root@MYSQL1 ~]# date |
9秒 |
|
[root@AAA1 ~]# ntpq -p |
|||
|
|
|
||
|
15:43 |
[root@AAA1 ~]# date -R |
[root@MYSQL1 ~]# date -R |
8秒 |
|
[root@AAA1 ~]# ntpq -p |
|||
|
中间一直是微调状态 |
|||
|
18:09 |
[root@AAA1 ~]# date -R |
[root@MYSQL1 ~]# date -R |
1秒 |
|
[root@AAA1 ~]# ntpq -p |
|||
可以看出，NTP一直在同步时钟，且进行很小的微调，9895.33ms的时间差，调整到18点09分还有1241.99ms，之间用了大概3小时来同步8秒多的时间，大概每秒调整0.7ms时间。
3、 加参数“-x”时，如何调整（时间差比较偏大，但是小于600s的情况）：
我们第二步测试的是10秒时间差的情况，对于更大的时间差，这种微调策略是什么效果呢，我们再进行一个测试验证：
将一台测试服务器的时间修改偏差了70几秒（17：26修改）：
[root@AAA3 ~]# date -s 17:26:00
2012年 04月 06日 星期五 17:26:00 CST
|
查询时间 |
NTP客户端 |
NTP服务端 |
offset |
|
17:35 |
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
73秒 |
|
[root@AAA3 ~]# ntpq -p |
|||
|
|
|
||
|
第二天 |
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
16秒 |
|
[root@AAA3 ~]# ntpq -p |
|||
|
|
|
||
|
第二天 |
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
5ms |
|
[root@AAA3 ~]# ntpq -p |
|||
这次73秒的时间差，用了大概1天的时间，平均每秒调整0.5ms。
由此可以验证，对于小于600s的情况，加了参数“-x”的，不管是10秒还是70秒，500秒，都是进行着这种微调式的时钟同步策略，NTP服务将这种时间差通过分散到每一秒去逐步进行微调，让系统基本感觉不到时间上的变化。这样能保证某些对时间跳动敏感的系统里，能很好的保证业务的安全。
4、 加参数“-x”时，如何调整（时间差大于600s）：
对于大于600s时间差的情况，我们也做了测试验证：
将时钟往前调十几分钟：
|
查询时间 |
NTP客户端 |
NTP服务端 |
offset |
|
17:08 |
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
将时间改为提前13分钟 |
|
[root@AAA3 ~]# ntpq -p |
|||
|
|
|
||
|
|
[root@AAA3 ~]# ntpq -p |
772秒 |
|
|
|
|||
|
|
[root@AAA3 ~]# ntpq -p |
772秒 |
|
|
|
|||
|
|
|
|
0秒 |
|
[root@AAA3 ~]# ntpq -p |
|||
|
|
|||
|
17:17 |
[root@AAA3 ~]# date -R |
[root@MYSQL1 ~]# date -R |
0秒 |
NTP服务大概过了5分钟后，就将相差的700多秒时间差，一步到位的进行了校正。
查询系统日志：
Apr 6 17:02:53 AAA3 ntpd[24511]: synchronized to 172.16.100.81, stratum 3
Apr 6 17:15:45 AAA3 ntpd[24511]: time reset +772.789372 s
Mar 19 10:44:12 yunwei-002 ntpd[3433]: 0.0.0.0 c61c 0c clock_step +763.773061 s
三、 问题处理
对于VOD点播系统，MAP、MYSQL、ORACLE等模块都会对一些时间比较敏感（比如节目调度时的定时计划、时移时的时间差等等，数据库中可能造成某些记录的创建时间晚于修改时间等等），如果时间不是连续的，而是跳动的，必然对业务有较大的影响。建议后期对NTP策略进行调整。
[root@AAA3 ~]# cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -x -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
# Additional options for ntpdate
NTPDATE_OPTIONS=""
将/etc/sysconfig/ntpd文件中的OPTIONS里增加“-x”参数，重启ntpd服务即可。
[root@AAA3 ~]# service ntpd restart