Échecs et tolérance de panne
Dans nos échanges quotidiens, nous avons tendance à parler de façon peu rigoureuse des raisons pour lesquelles les systèmes connaissent des défaillances. Une erreur, une panne, un échec, un bogue, un défaut : ces termes ont tendance à être utilisés de façon interchangeable. Dans le centre de données, les professionnels ne doivent jamais confondre ces mots ou en utiliser un à la place d’un autre. Voici une définition précise des termes relatifs aux discussions sur la tolérance aux pannes :
Un bogue est une anomalie dans la conception d’un système qui fait que son comportement diffère de manière cohérente par rapport à ses spécifications ou à ses attentes. En un sens, il peut s’agir de l’échec du système ou du logiciel à répondre aux attentes, mais un bogue n’est pas un échec du système. En effet, de nombreux bogues sont le produit de systèmes qui fonctionnent exactement comme ils ont été conçus, contrairement à ce qui était prévu. Le mot clé ici est « de façon cohérente ». Le comportement d’un bogue peut être reproduit dans toutes les instances du système. Le débogage est l’action de réingénierie du système menée pour éliminer les bogues.
Une panne est une anomalie dans un système qui fait qu’il se comporte de façon contraire à sa conception, ou qu’il cesse tout simplement de fonctionner. Ici, la conception du système peut ne pas avoir de défauts, mais dans une implémentation ou une instance de cette conception, il peut ne pas fonctionner correctement. Une panne entraîne un comportement dont on ne peut pas attendre qu’il se reproduise dans une autre instance du système. L’action d’élimination d’une panne porte le nom de réparation. Une panne du système peut se manifester elle-même de l’une de ces trois façons :
Une panne permanente est une interruption d’un système dont la cause est irréparable sans un remplacement complet du composant responsable
Une panne transitoire est interruption temporaire, bien que généralement non répétée, du système, dont la cause peut être réparée ou corrigée sur place, ou qui peut probablement se réparer elle-même sans intervention.
Une panne intermittente est une interruption temporaire, généralement répétée, du système, souvent provoquée par la dégradation ou la conception incorrecte d’un composant, et qui peut entraîner une panne permanente si elle n’est pas corrigée.
Un échec est l’effondrement complet de tout ou partie d’un système, souvent déclenché par une panne non traitée. Ici, la panne est la cause et l’échec est le résultat. Un système à tolérance aux pannes est un système qui se comporte comme prévu, ou conformément aux attentes du contrat de niveau de service (SLA), dans des circonstances adverses et qui par conséquent évite l’échec face à des pannes.
Un défaut est une anomalie dans la fabrication d’un composant matériel ou l’instanciation d’un composant logiciel, qui provoque une panne dans son fonctionnement et probablement la défaillance d’un système qui implémente ce composant. Une telle anomalie peut être corrigée seulement via un remplacement.
Une erreur est le produit d’une opération qui produit un résultat indésirable ou incorrect. Dans un appareil informatique, une erreur peut être symptomatique d’un bogue dans sa conception ou d’un défaut dans son implémentation, et elle peut être un indicateur efficace d’un échec imminent.
La maintenance des systèmes à tolérance aux pannes nécessite pour un spécialiste informatique, un administrateur ou un opérateur de bien comprendre ces concepts et leurs différences. Une plateforme cloud computing est par définition un système à tolérance aux pannes. Elle est conçue et construite de façon à anticiper les pannes, et elle fonctionne de façon éviter les échecs des services. Du point de vue de l’ingénierie, cette résilience correspond à ce que signifie le concept de « cloud ». Quand les ingénieurs qui ont conçu les téléphones ont utilisé pour la première fois une forme de nuage dans leurs schémas du système, il représentait des composants du réseau qui ne devaient pas être vus ou compris, mais dont les niveaux de service étaient suffisamment fiables pour ne pas avoir à faire partie du schéma : ils pouvaient être masqués par un nuage.
Quand un système d’information comme un réseau informatique d’entreprise entre en contact avec une plateforme de cloud public, cette plateforme a l’obligation de se comporter comme un système à tolérance aux pannes. Elle ne le fait cependant pas et ne peut pas rendre le système qui communique avec elle plus tolérant aux pannes que ce qu’il est déjà. La tolérance aux pannes n’est pas une immunité ni une garantie contre l’existence de pannes dans un système. Mais surtout, un système à tolérance aux pannes n’est pas nécessairement sans panne. La tolérance aux pannes est plutôt une capacité d’un système à maintenir les niveaux de service attendus quand des pannes se produisent.
L’objectif d’un système d’information est d’automatiser les fonctions qui utilisent des informations. La tolérance aux pannes elle-même ne peut être automatisée qu’à un degré limité. Internet lui-même, dans son incarnation d’origine qui était ARPANET, avait la tolérance aux pannes parmi ses objectifs principaux. En cas de sinistre, les communications numériques pouvaient être redirigées pour contourner un système dont l’adresse n’était plus accessible. Pourtant, Internet n’est pas une machine qui se maintient elle-même, ce qui est aussi le cas de tous les systèmes d’information.
Un travail humain est nécessaire en permanence pour que les systèmes d’information atteignent et conservent leurs objectifs de service. Les meilleurs systèmes rendent l’intervention et la remédiation humaines simples, immédiates et conformes à un plan.
Tolérance aux pannes dans les plateformes cloud
Les premières plateformes de service Cloud étaient en fait moins tolérantes aux pannes que ce que leurs architectes avaient prévu. Par exemple, la possibilité pour un client de surprovisionner des ressources pour des services, comme plusieurs instances de base de données ou des caches mémoire dupliqués, s’est avérée inefficace face à une supervision insuffisante, qui a parfois conduit à l’indisponibilité des sauvegardes ou des réplicas lors de sinistres. De plus, la surprovisionnement va à l’encontre de l’un des principes de base du modèle économique du cloud : payer seulement pour les ressources dont vous avez besoin. Une organisation ne peut pas économiser sur les coûts de fonctionnement si elle loue des instances de machine virtuelle supplémentaires pour le cas où la machine virtuelle principale tombe en panne.
Un système à tolérance aux pannes permet la redondance, mais d’une façon judicieuse et dynamique, en s’ajustant aux besoins et aux limites de disponibilité des ressources à un moment donné. À l’ère du client/serveur, les serveurs tout entiers étaient sauvegardés à intervalles réguliers, y compris leur stockage de données local et les volumes de stockage réseau auxquels ils étaient attachés. « Tout sauvegarder » était devenu la règle dans les entreprises. Une fois que les services de cloud public sont devenus économiques et pratiques, les organisations ont commencé à les utiliser pour « tout sauvegarder ». Au fil du temps, elles ont fini par réaliser que le cloud pouvait en faire plus que perpétuer les anciennes méthodes. Les plateformes cloud pouvaient être conçues d’abord pour la tolérance aux pannes, plutôt que d’être rendues tolérantes aux pannes une fois qu’elles étaient implémentées.
Techniques réactives
Quelle que soit la conception d’un système, la plus grande part de sa tolérance aux pannes dépend de la façon dont le système et les personnes qui le gèrent répondent aux premiers signes d’une panne. Voici quelques-unes des techniques réactives que les organisations utilisent pour atténuer les pannes quand elles se produisent.
Migration non anticipée des travaux
La technique de migration non anticipée des travaux garantit que l’hôte d’une charge de travail qui a apparemment subi une panne n’est pas réaffecté pour héberger cette même charge de travail. Cet avantage protège le « travail », bien qu’il puisse empêcher le système d’être en capacité de collecter les occurrences répétées d’une erreur comme le signe d’une panne, ce qui serait plus facile à suivre via un chemin correctement journalisé.
Réplication des tâches
De nombreux systèmes d’information distribués exécutent simultanément plusieurs instances (ou, pour l’orchestration de Kubernetes, plusieurs réplicas) d’une tâche. Les systèmes de gestion basés sur des stratégies peuvent être adaptés à la réplication d’une tâche s’il y a une panne apparente ou suspectée du système.
Points de contrôle et points de restauration
Dans leur forme la plus simple, les points de contrôle et les points de restauration impliquent la création d’instantanés d’un système à différents points dans le temps, et la possibilité pour les administrateurs de « revenir » à un point spécifié dans le temps si une restauration devient nécessaire. Cette stratégie devient plus compliquée quand des transactions sont impliquées, par exemple quand une application effectue deux actions ou plus sur une base de données, qui doivent ou réussir ou échouer comme un tout (une « transaction »). Un exemple courant est une application qui crédite de l’argent sur un compte tout en le débitant d’un autre compte. Ces opérations doivent ou réussir ou échouer comme un tout afin d’éviter de créer ou de détruire des actifs financiers.
Dans un système de récupération de point de contrôle transactionnel, les enregistrements des transactions réutilisables sont stockés en mémoire dans une arborescence de traitement. À certains points au cours d’une transaction, les ressources mémoire qu’elle utilise sont répliquées et déposées dans un pool de restauration. Dans le cas où l’analyse du journal indique une panne possiblement due au logiciel, l’arborescence de traitement est dupliquée, l’état de la transaction revient à un point antérieur et une nouvelle transaction est tentée. Si la nouvelle transaction réussit mieux que celle qui a posé problème (par exemple si un test de correction d’erreur réussit), l’ancienne branche de traitement est supprimée et la nouvelle branche est suivie à partir de ce point dans l’arborescence, ce que les ingénieurs appellent un changement de contexte1.
Une version sophistiquée de cette méthodologie implémente un système de suivi dans l’arborescence de traitement de sorte que, quand une erreur se produit à nouveau, le système peut effectuer le traitement à l’envers et faire le suivi de la cause de l’erreur. Il peut ensuite sélectionner un point de restauration, ou « point de récupération », approprié avant le déclenchement de l’erreur.[2]
Une autre implémentation, appelée SGuard, a été créée par des chercheurs de l’Université de Washington et Microsoft Research pour le traitement à tolérance aux pannes de gros flux de données. SGuard tire parti de HDFS (Hadoop Distributed File System) pour planifier l’écriture simultanée de plusieurs instantanés de flux de données pendant le traitement. Ces instantanés sont divisés selon les besoins en portions plus petites, ce qui divise à son tour le traitement du flux en segments plus petits. Les points de contrôle sont stockés dans HDFS. Ce système a pour avantage de conserver un enregistrement des transactions des données de streaming ainsi que plusieurs réplicas viables des données de streaming à des emplacements hautement distribués. Bien qu’un travail préparatoire considérable soit nécessaire pour implémenter SGuard, il est toujours considéré comme une technique réactive de tolérance aux pannes, car son fonctionnement principal est déclenché en réponse à un événement de panne3.
Techniques proactives
Une technique de tolérance aux pannes proactive est appliquée avant la révélation de l’existence d’une panne. Son objectif est d’être préventive, mais dans le cas d’une implémentation moderne, elle devient plus une méthodologie qu’un mantra. Voici quelques-unes des techniques actuellement utilisées par les plateformes cloud modernes.
Réplication des ressources
La clé d’une stratégie efficace de réplication des ressources ne peut pas être seulement de « sauvegarder tout ». Un analyste système doit être capable de déterminer les ressources d’un système (par exemple un moteur de base de données, un serveur web ou un routeur de réseau virtuel) qui peuvent se restaurer elles-mêmes après un événement d’échec et celles qui peuvent être irrécupérables. Une réplication intelligente peut être la première ligne de défense dans un système à tolérance aux pannes.
Quatre stratégies courantes sont utilisées pour implémenter la réplication des ressources ; elles sont toutes représentées dans la figure 1 :
Réplication active : toutes les ressources répliquées sont actives simultanément, chacune gérant indépendamment son propre état, c’est-à-dire ses propres données locales qui la rendent fonctionnelle. Cette propriété signifie que la demande d’un client est reçue par toutes les ressources répliquées dans une classe, et que toutes les ressources traitent une réponse. Cependant, c’est la ressource principale désignée dans cette classe dont la réponse est délivrée au client. Si une ressource échoue, y compris le nœud principal, un autre nœud est désigné comme son successeur. Ce système nécessite que le traitement entre le nœud principal et les nœuds de réplica soit déterministe pour se produire en tandem et selon un chemin défini.
Réplication semi-active : la réplication semi-active est similaire à la réplication active, mais à la différence que les nœuds de réplica peuvent traiter les demandes de façon non déterministe, c’est-à-dire pas en tandem avec le nœud principal. Les sorties des ressources secondaires sont supprimées et journalisées, et elles sont prêtes à basculer dès qu’un échec de la ressource principale se produit.
Réplication passive : seul le nœud de ressources principal traite les demandes, tandis que les autres (les réplicas) maintiennent l’état et attendent d’être désignés comme nœud principal si un échec se produit. La ressource principale avec laquelle le client est contacté relaie toutes les modifications de l’état à tous les réplicas. Tous les originaux et tous les réplicas qui appartiennent à une classe sont considérés comme « membres » d’un groupe, et un membre peut être expulsé du groupe s’il semble être en échec (même s’il n’est en réalité pas en échec). La possibilité existe pour la dégradation des latences ou de la qualité de service (QoS) pendant un événement d’échec, bien que la réplication passive consomme moins de ressources qu’en fonctionnement normal.
Réplication semi-passive : cette méthodologie a le même modèle de relations que pour la réplication passive, à ceci près qu’il n’y a pas de ressource principale permanente. Au lieu de cela, le rôle de coordinateur est attribué à chaque ressource tour à tour, la coordination des tours étant déterminée par un modèle de passage de jetons appelé paradigme du coordinateur tournant.
Figure 1 : Nœuds clients, nœuds principaux et nœuds de réplica dans un système d’information répliqué.
Équilibrage de charge
Les équilibreurs de charge distribuent les demandes provenant des différents clients entre plusieurs serveurs exécutant la même application, distribuant ainsi la charge de travail et réduisant la pression sur les composants du système. Un effet collatéral positif de l’utilisation d’un équilibreur de charge est que certains redirigeront automatiquement le trafic en dehors des serveurs qui ne répondent pas, réduisant ainsi les risques que des échecs complets se produisent. Dans les dérivés plus modernes où le logiciel a été conçu pour être distribué sur une plateforme cloud (par exemple les microservices), les charges de travail sont divisées entre des fonctions distinctes, qui sont elles-mêmes distribuées entre les processeurs du côté serveur avec comme objectifs une distribution égale et des niveaux d’utilisation modérés.
La virtualisation (l’ingrédient clé du cloud computing) permet des charges de travail distribuées plus équitablement entre les processeurs en les rendant portables, de sorte qu’elles peuvent être déplacées vers le processeur physique qui peut en faire une utilisation optimale. La conteneurisation améliore cette technique en séparant les charges de travail virtualisées des processeurs virtuels, de sorte qu’elles se trouvent dans le nœud du serveur dont le système d’exploitation est le mieux préparé pour elles. Ce principe est essentiel pour l’orchestration des charges de travail mise en œuvre par des systèmes comme Kubernetes.
Rajeunissement et reconfiguration
Dans les systèmes d’information où des instances d’un logiciel sont déployées pendant longtemps, il peut s’avérer nécessaire de redémarrer ce logiciel. Si certaines plateformes cloud antérieures tentaient d’échantillonner les niveaux de service des instances d’un logiciel au fil du temps pour déterminer le moment où un redémarrage devenait nécessaire, les réalisations plus récentes ont eu recours à une méthode plus simple consistant à planifier des redémarrages périodiques. Au cours de ces phases de redémarrage, les fichiers de configuration du démarrage peuvent être adaptés automatiquement pour tenir compte des circonstances changeantes du système ou pour anticiper un échec potentiel après le démarrage.
Migration anticipée
Quand la virtualisation est devenue un élément essentiel dans les centres de données, la migration anticipée a été suggérée comme méthode pour égaliser la pression exercée sur le matériel du serveur en faisant tourner les affectations des charges de travail sur les processeurs, peut-être en mode tourniquet (round robin). Les plateformes cloud redistribuent les charges de travail sur l’infrastructure virtuelle suffisamment souvent pour que cette méthode soit devenue largement inutile. Cependant, cette problématique est réapparue dans les discussions récentes en conjonction avec les méthodes IA pour prédire la pression exercée par les charges de travail dans différents systèmes informatiques. De tels systèmes peuvent créer leurs propres règles pour déplacer les charges de travail les plus critiques en dehors des nœuds de serveurs pour lesquels il est prédit une plus forte probabilité de panne.
Autoréparation
Dans un système d’information distribué à grande échelle, comme un réseau de distribution de contenu (CDN) ou une plateforme de réseaux sociaux, les fonctions des serveurs individuels peuvent être dispersées sur plusieurs adresses, généralement dans différents emplacements ou centres de données. Un réseau autoréparateur interroge les différentes connexions à intervalles réguliers (par exemple une plateforme de gestion des performances) quant au flux du trafic et à la réactivité. À chaque fois qu’il y a un problème de performances, les routeurs peuvent diriger les demandes en dehors des composants suspects, ce qui finit par stopper la circulation du trafic à travers ces composants. L’état de fonctionnement de ce composant peut alors être testé pour détecter les signes de l’erreur. Le composant peut ensuite être redémarré pour voir si le comportement persiste ; il est replacé dans un état actif seulement si les diagnostics ne révèlent pas la probabilité d’un échec. Ce type de réactivité transactionnelle automatisée est un exemple moderne d’autoréparation dans les centres de données hautement distribués4.
Planification des processus basée sur le troc
Une plateforme cloud (qui inclut des services cloud publics, mais qui peut aussi inclure une infrastructure locale) est capable uniquement de signaler son propre état. Quand Amazon a commencé à implémenter un modèle SaaS révisé en 2009, ses ingénieurs ont élaboré un concept appelé planification des instances choisies (spot instance scheduling). Dans ce système, un proxy silencieux agissant au nom du client publie les besoins en ressources pour un travail donné et diffuse une sorte de demande d’enchères, en particulier depuis les nœuds de serveur sur l’ensemble de la plateforme cloud. Chaque nœud indique sa propre capacité à répondre aux spécifications de l’enchère en termes de temps et de ressources consommées. L’enchérisseur le moins cher gagne le contrat et est désigné comme instance choisie pour le travail. Cette méthode de planification est actuellement une option pour Amazon Elastic Compute Cloud5.
Références
Ioana, Cristescu. A Record-and-Replay Fault Tolerant System for Multithreading Applications. Technical University of Cluj Napoca. http://scholar.harvard.edu/files/cristescu/files/paper.pdf.
Sidiroglou, Stelios, et al.ASSURE: Automatic Software Self-healing Using Rescue Points. Columbia University, 2009.
Kwon Yong-Chul, et al. Fault-tolerant Stream Processing Using a Distributed, Replicated File System. Association for Computing Machinery, 2008. https://db.cs.washington.edu/projects/moirae/moirae-vldb08.pdf.
Yang, Chen. Checkpoint and Restoration of Micro-service in Docker Containers. School of Information Security Engineering, Shanghai Jiao Tong University, Chine, 2015. https://download.atlantis-press.com/article/25844460.pdf.
Amazon Web Services, Inc. Spot Instance Requests Amazon, 2020. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html.