Server NTP tunggal pada jaringan isolat

Saya memiliki dua mesin linux (A dan B) di jaringan yang terisolasi. Mereka harus disinkronkan dengan waktu. Mesin A diaktifkan sesekali dan harus melayani waktu, karena terhubung ke sumber waktu otoritatif (GPS). Mesin B hanya diberi daya jika mesin A diaktifkan, tetapi ini adalah perangkat linux tertanam dan status dayanya akan sering berubah. Tidak ada mesin yang memiliki akses ke sistem lain. Ini jaringan tertutup.

Saya mengerti bahwa ini adalah urutan yang cukup tinggi untuk NTP, karena NTP biasanya mengharapkan untuk melakukan kontak dengan beberapa server. Saya mengalami masalah agar ini berfungsi dengan benar di Mesin B. Mesin A sinkron ke GPS, dan mesin B dapat mencapai mesin A dan bahkan melakukan kueri waktu, tetapi Mesin A tidak dipercaya (mungkin dengan sendirinya?). Setelah satu jam penuh mesin A menyala, tiba-tiba ini berubah dan mesin B bekerja. Namun, ketika mesin A turun (dan dengan demikian mesin B), mesin B sekali lagi tidak dapat menemukan sinkronisasi waktu yang baik.

Ini beberapa info ntpdate. Harap dicatat bahwa meskipun strata mesin A adalah 1, operasi gagal dengan output yang sama di akhir.

10.10.10.1: Server terjatuh: strata terlalu tinggi
server 10.10.10.1, port 123
strata 16, presisi -19, lompatan 11, kepercayaan 000
refid [10.10.10.1], tunda 0,02614, dispersi 0,00000
dikirimkan 4, dalam filter 4
waktu referensi: 00000000.00000000 Kamis, 7 Februari 2036 6: 28: 16.000
originate timestamp: d3a9bdc4.27ebb350 Kamis, 12 Juli 2012 21: 19: 00.155
kirimkan stempel waktu: bc17c803.b42dfffe Sat, 1 Januari 2000 0: 25: 39.703
penundaan filter: 0,02625 0,02614 0,02618 0,02625 
         0,00000 0,00000 0,00000 0,00000 
offset filter: 39544160 39544160 39544160 39544160
         0,000000 0,000000 0,000000 0,000000
menunda 0,02614, dispersi 0,00000
mengimbangi 395441600.451568

 1 Jan 00:25:39 ntpdate [677]: tidak ada server yang cocok untuk sinkronisasi ditemukan

Dugaan saya adalah bahwa mesin A tidak percaya diri untuk melayani waktu. Setelah 51 menit (mungkin telah terjadi sebelumnya, saya tidak tahu) waktu aktif dan jamnya disinkronkan ke GPS, mesin A mulai melayani waktu dengan benar, dan mesin B mengambilnya. Saya ingin ini terjadi lebih awal. Seperti, dalam beberapa detik jika memungkinkan.

Dengan konfigurasi berikut (dan banyak menunggu), akhirnya berhasil.

Mesin A ntp.conf:

Server 127.127.28.0 lebih suka minpoll 4 benar maxpoll 4
fudge 127.127.28.0 strata 1 waktu1 0,420 GPS jarak jauh 

Mesin B ntp.conf:

server 10.10.10.1 lebih suka minpoll 4 benar maxpoll 4

ntpq -c rekan pada Mesin B tanpa perbaikan waktu yang baik:

     remote control ketika jajak pendapat mencapai keterlambatan mengimbangi jitter
================================================== ============================
 10.10.10.1. LANGKAH. 16 u 9 16 0 0,000 0,000 0,000

ntp1 -c rekan pada Mesin B dengan perbaikan waktu yang baik:

     remote control ketika jajak pendapat mencapai keterlambatan mengimbangi jitter
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0.669 2.597 1.808

Jadi, sekarang pertanyaannya menjadi: bagaimana cara saya membuat Mesin A percaya dengan cepat?

Beberapa output debug dari Mesin A sebelum dan sesudah mesin B memutuskan bahwa Mesin A cukup baik untuk digunakan ..

sebelum..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 acara, no_sys_peer,
version = "ntpd 4.2.6p4@1.2324 Fri 24 Feb 15:01:45 UTC 2012 (1)",
prosesor = "armv7l", system = "Linux / 2.6.35.14", leap = 11, stratum = 2,
presisi = -19, rootdelay = 0,000, rootdisp = 44,537, refid = SHM (0),
reftime = d3ab0053.43b44780 Fri, 13 Jul 2012 20: 15: 15.264,
clock = d3ab0062.e7e03154 Fri, 13 Jul 2012 20: 15: 30.905, rekan = 34819, tc = 4,
mintc = 3, offset = 0,000, frekuensi = 0,000, sys_jitter = 3,853,
clk_jitter = 36.492, clk_wander = 0.000

