Quelques aventures avec ntp

Rédigé par jdrien - - aucun commentaire
Ce billet va présenter deux problèmes liés aux décalages avec les serveurs de référence de temps que j'ai rencontré il y a quelque temps sur les serveurs que j'administre.

Autant sur un PC bureautique il n'est pas nécessaire de se préoccuper de la finesse de la synchronisation avec les serveurs de temps (une simple mise à l'heure par ntpdate @server_de_temps au boot devrait suffire), autant le problème de la gestion de l'horloge est primordiale dans un contexte de serveur. En effet, outre le fait que le serveur ne sera que rarement rebooté et donc que la solution du ntpdate au boot est alors inadaptée, il est nécessaire que l'horloge interne du serveur soit correctement gérée à la fois pour les échanges avec les autres serveurs et pour les applications hébergées sur ledit serveur. De nombreuses applications nécessitent une gestion du temps monotone et ne supporte pas les remises à l'heure violentes.

Nous avions régulièrement des serveurs qui avaient un décalage trop important avec leurs serveurs de référence. Normalement, si le décalage est acceptable alors le démon ntpd va progressivement rattraper la dérive, petit à petit. Mais si le décalage est trop important, alors la synchronisation sera forcée. Et ce n'est pas bien !

On voit apparaître les messages suivants dans la log du démon ntpd :
time reset -0.291613 s

Ces time reset sont assez violents ; ils interviennent si le décalage n'est pas compris entre -0.128s et 0.128s. On peut obtenir facilement le décalage actuel par la commande suivante :
# /usr/sbin/ntpdate -q @IP_serveur_de_temps
server @IP_serveur_de_temps, stratum 6, offset -0.013661, delay 0.02574
 1 Aug 14:09:07 ntpdate[9017]: adjust time server @IP_serveur_de_temps offset -0.136612 sec

 
Ici le décalage est -0.136 seconde, donc trop important.

Nous avons pu voir deux cas différents :
 - le décalage est dû à un bug dans le firmware du serveur ;
 - le décalage est dû à un mauvais choix dans la source de temps choisi par le système.

Suite à une mise système sur des serveurs (passage en noyau 2.6.18), nous avons pu observer des décalages fréquents et des resynchronisations plusieurs fois par jour.
 
Premier cas : quand un bug de firmware entraîne des décalages de temps...
Il faut savoir que le noyau 2.6.18 utilise comme source de temps hpet (High Precision Event Timer) et non plus tsc (Time Stamp Counter) comme avant (pour plus d'information sur les sources de temps disponibles on peut lire le document http://www.makelinux.net/books/ulk3/understandlk-CHP-6-SECT-1).

 - pour vérifier la source de temps utilisée :
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

 - pour visualiser les sources disponibles :
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies hpet tsc


- il est fortement conseillé d'utiliser hpet qui doit être le plus précis normalement. J'ai effectué un test en changeant hpet par acpi_pm et la dérive était toujours importante :
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

Le problème est que sur les serveurs que nous utilisions, des IBM x3850, un bug dans le firmware génère une dérive système importante. La version du firmware a donc un impact sur la gestion système du temps. Pour être honnête nous n'avions jamais pensé à regarder du côté des composants matériels pour contrôler cette gestion du temps !

Extrait du changelog du bios en v1.05 :
    *  IBM BIOS Flash Update System x3800/x3850/x3950/x3950E
          - Version 1.05, ZSE122A    (Suggested)
          > Problem(s) Fixed:
              - Fix operating system time drift, while using HPET.

              
Bien sûr nous utilisions une version plus ancienne (v1.04) qui était atteinte de ce fameux bug !

Nous avons pu procéder à la mise à jour du firmware, et depuis plus de soucis. La précision est au rendez-vous. J'ai effectué quelques mesures pendant deux jours avant la mise à jour du firmware : avec une prise de mesure par minute, la dérive moyenne constatée est de -0.224423 seconde. Cette dérive moyenne obligeait le démon ntpd à forcer la synchrnonisation environ 6 fois par jour. Après la mise à jour du firmware, nous avons constaté une dérive moyenne de 0.000773 seconde et plus aucune synchronisation forcée.

Second cas :
Si on peut mettre à jour un composant de type hpet pour améliorer la fiabilité, tant mieux. Mais si on ne dispose de ces composants ? C'est ce qui s'est passé sur un autre serveur, encore plus antique que les IBM x3850 du point précédent.

Dans le fichier de log de ntpd j'ai pu remarqué que les synchronisations forcées sont nombreuses (plus de 4 par jour parfois) :
     7 Aug 01:06:03 ntpd[17849]: time reset -0.167096 s
 
La dérive est donc importante et les écarts fluctuent.
Sur ces vieux serveurs, nous n'avons pas la chance d'avoir un composant type HPET et nous ne pouvions certainement pas chercher du côté des mises à jour de firmware.

Nous allons donc tenter de trouver une meilleure horloge.
 
Liste des sources de temps disponibles :
    [root] # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    acpi_pm jiffies tsc pit


Ces sources sont présentées dans l'ordre de préférence.
 
La source utilisée :
    [root] # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    tsc


Avec cette source (TSC : Time Stamp Counter) la moyenne du décalage est de 0.013591 seconde.
 
J'ai changé la source pour utiliser acpi_pm :
    echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

J'ai supprimé le fichier drift et j'ai relancé ntpd.
 
Depuis la modification la moyenne du décalage est de -0.003481 seconde. Pour que cette modification soit prise en compte lors du prochain reboot, il faut ajouter l'option clocksource=acpi_pm au noyau dans le fichier /boot/grub/grub.conf.
 
Pour plus d'information sur les horloges, voir la page http://www.makelinux.net/books/ulk3/understandlk-CHP-6-SECT-1.

Conclusion : si un décalage se produit, il faut toujours faire à la qualité de la source de temps interne au serveur.

Bilan : habituellement en cas de problème NTP (dérive, resynchronisation etc.) on aura tendance à chercher du côté de la configuration du démon ntpd, d'un bug dans ledit démon ou bien encore on aura tendance à chercher du côté des serveurs de référence. Bref, on restera à un niveau applicatif pour ce module système et on ne cherchera pas nécessairement au niveau système pur (gestion des firmwares, configuration des paramètres du noyau).

Écrire un commentaire

Les commentaires sont modérés a posteriori, donc pas la peine de spammer...

Quelle est la dernière lettre du mot lwwz ? :