He leído varias veces (aunque no puedo encontrarlo ahora) que los centros de datos hacen un gran esfuerzo para asegurarse de que todos los servidores tengan exactamente la misma hora. Incluyendo, pero no limitado a preocuparse por los segundos bisiestos.

¿Por qué es tan importante que los servidores tengan el mismo tiempo? ¿Y cuáles son las tolerancias reales?

Seguridad

En general, las marcas de tiempo se usan en varios protocolos de autenticación para ayudar a prevenir ataques de repetición , donde un atacante puede reutilizar un token de autenticación que pudo robar (por ejemplo, olfateando la red).

La autenticación Kerberos hace exactamente esto, por ejemplo. En la versión de Kerberos utilizada en Windows, la tolerancia predeterminada es de 5 minutos.

Esto también lo utilizan varios protocolos de contraseña de un solo uso para la autenticación de dos factores, como Google Authenticator, RSA SecurID, etc. En estos casos, la tolerancia suele ser de unos 30-60 segundos.

Sin el tiempo sincronizado entre el cliente y el servidor, no sería posible completar la autenticación. (Esta restricción se elimina en las versiones más recientes de MIT Kerberos, al hacer que el solicitante y KDC determinen el desplazamiento entre sus relojes durante la autenticación, pero estos cambios ocurrieron después de Windows Server 2012 R2 y pasará un tiempo antes de que lo vea en Windows versión, pero algunas implementaciones de 2FA probablemente siempre necesiten relojes sincronizados).

Administración

Tener relojes sincronizados hace que sea más fácil trabajar con sistemas dispares. Por ejemplo, correlacionar las entradas de registro de varios servidores es mucho más fácil si todos los sistemas tienen el mismo tiempo. En estos casos, generalmente puede trabajar con una tolerancia de 1 segundo, que proporcionará NTP, pero idealmente desea que los tiempos estén tan sincronizados como sea posible. PTP, que proporciona tolerancias mucho más estrictas, puede ser mucho más costoso de implementar.

Principalmente, es para que pueda correlacionar incidentes de registros en diferentes dispositivos. Suponga que tiene un incidente de seguridad en el que alguien accede a su base de datos a través de su servidor web: desea que las marcas de tiempo en su firewall, su equilibrador de carga, su servidor web y su servidor de base de datos coincidan para que pueda encontrar los registros en cada dispositivo que se relacionan con el incidente. Idealmente, le gustaría que todo esté dentro de unos pocos milisegundos. Y debe estar sincronizado con el tiempo externo real, para que también pueda correlacionar sus registros con registros de terceros si fuera necesario.

No solo es importante desde la perspectiva de la administración, sino que tener relojes sincronizados también puede ser importante desde la correlación a nivel de aplicación. Esto depende de cómo se diseñe la solución, cómo las aplicaciones que se ejecutan obtienen su marca de tiempo para cualquier transacción con la que puedan trabajar. He visto fallar la validación de transacciones debido a una aplicación que se ejecuta en un servidor con demasiado desplazamiento (fue de aproximadamente 20 segundos en el futuro) en comparación con los otros con los que estaba interactuando.

Además, si se virtualiza en, por ejemplo, el servidor VMWare ESXi, y el tiempo de la VM no está sincronizado con el del hipervisor, entonces una acción como vmotion puede volver a sincronizar el reloj de la VM con los hipervisores y esto a su vez puede conducir a resultados impredecibles si la diferencia horaria es lo suficientemente grande

No sé cuáles son las tolerancias reales, porque creo que depende mucho de qué tipo de sistemas hay, pero creo que, en términos generales, es posible mantener los servidores en el centro de datos con una compensación de menos de un segundo entre sí.

Como mencionó los segundos bisiestos, debe tenerse en cuenta que requieren un manejo particularmente difícil.

Por lo general, se agregan inyectando un segundo como 23:59:60, esto es problemático si está validando marcas de tiempo como 0-59 para los campos de minutos y segundos. La alternativa de repetir 23:59:59 para que dure 2 segundos no es mucho mejor, ya que eso afectará cualquier cosa que sea sensible al tiempo hasta un nivel por segundo.

En realidad, Google ideó una buena solución hace un tiempo que parece que aún no se ha adoptado ampliamente. Su solución fue aplicar una "mancha" de salto y dividir el cambio durante un período de tiempo, todo el proceso siendo administrado por un servidor NTP. Publicaron un blog al respecto en 2011, es una lectura interesante y parece relevante para esta pregunta.

Siempre que intervienen marcas de tiempo, los dispositivos desincronizados pueden crear incoherencias lógicas, como: A envía una consulta a B, y la respuesta de B viene con una marca de tiempo anterior a la de la consulta, lo que posiblemente haga que A la ignore.

Estoy de acuerdo con todo el punto anterior. Quiero pensar más.
Algunas bases de datos como Cassendra dependen en gran medida de la marca de tiempo . Esa es la forma en que trata la concurrencia.

Diferentes marcas de tiempo arruinarán la base de datos.