NTP dispersiyonu nedir ve nasıl kontrol edebilirim?

Ubuntu 14.04 sunucularını, ntpd 4.2.6p5 çalıştıran ve müşteriler tarafından sağlanan birden fazla NTP sunucusunu kullanacak şekilde yapılandırılmış (pool.ntp.org sitesine erişilemez) yapılandırılmış yalıtılmış ağlarda yayınlıyoruz. Aptal terminal istemci cihazlarımız, BusyBox'ın (1.00-rc2) eski bir sürümünü ve Larry Doolittle'dan ntpclient 2010'u çalıştırıyor .

Bu kurulum yıllardır harika bir şekilde çalıştı, ancak son zamanlarda yeni bir müşteriyle barikat kurduk. ntpdate-debianLinux sunucusuyla ilgili olarak bize kendi başlarına harika görünen 5 kurum içi NTP sunucusu adresi sağladılar . Ancak BusyBox tarafında ntpclient"Dispersiyon çok yüksek" ifadesinden şikayetçi. Hata ayıklama çıktısından ntpclientNTP sunucusundan "1217163.1" alıyor, ancak desteklediği maksimum değer mutlak (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Bunların hepsi aynı LAN üzerindeki cihazlardır, bu yüzden açıkçası şaşırdım. Hatta donuyorum.

İşte ntpq -pnUbuntu 14.04 sunucusundan çıktı:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Benim sorularım:

1. Dağılım nedir ve değeri ne değiştirebilir?
2. NTP sunucularından daha fazla ayrıntı almak için hangi komutları çalıştırabilirim?
3. Hata Ubuntu sunucusu tarafında, yanlış bir şekilde olabilir ntp.confmi? Orada gerçekten özel bir şey yok.
4. Chrony'ye geçmek bu durumda herhangi bir şeyi değiştirir mi?

Buradaki cevaplarda bazı karışıklıklar olduğunu görüyorum. Başlangıç ​​olarak ntpclient, en azından -smodunda, tam bir NTP istemcisi gibi davranmıyor, yalnızca bir paket gönderiyor ve alıyor , bu nedenle "son 8 paket alınmadı". Aslında hiç kendi dağılımını tahmin etmiyor.

Bunun yerine, yazdırdığı değer, sunucu tarafından döndürülen paketteki "root dispersion" (rootdisp) adı verilen değerdir; bu, sunucu ile doğru zaman arasındaki toplam hata / varyans miktarının bir tahminidir. Bunun hesaplanma şekli oldukça basittir: her NTP sunucusu zamanını harici bir saatten (örneğin bir radyo veya GPS alıcısı) veya başka bir NTP sunucusundan alır. Bir sunucu zamanını harici bir saatten alırsa, kök dağılımı o saatin tahmini maksimum hatasıdır. Vaktini başka bir NTP sunucusundan alıyorsa, kök dağılımı o sunucunun kök dağılımı artı aralarındaki ağ bağlantısı tarafından eklenen dağılımdır.

Buradaki karışıklık noktalarından biri, ntpq ve chrony'nin saniyeler içinde dağılma ve kök dağılımını gösterdiği, ki bu da insanların aradığı şeydir, ntpclient bunu mikrosaniye cinsinden gösterir . Yine de, 1217163'ün değeri hala oldukça yüksek. İyi bir NTP sunucusu, zamanı birkaç milisaniye içinde bilir; birkaç on veya yüzlerce milisaniye içinde kötü bir tane. Sizinki size zamanının sadece +/- 1,2 saniye içinde güvenilebileceğini söylüyor.

NTP akıl sağlığı kontrollerini devre dışı bırakan -x 0ya da -t(ntpclient sürümüne bağlı olarak) seçeneğini seçerek bu sunucuya senkronize etmek için aslında ntpclient'i alabilirsiniz . Kabaca sadece doğru zamana ihtiyacınız varsa (birkaç saniye içinde), bu yeterli olabilir. Ancak, ntpclient, böyle kötü bir sunucuya senkronize etmeyi reddetmede oldukça makul. Kişisel ntpqubuntu makinede çıktı bunlar ya çok güvenilmez bir ağ, bir komplo gösterir düşük gecikme, olsa bile, tüm sunucularını için milisaniye yüzlerce titremeleri gösteren tüm düzensiz zaman sağlamak için sunucuların veya temeli Sunucunun kendisinde zaman tutma sorunu var.

Ayrıca, sunucunun 10.31.10.22 sunucusunun bir geri ödemenin LOCL(disiplinsiz yerel saatin) reklamını yapması, ancak 1 katmanına sahip olması beni endişelendiriyor . Genellikle yerel saat, 10'luk bir katmana geçiyor, böylece yalnızca son çare senkronizasyon kaynağı olarak kullanılıyor bir sürünün sürüklenmesini engellemek için. Ya 10.31.10.22 yanlış yapılandırılmış ve ağın geri kalanına kötü zaman veriyor ya da NTP'nin kontrolü dışındaki bazı programlar tarafından iyi zamanlar geçirilmiş, bu durumda yanlış yapılandırma sadece LOCLiadenin reklamını yapıyor ; örneğin GPSveya zamanını neyin sağladığına göre geçersiz kılınmalıdır .

"Dağılım nedir?" İçin kısmi bir cevap:

Tipik bir NTP gidiş dönüşü:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Bu, iki formül verir: ofset (istemci ve sunucu arasındaki zaman farkı) ve gecikme (ağın seyahat süresi için gerekli) aşağıdaki formüllerle:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Müşteri, en küçük gecikmeli olanı seçerek, alınan son 8 paketten mevcut ofseti seçer.

Aynı 8 paket, bu 8 ofsetin son adımda seçilene olan farkının ağırlıklı bir ortalamasını yaparak, gecikmenin ağırlık faktörü olarak kullanıldığı, daha küçük gecikmelere daha fazla ağırlık veren dağılımın hesaplanması için kullanılır. Bu, değerlerin "yayılması" için bir ölçüdür ve bir zaman sunucusunun kalitesini hesaplamak için kullanılır, özellikle seçim için birden fazla seçeneğiniz varsa.

Dağılımınız ve çarpıklığınız muazzam, yerel saatten bu akrana kadar çok büyük bir sapma var. Ofsetleri yerel ile karşılaştırmalı dateve saati elle ayarlamalısınız.

Ntpd'yi çalıştırın ve ntpq -ptüm eşleri kullanarak bir ana bilgisayardan gösterin . Daha iyisini seçecektir.

Göre bu Cisco belgelerinde , " dağılma saniyede rapor, bugüne kadar yerel saat ve sunucu saati arasındaki gözlendi maksimum saat zaman farkıdır". Tamamen kırılmayan ntp sunucuları ile, yüksek bir dağılım asla gerçekleşmemelidir. Uygulanabilir tek senaryo, müşterinizin ntp'yi başlattığı ve şimdiye kadar yalnızca yerel saatinin mevcut olduğu durumdur. Ve o zaman bile, rapor ettiğiniz kadar yüksek bir dağılım iki haftadan daha fazla süren saatlere karşılık gelir .

Yerel saatin başlangıçta çok uzakta olmamasını sağlamak (hatta birkaç saat bile kabul edilebilir), ya BIOS'ta saat ayarlayarak (ve tarihi bile!) Ya da ntpdatebaşlamadan önce bir kez yayınlayarak yeterli olmalıdır. ntpdmüşteriye.