Corretta configurazione NTP per alcuni server


9

Ho circa 20 server Linux in una piccola rete e ho bisogno che i loro orologi siano abbastanza vicini l'uno all'altro (ad es. Entro 20 msec). Ho iniziato con ognuno di loro sincronizzato con europe.pool.ntp.org e il lavoro è fatto.

Ora ho due domande:

  1. Sono un onere notevole per la piscina? Vale a dire che fa una notevole differenza per il pool se sto colpendo da 20 server o da 2?
  2. Se fa la differenza, qual è il setup / configurazione che manterrà la mia sottorete sincronizzata e il pool sotto carico leggero? Ci sono linee guida per reti enormi ( http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101 ) ma non ne ho trovate nessuna per reti piccole.

1
Di solito dovresti avere uno o due time server interni con cui sincronizzare la tua rete interna. I tuoi due server interni possono avere una peerrelazione. Vedi ad esempio ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101
Marki

Grazie per i commenti e il link Marki. Per quanto riguarda il collegamento, nota che è per "una rete enorme" che non è certo il mio caso. Per quanto riguarda il tuo suggerimento: non credo che un time server interno sia una buona idea (singolo punto di errore), ma 2 sembrano una buona idea. Puoi spiegare cos'è una relazione tra pari (o fornire un collegamento)?
ndemou,

Dovrei anche notare che non sono assolutamente un esperto di NTP - tutt'altro :-)
ndemou,

Non ti farà male se google un po 'su cosa sia un pari. Si noti che questo sito non serve nulla su un piatto d'argento quando le persone non effettuano alcuna ricerca.
Marki,

Non fraintendermi, ho fatto i miei compiti, ma l'NTP è uno di questi argomenti in cui la maggior parte della documentazione è troppo ingoiata (questo è il file ntp.conf - basta usarlo) o troppo in profondità (50 pagine di teoria dell'operazione da leggere prima di te può iniziare a cogliere i fatti di base).
ndemou,

Risposte:


8
  1. Sono un onere notevole per la piscina? Vale a dire che fa una notevole differenza per il pool se sto colpendo da 20 server o da 2?

Dato che il pool ha costantemente bisogno di server per molti anni (vedi [1]) direi che sebbene 2 o 20 server non facciano davvero la differenza, dovresti sempre ricordare che non sei solo. Quindi è meglio pensare a dire 1000 amministratori nel qual caso stiamo parlando di 2000 o 20000 server e questo fa la differenza.

  1. Se fa la differenza, qual è il setup / configurazione che manterrà la mia sottorete sincronizzata e il pool sotto carico leggero?

È necessario sincronizzare due [2] server nella rete con il pool (chiamiamoli server NTP primari ) e quindi sincronizzare tutti gli altri server con quei due. Questo metodo ha anche il vantaggio che il tempo tra tutti i tuoi server sarà abbinato più da vicino (entro meno di 1msec). Ciò è conforme alle migliori pratiche IETF .

1) La configurazione per i server NTP primari

Sostituisci le righe servere restrictdel tuo ntp [d] .conf con il seguente e mantieni il resto ai valori predefiniti della tua distribuzione [3]:

server 10.11.12.1  iburst peer
#      ^^^^^^^^^^^
#      The LAN IP of the _other_ Primary NTP server 
server 0.europe.pool.ntp.org 
server 1.europe.pool.ntp.org 
server 2.europe.pool.ntp.org 
server 3.europe.pool.ntp.org 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Si noti che questa configurazione consente anche agli host di Internet di interrogare l'ora dell'host tramite query NTP. Usa il tuo firewall se non vuoi. Nel mio esempio 10.11.12.1 e 10.11.12.2 sono gli IP dei server NTP primari (hanno due schede di rete una rivolta verso Internet pubblico e una la sottorete locale 10.11.12.x). Ogni server NTP primario ha l'altro dichiarato come peer (peer significa essenzialmente sia server che client: usi l'altro host come sorgente temporale e anche l'altro host ti utilizza come sorgente temporale). Quindi regola l'IP sulla prima riga in modo che la configurazione di ciascun server NTP primario punti all'altra come peer. Vedi [4] per quanto riguarda la mia scelta di usare 4 server.

