Ho letto più volte (anche se non riesco a trovarlo in questo momento) che i data center si impegnano molto per assicurarsi che tutti i server abbiano lo stesso orario. Compreso, ma non limitato a preoccuparsi dei secondi bisestili.

Perché è così importante che i server abbiano lo stesso tempo? E quali sono le tolleranze effettive?

Sicurezza

In generale, i timestamp sono utilizzati in vari protocolli di autenticazione per aiutare a prevenire gli attacchi di rigiocabilità , in cui un utente malintenzionato può riutilizzare un token di autenticazione che è stato in grado di rubare (ad esempio, annusando la rete).

L'autenticazione Kerberos fa esattamente questo, per esempio. Nella versione di Kerberos utilizzata in Windows, la tolleranza predefinita è 5 minuti.

Questo è anche usato da vari protocolli password monouso usati per l'autenticazione a due fattori come Google Authenticator, RSA SecurID, ecc. In questi casi la tolleranza è generalmente di circa 30-60 secondi.

Senza la sincronizzazione tra client e server, non sarebbe possibile completare l'autenticazione. (Questa restrizione viene rimossa nelle versioni più recenti di MIT Kerberos, facendo in modo che il richiedente e il KDC determinino l'offset tra i loro orologi durante l'autenticazione, ma queste modifiche si sono verificate dopo Windows Server 2012 R2 e passerà un po 'di tempo prima di vederlo in Windows versione. Ma alcune implementazioni di 2FA avranno probabilmente sempre bisogno di orologi sincronizzati.)

Amministrazione

La sincronizzazione degli orologi semplifica il lavoro con sistemi diversi. Ad esempio, correlare le voci di registro da più server è molto più semplice se tutti i sistemi hanno lo stesso tempo. In questi casi di solito puoi lavorare con una tolleranza di 1 secondo, che NTP fornirà, ma idealmente vuoi che i tempi siano strettamente sincronizzati quanto ti puoi permettere. Il PTP, che offre tolleranze molto più strette, può essere molto più costoso da implementare.

Principalmente, è così che è possibile correlare gli incidenti dai registri su diversi dispositivi. Supponiamo che tu abbia un incidente di sicurezza in cui qualcuno accede al tuo database attraverso il tuo server web: vuoi che i timestamp sul tuo firewall, il tuo bilanciamento del carico, il tuo server web e il tuo server di database coincidano in modo da poter trovare i registri su ciascun dispositivo che riguardano l'incidente. Idealmente, vorresti che tutto fosse entro pochi millisecondi. Inoltre, deve essere sincronizzato con l'ora esterna effettiva, in modo che sia possibile correlare i registri con i registri di terze parti, se necessario.

Non solo è importante dal punto di vista amministrativo, ma avere gli orologi sincronizzati può essere importante anche dalla correlazione a livello di applicazione. Questo dipende da come viene progettata la soluzione, da come le applicazioni in esecuzione ottengono il loro timestamp per qualsiasi transazione con cui potrebbero funzionare. Ho visto la convalida della transazione fallire a causa di un'applicazione in esecuzione su un server con un offset eccessivo (era di circa 20 secondi in futuro) rispetto alle altre con cui interagiva.

Anche se la virtualizzazione, ad esempio sul server VMWare ESXi, e il tempo della VM non sono sincronizzati con quello dell'hypervisor, un'azione come vmotion potrebbe risincronizzare l'orologio della VM con gli hypervisor e questo a sua volta può portare a risultati imprevedibili se la differenza di tempo è abbastanza grande.

Non so quali siano le tolleranze effettive, perché penso che dipenda molto dal tipo di sistemi esistenti, ma in generale penso che sia possibile mantenere i server nel datacenter con un offset di meno di un secondo l'uno rispetto all'altro.

Dato che hai citato i secondi bisestili, va notato che richiedono una gestione particolarmente difficile.

Di solito vengono aggiunti iniettando un secondo come 23:59:60, questo è problematico se si stanno convalidando i timestamp come 0-59 per i campi minuti e secondi. L'alternativa di ripetere 23:59:59 per farla durare 2 secondi non è molto meglio dal momento che guasterà tutto ciò che è sensibile al tempo fino a un livello al secondo.

Google in realtà ha trovato una buona soluzione qualche tempo fa che sembra non essere stata ancora ampiamente adottata. La loro soluzione era quella di applicare una "macchia" di salto e dividere la modifica per un periodo di tempo, l'intero processo è gestito da un server NTP. Hanno pubblicato un blog a riguardo nel 2011, rende la lettura interessante e sembra rilevante per questa domanda.

Ogni volta che sono coinvolti i timestamp, i dispositivi non sincronizzati possono creare incoerenze logiche, come ad esempio: A invia una query a B e la risposta di B arriva con un timestamp precedente a quello della query, facendo sì che A la ignori.

Sono d'accordo con tutto il punto sopra. Voglio fare più pensieri.
Alcuni database come Cassendra fanno molto affidamento sul timestamp . Questo è il modo in cui affronta la concorrenza.

Timestamp diversi rovinano in modo complicato il database.