"Est-ce que quelqu'un sait vraiment quelle heure il est ? Est-ce que quelqu'un s'en soucie vraiment ?"
– Chicago, 1969
Peut-être que ce groupe de rock ne se souciait pas de l'heure qu'il était, mais nos ordinateurs ont besoin de connaître l'heure exacte. Le chronométrage est très important pour les réseaux informatiques. Dans les banques, les marchés boursiers et d'autres activités financières, les transactions doivent être maintenues dans le bon ordre, et des séquences temporelles exactes sont essentielles pour cela. Pour les administrateurs système et les professionnels DevOps, il est plus facile de suivre la trace des e-mails via une série de serveurs ou de déterminer la séquence exacte des événements à l'aide de fichiers journaux sur des hôtes géographiquement dispersés lorsque les heures exactes sont conservées sur les ordinateurs en question.
J'avais l'habitude de travailler dans une organisation qui recevait plus de 20 millions d'e-mails par jour et disposait de quatre serveurs juste pour accepter et effectuer un filtrage de base sur le flot d'e-mails entrants. De là, les e-mails ont été envoyés à l'un des quatre autres serveurs pour effectuer des évaluations anti-spam plus complexes, puis ils ont été livrés à l'un des nombreux serveurs supplémentaires où les e-mails ont été placés dans les bonnes boîtes de réception. À chaque couche, les e-mails seraient envoyés à l'un des serveurs de niveau suivant, sélectionné uniquement par le caractère aléatoire du DNS à tour de rôle. Parfois, nous devions tracer un nouveau message dans le système jusqu'à ce que nous puissions déterminer où il "s'était perdu", selon les patrons aux cheveux pointus. Nous devions le faire avec une régularité effrayante.
La plupart de ces e-mails se sont avérés être des spams. Certaines personnes se sont en fait plaintes que leur [blague, photo de chat, recette, dicton inspirant ou autre e-mail étrange] du jour manquait et nous ont demandé de le retrouver. Nous avons rejeté ces opportunités.
Nos e-mails et autres recherches transactionnelles ont été facilitées par des entrées de journal avec des horodatages qui, aujourd'hui, peuvent se résoudre à la nanoseconde même sur les ordinateurs Linux modernes les plus lents. Dans les environnements de transactions à très haut volume, même quelques microsecondes de différence dans les horloges système peuvent signifier trier des milliers de transactions pour trouver la ou les bonnes.
La hiérarchie des serveurs NTP
Les ordinateurs du monde entier utilisent le protocole NTP (Network Time Protocol) pour synchroniser leur heure avec les horloges de référence standard Internet via une hiérarchie de serveurs NTP. Les serveurs principaux se trouvent au niveau 1 et sont directement connectés à divers services horaires nationaux au niveau 0 via satellite, radio ou même des modems sur des lignes téléphoniques. Le service de temps à la strate 0 peut être une horloge atomique, un récepteur radio réglé sur les signaux diffusés par une horloge atomique ou un récepteur GPS utilisant les signaux d'horloge très précis diffusés par les satellites GPS.
Pour éviter que les demandes de temps des serveurs de temps inférieurs dans la hiérarchie (c'est-à-dire avec un numéro de strate plus élevé) ne submergent les serveurs de référence primaires, il existe plusieurs milliers de serveurs publics NTP stratum 2 qui sont ouverts et disponibles pour quiconque. De nombreuses organisations avec un grand nombre d'hôtes qui ont besoin d'un serveur NTP configureront leurs propres serveurs de temps afin qu'un seul hôte local accède aux serveurs de temps de la strate 2, puis ils configurent les hôtes réseau restants pour utiliser le serveur de temps local qui, dans mon cas , est un serveur de strate 3.
Choix NTP
Le démon NTP d'origine, ntpd , a été rejoint par un plus récent, chronyd . Les deux gardent l'heure de l'hôte local synchronisée avec le serveur de temps. Les deux services sont disponibles, et je n'ai rien vu qui indique que cela changera de sitôt.
Chrony possède des fonctionnalités qui en font le meilleur choix pour la plupart des environnements pour les raisons suivantes :
-
Chrony peut se synchroniser avec le serveur de temps beaucoup plus rapidement que NTP. C'est bon pour les ordinateurs portables ou de bureau qui ne fonctionnent pas en permanence.
-
Il peut compenser les fluctuations des fréquences d'horloge, comme lorsqu'un hôte hiberne ou passe en mode veille, ou lorsque la vitesse d'horloge varie en raison d'un pas de fréquence qui ralentit les vitesses d'horloge lorsque les charges sont faibles.
-
Il gère les connexions réseau intermittentes et la saturation de la bande passante.
-
Il s'ajuste aux retards et à la latence du réseau.
-
Après la synchronisation initiale de l'heure, Chrony n'avance jamais l'horloge. Cela garantit des intervalles de temps stables et cohérents pour les services et applications système.
-
Chrony peut fonctionner même sans connexion réseau. Dans ce cas, l'hôte ou le serveur local peut être mis à jour manuellement.
Les packages NTP et Chrony RPM sont disponibles à partir des référentiels Fedora standard. Vous pouvez installer les deux et basculer entre eux, mais les versions modernes de Fedora, CentOS et RHEL sont passées de NTP à Chrony comme implémentation de chronométrage par défaut. J'ai trouvé que Chrony fonctionne bien, fournit une meilleure interface pour l'administrateur système, présente beaucoup plus d'informations et augmente le contrôle.
Juste pour être clair, NTP est un protocole qui est implémenté avec NTP ou Chrony. Si vous souhaitez en savoir plus, lisez cette comparaison entre NTP et Chrony en tant qu'implémentations du protocole NTP.
Cet article explique comment configurer les clients et serveurs Chrony sur un hôte Fedora, mais la configuration pour les versions actuelles de CentOS et RHEL fonctionne de la même manière.
Structure Chrony
Le démon Chrony, chronyd , s'exécute en arrière-plan et surveille l'heure et l'état du serveur de temps spécifié dans chrony.conf dossier. Si l'heure locale doit être ajustée, chronyd le fait en douceur sans le traumatisme programmatique qui se produirait si l'horloge était instantanément réinitialisée à une nouvelle heure.
chronyc de Chrony L'outil permet à quelqu'un de surveiller l'état actuel de Chrony et d'apporter des modifications si nécessaire. Le chronyque L'utilitaire peut être utilisé comme une commande acceptant des sous-commandes ou comme un programme interactif en mode texte. Cet article explique les deux utilisations.
Configuration client
La configuration du client NTP est simple et nécessite peu ou pas d'intervention. Le serveur NTP peut être défini lors de l'installation de Linux ou fourni par le serveur DHCP au démarrage. La valeur par défaut /etc/chrony.conf fichier (illustré ci-dessous dans son intégralité) ne nécessite aucune intervention pour fonctionner correctement en tant que client. Pour Fedora, Chrony utilise le pool Fedora NTP, et CentOS et RHEL ont leurs propres pools de serveurs NTP. Comme beaucoup de distributions basées sur Red Hat, le fichier de configuration est bien commenté.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network.
#allow 192.168.0.0/16
# Serve time even if not synchronized to a time source.
#local stratum 10
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
Regardons l'état actuel de NTP sur une machine virtuelle que j'utilise pour les tests. Le chronyque la commande, lorsqu'elle est utilisée avec la commande de suivi sous-commande, fournit des statistiques indiquant la distance entre le système local et le serveur de référence.
[root@studentvm1 ~]# chronyc tracking
Reference ID : 23ABED4D (ec2-35-171-237-77.compute-1.amazonaws.com)
Stratum : 3
Ref time (UTC) : Fri Nov 16 16:21:30 2018
System time : 0.000645622 seconds slow of NTP time
Last offset : -0.000308577 seconds
RMS offset : 0.000786140 seconds
Frequency : 0.147 ppm slow
Residual freq : -0.073 ppm
Skew : 0.062 ppm
Root delay : 0.041452706 seconds
Root dispersion : 0.022665167 seconds
Update interval : 1044.2 seconds
Leap status : Normal
[root@studentvm1 ~]#
L'ID de référence dans la première ligne du résultat est le serveur avec lequel l'hôte est synchronisé — dans ce cas, un serveur de référence de la strate 3 qui a été contacté pour la dernière fois par l'hôte à 16:21:30 2018. Les autres lignes sont décrites dans le page de manuel chronyc(1).
Les sources la sous-commande est également utile car elle fournit des informations sur la source de temps configurée dans chrony.conf .
[root@studentvm1 ~]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 6 377 0 -2613us[-2613us] +/- 63ms
^+ dev.smatwebdesign.com 3 10 377 28m -2961us[-3534us] +/- 113ms
^+ propjet.latt.net 2 10 377 465 -1097us[-1085us] +/- 77ms
^* ec2-35-171-237-77.comput> 2 10 377 83 +2388us[+2395us] +/- 95ms
^+ PBX.cytranet.net 3 10 377 507 -1602us[-1589us] +/- 96ms
[root@studentvm1 ~]#
La première source de la liste est le serveur de temps que j'ai configuré pour mon réseau personnel. Les autres ont été fournis par la piscine. Même si mon serveur NTP n'apparaît pas dans le fichier de configuration Chrony ci-dessus, mon serveur DHCP fournit son adresse IP pour le serveur NTP. La colonne "S"—État de la source—indique par un astérisque (* ) le serveur avec lequel notre hôte est synchronisé. Ceci est cohérent avec les données du suivi sous-commande.
Le -v fournit une belle description des champs de cette sortie.
[root@studentvm1 ~]# chronyc sources -v
210 Number of sources = 5
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 7 377 28 -2156us[-2156us] +/- 63ms
^+ triton.ellipse.net 2 10 377 24 +5716us[+5716us] +/- 62ms
^+ lithium.constant.com 2 10 377 351 -820us[ -820us] +/- 64ms
^* t2.time.bf1.yahoo.com 2 10 377 453 -992us[ -965us] +/- 46ms
^- ntp.idealab.com 2 10 377 799 +3653us[+3674us] +/- 87ms
[root@studentvm1 ~]#
Si je voulais que mon serveur soit la source de temps de référence préférée pour cet hôte, j'ajouterais la ligne ci-dessous au /etc/chrony.conf fichier.
server 192.168.0.51 iburst preferJe place généralement cette ligne juste au-dessus de la première instruction de serveur de pool près du haut du fichier. Il n'y a pas de raison particulière à cela, sauf que j'aime conserver les instructions du serveur ensemble. Cela fonctionnerait tout aussi bien au bas du fichier, et je l'ai fait sur plusieurs hôtes. Ce fichier de configuration n'est pas sensible à la séquence.
La préférence l'option la marque comme source de référence préférée. Ainsi, cet hôte sera toujours synchronisé avec cette source de référence (tant qu'elle est disponible). Nous pouvons également utiliser le nom d'hôte complet pour un serveur de référence distant ou le nom d'hôte uniquement (sans le nom de domaine) pour une source de temps de référence locale tant que l'instruction de recherche est définie dans /etc/resolv.conf dossier. Je préfère l'adresse IP pour m'assurer que la source de temps est accessible même si le DNS ne fonctionne pas. Dans la plupart des environnements, le nom du serveur est probablement la meilleure option, car NTP continuera à fonctionner même si l'adresse IP du serveur change.
Si vous n'avez pas de source de référence spécifique avec laquelle vous souhaitez vous synchroniser, vous pouvez utiliser les valeurs par défaut.
Configurer un serveur NTP avec Chrony
La bonne chose à propos du fichier de configuration Chrony est que ce fichier unique configure l'hôte à la fois en tant que client et serveur. Pour ajouter une fonction de serveur à notre hôte - ce sera toujours un client, obtenant son heure d'un serveur de référence - nous avons juste besoin d'apporter quelques modifications à la configuration de Chrony, puis de configurer le pare-feu de l'hôte pour qu'il accepte les requêtes NTP.
Ouvrez le fichier /etc/chrony .conf fichier dans votre éditeur de texte préféré et décommentez la strate locale 10 doubler. Cela permet au serveur Chrony NTP de continuer à agir comme s'il était connecté à un serveur de référence distant en cas d'échec de la connexion Internet ; cela permet à l'hôte de continuer à être un serveur NTP pour les autres hôtes du réseau local.
Redémarrons chronyd et suivre le fonctionnement du service pendant quelques minutes. Avant d'activer notre hôte en tant que serveur NTP, nous voulons tester un peu.
[root@studentvm1 ~]# systemctl restart chronyd ; watch chronyc trackingLes résultats devraient ressembler à ceci. La montre La commande exécute le suivi chronyc commande toutes les deux secondes afin que nous puissions observer les changements se produire au fil du temps.
Every 2.0s: chronyc tracking studentvm1: Fri Nov 16 20:59:31 2018
Reference ID : C0A80033 (192.168.0.51)
Stratum : 4
Ref time (UTC) : Sat Nov 17 01:58:51 2018
System time : 0.001598277 seconds fast of NTP time
Last offset : +0.001791533 seconds
RMS offset : 0.001791533 seconds
Frequency : 0.546 ppm slow
Residual freq : -0.175 ppm
Skew : 0.168 ppm
Root delay : 0.094823152 seconds
Root dispersion : 0.021242738 seconds
Update interval : 65.0 seconds
Leap status : Normal
Notez que mon serveur NTP, le studentvm1 host, se synchronise avec l'hôte à 192.168.0.51, qui est mon serveur NTP de réseau interne, à la strate 4. La synchronisation directe avec les machines du pool Fedora entraînerait une synchronisation à la strate 3. Notez également que la quantité d'erreurs diminue avec le temps. A terme, il devrait se stabiliser avec une infime variation autour d'une marge d'erreur assez réduite. La taille de l'erreur dépend de la strate et d'autres facteurs de réseau. Après quelques minutes, utilisez Ctrl+C pour sortir de la boucle de surveillance.
Pour transformer notre hôte en serveur NTP, nous devons lui permettre d'écouter sur le réseau local. Décommentez la ligne suivante pour autoriser les hôtes du réseau local à accéder à notre serveur NTP.
# Allow NTP client access from local network.
allow 192.168.0.0/16
Notez que le serveur peut écouter les requêtes sur n'importe quel réseau local auquel il est attaché. L'adresse IP dans la ligne "autoriser" est uniquement destinée à des fins d'illustration. Assurez-vous de modifier le réseau IP et le masque de sous-réseau dans cette ligne pour qu'ils correspondent à ceux de votre réseau local.
Redémarrez chronyd .
[root@studentvm1 ~]# systemctl restart chronydPour autoriser d'autres hôtes de votre réseau à accéder à ce serveur, configurez le pare-feu pour autoriser les paquets UDP entrants sur le port 123. Consultez la documentation de votre pare-feu pour savoir comment procéder.
Tests
Votre hôte est maintenant un serveur NTP. Vous pouvez le tester avec un autre hôte ou une VM ayant accès au réseau sur lequel le serveur NTP écoute. Configurez le client pour utiliser le nouveau serveur NTP comme serveur préféré dans /etc/chrony.conf fichier, puis surveillez ce client en utilisant le chronyc outils que nous avons utilisés ci-dessus.
Chronyc comme outil interactif
Comme je l'ai mentionné plus tôt, chronyc peut être utilisé comme un outil de commande interactif. Exécutez simplement la commande sans sous-commande et vous obtenez un chronyc invite de commande.
[root@studentvm1 ~]# chronyc
chrony version 3.4
Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the
GNU General Public License version 2 for details.
chronyc>
Vous pouvez saisir uniquement les sous-commandes à cette invite. Essayez d'utiliser le suivi , ntpdata , et sources commandes. Le chronyque la ligne de commande permet le rappel et l'édition de commandes pour chronyc sous-commandes. Vous pouvez utiliser l'aide sous-commande pour obtenir une liste des commandes possibles et leur syntaxe.
Conclusion
Chrony est un outil puissant pour synchroniser les horaires des hôtes clients, qu'ils soient tous sur le réseau local ou dispersés dans le monde entier. Il est facile à configurer car, malgré le grand nombre d'options disponibles, seules quelques configurations sont nécessaires dans la plupart des cas.
Une fois mes ordinateurs clients synchronisés avec le serveur NTP, j'aime régler l'horloge matérielle du système à partir de l'heure du système (OS) en utilisant la commande suivante :
/sbin/hwclock --systohcCette commande peut être ajoutée en tant que tâche cron ou script dans cron.daily pour maintenir l'horloge matérielle synchronisée avec l'heure du système.
Chrony et NTP (le service) utilisent tous deux la même configuration et le contenu des fichiers est interchangeable. Les pages de manuel pour chronyd, chronyc et chrony.conf contiennent une quantité incroyable d'informations qui peuvent vous aider à démarrer ou à en savoir plus sur les options de configuration ésotériques.
Utilisez-vous votre propre serveur NTP ? Faites-le nous savoir dans les commentaires et assurez-vous de nous dire quelle implémentation vous utilisez, NTP ou Chrony.