ここ数日、一般的にはまったく騒ぎになっていませんが、システム関連の界隈でちょっとしたザワつきを見せているのが
「2017年元旦にうるう秒の挿入が決定」
という話題です。
今日は2017年元旦のうるう秒についてご報告します。
システムと関係ない人、ユーザに徹している人にとっては全く何ともない話なんですが、いざシステムを管理している人にとっては結構な課題です。
発端は電話でした
「うちはうるう秒は大丈夫かね？」
そんな質問を受けたのは午後の昼下がり。
うるう秒？それ去年の夏（2015年7月）の話ですよね？
「いやいや、来年の元旦だよ。影響ない？大丈夫？」
ちょっと検索してみたら…
おおーホントだ。ちょっとした話題になっていました。
■NICTの解説ページ
プレスリリース | 「うるう秒」挿入のお知らせ | NICT-情報通信研究機構
2017年1月1日の世界標準時0時0分に一秒追加される、ということですか。
時差があるので日本の標準時としては午前9時0分で一秒追加が発生、ということですね。
「前回の2015年7月は大手SNSで通信障害もあったことだし、何かあれば報告上げてね。」
そう…っすねぇ。
とりあえず
気になるのはうるう秒調整によって発生する「サーバプロセスによるCPU100%占拠」の問題ですね。これは前回の夏の障害です。
で、このCPU100%になるプロセスがMySQLやJavaが代表的なソフトウェアだったということが気になります。MySQLは結構依存しているパッケージが多いミドルウェアですからねぇ。
調べてみると、ntpdを使っているかどうかによってまず初動が変わる、という点が分かります。ntpdを利用していない場合にはtzdataでうるう秒情報を含んだ時刻カウントが実行される、ということになります。確かにtzdataは毎回アップデートをキチッとやってますぞ。アップデートされたtzdataを利用している場合には対象の日の午前9時の段階で08:59:59⇒08:59:60⇒09:00:00と時間がカウントされるそうです。
なるほど。
clockspeedを使っていると…
実は管理対象のLinuxサーバの大多数はntpdを使っていません。clockspeedというソフトウェアを利用して、自身で正確な時刻を刻むように設定しています。
つまりtzdataで59秒⇒60秒⇒00秒と一秒多くカウントをするのでclockspeedはtzdataのおかげで時刻は狂うこともなくきちんと一秒多くカウントされる、ということになります。
で、他のサーバのいくつかはclockspeedで提供されるtaiclock経由で時刻合わせをしているので相互の時刻合わせもできなくもない、とはいえそもそもclockspeedで1秒以内の誤差はあれども正確な時間を刻んでくれているので、この1秒以内の時刻のズレをキープしつつインターネット上のNTPサーバと時刻同期されていれば問題は発生しない、ってことになりますかね。
とりあえずtaiclockで他のコンピュータに提供する時刻だけはしっかりするように参照されるtaiclockが動作する時刻サーバだけは定期的に時刻同期しておきますか。
とりあえずこの辺のイントラサーバはclockspeedとtzdata頼みでいっておきます。
Ubuntu12.04LTSだと、tzdataが現行最新バージョンの「2016h-0ubuntu0.12.04」なら大丈夫なはず。
14.04LTSなら「2016h-0ubuntu0.14.04」と"2016h-0ubuntu"にOSバージョンが続く、といったところ。
DebianだとバージョンがWheezyでは「2016i-0+deb7u1」となっていて、Jessieでは「2015g-0+deb8u1」となっているので、Jessieは今後アップデートが飛んでくるのかな？と。tzdataのアップデートは適宜動作しているので12月の直前になってから改めてチェックするようにします。
問題はntpdが動作するところ
明日に続きます。