setelah...

~ # ntpq -c rv
associd = 0 status = 0415 leap_none, sync_uhf_radio, 1 acara, clock_sync,
version = "ntpd 4.2.6p4@1.2324 Fri 24 Feb 15:01:45 UTC 2012 (1)",
prosesor = "armv7l", system = "Linux / 2.6.35.14", leap = 00, stratum = 2,
presisi = -19, rootdelay = 0.000, rootdisp = 41.278, refid = SHM (0),
reftime = d3ab0063.43b37856 Fri, 13 Jul 2012 20: 15: 31.264,
clock = d3ab006d.9ee53ec2 Fri, 13 Jul 2012 20: 15: 41.620, rekan = 34819, tc = 4,
mintc = 3, offset = 0,000, frekuensi = 43,896, sys_jitter = 0,762,
clk_jitter = 36.953, clk_wander = 0.000

NTP harus bekerja dengan baik. Lihatlah beberapa opsi untuk sinkronisasi cepat saat start-up. Lihat opsi burstdan iburstuntuk sistem B. Lihat trueopsi untuk sumber jam GPS.

Pertimbangkan untuk menggunakan jam perangkat keras sebagai sumber waktu cadangan di kedua sistem. Tetapkan sistem strata yang lebih tinggi B. Sesuatu seperti yang berikut ini akan berfungsi:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Tonton output ntpq -c peersuntuk melihat kapan Anda mendapatkan sumber jam tepercaya. Biasanya ntpingin sejumlah tanggapan dari sumber waktu tepercaya sebelum mempercayainya. Ini ditunjukkan oleh karakter pertama di setiap baris.

Sementara NTP menyukai lebih banyak sumber, jumlah sumber waktu ganjil dalam satu tingkat strata harus bekerja dengan baik. Karena Anda hanya memiliki dua server dan jam GPS prioritas (stratum) dari sumber harus meningkat dari GPS, jam di server A, jam di server B. Meningkatkan strata antara masing-masing tiga atau empat tingkat akan memastikan prioritas dihormati.

EDIT: Jika Anda memiliki server NTP busybox di server A, mungkin ada baiknya menginstal paket server ntp lengkap. Memahami apa yang terjadi dengan server A harus melalui jalan panjang untuk menyelesaikan masalah Anda. Anda memerlukan setidaknya satu sumber waktu tepercaya di sana sebelum server B harus memercayainya. Jika ntpq -c peerstidak berhasil, maka Anda dapat mencoba ntpdc peers. Kedua perintah ini memungkinkan Anda untuk menanyakan host lain. Sebuah peerstatslog juga dapat berguna.

Di server B gunakan ntpclient seperti yang didokumentasikan busybox ntp howto untuk mencatat apa yang terjadi di dalamnya

Jam harus cukup dekat dengan waktu yang tepat jika server belum lama mati. Jika Anda perlu menyinkronkan kedua sistem, itu sudah cukup. GPS akan membawa waktu ke sinkronisasi dengan dunia nyata pada akhirnya.

'ntpd -q' menyinkronkan dengan cepat, tetapi keluar (perilaku ntpdate). Perlu diikuti oleh ntpdperintah tanpa opsi keluar untuk melakukan sinkronisasi terus menerus.

EDIT2: Saya memeriksa server saya dan menemukan salah satu server dimatikan sedetik. Sambil memperbaiki ini saya bermain dengan pengaturan. iburstmembuat server dipercaya dengan sangat cepat. truememastikan driver jam dipercaya jika tidak ada beberapa sumber tepercaya lainnya. Jam itu mengambil sedikit lebih dari satu menit sebelum jam itu dipercaya secara lokal dan bisa dipercaya dari jarak jauh.

Saat menguji Anda harus dapat memulai kembali ntpdproses setelah disinkronkan dan menguji seberapa cepat pengaturan bekerja. Dalam kasus di atas Server B mungkin perlu dihidupkan ulang untuk menguji seberapa cepat sinkronisasi. Saat memantau ntpdperubahan, saya menggunakan garis seperti:

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

Nama host dan waktu tidur disesuaikan sesuai kebutuhan. Dalam beberapa kasus, saya rantai dua atau lebih ntpqbaris perintah di loop. Saat melakukannya, saya menggunakan perintah gema dan / atau tanggal untuk memberikan indikasi di mana set data berubah.