Configurando servidores NTP

Question

Eu tenho um problema ao configurar o NTP para manter o tempo em uma rede independente. Este será um fuso horário da ilha. O problema é que o tempo se separa, mesmo depois de terem sido sincronizados inicialmente.

Existem dois servidores NTP redundantes que executam o RHEL 5.4 e vários clientes Windows XP. Os requisitos são que a rede seja sincronizada com o servidor A enquanto o servidor B atua como backup. Nós temos um GPS que funciona como um servidor de tempo controlando o servidor A e o servidor B, mas nem sempre está disponível. Quando o GPS está presente, ambos os servidores sincronizam com o GPS.

Os clientes XP parecem se dividir em dois grupos quando os servidores se separam; com algum servidor a seguir e outro servidor B.

Como posso evitar que meus dois servidores se separem?

Posso controlar qual servidor os clientes XP seguem?

Os dois arquivos ntp.conf são os seguintes

ntp.conf para o servidor A ( 10.203.224.13 )

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 11

# Establish the drift file location
driftfile /etc/ntp.drift 

ntp.conf para o servidor B ( 10.203.224.14 )

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 13

# Establish the drift file location
driftfile /etc/ntp.drift

No servidor A

[root@serverA]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.14   LOCAL(1)        14 u   27   64  377    0.312  359.753   0.289
*LOCAL(1)       .LOCL.          11 l   55   64  377    0.000    0.000   0.001

No servidor B

[root@serverB]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   LOCAL(1)        12 u   55   64  377    0.346  -359.56   0.107
 10.203.224.14   .INIT.          16 u    -   64    0    0.000    0.000   0.000
*LOCAL(1)       .LOCL.          13 l   54   64  377    0.000    0.000   0.001

    

Answer 1

No servidor A, remova as linhas apontando para si e para o servidor B, deixando apenas a linha de relógio local "fudge" e o GPS. No servidor B, remova a linha "fudge" e a linha B do servidor, deixando apenas a linha A do servidor e o GPS.

A idéia é que o servidor A deve usar o GPS se estiver disponível, caso contrário ele deve confiar em seu próprio relógio. O servidor B deve usar o servidor A, seja qual for o servidor A está ganhando tempo, ou o GPS. Se for permitido ao servidor B confiar em si mesmo, ele anunciará uma fonte de tempo confiável para seus clientes, mesmo que esse tempo seja diferente do servidor A - que é o que você está vendo.

    

Answer 2

Existem vários problemas aqui:

1. O dispositivo GPS não está funcionando corretamente. Este é provavelmente um problema de conectividade. Um firewall está bloqueando os pacotes ou não está escutando na interface correta ou não pode alcançar um sinal de GPS ou algo similar. Pode ser que a indisponibilidade intermitente que você mencionou. Nesse caso, tente mostrar um ntpq -p de quando está funcionando.
2. O GPS é estrato 16. Quando estiver funcionando, isso deve ser 1. Qualquer coisa maior que 11 causará o mesmo problema porque o servidor A confiará no seu relógio local mais do que qualquer coisa em 11 ou mais.
3. O servidor A é configurado para obter tempo do Servidor B e o Servidor B é configurado para obter tempo do Servidor A. Esse tipo de configuração deve ser um relacionamento de peering em vez de um relacionamento mestre / escravo circular. Use a palavra-chave peer em vez da palavra-chave server para isso.
4. O Servidor A e o Servidor B estão configurados para usarem a si próprios como uma fonte de tempo por meio do protocolo ntp. Isso é redundante e não está funcionando. A conexão está falhando ou o estrato atual é 16 e não pode ir mais alto.
5. Os dois servidores selecionaram seus próprios relógios como a fonte de tempo mais confiável (indicada pelo * ao lado da fonte LOCAL . Eles também conseguiram se conectar uns aos outros. Não sei por que o Servidor B não se conectou). Escolha o Servidor A como a melhor fonte de tempo, pois ele possui o valor de estrato mais baixo, mas é provavelmente porque possui um tremor significativamente maior do que a fonte de tempo LOCAL .

Obtenha o GPS funcionando, altere os dois servidores para perscrutar um ao outro e remova as linhas para obter tempo de seu próprio endereço IP. (O relógio local é bom, mas adicionar a latência de um protocolo de rede para um relógio local é bobagem.)