Quelle heure est-il ?

travailler sur le temps

De nos jours, on ne se pose plus de question pour avoir l’heure. Tous nos systèmes connectés nous présentent une horloge, que ce soit notre PC, nos téléphones multiples, qu’ils soient fixes, de bureau ou mobiles, notre box à la maison, notre réfrigérateur en sera surement bientôt capable. Mais alors pourquoi tous ces systèmes ne sont-ils pas à l’heure ?

Cette question est plus particulièrement pertinente en entreprise. Des systèmes multiples, des composants installés sans forcément prendre en compte ce paramètre qui peut être jugé non indispensable, des procédures de contrôle qui ne s’en soucient pas et nous voila avec sur notre bureau plusieurs équipements nous présentant une heure différente. Laquelle est juste ? Y en a-t-il une de juste ? Difficile à dire.

Il fut un temps ou un installateur de téléphonie ne pouvait s’empêcher d’appeler l’horloge parlante lors de l’installation d’un système. Cela permettait de savoir que les lignes externes fonctionnaient bien d’une part, on ne dérangeait personne d’autre part pour faire un test et en plus on avait l’heure, pas mal non ? Mais aujourd’hui, ce sont principalement les systèmes de téléphonie d’entreprise qui ne sont pas à l’heure, quel dommage !

Avoir une heure cohérente et juste sur son système d’information est pourtant primordial. En plus de fournir une information importante aux utilisateurs (qui ne regarde pas régulièrement l’heure, ne serait-ce que pour ne pas arriver en retard à une réunion ou prendre son train du soir ?) elle permet de synchroniser nombre de processus, de déclencher des actions automatiques au bon moment. Comparer des événements sans une base horaire est très complexe, recevoir des courriels avec une heure en avance est perturbant, quant aux systèmes de sécurité se basant sur des échanges cryptographiques, ils sont parfois totalement inopérants si pas à l’heure. Prenez par exemple l’authentification par token, il ne faut pas trop d’écart d’heure entre les différents composants pour qu’elle ne fonctionne plus, 15 secondes d’écart sont suffisantes  pour des impacts importants.

Il est donc prudent de mettre en place une vraie structure de temps dans son SI, on pourra même le ranger des les « best practices », comme cela on peut le mettre au budget pour l’an prochain sans soucis. Le protocole NTP est là pour nous aider, on l’utilisera donc pour synchroniser tout ce qui peut l’être, mais on ne négligera pas non plus les fonctions intrinsèques aux systèmes d’exploitation en réseau, votre contrôleur de domaine Microsoft fournira ce service, mais il faudra quant même configurer les postes pour qu’ils se mettent à jour. En plus, le NTP est un vrai service en mode Cloud : totalement redondant, hiérarchique, disponible sur Internet avec une simple connexion, même à bas débit, sans contrainte géographique et qui plus est gratuite, alors pourquoi ne pas en profiter.

Mais comment le mettre en œuvre sérieusement ? Un système dédié, utilisation d’un NTP public, mise en place d’un serveur en interne ? Pas de préconisation particulière, si ce n’est de positionner au moins 2 serveurs NTP dans son organisation, idéalement sur des sites différents si possible. Une entrée DNS avec du round robin assurera simplement la redondance du service et un positionnement automatique dans le DHCP fournira l’information aux équipements sachant utiliser cette option.

La précision d’un service NTP dépend directement de la qualité de l’horloge de référence utilisée en amont et de la fiabilité de l’horloge interne du système. Sur un serveur virtuel (une VM), il peut être assez difficile d’avoir une horloge très stable et fiable, mais ceci devra être placé au regard de la précision attendue. Si un décalage de 10 ou 20ms n’est pas un problème pour vos applications, alors n’hésitez pas à dédier une petite VM sur votre hyperviseur préféré et à y monter un serveur NTP interne, vous pourrez alors synchroniser votre serveur sur des sources Internet si votre VM y a accès. Pour éviter les dérives trop grandes, il sera important de mettre en place une limite maximale entre deux synchronisations externes, en effet laisser faire le correcteur de dérive ne sera pas suffisant sur une VM, même peu chargée. Pour information, notre serveur de temps chez Setec IS est hébergé par une VM et propose une horloge d’une fiabilité en ms (moins de 5ms), sur un petit serveur physique nous aurions sans soucis 0.2 à 0.3ms. Si vous utilisez un réseau WAN opéré type IP VPN, demandez à votre fournisseur une source NTP sur chaque CE fourni, ceci vous fournira une source complémentaire si vous n’avez pas un accès simple à Internet.

