Yerel bir katman 2 NTP sunucusu kurma


9

Hiçbir internet bağlantısı olan (ve asla olmayacak) yerel bir ağda NTP kurmaya çalışıyorum. Ana öncelik, senkronize edildikleri zaman% 100 doğru olmasa bile ağdaki makinelerin birbirleriyle senkronize edilmesidir.

Ayrıca, dağıtılmış bir sistemin kurulumunu çoğaltmak için bir NTP hiyerarşisi kullanma gereksinimimiz vardır. Ne yapmak istiyorum böyle bir makine hiyerarşisi var:

Moon  (Main Server running Windows) (10.1.3.10)
|____Earth   (Linux x64 client) (10.1.3.1)
|____Mars    (Linux x64 client) (10.1.3.2)
|____Saturn  (Linux x64 client) (10.1.3.3)
|____RackCard23   (Linux x64 client and server to the two machines below)  (10.1.3.23)
     |___RackCard21   (Linux x64 client) (10.1.4.21)
     |___RackCard22   (Linux x64 client) (10.1.4.22)

RackCard'larda biri 10.1.3.x ağına, diğeri 10.1.4.x ağına bağlı iki ethernet bağlantı noktası bulunduğunu unutmayın. Ana sunucuyu senkronize eden RackCard23, Moon 10.1.3.x ağında bunu yapar ve RackCard22 / 23 10.1.4.x ağındaki RackCard23'e bağlanır. Bunun nedeni, RackCards22 / 23'ün ağlarını zaman senkronize etmesini istememem ve son dağıtılmış bir sistemi çoğaltmasıdır.

Şimdiye kadar doğru şekilde senkronize etmek için Moon'u senkronize ederek (RackCard23 dahil) gereken her şeyi almayı başardım.

Ancak RackCard23 ve 23'ü RackCard23'ü senkronize etmekte zorlanıyorum.

