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

De alguma forma, mas não exatamente baseado na pergunta mais antiga "ntpd vs. systemd-timesyncd - Como obter sincronização NTP confiável?" , Gostaria de perguntar sobre as diferenças entre chrony e systemd-timesyncd em termos de um cliente NTP .

Eu sei que systemd-timesyncd é uma implementação de cliente ntp mais ou menos mínima, enquanto o chrony é uma solução de daemon NTP de pleno direito que inclui um cliente NTP.

As notas de versão do ubuntu Bionic Beaver afirmam o seguinte:

Para uma sincronização simples, o sistema básico já vem com systemd-timesyncd. O Chrony é necessário apenas para atuar como um servidor de horário ou se você deseja que a sincronização seja mais precisa e eficiente anunciada.

Eu gosto da idéia de usar uma ferramenta pré-instalada mínima para fazer o trabalho e tenho certeza que o systemd-timesyncd fará o trabalho nos meus casos de uso, ainda estou curioso:

• Quais são as diferenças do mundo real entre os dois em termos de precisão?
• Quais são as diferenças de eficiência?
• Quais são as necessidades de sincronização de tempo "não simples", também conhecidas como casos de uso do chrony como cliente NTP?

O anúncio de systemd-timesyncd no arquivo systemd NEWS explica bem as diferenças dessa ferramenta em comparação com o Chrony e outras ferramentas semelhantes. (ênfase minha):

Um novo daemon "systemd-timesyncd" foi adicionado para sincronizar o relógio do sistema pela rede. Ele implementa um cliente SNTP . Ao contrário das implementações NTP, como o chrony ou o servidor de referência NTP, isso apenas implementa o lado do cliente e não se preocupa com toda a complexidade do NTP, concentrando-se apenas na consulta do tempo de um servidor remoto e na sincronização do relógio local . A menos que você pretenda servir o NTP a clientes em rede ou desejar conectar-se a relógios de hardware locais, esse 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 serão sincronizados a partir de servidores NTP locais, que são sincronizados por várias fontes, possivelmente incluindo hardware. O systemd-timesyncd tenta fornecer uma solução fácil de usar para esse caso de uso comum.

Tentando resolver 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 não é especificamente um caso de uso suportado pelo systemd-timesyncd. Mas quando você o usa para obter dados de sincronização de servidores NTP centrais conectados à sua rede interna confiável, o uso de várias fontes não é realmente tão relevante e você obtém boa precisão de uma única fonte.

Se você estiver sincronizando seu servidor em 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 consideração o RTT e economizar tempo, mas isso não é tão benéfico quando o seu RTT é realmente pequeno, como é o caso de uma rede local rápida e de 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 da 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 do chrony como cliente NTP?

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

• executando o servidor NTP (para que outros hosts possam usar esse host como fonte de 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 precisas de hora dos 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 horário:

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 um tempo mais exato.

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

Embora um servidor ou cliente NTP com recursos completos atinja um nível muito alto de precisão e evite etapas abruptas de tempo, tanto quanto possível, usando diferentes métodos matemáticos e estatísticos e ajustes suaves da velocidade do relógio, o SNTP só pode ser recomendado para aplicativos simples, onde os requisitos para precisão e confiabilidade não são muito exigentes. Ao desconsiderar os valores de desvio e ao usar maneiras simplificadas de métodos de ajuste do relógio do sistema (geralmente simples etapas de tempo), o SNTP alcança apenas uma sincronização de tempo de baixa qualidade quando comparado com uma implementação completa do NTP.

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. Isso é bom para muitos aplicativos em que é necessário um carimbo de data / hora simples. Além disso, o SNTP não possui a capacidade de monitorar e filtrar vários servidores NTP. Geralmente, é usada uma abordagem round-robin simples, 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 que o SNTP, e isso o torna o vencedor de fato na maioria dos aplicativos empresariais. Por outro lado, a simplicidade do SNTP o torna mais apropriado para coisas como câmeras IP, DVRs e alguns comutadores de rede. Esses tipos de hardware não possuem os 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 dos principais pontos fracos do SNTP é que você não pode torná-lo mais preciso recuperando o tempo de várias fontes, como o Network Time Protocol, por padrão.

Outro ponto importante que posso ver são as implementações de SNTP que fornecem mais problemas do que o NTP na virtualização, quando você tem o daemon de hipervisor e NTP tentando alterar o tempo da VM. Especialmente com o fato de eles não concordarem com o tempo com algumas configurações incorretas, os dois ficam ativos e podem causar grandes problemas. (Embora os administradores de sistema competentes mantenham ativo apenas um método para sincronização com o tempo, pode acontecer que ambos estejam ativos por um erro de configuração).

O PS systemd-timesyncdnão deve ser uma alternativa recomendada quando não estiver em uso systemd.

chronynão é uma forma de garfo, ntpdmas é implementada a partir 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 mudar do tradicional ntpdpara o chronyRed Hat (RHEL 7 em diante) e o SuSE (do SLES 15).

systemd-timesyncdimplemente apenas o modo de cliente protocolo SNTP ( RFC4330 ) . Portanto, casos de uso complexos não são cobertos por . 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 é possível fornecer um tempo de alta precisão .systemd-timesyncdsystemd-timesyncdchrony