Configurando um servidor NTP do estrato local 2

Question

Estou tentando configurar o NTP em uma rede local que não possui (e nunca irá) conexão com a Internet. A principal prioridade é que as máquinas na rede sejam sincronizadas umas com as outras, mesmo que o tempo de sincronização não seja 100% preciso.

Também temos um requisito para usar uma hierarquia de NTP para replicar a configuração de um sistema implantado. O que eu quero fazer é ter uma hierarquia de máquinas como esta:

Moon  (Main Server running Windows) (10.1.3.10)
|____Earth   (Linux x64 client) (10.1.3.1)
|____Mars    (Linux x64 client) (10.1.3.2)
|____Saturn  (Linux x64 client) (10.1.3.3)
|____RackCard23   (Linux x64 client and server to the two machines below)  (10.1.3.23)
     |___RackCard21   (Linux x64 client) (10.1.4.21)
     |___RackCard22   (Linux x64 client) (10.1.4.22)

Note que os RackCards possuem duas portas ethernet, uma conectada à rede 10.1.3.x e outra na rede 10.1.4.x. O RackCard23, que sincroniza o servidor mestre Moon, fará isso na rede 10.1.3.x e o RackCard22 / 23 se conectará ao RackCard23 na rede 10.1.4.x. Isso porque eu não quero que o RackCards22 / 23 deixe sua rede para sincronizar o tempo e porque ele replica um sistema implementado final.

Até agora, consegui obter tudo o que deveria, sincronizando o Moon para sincronizar corretamente (incluindo o RackCard23).

Mas estou tendo dificuldade em fazer com que RackCard22 e 23 sincronizem o RackCard23.

