Notions de Faute, Erreur et Panne

Les types, la fréquence et les solutions aux pannes 

Nous décrirons d’abord la relation existante entre les notions de faute, d’erreur et de panne après avoir donné leurs définitions [1][7]. Ensuite, nous présenterons les différents types de panne d’un système à large échelle tel que le nôtre. Enfin nous étudierons la fréquence de ces pannes et présenterons les solutions existantes pour tolérer (prévenir ou réparer) ces pannes.

Notions de Faute, Erreur et Panne 

❖ Panne (outage) : Un système est dit en panne lorsqu’il ne se comporte pas conformément à sa spécification. Une panne est aussi appelée « défaillance » . Une définition plus détaillée s’appuyant sur les attributs tels que la contrôlabilité, la consistance, les conséquences sur le système et le domaine de panne est donnée en [1].
❖ Erreur (error) : Une erreur est un état anormal d’un système, susceptible de causer une panne, mais ne la provoque pas nécessairement (ou pas immédiatement) soit parce qu’il y a une redondance interne suffisante pour que le système continue de fournir le service, soit la partie erronée de l’état n’est pas utilisée pour telle ou telle fonction. Le temps entre l’apparition de l’état d’erreur et la panne est le délai de latence. Une erreur est latente tant qu’elle n’a pas provoqué de panne.
❖ Faute (fault) : Une faute peut être une action, un événement ou une circonstance qui peut entraîner une erreur.

On remarque qu’il ya une relation de causalité entre Faute, Erreur et Panne. Par exemple, dans le cadre des systèmes pair-à-pair, la panne d’un nœud est une faute (pour le système) qui a pour conséquence l’erreur : le nœud n’est plus accessible. Si un autre pair veut accéder au nœud, cela sera impossible. Le système n’est donc plus conforme à sa spécification, on a donc une panne.

La tolérance aux pannes vise à préserver le service rendu par le système malgré l’occurrence de fautes. Le terme « tolérance aux fautes », en allusion au système lui même, est généralement utilisé à là place de « tolérance aux pannes » ; les fautes du système étant les pannes de ses composants, tolérer ses fautes revient à tolérer les pannes de ses composants. Nous parlerons donc de fautes et de pannes selon le niveau auquel nous nous situons, mais cela correspondra toujours aux pannes des composants (nœuds, réseau de communication).

Les différents types de panne

La classification des différents types de panne étant sous-jacente au modèle du système utilisé, nous allons d’abord présenter l’architecture de notre système avant d’étudier ses pannes. Rappelons que notre objectif est d’acheminer des transactions dans un réseau en pair-à-pair qui, de par sa définition même, est un environnement très volatile où les déconnexions fréquentes de nœuds doivent être prises en charge afin de gérer la cohérence de la base de données répartie.

L’architecture de notre système

Elle correspond à celle d’une base de données répartie au-dessus d’un réseau à large échelle. Elle définit quatre catégories de nœuds. La figure suivante présente l’architecture de notre système et montre ses différents types de nœuds :

• Description de l’architecture : 

➤ DBMS Node : un DBMS Node est un nœud stockant localement une réplique, partielle ou entière, de la base de données avec un SGBD. On distingue généralement deux groupes de DBMS Nodes, ceux qui ont des répliques en lecture seule (read-only) et ceux ayant des répliques en lecture et écriture (read-write).
➤ Catalogue Node : c’est un nœud faisant partie du catalogue gérant les métadonnées. Nous ne nous intéresserons pas à ce type de nœud. En effet nous considérons le catalogue comme une application à part avec laquelle nous interagissons pour lire et/ou écrire dans les métadonnées. Un exemple d’une telle application est l’exemple de Juxmem [2][14] qui est aujourd’hui toujours en phase de développement.
➤ TM Node : un Transaction Manager Node est un nœud chargé d’acheminer les transactions des applications vers les DBMS Node. Lorsqu’il reçoit une transaction d’un utilisateur, il choisit, en fonction des charges et fraîcheurs (et éventuellement d’autres paramètres), le DBMS Node le plus adéquat pour traiter la requête du client. Une étude sur le routage est faite en [3]. Elle se fonde sur la notion de fraîcheur.
➤ Client Node : c’est un nœud demandant un service, un client.

Remarque : un nœud peut-être à la fois un Catalogue Node, un DBMS Node et/ou un TM Node, et comme on est en P2P, il peut jouer le comportement d’un client ou d’un serveur selon les circonstances.

• Fonctionnement du système de routage : 

Le système fonctionne comme suit : un nœud client se connecte à un TM Node et lui envoie sa transaction. Le TM Node analyse la transaction afin de savoir à quelle partie de la base elle veut accéder. Il identifie par la suite l’ensemble des DBMS Nodes stockant une réplique des données sollicitées. Il en choisit le plus optimal (i.e. le nœud avec le coût d’exécution le plus faible) en se basant sur les informations stockées dans le catalogue. Et enfin il route la transaction vers le nœud DBMS choisi pour que celui-ci fasse l’exécution. Après l’exécution de la transaction, le DBMS Node envoie directement les résultats au nœud client qui avait envoyé la requête et un message au TM Node pour lui faire part de la bonne terminaison de la transaction. Durant ce processus faisant intervenir au moins trois nœuds, des pannes peuvent survenir à tout moment. Et suivant le niveau où intervient la panne on peut avoir plusieurs cas que nous allons décrire et classer dans la section ci-après.

