Início / unix / Perguntas / 782638
Accepted
Dodge_X
Asked: 2024-08-28 09:01:55 +0800 CST

O cliente NTP não consegue sincronizar dados de um servidor específico

  • 772

Quero criar um servidor NTP e meus clientes poderão sincronizar dados deste servidor.

Então, eu adiciono a política de restrição no meu servidor e, em seguida, reinicio o serviço NTP para que ele funcione como um servidor NTP. Então, adiciono esse servidor aos meus clientes e removo outros servidores NTP e pools para torná-lo o único servidor NTP neste cliente.

Já executei este comando para verificar este servidor escolhido pelo cliente:

ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xx.xx.xx.xx     91.189.91.157    3 u  342   64  340    0.087    8.349 4492269

Como você pode ver, funciona bem. Eu também executo ntpdate -q xx.xx.xx.xx para verificar o horário manualmente.

Mas eu quero mudar um horário específico no meu servidor NTP, então eu desabilitei todos os pools no meu servidor NTP, e então usei date -s para mudar o horário. Eu também reiniciei este servidor. O problema é que quando eu termino todos esses passos, o cliente não consegue sincronizar o datetime do meu servidor NTP!

ntpdate -q xx.xx.xx.xx
server xx.xx.xx.xx, stratum 16, offset -26584.931234, delay 0.02574
27 Aug 07:23:49 ntpdate[1563239]: no server suitable for synchronization found

Isso significa que ainda preciso definir um pool ou um servidor no meu servidor NTP e como posso alterar um horário específico no meu servidor NTP?

ubuntu

2 respostas

  1. O problema que você está vendo é que o horário do cliente local e o horário do servidor remoto estão muito distantes. O deslocamento máximo é de 1000 segundos; suas máquinas estão separadas por 26.000 segundos!

    A razão para esse máximo é devido a como ntpdfunciona; ele tenta ajustar a velocidade do relógio local para permitir que ele entre em sincronia. Com um grande deslocamento, isso pode acabar levando dias ou semanas, e durante esse tempo seu relógio está muito errado.

    Você pode consertar isso no cliente parando ntpde executando ntpdate server.address. Isso fará um "pulo brusco" no tempo do seu cliente para corresponder ao servidor. Agora ntpddeve reiniciar de forma limpa.

    • 1
  2. Best Answer

    Outro problema é que seu servidor está anunciando stratum 16, que é o valor máximo do estrato. O estrato representa quantas "camadas" de servidores NTP estão entre ntpde o relógio de referência, e ter 16 etapas intermediárias seria... um tanto incomum e excessivo. Espera-se que uma cadeia tão longa de servidores NTP acumule tanto atraso/incerteza que estendê-la ainda mais seria inútil.

    ntpdtambém anunciará stratum 16quando ainda não estiver sincronizado com nenhum outro servidor NTP ou relógio de referência; em essência, ele está dizendo "Não confie em mim, ainda não tenho certeza da hora correta com precisão séria".

    Para usar ntpdda maneira que você quiser, sem conexão com nenhum servidor NTP ou relógio de referência, a maneira moderna é configurar as configurações do modo órfão em seu ntp.conf:

    # If orphaned, serve others with this stratum.
tos orphan 8
# Wait for this many seconds before starting to serve others
tos orphanwait 300

    Com essas configurações, você teria que esperar 5 minutos após iniciar seu "master" ntpdantes que os clientes NTP pudessem realmente sincronizar com ele; se você tiver uma mistura de órfãos e não órfãos (ou seja, com uma conexão a uma hierarquia de servidores NTP com um relógio de referência no topo), isso permite que os clientes escolham um servidor NTP com tempo de qualidade superior a este.

    Mas em uma situação em que você tem certeza absoluta de que seu servidor NTP será o único acessível, você deve definir o estrato órfão como 1 e minimizar o tempo de espera do órfão:

    tos orphan 1
tos orphanwait 10

    Referência da documentação do NTP aqui .

    Se você estiver usando uma versão antiga ntpdque não suporta o modo órfão , a maneira mais antiga é configurar uma fonte de tempo falsa usando o driver de relógio de referência Undisciplined Local Clock :

    # Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 8

    Isso cria um relógio de referência falso que está sempre em 100% de acordo com o relógio do kernel, então ntpdirá trivialmente "sincronizar" com ele, e então irá se considerar bom o suficiente para servir informações de tempo para outros. O fudgecomando define o valor stratum desse relógio de referência falso para 8, então outros servidores NTP com uma boa conexão com um relógio de referência próximo ainda seriam preferidos a ele.

    No seu caso, você configuraria o Undisciplined Local Clock somente no seu ntpdservidor "master" e somente se ele não suportar o novo modo órfão.

    Não importa qual tipo de configuração você usa, definir o estrato como 8 ou superior ao usar o NTP para distribuir alguma escala de tempo não UTC personalizada (como você está planejando) é uma boa ideia; isso minimiza o risco de confusão se sua hierarquia NTP personalizada acabar acidentalmente sendo acessada por clientes do mundo externo, que geralmente esperariam que um servidor NTP registrasse os timestamps NTP correspondentes à escala de tempo UTC.

    E como Stephen Harris disse em outra resposta, se suas máquinas estiverem separadas por mais de 1000 segundos e você quiser que elas sejam sincronizadas rapidamente, você deve interromper todos os aplicativos sensíveis ao tempo no cliente, executar ntpdate server.addressum salto brusco no cliente para o segundo correto ou algo assim e, então, começar ntpda refinar a sincronização a partir daí.

    • 0

relate perguntas