北国のインフラエンジニアのkirksenchoです、初めましてこんばんは。

とうとう今月末に迫ってきたうるう秒挿入ですが、そろそろ対策しないとなりませんね。

3年前のうるう秒挿入時は、Linuxカーネルのバグが原因で、あちらこちらで問題が出ていたようです。

さくらクラウドさんでは、こんな情報が出されていましたが、番犬タイマーでカーネルパニックされたらインフラエンジニアもパニくりますね。
http://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=655

要はカーネルをバグフィックスされたバージョンにアップデートしておけば問題は出ないはずですが（デグレや新たなバグ作り込みが無い前提）、既に該当するカーネルバージョンのサーバが数百台も数千台もあって、カーネルアップデートの影響が大きすぎて無理！というケースも大規模クラウド全体を管理していたら、ありがちです。

そこで回避策として色々考えられますが、要はバグ持ちカーネルさんにLeap通知さえしなければ大丈夫というポイントを利用します。

大規模クラウドであれば、ntpdサーバも内部で立てていると思いますが、その上にバグの無いカーネルバージョンでもう一個ntpdサーバを立てて（以降、代理ntpdサーバと記載）、その代理ntpdサーバは下位ntpdサーバにleap通知をしないようにすればいいのです。

ただntpdだけを使用していると、それは難しいので、CentOS7から標準採用されているchronyを組み合わせます。
クラウド内の代理ntpdサーバ自体の時刻同期はchronyを使用して、NICTやPOOLやMFEED等に同期します。
この時にくれぐれも一時期話題となった福岡大学には同期しないようにする事を薦めます。

福岡大のNTPサーバがアクセス集中で悲鳴
http://www.itmedia.co.jp/news/articles/0501/21/news059.html
http://www.asyura2.com/0411/it07/msg/283.html

福岡大学NTPサーバの混雑解消にご協力を
http://srad.jp/story/05/01/21/0214236/

特にchronyは福岡大学のclock.nc.fukuoka-u.ac.jpやdrake.nc.fukuoka-u.ac.jpとは同期してくれませんでした。
clock.tl.fukuoka-u.ac.jpとは同期しましたが、無理に福岡大学のNTPDに同期する必要も無いでしょう。

話が逸れましたが、chronyにはport 0設定をconfに書きます。すると上位とは同期しますが、下位には時刻同期を提供しません。
そしてchronyは上位と同期するときは毎回空いてるポートを探して使ってくれるので、ntpdみたいにポート123を専有することもないです。
なので同時にntpdをポート123を使用して起動する事ができます。

ntpdはスタンドアロンモードで動作させますが、自分の時刻はchronyがちゃんと合わせてくれているので心配ありません。
ntpdのスタンドアロンモードは、２つくらいあります。

以下を設定すると、LOCALクロック参照固定モードになります。
server 127.127.1.0

LOCALクロック参照だとループ参照になって不安定になるという情報もありますが、その対策としてはOrphan Modeがあります。
fudge 127.127.1.0 stratum 4
tos orphan 3
設定には上記を書いて、serverの記載は全て消します。
するとntpdは、Orphan Modeで動き始めるので、下位のサーバから同期先としても機能するようになります。

この状態にすると、うるう秒通知をchronyは受け取ってカーネルに通知し、自分自身の時刻はうるう秒対応した状態で合わせますが、下位に時刻同期を提供しているntpdはうるう秒の事を全く知らずに普通にローカルクロックを参照して下位サーバに時刻を提供します。

うるう秒挿入が過ぎると、下位のNTPDサーバは1秒進んだ状態となりますが、ポーリングのタイミングが来た時点でズレに気づいてslewモードで合わせようと頑張り始めます。
でも1秒もずれていると、slewではなかなか追い付きませんので、ntpdの仕様として一定時間が過ぎると、stepモードに切り替わって、ガバっと時刻が合います。

その後、下位のNTPDサーバに同期していた子供サーバ達も、わらわらとズレに気づいてslew＋stepで時刻合わせを始めます。
末端にズレ修正が行き渡るまでは1時間ちょっとといったところでしょうか。

もちろん、この時間のズレと修正のされかたを、サーバ上で動いているシステムが許容できる必要があります。
ミリ秒単位で管理していて、一気に1ミリ秒でも時間が戻ったら破綻するようなシビアなシステムの場合は、-xを付けてslewモード完全固定にして、1秒あたり 0.5ミリ秒しか時間修正されない状況でじっくり時間をかけて1秒を巻き戻す必要があるでしょう。
その場合も下位のntpdサーバだけ、そのモードにしておけば、末端の子供サーバ達の設定はそのままで済みます。

以上、今月末に迫った、うるう秒対応について、まとめてみました。
何事もなく2015年7月1日午前9時0分(JST)が来ることを願ってやみません。