Si vous souhaitez encore plus de précision, vous pourrez alors dédier un serveur, son horloge physique sera bien plus stable et surtout constante, on peut alors facilement la corriger de la dérive. Mais un serveur aujourd’hui représente un investissement, une maintenance et donc des coûts importants. Vous pouvez néanmoins recycler deux vieux équipements et les remettre en service pour cet usage, pas besoin de maintenance, en revanche il faudra un peu d’énergie. On préférera des systèmes d’exploitation légers, idéalement qui tournent entièrement en mémoire de façon à ce que les disques soient à l’arrêt lors du fonctionnement normal du serveur, c’est toujours un peu plus de fiabilité et d’économie d’énergie.

Il est également possible d’utiliser des petits serveurs spécifiques issus des gammes industrielles qui ont l’avantage de ne pas comporter d’éléments mobiles (disque dur, ventilateur…), comme le célèbre et robuste Soekris 4501 qui pourra en plus être modifié par les plus experts pour y ajouter une source GPS à grand renfort de soudure, ou n’importe lequel des serveurs « fanless » du marché supportant un Linux ou un FreeBSD.

Si vous avez l’âme d’un aventurier, vous pouvez même utiliser des pico serveurs type Raspbery Pi avec une source Internet ou encore mieux avec un GPS en USB (cf Raspbery NTP). Cette dernière solution vous permet à moindre frais d’avoir une horloge de premier ordre (stratum 1) et surtout d’une grande précision, pour un coût modique, jugez plutôt :

  • synchronisé sur Internet : précision de 3ms mais avec une gigue assez forte
  • synchronisé sur un serveur local en stratum 1, les résultats sont excellents avec autour de 20 micro seconde de décalage et une gigue en nano seconde
  • synchronisé sur un GPS directement connecté, le décalage est proche de la micro-seconde, il faudra en revanche que l’antenne GPS ait le ciel visible, ce qui sera probablement le plus compliqué

Pas question d’attendre qu’il ne soit trop tard, ajoutez à votre liste de projet une remise à plat de votre infrastructure de temps, c’est un projet peu coûteux et à haute valeur pour votre SI.

Et aussi

  • 20 mai 2014 Performance d’une application dans un environnement mutualisé Les précédents articles de la catégorie ont permis de visualiser un certain nombre de cas figures liés aux réseaux (WAN + LAN). Mais les serveurs eux-mêmes sont la cause de différences de performances notables. D'où la nécessité de superviser ces performances, en particulier sur les environnements mutualisés comme les clusters de machines virtuelles. Voici quelques […]
  • 16 décembre 2013 Etes vous bien préparés au SPAM La sécurité d’un système est impactée par le plus faible de ses maillons, nous le savons tous. Alors pourquoi ne prend-on pas plus au sérieux la sécurité des courriels échangés, base de productivité de nombreuses activités des entreprises aujourd’hui ? Le courriel, que nous utilisons tous les jours pour nos usages aussi bien professionnels que personnels, est un outil indispensable. […]
  • 14 octobre 2013 Avons-nous des Backdoors dans les OS de nos PC / serveurs ? Ne soyons pas naïfs, les pressions à créer des backdoors étaient inévitables. On a maintenant la preuve qu'elles existent comme le rappelle cette interview de Linus Torvalds, que la NSA a manifestement approché. Comme le fait remarquer Greg Ferro qui a été ma source de ce lien, les présomptions sur les OS de Microsoft sont très très fortes (cf. les coopérations de Skype depuis son […]