一、 問題背景
天威視訊項目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