Sur les serveurs Linux : configuration de Chrony/NTP, dérive du RTC et pièges de virtualisation

«L’heure n’est pas correcte» peut sembler banal, mais en exploitation c’est souvent le point de départ d’une réaction en chaîne : les certificats TLS sont considérés comme invalides, les connexions Kerberos échouent, les quorums de cluster basculent, les sauvegardes tombent dans des fenêtres de rétention incorrectes et les logs ne peuvent plus être corrélés proprement. Timekeeping sur Linux-serveurs est donc moins une question de confort qu’une discipline opérationnelle fondamentale. Parallèlement, l’heure est un sujet qui, dans les environnements modernes, déraille plus rapidement qu’auparavant à cause de la virtualisation, des images cloud, des workflows snapshot/RESTore et d’un matériel hétérogène.

Cet article rassemble des connaissances pratiques sur la configuration de Chrony/NTP, sur le rôle de la RTC (Real-Time Clock, c’est‑à‑dire l’horloge matérielle) et sur les pièges typiques de la virtualisation. L’objectif est une configuration qui, en fonctionnement normal, est stable, détecte rapidement les écarts et réagit de manière contrôlée en cas d’incident (p. ex. après reprise, RESTore de snapshot ou migration d’hôte) — sans introduire de « sauts temporels » comme risque latent dans la plateforme.

Timekeeping sur Linux-serveurs : pourquoi une heure correcte est critique en exploitation

De nombreux composants s’appuient sur une heure système monotone et crédible :

• TLS et vérification des certificats : si l’horloge est trop en avance ou en retard, les handshakes échouent (client et serveur évaluent « not before/not after »).
• Kerberos/SSO : la validité des tickets ne tolère que de faibles écarts. La dérive temporelle se comporte comme une erreur d’authentification.
• Journaux, SIEM, réponse aux incidents : les horodatages sont la colonne vertébrale de la corrélation. La dérive complique inutilement les analyses de root cause.
• Bases de données et réplication : timeouts, TTL, traces d’audit et tâches planifiées dépendent d’une horloge cohérente.
• Ordonnanceurs, cron, systemd-timers : les sauts peuvent provoquer l’exécution double ou l’omission de jobs.

Il est important de distinguer entre « régler l’heure » (wall clock) et « mesurer le temps » (temps monotone). Linux utilise des sources de temps monotone pour de nombreuses mesures, mais protocoles, certificats et journaux dépendent de la wall clock. C’est précisément là que les sauts et la dérive ont un impact.

Principes de base : distinguer clairement horloge système, RTC et sources de temps

Sur les serveurs classiques existent au moins deux horloges :

• Horloge système (kernel clock) : fonctionne en RAM et démarre au boot. Cette horloge est continuellement corrigée par NTP/Chrony.
• RTC (Real-Time Clock) : horloge matérielle alimentée par batterie sur la carte mère. Elle constitue la première référence au démarrage, avant que l’heure réseau ne soit disponible.

La RTC est réputée pour sa dérive (écart par unité de temps), car elle repose souvent sur un quartz bon marché, la température et le vieillissement jouent un rôle et les serveurs ne se trouvent pas toujours dans des environnements idéaux. La dérive est normale — ce qui compte, c’est la manière dont vous la gérez.

Un autre concept est le stratum : c’est la « distance » à la référence temporelle. Les serveurs stratum‑1 sont directement reliés à une référence (p. ex. GNSS, horloge radio, PTP/PHC), les stratum‑2 obtiennent l’heure depuis des stratum‑1, etc. En exploitation d’entreprise, les stratum‑2/3 sont courants et parfaitement suffisants, dès lors que la redondance et le monitoring sont en place.

Chrony vs NTP classique et systemd-timesyncd : que convient en exploitation serveur ?

Dans l’environnement Linux vous rencontrerez typiquement trois variantes :

• chronyd (Chrony) : client/serveur NTP moderne, robuste face à une connectivité variable, rapide à se régler et adapté aux machines virtuelles. Chrony est la solution par défaut dans de nombreuses distributions.
• ntpd (daemon NTP classique) : robuste, mais dans de nombreux environnements de plus en plus remplacé par Chrony. Fonctionne toujours, mais est souvent moins flexible en cas de conditions « non idéales ».
• systemd-timesyncd : client SNTP simplifié (NTP réduit). Acceptable pour des postes de travail ou des serveurs très simples, mais en exploitation professionnelle les fonctions de diagnostic et de serveur font souvent défaut.