2) La configurazione per tutti gli altri server

2A) Se si dispone di due interfacce di rete

È meglio utilizzare la seconda interfaccia per creare una sottorete locale (ad es. 10.11.12.0/24) E utilizzarla per le query NTP. In tal caso, le linee di limitazione possono essere più strette. Quindi di nuovo sostituisci le righe servere restrictdel tuo ntp [d] .conf con il seguente e mantieni il resto ai valori predefiniti della tua distribuzione [3]:

restrict -4 default ignore
restrict -6 default ignore
restrict 10.0.0.0 mask 255.0.0.0 kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

2B) Se non si hanno due interfacce di rete

È necessario utilizzare le seguenti righe di limitazione (e leggere la nota sull'uso del firewall per bloccare l'accesso ai server NTP sopra). Quindi di nuovo sostituisci le righe servere restrictdel tuo ntp [d] .conf con il seguente e mantieni il resto ai valori predefiniti della tua distribuzione [3]:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

Appunti

[1] Dal 2006 al 2012 chiedono costantemente l'adesione di più server: la richiesta del 2006 , quella del 2009 e quella del 2012 . Controlla www.pool.ntp.org per aggiornamenti sullo stato corrente.

[2] Due server NTP primari sono proposti solo come un modo semplice per ottenere ridondanza senza complicate disposizioni di disponibilità elevata. Puoi optare per 3 o 4 per altri motivi (leggi di nuovo le migliori pratiche IETF )

[3] In pratica e indipendentemente dalla tua distribuzione, l'unica altra cosa che devi includere nella tua configurazione ntpd è una linea che definisce una directory per mettere un file di drift e un nome per esso - ad es driftfile /var/lib/ntp/ntp.drift. Ho testato la mia soluzione in CentOS, Debian e Ubuntu. Immagino che funzioni nella maggior parte delle altre distro.

[4] Ho configurato 4 server pool seguendo le migliori pratiche . La configurazione di più di 4 server è tecnicamente accettata, ma aumenterai il carico nel pool NTP per un discutibile aumento della disponibilità, quindi non farlo. Nelle migliori pratiche vedo che "a partire da ntp-4.2.6, la direttiva" pool "creerà associazioni" sufficienti "per fornire un valido servizio di tempo", quindi se si utilizza .pool. indirizzi come faccio qui e ntp> = 4.2.6 il numero esatto di linee del server probabilmente non ha importanza.

Rant Oh! Odio l'NTP (tranne per il fatto che mi piace che funzioni). La documentazione ufficiale è piena di informazioni obsolete e hanno "come si usa?" informazioni mescolate con dettagli scientifici sugli interni. E odio anche come restrict 127.0.0.1significhi davveroallow everything for 127.0.0.1


Storia degli aggiornamenti

Ho rimosso l' iburstopzione dalla configurazione dei server NTP locali perché la loro compatibilità con il pool è discutibile. (vedi commenti). La loro rimozione aggiunge solo un paio di minuti di tempo di attesa alla prima sincronizzazione.


Crediti

Commenti e risposte degli utenti SF Marki e Sven hanno fornito un buon punto di partenza per questa risposta. Grazie ad entrambi.


1
+1 da me. Gestisco un server pool e non posso enfatizzare eccessivamente la correttezza di questo post, tranne per il fatto che iburstè un parametro fastidioso da utilizzare sui server pubblici, quindi per favore non farlo (anche se non è così fastidioso come burst). Gli amministratori dei pool server ti stanno facendo un favore senza sapere chi sei e senza alcuna ricompensa per se stessi, puramente per il miglior funzionamento di Internet. Se tu, lavorando di più, riesci a rendere le loro vite più facili, devi farlo a loro.
MadHatter,

