ESXiの中でテスト用のLinuxServerを構築し設定したところ、時刻あわせのntpdに関する制限？のようなものに気がついたのでメモ。
当方のESXiでは、下図のような構成でゲストOSが動作しています。
DNSサーバ(192.168.xxx.2)ではずいぶん前からntpdが起動しており、ntpq -pするとこんな感じ。
[DNSサーバ] # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== ntp1.******.ad. .GPS. 1 u 3 64 1 42.771 233.190 0.008 LOCAL(0) .LOCL. 5 l 2 64 1 0.000 0.000 0.008 ※上位のntpはGPSなので、stratumが1。自分のは5くらいになってます。
そして、テストのLinuxサーバにも以前からDNSサーバのアドレスをntp.confに記述して起動しておったわけですよ。
みてみるとこんな感じ。
[TEST Linux] # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) 73.78.73.84 5 l - 64 1 0.000 0.000 0.002 *** DNS *** .INIT. 16 u - 64 0 0.000 0.000 4000.00
stratumが16の件について。
DNSのntp.confのrestrict項の記述を間違えたかと思いましたが、そんなこともなく。
確認のため、TEST Linuxサーバのntpdを止めて、ntpdateしてチェックするとこんな感じ。
[TEST Linux] # ntpdate -d 192.168.xxx.2 20 Aug 12:18:48 ntpdate[11416]: ntpdate 4.2.0@1.1161-r Wed May 20 09:49:43 JST 2009 (1) Looking for host 192.168.xxx.2 and service ntp host found : (*** DNS ***) transmit(192.168.xxx.2) receive(192.168.xxx.2) transmit(192.168.xxx.2) receive(192.168.xxx.2) transmit(192.168.xxx.2) receive(192.168.xxx.2) transmit(192.168.xxx.2) receive(192.168.xxx.2) transmit(192.168.xxx.2) 192.168.xxx.2: Server dropped: strata too high server 192.168.xxx.2, port 123 stratum 16, precision -17, leap 11, trust 000 refid [192.168.xxx.2], delay 0.02623, dispersion 0.00003 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 15:28:16.000 originate timestamp: d0187297.adcd3e95 Fri, Aug 20 2010 12:18:47.678 transmit timestamp: d0187298.21612c6a Fri, Aug 20 2010 12:18:48.130 filter delay: 0.02646 0.02623 0.02650 0.02623 0.00000 0.00000 0.00000 0.00000 filter offset: -0.45194 -0.45204 -0.45220 -0.45206 0.000000 0.000000 0.000000 0.000000 delay 0.02623, dispersion 0.00003 offset -0.452043
やっぱりstratum 16だ。
ちなみに、ntpdのstratumは、時刻の信頼度のこと。1～15の順で分けられ、最も精度が高いものが1となる。16というのは、まだ上位のntpと同期していないということ。
・・・・そんなはずないんだけどなぁ。
ためしに、vmesxi上で動作させているntpdにあわせてみた。
[TEST Linux] # ntpdate -d vmesxi 20 Aug 12:26:53 ntpdate[11518]: ntpdate 4.2.0@1.1161-r Wed May 20 09:49:43 JST 2009 (1) Looking for host vmesxi and service ntp host found : vmesxi transmit(192.168.xxx.220) receive(192.168.xxx.220) transmit(192.168.xxx.220) receive(192.168.xxx.220) transmit(192.168.xxx.220) receive(192.168.xxx.220) transmit(192.168.xxx.220) receive(192.168.xxx.220) transmit(192.168.xxx.220) server 192.168.xxx.220, port 123 stratum 2, precision -20, leap 00, trust 000 refid [192.168.xxx.220], delay 0.02614, dispersion 0.00024 transmitted 4, in filter 4 reference time: d01873e5.0a0ba31a Fri, Aug 20 2010 12:24:21.039 originate timestamp: d018747c.50704730 Fri, Aug 20 2010 12:26:52.314 transmit timestamp: d018747e.18b790fb Fri, Aug 20 2010 12:26:54.096 filter delay: 0.03047 0.02618 0.02625 0.02614 0.00000 0.00000 0.00000 0.00000 filter offset: -1.78058 -1.78263 -1.78267 -1.78263 0.000000 0.000000 0.000000 0.000000 delay 0.02614, dispersion 0.00024 offset -1.782639 20 Aug 12:26:54 ntpdate[11518]: step time server 192.168.xxx.220 offset -1.782639 sec
・・・うまく時計あわせできた。
もしかしてESXi内で動作しているゲストOSのntpdは、ESXiが全部仕切っちゃうのでしょうか。
ちょっと様子見てみます。
＜備考＞
ESXi内で動作しているFreeBSDの時刻が、とんでもなくずれる場合の対処法。
# echo 'kern.hz=100' >> /boot/loader.conf ※loader.confに kern.hz=100を記述
これでよし。
通常実機では、FreeBSDでもLinuxでもこのタイマー割り込みレートは kern.hz=1000 ですが、ESXiなどのゲストOS内環境では割り込みを取りこぼすことがあるため、ゲストOS内のタイマーレートを下げることで解決するようです。
Linuxについては以下の通り。
[/etc/grub.conf]kernel行末尾に以下を追加 divider=10 clocksource=acpi_pm
※dividerはdiv(割る)の意味で、この場合 1000 ÷ 10 = 100Hz
Thanks to arakawaさん。