Aspetti da considerare quando si eseguono server NTP pubblici

Quindi, recentemente mi sono reso conto che da quando ho 3 orologi GPS nella mia rete, potrei, tecnicamente, restituire un po 'e servire il tempo al resto del mondo. Finora non ho visto alcun lato negativo di queste idee, ma ho le seguenti domande;

1. Posso virtualizzare questo? Non ho intenzione di spendere soldi e tempo per sostenere l'hardware per questo, quindi la virtualizzazione è un must. Dato che i server avranno accesso a tre fonti di strato 1, non riesco a vedere come questo possa essere un problema se la configurazione di ntpd è corretta

2. Che tipo di traffico vede normalmente un server NTP pubblico (parte di pool.ntp.org)? E di quali grandi VM ho bisogno per questo? ntpd non dovrebbe essere troppo dispendioso in termini di risorse per quanto posso raccogliere, ma preferirei sapere in anticipo.

3. Quali aspetti di sicurezza ci sono? Sto pensando di installare ntpd su due VM nella DMZ, consentire solo ntp in entrata attraverso il FW e solo ntp in uscita dalla DMZ ai server ntp interni. Sembrano esserci anche alcune impostazioni ntp consigliate in base alla pagina del pool NTP, ma sono sufficienti? https://www.ntppool.org/join/configuration.html

4. Raccomandano di non avere il driver dell'orologio LOCAL configurato, equivale a rimuovere la configurazione dell'origine temporale LOCAL dai file di configurazione?

5. Qualcos'altro da considerare?

Innanzitutto, buon per te; è una cosa utile e di buon umore da fare. Detto questo, e dato il tuo chiarimento che stai pianificando di creare una o più macchine virtuali DMZ che si sincronizzeranno e renderanno pubblicamente disponibile il tempo dai tuoi tre server stratum-1 (interni) abilitati per GPS Meinberg:

1. Modifica : la virtualizzazione viene periodicamente discussa nell'elenco dei pool ; uno recente è stato a luglio 2015, che può essere seguito a partire da questa email . Chiedi a Bjørn Hansen, il responsabile del progetto, ha postato sul thread e non ha parlato contro la virtualizzazione. Chiaramente un certo numero di operatori di server di pool sta virtualizzando in questo momento, quindi non credo che nessuno ti sparerà per questo, e come un poster chiarisce, se i tuoi server non sono affidabili il sistema di monitoraggio del pool li rimuoverà semplicemente dal piscina. KVM sembra essere la tecnologia di virtualizzazione preferita; Non ho trovato nessuno che utilizza specificamente VMWare, quindi non posso commentare quanto sia "onesta" una virtualizzazione. Forse il miglior riassunto sull'argomento ha detto

   I miei server pool sono virtualizzati con KVM sui miei host KVM personali. Il monitoraggio dice che il server è abbastanza preciso e fornisce un tempo stabile per gli ultimi 2-3 anni. Ma non installerei un server pool su un server virtuale noleggiato da un altro provider.

2. Questo è il numero medio giornaliero di client distinti al secondo che vedo sul mio server pool (che si trova nel Regno Unito, in Europa e zone globali) nell'ultimo anno:

   

   Ciò non impone quasi alcun carico di sistema rilevabile ( ntpdsembra utilizzare tra l'1% e il 2% di una CPU, il più delle volte). Si noti che, ad un certo punto durante l'anno, il carico ha raggiunto il picco brevemente a quasi un migliaio di clienti al secondo (massimo: 849,27); Controllo il carico eccessivo e gli allarmi non si sono tutti attivati, quindi posso solo notare che anche quel livello di carico non ha causato problemi, anche se brevemente.

3. Le configurazioni consigliate dal progetto sono le migliori pratiche e funzionano per me. Uso anche iptablesper limitare i client a due pacchetti in entrata in una finestra di dieci secondi (è incredibile quanti clienti maleducati ci sono là fuori, che pensano che dovrebbero essere liberi di scoppiare per impostare rapidamente i propri orologi).

4. Oppure rimuovi tutte le righe che fanno riferimento agli indirizzi dei server che iniziano con 127.127.

5. Le linee guida sulle migliori pratiche raccomandano anche più di tre orologi, quindi potresti voler scegliere un paio di altri server pubblici o server pool specifici, oltre ai tuoi tre server stratum-1.

   Vorrei anche notare che se stai pianificando di collocare entrambe queste macchine virtuali sullo stesso hardware host, probabilmente dovresti semplicemente eseguire quella, ma raddoppiare la larghezza di banda dichiarata nel pool (ad esempio, accettare il doppio delle query che altrimenti ).

In primo luogo, congratulazioni per una domanda NTP che è materiale non facciale. :-) Ho incluso alcuni grafici in fondo a questo post per darti un'idea delle cose. La VM in questione è impostata su 100 Mbps nel pannello di controllo del pool ed è nel Regno Unito, in Europa e nei pool globali.

