La synchronisation horaire des equipements informatiques

Christian Claveleira

La synchronisation horaire des equipements informatiques

Christian Claveleira, claveleira@univ-rennes1.fr Octobre 1995

R sum e e Cet article traite dun aspect souvent d laiss de ladministration des syst` mes dinfore e e mation : leur synchronisation horaire. Nous allons en voir la n cessit , les moyens a notre e e ` disposition pour y parvenir et leur mise en oeuvre.

1 Introduction
Actuellement tout equipement informatique dispose dune horloge mat erielle ou logicielle ` a laquelle il est fait r erence pour horodater des chiers, des transactions, des courriers ef electroniques, etc... Cette horloge, bien que con ue autour dun oscillateur ` quartz, d c a erive comme toute montre ordinaire. Ceci est dautant plus g nant lorsque les machines sont en r e eseau et partagent des ressources communes comme des syst` emes de chiers. Par exemple, certains outils de d eveloppement, comme la commande Unix make, basent leur travail sur la comparaison des dates de modication de chiers. De m me, la corr e elation de messages de logs de plusieurs syst` emes devient tr` difcile si elle ne sont pas ` la m me heure. es a e Cest encore plus ennuyeux lorsquil sagit de serveurs visibles de tout lInternet comme les relais de messagerie qui oblit` erent les courriers quils transmettent. A titre dexemple, d ebut septembre 1995, pr` de 60plus de 1minute sur lheure exacte et 27des courriers avant quils ne soient es emis... Les serveurs DNS ne sont pas plus ` lheure... a

Comment assurer la synchronisation d equipements en r eseau

La m ethode manuelle ayant ses limites (:-), trois protocoles ont e con us dans ce but: et c

2.1

Time Protocol

Cest le plus ancien (1983), il fait lobjet du RFC868. Sappuyant sur UDP ou TCP il se r esume ` lenvoi par les serveurs dun paquet contenant le temps en secondes a ecoul depuis le premier e janvier 1900 ` 0H. Il a e utilis par le d a et e emon Unix timed mais sa faible r esolution et labsence

La synchronisation horaire des equipements informatiques

Christian Claveleira

RFRENCES DE TEMPS STRATE 1 (serveur ou client) STRATE 2 (serveur ou client) STRATE n (serveur ou client)

F IG . 1 Relations entre serveurs NTP de sp ecication de m ecanismes de compensation de d elais de transit ont conduit ` l a etude dun protocole plus sophistiqu e.

2.2

Network Time Protocol (NTP)

Il fait lobjet du RFC1305 et en est ` sa troisi` a eme version. Nettement plus elabor que Time e Protocol il permet la constitution de r eseaux dentit NTP avec de multiples redondances an es dassurer la synchronisation permanente et able des machines concern ees. La principale contribution aux travaux sur NTP est celle de David L. Mills de luniversit du e Delaware. Des algorithmes de ltrage et de s election ainsi que des mod` dimpl eles ementation sont d enis dans NTP. Ils permettent ` tout moment aux clients NTP de d a eterminer la meilleure source de synchronisation, d eliminer les sources suspectes et de corriger les temps de transit dans le r eseau. Son impl ementation de r erence est le d ef emon Unix xntpd. Concernant sa mise en oeuvre, lune des caract eristiques principales dun r eseau NTP est sa structure pyramidale (Voir gure 1). Des r erences de temps synchronisent des serveurs NTP qui ef leur sont directement raccord Ceux-ci constituent la strate 1, ils vont synchroniser chacun es. plusieurs dizaines dautres serveurs qui vont constituer la strate 2 et ainsi de suite jusquaux clients terminaux. Ce principe permet de bien r epartir la charge des serveurs tout en conservant une distance aux sources de r erence relativement faible. ef Un serveur NTP peut fonctionner dans les modes suivants: mode serveur simple : il se contente de r epondre aux requ tes de ses clients e mode sym etrique actif : il demande ` etre synchronis par dautres serveurs et leur annonce a e quil peut egalement les synchroniser mode sym etrique passif : m me chose mais ` linitiative des autres serveurs e a

La synchronisation horaire des equipements informatiques

Christian Claveleira

