Facebook dévoile un nouveau service de temps

Facebook a dévoilé un nouveau service de temps NTP à l’adresse time.facebook.com. Il serait plus précis que d’autres services de temps publics et n’identifierait pas les utilisateurs par leur adresse IP. Facebook a également publié un billet lié à ce service sur son blog d’ingénierie. (en anglais)

Si une grande entreprise IT comme Facebook s’intéresse aux services de temps, c’est en raison de l’exploitation de systèmes distribués. Pour traiter les transactions d’une base de données distribuée ou garantir une journalisation correcte, plusieurs serveurs doivent synchroniser leurs horloges avec une très grande précision.

Facebook a acheté un équipement de test professionnel de type Stratum 1 (un appareil qui reçoit directement les informations de temps depuis les horloges atomiques des satellites) et a réalisé un benchmark comparant ntpd, couramment utilisé comme serveur de temps, et chrony ( https://chrony.tuxfamily.org/ ), un daemon NTP relativement plus récent. Après son démarrage initial, ntpd a temporairement affiché une erreur de -10 ms avant de converger progressivement vers une erreur de ±1 ms, tandis qu’avec chrony, la plupart des écarts sont restés dans une plage de ±0,2 ms, montrant une précision nettement supérieure à celle de ntpd.

chrony a aussi d’autres avantages, notamment la prise en charge du hardware timestamping. Le protocole de synchronisation temporelle NTP tente de déterminer l’heure actuelle la plus précise possible en apposant des horodatages à chaque échange de paquets entre le serveur et le client, puis en calculant le temps écoulé pendant l’aller-retour. Mais en dehors d’un système d’exploitation temps réel, il est impossible de garantir que le délai de traitement d’une opération reste sous un certain seuil. Il en va de même pour NTP, ce qui constitue l’une des causes d’augmentation de l’erreur lors de la synchronisation de l’heure via le réseau.

Or, certaines NIC (cartes réseau) prennent en charge le hardware timestamping. Cette fonctionnalité permet à la NIC de maintenir sa propre horloge et de traiter les horodatages via un matériel dédié, avec un délai de traitement de seulement quelques nanosecondes. Dans une situation idéale sur un réseau local, si le serveur NTP et le client prennent tous deux en charge le hardware timestamping, il serait possible de synchroniser l’heure avec une erreur inférieure à 1 microseconde. Bien sûr, un service de temps réel n’est pas déployé dans un environnement de réseau local, et la NIC côté client ne prend pas toujours en charge le hardware timestamping, donc on ne peut pas espérer atteindre ce niveau dans la pratique. Cela dit, selon les résultats du benchmark combinant chrony et le hardware timestamping, la plupart des erreurs de synchronisation temporelle sont restées dans ±0,1 ms.

Facebook indique donc fournir son service de temps public avec une configuration chrony où le hardware timestamping est activé. Alors que d’autres serveurs de temps publics, comme ceux de Google ou d’Apple, peuvent parfois dépasser une erreur de ±2 ms, le service de Facebook resterait le plus souvent à l’intérieur de ±1 ms. À noter que ce service est exploité avec des endpoints répartis sur cinq régions différentes. Pour plus de détails, consultez l’article original.

[ryuheechul]

Waouh. C’était un article intéressant. Les efforts consacrés à la précision y sont partagés de façon à la fois concise (?) et détaillée. Après l’avoir lu, j’ai changé le serveur NTP de mon Mac pour time3.facebook.com.

[kunggom]

J’utilise time1.facebook.com. Après quelques pings, j’ai constaté que les autres endpoints, de 2 à 5, ne répondaient pas au ping ou étaient assez lents. En configurant time1.facebook.com comme serveur de temps dans chrony, l’erreur estimée dépasse légèrement ±1 ms. En revanche, avec simplement time.facebook.com, je n’arrive pas à récupérer l’heure.

[kunggom]

À titre de comparaison, d’autres serveurs de temps, comme time.google.com ou time.windows.com, affichent sans exception une erreur supérieure à 30 ms. Il en va de même pour les pools NTP comme kr.pool.ntp.org. Jusqu’à présent, le serveur de temps présentant l’écart le plus faible parmi ceux que j’ai vus est ntp.postech.ac.kr, un serveur Stratum 1, que chrony estime à environ ±5 ms.

[kunggom]

J’ai récemment découvert que si l’on configure time.apple.com comme pool dans chrony, on obtient des serveurs NTP de haute précision situés en Corée et au Japon. Ils apparaissent même comme étant en Stratum 1. Apple semble équiper ses propres serveurs CDN de récepteurs GPS pour les utiliser comme serveurs de temps.

[xguru]

C’est intéressant. L’expression « at Facebook scale » devient presque familière désormais.

[kunggom]

Petite parenthèse : cet article n’a pas été publié sur le Twitter de GeekNews. Y a-t-il des critères particuliers pour les actualités publiées par le bot Twitter ?

[xguru]

Ah, après vérification, l’erreur venait du fait qu’au moment de couper le texte après vérification du nombre de caractères avant publication, l’URL placée tout au début du contenu était convertie automatiquement en lien, ce qui faisait dépasser la limite de caractères et provoquait une erreur de l’API Twitter, snif

Sur Twitter, les URL sont systématiquement converties en quelque chose comme 22 octets.

Il faudra sans doute corriger cette partie, snif