1. Penso che MadHatter abbia affrontato bene questo aspetto: la virtualizzazione dovrebbe andare bene. Come dici tu, se si stanno alimentando dal tuo strato 1 connesso al GPS, dovrebbero essere ragionevolmente solidi. Nella mia esperienza, le VM tendono ad essere un po 'più nervose del bare metal in termini di frequenza (vedi grafico sotto), ma è quello che ti aspetteresti: hanno a che fare con un livello di emulazione del clock (si spera piuttosto efficiente) e potenzialmente rumoroso vicinato. Se preferisci non vedere quel tipo di nervosismo, potresti usare server più vecchi o desktop inutilizzati come DMZ stratum 2s.

2. Questa VM è 1 core, 2 GB di RAM, con Ubuntu 16.04 LTS, virtualizzata in OpenStack (hypervisor KVM). Come puoi vedere, la RAM è un po 'esagerata.

3. Le impostazioni consigliate, incluso il fatto che non sia configurato il driver locale, sono quelle predefinite in Ubuntu 16.04. Sto correndo molto vicino alla configurazione stock, oltre alla peer list.

4. (vedi sopra)

5. Probabilmente inizierei la larghezza di banda sul lato basso e aumenterei la larghezza di banda dopo averla monitorata per un po '. Se le tue VM sono tutte vicine tra loro e vicine al tuo strato 1 in termini di latenza di rete, probabilmente avrei tutte le VM che parlano con tutti gli strati 1, e probabilmente li scrutino tra loro e attiva anche la modalità orfana.

Ecco i grafici: coprono tutti lo stesso periodo di circa 3 settimane, ad eccezione di quello di rete, che ha avuto un paio di picchi dovuti ai backup. Quando c'erano i picchi di rete non riuscivo nemmeno a vedere il normale traffico NTP, quindi ho ingrandito un po 'per mostrare il solito sfondo.

Offset di sistema della frequenza di rete della memoria della CPU

Alcune cose da considerare con NTP

Ci sono già tante buone risposte qui. Sto solo aggiungendo alcuni pensieri per completezza in base alle mie esperienze.

Suggerirei di abilitare la registrazione NTP e gli skew e le correzioni dell'orologio grafico su bare metal vs. VM in quanto riguarda quella discussione se ciò è un problema. Non credo che questo possa essere generalizzato facilmente poiché l'hardware e la configurazione variano tra le implementazioni. Potrebbe essere meglio ottenere i tuoi numeri su quello.

Ho sempre suggerito alla gente di scegliere ruoli di sistemi di server o dispositivi di rete che hanno un tempo di CPU abbastanza costante e che non sono kernel senza tick o che hanno abilitato le modalità di risparmio energetico. Evita in particolare i demoni di linea cpuspeed o speed govenors o il risparmio energetico avanzato sui server NTP, anche se sono solo strato 2 nella tua fattoria. Un po 'di stabilità può essere ottenuta non andando mai più in profondità di C-State 1, ma il consumo di energia aumenterà.

Cerco anche di assicurarmi che le persone scelgano una manciata di server di livello 1 che si trovano a meno di 40 ms dal bordo della loro rete, quindi li dividono su tutti i server NTP periferici e mi assicuro che non ci siano 2 server dietro lo stesso SNAT nella tua rete allo stesso server stratum 1. Sulla stessa linea di burst, non è saggio avere più server dietro lo stesso SNAT usando gli stessi server upstream, poiché sembrerà che tu abbia abilitato il burst anche quando non lo hai fatto.

Si dovrebbe sempre onorare il kodpacchetto dal server upstream e disporre di strumenti di monitoraggio che controllino gli offset di tempo e la raggiungibilità dei server upstream.

Si potrebbe prendere in considerazione con le proprie fonti di tempo precisi in alcuni dei vostri data center a pari con o ripiegare nel caso improbabile che il GPS SA è abilitata dai militari. Ci sono apparecchi economici appositamente per questo. Anche se ci si trova in un ambiente "a gabbia" e non si dispone del proprio datacenter, alcune strutture di hosting potrebbero adattarlo.

Consulta il documento di cronometraggio vmware all'indirizzo http://www.vmware.com/pdf/vmware_timekeeping.pdf

L'esecuzione di un demone NTP in una VM non è probabilmente una buona idea, soprattutto se hai bisogno di tempo affidabile.

Ecco un buon KB di VMware con parametri di configurazione effettivi per diverse distribuzioni di Linux

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427