Por que é importante que os servidores tenham exatamente o mesmo tempo?

Question

Eu li várias vezes (embora não consiga encontrá-lo agora) que os datacenters fazem um grande esforço para garantir que todos os servidores tenham exatamente o mesmo tempo. Incluindo, mas não limitado 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?

    

Answer 1

Segurança

Em geral, os timestamps são usados em vários protocolos de autenticação para ajudar a evitar ataques de replay , onde um invasor pode reutilizar um token de autenticação que ele conseguiu roubar (por exemplo, farejando 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 tempo em sincronia entre o cliente e o servidor, não seria possível concluir a autenticação. (Essa restrição é removida nas versões mais recentes do MIT Kerberos, fazendo com que o solicitante eo KDC determinem o deslocamento entre seus relógios durante a autenticação, mas essas alterações ocorreram após o Windows Server 2012 R2 e levará algum tempo até que você o veja em um Windows Mas algumas implementações do 2FA provavelmente precisarão sempre de relógios sincronizados.)

Administração

Ter clocks 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, você normalmente pode trabalhar com uma tolerância de 1 segundo, o que o NTP fornecerá, mas, idealmente, você quer que os horários sejam sincronizados o mais próximo possível. O PTP, que fornece tolerâncias muito menores, pode ser muito mais caro para implementar.

    

Answer 2

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

    

Answer 3

Não só é importante do ponto de vista da administração, mas também é importante ter clocks sincronizados com a correlação no nível do aplicativo. Isso depende de como a solução é projetada, como os aplicativos em execução obtêm seu timestamp para quaisquer transações com as quais possam trabalhar. Vi a validação da transação falhar por causa de um aplicativo em execução em um servidor com muito deslocamento (cerca de 20 segundos no futuro) em comparação com os outros com os quais estava interagindo.

Além disso, se virtualizar, por exemplo, o servidor VMWare ESXi e o tempo da VM não estiver em sincronia com o hipervisor, uma ação como a 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 de tempo for grande o suficiente.

Eu não sei o que são tolerâncias reais, porque eu acho que depende muito do tipo de sistema que existe, mas eu acho que geralmente é possível manter os servidores no data center com menos de um segundo de diferença entre um ao outro.

    

Answer 4

Desde que você mencionou os segundos bissextos, deve-se notar que eles requerem tratamento particularmente difícil.

Eles geralmente são adicionados injetando um segundo como 23:59:60, isso é problemático se você estiver validando timestamps como 0-59 para os campos de minutos e segundos. A alternativa de repetir 23:59:59 para chegar a 2 segundos de duração não é muito melhor, já que isso irá mexer com qualquer coisa que seja sensível a um nível por segundo.

O Google chegou a uma boa solução há algum tempo que parece não ter sido amplamente adotada ainda. A solução deles foi aplicar um salto de "espalhamento" e dividir a mudança ao longo de um período de tempo, todo o processo sendo gerenciado por um servidor NTP. Eles publicaram um blog sobre o assunto em 2011, para leitura interessante e parece relevante para esta questão.

    

Answer 5

Sempre que registros de data e hora estiverem envolvidos, dispositivos des-sincronizados 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 anterior à consulta, possivelmente fazendo com que A ignore. / p>     

Answer 6

Concordo com todo o ponto acima. Quero jogar mais pensamentos
Alguns bancos de dados, como o Cassendra, dependem muito do registro de data e hora . É assim que lida com a concorrência.

Carimbo de data / hora diferente irá atrapalhar o banco de dados.