chrony vs. systemd-timesyncd – Quais são as diferenças e casos de uso como clientes NTP?

O anúncio do systemd-timesyncd no arquivo systemd NEWS faz um bom trabalho ao explicar as diferenças desta ferramenta em comparação com o Chrony e ferramentas semelhantes. (ênfase minha):

Um novo daemon "systemd-timesyncd" foi adicionado para sincronizar o relógio do sistema na rede. Ele implementa um cliente SNTP . Em contraste com as implementações de NTP, como chrony ou o servidor de referência NTP, isso implementa apenas um lado do cliente e não se preocupa com a complexidade total do NTP, concentrando-se apenas em consultar o tempo de um servidor remoto e sincronizar o relógio local com ele . A menos que você pretenda servir NTP para clientes em rede ou queira se conectar a relógios de hardware locais, este cliente NTP simples deve ser mais do que apropriado para a maioria das instalações. [...]

Essa configuração é um caso de uso comum para a maioria dos hosts em uma frota de servidores. Eles geralmente são sincronizados a partir de servidores NTP locais, que são sincronizados de várias fontes, possivelmente incluindo hardware. systemd-timesyncd tenta fornecer uma solução fácil de usar para esse caso de uso comum.

Tentando responder às suas perguntas específicas:

Quais são as diferenças do mundo real entre os dois em termos de precisão?

Acredito que você pode obter maior precisão obtendo dados de sincronização de várias fontes, o que especificamente não é um caso de uso com suporte para systemd-timesyncd. Mas quando você o está usando para obter dados de sincronização de servidores NTP centrais conectados à sua rede interna confiável, o uso de várias fontes não é tão relevante e você obtém boa precisão de uma única fonte.

Se você estiver sincronizando seu servidor de um servidor confiável em uma rede local e no mesmo datacenter , a diferença de precisão entre NTP e SNTP será praticamente inexistente. O NTP pode levar em conta o RTT e fazer timesmearing, mas isso não é tão benéfico quando seu RTT é muito pequeno, como é o caso de uma rede local rápida e uma máquina próxima. Você também não precisa de várias fontes se puder confiar na que está usando.

Quais são as diferenças de eficiência?

Obter a sincronização de uma única fonte é muito mais simples do que obtê-la de várias fontes, pois você não precisa tomar decisões sobre quais fontes são melhores que outras e possivelmente combinar informações de várias fontes. Os algoritmos são muito mais simples e exigirão menos carga de CPU para o caso simples.

Quais são as necessidades de sincronização de tempo "não simples", também conhecidas como casos de uso para chrony como cliente NTP?

Isso é abordado na citação acima, mas em qualquer caso, esses são casos de uso para Chrony que não são cobertos pelo systemd-timesyncd:

• executando servidor NTP (para que outros hosts possam usar este host como fonte para sincronização);
• obter informações de sincronização NTP de várias fontes (o que é importante para os hosts obterem essas informações de servidores públicos na Internet); e
• obter informações de sincronização do relógio local, que geralmente envolve hardware especializado, como dispositivos GPS, que podem obter informações de hora precisas de satélites.

Esses casos de uso requerem Chrony ou ntpd ou similar.

Como a outra resposta afirma corretamente, chronyimplementa NTP e systemd-timesyncdSNTP.

Do ponto de vista de um cliente de serviço de tempo:

O SNTP é um protocolo muito mais simples de implementar;
O NTP permite incrementos/correções passo a passo no tempo. Uma grande vantagem do NTP é que ele também leva em consideração o RTT da resposta para obter uma hora mais exata.

De https://www.meinbergglobal.com/english/faq/faq_37.htm

Enquanto um servidor ou cliente NTP completo atinge um nível muito alto de precisão e evita tanto quanto possível passos de tempo abruptos usando diferentes métodos matemáticos e estatísticos e ajustes suaves de velocidade de clock, o SNTP só pode ser recomendado para aplicações simples, onde os requisitos de precisão e confiabilidade não são muito exigentes. Ao desconsiderar os valores de desvio e usar formas simplificadas de métodos de ajuste do relógio do sistema (muitas vezes simples passo de tempo), o SNTP alcança apenas uma sincronização de tempo de baixa qualidade quando comparado com uma implementação NTP completa.

O SNTP adota uma abordagem muito mais simples. Muitas das complexidades do algoritmo NTP são removidas. Em vez de distorcer o tempo, muitos clientes SNTP avançam o tempo. Isso é bom para muitos aplicativos em que um carimbo de data e hora simples é necessário. Além disso, o SNTP não tem a capacidade de monitorar e filtrar vários servidores NTP. Muitas vezes, uma abordagem simples de round-robin é usada, onde se um servidor falhar, o próximo em uma lista é usado

De https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

O NTP é muito mais preciso e preciso do que o SNTP, e isso o torna o vencedor de fato na maioria dos aplicativos corporativos. Por outro lado, a simplicidade do SNTP o torna mais apropriado para coisas como câmeras IP, DVRs e alguns switches de rede. Esses tipos de hardware carecem de recursos de processamento para lidar com protocolos mais complexos, mas à medida que os dispositivos conectados se tornam cada vez mais poderosos, isso pode mudar.

Um grande ponto fraco do SNTP é que você não pode torná-lo mais preciso recuperando o tempo de várias fontes, como o Network Time Protocol faz por padrão.

Um outro ponto importante que posso ver as implementações de SNTP dando mais problemas do que o NTP está na virtualização, quando você tem o hypervisor e o daemon NTP tentando alterar o tempo da VM. Especialmente com eles não concordando a tempo com alguma configuração incorreta faz com que ambos sejam ativos, isso pode causar grandes problemas. (Embora os administradores de sistema competentes mantenham ativo apenas um método de sincronização com o tempo, pode acontecer que ambos estejam ativos por um erro de configuração).

PS systemd-timesyncdnão deve ser uma alternativa aconselhada quando não estiver usando systemd.

chronynão é um formulário fork, ntpdmas é implementado do zero. Ele implementa os modos cliente e servidor do protocolo NTPv4 completo ( RFC5905 ). Em usuários de nível empresarial, estamos vendo uma tendência de mudança do tradicional ntpdpara chronyo Red Hat (RHEL 7 em diante) e SuSE (do SLES 15).

systemd-timesyncdimplementar apenas o modo cliente do protocolo SNTP ( RFC4330 ) . Portanto, casos de uso complexos não são cobertos pelo . Por exemplo, o SNTP não pode torná-lo mais preciso recuperando o tempo de várias fontes, como o NTP faz por padrão. Como resultado , não pode fornecer um tempo de alta precisão como .systemd-timesyncdsystemd-timesyncdchrony