Pour les administrateurs, Chrony est le choix pragmatique dans la plupart des cas : bonnes commandes de statut et de débogage, « slewing » contrôlé (correction progressive) et options de configuration claires pour les scénarios de virtualisation.

Etat des lieux : la synchronisation temporelle est-elle active et stable ?

Avant de reconfigurer : prendre l’état en compte afin de pouvoir comparer ensuite.

1) Vérification de base avec timedatectl

timedatectl status

Surveillez en particulier :

• System clock synchronized : indique si le service temporel rapporte une synchronisation.
• NTP service : quel service est actif (chronyd, systemd-timesyncd ou autre).
• RTC in local TZ : dans les environnements serveurs, cela devrait typiquement être no (RTC en UTC).

2) Statut Chrony : sources et écart

chronyc tracking
chronyc sources -v
chronyc sourcestats -v

Interprétation (brève et pragmatique) :

• System time / Last offset : l’écart actuel par rapport à la source sélectionnée.
• RMS offset : l’écart « typique », utile pour évaluer la tendance.
• Frequency : à quel point l’horloge locale doit être corrigée (ppm). Des valeurs anormalement élevées peuvent indiquer une source d’horloge instable ou des problèmes liés à la virtualisation.
• sources : montre les serveurs joignables, le stratum, le delay/jitter. La redondance est importante : plusieurs sources doivent être joignables de manière stable.

3) Journaux : identifier sauts et événements de resynchronisation

journalctl -u chronyd --since "-7 days" | tail -n 200

Recherchez des mentions comme « stepped », « makestep », « reset », « time jump ». Des sauts récurrents sont un signal d’alerte, car ils peuvent affecter les timers, les bases de données et les mécanismes de sécurité.

Configurer Chrony : sources stables, stratégie de correction claire

Une configuration robuste commence par une stratégie claire de sources de temps. Dans les réseaux d’entreprise, les options typiques sont :

• serveurs NTP internes (recommandés) : contrôlables de manière centralisée, compatibles avec le pare-feu, politique cohérente.
• pools publics (uniquement si autorisés) : par ex. sources basées sur un fournisseur ou sur un pool, mais avec vérification de la politique et de la conformité.
• référence locale (repli) : par ex. une source « local » comme dernière instance — avec une grande prudence, pour éviter de propager involontairement une « fausse heure » dans le réseau.

Exemple : Chrony en client avec des sources de temps internes

Le chemin et les détails varient selon la distribution (souvent /etc/chrony/chrony.conf ou /etc/chrony.conf). L’exemple suivant montre un schéma typique : plusieurs sources, comportement step contrôlé lors du démarrage, statistique de drift stable.

# /etc/chrony/chrony.conf (Beispiel)

# Mehrere, voneinander unabhängige NTP-Server (idealerweise unterschiedliche Hosts/Standorte)
server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst

# Drift-Datei: Chrony lernt die Frequenzabweichung Ihrer Hardware/VM
# (Pfad je nach Distribution)
driftfile /var/lib/chrony/chrony.drift

# Schnelles Einregeln nach Boot: bei großen Abweichungen wenige Male „step“ erlauben,
# danach nur noch slewing (schrittweise) korrigieren.
makestep 1.0 3

# RTC beim Stop/Start aktualisieren, damit Boot-Zeit plausibler ist
rtcsync

# Optional: Wenn der Host nur selten Netz hat, kann eine Offline-Strategie sinnvoll sein
# (hier nicht aktiviert)
# offline

# Logging sparsam, aber ausreichend für Troubleshooting
logdir /var/log/chrony
# log measurements statistics tracking

Pourquoi ces paramètres ? „iburst“ accélère la mesure initiale après le démarrage. „makestep“ autorise quelques sauts brutaux au départ pour atteindre rapidement une plage plausible. Ensuite, vous évitez les step car ils ont des effets secondaires en production. „rtcsync“ garantit que la RTC reçoit régulièrement l’heure corrigée, ce qui stabilise les phases de démarrage — sans idéaliser la RTC comme vérité primaire.

Redémarrer et valider Chrony

