Problème de la seconde problématique

Aujourd’hui, chacun de nous a de nombreuses possibilités de vérifier l’heure actuelle. Nous avons des smartphones, des montres, des ordinateurs, des téléviseurs, des réfrigérateurs, des fours, etc. Tout le monde sait ce qu’est une année et ce qu’elle signifie. Nous comprenons les fuseaux horaires et l’heure UTC. Tout semble trivial. Cependant, du point de vue des systèmes informatiques, il existe de nombreuses surprises auxquelles nous pouvons être confrontés. Malheureusement, cela nous amène à rencontrer des problèmes qui surviennent très rarement.

Il existe de nombreux problèmes liés au temps qui existent dans différents systèmes informatiques, en fonction du type de système. Ils sont principalement liés à la précision de la mesure du temps et à la synchronisation du temps entre les machines dans les systèmes distribués. Dans cet article, je vais me concentrer sur une situation étrange qui ne s’est produite que 27 fois dans l’histoire.

Seconde intercalaire

Initialement, une seconde était définie comme 1/86400 du jour. Puis en 1960, la définition a été modifiée pour être de 1/31 556 925,9747 de l’année tropique. Cependant, il s’est avéré que le mouvement de la Terre autour du Soleil n’est pas toujours le même, et parfois il y a des différences causées par les marées, le mouvement des masses à l’intérieur de la planète ainsi que les tremblements de terre. Par conséquent, en 1967, la valeur de la seconde a été définie de manière complètement différente :

“Cela équivaut à 9 192 631 770 périodes de radiation correspondant à la transition entre les deux niveaux F = 3 et F = 4 de la structure hyperfine de l’état fondamental S1/2 de l’atome de césium 133Cs”

Les horloges les plus précises sont les horloges atomiques, qui mesurent simplement le temps en fonction de la vitesse à laquelle les électrons passent entre les deux couches d’un atome. Cependant, il restait la question de compenser la différence entre les valeurs mesurées par les horloges atomiques et le temps réel que la Terre met à tourner autour du Soleil.

À cette fin, la seconde intercalaire a été inventée. Le IERS (Service international de la rotation terrestre et des systèmes de référence) décide quand cette seconde doit être ajoutée. Habituellement, elle est ajoutée le dernier jour de juin ou de décembre. Une déduction d’une seconde est également possible, mais à ce jour cela ne s’est pas encore produit.

Temps et systèmes informatiques

Le timing est en fait présent dans la plupart des projets. Nous devons être en mesure de spécifier quand une action utilisateur particulière s’est produite, quand un e-mail particulier doit être envoyé. Il peut également être important de déterminer l’ordre exact des événements. Dans le cas d’une seule machine, ce n’est pas très compliqué. Cependant, dans le cas de systèmes distribués, où nous traitons avec plusieurs nœuds, la situation est plus compliquée. Les horaires matériels donnés par l’oscillateur à quartz habituel ne sont pas entièrement précis et il peut y avoir des différences entre les nœuds. Lorsque la séquence d’événements est importante, un écart dans les lectures de l’horloge des nœuds est inacceptable. C’est pourquoi le protocole NTP (Network Time Protocol) est utilisé, qui fait correspondre l’heure indiquée par une machine particulière à l’heure donnée par un groupe de serveurs.

Il y a au moins deux horloges dans les ordinateurs : les horloges en temps réel et les horloges monotones.

Horloges en temps réel

Elles retournent simplement la date et l’heure actuelles. Dans les systèmes basés sur Unix, l’horloge est basée sur la date du 1er janvier 1970 à 00:00:00, et à partir de ce moment, elle compte le nombre de secondes. Ces horloges posent problème car elles sont synchronisées par NTP, ce qui peut les faire avancer et reculer. Par conséquent, elles ne sont pas tout à fait adaptées pour mesurer le passage du temps, comme les délais d’attente.

Horloges monotones

Les horloges monotones sont plus précises, fournissant des valeurs en microsecondes ou même plus précisément. Elles sont implémentées sous forme de compteurs, qui pourraient par exemple commencer lorsque le système démarre. NTP ne peut ajuster que la vitesse de comptage, ralentissant ou accélérant l’horloge particulière. Comme il n’y a pas de sauts, elles sont un meilleur choix pour mesurer le passage du temps.

Conséquences d’une mauvaise synchronisation

Le résultat d’une mauvaise synchronisation ou d’horloges désynchronisées peut entraîner une perte de données. Il vaut mieux que le système plante complètement que de fonctionner de manière incorrecte et inaperçue, ce qui peut entraîner une corruption des données. Par conséquent, dans les situations où nous nous fions aux horloges, elles doivent être correctement synchronisées et surveillées. Si une horloge dysfonctionne, elle doit être considérée comme complètement hors service.

