chrony vs. systemd-timesyncd - Quelles sont les différences et les cas d'utilisation en tant que clients NTP?

D'une manière ou d'une autre, mais pas tout à fait en s'appuyant sur la question plus ancienne "ntpd vs systemd-timesyncd - Comment obtenir une synchronisation NTP fiable?" , Je voudrais poser des questions sur les différences entre chrony et systemd-timesyncd en termes de client NTP .

Je sais que systemd-timesyncd est une implémentation client ntp plus ou moins minimale alors que chrony est une solution démon NTP à part entière qui inclut un client NTP.

Les notes de version d' ubuntu Bionic Beaver indiquent ce qui suit:

Pour les besoins de synchronisation simple, le système de base est déjà livré avec systemd-timesyncd. Chrony n'est nécessaire que pour agir en tant que serveur de temps ou si vous souhaitez que la synchronisation annoncée soit plus précise et plus efficace.

J'aime l'idée d'utiliser un outil préinstallé minimal pour faire le travail et je suis presque sûr que systemd-timesyncd fera le travail pour mes cas d'utilisation, je suis quand même curieux:

• Quelles sont les différences réelles entre les deux en termes de précision?
• Quelles sont les différences d'efficacité?
• Quels sont les besoins de synchronisation temporelle "non simples" alias les cas d'utilisation de chrony en tant que client NTP?

L' annonce de systemd-timesyncd dans le fichier systemd NEWS explique bien les différences de cet outil par rapport à Chrony et à des outils similaires. (c'est moi qui souligne):

Un nouveau démon "systemd-timesyncd" a été ajouté pour synchroniser l'horloge système sur le réseau. Il implémente un client SNTP . Contrairement aux implémentations NTP telles que chrony ou le serveur de référence NTP, cela implémente uniquement un côté client et ne dérange pas la complexité NTP complète, se concentrant uniquement sur l'interrogation de l'heure à partir d'un serveur distant et la synchronisation de l'horloge locale avec celui-ci . Sauf si vous avez l'intention de servir NTP à des clients en réseau ou si vous souhaitez vous connecter à des horloges matérielles locales, ce simple client NTP devrait être plus que approprié pour la plupart des installations. [...]

Cette configuration est un cas d'utilisation courant pour la plupart des hôtes d'un parc de serveurs. Ils seront généralement synchronisés à partir de serveurs NTP locaux, eux-mêmes synchronisés à partir de plusieurs sources, y compris éventuellement du matériel. systemd-timesyncd essaie de fournir une solution facile à utiliser pour ce cas d'utilisation courant.

Essayer de répondre à vos questions spécifiques:

Quelles sont les différences réelles entre les deux en termes de précision?

Je pense que vous pouvez obtenir une précision plus élevée en obtenant des données de synchronisation à partir de plusieurs sources, ce qui n'est spécifiquement pas un cas d'utilisation pris en charge pour systemd-timesyncd. Mais lorsque vous l'utilisez pour obtenir des données de synchronisation à partir de serveurs NTP centraux connectés à votre réseau interne fiable, l'utilisation de plusieurs sources n'est pas vraiment pertinente et vous obtenez une bonne précision d'une seule source.

Si vous synchronisez votre serveur à partir d'un serveur de confiance dans un réseau local et dans le même centre de données , la différence de précision entre NTP et SNTP sera pratiquement inexistante. NTP peut prendre en compte le RTT et faire du temps, mais ce n'est pas si avantageux lorsque votre RTT est vraiment petit, ce qui est le cas d'un réseau local rapide et d'une machine à proximité. Vous n'avez pas non plus besoin de plusieurs sources si vous pouvez faire confiance à celle que vous utilisez.

Quelles sont les différences d'efficacité?

Obtenir la synchronisation à partir d'une seule source est beaucoup plus simple que de l'obtenir à partir de plusieurs sources, car vous n'avez pas à décider quelles sources sont meilleures que d'autres et éventuellement à combiner des informations provenant de plusieurs sources. Les algorithmes sont beaucoup plus simples et nécessiteront moins de charge CPU pour le cas simple.

Quels sont les besoins de synchronisation temporelle "non simples" alias les cas d'utilisation de chrony en tant que client NTP?

Cela est abordé dans la citation ci-dessus, mais dans tous les cas, ce sont des cas d'utilisation de Chrony qui ne sont pas couverts par systemd-timesyncd:

• exécuter un serveur NTP (afin que d'autres hôtes puissent utiliser cet hôte comme source de synchronisation);
• obtenir des informations de synchronisation NTP à partir de plusieurs sources (ce qui est important pour les hôtes obtenant ces informations à partir de serveurs publics sur Internet); et
• obtenir des informations de synchronisation à partir de l'horloge locale, ce qui implique généralement du matériel spécialisé tel que des appareils GPS qui peuvent obtenir des informations précises sur l'heure des satellites.

Ces cas d'utilisation nécessitent Chrony ou ntpd ou similaire.

Comme l'autre réponse l'indique correctement, chronyimplémente NTP et systemd-timesyncdSNTP.

Du point de vue d'un client de service de temps:

SNTP est un protocole beaucoup plus simple à mettre en œuvre;
NTP permet des incréments / corrections étape par étape à temps. Un avantage majeur du NTP est qu'il prend également en compte le RTT de la réponse pour obtenir une heure plus précise.

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

Alors qu'un serveur ou un client NTP complet atteint un niveau de précision très élevé et évite autant que possible les pas de temps abrupts en utilisant différentes méthodes mathématiques et statistiques et des ajustements de vitesse d'horloge fluides, SNTP ne peut être recommandé que pour des applications simples, où les exigences de la précision et la fiabilité ne sont pas trop exigeantes. En ne tenant pas compte des valeurs de dérive et en utilisant des méthodes simplifiées de méthodes d'ajustement de l'horloge système (souvent un simple pas de temps), SNTP n'obtient qu'une synchronisation temporelle de faible qualité par rapport à une implémentation NTP complète.

SNTP adopte une approche beaucoup plus simple. De nombreuses complexités de l'algorithme NTP sont supprimées. Plutôt que de biaiser le temps, de nombreux clients SNTP incrémentent le temps. C'est très bien pour de nombreuses applications où un simple horodatage est requis. En outre, SNTP n'a pas la capacité de surveiller et de filtrer plusieurs serveurs NTP. Souvent, une approche à tour de rôle simple est utilisée, où si un serveur tombe en panne, le suivant dans une liste est utilisé

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

NTP est beaucoup plus précis et précis que SNTP, ce qui en fait le gagnant de facto dans la plupart des applications d'entreprise. D'un autre côté, la simplicité du SNTP le rend plus approprié pour des choses comme les caméras IP, les DVR et certains commutateurs réseau. Ces types de matériel manquent de ressources de traitement pour gérer des protocoles plus complexes, mais à mesure que les appareils connectés deviennent de plus en plus puissants, cela peut changer.

Un point faible majeur de SNTP est que vous ne pouvez pas le rendre plus précis en récupérant l'heure de plusieurs sources comme le fait par défaut le Network Time Protocol.

Un autre point majeur que je peux voir les implémentations SNTP donnant plus de problèmes que NTP est dans la virtualisation, lorsque vous avez à la fois l'hyperviseur et le démon NTP essayant de changer l'heure de la machine virtuelle. En particulier, le fait qu'ils ne soient pas d'accord sur l'heure avec une mauvaise configuration les rend tous les deux actifs, cela pourrait causer de gros problèmes. (Alors que les administrateurs système compétents ne garderont active qu'une seule méthode de synchronisation avec le temps, il peut arriver qu'ils soient tous deux actifs par une erreur de configuration).

PS systemd-timesyncdne devrait pas être une alternative conseillée lorsqu'il n'est pas utilisé systemd.

chronyn'est pas un fork ntpdmais il est implémenté à partir de zéro. Il implémente les modes client et serveur du protocole NTPv4 complet ( RFC5905 ). Chez les utilisateurs de niveau entreprise, nous constatons une tendance à passer du traditionnel ntpdau chronyRed Hat (à partir de RHEL 7) et au SuSE (à partir de SLES 15).

systemd-timesyncdimplémenter uniquement le mode client du protocole SNTP ( RFC4330 ) . Par conséquent, les cas d'utilisation complexes ne sont pas couverts par . Par exemple, SNTP ne peut pas le rendre plus précis en récupérant l'heure de plusieurs sources comme NTP le fait par défaut. En conséquence, il ne peut pas fournir un temps aussi précis que .systemd-timesyncdsystemd-timesyncdchrony