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 [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, 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
Respostas:
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
fonte
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.
fonte
O NTPd definirá seu próprio estrato de acordo com:
(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).
fonte
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:
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
fonte