systemctl enable --now chronyd
systemctl RESTart chronyd
chronyc tracking
chronyc sources -v

Après la mise en place, la synchronisation devrait se stabiliser en peu de temps. Sinon, les causes sont le plus souvent les chemins réseau (UDP/123), le DNS, les règles du pare-feu ou des problèmes de source temporelle.

Comprendre et maîtriser la dérive de la RTC : UTC, hwclock et scénarios d’erreur typiques

Beaucoup de problèmes de temps ne proviennent pas du NTP, mais du démarrage : si la RTC est nettement hors de sync, le système démarre avec une heure incorrecte. Les services qui s’exécutent très tôt (p. ex. journalisation, contrôles de sécurité précoces, certains agents) écrivent alors des horodatages « faux » avant la correction par le NTP.

Configurer la RTC en UTC (standard pour l’exploitation des serveurs)

La ligne claire est : RTC en UTC, fuseau horaire en Linux via tzdata/Zoneinfo. « RTC en local TZ » entraîne, en particulier avec DST (heure d’été/hiver) et les scénarios de dual-boot, des cas particuliers inutiles.

timedatectl set-timezone Europe/Berlin
timedatectl set-local-rtc 0

Le fuseau horaire est une couche de présentation. Pour les protocoles, les clusters et les systèmes distribués, l’UTC fait office de base commune.

Vérifier l’état de la RTC et rendre la dérive visible

hwclock --verbose
hwclock --show
date -u

Si la RTC et l’heure système divergent nettement, clarifiez d’abord : NTP/Chrony est-il correctement configuré ? La RTC est-elle réellement persistante (pile/réglages UEFI) ? Dans les VMs, la « RTC » est souvent virtuelle et dépend du timing de l’hyperviseur.

Quand « rtcsync » aide — et quand non

« rtcsync » (dans Chrony) synchronise périodiquement la RTC à partir de l’heure système. Cela aide si la RTC ne dérive que modérément. En revanche, si la RTC est extrêmement instable (pile vide, matériel défectueux, timing agressif de la virtualisation), l’utilisation de « rtcsync » écrira certes des valeurs « correctes », mais n’éliminera pas la cause. Dans ce cas, il faut du monitoring et, le cas échéant, une réparation matérielle ou une correction côté hôte.

Pièges de la virtualisation : dérive temporelle, problèmes de TSC, Snapshot/RESTore et Live-Migration

Dans les VMs, s’ajoute une couche supplémentaire : le guest voit une horloge virtuelle influencée par l’hyperviseur. Causes typiques de dérive et de sauts :

• Overcommit de l’hôte et CPU-steal : si les vCPU ne tournent pas régulièrement, la VM « manque » des intervalles de temps.
• Pause/Resume, Suspend : la VM a été arrêtée, l’horloge murale (wall clock) saute au resume.
• Snapshots/RESTore : un RESTore peut remettre la VM dans un « passé » — horodatages, certificats et logs deviennent alors incohérents.
• Live-Migration : selon la plateforme, la source d’horloge et l’émulation des timers peuvent changer.

Un terme important est TSC (Time Stamp Counter) : un compteur CPU pouvant servir de base temporelle. En virtualisation, le TSC est émulé ou transféré de manière « stable ». Si le TSC n’est pas stable ou change lors d’une migration, le guest perçoit des « saccades » temporelles.

Règle d’or : une seule instance doit modifier l’heure de manière « brute »

Beaucoup d’hyperviseurs proposent des « Guest Tools » qui corrigent activement l’heure dans le guest (parfois par des sauts brusques). En parallèle, Chrony/NTP tourne dans le guest. Si les deux interviennent, vous obtenez un comportement mixte difficilement reproductible : Chrony observe des sauts, estime des sources comme non fiables ou contre-régule en permanence.

Recommandation pratique :

• Dans les VMs : utiliser Chrony comme service de temps principal dans le guest.
• Ne laisser la synchronisation horaire de l’hyperviseur active que s’il existe une politique claire (p. ex. uniquement au démarrage) et si elle ne concurrence pas Chrony.

La manière exacte de configurer cela dépend de VMware, Hyper-V, KVM/QEMU, Proxmox ou des hyperviseurs cloud. L’essentiel est le principe : pas de « régleurs d’heure » concurrents.

