Único servidor NTP na rede isolada

Question

Eu tenho duas máquinas linux (A e B) em uma rede isolada. Eles devem estar sincronizados no tempo. A máquina A é alimentada de forma intermitente e deve atender a hora, pois ela está conectada a uma fonte de horário autoritativa (GPS). A Máquina B só é energizada se a máquina A estiver energizada, mas é um dispositivo Linux embutido e seu estado de energia mudará com freqüência. Nenhuma das máquinas tem acesso a outros sistemas. É uma rede fechada.

Eu entendo que isso é uma tarefa bastante difícil para o NTP, já que o NTP geralmente espera ter contato com vários servidores. Estou tendo problemas para fazer isso funcionar corretamente na Máquina B. A máquina sincroniza muito bem com o GPS, e a máquina B pode acessar a máquina A e até fazer consultas de tempo, mas a Máquina A não é confiável (talvez por si só?). Depois de uma hora de máquina A sólida, isso de repente mudou e a máquina B funcionou. No entanto, quando a máquina A desceu (e, portanto, a máquina B), a máquina B está novamente impossibilitada de encontrar uma boa sincronização de tempo.

Veja algumas informações do ntpdate. Por favor, note que mesmo quando o estrato da máquina A é 1, a operação falha com a mesma saída no final.

10.10.10.1: Server dropped: strata too high
server 10.10.10.1, port 123
stratum 16, precision -19, leap 11, trust 000
refid [10.10.10.1], delay 0.02614, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: d3a9bdc4.27ebb350  Thu, Jul 12 2012 21:19:00.155
transmit timestamp:  bc17c803.b42dfffe  Sat, Jan  1 2000  0:25:39.703
filter delay:  0.02625  0.02614  0.02618  0.02625 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
delay 0.02614, dispersion 0.00000
offset 395441600.451568

 1 Jan 00:25:39 ntpdate[677]: no server suitable for synchronization found

Meu palpite é que a máquina A simplesmente não confia em si mesma para o tempo de serviço. Depois de 51 minutos (pode ter acontecido antes, eu não sei) do tempo de atividade e com o seu relógio sincronizado com o GPS, a máquina A começou a servir a hora corretamente, e a máquina B a pegou. Eu preciso que isso aconteça mais cedo. Como, dentro de segundos, se possível.

Com as seguintes configurações (e muita espera), ele finalmente é bem-sucedido.

Máquina A ntp.conf:

server 127.127.28.0 prefer true minpoll 4 maxpoll 4
fudge 127.127.28.0 stratum 1 time1 0.420 refid GPS 

Máquina B ntp.conf:

server 10.10.10.1 prefer true minpoll 4 maxpoll 4

ntpq -c peers na Máquina B sem correção de tempo:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.10.10.1   .STEP.          16 u    9   16    0    0.000    0.000   0.000

ntp1 -c peers na Máquina B com correção de tempo:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.10.10.1   SHM(0)           2 u    7   16   17    0.669    2.597   1.808

Então, agora a questão é: como faço a Máquina A confiar em si mesma rapidamente?

Algumas saídas de depuração da Máquina A antes e depois da máquina B decidem que a Máquina A é boa o suficiente para usar ..

antes ..

~ # ntpq -c rv
associd=0 status=c418 leap_alarm, sync_uhf_radio, 1 event, no_sys_peer,
version="ntpd [email protected] Fri Feb 24 15:01:45 UTC 2012 (1)",
processor="armv7l", system="Linux/2.6.35.14", leap=11, stratum=2,
precision=-19, rootdelay=0.000, rootdisp=44.537, refid=SHM(0),
reftime=d3ab0053.43b44780  Fri, Jul 13 2012 20:15:15.264,
clock=d3ab0062.e7e03154  Fri, Jul 13 2012 20:15:30.905, peer=34819, tc=4,
mintc=3, offset=0.000, frequency=0.000, sys_jitter=3.853,
clk_jitter=36.492, clk_wander=0.000

depois ...

~ # ntpq -c rv
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd [email protected] Fri Feb 24 15:01:45 UTC 2012 (1)",
processor="armv7l", system="Linux/2.6.35.14", leap=00, stratum=2,
precision=-19, rootdelay=0.000, rootdisp=41.278, refid=SHM(0),
reftime=d3ab0063.43b37856  Fri, Jul 13 2012 20:15:31.264,
clock=d3ab006d.9ee53ec2  Fri, Jul 13 2012 20:15:41.620, peer=34819, tc=4,
mintc=3, offset=0.000, frequency=43.896, sys_jitter=0.762,
clk_jitter=36.953, clk_wander=0.000

    

Answer 1

O NTP deve funcionar bem. Veja algumas das opções para sincronização rápida na inicialização. Veja as opções burst e iburst para o sistema B. Veja a opção true para a fonte do relógio GPS.

Considere usar o relógio de hardware como fonte de tempo de backup em ambos os sistemas. Defina um sistema de estrato superior B. Algo como o seguinte deve funcionar:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Assista a saída de ntpq -c peers para ver quando você obtém uma fonte de relógio confiável. Normalmente, ntp deseja um número de respostas de uma fonte de tempo confiável antes de confiar nela. Isso é indicado pelo primeiro caractere em cada linha.

Embora o NTP goste de mais fontes, qualquer número ímpar de fontes de tempo dentro de um nível de estrato deve funcionar bem. Como você só tem dois servidores e um relógio GPS, a prioridade (estrato) das fontes deve aumentar de GPS, relógio no servidor A, relógio no servidor B. Aumentar o estrato entre cada um por três ou quatro níveis garantirá que as prioridades sejam respeitadas. / p>

EDIT: Se você tiver o servidor NTP busybox no servidor A, pode valer a pena instalar o pacote completo do servidor ntp. Entender o que está acontecendo com o servidor A deve ajudar muito a solucionar seu problema. Você precisará de pelo menos uma fonte de tempo confiável antes que o servidor B confie nela. Se ntpq -c peers não funcionar, você pode tentar ntpdc peers . Ambos os comandos permitem que você consulte outros hosts. Um peerstats log também pode ser útil.

No servidor B, use o ntpclient conforme documentado o busybox ntp howto para registrar o que está acontecendo nele

Os relógios devem estar razoavelmente próximos do horário correto, se os servidores não estiverem inativos por muito tempo. Se você precisar sincronizar os dois sistemas, isso deve ser suficiente. O GPS irá sincronizar o tempo com o mundo real.

'ntpd -q' é sincronizado rapidamente, mas sai (comportamento ntpdate). Ele precisa ser seguido por um comando ntpd sem a opção quit para ter sincronização contínua.

EDIT2: Eu verifiquei meu servidor e descobri que um dos servidores estava desligado por um segundo. Enquanto corrigia isso eu joguei com as configurações. iburst obtém um servidor confiável muito rapidamente. true assegurou que o driver do relógio era confiável se não houvesse várias outras fontes confiáveis. O relógio demorou um pouco mais de um minuto para ser confiável localmente e poder ser confiado remotamente.

Ao testar, você deve ser capaz de reiniciar o processo ntpd depois que ele for sincronizado e testar a velocidade com que as configurações funcionam. No caso acima, o Servidor B pode precisar ser reiniciado para testar a velocidade de sincronização. Ao monitorar ntpd alterações, eu uso uma linha como:

while ntpq -c peers localhost; do sleep 10; done

O nome do host e o tempo de sono são ajustados conforme necessário. Em alguns casos, eu encadeço duas ou mais linhas de comando ntpq no loop. Ao fazer isso, eu uso um comando echo e / ou data para fornecer uma indicação de onde os conjuntos de dados são alterados.