Soru İzolatör ağında tek NTP sunucusu


Yalıtılmış bir ağda iki adet linux makinem var (A ve B). Zaman senkronize edilmiş olmalılar. Makine A aralıklı olarak çalışır ve yetkili bir zaman kaynağına (GPS) bağlı olduğundan, zamana hizmet etmelidir. Makine B, yalnızca makine A güçlüyse çalışır, ancak gömülü bir linux aygıtıdır ve güç durumu sık sık değişecektir. Hiçbir makinenin diğer sistemlere erişimi yoktur. Kapalı bir ağ.

NTP'nin genellikle birkaç sunucuyla iletişim kurmasını beklediğinden, bunun NTP için oldukça uzun bir sıralama olduğunu anlıyorum. Makine B'de düzgün bir şekilde çalışmasını sağlamakta güçlük çekiyorum. Makine GPS’e çok iyi bir şekilde senkronize ediyor ve makine B makine A'ya ulaşabiliyor ve hatta zaman sorguları yapabiliyor, fakat A Makinesi güvenilir değil (belki de kendi başına mı?). A makinesinin katı bir saatinden sonra, bu aniden değişti ve makine B çalıştı. Ancak, makine A düştüğünde (ve böylece makine B), makine B bir kez daha iyi bir zaman senkronizasyonu bulamamaktadır.

İşte bazı ntpdate bilgileri. Makine A tabakası 1 olduğunda bile, işlemin sonunda aynı çıktıda başarısız olduğunu unutmayın.

10.10.10.1: Sunucu düştü: çok yüksek
sunucu 10.10.10.1, bağlantı noktası 123
Stratum 16, kesinlik -19, sıçrama 11, güven 000
refid [10.10.10.1], 0,02614 gecikme, dağılım 0.00000
4 iletilen filtre 4
referans zamanı: 00000000.00000000 Per, Şub 7 2036 6: 28: 16.000
menşe zaman damgası: d3a9bdc4.27ebb350 Per, 12 Temmuz 2012 21: 19: 00.155
iletim zaman damgası: bc17c803.b42dfffe Cts, Ocak 1 2000 0: 25: 39.703
filtre gecikmesi: 0,02625 0,02614 0,02618 0,02625
         0.00000 0.00000 0.00000 0.00000
filtre ofset: 39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
0,02614 gecikme, dağılım 0.00000
ofset 395441600.451568

 1 Oca 00:25:39 ntpdate [677]: senkronizasyon için uygun sunucu bulunamadı

Benim tahminimce, makine A sadece hizmet etmek için kendini güvenmiyor. 51 dakika sonra (daha önce başıma gelebilir, bilmiyorum) ve saatinin GPS'e senkronize olması, makine A'nın doğru zamanda hizmet vermeye başlaması ve B makinesinin onu alması. Daha önce olması için buna ihtiyacım var. Mümkünse, saniyeler içinde.

Aşağıdaki yapılandırmalarla (ve çok fazla bekletme), sonunda başarılı olur.

Makine A ntp.conf:

Sunucu 127.127.28.0 tercih et gerçek minpoll 4 maxpoll 4
fudge 127.127.28.0 stratum 1 zaman1 0.420 refid GPS 

Makine B ntp.conf:

sunucu 10.10.10.1 gerçek minpoll 4 maxpoll 4 tercih

ntpq -c makine B'de iyi bir zaman düzeltmesi olmadan çalışır:

     Anketi durdurma gecikme ofset jitter zaman uzaktan refid st t
================================================== ============================
 10.10.10.1. 16 u 9 16 0 0,000 0,000 0,000

ntp1 -c, makine B'de iyi bir zaman düzeltmesiyle:

     Anketi durdurma gecikme ofset jitter zaman uzaktan refid st t
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0.669 2.597 1.808

Şimdi, soru şu oluyor: Nasıl Makine A'nın kendine hızlı bir şekilde güvenirim?

Makine A'dan önce ve sonra makine A'dan bazı hata ayıklama çıktısı, Makine A'nın kullanmak için yeterince iyi olduğuna karar verir.

önce..