Mais avant d’effectuer ce classement, notons d’abord qu’un SGBD est composé de plusieurs composants ou modules chargés d’opérer chacun une tâche spécifique nécessaire au bon fonctionnement du SGBD. L’un de ces composants est le module ou gestionnaire de transactions [4] garant du traitement des transactions (une transaction étant un ensemble d’opérations d’accès et de mise à jour de données émises par un utilisateur). On peut le présenter comme suit :

➤ Module de transactions : il est responsable du traitement des transactions dans l’architecture d’un SGBD. Une transaction étant un ensemble d’opérations d’accès et de mise à jour de données, ces opérations doivent être traitées comme un tout. Le module de transactions doit assurer d’une part l’indivisibilité des opérations soumises, la cohérence du système après l’exécution de l’ensemble des opérations, l’isolation des traitements par rapports aux autres traitements en cours d’exécution et enfin la persistance des résultats. Ce sont les propriétés ACID.

Les différents types de panne 

➤ Panne de SGBD : elle fait référence à la panne du serveur SGBD qui tourne sur un DBMS Node.
➤ Panne du module de transactions : c’est la panne du module de transactions du serveur SGBD d’un DBMS Node.
➤ Panne de nœud : panne d’un nœud du système. Le nœud peut être un nœud TM Node, DBMS Node ou Client Node. La panne peut-être due à une coupure d’alimentation, des problèmes logiciels, matériels (disques, Ram, …).
➤ Panne de communication : messages perdus ou non délivrables, partitionnement du réseau (network partitioning).

Remarque : Les pannes de nœud du type DBMS Node, de SGBD et de module de traitement de transactions induisent les mêmes conséquences: le nœud ne peut pas exécuter de transactions. De ce fait, elles peuvent avoir le même traitement. Nous ne considérerons donc pas les pannes de SGBD et celles du module de traitement de transactions, nous les assimilons à des pannes de nœud puisqu’elles ont les mêmes conséquences. Un autre type de panne que nous assimilons à des pannes de nœud est la panne de transaction (abort). Ces pannes peuvent être dues à des erreurs de données ou des deadlocks.

Notons que dans les systèmes très volatiles que sont les P2P en particulier, la dynamicité a en général les mêmes effets que les pannes. Cependant, il est généralement possible de traiter ces cas de manière plus efficace. En effet, ces interventions peuvent être prévues et les déconnexions peuvent donc être faites « proprement » (en prévenant les autres sites ou nœuds). Notons toutefois qu’un système qui tolère les pannes tolérera également les déconnexions volontaires ou involontaires. Enfin, les équipements réseaux comme les routeurs ou les serveurs de noms peuvent également tomber en panne, rendant ainsi des nœuds temporairement inaccessibles.

Table des matières

Introduction
Chapitre 1 : Les types, la fréquence et les solutions aux pannes
1. Introduction
2. Notions de Faute, Erreur et Panne
3. Les différents types de panne
3.1. L’architecture de notre système
• Description de l’architecture
• Fonctionnement du système de routage
3.2. Les différents types de panne
4. Détermination de la fréquence probable des pannes
5. Étude des solutions existantes pour prévenir ou réparer ces pannes
5.1. Les solutions préventives : la redondance
5.2. Les solutions optimistes ou à posteriori
5.2.1. Principes de détection des pannes
5.2.2. Mise en œuvre de détecteurs de pannes
5.3. Le traitement des erreurs du système
6. Conclusion
Chapitre 2 : La réplication
1. Introduction
2. Avantages et inconvénients
3. Mise à jour synchrone et asynchrone
4. Réplication asymétrique et symétrique
5. Processus de synchronisation
5.1. Initiative du rafraîchissement
5.2. Détection des mises à jour
5.3. Nature des rafraîchissements
6. Notions de cohérence
7. Borner la fréquence des pannes
8. Conclusion
Chapitre 3 : Les mécanismes de gestion de pannes dans un réseau à large échelle
1. Introduction
2. Mécanismes de détection de pannes
2.1. La détection des pannes dans un réseau à large échelle
2.2. Algorithme de détection des pannes de nœud et de communication
3. Mécanismes de tolérance aux pannes
3.1. Algorithme des Client Nodes
A. Les pannes vues à partir d’un nœud client
B. Description de l’algorithme
3.2. Algorithme des DBMS Nodes
A. Les pannes vues à partir d’un DBMS Node
B. Description de l’algorithme
C. Algorithme
3.3. Algorithme des TM Nodes
A. Les pannes vues à partir d’un TM Node
B. Description de l’algorithme
B.1. Tolérance des pannes vues par les TM Nodes
B.2. Validation différée des transactions
C. Algorithme
4. Diagramme de processus UML de notre traitement
5. Conclusion
Chapitre 4 : Validation
1. Introduction
2. Peersim
3. Notre implémentation
3.1. La classe MyCatalogue
3.2. La classe MyProtocol
3.3. La classe MyTransaction
3.4. La classe NetworkInitializer
3.5. La classe NetworkObserver
3.6. La classe NetworkManager
4. Expériences
4.1. Impact du nombre de répliques sur le traitement
4.2. Comparaison avec un traitement ne tolérant pas les pannes
4.3. Impact du nombre de pannes sur le traitement
4.4. Comparaison des approches probabiliste et hiérarchique
5. Conclusion
Conclusion et Perspectives
BIBLIOGRAPHIE

Lire le rapport complet