web-dev-qa-db-ja.com

NTP実行中、サーバーの時刻が間違っているVM

サーバーの時間は7時間オフでした（dateが正しいタイムゾーンを示していても、午前10時ではなく午前3時でした）。 ntpqの出力は次のとおりです。

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 xx.xxx.xxx.x.ar xxx.x.xx.xx      2 u   72 1024  177    6.516  2520657 1650156
 ntp.xxxx.ac.uk  xxx.xxx.xxx.x    2 u   7h 1024  377   14.039  2520655 1347346
 xxx.xxx.xxx.xx  xxx.xxx.xxx.x    2 u  114 1024  377    5.449  -18.941 2130343
 ns1.xxxxxxx.com xxx.x.xx.xx      2 u  148 1024  377    8.050  2520655 1650156

時間は以下によって修正されました：

ntpdate -u 0.europe.pool.ntp.org

しかし、それは数日後に再び起こりました。 ntpq -pの2行目は、最後に受信したパケットから7hであると考えています。しかし、それが理由である場合、ntpが他のサーバーを使用して時刻を同期しなかったのはなぜですか？

何が起きたの？これが再発しないようにするにはどうすればよいですか？

編集もう1つの考慮すべき点は、それがVMであることです。 VMが何らかの一時停止状態だった可能性はありますか？

vmware-toolbox-cmd timesync statusが無効になっていることに注意してください。

linuxvirtual-machinesntpntpdntpdate
6
sina

Ntpdが起動したら、ホストとリモート間の時間差をチェックしますNTPサーバー。その差が大きすぎる場合（通常10〜15分）、それはrefuse何かを変える。

ntpdateを実行すると、ntpd自体が行うことのミリ秒以内に時間をもたらす、ワンショットのより単純なSNTP実装を効果的に使用します。これで、ntpdサービスを再起動すると、サーバーが同期されているはずです（ntpq -pで確認してください）。

単純な永続的な解決策は、ブートプロセスの早い段階で最初にntpdateを使用し、しばらくしてから「実際の」ntpデーモンを起動することです。ちなみに、CentOS 6.xと7.xはまったく同じことを行います。ntpdateとntpの両方をインストールすると、前者はブートプロセスの早い段階で使用され、後者は後の段階で使用されます。

5
shodanshok

過度のジッター/オフセットが原因でntpが同期に失敗したようです。国の近くにあるntpサーバーの別のプールを試すことをお勧めします。

これらのIPはパブリックで十分に文書化されたサーバーであるため、ステータスのIPを難読化する必要はありません

VMwareでマシンを実行している場合は、次も確認してください http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf およびntpを維持物理サーバーのクロックが調整されています。

「考慮すべきもう1つのことは、それがVMであることです。VMが何らかの一時停止状態だった可能性はありますか？」

はい、VMwareツールが同期無効に設定されている場合でも、VMwareは一時停止後にクロックを再同期します

VMware Toolsの定期的な時刻同期をオンにするかどうかに関係なく、時刻同期は特定の操作の後に発生します。

  • VMware Toolsデーモンが起動したとき（再起動中や電源投入時など）
  • サスペンド操作から仮想マシンを再開するとき
  • スナップショットに戻した後
  • ディスクを圧縮した後
3
Alessandro Carini