Desvio do timestamp do Unix

1

Eu tenho dois servidores Ubuntu que sincronizam seu timestamp para europe.pool.ntp.org todas as noites. Pouco antes de sincronizar, vejo uma diferença de 4 segundos entre os dois servidores. Um dos servidores parece desviar de 4 segundos em 24 horas.

  • É um problema de hardware ou software?
  • Existe uma maneira de corrigir isso, além de sincronizar várias vezes ao dia?
  • Se a única solução é sincronizar com mais frequência, há alguma falha no servidor?

Obrigado Olivier

    
por Antares 25.02.2011 / 01:12

3 respostas

2

A deriva do relógio é absolutamente uma parte normal do tempo mantendo-se em um computador, mas os detalhes sobre como ocorre uma strong variação podem ser uma função de muitas coisas diferentes. No caso de distorção "anormalmente grande", as razões podem variar de um relógio de hardware de baixa qualidade para um sistema com alta utilização. Portanto, manter-se sincronizado com um servidor de horário externo e canônico é um passo muito importante.

A melhor configuração é usar o ntpdate para definir o tempo de inicialização e, em seguida, usar o ntpd para compensar a distorção do clock. Ouvi reclamações no passado sobre o fato de o ntpd estar com fome de recursos (não consigo falar com exatidão, apenas que ouvi a queixa com frequência), mas as implementações modernas são quase imperceptíveis. A verdadeira elegância do ntpd está em dois pontos principais:

  • Ele monitorará a distorção do relógio com o passar do tempo para determinar o quão rapidamente seu relógio flutua e ajustará a frequência de pesquisa de acordo
  • Sempre que ocorrer uma sincronização, ele usará esses cálculos de desvio e levará lentamente o relógio de volta ao tempo

Isso tem a grande vantagem de minimizar o impacto das alterações de horário em seu sistema, por exemplo, você não terá situações como registros de data e hora em logs que aparecem para pular.

Eu recomendaria enfaticamente a configuração de vários servidores na sua configuração. Isso pode ser feito facilmente editando o arquivo /etc/ntp.conf e adicionando várias instruções do servidor. Por exemplo:

server ntp.ubuntu.com
server 0.pool.ntp.org
server 1.pool.ntp.org

Para algumas discussões sobre quais servidores NTP públicos estão disponíveis, é possível ver a pergunta - Servidores NTP públicos

Uma ressalva com o ntpd é a seguinte: se o seu tempo estiver muito longe, ele não corrigirá seu tempo. Para citar a man page (de acordo com o RHEL5.6)

In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock byhand. This causes ntpd to exit with a panic message to the system log.

É por isso que considero importante definir o relógio na hora da inicialização como importante. Enquanto a máquina está desligada, você está confiando no relógio do hardware e na bateria do CMOS para manter o tempo. Além disso, no caso de uma VM, reverter para instantâneo quase certamente acionará essa condição. Manter isso em mente é uma consideração importante se você estiver usando aplicativos sensíveis ao tempo, como a autenticação do Kerberos.

    
por 25.02.2011 / 02:41
2

É uma característica dos relógios de computador. Você pode ler um pouco sobre isso aqui e um pouco sobre < href="http://en.wikipedia.org/wiki/Clock_drift"> desvio do relógio na wikipedia.

Sincronizar com mais frequência é a melhor maneira de atacar isso. Eu normalmente sincronizo relógios a cada hora com um servidor local que sincroniza externamente uma vez por hora também. Você pode ter mais de um servidor para fornecer fallout para ntp .

Existem alguns ntp pools que podem ser usados sincronizados com relógios de alta resolução, como ntp.org .

    
por 25.02.2011 / 01:26
1

Apenas use o ntpd. Diminui as cargas nos servidores conversando com eles quando estão menos ocupados e têm menos latência. Ao correr continuamente, ele pode monitorar o relógio mais de perto e modelar a deriva com mais parâmetros do que apenas a velocidade.

    
por 25.02.2011 / 01:52