Usando servidores ntp públicos para backup no servidor local 1 do stratum

Question

Nos meus datacenters, tenho acesso a um servidor de estrato 1, mas configuro nossos servidores para usar servidores de pool ntp além dele. Meu pensamento principal era para backup no caso de nosso servidor local cair, mas estou preocupado que isso esteja realmente fazendo com que o tempo fique fora mais do que deveria ser.

Com base na saída ntpq abaixo, o ntpd está usando meu servidor de estrato local 1 e dois servidores públicos ("+") que têm um atraso muito ruim em seu cálculo. Tivemos relatos de que o tempo que estamos colocando em mensagens está errado e estou pensando em ter esses servidores públicos envolvidos fazendo com que a sincronização de tempo seja pior, estamos tentando ter um tempo preciso dentro de um milissegundo.

Editar: A pergunta que estou procurando é: ter esses servidores ntp públicos com alto jitter, o que faz com que minha precisão de tempo seja pior do que se eu configurasse o meu único servidor ntp de data center GPS local (192.168.20.4)?

$ ntpq -pn
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.20.4    .TSYN.           1 u   18   64  377    0.799    0.626   0.028
+67.219.95.113   128.138.141.172  2 u    3  256  377   45.266   -0.664   4.542
-50.116.55.65    209.51.161.238   2 u   46  256  377    2.979    0.876   0.217
+74.117.214.2    .GPS.            1 u  235  256  377   83.977   -4.988   0.106
-205.233.73.201  198.82.247.71    3 u  218  256  175    9.369    1.712   0.236

$ ntpq -c rl
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sat Dec 20 19:00:16 UTC 2014 (1)",
processor="x86_64", system="Linux/2.6.32-431.11.2.el6.x86_64", leap=00,
stratum=2, precision=-24, rootdelay=0.934, rootdisp=5.188,
refid=192.168.20.4,
reftime=d8f8f71b.08d0821a  Sat, May  9 2015 17:14:03.034,
clock=d8f8f775.c8d11ec4  Sat, May  9 2015 17:15:33.784, peer=62815,
tc=10, mintc=3, offset=0.351, frequency=-16.428, sys_jitter=1.168,
clk_jitter=0.182, clk_wander=0.006

    

Answer 1

Os deslocamentos do NTP que você está vendo são milissegundos e não segundos. Se você tiver problemas com as datas colocadas em seus cabeçalhos de e-mail, talvez sejam seus clientes. Se você conseguir uma cópia dos cabeçalhos, deverá ser fácil determinar onde está o problema. O cabeçalho Date: deve ter quase exatamente o mesmo tempo que o seu último cabeçalho Received: (primeiro servidor MTA para lidar com email). O NTP é muito mais preciso que é necessário para cabeçalhos de email. Se houver um problema, verifique se seus servidores estão sincronizados com seu servidor NTP.

Parece que você reuniu esses dados relativamente logo depois de reiniciar o seu cliente NTP. Isso é indicado pelo vale de pesquisa de 256. Ele deve subir para 1024 depois que as coisas se estabilizarem.

Seu servidor NTP está rastreando seu servidor local conforme indicado pelo "*" à esquerda. Dado seu estrato e jitter, é improvável que isso mude. Se houver um tempo significativamente diferente dos outros servidores, ele poderá ser despejado.

Dois outros servidores estão sendo usados para determinar se o relógio atual pode ser confiável. Estes são indicados por "+" à esquerda. Eles serão escolhidos nos servidores de menor status. Os outros dois não estão participando da votação, conforme indicado por "-" à esquerda. Os servidores de votação podem mudar ao longo do tempo com base na sua estabilidade como uma fonte para o seu servidor. O jitter desses servidores não deve causar nenhum problema, a menos que seu servidor local seja removido.

    

Answer 2

O NTP não consegue atingir essa precisão em seu jitter.

Você deveria dar uma olhada no PTP.

link

Se você quiser redundância, pode obter apenas dois relógios GPS.

Um jitter alto pode ser sintomático de uma rede (inter) congestionada, ou apenas a falta de algum sistema de modelagem / reserva de tráfego. Certifique-se de escolher um sistema NTP público que tenha um jitter razoavelmente baixo e estável e ajuste sua rede para tornar isso possível.