Configurando um servidor NTP local do estrato 2

9

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

Também temos o requisito de usar uma hierarquia 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)

Observe 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 com 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 ocorre porque não quero que os RackCards22 / 23 saiam da rede para sincronizar o tempo e porque replicam um sistema final implantado.

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

Mas estou tendo dificuldade em sincronizar o RackCard22 e o 23 com 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 do estrato 16, apesar de ter sido sincronizada com um servidor do "estrato 1" (Moon):

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o 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 4.2.2p1@1.1570-o 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, ele não consegue encontrar um servidor adequado, porque o servidor que estou tentando usar está relatando que é um servidor estrato 16 (que eu acredito que significa não sincronizado). Isso apesar do fato de estar sincronizado.

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

Qualquer ajuda é muito apreciada, pois tenho tentado fazê-lo funcionar há dias!

EDITAR:

Olá Christopher,

Eu tenho reiniciado o ntpd, sim;)

Todas as caixas Linux estão executando o CentOS 5.4.

Esta é a saída dos comandos que você sugeriu. Primeiramente 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 então 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

ntp

— fwgx
fonte

Se você não tem uma conexão com a Internet, qual é a sua fonte de tempo, eu perdi em algum lugar?

— dbasnett

A fonte do tempo realmente não importa, não estamos buscando um tempo 100% exato. O que queremos é que todas as máquinas estejam sincronizadas umas com as outras, mesmo que isso signifique que seus horários sejam 10 ou mais minutos do que o tempo real. Portanto, estamos usando uma máquina aleatória na rede como uma fonte de tempo mestre - ou seja, apenas seu relógio interno. O que sabemos e aceitamos não é confiável, mas enquanto as coisas sincronizarem, tudo bem para nós. No sistema real implantado, estaremos sincronizando com uma fonte de tempo em outro sistema sobre o qual não temos controle, o que pode ou não ser mais preciso.

— fwgx

5

Como Chris mencionou, o estrato 16 indica que um servidor realmente não foi sincronizado com um servidor. Só para ter certeza, você reiniciou os serviços NTP, certo? ( service ntpd restart) Não estou tentando insinuar que você sente falta das coisas fáceis, mas sempre sinto!

Você pode postar a saída de mais alguns comandos para ajudar a diagnosticar?

ntpq -pno cliente e servidor. Deve mostrar quais servidores ele configurou, bem como estatísticas para esses servidores.
ntpdc -c monlistno 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 após mais informações
OK, vendo sua saída, eis o seu problema: você não possui um servidor do estrato 1. De fato, a "Lua" está usando o relógio local. Ele está se reportando como um servidor estrato 16. Para sua referência, um servidor Stratum1 teria um GPS ou relógio atômico local. Você tem um desses? Caso contrário, o Moon precisa sincronizar seu relógio com outro servidor ntp. Se não tiver acesso à rede, você precisará alterar o estrato. (Isso exige que você não se importe muito com o tempo 'verdadeiro'. O que você não faz, mas qualquer outra pessoa lendo isso deve observar isso.)

Na Lua, adicione a seguinte linha ao seu arquivo ntp.conf: fudge 127.127.1.0 stratum 10. Isso fará com que ele reporte o relógio local como estrato 10. O que fará com que todos os outros servidores o usem no relógio local do estrato 16.

--Christopher Karel

— Christopher Karel
fonte

adicionou resultados ao principal post da pergunta.

— Fwgx

concordando com Christopher. uma série de equívocos sobre Strata ntp.org/ntpfaq/NTP-s-algo.htm

— dbasnett

3

Pode estar fora de tópico, um servidor Stratum 2 local requer conexão com um servidor Stratum 1 e, dentro da sua rede isolada, você não possui 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 à sua rede, com o software adequado, pode ser o servidor NTP Stratum 1 que o servidor Stratum 2 ou, se você o tiver dentro da rede em qualquer computador, sincronize com ele.

2

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

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

(Essa não é necessariamente a ordem dos eventos, mas a ordem na qual eles são processados com a finalidade de definir o estrato local.)
(Além disso, o estrato 16 não significa necessariamente que não está sincronizado).

— Chris S
fonte

1

Será que, como o Moon é uma máquina Windows XP Pro x64 usando o serviço NTP W32Time padrão que é realmente o NTP Simples (SNTP), o RackCard23 não o vê como um servidor NTP adequado, nunca definirá seu estrato para outra coisa? que 16?

— Fwgx

Não vi isso antes de editar minha postagem. Isso é bem provável. Algum motivo para não usar um cliente ntp adequado no topo da sua hierarquia? (Com base no Windows ou no Unix)

— Christopher Karel

2

Como uma espécie de aparte, incluirei algumas análises da sua saída ntpq. Apenas para ajudar a solucionar problemas genéricos no futuro, para você e outras pessoas.

Primeiro, no 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 aos quais esta máquina está configurada para sincronizar. Notável é a falta *ou +que indicaria um par sincronizado ou candidatos secundários. Isso significa que seu servidor não utilizará as entradas aqui, mas pelo menos fará o check-in 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 a que distância estão os dois relógios. No valor de "segundos de diferença nos relógios" ou na latência entre as duas máquinas, até a diferença nessa latência. Aqui, números mais altos são piores.

O motivo de entradas não sincronizadas como essa pode depender de alguns fatores: Se o deslocamento nos relógios for muito alto, o ntp nem tentará, pois introduziria um salto muito grande na hora local. Se o jitter ficar ruim, o cliente será dessincronizado até que as coisas se estabilizem. (Isso geralmente é temporário e, no entanto, ocorre novamente) 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 utilizará.

--Christopher Karel

— Christopher Karel
fonte