Ordonnancement des événements

Par exemple, dans la réplication avec plusieurs leaders, la stratégie du dernier enregistrement gagne est utilisée. Ainsi, si deux nœuds ont des horloges non synchronisées, la différence peut être même de 2 ou 3 ms, une situation peut survenir où l’ordre des écritures est inversé, conduisant à des données incorrectes. Cependant, il s’avère que même la synchronisation par NTP pourrait ne pas être suffisante, car elle est également fortement influencée par les retards du réseau. Par conséquent, des horloges logiques basées sur des compteurs croissants devraient plutôt être utilisées pour ordonner les événements. Elles ne mesurent pas le temps, mais déterminent uniquement l’ordre relatif des événements.

Certains bases de données comme par exemple Spanner de Google utilisent l’API TrueTime, qui renvoie, respectivement, la plage de temps qui peut actuellement être (c’est-à-dire, elle prend en compte l’erreur qui peut survenir) [plus tôt, plus tard]. Une telle base de données gère de manière appropriée les transactions se référant à cette erreur, afin de garantir le bon ordre. Bien sûr, pour avoir les performances adéquates, la plage de temps ne doit pas être trop grande. Par conséquent, Google utilise dans chacun de leurs centres de données un GPS ou une horloge atomique pour déterminer l’heure actuelle, permettant aux horloges d’être synchronisées avec une précision d’environ 7 ms.

Comme vous pouvez le constater, le temps dans les projets informatiques n’est pas une chose banale. Cependant, concentrons-nous sur la seconde intercalaire et les problèmes qui y sont associés.

Problèmes et échecs

Les programmeurs savent que si quelque chose se produit rarement, il est prévu que ce sera différent de ce qui était supposé car personne ne l’a jamais vécu auparavant. Dans le cas des secondes intercalaires, une telle situation s’est produite 27 fois en 52 ans, en moyenne une fois tous les deux ans. C’est extrêmement rare, donc divers problèmes et erreurs logicielles étaient inévitables. La pire période a été entre 1999 et 2005, période pendant laquelle les secondes intercalaires ont essentiellement été oubliées pendant six ans.

Le 30 juin 2012, une grave baisse de performance a été signalée sur Reddit, au début les administrateurs ont accusé un ralentissement du réseau qui s’était également produit quelques jours plus tôt. Après une enquête plus approfondie, il s’est avéré que les machines Linux avaient une utilisation très élevée du processeur. Le problème était un bug dans le noyau Linux, le module “hrtimer” est devenu fou lorsqu’une seconde supplémentaire a été ajoutée. Reddit n’était pas le seul affecté, car d’autres entreprises ont également constaté de tels problèmes. Linus Torvalds a commenté la situation comme suit :

“Presque chaque fois que nous avons une seconde intercalaire, nous trouvons quelque chose. C’est vraiment ennuyeux, car c’est un cas classique de code qui n’est pratiquement jamais exécuté, et donc pas testé par les utilisateurs dans leurs conditions normales.”

Explication du problème “hrtimer”

Hrtimer est le module responsable de réveiller les applications d’un état d’attente. Les applications qui, par exemple, attendent que le système d’exploitation effectue une tâche, et seulement plus tard pourront-elles effectuer leurs actions. Lorsqu’une seconde intercalaire a été ajoutée, le module est devenu fou et a réveillé toutes les applications, entraînant une utilisation élevée du processeur et une chute gigantesque des performances, voire même un crash complet du système dans certains cas.

Dans le cas de Reddit, le problème a principalement affecté la base de données Cassandra et Java, tandis que des problèmes similaires liés au même bug ont été rencontrés dans les bases de données MySQL, les serveurs Tomcat ou Hadoop.

Fait intéressant, les serveurs d’Opera ont planté la veille, après que les serveurs NTP aient annoncé une seconde intercalaire.

Consommation d’énergie

Le centre de données Hetzner Online a signalé qu’au cours de la nuit du 30 juin au 1er juillet 2012, la consommation d’énergie a considérablement augmenté pour dépasser 1 mégawatt. Cela a été causé par le bug décrit ci-dessus. Les processeurs ont soudainement commencé à fonctionner à pleine charge, ce qui s’est traduit par une augmentation de la consommation d’énergie. Le graphique montre 2h du matin, probablement parce que le fuseau horaire est inclus ici. Une augmentation similaire de la consommation d’énergie s’est également produite chez OVH. Il est probable que d’autres centres ont observé la même anomalie, bien que seuls ces deux aient signalé de telles observations.

