"Qualcuno sa davvero che ore sono? A qualcuno importa davvero?"
– Chicago, 1969
Forse a quel gruppo rock non importava che ora fosse, ma i nostri computer hanno bisogno di sapere l'ora esatta. Il cronometraggio è molto importante per le reti di computer. Nelle banche, nei mercati azionari e in altre attività finanziarie, le transazioni devono essere mantenute nell'ordine corretto e le sequenze temporali esatte sono fondamentali per questo. Per gli amministratori di sistema e i professionisti DevOps, è più facile seguire la traccia dell'e-mail attraverso una serie di server o determinare l'esatta sequenza di eventi utilizzando file di registro su host geograficamente dispersi quando l'ora esatta viene mantenuta sui computer in questione.
Lavoravo in un'organizzazione che riceveva oltre 20 milioni di e-mail al giorno e aveva quattro server solo per accettare e fare un filtro di base sul flusso di e-mail in arrivo. Da lì, le e-mail sono state inviate a uno degli altri quattro server per eseguire valutazioni anti-spam più complesse, quindi sono state consegnate a uno dei numerosi server aggiuntivi in cui le e-mail sono state inserite nelle caselle di posta corrette. Ad ogni livello, le e-mail verrebbero inviate a uno dei server di livello successivo, selezionato solo dalla casualità del DNS round-robin. A volte dovevamo rintracciare un nuovo messaggio attraverso il sistema finché non potessimo determinare dove "si fosse perso", secondo i capi dai capelli a punta. Abbiamo dovuto farlo con una regolarità spaventosa.
La maggior parte di quell'e-mail si è rivelata spam. Alcune persone si sono effettivamente lamentate del fatto che la loro [barzelletta, foto del gatto, ricetta, detto ispiratore o altra email-strana] del giorno mancava e ci hanno chiesto di trovarla. Abbiamo rifiutato queste opportunità.
La nostra e-mail e altre ricerche transazionali sono state aiutate da voci di registro con timestamp che, oggi, possono essere risolte fino al nanosecondo anche nel più lento dei moderni computer Linux. In ambienti di transazioni ad alto volume, anche pochi microsecondi di differenza negli orologi di sistema possono significare ordinare migliaia di transazioni per trovare quella corretta.
La gerarchia del server NTP
I computer di tutto il mondo utilizzano il Network Time Protocol (NTP) per sincronizzare i propri orari con gli orologi di riferimento standard di Internet tramite una gerarchia di server NTP. I server primari si trovano allo strato 1 e sono collegati direttamente a vari servizi dell'ora nazionale allo strato 0 tramite satellite, radio o persino modem tramite linee telefoniche. Il servizio orario allo strato 0 può essere un orologio atomico, un ricevitore radio sintonizzato sui segnali trasmessi da un orologio atomico o un ricevitore GPS che utilizza i segnali dell'orologio altamente precisi trasmessi dai satelliti GPS.
Per evitare che le richieste di tempo dai server dell'ora più in basso nella gerarchia (cioè con un numero di strati più alto) sovraccaricano i server di riferimento primari, ci sono diverse migliaia di server NTP strato 2 pubblici aperti e disponibili per l'uso da parte di chiunque. Molte organizzazioni con un gran numero di host che necessitano di un server NTP configureranno i propri time server in modo che solo un host locale acceda ai time server dello strato 2, quindi configureranno gli host di rete rimanenti per utilizzare il server dell'ora locale che, nel mio caso , è un server Stratum 3.
Scelte NTP
Il demone NTP originale, ntpd , è stato affiancato da uno più recente, chronyd . Entrambi mantengono l'ora dell'host locale sincronizzata con il server dell'ora. Entrambi i servizi sono disponibili e non ho visto nulla che indichi che questo cambierà a breve.
Chrony ha caratteristiche che lo rendono la scelta migliore per la maggior parte degli ambienti per i seguenti motivi:
-
Chrony può sincronizzarsi con il time server molto più velocemente di NTP. Questo è utile per laptop o desktop che non funzionano costantemente.
-
Può compensare le fluttuazioni delle frequenze di clock, ad esempio quando un host va in ibernazione o entra in modalità di sospensione, o quando la velocità di clock varia a causa del salto di frequenza che rallenta le velocità di clock quando i carichi sono bassi.
-
Gestisce le connessioni di rete intermittenti e la saturazione della larghezza di banda.
-
Si adatta ai ritardi e alla latenza della rete.
-
Dopo la sincronizzazione dell'ora iniziale, Chrony non fa mai il passo dell'orologio. Ciò garantisce intervalli di tempo stabili e coerenti per i servizi di sistema e le applicazioni.
-
Chrony può funzionare anche senza una connessione di rete. In questo caso, l'host o il server locale possono essere aggiornati manualmente.
I pacchetti NTP e Chrony RPM sono disponibili dai repository Fedora standard. Puoi installarli entrambi e passare da uno all'altro, ma le moderne versioni di Fedora, CentOS e RHEL sono passate da NTP a Chrony come implementazione predefinita per il cronometraggio. Ho scoperto che Chrony funziona bene, fornisce un'interfaccia migliore per l'amministratore di sistema, presenta molte più informazioni e aumenta il controllo.
Giusto per chiarire, NTP è un protocollo implementato con NTP o Chrony. Se vuoi saperne di più, leggi questo confronto tra NTP e Chrony come implementazioni del protocollo NTP.
Questo articolo spiega come configurare client e server Chrony su un host Fedora, ma la configurazione per le versioni correnti di CentOS e RHEL funziona allo stesso modo.
Struttura Chrony
Il demone Chrony, chronyd , viene eseguito in background e monitora l'ora e lo stato del server dell'ora specificato in chrony.conf file. Se è necessario modificare l'ora locale, chronyd lo fa senza problemi senza il trauma programmatico che si verificherebbe se l'orologio venisse istantaneamente reimpostato su una nuova ora.
cronaca di Chrony strumento consente a qualcuno di monitorare lo stato corrente di Chrony e apportare modifiche se necessario. Il cronico L'utilità può essere utilizzata come comando che accetta sottocomandi oppure può essere utilizzata come programma interattivo in modalità testo. Questo articolo spiegherà entrambi gli usi.
Configurazione client
La configurazione del client NTP è semplice e richiede poco o nessun intervento. Il server NTP può essere definito durante l'installazione di Linux o fornito dal server DHCP al momento dell'avvio. L'impostazione predefinita /etc/chrony.conf file (mostrato di seguito nella sua interezza) non richiede alcun intervento per funzionare correttamente come client. Per Fedora, Chrony utilizza il pool NTP Fedora e CentOS e RHEL hanno i propri pool di server NTP. Come molte distribuzioni basate su Red Hat, il file di configurazione è ben commentato.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network.
#allow 192.168.0.0/16
# Serve time even if not synchronized to a time source.
#local stratum 10
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
Diamo un'occhiata allo stato attuale di NTP su una macchina virtuale che utilizzo per il test. Il cronico comando, se utilizzato con il tracciamento sottocomando, fornisce statistiche che segnalano la distanza del sistema locale dal server di riferimento.
[root@studentvm1 ~]# chronyc tracking
Reference ID : 23ABED4D (ec2-35-171-237-77.compute-1.amazonaws.com)
Stratum : 3
Ref time (UTC) : Fri Nov 16 16:21:30 2018
System time : 0.000645622 seconds slow of NTP time
Last offset : -0.000308577 seconds
RMS offset : 0.000786140 seconds
Frequency : 0.147 ppm slow
Residual freq : -0.073 ppm
Skew : 0.062 ppm
Root delay : 0.041452706 seconds
Root dispersion : 0.022665167 seconds
Update interval : 1044.2 seconds
Leap status : Normal
[root@studentvm1 ~]#
L'ID di riferimento nella prima riga del risultato è il server con cui è sincronizzato l'host, in questo caso un server di riferimento di strato 3 che è stato contattato per l'ultima volta dall'host alle 16:21:30 2018. Le altre righe sono descritte nel Pagina man di chronyc(1).
Le fonti il sottocomando è utile anche perché fornisce informazioni sull'origine dell'ora configurata in chrony.conf .
[root@studentvm1 ~]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 6 377 0 -2613us[-2613us] +/- 63ms
^+ dev.smatwebdesign.com 3 10 377 28m -2961us[-3534us] +/- 113ms
^+ propjet.latt.net 2 10 377 465 -1097us[-1085us] +/- 77ms
^* ec2-35-171-237-77.comput> 2 10 377 83 +2388us[+2395us] +/- 95ms
^+ PBX.cytranet.net 3 10 377 507 -1602us[-1589us] +/- 96ms
[root@studentvm1 ~]#
La prima fonte nell'elenco è il time server che ho configurato per la mia rete personale. Gli altri sono stati forniti dalla piscina. Anche se il mio server NTP non appare nel file di configurazione di Chrony sopra, il mio server DHCP fornisce il suo indirizzo IP per il server NTP. La colonna "S" —Stato sorgente—indica con un asterisco (* ) il server con cui è sincronizzato il nostro host. Ciò è coerente con i dati del tracciamento sottocomando.
Il -v l'opzione fornisce una bella descrizione dei campi in questo output.
[root@studentvm1 ~]# chronyc sources -v
210 Number of sources = 5
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 7 377 28 -2156us[-2156us] +/- 63ms
^+ triton.ellipse.net 2 10 377 24 +5716us[+5716us] +/- 62ms
^+ lithium.constant.com 2 10 377 351 -820us[ -820us] +/- 64ms
^* t2.time.bf1.yahoo.com 2 10 377 453 -992us[ -965us] +/- 46ms
^- ntp.idealab.com 2 10 377 799 +3653us[+3674us] +/- 87ms
[root@studentvm1 ~]#
Se volessi che il mio server fosse l'origine dell'ora di riferimento preferita per questo host, aggiungerei la riga seguente a /etc/chrony.conf file.
server 192.168.0.51 iburst preferDi solito metto questa riga appena sopra la prima istruzione del server del pool vicino alla parte superiore del file. Non c'è una ragione speciale per questo, tranne che mi piace tenere insieme le istruzioni del server. Funzionerebbe altrettanto bene nella parte inferiore del file e l'ho fatto su diversi host. Questo file di configurazione non è sensibile alla sequenza.
Il preferisce l'opzione contrassegna questa come la fonte di riferimento preferita. Pertanto, questo host sarà sempre sincronizzato con questa origine di riferimento (purché sia disponibile). Possiamo anche utilizzare il nome host completo per un server di riferimento remoto o solo il nome host (senza il nome di dominio) per un'origine dell'ora di riferimento locale purché l'istruzione di ricerca sia impostata in /etc/resolv.conf file. Preferisco l'indirizzo IP per garantire che l'origine dell'ora sia accessibile anche se il DNS non funziona. Nella maggior parte degli ambienti, il nome del server è probabilmente l'opzione migliore, perché NTP continuerà a funzionare anche se l'indirizzo IP del server cambia.
Se non disponi di una fonte di riferimento specifica su cui desideri eseguire la sincronizzazione, è possibile utilizzare le impostazioni predefinite.
Configurazione di un server NTP con Chrony
La cosa bella del file di configurazione di Chrony è che questo singolo file configura l'host sia come client che come server. Per aggiungere una funzione server al nostro host (sarà sempre un client, ottenendo l'ora da un server di riferimento) dobbiamo solo apportare un paio di modifiche alla configurazione di Chrony, quindi configurare il firewall dell'host per accettare le richieste NTP.
Apri il /etc/crony .conf file nel tuo editor di testo preferito e decommenta lo stratum locale 10 linea. Ciò consente al server Chrony NTP di continuare a comportarsi come se fosse connesso a un server di riferimento remoto se la connessione Internet non riesce; ciò consente all'host di continuare a essere un server NTP per altri host sulla rete locale.
Ripartiamo chronyd e traccia come funziona il servizio per alcuni minuti. Prima di abilitare il nostro host come server NTP, vogliamo provare un po'.
[root@studentvm1 ~]# systemctl restart chronyd ; watch chronyc trackingI risultati dovrebbero assomigliare a questo. L'orologio il comando esegue il monitoraggio cronologico comando ogni due secondi in modo da poter osservare i cambiamenti che si verificano nel tempo.
Every 2.0s: chronyc tracking studentvm1: Fri Nov 16 20:59:31 2018
Reference ID : C0A80033 (192.168.0.51)
Stratum : 4
Ref time (UTC) : Sat Nov 17 01:58:51 2018
System time : 0.001598277 seconds fast of NTP time
Last offset : +0.001791533 seconds
RMS offset : 0.001791533 seconds
Frequency : 0.546 ppm slow
Residual freq : -0.175 ppm
Skew : 0.168 ppm
Root delay : 0.094823152 seconds
Root dispersion : 0.021242738 seconds
Update interval : 65.0 seconds
Leap status : Normal
Nota che il mio server NTP, lo studentvm1 host, si sincronizza con l'host in 192.168.0.51, che è il mio server NTP di rete interno, allo strato 4. La sincronizzazione diretta con le macchine del pool Fedora risulterebbe nella sincronizzazione allo strato 3. Si noti inoltre che la quantità di errore diminuisce nel tempo. Alla fine, dovrebbe stabilizzarsi con una piccola variazione attorno a un intervallo di errore abbastanza piccolo. La dimensione dell'errore dipende dallo strato e da altri fattori di rete. Dopo alcuni minuti, usa Ctrl+C per uscire dal ciclo di visualizzazione.
Per trasformare il nostro host in un server NTP, dobbiamo consentirgli di ascoltare sulla rete locale. Decommenta la riga seguente per consentire agli host sulla rete locale di accedere al nostro server NTP.
# Allow NTP client access from local network.
allow 192.168.0.0/16
Si noti che il server può ascoltare le richieste su qualsiasi rete locale a cui è collegato. L'indirizzo IP nella riga "consenti" ha solo scopo illustrativo. Assicurati di modificare la rete IP e la subnet mask in quella riga in modo che corrispondano a quelle della tua rete locale.
Riavvia chronyd .
[root@studentvm1 ~]# systemctl restart chronydPer consentire ad altri host sulla tua rete di accedere a questo server, configura il firewall per consentire i pacchetti UDP in entrata sulla porta 123. Controlla la documentazione del tuo firewall per scoprire come farlo.
Test
Il tuo host è ora un server NTP. Puoi testarlo con un altro host o una VM che ha accesso alla rete su cui è in ascolto il server NTP. Configura il client per utilizzare il nuovo server NTP come server preferito in /etc/chrony.conf file, quindi monitora quel client utilizzando chronyc strumenti che abbiamo usato sopra.
Chronyc come strumento interattivo
Come ho detto prima, cronaca può essere utilizzato come strumento di comando interattivo. Esegui semplicemente il comando senza un sottocomando e otterrai un chronyc prompt dei comandi.
[root@studentvm1 ~]# chronyc
chrony version 3.4
Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the
GNU General Public License version 2 for details.
chronyc>
Puoi inserire solo i sottocomandi a questo prompt. Prova a utilizzare il monitoraggio , ntpdata e fonti comandi. Il cronico la riga di comando consente il richiamo e la modifica dei comandi per chronyc sottocomandi. Puoi utilizzare la aiuto sottocomando per ottenere un elenco di possibili comandi e la loro sintassi.
Conclusione
Chrony è un potente strumento per sincronizzare gli orari degli host dei client, siano essi tutti sulla rete locale o sparsi per il mondo. È facile da configurare perché, nonostante l'elevato numero di opzioni disponibili, nella maggior parte delle circostanze sono necessarie solo poche configurazioni.
Dopo che i miei computer client si sono sincronizzati con il server NTP, mi piace impostare l'orologio hardware del sistema dall'ora del sistema (OS) usando il comando seguente:
/sbin/hwclock --systohcQuesto comando può essere aggiunto come cron job o script in cron.daily per mantenere l'orologio hardware sincronizzato con l'ora di sistema.
Chrony e NTP (il servizio) utilizzano entrambi la stessa configurazione e il contenuto dei file è intercambiabile. Le pagine man di chronyd, chronyc e chrony.conf contengono un'incredibile quantità di informazioni che possono aiutarti a iniziare o a conoscere le opzioni di configurazione esoteriche.
Gestisci il tuo server NTP? Facci sapere nei commenti e assicurati di dirci quale implementazione stai utilizzando, NTP o Chrony.