~ # ntpq -c rv
associd = 0 durum = c418 leap_alarm, sync_uhf_radio, 1 etkinlik, no_sys_peer,
version = "ntpd 4.2.6p4@1.2324 Cum Şub 24 15:01:45 UTC 2012 (1)",
işlemci = "armv7l", sistem = "Linux / 2.6.35.14", sıçrama = 11, katman = 2,
precision = -19, rootdelay = 0.000, rootdisp = 44.537, refid = SHM (0),
reftime = d3ab0053.43b44780 Cum, 13 Temmuz 2012 20: 15: 15.264,
clock = d3ab0062.e7e03154 Cum, 13 Temmuz 2012 20: 15: 30.905, eş = 34819, tc = 4,
mintc = 3, ofset = 0.000, frekans = 0.000, sys_jitter = 3.853,
clk_jitter = 36.492, clk_wander = 0.000

sonra...

~ # ntpq -c rv
associd = 0 durum = 0415 leap_none, sync_uhf_radio, 1 etkinlik, clock_sync,
version = "ntpd 4.2.6p4@1.2324 Cum Şub 24 15:01:45 UTC 2012 (1)",
işlemci = "armv7l", sistem = "Linux / 2.6.35.14", sıçrama = 00, katman = 2,
precision = -19, rootdelay = 0.000, rootdisp = 41.278, refid = SHM (0),
reftime = d3ab0063.43b37856 Cum, 13 Temmuz 2012 20: 15: 31.264,
clock = d3ab006d.9ee53ec2 Cum, 13 Temmuz 2012 20: 15: 41.620, eş = 34819, tc = 4,
mintc = 3, sapma = 0.000, frekans = 43.896, sys_jitter = 0.762,
clk_jitter = 36.953, clk_wander = 0.000

7
2017-07-12 21:20


Menşei


Görebilir miyiz ntp.conf dosyaları ve çıktı ntpq -p makine B A makinesinden iyi zaman almıyorsa? Makine A'yı sahte bir numara veya bir şey olarak işaretleyebilir. Makine B makine A'ya güvenmediğinde, makine A GPS ile senkronize edilir mi? (Çıktısı ntpstat makinede A.) - Aaron Copley
onu duydum chronyd Bu uygulama için daha uygundur. "Bilgisayarınız günde bir kez 5 dakika boyunca ağa bağlanıyorsa (veya bunun gibi bir şey) veya (Linux v2.0) bilgisayarınızı kullanmadığınızda kapatırsanız veya NTP'yi bir görünürde hiçbir donanım saati olmadan ağ, chrony sizin için çok daha iyi çalışacaktır. " - David Schwartz
@AaronCopley Birkaç (10 veya 12) saat içinde yayınlayabilirim. Makine A, önyükleme işleminin bir dakikası içinde GPS'e senkronize olur. Makine B'nin, makine A'ya oldukça uzun bir süre boyunca senkronizasyon sorunları vardır. - San Jacinto
@DavidSchwartz Teşekkürler. Ona bakacağım, ama eğer yardımcı olabilirsem konfigürasyonların ötesine geçmek konusunda biraz isteksizim. Şu anda B Makinesi için herhangi bir şeyi çapraz inşa etmek bir hatıra. - San Jacinto
@ AaronCopley Güncelleme. - San Jacinto


Cevaplar:


NTP iyi çalışmalı. Başlangıçta hızlı senkronizasyon için bazı seçeneklere bakın. Bak burst ve iburst Sistem B için seçenekler true GPS saat kaynağı için seçenek.

Her iki sistemde donanım saatini yedek zaman kaynağı olarak kullanmayı düşünün. Daha yüksek bir katman sistemi B ayarlayın. Aşağıdaki gibi bir şey çalışmalıdır:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Çıkışını izle ntpq -c peers güvenilir bir saat kaynağı aldığınızda görmek için. Normalde ntp Güvenilir bir zaman kaynağından güvenmeden önce bir dizi yanıt ister. Bu, her satırdaki ilk karakterle gösterilir.

NTP daha fazla kaynaktan hoşlanırken, bir katman seviyesindeki tek sayıdaki zaman kaynağı iyi çalışmalıdır. Sadece iki sunucunuz ve bir GPS saatiniz olduğundan, kaynakların önceliği (stratum) GPS'den, sunucu A'daki saat, sunucu B'deki saatten artacaktır. Tabakaları üç veya dört seviyeye çıkarmak, önceliklere uyulmasını sağlayacaktır.