mode broadcast : destin aux r e eseaux locaux, il se limite ` une diffusion dinformations a horaires destin ` des clients pouvant etre soit passifs, soit d ees a ecouvrant ainsi les serveurs avec lesquels ils vont se synchroniser mode client : envoie des requ tes ` un ou plusieurs serveurs e a La repr esentation du temps NTP sur 64 bits permet une r esolution th eorique de 232ps et permet dattendre 2036 avant d ebordement !

2.3

Simple Network Time Protocol (SNTP)

D ecrit dans le RFC 1361, cest une version simpli de NTP, d ee epourvue des m ecanismes de s election, destin ` des utilisations o` une pr ee a u ecision de lordre de la seconde est sufsante. Un client SNTP peut bien s r se synchroniser sur un serveur NTP.Bien quayant plut t e con u pour u o et c impl ementer des clients simple, SNTP permet egalement de mettre en oeuvre des serveurs mais ceux-ci doivent alors etre synchronis directement par une r erence temporelle. e ef

Le temps Unix

La principale cible de limpl ementation de NTP est le(s) syst` eme(s) Unix. Pour comprendre les probl` emes dimpl ementation, voire dutilisation, de xntpd, il est bon de survoler la gestion du temps sous Unix. Celui-ci g` un temps syst` ere eme constitu dun registre incr e ement de n micro-secondes ` e a chaque interruption dun temporisateur mat eriel. La fr equence dinterruption est souvent de 100Hz et n vaut donc 10000. Cette valeur est contenue dans la variable interne au noyau appel tick . ee Lorsquune correction est ` faire sur lheure syst` a eme, tick est modi de la quantit contenue ee e dans la variable tickadj du noyau, jusqu` ce que la correction soit effectu par appel ` la routine a ee, a adjtime(). Limpl ementation de adjtime() ainsi que la valeur de tickadj, voire la valeur de tick, posent souvent probl` eme lors de limpl ementation de NTP (d emon xntpd) sous Unix ce qui oblige ` des a parades plus ou moins sp eciques par syst` dexploitation. eme

4 Les rerences de temps ef

Elles sont toutes d eriv plus ou moins directement dhorloges atomiques. On peut citer : ees les horloges pilot par des signaux radio ees emis par des emetteurs sp ecialis comme DCF77 es en Allemagne les horloges pilot par des ees emetteurs de radio-diffusion publiques transmettant, en plus de leur programme, des informations horaires comme l emetteur TDF dAllouis diffusant France-Inter les syst` emes de positionnement comme le Loran C ou, mieux, le GPS constituent dexcellentes sources de r erence ef

La synchronisation horaire des equipements informatiques

Christian Claveleira

Le d emon xntpd

Il impl emente le protocole NTP ainsi que divers pilotes utilis pour le raccordement de r ees ef rences de temps permettant ainsi de mettre en oeuvre aussi bien un simple client terminal quun serveur primaire. La partie purement NTP tourne sur un grand nombre de syst` emes dexploitation: SunOS 4.x, Solaris 2, HP/UX 9.x, Ultrix 4.3, OSF/1, IRIX 4.x, AIX 3.2, A/ UX, *BSD, Linux,... Les pilotes, par contre, ne sont impl ement que sur quelques uns. Seul SunOs 4.x supporte es lensemble des pilotes. Evoluant en m me temps que NTP, xntpd est devenu, au l du temps, une esp` de monstre. e ece Si son utilisation en serveur de strate sup erieure ` 1 reste relativement simple, la mise en oeuvre a dun serveur primaire est beaucoup plus ardue. Les sources de r erence sont connect via un port s asynchrone et d ef ees erie elivrent des messages horaires compl es, dans certains cas, de signaux impulsionnels ` la cadence dun top par et a seconde (PPS:Pulse Per Second). Lobtention dune bonne pr ecision d epend de celle avec laquelle les messages sont rep es : er au niveau application : Unix n etant pas un syst` eme temps r cest la solution la moins eel, efcace mais la plus facile ` impl a ementer au niveau des queues logicielles du noyau : solution beaucoup plus pr ecise mais n ecessite dintervenir dans le noyau au niveau des queues mat erielles du noyau : encore plus pr ecise mais intervention encore plus d elicate Quoi quil en soit, le rep erage des messages ne peut pas etre plus pr que ce que permet ecis lutilisation dune communication asynchrone en mode caract` pour aller plus loin lutilisation ere; dun signal PPS simpose avec, ` nouveau, le probl` de son rep a eme erage et de son interfa age : c Ce signal peut etre appliqu e sous forme de caract` asynchrone sur le l de r ere eception de donn dun port RS232 : on ees retrouve les m mes probl` e emes quavec les messages directement sur un l d capable de g erer une interruption mat etat en erielle : cest de loin la m ethode la plus efcace (pr ecision meilleure que la milliseconde) mais n ecessite du code sp ecique dans le noyau Toutes ces m ethodes ne sont pas disponibles sur tous les OS, seul SunOS, actuellement, les supporte toutes. La livraison de xntpd comporte un certain nombre de commandes facilitant la maintenance ` a distance dun parc de machines synchronis ees: ntpq et xntpdc permettent dinterroger un serveur pour connatre son et, etat eventuellement, modier sa conguration. Exemple :
ntpq -p cicb-gw

La synchronisation horaire des equipements informatiques

Christian Claveleira