[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge   127.127.1.0 stratum 2   #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge   127.127.0.1 stratum 2

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery

#Attempt to get to act as an NTP Server
broadcast 10.1.4.255

restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap

Bu ntptrace'in çıktısıdır:

[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030

Gördüğünüz gibi, "stratum 1" sunucusuna (Moon) senkronize edilmiş olmasına rağmen, makine kendisini bir stratum 16 sunucusu olarak rapor ediyor:

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time:    cfc99402.e010624d  Mon, Jun 21 2010  8:32:18.875
originate timestamp: cfc9dfad.48000000  Mon, Jun 21 2010 13:55:09.281
transmit timestamp:  cfc9dfad.47e27179  Mon, Jun 21 2010 13:55:09.280
filter delay:  0.04155  0.04155  0.04137  0.04135
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
         0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394

21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec

İstemcilerin yapılandırması (RackCard21 / 22) şöyle görünür:

[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer

server 127.127.1.0
fudge   127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# restrict 127.0.0.1

restrict None mask 255.255.255.255 nomodify notrap noquery

Ve ntptrace bunu verir:

[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: cfc9dfef.12b79516  Mon, Jun 21 2010 13:56:15.073
transmit timestamp:  cfc9e1e2.aeae7d56  Mon, Jun 21 2010 14:04:34.682
filter delay:  0.02573  0.02571  0.02568  0.02568
         0.00000  0.00000  0.00000  0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
         0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286

21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found

Bu yüzden uygun bir sunucu bulamıyorum çünkü kullanmaya çalıştığım sunucu bir katman 16 sunucu olduğunu bildiriyor (ki bu senkronize olmayan anlamına gelir). Bu senkronize olmasına rağmen.

Bu yüzden bir şekilde RackCard23'ü daha yüksek bir tabaka haline getirmem gerekiyor (İdeal olarak tabaka 2). Bunu nasıl yapabilirim?

Herhangi bir yardım çok takdir ben günlerce çalışmak için bu çalışıyorum olmuştur!

DÜZENLE:

Merhaba Christopher,

Ben ntpd yeniden başlatıldı, evet;)

Tüm linux kutuları CentOS 5.4 çalıştırıyor.

Bu, önerdiğiniz komutların çıktısıdır. İlk olarak sunucudan:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  34566 127.0.0.1              1 7 2      0      0       0
10.1.4.21                123 10.1.4.23              5 3 4    180      5       1
10.1.4.22                123 10.1.4.23              7 3 4      0      2       2

Ve sonra müşteriden:

[root@RackCard21]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.4.23       .INIT.          16 u   10   16    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   44   64    1    0.000    0.000   0.001

İnternet bağlantınız yoksa zaman kaynağınız nedir, onu bir yerde özledim mi?
dbasnett

Zaman kaynağı gerçekten önemli değil,% 100 doğru zamanın ardından değiliz. İstediğimiz şey, tüm makinelerin zamanlarının gerçek zamandan 10 dakika uzakta olduğu anlamına gelse bile birbiriyle senkronize olmasıdır. Bu yüzden ağdaki rastgele bir makineyi ana zaman kaynağı olarak kullanıyoruz - yani sadece dahili saati. Bildiğimiz ve kabul ettiğimiz güvenilmezdir, ancak işler senkronize olduğu sürece bizim için sorun olmaz. Gerçek konuşlandırılmış sistemde, kontrolümüzün olmadığı başka bir sistemdeki zaman kaynağını senkronize edeceğiz, bu daha doğru olabilir veya olmayabilir.
fwgx

Yanıtlar:


5

Chris'in belirttiği gibi, tabaka 16 bir sunucunun bir sunucu ile gerçekten senkronize olmadığını gösterir. Sadece emin olmak için ntp servislerini yeniden başlattınız değil mi? ( service ntpd restart) Kolay şeyleri özlediğini ima etmeye çalışmıyorum, ama hep yaparım!

Teşhise yardımcı olmak için birkaç komut daha gönderebilir misiniz?

ntpq -pistemcide ve sunucuda. Hangi sunucuları yapılandırdığını ve bu sunucuların istatistiklerini göstermelidir.
ntpdc -c monlistsunucuda. Bağlı istemcileri göstermelidir.

Ayrıca, bir işletim sisteminden bahsetmediğiniz için RHEL tarzı komutlarla çalışıyorum. Farklı bir şeyiniz varsa bana bildirin.

Daha fazla bilgi verdikten sonra DÜZENLE
tamam, çıktınızı görün, sorun burada: Tabaka 1 sunucunuz yok. Aslında, "Ay" yerel saat kullanıyor. Kendini bir katman 16 sunucusu olarak bildiriyor. Referans olarak, Stratum1 sunucusunda yerel bir GPS veya atom saati bulunur. Bunlardan biri var mı? Aksi takdirde, Moon'un saatini ANOTHER ntp sunucusuyla senkronize etmesi gerekir. Ağ erişimi yoksa, katmanını geçmeniz gerekir. (Bu, 'gerçek' zamanla çok fazla ilgilenmemenizi gerektirir. Bunu yapmazsınız, ancak bunu okuyan herkes bunu not etmelidir.)

Ay da, sizin ntp.conf dosyasına aşağıdaki satırı ekleyin: fudge 127.127.1.0 stratum 10. Bu, yerel saatini katman 10 olarak bildirecektir. Bu, diğer tüm sunucuların yerel katmanları 16 saatlerinde kullanmasını sağlayacaktır.

--Christopher Karel


ana soru mesajına sonuçlar ekledi.
fwgx

Christopher ile aynı fikirde. Strata hakkında birçok yanlış anlama ntp.org/ntpfaq/NTP-s-algo.htm
dbasnett

3

Konu dışı olabilir, yerel bir Stratum 2 sunucusu bir Stratum 1 sunucusuna bağlantı gerektirir ve izole ağınızda bir tane yoktur.

Ucuz bir GPS modülü ve bir Ahududu Pi, minimum güç tüketimi ve geniş arabirim kapasitesine sahip tek kartlı bir bilgisayar alabilirsiniz. GPS modülünüzü Raspberry Pi'ye bağlayın ve Pi'ye ağınıza katılın, uygun yazılımla, Stratum 2 sunucunuzun Stratum 1 NTP sunucunuz olabilir veya ağınız içinde her bilgisayar olduğundan, zaman senkronize edebilirsiniz.


2

NTPd, kendi katmanını aşağıdakilere göre ayarlayacaktır:

  1. Yerel saatin kayması değerlendirilmediyse, katmanı 16'ya ayarlayın. Bu işlem normal bir sunucuda yaklaşık 15 dakika sürer ve bundan sonra bir sonraki adıma geçer.
  2. Tüm yapılandırılmış zaman sunucularına bağlanın, hangilerinin güvenilir olduğunu belirleyin (ve bunun için tercih edilir), yerel katmanı en düşük güvenilir sunucunun katmanına artı bire ayarlayın. Bulunan en düşük güvenilir sunucu 1 ise, yerel 2 olacaktır.

(Bu mutlaka olayların sırası değil, yerel katmanı ayarlamak için işlendikleri sıradır.)
(Ayrıca, katman 16, senkronize olmadığı anlamına gelmez).


1
Moon, aslında Basit NTP (SNTP) olan varsayılan W32Time NTP hizmetini kullanan bir Windows XP Pro x64 makinesi olduğu için, RackCard23'ün uygun bir NTP sunucusu olarak görmediğinden, katmanını hiçbir zaman başka bir şeye ayarlamayacaktır. 16 yaşından büyük?
fwgx

D'oh, yazımı düzenlemeden önce bunu görmedim. Bu büyük olasılıkla. Hiyerarşinizin en üstünde uygun bir ntp istemcisi kullanmamak için herhangi bir neden var mı? (Windows veya Unix tabanlı)
Christopher Karel

2

Bir nevi kenara ntpq çıktısının bir analizini ekleyeceğim. Sadece gelecekte ve kendiniz ve diğerleri için genel sorun giderme işlemlerine yardımcı olmak için.

İlk olarak, sunucunuzdan:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

İlk sütun, bu makinenin senkronize edilecek şekilde yapılandırıldığı iki sunucuyu gösterir. Dikkate değer bir eş ya da ikincil adayın olmaması *ya da +bu adayları göstermesi. Bu, sunucunuzun buradaki girişleri kullanmayacağı anlamına gelir, ancak en azından onlarla giriş yapıyor demektir.

Üçüncü sütun, "st", bu sunucuların katmanını gösterir. Bu durumda, bu her iki makinenin de yerel saatlerini kullandığını gösterir. (varsayılan katman 16'dır) Son üç sütun, iki saatin ne kadar uzakta olduğunu gösterir. Ya "saatlerdeki saniye farkı" değerinde ya da iki makine arasındaki gecikmede, bu gecikmedeki farka göre. Burada, daha yüksek sayılar daha kötü.

Bunun gibi senkronize olmayan girişlerin nedeni bazı faktörlere bağlı olabilir: Saatlerdeki ofset çok fazlaysa, yerel saatte çok büyük bir sıçrama sağlayacağı için ntp bile denemeyecektir. Eğer titreme kötüleşirse, işler istikrar kazanana kadar istemci desyncc olur. (Bu genellikle geçicidir ve yine de tekrarlanır) Alternatif olarak, sizin durumunuzda olduğu gibi, yapılandırılmış sunucular eşit veya daha yüksek katman değerlerine sahipse, zaman kaynakları olarak daha az güvenilir olduklarını gösterirse, istemci bunları kullanmaz.

--Christopher Karel

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.