arquitetura do servidor NTP

Question

Eu tenho um ambiente virtual rodando várias caixas Linux e estou planejando como gerenciar toda a arquitetura ntp.
Tanto quanto eu sei, não há nenhum uso em ter dois servidores no arquivo 'ntp.conf', deve haver apenas um ou mais de três servidores ntp apontados pelo cliente, então, minha primeira abordagem é ter um servidor 'server1' apontando para 4 servidores públicos, especificamente os do RHEL, depois tendo outra caixa 'server2' apontando para server1 e abaixo todos os meus outros servidores Linux apontando para server2, mas observei um comportamento estranho com essa arquitetura. Eu vi alguns servidores dessincronizando entre o server2 e eles e até mesmo algumas vezes server1 e server2 não são perfeitamente sincronizados. Minha primeira pergunta é: por que isso está acontecendo?
Então eu criei outra arquitetura que estava tendo o mesmo servidor1 apontando para servidores ntp públicos e então tendo três servidores, 'server2', 'server3' e 'server4' apontando para server1 e abaixo todas as minhas outras máquinas apontando para servers2-4.
Existe uma chance dessa arquitetura melhorar a sincronização em toda a minha rede?
Ou seria o mesmo desempenho entre sincronizações?
Qual seria a melhor maneira de arquitetar isso?

Edited

Aqui está a saída de ntpq -p do server1:

remote          refid      st t when poll reach   delay   offset  jitter
=========================================================================
*Time100.Stupi. .PPS.       1 u  317 1024  377  182.786    5.327   3.022
LOCAL(0)        .LOCL.     10 l  46h   64    0    0.000    0.000   0.000

E aqui está o seu ntp.conf :

# For more information about this file, see the man pages
# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst
#broadcast 192.168.1.255 autokey        # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 autokey            # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 autokey # manycast client

# Enable public key cryptography.
#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

# Enable writing of statistics records.
statistics clockstats cryptostats loopstats peerstats sysstats rawstats

### Added by IPA Installer ###
server 127.127.1.0
fudge 127.127.1.0 stratum 10

Aqui está a saída de três clientes:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u    1   64    1    1.090   -0.138   0.036


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u 1035 1024  377    1.117   -1.943   0.530


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u   32   64    1    0.902    1.788   0.140

    

Answer 1

Dependendo de como o tempo crítico está em seu ambiente, você pode não querer que o server1 seja um ponto único de falha. Se você tiver que colocá-lo off-line para manutenção ou reparo por um período prolongado, seus colegas deixarão de sincronizar. É tudo a partir daí.

Por que não ter server1, server2, server3, server4 todos sincronizados com 4 ou 5 pontos de Internet. Então, sua rede interna pode fazer referência a esses sistemas?

A sabedoria convencional diz que 3 é o que você precisa para o quorum, mas você precisa ser tolerante com pelo menos um ser determinado como falsete ou ficar off-line.

Por favor, veja; 5.3.3. Quantidade de servidores de tempo upstream

Além disso, você menciona estranheza e problemas com sua configuração atual. Ajudaria a ver a saída de ntpq -p para os hosts relevantes.

    

Answer 2

Embora não seja estritamente verdadeiro que 2 servidores não sejam úteis, o rascunho do RFC das Melhores Práticas Atuais recomenda 4, no mínimo. O algoritmo de interseção do NTP não depende apenas do quorum no número dos servidores, mas também da qualidade do tempo que eles retornam - e você não pode prever isso. Então, quanto mais, melhor. Não há problema em ter até 10 servidores NTP upstream .

Como Aaron mencionou, todos os seus servidores propostos 1-4 devem apontar para servidores NTP upstream, e seus sistemas internos devem apontar para todos os 4 deles. Os servidores 1-4 também podem espiar uns aos outros (no modo simétrico), mas isso não é estritamente necessário.

É importante entender por que você não deve canalizar o NTP através de um único servidor em qualquer ponto de sua arquitetura: o NTP requer vários servidores para precisão , não apenas redundância (consulte os documentos NTP para a < href="http://doc.ntp.org/current-stable/warp.html#arch"> descrição dos algoritmos , o que explica porquê). (Plug Shameless: Eu escrevi mais sobre isso em outro lugar , incluindo sugestões para arquitetura .)