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 fiable NTP synchronisation?" , je voudrais poser des questions sur la 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 tandis que chrony est une solution démon complète NTP démon qui inclut un client NTP.
L'ubuntu Notes de version de Bionic Beaver indique ce qui suit:
Pour des besoins de synchronisation temporelle simples, le système de base est déjà livré avec systemd-timesyncd. Chrony n'est nécessaire que pour agir comme un serveur de temps ou si vous voulez 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 simple" aka les cas d'utilisation de chrony comme client NTP?
Le annonce de systemd-timesyncd dans le fichier NEWS de systemd 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 this this implémente uniquement un côté client, et ne se soucie pas de la pleine NTP, en se concentrant uniquement sur l'interrogation de l'heure d'un serveur distant et la synchronisation de l'horloge locale avec celle-ci . À moins que vous n'ayez l'intention de servir NTP aux clients en réseau ou que vous souhaitiez vous connecter aux 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 locaux NTP, 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 plus grande précision 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 centraux NTP 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 approuvé dans un réseau local et dans le même centre de données , la différence de précision entre NTP et SNTP seront pratiquement inexistants. NTP peut prendre en compte RTT et faire du timemearing, mais ce n'est pas si avantageux lorsque votre RTT est vraiment petit, ce qui est le cas d'un un réseau local rapide et 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 simple" aka les cas d'utilisation de chrony comme 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 NTP serveur (afin que d'autres hôtes puissent utiliser cet hôte comme source de synchronisation));
- obtenir NTP informations de synchronisation à 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, chrony implémente NTP et systemd-timesyncd SNTP.
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 de NTP est qu'il prend également en compte le RTT de la réponse pour obtenir une heure plus exacte.
De https://www.meinbergglobal.com/english/faq/faq_37.htm
Alors qu'un serveur ou client complet NTP 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é pour les applications simples, où les exigences de précision et de 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 réglage de l'horloge système (souvent un simple pas de temps), SNTP n'obtient qu'une synchronisation de temps de faible qualité par rapport à une synchronisation complète NTP implémentation.
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 échouent. Cela convient parfaitement à de nombreuses applications où un horodatage simple est requis. De plus, SNTP manque la capacité de surveiller et de filtrer plusieurs NTP serveurs. 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é
De 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, je peux voir des implémentations SNTP donner plus de problèmes que NTP est en virtualisation, lorsque vous avez à la fois l'hyperviseur et NTP démon essayant de changer le = VM time. Surtout avec le fait qu'ils ne s'accordent pas sur l'heure avec une mauvaise configuration, ils sont tous les deux actifs, cela peut 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).
P.S. systemd-timesyncd ne devrait pas être une alternative recommandée lorsque vous n'utilisez pas systemd.
chrony n'est pas un fork ntpd mais il est implémenté à partir de zéro. Il implémente à la fois les modes client et serveur du protocole NTPv4 complet (- RFC5905 ). Sur les utilisateurs de niveau entreprise, nous constatons une tendance à passer du ntpd traditionnel au chrony comme Red Hat (à partir de RHEL 7) et SuSE (à partir de SLES 15).
systemd-timesyncd implémente uniquement le protocole SNTP ( RFC43 ) en mode client . Par conséquent, les cas d'utilisation complexes ne sont pas couverts par systemd-timesyncd. 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. Par conséquent systemd-timesyncd ne peut pas fournir un temps aussi précis que chrony.