Grazie MadHatter. Per quanto riguarda iburst, ho pensato che fosse OK per i tipici server "sempre attivi". Hai dei link per supportare il tuo consiglio di non usare questa opzione? (Ho controllato www.pool.ntp.org/en/use.html e ho anche cercato su Google per 10 minuti ma non ho trovato nulla di conclusivo)
ndemou

Condividerò felicemente le mie statistiche sul traffico; un breve esempio suggerisce che host non configurati correttamente, ovvero host che trasmettono più frequentemente di una volta al minuto, rappresentano circa il 45% dei miei clienti ma sono responsabili di circa il 75% del traffico. Ciò avverrà principalmente dai server che usano burst, ma iburstdice anche (dalla ntpdpagina man) " con questa opzione viene scambiata una raffica di messaggi per sistemare i dati e impostare l'orologio in circa 10 secondi ". Usando iburstdice " impostare il mio orologio rapidamente è più importante che mantenere basso il carico sul tuo server ", e questo è scortese.
MadHatter,

Hai ragione sulla "raffica di messaggi", ma per quanto posso capire questo scoppio avverrà solo durante l'avvio del demone NTP e (forse) se il server del pool è momentaneamente irraggiungibile (io sono iniziale). Ecco un estratto dalla pagina NTPd di Arch wiki: "L'opzione iburst è consigliata e invia un'esplosione di pacchetti solo se non riesce a ottenere una connessione con il primo tentativo. L'opzione burst lo fa sempre, anche al primo tentativo, e non dovrebbe mai essere utilizzato senza autorizzazione esplicita e potrebbe comportare la blacklist ".
ndemou,

Hai ragione, iburstè molto meno discutibile di burst. Il mio punto è che quando stai usando la risorsa di qualcun altro gratuitamente, c'è un argomento che dovresti piegarti all'indietro per essere premuroso; semplicemente non essere attivamente sconsiderati non può essere ritenuto sufficiente. Sono d'accordo che si dice che sia la migliore pratica, ma quei documenti non tengono conto del fatto che i server upstream a cui stai sincronizzando facciano parte della tua azienda o meno; dettano le migliori pratiche tecniche (che, sono d'accordo, è di usare iburst) piuttosto che le migliori pratiche sociali .
MadHatter,

6

L'approccio usuale per questo è usare un'impostazione a più livelli: sincronizzi uno o due server nella tua rete con il pool e poi li usi come fonte di tempo locale. Questi livelli sono chiamati strati nel gergo NTP.

Inoltre, pensaci: se lo fai come hai prescritto, non sarà davvero evidente, ma se 1000 siti della tua dimensione iniziano questo, finisci con 20k richieste per lo più inutili e ad un certo punto, diventa evidente.

Leggi http://en.wikipedia.org/wiki/Network_Time_Protocol


Ma considera il punto di vista alternativo: venti clienti in più su milioni di clienti esistenti non sono quasi nulla.
200_successo

2
Come ha detto, se tutti iniziano a pensare in questo modo ...
Marki,

Ma a che punto ti fermi? Pensa a tutti i dispositivi di classe Linksys forniti preconfigurati per l'uso pool.ntp.org. Sicuramente il traffico DNS supera il traffico NTP. Devi anche memorizzare nella cache DNS localmente? Anche il traffico DNS è probabilmente minuscolo rispetto al resto del consumo di larghezza di banda.
200_successo

@ 200_success: non vale la pena discutere, ma la maggior parte di questi dispositivi di "classe Linksys" memorizzano nella cache il traffico DNS localmente e interrogano il loro DNS ISP, che memorizza anche nella cache ...
Sven

1
Se Linksys spedisce dispositivi che si sincronizzano con ntp.pool.orgsono in violazione dei termini del pool ; se lo hanno fatto correttamente facendo domanda per una zona del fornitore (vedi link), ci si aspettava che anche loro contribuissero al progetto del pool in proporzione al loro carico (di nuovo, vedi link).
MadHatter,
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.