chrony vs. systemd-timesyncd - Quali sono le differenze e i casi d'uso come client NTP?


18

In qualche modo, ma non del tutto, basandosi sulla domanda precedente "ntpd vs. systemd-timesyncd - Come ottenere una sincronizzazione NTP affidabile?" , Vorrei chiedere le differenze tra chrony e systemd-timesyncd in termini di client NTP .

So che systemd-timesyncd è un'implementazione client ntp più o meno minimale mentre chrony è una soluzione demone NTP completa che sembra includere un client NTP.

Le note di rilascio di Ubuntu Bionic Beaver indicano quanto segue:

Per semplici esigenze di sincronizzazione, il sistema di base è già dotato di systemd-timesyncd. Chrony è necessario solo per fungere da time server o se si desidera la sincronizzazione pubblicizzata più accurata ed efficiente.

Mi piace l'idea di utilizzare uno strumento minimo preinstallato per fare il lavoro e sono abbastanza sicuro che systemd-timesyncd farà il lavoro per i miei casi d'uso, tuttavia sono curioso:

  • Quali sono le differenze del mondo reale tra i due in termini di precisione?
  • Quali sono le differenze di efficienza?
  • Quali sono i tempi di sincronizzazione "non semplici", ovvero i casi d'uso di chrony come client NTP?

Risposte:


13

L' annuncio di systemd-timesyncd nel file systemd NEWS fa un buon lavoro nel spiegare le differenze di questo strumento rispetto a Chrony e strumenti simili. (enfasi mia):

È stato aggiunto un nuovo demone "systemd-timesyncd" per sincronizzare l'orologio di sistema attraverso la rete. Implementa un client SNTP . A differenza delle implementazioni NTP come chrony o il server di riferimento NTP, questo implementa solo un lato client e non si preoccupa della piena complessità NTP, concentrandosi solo sull'interrogazione del tempo da un server remoto e sulla sincronizzazione dell'orologio locale con esso . A meno che non si intenda servire NTP per client in rete o non si desideri connettersi a orologi hardware locali, questo semplice client NTP dovrebbe essere più che appropriato per la maggior parte delle installazioni. [...]

Questa configurazione è un caso d'uso comune per la maggior parte degli host in una flotta di server. Di solito vengono sincronizzati dai server NTP locali, che a loro volta vengono sincronizzati da più fonti, incluso eventualmente l'hardware. systemd-timesyncd cerca di fornire una soluzione di facile utilizzo per quel caso d'uso comune.


Cercando di rispondere a domande specifiche:

Quali sono le differenze del mondo reale tra i due in termini di precisione?

Credo che tu possa ottenere una maggiore precisione ottenendo dati di sincronizzazione da più fonti, che non è specificamente un caso d'uso supportato per systemd-timesyncd. Ma quando lo si utilizza per ottenere dati di sincronizzazione dai server NTP centrali collegati alla propria rete interna affidabile, l'utilizzo di più origini non è poi così rilevante e si ottiene una buona precisione da un'unica fonte.

Se stai sincronizzando il tuo server da un server fidato in una rete locale e nello stesso datacenter , la differenza di precisione tra NTP e SNTP sarà praticamente inesistente. NTP può prendere in considerazione RTT e fare i tempi, ma non è molto utile quando RTT è veramente piccolo, come nel caso di una rete locale veloce e di un computer vicino. Inoltre non hai bisogno di più fonti se ti puoi fidare di quello che stai usando.

Quali sono le differenze di efficienza?

Ottenere la sincronizzazione da una singola fonte è molto più semplice che ottenerla da più fonti, poiché non è necessario prendere decisioni su quali fonti sono migliori di altre e possibilmente combinare informazioni da più fonti. Gli algoritmi sono molto più semplici e richiederanno meno carico della CPU per il caso semplice.

Quali sono i tempi di sincronizzazione "non semplici", ovvero i casi d'uso di chrony come client NTP?

Questo è affrontato nella citazione sopra, ma in ogni caso si tratta di casi d'uso per Chrony che non sono coperti da systemd-timesyncd:

  • in esecuzione server NTP (in modo che altri host possano utilizzare questo host come sorgente per la sincronizzazione);
  • ottenere informazioni sulla sincronizzazione NTP da più fonti (che è importante per gli host che ottengono tali informazioni dai server pubblici su Internet); e
  • ottenere informazioni di sincronizzazione dall'orologio locale, che di solito coinvolge hardware specializzato come dispositivi GPS in grado di ottenere informazioni precise sul tempo dai satelliti.

