NTP - Emmanuel de Castro

Transcription

Emmanuel De Castro
Xavier Perrin
Systèmes distribués
Mars 2005
Master 2 TIIR
NTP Network Time Protocol
Xavier Perrin – Emmanuel De Castro
Sommaire
So mma ire ..... .... .... .... .... .... ..... .... .... .... . ... .... ..... .... .... ... 2
Int ro du ct io n . .... .... .... .... .... ..... .... .... .... . ... .... ..... .... .... ... 3
I L a def i nit io n du t e mps ... ..... .... .... .... .... .. .. ..... .... .... ... 4
1) Le temps ................................................................................. 4
2) Le transport du temps............................................................... 5
3) Les besoins en informatique....................................................... 6
II Le s pro to co les de sy nc hro nis at io n du t emps . .... .... ... 7
1) TP .......................................................................................... 7
A)
Présentation....................................................................... 7
B)
Mécanisme. ........................................................................ 7
C)
Les limites de ce protocole. .................................................. 7
2) NTP ........................................................................................ 8
A)
Présentation....................................................................... 8
i) Bref historique.................................................................... 8
ii)
Les évolutions de NTP....................................................... 8
B)
Les modes d’utilisation ........................................................ 8
C)
Architecture ..................................................................... 10
i) Généralités ...................................................................... 10
ii)
L’architecture réseau ...................................................... 10
iii)
L’architecture système .................................................... 12
D)
La mise à l’heure .............................................................. 13
i) Gestion des messages ....................................................... 13
ii)
Réglage de l'horloge ....................................................... 14
3) SNTP .................................................................................... 15
II I Le s o ut il s dis po nibl es . ..... .... .... .... .... .. .. ..... .... .... . 16
1) Les différents type de serveurs primaire .................................... 16
A)
Serveur par horloge GPS.................................................... 16
B)
Serveur par horloge atomique ............................................ 16
C)
Serveur rackable par horloge GPS....................................... 16
D)
Serveur rackable par horloge atomique ............................... 17
2) Un exemple de serveur primaire: chronos.univ-rennes1.fr ........... 17
A)
Présentation..................................................................... 17
B)
Architecture ..................................................................... 18
3) Les clients ............................................................................. 18
C)
Pour Windows................................................................... 18
D)
Pour Linux ....................................................................... 18
4) Quelques utilitaires en detail .................................................... 19
A)
ntptrace........................................................................... 19
B)
ntpq ................................................................................ 19
Co nc lus i o n ... .... .... .... .... ..... .... .... .... .... . ... ..... .... .... .... . 20
Page 2 sur 20
Mars 2005
Introduction
De nos jours, la plupart des équipements électroniques possèdent une
horloge ; l’informatique n’échappant pas à cette règle, les ordinateurs disposent
d’horloges matérielles et logicielles. Ces horloges, bien que conçues autour d'un
oscillateur à quartz, dérivent comme toutes montres ordinaires.
Ceci est d'autant plus gênant lorsque les machines sont interconnectées
entre elle pour former un réseau ; en effet, lors de leurs diverses
communications, elles sont amenées à estampiller leurs messages avec l’heure
et il peut apparaître que les messages arrivent avant qu’ils ne soient partis si les
horloges des différentes machines ne sont pas synchronisées !
D’autres problèmes peuvent survenir si ces machines partagent des
ressources communes comme des systèmes de fichiers ; certains outils de
développement, comme la commande Unix "make", basent leur travail sur la
comparaison des dates de modification de fichiers. Si les horloges ne sont pas
synchronisées des messages étranges peuvent apparaître !
xavier@tuxy /mnt/boutique $ make compil
make: Warning: File `Makefile' has modification time 52 s in the future
gcc -o hello test.c
make: warning: Clock skew detected. Your build may be incomplete.
De même, la cohérence et la comparaison de messages de "logs" de
plusieurs systèmes deviennent très difficiles s'ils ne sont pas à la même heure.
La nécessité de synchroniser des équipements en réseau paraît alors
évidente. C'est le but du protocole Network Time Protocol (NTP) ; il synchronise
les horloges des machines le plus précisément possible.
Afin de mieux comprendre la technique de synchronisation des horloges
des machines nous allons dans une première partie définir ce qu’est exactement
le temps, et quel référentiel adopter, puis nous verrons dans une seconde partie
comment fonctionne le protocole NTP et enfin nous ferons un tour d’horizons sur
les différents outils disponibles.
Page 3 sur 20
Mars 2005
I
La
L a d e finition du temps
1) Le temps
Afin de mesurer le temps, nous avons besoin d’une échelle, d’une origine
et d’une unité. L’astronomie en fournis plusieurs : rotation de la terre sur ellemême ou autour du soleil.
On attend d’une échelle quelle soit universelle (utilisée par le plus grand
nombre de personnes possibles), pérenne (il faut que cette échelle ne puisse être
interrompue, et créer des trous dans la mesure du temps), accessible (chacun
doit pouvoir accéder à la lecture du temps sans difficulté), précise (la lecture doit
avoir la meilleure précision possible) et uniforme (la valeur des mesures ne doit
pas dépendre du temps ou du lieu où l'on fait les mesures)
Si on prend comme oscillateur la rotation de la terre sur elle-même, on
s'aperçoit que cette rotation n'est pas uniforme sur quelques jours, ce qui
conduit à l'élaboration du temps solaire moyen basé sur un soleil moyen fictif
dont les passages au méridien sont séparés par des intervalles égaux subdivisés
en périodes de 24 heures ou 86400 secondes.
Le temps solaire moyen du point de l'observatoire de Greenwhich
augmenté de 12 heures est appelé temps universel (TU). Or ce temps universel
n'est pas à son tour uniforme à cause de diverses irrégularités physiques dont le
déplacement des pôles. On aboutit à un temps universel corrigé nommé TU2.
Si on prend comme oscillateur la rotation de la terre autour du soleil, on
définit un temps appelé temps des éphémérides (TE). Ce temps est connu avec
moins de précision que TU, mais a l'avantage d'être plus uniforme.
Ces temps obtenus sont différents; la seconde universelle n'est pas la
même que la seconde des éphémérides.
Depuis 1955 avec l'apparition des horloges atomiques on s'est aperçu de la
dérive des secondes définies au moyen des horloges naturelles. On utilise
maintenant des oscillateurs artificiels plus précis que sont les horloges à quartz
et les horloges atomiques. Celles-ci sont utilisées plus comme étalon de
fréquences ou garde temps que comme mesure directe du temps. Les horloges à
quartz sont des oscillateurs mécaniques basés sur la vibration d'un cristal de
quartz taillé suivant une certaine forme. Deux cristaux de quartz ne sont jamais
taillés de la même manière et ne sont donc pas exactement tous à la même
fréquence. Les horloges atomiques sont elles basées très schématiquement par
la fréquence émise lors du changement de transition d'un atome de gaz excité. Il
existe deux catégories d'horloges atomiques. Les unes sont des garde temps
beaucoup plus stable que les horloges à quartz; les autres constituent des
étalons absolus de fréquences et sont à la base de la définition moderne de la
seconde, c'est ce qu'on appelle le temps atomique (TA). Naturellement ce temps
atomique va dépendre du type de gaz dont on va mesurer la fréquence de
transition.
Page 4 sur 20
Mars 2005
Le petit tableau ci-dessous donne les différentes précisions des temps
définis ci-dessus:
TEMPS
TU
TE
TA césium
PRECISION
10^-3
10^-1
10^-13
UNIFORMITE
10^-7
10^-9
10^-13
Le temps légal défini par la seconde légale a été basé
Sur le temps universel (TU) jusqu'en 1956
Sur le temps des éphémérides (TE) de 1956 à 1967
Sur le temps atomique à jet de césium à partir de 1967
Jusqu'en 1956 la seconde légale était définie comme la 86400ème partie du jour
solaire moyen.
A partir de 1956 la seconde des éphémérides a été définie par le comité
international des poids et mesure comme étant la fraction 1/31556925.9747 de
l'année tropique pour 1900 janvier 0 à 12 heures de temps des éphémérides.
Depuis 1967 la seconde légale est définie comme la durée de 9 192 631
770 périodes de la radiation correspondant à la transition entre les deux niveaux
hyperfins de l'état fondamental de l'atome de césium 133.
2) Le transport du temps
La mesure du temps ne suffit pas pour pouvoir utiliser le temps, car les
oscillateurs choisis, naturels ou artificiels, ne sont pas directement utilisables par
le commun de mortels. C'est pourquoi on distingue les horloges primaires et les
horloges secondaires.
Les horloges primaires, naturelles ou artificielles, servent d'étalon sur lesquels
on va se synchroniser. Les horloges secondaires sont synchronisées sur les
horloges primaires et servent à transporter le temps. C'est le cas classique est
très utilisé des montres et autres réveils.
Avec l'apparition des télécommunications il est maintenant possible de
transporter le temps au moyen de signaux radios. Et l'on sait synchroniser les
différents étalons de fréquence entre eux sur la planète pour obtenir un temps
moyen coordonné appelé temps universel coordonné (TUC). Naturellement ce
temps est moins précis que celui des horloges atomiques puisqu'il faut tenir
compte des délais de transmission des signaux.
Il y a à travers le monde plusieurs sites officiels de transmission du temps
par des tops radio. En France c'est l'émetteur de TDF qui est chargé de la
transmission.
Les différents temps que l'on vient de mettre en évidence, temps solaire
moyen, temps universel, temps des éphémérides, temps atomique et temps
Page 5 sur 20
Mars 2005
universel coordonné, sont tous différents et ne sont pas utilisés pour le même
usage.
L'usage du temps qui nous intéresse ici est celui du service de l'heure pour
la vie quotidienne, c'est donc le temps universel (TU). Mais comme la seconde
est définie à partir des étalons atomiques il faut réajuster l'heure régulièrement
afin que le soleil passe toujours au méridien de Greenwich à midi. Ce
réajustement a lieu si nécessaire fin juin ou fin décembre, et l'on ajoute ou
enlève une seconde à la minute courante. C'est ainsi que de temps en temps il y
a des minutes qui font 61 secondes ou parfois 59 secondes
3) Les besoins en informatique
L’informatique possède de nombreuses applications nécessitant que les
horloges entre les machines du réseau soient synchronisées ; voici une liste non
exhaustive mais représentative de certaines de ces applications.
Bases de données distribuées
Transactions
Journalisation
Logs
estampilles de documents sécurisés
certification et cryptographie
Aviation
Programmation télévision et radio
synchronisation pour les téléconférences en temps réel
Gestion des réseaux
On peut également généraliser à toutes applications distribuées.
Page 6 sur 20
Mars 2005
II
Les protocoles de
synchronisation du temps
Comme nous l’avons vu, il est important, en informatique, de synchroniser
les horloges des différents éléments actifs d’un réseau. Pour cela, plusieurs
protocoles sont apparus, chacun étant défini par une RFC.
1) TP
A) Présentation.
Time Protocol (TP) est le protocole de synchronisation du temps le plus
ancien. Il date de 1983 et est défini par la RFC 868.
Etant donné l’utilité d’un tel mécanisme, il a rapidement été populaire,
notamment sur les systèmes Unix par le biais du démon timed et de la
commande rdate.
B) Mécanisme.
Le mode fonctionnement de TP est simple. Un client fait une requête à un
serveur sur le port 37. Le serveur répond au client par l’envoi d’un entier
contenant le nombre de secondes écoulé depuis le premier janvier 1900 à 0h. Le
client utilise cette valeur pour mettre à jour son horloge.
C) Les limites de ce protocole.
Le fonctionnement TP est beaucoup trop simple. On peut le résumer à
l’envoi de l’heure (sous forme de secondes) par un serveur vers un client.
L’heure ainsi transmise et l’heure du serveur au moment de la réponse. On se
rend bien compte qu’il est impossible d’obtenir une précision supérieure à la
seconde. De plus, cette valeur du temps n’est pas précise car elle ne prends pas
en compte le temps mis par le paquet pour transiter sur le réseau. Cela n’a
toutefois pas d’influence car la durée du transport est, en principe, inférieure à la
seconde.
Page 7 sur 20
Mars 2005
2) NTP
A) Présentation
i)
Bref historique
Pour résoudre les problèmes soulevés par le protocole TP, un autre
protocole de synchronisation des horloges est développé sous le nom d’Internet
Clock Service. Ce n’est qu’en 1988 qu’apparaît la première version de NTP.
La version de NTP la plus récente actuellement est la version 4. Elle est
basée sur NTP version 3 (qui était basé sur la version 2 et sur le Digital Time
Synchronisation Service (DTSS) de DEC) et y ajoute un certain nombre
d’améliorations. Elle est apparue en 1994.
ii)
Les évolutions de NTP
Les principales évolutions de NTP concernent les algorithmes de mise à
jour des horloges locales, cela dans le but d’augmenter la précision (on atteint
une précision de 10-3 seconde en LAN) D’autres fonctionnalités sont
implémentées telles que le chiffrement des paquets ou la gestion de IP v6.
Voyons plus précisément les améliorations apportées par la version 4 :
Augmentation de la précision (précision 10 fois plus forte).
Fourni un nouveau modèle de gestion de l’horloge locale.
L’augmentation significative de la précision, permet d’augmenter les délais
entre les synchronisations. Cela permet de diminuer le nombre de requêtes sur le
serveur et une utilisation moindre de la bande passante du réseau.
B) Les modes d’utilisation
Sauf dans le mode broadcast, une association est créée quand deux
machines échangent des messages. Une association peut fonctionner dans un
des cinq modes suivants :
Mode symétrique actif:
Un serveur fonctionnant dans ce mode envoie périodiquement des
messages, sans se soucier de l'état de ses voisins (joignables, serveurs primaires
ou secondaires, clients). Il indique ainsi sa « volonté » de synchroniser d'autres
serveurs et d'être synchronisé par eux.
Page 8 sur 20
Mars 2005
Mode symétrique passif:
Ce type d'association est généralement créé lors de l'arrivée sur le serveur
d'un message d'un autre serveur (en mode symétrique actif). Le serveur
annonce son intention de synchroniser et d'être synchronisé. Seulement il ne le
fait qu'après avoir été sollicité par un autre serveur.
Mode client:
La machine envoie des messages régulièrement, sans se préoccuper de
l'état de ses voisins. La station (typiquement, elle appartient à un réseau LAN)
indique ainsi sa « volonté » d'être synchronisée.
Mode serveur:
L'association de ce mode est créée lors de la réception d'une requête (un
message) d'une station en mode client.
Mode broadcast:
Destiné aux réseaux locaux, il se limite à une diffusion d'informations
horaires pour des clients pouvant être soit passifs, soit découvrant ainsi les
serveurs avec lesquels ils vont se synchroniser.
Les simples clients se synchronisent en mode client/serveur s'ils sont
isolés, ou en mode multicast s'ils font partie d'un réseau (ex : machines
universitaires se synchronisant sur plusieurs serveurs de strate 3, comme les
serveurs des départements universitaires).
Une station en mode client envoie de temps en temps un message NTP à
une station en mode serveur, généralement peu de temps après avoir
redémarré. Le serveur n'a pas besoin d'enregistrer des informations sur l'état du
client, puisque c'est le client qui décide quand envoyer une requête, en fonction
de son état en local. Dans ce mode, le fonctionnement pourrait être simplifié en
un mécanisme de RPC sans perdre de précision ni de robustesse, surtout dans le
cadre d'un réseau LAN à haut débit.
Dans les modes symétriques, la distinction client/serveur disparaît. Le
mode passif est destiné aux serveurs de temps qui se trouvent près de la racine
du système de synchronisation (les serveurs de la strate 1 ou 2).
Le mode symétrique actif est destiné aux serveurs de temps qui se
trouvent près des feuilles du réseau de synchronisation, sur les strates les plus
élevées. La fiabilité du service de temps peut être généralement assurée avec
deux stations sur le niveau au-dessus (strate plus petite) et une station sur le
même niveau.
Normalement, une station fonctionne en mode actif (symétrique, client ou
broacast) avec une configuration donnée au démarrage, alors que les autres sont
en mode passif (symétrique ou serveur) sans configuration préalable.
Cependant une erreur intervient lorsque deux stations qui communiquent
sont dans le même mode, sauf pour le mode symétrique actif. Dans ce cas,
Page 9 sur 20
Mars 2005
chaque station ignore les messages de l'autre et l'association créée par cet
échange n'est rompue qu'en cas de coupure de réseau entre les deux stations.
Le mode broadcast est surtout destiné aux réseaux locaux avec beaucoup
de stations et où la précision requise n'est pas très importante. Le déroulement
classique est le suivant : un ou plusieurs serveurs de temps du réseau envoie
régulièrement des broacasts aux stations, pour déterminer l'heure, avec une
latence de l'ordre de quelques millisecondes.
Comme dans le mode client/serveur, le protocole utilisé peut être simplifié.
Ainsi, un système basé sur l'algorithme de sélection d'horloge peut être utilisé
dans le cas où on dispose de multiples serveurs de temps, afin d'optimiser la
fiabilité.
NTP intègre un système d'exploration du réseau pour découvrir
automatiquement de nouveaux serveurs NTP, par différentes méthodes :
Multicast :
1. Les serveurs inondent périodiquement le réseau local par un
message multicast.
2. Les clients utilisent le mode client/serveur lors du premier contact
pour mesurer le temps de propagation puis restent en écoute.
Manycast : (mode plus précis)
1. Les clients inondent le réseau local par un message multicast.
2. Les serveurs répondent en multicast.
3. Les clients communiquent ensuite avec les serveurs comme s'ils
avaient été configurés en unicast.
Des contrôles de time-out et de TTL garantissent le bon déroulement de la
configuration.
C) Architecture
i)
Généralités
NTP est un protocole basé sur UDP pour le transport et sur IP pour
l’adressage. Il est disponible sur le port 123.
ii)
L’architecture réseau
L’architecture réseau de NTP a deux caractéristiques principales : la
hiérarchisation des serveurs et leurs redondances. Nous allons les présenter dans
les deux parties qui suivent.
Page 10 sur 20
Mars 2005
a) La structure en strate de NTP
Les serveurs NTP suivent une hiérarchisation bien définie. En théorie, nous
pouvons observer jusqu’à 15 niveaux de couche différente. En pratique, nous ne
dépasserons rarement la 5ème couche.
Chaque couche n’est pas libre d’agir à sa guise. Tout est réglementé :
Un serveur NTP de couche 1 se synchronise sur une source de référence,
dites sources primaires (récepteur GPS, horloge atomique, …). Ces serveurs sont
déclarés officiellement. Il en existe très peu sur le réseau.
Un serveur de strate 2 se synchronise sur un serveur de strate 1. Ils sont
également déclarés officiellement.
Un serveur de strate supérieur à 2 se synchronise sur un serveur de strate
inférieur. Ils ne sont pas déclarés. Ainsi, tout site informatique peut installer un
serveur NTP de strate 3 sur son réseau et synchroniser l’ensemble de son parc
de machine avec. Ils ont toutefois l’obligeance de prévenir les administrateurs du
serveur sur lequel il se connectera.
Source
primaire
Serveur
(1)
Serveur
(2)
Serveur
(3)
Serveur
(2)
Serveur
(3)
Serveur
(1)
Serveur
(2)
Serveur
(3)
Serveur
(5)
Page 11 sur 20
Serveur
(4)
client
Serveur
(2)
Serveur
(3)
Serveur
(3)
client
client
Serveur
(4)
Serveur
(1)
client
Serveur
(2)
Serveur
(3)
client
Serveur
(4)
client
client
Mars 2005
Notons qu’un simple client n’est pas autorisé à se connecter sur des
serveurs de couche inférieure à 3.
Ce principe permet de bien répartir la charge des serveurs. De plus, en
choisissant un serveur de synchronisation proche, on réduit la distance et on
diminue ainsi les erreurs dues au temps de transport de l’heure.
b) La redondance du protocole
A la vue du schéma précédent, apparaît un problème : lorsque qu’un
serveur de couche basse ou qu’une source primaire est indisponible, toutes les
machines se synchronisant sur cette branche ne sont plus à l’heure. Pour palier
cela, la structure réseau de NTP est redondante. En effet, il est possible de
configurer les serveurs de telle façon à ce qu’ils utilisent plusieurs sources de
référence. Par exemple, un serveur de strate 1 se synchronisera à l’aide de
plusieurs sources primaire. Il est même possible d’utiliser des serveurs de même
niveau en mode symétrique.
iii)
L’architecture système
Maintenant que nous avons vu comment l’heure est transmise de la source
primaire vers les serveurs, nous allons nous intéresser aux opérations effectuées
en interne par le serveur après réception des réponses par les sources de
synchronisation.
Comme nous l’avons vu, un serveur se connecte sur un ou plusieurs
serveurs de strate inférieure ou égale à la sienne. Il est donc susceptible de
recevoir plusieurs heures différentes. Les réponses sont donc dans un premier
temps analysé afin de ne prendre en compte que les valeurs conforment aux
attentes du protocole. On estime que cette phase permet déjà de réduire les
erreurs par un facteur de 10. Ce premier filtrage est suivi par une sélection qui
détecte les données erronées afin d’éliminer les valeurs faussées envoyées par
des serveurs aux comportements byzantin. Après cette phase, on suppose que
les valeurs restantes sont valides et peuvent être prises en compte pour le calcul
du décalage de l’horloge locale. Un algorithme permet de calculer ce décalage et
ensuite, celui-ci est appliqué.
Un schéma peut résumer ces différentes phases :
Page 12 sur 20
Mars 2005
Serveur NTP
Serveur NTP
Serveur NTP
Filtrage
Sélection
Combinaison
Décalage
Remarque : selon le décalage constaté (plus ou moins importante), les
méthodes de recalage peuvent varier. Nous étudions cela dans la partie
concernant les mécanismes de mise à l’heure.
D) La mise à l’heure
i)
Gestion des messages
Comme beaucoup de systèmes distribués sur un réseau, les hôtes NTP (clients
ou serveurs) utilisent des messages pour communiquer.
Voici les champs contenus dans un paquet NTP :
Page 13 sur 20
Mars 2005
La synchronisation d'un client nécessite plusieurs échanges de messages
afin d'améliorer à chaque fois l'estimation du temps. Dans la pratique, il faut à
peu près cinq minutes pour que l'horloge du système devienne fiable. Une fois
cette synchronisation effectuée, le client pourra devenir à son tour un système
de référence. De plus, plus le client échange des messages avec ses serveurs de
référence, plus il est capable de discerner, parmi eux, ceux qui amènent une
certaine part d'erreur dans la détermination du temps. Le cas échéant, il peut
décider de ne plus faire appel à ces systèmes appelés « falsetickers ».
L'échange de messages conduisant à la synchronisation suit la procédure
suivante :
Le système désirant être synchronisé envoie d'abord un paquet dans
lequel il initialise le champ « Originate timestamp » avec sa propre heure
système.
Le serveur stocke ensuite l'heure de réception du paquet dans le champ
« Receive timestamp » du même paquet.
Ensuite il effectue un contrôle de validité du paquet pour s'assurer qu'il
doit bien effectuer le traitement (vérification du stratum du client,
authentification, ...).
Avant de retourner le paquet à l'expéditeur, le champ « Transmit
timestamp » est renseigné avec l'heure courante du serveur.
Le client enregistre l'heure de réception de la réponse afin de pouvoir
estimer le temps de trajet du paquet. En supposant que les délais de
transmission des messages sont symétriques, le temps de trajet correspond à la
moitié du temps d'attente total moins le temps de traitement sur la machine
distante. (NTP implémente un algorithme de Huff&Puff pour compenser les délais
de transmission asymétriques)
Le client lui aussi vérifie la validité de la réponse pour savoir si elle doit
être prise en compte.
Le système client peut alors estimer le décalage de son horloge avec le
système de référence.
ii)
Réglage de l'horloge
Une fois que le décalage a été déterminé, il faut agir sur l'horloge pour se
synchroniser. Plusieurs possibilités d'action s'offrent alors au processus qui
interagit avec l'horloge:
Il peut changer brutalement l'heure système. Cette technique est à
éviter car elle perturbe les applications utilisant l'horloge du système et
peut même engendrer une certaine instabilité.
Page 14 sur 20
Mars 2005
Le processus peut aussi faire varier la fréquence d'horloge: la ralentir si
elle est en avance ou inversement, l'accélérer pour lui faire rattraper
son retard. Cette technique permet un contrôle plus fin de l'heure
locale et a l'avantage de préserver l'intégrité du système.
Le choix de l'action à entreprendre dépend en fait de l'importance du
décalage constaté :
Pour un décalage minuscule, la fréquence d'horloge est modifiée.
Si ensuite on constate des décalages plus grands (de l'ordre de la
seconde), le processus ne tient pas compte de la réponse des serveurs
et préfèrera faire des calculs statistiques sur les anciens décalages afin
de déterminer la marche à suivre.
Au bout d'un moment, si des décalages encore importants sont
constatés, ils seront pris en compte : pour les plus petits d'entre eux, la
fréquence d'horloge sera modifiée tandis que pour les plus grands (sans
toutefois être énormes), l'horloge est réinitialisée brutalement.
Dans le cas d'un décalage vraiment très important, la réponse des
serveurs est rejetée et le processus NTP s'arrête car il pense que ses
systèmes de référence sont entrés dans un état non fiable.
3) SNTP
En dernier lieu, une version simplifiée du protocole NTP est développée en
parallèle. Il s'agit du Simple Network Time Protocol (SNTP) spécifié dans la
[RFC2030] et qui en est déjà à sa quatrième version.
SNTP est destiné à des réseaux où la précision de l'ordre de la seconde est
suffisante (exemple : workstations). A la base, SNTP amène un allègement des
algorithmes de traitement des paquets NTP (Elle est dépourvue des mécanismes
de sélection), ce qui permet d'envisager SNTP sur des systèmes embarqués où la
capacité de calculs, notamment à virgule flottante, est généralement très limité.
L'objectif de ce nouveau protocole est de faciliter l'implémentation d'un
client NTP n'ayant pas besoin de beaucoup de précision tout en étant capable de
dialoguer avec des serveurs NTP standards. Cependant, l'utilisation de SNTP doit
rester limitée pour ne pas perturber et fausser le réseau NTP. En fait, il est
vivement recommandé de n'utiliser SNTP qu'en bout de chaîne dans les échanges
NTP, c'est à dire directement sur les systèmes clients. On doit ainsi éviter de
faire d'un système réglé par SNTP, une référence pour un autre système.
Page 15 sur 20
Mars 2005
III
Les outils disponibles
1) Les différents type de
serveurs primaire
A) Serveur par horloge GPS
L'antenne GPS est reliée au boîtier qui est capable de déterminer
l'heure de façon très précise. Le boîtier est en générale branché par le port
série mais il existe des modèles utilisant une interface ethernet. Ce boîtier
est ensuite relié à une machine ou s'exécute un serveur NTP qui utilisent
les informations délivrées par le boîtier pour recaler sa propre horloge.
Voici un exemple de boîtier GPS:
B) Serveur par horloge atomique
L'antenne reçoit des ondes radios qui sont ensuite interprétées par le
boîtier qui est capable de déterminer l'heure de façon très précise. Le
boîtier est en générale branché par le port série mais il existe des modèles
utilisant une interface ethernet. Ce boîtier est ensuite relié à une machine
ou s'exécute un serveur NTP qui utilisent les informations délivrées par le
boîtier pour recaler sa propre horloge.
C) Serveur rackable par horloge GPS
Ce type de serveur a un fonctionnement similaire avec les serveurs
par horloge GPS à la seule différence que le serveur et le boîtier forment
une seule et même machine. Sur ce type de serveur, seule l'interface
Ethernet est disponible.
Page 16 sur 20
Mars 2005
D) Serveur rackable par horloge atomique
Ce type de serveur a un fonctionnement similaire avec les serveurs par
horloge atomique à la seule différence que le serveur et le boîtier forment une
seule et même machine. Sur ce type de serveur, seule l'interface Ethernet est
disponible.
2) Un exemple de serveur primaire:
chronos.univ-rennes1.fr
A) Présentation
Ce serveur a été financé et mis sur pied par la cellule technique du Comité
Réseau des Universités afin d'offrir le service NTP à la communauté
enseignement/recherche française qui ne disposait, début 1995, que d'un seul
serveur primaire sur Renater: le serveur de l'Inria.
Page 17 sur 20
Mars 2005
B) Architecture
Ce serveur, construit autour d'une SparcStation 10 sous SunOS Release
4.1.3_U1 avec l'extension multicast, s'appuie sur un récepteur GPS SVeeSix
Trimble pour sa synchronisation. L'utilisation d'un signal PPS pris en compte
directement, par interruptions, dans le noyau de l'OS. Cela lui confère une
excellente précision (de l'ordre de la dizaine de micro-secondes).
3) Les clients
C) Pour Windows
Windows XP dispose par défaut d’un outil de synchronisation de son
horloge. Il est toutefois possible d’installer un client NTP (ou SNTP) ; en voici une
liste non exhaustive :
AboutTime (SNTP)
WinSNTP 32-bit (SNTP)
SocketWatch (NTP)
Dimension 4 (SNTP)
ntpdate (NTP)
Tardis
Automachron (NTP)
NTPTime Client (NTP)
D) Pour Linux
Il existe 2 grands clients sous linux :
ntpd
ntpdate
Les deux ont des méthodes de fonctionnement différent. Alors que ntpd
est un démon, ntpdate est un simple programme. Il ne tourne donc pas en tâche
de fond. En général, nous le configurons pour qu’il soit exécuté à chaque
démarrage de la machine. Nous pouvons d’ailleurs le vérifier facilement :
>>:/home # ls /etc/rcS.d/ | grep ntpdate
S51ntpdate
Evidemment, il est possible d’exécuter ntpdate en ligne de commande à la
demande ou dans un cron de telle façon à ce que l’horloge se synchronise à
heure régulière.
Page 18 sur 20
Mars 2005
ntpd, quant à lui, est un démon. Il tourne constamment et synchronise
l’horloge locale de façon régulière et transparente.
4) Quelques utilitaires en detail
A) ntptrace
ntptrace permet d'afficher le chemin de la synchronisation vers le serveur
de strate 1 en partant de l'ordinateur 'machine'.
Exemple:
$ ntptrace lptfpc19.obspm.fr
lptfpc19.obspm.fr: stratum 3, offset -0.008014, synch distance 0.05196
opdaf2.obspm.fr: stratum 2, offset -0.000648, synch distance 0.03754
ntp-p1.obspm.fr: stratum 1, offset -0.002420, synch distance 0.00000, refid '1PPS'
B) ntpq
La commande host 'serveur' permet de changer le destinataire des
commandes. peer affiche la liste des serveurs qui participent à la
synchronisation: une étoile en première colonne indique celui qui est utilisé
actuellement, 'St' est le strate (16 est une machine non disponible pour une
synchro, c'est le cas entre autres pour tout serveur NTP pendant les quelques
minutes qui suivent son démarrage) et 'reach' est normalement à 377. L'offset
est donné en millisecondes. Autre commande intéressante: rv (ou rl), elle donne
diverses informations sur le serveur ntp.
$ ntpq
ntpq> host ntp-p
ntpq> current host set to opdaf2.obspm.fr
ntpq> peer
remote
refid
st t when poll reach
delay
offset
disp
==============================================================================
*ntp-p1.obspm.fr .1PPS.
1 u 667 1024 377
7.08
0.149
1.10
+lip.curie.fr
.GPS.
1 u 832 1024 377
93.15 -16.340
10.50
+sancerre.jussie canon.inria.fr
2 u 624 1024 377
15.40
-7.300
1.77
-soleil.uvsq.fr brahma.jussieu. 2 u
35 1024 377
28.26
6.294
20.77
-joliot.net.espc chronos.cru.fr
2 u 769 1024 377
28.29
7.837
9.51
ntpq> rv
status=06c4 leap_none, sync_ntp, 12 events, event_peer/strat_chg
system="OpenVMS AXP", leap=00, stratum=2, rootdelay=7.08,
rootdispersion=18.22, peer=60828, refid=ntp-p1.obspm.fr,
reftime=bc9855a4.a185d000 Fri, Apr 7 2000 14:40:04.630, poll=10,
clock=bc985896.ace06000 Fri, Apr 7 2000 14:52:38.675, phase=0.660,
freq=-13682.74, error=27.16
Page 19 sur 20
Mars 2005
Conclusion
NTP est le protocole de synchronisation du temps le plus utilisé à travers le
monde. Son succès est dû à sa facilité d’utilisation, sa fiabilité et sa précision
(10-3 secondes en LAN). NTP évolue constamment. Il est aujourd’hui en version
4. Ces évolutions successives permettent à NTP de tenir compte des nouveautés
technologiques (IPv6, cryptage, …).
Derrière sa simplicité d’utilisation, NTP cache un fonctionnement bien plus
complexe. Il fait appelle à de nombreux principes et algorithmes dans le but
d’offrir un service de qualité.
Une version simplifiée de NTP existe. Il s’agit du protocole SNTP. Ce
protocole permet une synchronisation allant jusqu’au dixième de seconde. Cette
précision est bien souvent suffisante. Il est ainsi possible d’utiliser SNTP au
niveau des clients.
Page 20 sur 20
Mars 2005

NTP - Emmanuel de Castro

Transcription

Documents pareils

Distribution d`Heure – Serveur NTP

logiciel monitor ntp

Truc et Astuce Serveur d`heure au format NTP

Bridal_suivi plasma _Annonce_These_LIB_ED

Télécharger en PDF

La synchronisation horaire des équipements

Télécharger la brochure

Horloge murale à diodes lumineuses, maîtresse

N-Éthyl-2-pyrrolidone