Configurar corretamente o NTP ativo simétrico?

4

Estou tentando configurar dois servidores NTP para serem pares um do outro, mas não tenho idéia de como saber se está funcionando ou não, ou se minha configuração de NTP está correta. Eu coloquei uma visão simplificada de como meus servidores NTP estão configurados abaixo.

Server A : 
  ntp.conf : 
    restrict default kod nomodify notrap noquery
    peer Server B

Server B :
  ntp.conf : 
    restrict default kod nomodify notrap noquery
    peer Server A

Eu tenho duas perguntas em relação a essa configuração:

EDIT: Esclarecimento adicionado à pergunta 1

  1. Usando o ntp.conf simplificado que coloquei, os dois servidores NTP agem como pares entre si, tentando corrigir o tempo deles? Eu estou procurando a configuração mais simples possível para pares ntp e não tenho certeza se estou configurando corretamente.
  2. Como eu confirmo que a configuração do meu NTP está funcionando?

A razão pela qual estou fazendo as perguntas acima é porque tenho uma configuração alternativa em que a única mudança é que eu adicionei novamente a configuração nopeer à estrofe restrict e, em ambos os casos, a saída a seguir é retornou:

Server A:
  ntpdc -l
    sym_active : Server B

Server B:
  ntpdc -l
    sym_active : Server A

O que não faz sentido algum, já que a diretiva nopeer não deve permitir que eu coloque os dois servidores juntos.

Nota: Isso é executado no CentOS 6

EDIT: Arquivos ntp.conf reais e ntpq -p, conforme solicitado. Não tenho certeza de como isso seria útil:

Server A:
  driftfile /var/lib/ntp/drift

  restrict default kod nomodify notrap noquery
  restrict -6 default kod nomodify notrap noquery


  restrict 127.0.0.1 
  restrict -6 ::1 

  peer 192.168.122.3

Server B:
  driftfile /var/lib/ntp/drift

  restrict default kod nomodify notrap noquery
  restrict -6 default kod nomodify notrap noquery

  restrict 127.0.0.1
  restrict -6 ::1

  peer 192.168.122.2

A saída de ntpq -p depois de mais de 5 minutos (que excede o intervalo de sondagem) é a seguinte para cada servidor.

Server A:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 secure.jzhu.loc .INIT.          16 u   55   64    0    0.000    0.000   0.000

Server B:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 masterdns.jzhu. .INIT.          16 u   33   64    0    0.000    0.000   0.000

Nota: Com ou sem a diretiva nopeer, o alcance permanece consistentemente em 0. Embora isso seja mais provável devido ao fato de que eles são ambos servidores stratum 16 do que qualquer outra coisa. Nota: iptables -F foi executado ao executar este teste e a política padrão para a cadeia INPUT foi ACCEPT.

    
por Jason Zhu 04.06.2014 / 04:15

1 resposta

1

Não, isso não vai funcionar. O NTP precisa de uma fonte de tempo válida. Um host não sincronizado não é uma fonte válida, portanto dois hosts não sincronizados não podem ser válidos um para o outro. Na verdade, a filosofia do NTP é sobre distribuir o tempo "correto", não para tentar manter um conjunto de máquinas sincronizadas entre si.

Se você absolutamente não consegue obter uma fonte de tempo real, pode mentir para o NTP e dizer que o relógio de uma das máquinas deve ser confiável. Escolha um servidor como o "correto" e configure um relógio local nele. Esse relógio seria a fonte para o NTP desse servidor, e o outro servidor seria sincronizado com ele.

Se você quiser que o relógio do servidor A seja o usado, ele terá no ntp.conf:

server 127.127.1.1             # local clock trusted
fudge  127.127.1.1 stratum 10  # Real clocks should be preferred

Dizemos ao servidor para usar o relógio e fingir que é um relógio de camada 10. Isso significa que o servidor A deve então sincronizar e se tornar um servidor de estrato 11. Você pode então apontar B e sincronizar.

ntp.conf do servidor B

server A

É isso. Execute ntpq -p para ver a sincronização.

    
por 19.09.2014 / 08:46

Tags