[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge   127.127.1.0 stratum 2   #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge   127.127.0.1 stratum 2

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery

#Attempt to get to act as an NTP Server
broadcast 10.1.4.255

restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap

Esta é a saída do ntptrace:

[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030

Como você pode ver, a máquina está se reportando como um servidor stratum 16, apesar de ter sido sincronizado com um servidor "stratum 1" (Lua):

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate [email protected] Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time:    cfc99402.e010624d  Mon, Jun 21 2010  8:32:18.875
originate timestamp: cfc9dfad.48000000  Mon, Jun 21 2010 13:55:09.281
transmit timestamp:  cfc9dfad.47e27179  Mon, Jun 21 2010 13:55:09.280
filter delay:  0.04155  0.04155  0.04137  0.04135
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
         0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394

21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec

A configuração dos clientes (RackCard21 / 22) é assim:

[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer

server 127.127.1.0
fudge   127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# restrict 127.0.0.1

restrict None mask 255.255.255.255 nomodify notrap noquery

E o ntptrace fornece isso:

[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate [email protected] Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: cfc9dfef.12b79516  Mon, Jun 21 2010 13:56:15.073
transmit timestamp:  cfc9e1e2.aeae7d56  Mon, Jun 21 2010 14:04:34.682
filter delay:  0.02573  0.02571  0.02568  0.02568
         0.00000  0.00000  0.00000  0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
         0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286

21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found

Portanto, não é possível encontrar um servidor adequado, porque o servidor que estou tentando usar está relatando que é um servidor de estrato 16 (que, acredito, significa não sincronizado). Isso ocorre apesar do fato de estar sincronizado.

Então, eu preciso de alguma forma fazer do RackCard23 um estrato mais alto (idealmente o estrato 2). Como faço para fazer isso?

Qualquer ajuda é muito apreciada, já que tenho tentado fazer isso funcionar por alguns dias!

EDITAR:

Oi Christopher,

Eu tenho reiniciado o ntpd, sim;)

Todas as caixas de linux estão rodando o CentOS 5.4.

Esta é a saída dos comandos que você sugeriu. Em primeiro lugar do servidor:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  34566 127.0.0.1              1 7 2      0      0       0
10.1.4.21                123 10.1.4.23              5 3 4    180      5       1
10.1.4.22                123 10.1.4.23              7 3 4      0      2       2

E, em seguida, do cliente:

[root@RackCard21]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.4.23       .INIT.          16 u   10   16    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   44   64    1    0.000    0.000   0.001

    

Answer 1

Como Chris mencionou, o stratum 16 indica que um servidor não foi realmente sincronizado com um servidor. Só para ter certeza, você reiniciou os serviços ntp, certo? ( service ntpd restart ) Eu não estou tentando insinuar você perder as coisas fáceis, mas eu sempre faço!

Você pode postar a saída de mais alguns comandos para ajudar no diagnóstico?

ntpq -p no cliente & servidor. Deve mostrar quais servidores ele configurou, bem como estatísticas para esses servidores.
ntpdc -c monlist no servidor. Deve mostrar os clientes conectados.

Além disso, como você não mencionou um sistema operacional, estou executando com comandos no estilo RHEL. Deixe-me saber se você tem algo diferente.

EDITAR depois de mais informações
OK, vendo a sua saída, aqui está o seu problema: Você não tem um servidor de estrato 1. Na verdade, a "Lua" está usando o relógio local. Está se reportando como um servidor de estrato 16. Para sua referência, um servidor Stratum1 teria um GPS local ou um relógio atômico. Você tem um desses? Caso contrário, Moon precisa sincronizar seu relógio com OUTRO servidor ntp. Se não tiver acesso à rede, você precisará falsificar seu estrato. (Isso requer que você não se importe muito com o tempo 'verdadeiro'. O que você não quer, mas qualquer outra pessoa que esteja lendo isso deve notar isso.)

Em Lua, adicione a seguinte linha ao seu arquivo ntp.conf: fudge 127.127.1.0 stratum 10 . Isso fará com que ele relate seu clock local como stratum 10. O que fará com que todos os outros servidores o usem em seu clock local estrato 16.

- Christopher Karel

    

Answer 2

Pode estar fora de tópico, um servidor local Stratum 2 requer conexão com um servidor Stratum 1 e dentro de sua rede isolada, você não tem um.

Você pode obter um módulo GPS barato e um Raspberry Pi, um computador de placa única com consumo mínimo de energia e ampla capacidade de interface. Conecte seu módulo GPS ao Raspberry Pi e junte o Pi em sua rede, com o software apropriado, ele pode ser o seu servidor Stratum 1 NTP que o seu servidor Stratum 2 ou desde que você o tenha dentro de sua rede, sincronize o tempo com ele. / p>     

Answer 3

O NTPd definirá seu próprio estrato de acordo com:

1. Se o desvio do relógio local não tiver sido avaliado, defina o estrato como 16. Esse processo leva cerca de 15 minutos em um servidor normal, após o qual prossegue para a próxima etapa.
2. Conecte-se a todos os servidores de horário configurados, avalie quais deles são confiáveis (e, portanto, preferidos), defina o estrato local para o estrato do servidor mais confiável e mais um. Portanto, se o servidor confiável mais baixo encontrado for 1, o local será 2.

(Esta não é necessariamente a ordem dos eventos, mas a ordem na qual eles são processados com o propósito de definir o estrato local).
(Além disso, o estrato 16 não significa necessariamente que ele não esteja sincronizado).

    

Answer 4

Como uma espécie de lado, incluirei algumas análises de sua saída ntpq. Apenas para ajudar na solução de problemas genéricos no futuro, para você e para os outros.

Primeiro, do seu servidor:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

A primeira coluna indica os dois servidores para os quais esta máquina está configurada para sincronizar. Notável é a falta de * ou + que indicaria um par sincronizado ou candidatos secundários. Isso significa que o seu servidor não estará usando as entradas aqui, mas pelo menos está checando com elas.

A coluna três, "st", indica o estrato desses servidores. Nesse caso, isso indica que ambas as máquinas estão usando o relógio local. (estrato padrão de 16) As últimas três colunas indicariam o quão longe os dois relógios estão. Seja em um valor de "diferença de segundos nos relógios" ou na latência entre as duas máquinas, com a diferença nessa latência. Aqui, números mais altos são piores.

A razão para entradas não-sincronizadas como essa pode depender de alguns fatores: Se o offset em clocks for muito, então o ntp nem tentará, já que introduziria um salto muito grande na hora local. Se o jitter ficar ruim, o cliente fará a dessincronização até que as coisas se estabilizem. (Isso geralmente é temporário e, ainda assim, recorrente) Como alternativa, como no seu caso, se os servidores configurados tiverem valores de estrato iguais ou superiores, indicando que são menos confiáveis como fontes de tempo, o cliente não os usará.

- Christopher Karel