Questi casi d'uso richiedono Chrony o ntpd o simili.


1
Grazie mille per la risposta elaborata e per il pollice in alto per aver affrontato in modo specifico le mie domande. Per approfondire ciò: - - 1. Qual è l'ordine di grandezza del delta di precisione. Sapere questo aggiungerebbe sicuramente un po 'di sostanza al processo decisionale. Stiamo parlando di 10 ^ -9 o 10 ^ -1 secondi? - - 2. La tua risposta sull'efficienza mi ha reso ancora più gentile: - in modo blasfemo - una media di alcuni numeri aggiunge così tanto al carico della CPU che devi menzionarlo nelle note di rilascio di Ubuntu?
wedi,

3
@wedi: l'accuratezza di timesyncd dipenderà principalmente dal server e dalla rete. Con un solo server, non c'è modo di sapere se il server sta restituendo dati fasulli, quindi devi solo fidarti completamente di esso. (L'errore massimo da questo è illimitato). La massima precisione che puoi ottenere sarà determinata dal jitter di rete tra te e il server (potrebbe essere un paio di millisecondi o più).
TooTea

1
Grazie, @TooTea! Ok. Vedo. Quindi la maggiore precisione deriva dall'uso di più di una fonte e qualsiasi speciale chrony magic che sta facendo con una singola fonte può essere trascurato. La mia comprensione: - - 1. Utilizzo del singolo timeserver metadata.google.internal su un'istanza GCE => nessuna differenza misurabile nell'accuratezza (escludiamo il timemearing et.al.) - - 2. Utilizzo di tre server a tempo con ottima reputazione su un VM in alcune società di hosting consolidate => vedi una differenza ma non "molto" (qualunque cosa possa essere) - - 3. Usando pool.ntp.org su un raspi collegato tramite alcuni ISP => sei felice quanto Larry può ottenere.
wedi,

Direi corretto su tutti e tre i @wedi. In particolare (1), se si utilizza un timeserver sulla stessa "rete locale" della propria macchina ed essenzialmente nello stesso datacenter (rtt molto basso e jitter molto basso) i vantaggi di NTP e timemearing rispetto a SNTP, per quanto riguarda l'accuratezza, sarà molto basso. Quindi ci sono pochi motivi per eseguire NTP (e non SNTP) in questi casi d'uso!
filbranden,

@wedi Aggiornata la risposta per menzionare esplicitamente l'utilizzo di un server attendibile su una rete locale.
filbranden,

14

Come l'altra risposta afferma correttamente, chronyimplementa NTP e systemd-timesyncdSNTP.

Dal punto di vista di un client del servizio orario:

SNTP è un protocollo molto più semplice da implementare;
NTP consente incrementi / correzioni passo-passo in tempo. Uno dei principali vantaggi di NTP è che tiene conto anche dell'RTT della risposta per ottenere un orario più preciso.

Da https://www.meinbergglobal.com/english/faq/faq_37.htm

Mentre un server o client NTP con funzionalità complete raggiunge un livello di precisione molto elevato ed evita il più possibile i bruschi intervalli di tempo utilizzando diversi metodi matematici e statistici e regolazioni regolari della velocità di clock, SNTP può essere raccomandato solo per applicazioni semplici, dove i requisiti per l'accuratezza e l'affidabilità non sono troppo esigenti. Ignorando i valori di deriva e utilizzando metodi semplificati di metodi di regolazione dell'orologio di sistema (spesso semplici passi temporali), SNTP ottiene solo una sincronizzazione temporale di bassa qualità rispetto a un'implementazione NTP completa.

SNTP adotta un approccio molto più semplice. Molte delle complessità dell'algoritmo NTP vengono rimosse. Piuttosto che distorcere il tempo, molti client SNTP fanno un passo indietro. Questo va bene per molte applicazioni in cui è richiesto un semplice timestamp. Inoltre, SNTP non ha la capacità di monitorare e filtrare più server NTP. Spesso viene utilizzato un semplice approccio round robin, in cui se un server si guasta, viene utilizzato il successivo in un elenco

Da https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP è molto più accurato e preciso di SNTP e questo lo rende di fatto il vincitore nella maggior parte delle applicazioni aziendali. D'altra parte, la semplicità di SNTP lo rende più appropriato per cose come telecamere IP, DVR e alcuni switch di rete. Questi tipi di hardware non dispongono delle risorse di elaborazione per gestire protocolli più complessi, ma quando i dispositivi connessi diventano sempre più potenti, ciò può cambiare.

Uno dei principali punti deboli di SNTP è che non è possibile renderlo più preciso recuperando il tempo da più fonti come per impostazione predefinita Network Time Protocol.

Un altro punto importante che posso vedere le implementazioni SNTP che danno più problemi di NTP è nella virtualizzazione, quando hai sia l'hypervisor che il demone NTP che provano a cambiare il tempo della VM. Soprattutto con loro che non concordano in tempo con qualche configurazione errata li rende entrambi attivi, potrebbe causare grossi problemi. (Mentre gli amministratori di sistema competenti manterranno attivo solo un metodo per la sincronizzazione con il tempo, può accadere che siano entrambi attivi da un errore di configurazione).

PS systemd-timesyncdnon dovrebbe essere un'alternativa consigliata quando non in uso systemd.


1
Non è del tutto ovvio. In teoria si potrebbe eseguire il systemd-timesyncdprogramma con un altro gestore dei servizi. Ho fornito un pacchetto di servizi per eseguirlo sotto il nosh toolkit's service-managerdal 2018. Quello che hai perso è che le persone systemd (per bug Debian n. 812522) incoraggiano i servizi guest di VirtualBox e altri a entrare in conflitto esplicito con il systemd-timesyncdservizio per impedirne l'uso nelle macchine virtuali.
JdeBP

@JdeBP Osservazione interessante. Uso Debian senza systemd.... Tuttavia, vmtools timesync può e sarà disabilitato e dovrebbe essere disabilitato nei server che eseguono servizi NTP (ad esempio le VM dei server NTP), e alcuni amministratori di sistema vengono sincronizzati da vmtools, altri seguono i documenti di VmWare che disabilitano il timesync di vmtools (che dovrebbe essere usato solo quando sai cosa stai facendo). Questo bug non è lineare da risolvere e sarà un ulteriore punto di configurazione facilmente individuabile dalle persone che seguono i consigli di VmWare di non usare vmtools timesync.
Rui F Ribeiro,

(modifica la mia risposta alla luce della tua osservazione, ho avuto un errore su quel testo sulla gestione di vmtools vs (S) NTP e rendilo più esplicito)
Rui F Ribeiro

1
@wedi Nel caso di VmWare la sincronizzazione con l'hypervisor può essere disabilitata sia su Vcenter, sia sulla configurazione delle immagini VM o sul lato Linux. vedere unix.stackexchange.com/questions/492487/… correlato che faccio sempre vmware-toolbox-cmd timesync disablenei miei server NTP, indipendentemente dal fatto che i ragazzi di VmWare abbiano disabilitato la sincronizzazione oraria per quelle VM. (Di solito preferisco anche usare chrony come client NTP)
Rui F Ribeiro

1
Sono contento che tu abbia sottolineato la possibile gara di sincronizzazione temporale! Buono a tenerlo a mente!
wedi,

0

chronynon è un fork, ntpdma è implementato da zero. Implementa le modalità client e server del protocollo NTPv4 completo ( RFC5905 ). Per gli utenti di livello aziendale, stiamo assistendo a una tendenza dal tradizionale ntpdal chronyRed Hat simile (da RHEL 7 in poi) e SuSE (da SLES 15).

systemd-timesyncdimplementare solo la modalità client protocollo SNTP ( RFC4330 ) . Quindi i casi d'uso complessi non sono coperti da . Ad esempio, SNTP non può renderlo più preciso recuperando il tempo da più fonti come NTP fa per impostazione predefinita. Di conseguenza, non è possibile fornire tempi di alta precisione come .systemd-timesyncdsystemd-timesyncdchrony


1
Mmmh. Non ho notato nessuno che pretende che chrony sia un fork e ho menzionato nella mia domanda che chrony implementa server e client mentre systemd-timesyncd è solo client. Grazie per aver menzionato le RFC pertinenti.
wedi,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.