ブロードバンドタワーで Scality RING を担当しているポールです。
今回は RING とは直接関係のない話にはなりますが、コンピュータを利用する上で切り離すことのできない、時刻同期に関するお話です。先日実施した某社ストレージ製品の更新作業時に気づいたことや、時刻同期にまつわるいくつかの経験を踏まえて、小話をまとめてみたいと思います。
なお、NTP（Network Time Protocol）にまつわる話が中心になりますが、私は NTP サーバの管理はしていませんのでその方面はあまりノウハウがありません。NTP サーバ側の話ではなく、NTP クライアントに相当するストレージ機器側の設定や動作の話になります。
その１：NTP に対応していないストレージ製品
トップバッターは、某社のストレージ製品です（Scality 社製ではありません）。このストレージはとあるエントリーレベルの SAN ストレージで、過去に何度か、私や前任者がファームウェアを更新しています。（設置場所はブロードバンドタワーのデータセンターです）
ファームウェアを更新するためには、管理端末上に導入している GUI 管理アプリケーションから接続して実施する必要がありました。私が最後に更新した際も同様に GUI 管理アプリケーションでストレージへ接続したのですが、そのとき突然、
GUI管理アプリケーションの動作する端末と、管理対象ストレージ機器との間で時刻のずれがあります。時刻同期をしますか？（Y/N）
といった内容のダイアログがでてきました。ダイアログ内の情報から20分程度のずれがあることがわかり、その場で時刻同期を行いました。
そのときふと気づきました。20分も時刻がずれているということは、このストレージは NTP サーバの設定をしていないのだろうか？と。そこで GUI管理アプリケーション上に設定箇所がないか丁寧に調べました。残念ながら設定箇所が見つからなかったため、NTP サーバの設定を一旦脇に置いて、ファームウェアの更新を行いました。更新には相応に時間がかかるため、その間にメーカーのサポート情報を調べたのですが、なんと更新後のファームウェアには NTP サーバに関する設定項目が追加されていることがわかり、更新後に NTPサーバの設定を行いました。
このことからわかるのは、どうやら更新前のファームウェアには、NTP を用いた時刻同期の設定方法がなかったようなのです。なぜ企業向けのストレージ機器が NTP に対応していなかったのだろうか？と考えました。おそらく、時刻同期は GUI管理アプリケーションで操作する度に行えば十分、という設計思想があったのでしょう。ここで重要なのは、あくまでも NTP を用いた時刻同期ができなかっただけであり、時刻同期する機能が一切なかったわけではない、ということです。
実際、多くの他のユーザ環境では定期的にGUI管理アプリケーションでストレージに接続し、ボリュームの追加や接続するホストの追加などの設定変更を行うでしょうから、時刻同期はそれで十分なのだと思います。しかし、そのストレージは長い間設定変更がなく、私が GUI管理アプリケーションで接続したのも2年ぶりでした。そのため時刻のずれが 20分程度まで広がっていたようです。誤解のないように強調しておくのですが、その時点で既に2年以上、何事もなく安定的にストレージが稼働していたことが何よりも重要ですから、NTP の未対応は些末な話なのです。そしてその時から NTP サーバとの時刻同期をしていますので、もう時刻同期に関するダイアログを見ることはないのだろうと思います。
その２：NTP同期をしていたにもかかわらず、強烈に時刻がずれる場合もある
２番バッターは、某社の企業向けエントリーレベルの NAS 製品です（やはり Scality社製ではありません）。かれこれ10年以上前のことですが、珍しく私が深夜に納品に立ち会った思い出深い案件でした。順調に運用が開始したのですが、納品後1年程度過ぎてから、お客様から次のようなお問い合わせがありました。
・利用開始してから1年しか経っていないのに、時刻が半年以上遅れている。 ・NTP サーバとの時刻同期の設定は行っている。 ・これは仕様なのか？
はい。もちろんそんな仕様があるわけがないです。しかし実際に NTP の設定は行われているにも関わらず、機器の時刻は強烈に遅れていました。
原因は２つありました。ストレージ機器のモデルと設置場所、および NTPの同期間隔です。
まず前者ですが、エントリーレベルのストレージ製品というのは、ハードディスクを大量に搭載した筐体の中にストレージコントローラを内蔵するものがほとんどです。しかも SSD が出現する前の時代には、ストレージの I/O 性能を上げるために 15,000 rpmの 3.5インチ ハードディスクを 3Uの筐体の前面に14-15本搭載させていました。一方で筐体の背面から挿しこまれたストレージコントローラ内で時計が動作するわけですが、ハードディスクから発生する熱がもろにクォーツの振動に影響してしまうようで、時計がずれやすいのです。更に不幸が重なります。設置場所のエアコンの効きが悪く機器の吸気温度が高かったので、その状況に拍車をかけていました。（いわゆるオフィス内のマシンルームのような場所で、データセンターのように空調が完備している場所ではありませんでした）
仮にそのような状況でも、頻繁に時刻同期が行われていればなんとか食い止められるものなのですが、不幸なことに時刻同期の間隔が 1時間おきで、時刻のずれが30分を越えるとそれ以降は同期を行わない、というデフォルト設定のままになっていました。おそらく１時間ごとの同期の間に時刻のずれが30分をゆうゆうと越えてしまうことがあって、時刻同期が実施されなくなり、そのことを監視でもキャッチできなかったのでしょう。
当時私からお客様にお願いしたのは、０：手動で時刻同期をして強制的に現在時刻に合わせていただく、１：時刻同期の間隔を10分程度に縮める、２：部屋のエアコンをもっと効かせてもらう（特に機器の吸気側を涼しくする）、の３点でした。その後は時刻同期の問題が再発することもありませんでした。
（その１）と（その２）は両方とも時計のずれに関する話ですが、ずれの度合はかなり違います。ストレージ機器のラインナップも違いますし、10年程度の時期の違いもあるので単純な比較はできません。唯一比較できるとすれば設置環境の外的要因でしょうか。ということで、ストレージを設置する際はオフィス内のマシンルーム等ではなく、十分に温度管理が行われているデータセンターがよいと思います （さりげなくデータセンターをプッシュしてみます）。
（補足）NTP クライアントの step/slew モードに関連して
一般に NTPクライアントの動作を説明する用語として、step/slew の、２つのモードがあります。かなりざっくりとした説明ですが、slew モードは時刻を非常にゆっくりと調整し、決して時刻を過去に戻しません。step モードは時刻を（slew モードよりも）大きな幅で調整できますが、時刻が過去に戻る場合があります。それぞれのモードにはメリットとデメリットがあり、NTP クライアントは状況に応じて２つのモードを複雑に組み合わせながら時刻調整を行うように実装されています。とはいえ実装はベンダーごとに違いますので、NTP クライアントの詳細については、各ベンダーのサポート情報をご確認ください。
その３：ストレージ機器には NTPを使っても、なかなか同期しない時計がある
このタイトルを読んで、すぐにあれのことだな？と気づいたかたは、私と同様にストレージ業界が長い人だと思います。企業向けNAS製品の場合、長期間データ保持のための WORM （Write Once Read Many）対応の機能があります。データの属性を読み取り専用に変更した後は、データの変更と削除ができなくなるのですが、この仕組みを応用して、データに対して数年～十数年の保持期限を設定し、保持期限が過ぎるまではストレージ上からデータを削除させない運用を可能にします。このような機能を実現するうえで最も重要になるのが、時刻管理の基盤となる時計機能です。特にコンプライアンス準拠が強く求められる WORM 用途の場合は、通常の時計とは異なる仕組みで動作するコンプライアンス・クロックというものをストレージ機器の内部で動作させる必要があります。
この、通常の時計とは異なる仕組み、というのがポイントで、ストレージ製品ごとに実装の方法が変わります。通常の時計はNTPによる時刻同期を用いたり、もっといえば利用者が意図的に時計を先に進めることができます。一方でコンプライアンス・クロックは通常の時計とのずれが発生しても、利用者は意図してコンプライアンス・クロックを先に進めることができません。しかも、通常の時計とのずれの補正に異様なほどの時間を要します。その理由は、コンプライアンス・クロックのずれがすぐに補正できてしまうと、時計を未来時刻に設定することでデータの保持期限を偽って短縮することが可能になり、実質的には保持期限より前にデータを削除できてしまうからです。
過去に私の知っているお客様で、このコンプライアンス・クロックを設定したストレージ機器を海外に設置する事情があり、その準備のため機器の電源を落として倉庫内に１ヶ月ほど置いていた、という事例がありました。これは全くおすすめできない運用です。電源が落ちていれば当然コンプライアンス・クロックは1秒たりとも進みません。１ヶ月後の起動時には、通常の時計はスムーズにずれが解消しますが、コンプライアンス・クロックはずれの解消に数年を要したはずです。その後の話は特に伺っていませんが、データに対して保持期限を設定して読み取り専用に変えてしまったら、そのデータはいつまでも保持期限に到達することができず、最終的には機材の耐用年数に到達し、機材の廃棄まで削除できないデータになっていた可能性があります。このように、ストレージ製品の WORM 機能を使う場合は、機材の長期間停止を行わないような運用が望ましいです。
（番外編１）23時59分60秒の存在
それはつまり、0時0分0秒のことですよね？
と思われたかたもいるかと思いますが、残念ながら違います。この世の中では、不定期に 23時59分60秒が発生しているのです。その前後には 23時59分59秒 と 0時0分0秒が別に存在しますから、そのどちらでもないのです。
・・・と、どこかミステリーがかった話のように紹介してみましたが、単純に言い換えれば、1日が1秒だけ長くなるというだけのことです。なぜ世の中にそういうものが存在するのかというと、現在利用されている UTC（協定世界時）のずれを解決するために「うるう秒」の追加がときどき行われているからです。ここから先はインターネット検索していただいたほうが詳しく調べられますのでそちらに説明を譲りますが、直近では日本標準時で 2017年1月1日午前8時59分60秒 というのが存在しました（グリニッジ標準時で 23時59分60秒 に相当します）。既に１年以上前のことなので皆さん忘れているかもしれませんが、コンピュータが NTP を利用することで誤作動をすることなく無事乗り越えられています。うるう秒の対応については、関係された開発者と機器管理者の皆様に、改めて感謝いたします。
（番外編２）コンピュータの時刻を「かなり前」に戻すときの注意点
ここまでは主に、コンピュータの時刻が遅れていて時刻を先に進める例を説明したのですが、この項では逆です。時刻を遠い過去の時点へ戻す場合です。コンピュータの時計を操作することで時刻を戻すことはもちろんいつでも可能なのですが、そのことによってコンピュータの内部には、（同じ未来に辿りつけるかは誰にもわからない）未来のデータが出現してしまうことになります。これも NTP による時刻調整がスムーズに行える程度の時刻戻しであればあまり影響はないのですが、数ヶ月を越えた時刻戻しになってしまうと、コンピュータの中で対処が難しくなってしまいます。
私の経験では、Linux が動作するコンピュータの時計を数ヶ月前に戻して再起動すると、ファイルシステムに対して fsck によるチェックが必要になります。一瞬ヒヤッとさせられるのですが、すべてのファイルシステムをチェックしてしまえば、普通に Linux が（過去時刻で）起動してきます。
Linux だけの場合この程度の手間で済みます。注意が必要なのは、Linux 上で動作するアプリケーションです。アプリケーションによっては、過去時刻に戻ったために動作がおかしくなり、その状況を補正することができず最悪の場合データを取り出せなくなる場合があります。くれぐれもご利用は計画的に。時刻戻しを試す場合は、仮想マシンでスナップショットをとってから実施する、もしくは影響が出そうなアプリケーションのデータをあらかじめコンピュータの外部に退避してから実施することをお勧めします。
（番外編３）なぜ時刻同期をしているのに、時計が１時間進んでいるのか？
この話はコンピュータの話ではないのですが、時刻同期の話なのでついでに。最近海外によく出張している某本部長に勧められて始めた英会話ビデオレッスンで、フィリピン在住の講師と会話していた時のことです。日本製の壁掛け用電波時計を入手したとのことで、うれしそうに実物をカメラ越しに見せてくれました。私も日本製の電波時計と聞いて日本人であることを誇りに思いましたが、一方で奇妙な質問を受けました。電波で時刻同期をすると、時計が1時間進んだ状態になってしまうのだそうです。これ何とかなりませんか？と。
ここまで読んで、オチがわかってしまうかたはさすがだと思います。私は電波時計のメーカーと型番を教えてもらい、インターネットで公開されている説明書を読みました（説明書は日本語で書かれていたので、仮にその講師が説明書を読んでも内容を理解できなかっただろうと思います）。
日本語で書かれた説明書にはなんと、
この電波時計は、日本標準時にのみ調整することが可能です。
と書かれていました。１時間はまさに、日本標準時とフィリピン標準時の時差ですね。。。しょうがないので私は講師に以下のように伝えました。
Please don't use the wave. Because the clock cannot adjust time in Philippine Standard Time! The time of the clock will not be greatly shifted without the wave. Because it is made in Japan.
時計メーカーの開発者は、まさかその時計が日本以外の国や地域で使用されるとは思っていなかったのかもしれませんが、私は日本人としてできる最大限のフォローをしたつもりです。
いかがでしたでしょうか。今回のブログ記事は以上になります。
次回以降は再び Scality RING 関連のブログ記事を予定していますので、ご期待ください。
本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。