Les paramètres "les moins mauvais" pour chrony comme NTP serveur sur une machine virtuelle

Question

Je suis chargé de reconstruire un serveur LAN servant de serveur NTP pour des centaines de machines clientes. Malheureusement, c'est sur une machine virtuelle et comme démontré par des questions telles que quelles sont les limites des serveurs NTP dans des machines virtuelles? C'est loin d'être idéal.

Toutefois, dans les circonstances actuelles, c'est ce que je dois travailler, jusqu'à ce que les centaines de machines s'appuie sur ce serveur soient reconfigurées pour une installation plus robuste NTP, quelque part dans le futur.

Heureusement, les clients ne reposent pas sur une précision de milliseconde. J'ai envisagé de courir Chrony sur le nouveau serveur, de la configurer pour utiliser quatre serveurs Stratum 2 locaux.

Je suis nouveau à NTP servant et nouveau à Chrony. Quels paramètres côté serveur envisageriez-vous essentiel pour cette situation? L'objectif est de minimiser l'inexactitude compte tenu des contraintes fondamentales de la gestion d'un serveur NTPsur une machine virtuelle en premier lieu.

Answer 1

La question que vous avez liée est un bon exemple de la sagesse reçue dans une réponse établie devenant si obsolète pour être tout simplement faux pour la majorité des cas d'utilisation. En cours d'exécution NTP Les serveurs de VMS sur les hyperviseurs modernes avec des noyaux invités modernes ne sont généralement pas problématiques. Sur un réseau local, VMS peut atteindre une précision sub-milliseconde (je viens de vérifier quelques-uns de mes propres vms et ils étaient Tous les sous-0,5 ms). Beaucoup de serveurs de piscine publique exécutés dans VMS .

À votre question:

1. Vérifiez que votre noyau a correctement atténué la source d'horloge: grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource. Ceci est typiquement tsc pour le métal nu et Hyper-V, KVM et Xen ont tous leurs pilotes d'horloge respectifs qui sont nommés de manière évidente.
2. Si vous exécutez sous KVM ou Hyper-V, vous pouvez configurer un pilote PTP local qui offre une précision supplémentaire. Voir https://docs.microsoft.com/fr- US/Azure/Virtual-Machines/Linux/Time-Sync et https://opensource.com/article/17/6/timekeeping-Linux-vms Pour plus de détails (ce dernier est Une lecture intéressante expliquant toutes les améliorations récentes qui rendent le chronométrage en VMS beaucoup mieux que cela ne l'était). TL; DR pour Chrony Config: refclock PHC /dev/ptp0 dpoll -2
3. Quatre pairs sont un minimum pour le chronométrage précis - mieux pour ajouter le public NTP piscine ou certaines sources sur Internet supplémentaires (Time.apple.com en est une fois souvent) et bénéficiez de plusieurs pairs et remplacement automatique.
4. Ne pas avoir votre nouveau VM comme le seul serveur de temps de votre réseau. Configurez votre propre équivalent local de la piscine , où vous fournissez plusieurs NTP Serveurs pour tous les clients via une entrée DNS à valeurs multiples et chacune de ces sources entre pairs avec des sources de 4 à 10 stratum inférieures.
5. Si vous avez une vue sur le ciel (pour un récepteur GPS) ou de l'argent sans fin (pour une horloge atomique), envisagez d'ajouter un serveur Stratum 1 local qui a une faible latence à votre VMS. J'utilise une Beaglebone avec une carte GPS; Il existe également de nombreuses solutions à base de PI de framboise et quelques dispositifs abordables à distance, comme - LEORTP .