O peering de NTP ajudará a deriva relativa dos meus servidores?

Question

Eu tenho uma série de servidores NTP internos; todas as outras máquinas da minha rede estão configuradas para falar com esses servidores assim:

# ntp.conf for client machines
server 0.ntp.internal iburst
server 1.ntp.internal iburst
server 2.ntp.internal iburst

Enquanto isso, esses servidores NTP internos são configurados para conversar com os servidores NTP da Amazon da seguinte forma:

# ntp.conf for the internal NTP servers
server 0.amazon.pool.ntp.org iburst
server 1.amazon.pool.ntp.org iburst
server 2.amazon.pool.ntp.org iburst
server 3.amazon.pool.ntp.org iburst

O problema que encontrei é que meus servidores NTP escolherão diferentes servidores AWS NTP uns dos outros como sua fonte autorizada, e minhas máquinas cliente também escolherão diferentes servidores NTP internos uns dos outros como sua fonte autoritativa, resultando em alguns relógio deriva ao longo do tempo. Basicamente, eu gostaria que os servidores NTP internos fossem tão consistentes quanto possível, de modo que, por procuração, minhas máquinas clientes não seriam muito inconsistentes entre si.

Eu tenho lido sobre o NTP, mas estou recebendo mensagens massivas sobre o que ele realmente faz e se ele ajudará a reduzir o problema de desvio do relógio. O que estou vendo com mais frequência é que configurar um servidor como um par permitirá que ntpd trate o par como uma fonte de tempo em potencial, mas isso não faz com que os dois servidores tentem convergir seus relógios juntos; no entanto eu vi fontes dizendo o contrário. Eu também tenho visto fontes dizendo que se você colocar os servidores juntos, você não deve permitir que todos tenham a mesma lista de server s, o que não faz sentido para mim. Eu não sei o que pensar.

Então ... adicionando esta seção aos meus servidores NTP internos ' ntp.conf help para aproximar os relógios uns dos outros?

# adding to ntp.conf for 0.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 1.ntp.internal
peer 0.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 2.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal

A propósito, eu não posso espiar as máquinas clientes como elas são transitórias, então mesmo que peering seja a solução, isso só pode ser feito com meus servidores NTP internos.

    

Answer 1

Geralmente, você quer um número ímpar de servidores e / ou colegas. O algoritmo de escolha do servidor NTP é complexo e não encontrei boa documentação sobre ele.

Alguns dos fatores considerados incluem:

• O estrato do servidor. Estratos inferiores são preferidos.
• A estabilidade do servidor. Servidores com dados mais estáveis são preferidos.
• Quão bem o tempo do servidor concorda com outros servidores.

Estas são algumas regras que eu uso ao configurar o NTP:

• Pesquise todos os servidores internos para que eles estejam cientes um do outro e possam escolher entre si como servidores. Na minha experiência, os colegas tendem a ser incluídos no conjunto de servidores selecionado.
• Use um ou três servidores externos em cada servidor interno.
• Se estiver usando relógios internos, falsifique o estrato para 8 ou superior. Use valores de fudge diferentes para cada servidor.
• Opcionalmente, prefira um servidor se vários servidores igualmente confiáveis estiverem disponíveis.

Se os relógios estão se afastando, há um problema com sua configuração. Foi minha experiência que executar o NTP em um servidor virtual pode causar instabilidade.

Não é provável que o peering de clientes para o servidor funcione. O estrato do cliente normalmente será um maior do que o servidor, então será menos pesado.