DÜZENLEME: A sunucusunda busybox NTP sunucunuz varsa, tam ntp sunucu paketini yüklemeye değer olabilir. Sunucu ile neler olup bittiğini anlamak probleminizi çözmenin uzun bir yolunu bulmalıdır. Sunucu B'ye güvenmeden önce en az bir güvenilir zaman kaynağına ihtiyacınız olacaktır. Eğer ntpq -c peers çalışmıyor, sonra deneyebilirsiniz ntpdc peers. Her iki komut da diğer ana bilgisayarları sorgulamanıza olanak tanır. bir peerstats log da yararlı olabilir.

B sunucusunda ntpclient belgeli olarak kullanılır. busybox ntp howto ne olup bittiğini günlüğe kaydetmek

Sunucular uzun süre beklemediyse saatler doğru zamana yakın olmalıdır. İki sistemi senkronize etmeniz gerekiyorsa, bu yeterli olmalıdır. GPS, zamanı en sonunda gerçek dünyayla senkronize edecek.

'ntpd -q' hızlıca eşitler, ancak çıkar (ntpdate davranışı). Takip edilmesi gereken bir ntpd sürekli senkronizasyona sahip çıkma seçeneği olmadan komut.

EDIT2: Sunucumu kontrol ediyorum ve sunuculardan birinin bir saniyeliğine kapandığını gördüm. Bunu tamir ederken ayarları ile oynadı. iburst Çok hızlı bir şekilde güvenilir bir sunucu alır. true Birden fazla güvenilir kaynak olmasaydı saat sürücüsünün güvende olmasını sağladı. Yerel olarak güvendikten ve uzaktan güvenilmeden önce saat bir dakikadan biraz fazla zaman aldı.

Test ederken, yeniden başlatabilmeniz gerekir. ntpd Senkronize edildikten ve ayarların ne kadar hızlı çalıştığını test edin. Yukarıdaki durumda, ne kadar hızlı senkronize olduğunu test etmek için Sunucu B'nin yeniden başlatılması gerekebilir. İzleme yaparken ntpd değişiklikler gibi bir çizgi kullanın:

while ntpq -c peers localhost; do sleep 10; done

Ana bilgisayar adı ve uyku zamanı gerektiğinde ayarlanır. Bazı durumlarda iki veya daha fazla zinciri ntpq döngüdeki komut satırları. Bunu yaparken, veri kümelerinin nerede değiştiğine dair bir gösterge sağlamak için bir eko ve / veya tarih komutu kullanıyorum.


8
2017-07-13 00:57



Conf dosyasına eklenmesi durumu iyileştirmedi. Bu makinelerin her biri bir busybox makinesidir ve "-c" seçeneği ntpq olarak bilinmemektedir. Ayrıca, saatler, GPS ile senkronize edilene kadar bu cihazlara güvenemez. Sadece sistemlerin bir sınırlaması. Teşekkürler. - San Jacinto
Ben aslında bir küçük hata yaptım, zaten Machine A'da çalışan ntpd'nin tam sürümüne sahiptim. Machine B, BusyBox versiyonunu çalıştıran tek kişidir (ve eğer bunun için bir program yapmam gerekiyorsa, ben de aynı şeyi yapardım. ). Sonunda, her şey çalışıyor. Bence ciddi bir güven problemi. Düzenlemelere biraz bilgi verebilir misiniz? Teşekkürler. - San Jacinto
Ayrıca, cevabınızı tekrar düzenleme şansınız olursa, sisteminiz beni bilgilendirir mi? Teşekkürler. - San Jacinto
@SanJacinto Sistemimden sonuçları ile ikinci bir düzenleme ekledim. Ben meşgul kutusu ntpd istemcisi yok, bu yüzden sonuçları için kefil olamaz. İkisini de eklemeye çalışırdım true ve iburstB sunucusuna - BillThor
Çabadan benim için +1, ama sorunumu çözmüyor. Bulduğum bir çözüm (ve isterseniz başka bir şey önermek ve deneyeceğim) GPS'e senkronize ettikten sonra makine A'daki ntpd'yi öldürmek ve sonra yeniden başlatmak. Bu, makine B'nin saniyeler içinde A makinesine senkronize olmasını sağlar. Tahminimce, A Makinesi'nde (her zaman Epoch'tan önyükleme yapıyor) 42 yıllık bir sıçrama, zamanını paylaşma konusunda gergin oluyor, ama başladığında ve saat zaten ayarlanmışsa, sanki saat uzak değildi sanki Bununla birlikte, küçük ayarlamalar, zamanını paylaşma konusunda kendini iyi hissettiriyor. Ntp'ye izin verdim .. - San Jacinto