Après Snapshot/RESTore : vérifier de façon contrôlée avant de démarrer les applications

Un RESTore depuis un snapshot est fondamentalement un « saut temporel ». Si la VM revient dans le passé, les effets suivants peuvent survenir :

• Les certificats semblent « pas encore valides » ou déjà expirés (selon le sens du saut).
• Journald/rotation des logs provoque des discontinuités ou des plages de temps dupliquées.
• L’authentification basée sur des tokens (OIDC, Kerberos) échoue.

Il est opérationnellement utile d’avoir un point de contrôle fixe dans le Runbook: après un RESTore, stabiliser d’abord le service temporel, puis démarrer les applications. Si vous utilisez systemd, vous pouvez modéliser les dépendances via „network-online.target“ et les ordres de démarrage des services. L’important est le principe, pas nécessairement une conception de Unit précise.

Playbook de dépannage: en cas de dérive ou de saut d’heure

Au quotidien, une séquence de vérification reproductible est plus importante que „la théorie parfaite“. Le playbook ci‑dessous est structuré pour vous permettre de distinguer rapidement entre réseau, configuration, hyperviseur et matériel.

Étape 1: un service temporel est‑il actif?

timedatectl status
systemctl list-unit-files | grep -E "chrony|ntp|timesync"
systemctl status chronyd --no-pager

Si plusieurs services sont actifs (p. ex. chronyd et systemd-timesyncd), choisissez délibérément l’un d’entre eux et désactivez l’autre afin d’éviter les «double corrections».

Étape 2: atteignez‑vous les sources NTP?

NTP utilise généralement UDP port 123. Les pare‑feu et les groupes de sécurité sont une cause fréquente d’état «unsynchronized».

chronyc sources -v
chronyc activity
ss -anu | grep ":123" || true

Si des sources apparaissent comme unreachable: vérifier le DNS, le routage/le pare‑feu, et s’assurer que la source parle bien NTP (pas uniquement SNTP derrière un load balancer sans stabilité UDP).

Étape 3: forte divergence après le boot ou le RESTore?

Si des systèmes démarrent avec une forte dérive, les services peuvent écrire des horodatages erronés durant les premières minutes. Vérifiez le RTC et la politique Chrony («makestep»). Un step peut être utile pour une correction ponctuelle, mais pas comme fonctionnement permanent.

chronyc tracking
hwclock --show
journalctl -u chronyd --since "-24 hours" | grep -Ei "step|jump|makestep|reset"

Étape 4: indicateurs spécifiques aux VM

Si la dérive apparaît surtout sous charge, le CPU‑steal/overcommit est un candidat. On observe alors souvent des «spikes» dans les offsets, pas seulement une dérive constante.

uptime
vmstat 1 5
chronyc sourcestats -v

Interprétation: une longue run‑queue, des valeurs fluctuantes et des motifs jitter/delay instables indiquent des problèmes d’ordonnancement. Dans ces cas, ajouter davantage de sources NTP ne résout pas le problème; il faut des corrections de ressources ou de l’hôte.

Bonnes pratiques pour environnements cloud et hybrides

Dans les environnements cloud et hybrides, des contraintes supplémentaires se combinent: les images sont clonées, les instances mettent en veille, les chemins réseau changent, et il existe souvent des services temporels spécifiques au provider. Règles pratiques:

• Plusieurs sources temporelles: au moins trois, idéalement issues de domaines de défaillance différents (p. ex. deux internes, une externe ou un service proche du provider – selon la politique).
• Monitoring plutôt que l’intuition: Offsets, jitter, reachability et états «unsynchronized» doivent être intégrés à votre monitoring.
• Pas de step en exploitation normale: les steps uniquement de manière contrôlée (Boot/Initialisation) ou en cas d’incident selon le Runbook.
• Prendre en compte les images immuables: les fichiers de dérive et les chemins de persistance (p. ex. /var/lib/chrony) doivent être prévus dans la stratégie d’image, sinon Chrony «n’apprend» jamais et se comporte à chaque redémarrage comme fraîchement installé.

Checklist de monitoring: ce qui doit réellement déclencher une alerte

Toute dérive n’est pas un incident. Des critères d’alerte pertinents portent plutôt sur des états et des tendances:

• chronyd nicht aktiv ou « System clock synchronized: no » pendant une longue période.
• Aucune source joignable (la reachability disparaît).
• Décalage au-dessus du seuil pendant X minutes (seuil selon l’application, p. ex. plus strict pour Kerberos).
• Sauts/Steps fréquents dans les logs (indication de sources de temps concurrentes ou de problèmes VM).

Pour les liens internes de votre magazine, il est typiquement pertinent de renvoyer vers des Monitoring-Runbooks (métriques, alertes, escalade), afin que le temps ne soit pas seulement « configuré », mais aussi « opérationnalisé ».

Stratégie de repli : que faire si l’heure est « cassée » ?

La situation la plus délicate est une heure massivement erronée dans des systèmes proches de la production. Un saut incontrôlé peut causer plus de dégâts qu’une correction lente. Une stratégie de repli pragmatique comprend trois éléments : endiguement, correction, validation.

1) Endiguement : limiter l’impact

• Si possible : retirer l’instance affectée du load balancer ou mettre les services en mode « read-only »/maintenance.
• Empêcher que l’instance propage une heure erronée aux autres (si elle est elle‑même serveur NTP : désactiver temporairement la distribution NTP).

2) Correction : contrôlée plutôt que précipitée

Si l’écart est faible à moyen, privilégiez le slewing (correction progressive). Pour des écarts très importants, un step peut être inévitable — mais alors de manière planifiée : prendre en compte les applications, réévaluer les tokens/SSO, prévoir la cohérence des logs.

Une approche courante est de laisser Chrony faire son travail et de n’autoriser temporairement le comportement de step qu’en cas d’incident. Ne modifiez pas les politiques de façon permanente « au cas où ».

3) Validation : que faut-il vérifier après une modification de l’heure ?

• Auth : Kerberos/SSO, jetons API, comptes de service.
• TLS : tester les points de terminaison critiques avec certificats, en particulier les connexions mTLS.
• Scheduler : vérifier cron/systemd-timers pour des exécutions en double, appliquer le cas échéant les runbooks de jobs.
• Logs : marquer la fenêtre temporelle pour que l’Incident Response classe correctement l’anomalie.

Pièges fréquents au quotidien (et comment les éviter)

Piège 1 : « RTC in local TZ » et chaos DST

Si le RTC est basé sur l’heure locale, les horodatages se décalent lors du passage DST et l’ordre de démarrage devient difficile à expliquer. Solution : RTC en UTC, fuseau horaire uniquement pour l’affichage.

Piège 2 : une seule source temporelle

Un serveur NTP unique est un point de défaillance unique. Même s’il paraît stable : maintenance, problèmes DNS ou changements de routage suffisent à provoquer une dérive. Solution : au moins trois sources.

Piège 3 : synchronisation concurrente du temps dans les VM

Les outils de l’hyperviseur fournissent l’heure, Chrony fournit l’heure, et les deux interviennent avec des stratégies différentes. Solution : désignation claire d’un propriétaire, documentée dans le standard de la plateforme.

Piège 4 : les snapshots interprétés comme « état sûr »

Les snapshots ne constituent pas une ancre temporelle consistante. Après un RESTore, il est impératif de valider l’heure. Solution : runbook de RESTauration avec vérification de l’heure avant le démarrage des applications.

Conclusion : le temps est de l’infrastructure — et requiert de la discipline opérationnelle

La gestion du temps sur les serveurs Linux est robuste lorsque vous combinez trois éléments : des sources propres (redondantes et accessibles), une stratégie de correction contrôlée (sauts uniquement ciblés) et une vision réaliste du RTC et de la virtualisation (la dérive est normale, les sauts constituent des risques). Chrony est un outil pragmatique pour cela, mais ce qui est décisif, c’est le modèle d’exploitation : supervision, runbooks pour les incidents et des règles claires pour les mécanismes d’horloge des VM.

Si vous ancrez ces standards dans les templates de build et la documentation d’exploitation, les problèmes de temps ne disparaissent pas «magiquement» — mais ils deviennent rares, rapidement diagnostiquables et, surtout, maîtrisables.

Pour ce sujet, les serveurs NTP Linux et la synchronisation temporelle Linux sont également importants. L’article remet ces aspects en perspective de manière compréhensible et montre ce qui compte au quotidien.