remote refid st t when poll reach delay offset disp ============================================================================ *resone.univ-ren .PPS. 1 u 46 1024 377 2.33 0.027 15.99 +mailimailo.cicb resone.univ-ren 2 u 93 1024 377 3.19 0.418 14.04 +yseult.sis.past .TDF. 1 u 178 1024 377 25.09 -3.689 0.52 +roland.univ-ren resone.univ-ren 2 u 227 1024 377 3.88 -0.305 9.58 CICB-NET.univ-r 0.0.0.0 16 u 64 0 0.00 0.000 16000.0

ntptrace permet de remonter la chane de synchronisation dun serveur. Exemple :

ntptrace mimo mailimailo.univ-rennes1.fr:stratum 3, offset 0.000766, synch distance 0.05338 cicb-gw.univ-rennes1.fr: stratum 2, offset 0.000278, synch distance 0.05412 resone.univ-rennes1.fr: stratum 1,offset -0.000151, synch distance 0.00005, refid P

Dautres commandes sont plus sp eciques de ladaptation de xntpd ` lOS : a tickadj permet de modier la valeur de certaines variables du noyau, comme tick et tickadj, lorsque les valeurs par d efaut sont incompatibles avec xntpd.

Mise en oeuvre dun serveur primaire : lexemple de chronos.univrennes1.fr

Ce serveur a e nanc et mis sur pied par la cellule technique du Comit R et e e eseau des Universit an doffrir le service NTP ` la communaut enseignement/recherche fran aise qui ne es a e c disposait, d ebut 1995, que dun seul serveur primaire sur Renater: le serveur de lInria. Ce serveur (Voir gure 2), construit autour dune SparcStation 10 sous SunOS Release 4.1.3 U1 + extensions multicast, sappuie sur un r ecepteur GPS SVeeSix Trimble pour sa synchronisation. Lutilisation dun signal PPS pris en compte directement, par interruptions, dans le noyau de lOS support, lui conf` une excellente pr ere ecision (de lordre de la dizaine de micro-secondes). Structure du serveur : voir gure 3. Une interface a e d et evelopp pour adapter les signaux du r ee ecepteur au port s de la SparcSerie tation et pour alimenter le r ecepteur (Voir gure 4). Les sch emas en sont disponibles sur le serveur WWW du CRU (Voir Informations sur le service NTP et son utilisation). La mise en exploitation a e retard par des probl` et ee emes de non-r eponse du r ecepteur ` des a messages de polling du serveur. La mise au point dune version du pilote fonctionnant sans polling a permis d eliminer ce probl` eme. Depuis, chronos est ofciellement ouvert aux serveurs NTP de (gros) sites et accueille plusieurs dizaines de clients.

Informations sur le service NTP et son utilisation

Le serveur WWW du CRU abrite une rubrique sur le service NTP o` lon trouve u les serveurs NTP publics fran ais et mondiaux c

La synchronisation horaire des equipements informatiques

Christian Claveleira

F IG . 2 Le serveur chronos.univ-rennes1.fr

datas mise en forme rcepteur PPS GPS alim conversion alimentation interface SUN RS232 serveur xntpd

F IG . 3 Synoptique du serveur NTP de Rennes 1

La synchronisation horaire des equipements informatiques

Christian Claveleira

F IG . 4 Interface sp ecique du serveur NTP

La synchronisation horaire des equipements informatiques

Christian Claveleira

des conseils de mise en oeuvre de NTP les logiciels NTP (clients et serveurs) des informations sur le serveur de Rennes etc... (URL: http://www.univ-rennes1.fr/CRU/NTP) Cette rubrique, encore jeune, est en cours de constitution; les contributions sont bienvenues...

Enn, quelques conseils de mise en oeuvre :

il existe une alternative int eressante ` lutilisation de xntpd pour mettre en oeuvre des sera veurs NTP interm ediaires : lutilisation de routeurs Cisco. En effet, les versions dIOS 10.x impl ementent NTP et permettent ainsi davoir un serveur NTP par r eseau ` moindre invesa tissement. attention ` la redondance : un serveur NTP doit etre synchronis par au moins trois serveurs a e diff erents an de pallier les diverses d efaillances possibles. sur un r eseau local lutilisation du mode broadcast permet de simplier la conguration des clients (mais il faut etre s r quil ny ait pas de serveurs clandestins mal congur u es). veiller ` bien r a epartir la charge en mettant en place autant de strates que n ecessaire en particulier pour ne pas surcharger les serveurs publics de r erence. ef sur SunOS il est n ecessaire dajuster les variables du noyau ` laide de la commande tickadj a et de compenser la d erive de lhorloge locale si elle d epasse 100ppm il y a tr` peu de serveurs de strate 2 actuellement en France, donc, si vous en mettez en es oeuvre, pensez ` la communaut et signalez-le ` timemaster@univ-rennes1.fr a e a