Li várias vezes (embora não possa encontrá-lo agora) que os datacenters envidam grandes esforços para garantir que todos os servidores tenham exatamente o mesmo tempo. Incluindo, mas não se limitando a, se preocupar com segundos bissextos.

Por que é tão importante que os servidores tenham o mesmo tempo? E quais são as tolerâncias reais?

Segurança

Em geral, os carimbos de data e hora são usados ​​em vários protocolos de autenticação para ajudar a impedir ataques de reprodução , onde um invasor pode reutilizar um token de autenticação que ele conseguiu roubar (por exemplo, cheirando a rede).

A autenticação Kerberos faz exatamente isso, por exemplo. Na versão do Kerberos usada no Windows, a tolerância padrão é de 5 minutos.

Isso também é usado por vários protocolos de senha descartáveis ​​usados ​​para autenticação de dois fatores, como Google Authenticator, RSA SecurID, etc. Nesses casos, a tolerância geralmente é de 30 a 60 segundos.

Sem o momento sincronizado entre cliente e servidor, não seria possível concluir a autenticação. (Essa restrição é removida nas versões mais recentes do MIT Kerberos, solicitando que o solicitante e o KDC determinem o deslocamento entre os relógios durante a autenticação, mas essas alterações ocorreram após o Windows Server 2012 R2 e demorará um pouco para você vê-lo no Windows Mas algumas implementações do 2FA provavelmente sempre precisarão de relógios sincronizados.)

Administração

Ter relógios sincronizados facilita o trabalho com sistemas diferentes. Por exemplo, correlacionar entradas de log de vários servidores é muito mais fácil se todos os sistemas tiverem o mesmo tempo. Nesses casos, geralmente você pode trabalhar com uma tolerância de 1 segundo, que o NTP fornecerá, mas, idealmente, você deseja que os horários sejam o mais sincronizados possível. O PTP, que fornece tolerâncias muito mais rígidas, pode ser muito mais caro de implementar.

Principalmente, é para que você possa correlacionar incidentes de logs em diferentes dispositivos. Suponha que você tenha um incidente de segurança em que alguém acesse o banco de dados por meio do servidor da web - você deseja que os carimbos de data e hora no firewall, no balanceador de carga, no servidor da web e no servidor de banco de dados correspondam, para que você possa encontrar os registros em cada dispositivo que se relacionam com o incidente. Idealmente, você gostaria que tudo estivesse dentro de alguns milissegundos. E ele precisa estar sincronizado com o horário externo real, para que você também possa correlacionar seus logs com logs de terceiros, se isso for necessário.

Não só é importante do ponto de vista da administração, mas também é importante ter relógios sincronizados, além da correlação no nível do aplicativo. Isso depende de como a solução foi projetada, de como os aplicativos em execução obtêm seu carimbo de data / hora para qualquer transação com a qual possam trabalhar. Vi a validação da transação falhar por causa de um aplicativo em execução em um servidor com muito deslocamento (demoraria cerca de 20 segundos no futuro) comparado aos outros com os quais estava interagindo.

Além disso, se a virtualização no servidor VMWare ESXi, por exemplo, e o tempo da VM não estiverem sincronizados com o do hipervisor, uma ação como vmotion poderá sincronizar novamente o relógio da VM com os hipervisores e isso, por sua vez, pode levar a resultados imprevisíveis se a diferença horária for grande o suficiente.

Não sei quais são as tolerâncias reais, porque acho que depende muito de que tipo de sistemas existem, mas acho que, em termos gerais, é possível manter os servidores no datacenter com menos de um segundo de diferença entre si.

Como você mencionou os segundos bissextos, observe que eles exigem um manuseio particularmente difícil.

Eles geralmente são adicionados injetando um segundo como 23:59:60, isso é problemático se você estiver validando carimbos de data e hora como 0-59 para os campos de minutos e segundos. A alternativa de repetir 23:59:59 para durar 2 segundos não é muito melhor, pois isso interfere em qualquer coisa que seja sensível ao tempo até um nível por segundo.

O Google realmente encontrou uma boa solução há algum tempo, que parece não ter sido amplamente adotada ainda. A solução deles foi aplicar um salto "difuso" e dividir a alteração por um período de tempo, todo o processo sendo gerenciado por um servidor NTP. Eles publicaram um blog sobre isso em 2011, contribuem para uma leitura interessante e parecem relevantes para essa questão.

Sempre que houver registro de data e hora, os dispositivos dessincronizados podem criar incoerências lógicas, como: A envia uma consulta para B e a resposta de B vem com um registro de data e hora mais cedo que o da consulta, possivelmente fazendo com que A o ignore.

Eu concordo com todo o ponto acima. Quero pensar mais.
Alguns bancos de dados como o Cassendra dependem muito do carimbo de data / hora . É assim que se lida com a simultaneidade.

Um carimbo de data / hora diferente atrapalha o banco de dados.