Le problème de l’an 2000

Il y a plusieurs décennies, nous n’avions pas un tel confort pour utiliser la mémoire sans presque aucune limite.

Par conséquent, l’année était enregistrée en ne donnant que les deux derniers chiffres. Les premiers problèmes ont commencé à apparaître dans les années 1990, lors de la détermination, par exemple, de la validité d’une carte de crédit, qui dépassait l’année 2000. Beaucoup de gens parlaient du désastre qui se produirait à cause de cela, une véritable apocalypse était prédite. La fin du monde, certes, ne s’est pas produite, mais c’est toujours l’une des erreurs les plus stupides commises par les programmeurs. Ne penser qu’au futur proche n’est jamais bon. En fin de compte, il a fallu beaucoup de travail pour remettre les logiciels en état, ce qui, bien sûr, a eu un coût.

Implémentations de la seconde intercalaire

La mise en œuvre la plus simple consiste simplement à annoncer une seconde intercalaire par les serveurs NTP. Ensuite, à la fin de la minute, lorsque cette seconde doit être ajoutée, la valeur 59 apparaît deux fois.

Une autre approche est celle utilisée principalement dans Windows, le système ignore la seconde intercalaire. Ce n’est que lors de la prochaine synchronisation avec NTP que l’heure saute à la valeur correcte.

Les deux solutions ci-dessus ont leurs inconvénients, car dans la première, nous avons la même heure deux fois, et dans la seconde, nous avons un saut étrange, c’est pourquoi Google a décidé d’aborder le sujet différemment. Ils ont trouvé une solution appelée “leap smear”, qui ajoute progressivement des millisecondes à l’heure tout au long de la journée, au lieu d’ajouter une seconde entière à un moment donné. Pour être précis, pour chaque seconde de la journée où une seconde intercalaire doit être ajoutée, une valeur de 1/86400 est ajoutée, ce qui correspond simplement à répartir cette seconde supplémentaire sur les secondes de la journée (246060 = 86400).

Problèmes futurs liés au temps

Le prochain problème lié au temps pourrait survenir le 19 janvier 2038. Sur les systèmes basés sur Unix, le temps est stocké avec le nombre de secondes à partir du 1er janvier 1970 à 00:00:00. Le nombre de secondes est stocké dans une variable entière signée avec une valeur positive maximale de 2 147 483 647 (32 bits), ce qui correspond à l’heure du 19 janvier 2038 à 03:14:07. La solution au problème consistera à passer à l’écriture du temps en utilisant 64 bits, ce qui augmentera considérablement la plage de valeurs (2^63-1). En utilisant 64 bits, le prochain problème de ce type ne se produira pas avant l’année 292 277 026 596, c’est-à-dire dans 292 milliards d’années. Les systèmes d’exploitation seront plus susceptibles de s’adapter aussi harmonieusement que possible. Cependant, il est connu qu’il y aura toujours quelqu’un qui utilise encore un logiciel ancien et non développé et qui aura alors un sérieux problème.

Fin de la seconde intercalaire

Après des années de discussions par divers organismes de normalisation, la décision d’abolir la seconde intercalaire d’ici 2035 a été prise lors de la 27e Conférence générale des poids et mesures en novembre 2022. À partir de 2035, les secondes intercalaires ne seront plus une préoccupation. Le Bureau international des poids et mesures permettra à l’UTC et à l’UT1 de dériver jusqu’en 2135 au moins, dans l’espoir que les scientifiques développeront une meilleure méthode pour tenir compte du temps perdu, ou que les ordinateurs deviendront plus aptes à gérer les changements d’horloge.

Résumé

Comme vous pouvez le constater, la gestion du temps n’est pas facile, surtout dans le cas des secondes intercalaires, où le fonctionnement réel de la solution en production est vérifié très rarement. De tels problèmes sont destinés à se produire. Ce n’est pas surprenant, car ce sont plutôt des solutions de bas niveau, qui sont utilisées par tout un tas d’autres choses. Cependant, il faut admettre que la solution la plus prévisible et la plus sûre semble être celle de Google appelée “Leap smear”, où il n’y a pas de saut artificiel une fois tous les x ans, mais tout se fait en douceur sans affecter le fonctionnement normal. Si vous voulez en savoir plus sur des choses étranges liées au temps, consultez ce site.

P.S. Le jour où la seconde intercalaire est ajoutée, si possible, il vaut mieux ne pas monter dans un avion, et il vaut mieux rester à la maison. À coup sûr, quelque chose ne fonctionnera pas à nouveau, nous verrons ce que ce sera cette fois-ci.

Source de l’article