はじめまして!
ファーストサーバのtmatsumotです。
入社したばかり&未経験のため、まだ知識は不十分ではありますが、
自分なりに学んだことを書いてみようと思います！
(間違った情報の記載があればご指摘お待ちしております。)
今回のテーマはうるう秒対策です。
みなさんご存知でしょうか？
#うるう秒とは
閏秒（うるうびょう、英: leap second）は、現行の協定世界時 (UTC) において、世界時のUT1との差を調整するために追加もしくは削除される秒である。
引用 - wikipedia
要するに我々の知らない間に世界の時刻がズレるんです。
ドユコッチャ∑(ﾟДﾟ)
現代の世界標準時になっているのは原子時計による時刻系「国際原子時（TAI）」です。
それに対し、地球の自転に基づく時刻系として「世界時（UT1）」があります。
しかし、地球の自転速度は一定でないため、TAIとUT1に誤差が生じることがあります。
その誤差が0.8秒を超える時、原子時計の時刻に1秒を挿入もしくは削除して調整されるのです。
この追加（あるいは削除）される1秒こそ「うるう秒」なのです。
#いつ発生するのか
2016/12/20現在、我々が対応すべきうるう秒はこれです。
【今回のうるう秒の調整】
平成29年（2017年）1月1日（日）午前8時59分59秒と午前9時00分00秒の間に「8時59分60秒」を挿入します。
引用 - 総務省HP
実施日はもう目の前！対策はお早めに！
ちなみにうるう秒の追加は昭和47年(1972年)7月1日に始まり、今回で27回目なんだそうです。
過去の実施日をみたところ、1月1日もしくは7月1日のどちらかで行われています。
#なにを対策するのか
もちろん日常生活においては気にしなくてもokです。
しかし、NTPサーバの管理者はそんなわけにはいきません！
過去にはSNSのmixiでうるう秒を原因とするシステム障害が約4時間にわたって発生
したこともあったそうです。
ECサイト等の受発注を行うシステムは特に注意が必要みたいですよ。
「NTPサーバは賢いからズレてたらすぐ気付くんじゃないの？」
⇨はい、そうです。
実は放置してても時刻は勝手に同期されます。
ナーンヤ(´Д` )
では何が問題なのか。
それはデフォルトでの同期の方法が「過去に戻る」といった動作をすることです。
過去に戻るという動作によってソフトウェア上の不具合が発生したりするそうです。
今回は過去に戻らずに同期するための設定を説明します。
#時刻同期の種類
NTPには時刻同期の機能が備わっておりますが、２つのモードが存在します。
-
stepモード
一気に時刻同期 -
slewモード
ゆっくりじわじわと同期
####stepモードについて
すぐに正しい時刻に修正される。
しかし、時間の逆行が発生する可能性がある。
NTPサーバのデフォルトの同期方法はstepモードということになります。
####slewモードについて
1秒間に最大0.0005秒修正される。(1日に43秒)
時刻の逆行は発生しないものの、1秒のずれも修正に2000秒かかります。
#設定方法
さて実際の設定方法を記載します。
先ほど述べたようにデフォルトのstepモードになっているNTPサーバを、
時間の逆行が起きないようにslewモードに変更します。
- 設定ファイルの変更
# vi /etc/sysconfig/ntpd
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g"
↓
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid -g"
上記のように-xオプションをつけます。
すると"一気に同期を行う"しきい値が128ミリ秒から600秒に変更されます。
つまり、時刻のずれが600秒発生しない限りは、ゆっくりじわじわと同期が行われます。
あとはntpdの再起動を行えばあっとゆう間に設定完了!slewモードで稼動します。
/etc/init.d/ntpd restart
本当にあっという間です。
#実はここから本題
非常にあっけなく設定完了となりましたが、実は今回書きたかったのはここからの話です！
(設定方法はネット上に山程記載があるので)
そこで今回実際に検証を行ってみたところ、予想外の結果が得られました。
ヒヤッとした話、聞いてください。
#検証
slewモードでの時刻同期の検証を行います。
同期の動きがわかりやすくするため、検証では時刻を20秒ずらしてみます。
計算上は40000秒後に修正が完了するはず。およそ11時間後です。
検証実施は2016/12/8 18:20。20秒の追加を行う。
2016/12/9 5:20頃に修正完了予定。
以下、ntpq -pの結果とその時刻 (offset=時刻サーバとのずれ(ミリ秒))
Wed Dec 7 18:00:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 1.254 0.098
*clockサーバB ... 0.015 0.284
+172.27.3.32 ... -0.272 0.490
Wed Dec 7 18:10:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 1.254 0.098
*clockサーバB ... 0.047 0.277
Thu Dec 8 18:20:01 JST 2016
remote ... offset jitter
====================================
clockサーバA ... -19565. 3529.58 ←20秒追加
clockサーバB ... -19566. 3529.56
Thu Dec 8 18:30:01 JST 2016
remote ... offset jitter
====================================
*clockサーバA ... -19564. 46.212
clockサーバB ... -19565. 1.391
Thu Dec 8 18:40:01 JST 2016
remote ... offset jitter
====================================
*clockサーバA ... -19302. 82.791
clockサーバB ... -19565. 0.000
...そして次の日
Fri Dec 9 05:00:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... -786.15 146.332
*clockサーバB ... -791.44 146.139
Fri Dec 9 05:10:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... -326.41 96.822
*clockサーバB ... -300.95 118.490
Fri Dec 9 05:20:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 35.268 146.815
*clockサーバB ... -36.234 97.005
おお！
確かに予定時刻の2016/12/9/ 5:20に時刻のずれがほとんどなくなっている！！
しかし！
Fri Dec 9 05:30:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 100.896 132.745
*clockサーバB ... 292.863 120.613
Fri Dec 9 05:40:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 478.216 90.390
*clockサーバB ... 476.249 92.297
は、離れていく...！
(というか、追い越してしまっている汗)
↓追い越してからのoffset値が最大になった時刻
Fri Dec 9 06:20:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 536.816 12.289
*clockサーバB ... 522.565 9.429
その後は徐々にoffsetの値は小さくなり、正確な時刻に近づきました。
Fri Dec 9 20:20:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 10.853 0.514
*clockサーバB ... 10.540 0.509
Fri Dec 9 20:30:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 10.176 0.298
*clockサーバB ... 9.552 0.201
Fri Dec 9 20:40:01 JST 2016
remote ... offset jitter
====================================
+clockサーバA ... 9.640 0.238
*clockサーバB ... 8.873 0.302
#結果
[追加時刻] 2016/12/8 18:20
[修正時刻] 2016/12/9 5:20
[安定時刻] 2016/12/9 20:20
#結論
予想外であったことは時刻同期が安定するのに時間がかかること。
予定時刻に一度ずれが解消されるが、そこからまたずれが発生する。
今回の検証では、最終的な安定までに26時間もかかったことになる。
しかし、20秒と大きくずらした場合の結果のため、
実際のうるう秒の1秒追加時はずれの幅も狭く、安定までの時間も短いと予想される。
皆さんもslewモードで時刻同期の際には、
時刻修正後に行き過ぎてしまう現象にも焦らず、安定するのを気長に待ちましょう！
※補足
stepモードで20秒ずらした場合、10分で修正されました。早い ∑(ﾟДﾟ)
それでは以上、tmatsumotの「うるう秒対策してみた」でした。
最後までお読みいただきありがとうございました！