Plan Introduction Réplication Points de reprise Motivation Techniques

Présentation au sujet: "Plan Introduction Réplication Points de reprise Motivation Techniques"— Transcription de la présentation:

0 Jean-Michel Busca & Maria Gradinariu
Tolérance aux fautes Jean-Michel Busca & Maria Gradinariu Université Paris 6 EFREI

1 Plan Introduction Réplication Points de reprise Motivation Techniques
Principe Réplication active Réplication passive Réplication semi-active Points de reprise Principe Problème EFREI

2 I. Introduction EFREI

3 I.1 Motivation Constat : de plus en plus de systèmes sont critiques. Exemple : pilote automatique d'avion, réseau téléphonique, système d'information d'une entreprise, … d'où besoin d'une disponibilité quasi-permanente. Disponibilité du matériel visée par les constructeurs : 99,999% (5 mn de panne par an). Quid du système, et des logiciels exécutés ? Objectif Assurer la disponibilité et la bonne exécution d'un système critique en dépit de l'occurrence d'une ou plusieurs fautes. critiques : dont le dysfontionnement peut causer la perte de vies humaines, ou bien des pertes financières (perte d'exploitation, perte d'image, …), … EFREI

4 I.2 Techniques Deux types de techniques de tolérance aux fautes :
réplication points de reprise C S1 P1 crash crash S2 P2 S3 P3 Réplication Points de reprise La réplication s'adresse plutôt aux systèmes relativement simples (ex : un serveur autonôme). Les techniques de points de reprise peuvent prendre en compte des systèmes plus complexes (ex : une application de calcul parallèle). EFREI

5 II. Réplication EFREI

6 II.1 Principe Système à fiabiliser : un serveur par exemple.
on réplique le système sur N sites pour tolérer jusqu'à N – 1 fautes simultanées les N sites doivent avoir un taux de fautes corrélées très faible S1 panne reprise S2 S3 panne reprise Sources de corrélation de fautes : logiciel, services réseau (DNS, …), alimentation, … Fautes : pour N – 1, il s'agit de fautes franches Eloignement : doit être en rapport avec l'étendue géographique des clients du serveurs. Comment calculer N ? à partir des probabilité individuelles de pannes p et du taux de disponibilité que l'on souhaite atteindre T Conséquence : les sites sont généralement éloignés, et donc les latences réseau sont élevées A considérer également : panne du réseau d'accès aux sites EFREI

7 ex : réplication active
II.1 Principe (2) Deux types de requêtes à considérer : requête de consultation : le traitement de la requête ne modifie pas l'état du serveur. La requête peut être envoyée à une seule des répliques, par exemple la plus proche. On peut ainsi faire du partage de charge. requête de mise à jour : le traitement de la requête modifie l'état du serveur. La mo-dification induite doit être propagée à l'ensemble des répliques, pour préserver leur cohérence mutuelle. Le mode de propagation est fonction du mode de réplication choisi. consultation mise à jour C S1 Etat du serveur : au sens large - données internes des processus et données stockées sur disques S2 S3 ex : réplication active EFREI

8 II.1 Principe (3) Points à considérer :
utilisation des répliques : toutes actives simultanément, ou seulement une réplique active, les autres étant en attente ? ordonnancement des requêtes : si plusieurs répliques sont actives, il faut ordon-nancer les requêtes sur ces répliques sélection de la réponse à une requête : si plusieurs répliques sont actives, quelle réponse sélectionner comme réponse globale ? Etat du serveur : au sens large - données internes des processus et données stockées sur disques EFREI

9 II.2 Réplication active Toutes les répliques sont actives simultanéments : elles traitent toutes les mêmes requêtes (pour les requêtes de mise à jour), et fournissent toutes une réponse. C1 S1 requête C2 S2 diffusion ordonnée vote réponse … … CM Il s'agit d'un *schéma de principe*. Diffusion ordonnée : du type qui convient (FIFO, causal, total), avec implémentation variable (par exemple, pour ordre total : sequenceur, consensus, ou jeton) Vote : plutôt implémenté sous forme de librairie au niveau de chaque client, car sinon, ne resiste pas aux pannes, ni franches, ni byzantines. SN EFREI

10 II.2 Réplication active (2)
Avantages : recouvrement rapide (les fautes sont transparentes aux clients) : adapté aux systèmes temps réels autorise le masquage des fautes byzantines : en comparant les réponses, le voteur peut écarter jusqu'à (N – 1) / 2 sites byzantins (dans modèle synchrone) Inconvénients : coût en messages et traitement : 1 requête → x . N messages, N traitements latence d'interrogation : tous les sites sont contactés, diffusion ordonnée EFREI

11 II.3 Réplication passive
Il y a deux types de répliques : 1 réplique primaire, N – 1 répliques secondaires. Seule la réplique primaire est active et traite les requêtes. L'état des répliques se-condaires est périodiquement mis à jour à partir de la réplique primaire. C1 S1 requête réponse C2 S2 mise à jour périodique de l'état : - complète - ou par delta sur faute : ré-élection réplique primaire … … Idée : relever et transporter l'état du serveur peut être beaucoup moins couteux que l'exécution de la requête qui modifie l'état. Arpès ré-élection de la réplique primaire, les requêtes sont envoyées vers le nouveau primaire. Peut-être réalisé sous la forme d'un serveur de nom : nom = groupe, adresse = celle du primaire courant. CM SN EFREI

12 II.3 Réplication passive (2)
Avantages : moins de ressources consommées : 1 requête → 2 messages, 1 traitement les sites secondaires peuvent temporairement être affectés à d'autres tâches Inconvénients : lenteur de la reprise, nécessitant la ré-élection du primaire perte de mises à jour possible, si état de reprise non à jour coût du maintien de l'état des secondaires EFREI

13 II.4 Réplication semi-active
La réplication semi-active est identique la réplication active, mais un seul site produit la réponse (pas de phase de vote). C1 S1 réponse requête C2 S2 diffusion ordonnée sur faute : ré-élection du site émettant la réponse … … CM SN EFREI

14 II.4 Réplication semi-active (2)
Avantages : par rapport à active : obtention plus rapide de la réponse (on n'attend pas la réponse de tous les sites pour voter) par rapport à passive : recouvrement plus rapide (simple ré-élection du site donnant le résultat) , pas de perte d'état Inconvénients : par rapport à active : pas de détection de faute byzantine par rapport à passive : plus de ressources consommées EFREI

15 III. Points de reprise EFREI

16 III.1 Principe Système à fiabiliser : un ensemble de processus (ou de sites) qui communiquent entre eux. Chaque processus fait régulièrement une sauvegarde de son état courant (point de reprise) sur support stable (ex : disque RAID1). En cas de défaillance, un processus reprend son exécution à partir du dernier point de reprise qu'il a effectué. reprise crash t P point de reprise Note : la reprise se fait sur le même site si seul le processus est en faute, ou sur un site différent si c'est le site qui est en faute. Dans ce cas, le disque sur lequel sont effectués les points de reprise doit être accessible depuis les deux sites (serveur NFS par exemple). Note : on verra plus tard que plusieurs processus vont devoir reprendre, pas juste le processus fautif. EFREI

17 III.2 Problèmes Il faut assurer la cohérence de la reprise par rapport à l'exécution des autres proces-sus (non en faute). Trois cas peuvent se présenter : le processus qui reprend n'a ni reçu ni émis de message depuis son dernier point de reprise. reprise crash t P Q R Dans ce cas, seul le processus fautif reprend. Tout se passe comme s'il avait été plus lent. EFREI

18 III.2 Problèmes (2) le processus qui reprend a reçu un ou plusieurs messages depuis son dernier point de reprise. reprise crash t P Q R Dans ce cas, les messages reçus depuis le crash doivent être regénérés pour P. Il faut pour cela définir un protocole de (re-)transmission des messages : identification, journalisation sur l'émetteur, ré-émission sur reprise du destinataire. EFREI

19 III.2 Problèmes (3) le processus qui reprend a émis un ou plusieurs messages depuis son dernier point de reprise. reprise crash t P Q R Si on ne fait rien dans ce cas, les messages précédemment émis entre le point de sauvegarde et le crash vont être ré-émis. Deux cas se présentent : si le processus P est déterministe, on peut envisager filtrer les messages sur Q et R lors de leur seconde réception sinon, il faut que les processus Q et R reprennent également leur exécution pour repartir d'une ligne de reprise cohérente. EFREI

20 Conclusion Tolérance aux fautes via la réplication
Coûteuse en bande passante Nécessite l’utilisation des algorithmes de vote ou bien d’accord et des algorithmes de diffusion atomique Tolérance aux fautes via les points de reprise Impraticable dans les systèmes temps réel Nécessite une énorme capacité de stockage Les fautes byzantines ne sont pas tolérées

21 Jean-Michel Busca & Maria Gradinariu
EFREI Temps et datation Jean-Michel Busca & Maria Gradinariu

22 Plan Motivations Horloges physiques Contexte Causalité Datation
Principe Limites Algorithme de resynchronisation

23 Plan (2) Horloges logiques Horloges vectorielles Comparatif Principe
Exemple Propriétés Ordre total Applications Horloges vectorielles Principe Exemple Propriétés Applications Comparatif

24 I. Motivations

25 I.1 Contexte On considère un système réparti comme un ensemble de processus asynchro-nes s'exécutant sur différents sites. Les processus communiquent uniquement par message (pas de mémoire commune). Les délais de communication sont finis, mais non connus et fluctuants. t P1 message P2 P3 P4

26 I.1 Contexte (2) Pour étudier le système réparti, on s'intéresse à la sucession des événements se produisant sur les différents processus. On définit trois types d'événements : - les événements locaux (changement de l'état interne d'un processus) - les émissions de message - les réceptions de message t e10 e11 e12 e13 e14 P1 e20 e21 e22 e23 e24 P2 e30 e31 e32 e33 e34 e35 P3 e40 e41 e42 P4

27 I.2 Causalité Pour étudier la causalité entre les événements, on définit la relation de précédence causale, notée →, traduisant une causalité potentielle entre les événements. a → b si et seulement si : - a et b sont des événements du même processus et a a lieu avant b - a est l'envoi d'un message m et b est la réception de m - il existe c tel que a → c et c → b (fermeture transitive) Définition a → b a a potentiellement causé b a précède causalement b a happened before b Attention "a cause b"  a → b mais a → b  "a cause b" Plutot que la date des événements, ce qui nous intéresse le plus souvent est la relation de causalité entre les événements. La date n'est qu'un moyen d'approcher cette relation. EFREI

28 I.2 Causalité (2) Deux événements qui ne sont pas causalement dépendants l'un de l'autre sont dits concurrents, noté║ : a║b   (a → b)   (b → a) t e10 e11 e12 e13 e14 P1 e20 e21 e22 e23 e24 P2 chemin causal e30 e31 e32 e33 e34 e35 P3 Relations : e10 → e12 e31 → e21 e11 → e35 e12║e22 e32║e23 e33║e14

29 I.2 Causalité (3) Propriétés :
- la précédente causale est une relation d'ordre strict (anti-symétrique, transitive) - l'ordre défini est partiel (existence d'événements║) On a parfois besoin d'un ordre total sur les événements. On étend alors la relation de causalité en un ordre total compatible,en prenant en compte l'identificateur des processus pour distinguer les événements concurrents : a →t b  (a → b)  ( a ║ b  pid(a) < pid(b) ) Compatibilité : (a → b)  (a →t b) pid(e) : PID du processus sur lequel e s'est produit

30 I.3 Datation A chaque événement on associe sa date d'occurrence :
Objectif : trouver un système de datation D qui respecte et représente au mieux la relation de précédente causale. - respecte : (a → b)  D(a) < D(b) exigence minimale, naturelle - représente : (a → b)  D(a) < D(b) plus difficile à obtenir

31 II. Horloges physiques

32 II.1 Principe Les événements sont datés à l'aide de l'horloge physique de chaque site Si. On suppose que : - toutes les horloges sont parfaitement synchronisées au départ, - leur résolution est suffisante pour dater distinctement tous les événements locaux. e11 e12 e13 e14 P1 T1 : 1,07 2,12 … … e21 e22 e23 e24 P2 T2 : 1,23 1,67 … … e31 e32 e33 e34 e35 P3 T3 : 0,45 1,39 … … …

33 II.2 Limites Les horloges physiques dérivent au cours du temps, et le sens et l'amplitude de la dérive est propre à chaque machine. Les événements locaux restent correctement ordonnés par leur date, mais pas nécessairement ceux se produisant sur des ma-chines distinctes. e118523 P1 T1 : 1234,56 e232654 P2 T2 : hypothèse : l'horloge de P2 va moins vite que celle de P1 1234,56 Conséquence : la précedence causale n'est pas respectée. e → e et pourtant T(e118523)  T(e232654)

34 II.2 Limites (2) La datation par horloge physique ne tient pas compte de la causalité des événe-ments non locaux. e11 e12 e13 e14 P1 T1 : 1,07 2,12 … … e21 e22 e23 e24 P2 T2 : 1,23 1,67 … … e31 e32 e33 e34 e35 P3 T3 : 0,45 1,39 … … … La datation temps réel sur-représente la relation de causalité. Conséquence : la précédence causale n'est pas représentée. T(e22) < T(e12) et pourtant non (e22 → e12) EFREI

35 II.3 Algorithmes de resynchronisation
Les algorithmes de resynchronisation (Berkeley, NTP, etc.) permettent de limiter la dérive relative des horloges des sites d'un système réparti. Serveur de temps Hr ? Hr processus H = Hr + T / 2, précision : T / 2 - Tmin T Problèmes : - précision pas toujours suffisante (NTP : 10 ms sur Internet, 1 ms sur LAN) - recalage lissé de l'horloge pour assurer la stricte croissance du temps - il reste toujours la non-représentation de la précédence causale

36 III. Horloges logiques

37 III.1 Principe Chaque processus Pi / site Si maintient une horloge virtuelle scalaire Hi. La valeur de cette horloge est véhiculée dans chaque message pour recaler les horloges locales entre elles. Au départ : Hi = 0 A chaque événement e sur Pi : - événement interne ou émission : Hi++ D(e) = Hi - réception : Hi = max (Hi, Hmsg) // recalage horloge locale Hi++ message Hemetteur Lamport 1978 Messages véhiculant l'heure : il s'agit de messages existant par ailleurs, et non de messages spécialement envoyés pour la gestion des horloges logiques. EFREI

38 III.2 Exemple t P1 H1 : 1 2 5 6 P2 H2 : 2 3 4 5 P3 H3 : 1 2 3 4 6 P4
1 2 5 6 [1] [4] e21 e22 e23 e24 P2 H2 : 2 3 4 5 [1] [5] e31 e32 e33 e34 e35 P3 H3 : 1 2 3 4 6 [1] [2] P4 e41 e42 H3 : Méthode : prendre chaque processus l'un après l'autre. Dater les événements du processus jusqu'à rencontrer une réception dont on ne connaît pas la date d'émission. Passer au processus suivant. Itérer jusqu'à dater tous les événements. 1 2 EFREI

39 III.3 Propriétés P1- H respecte la causalité : (a → b)  H(a) < H(b) . vrai pour deux événements locaux . vrai pour une émission et une réception . vrai dans tous les cas par induction le long du chemin causal P2- H ne représente pas la causalité : H(a) < H(b)  (a → b) . exemple : H(e12) = 2 < H(e23) = 4 et pourtant e12 ║ e23 . résultat attendu : H est un ordre total alors que → est un ordre partiel . seules certitudes : H(a) < H(b)  H(a)  H(b)  (a → b)  (a ║ b) H(a) = H(b)  (a ║ b) P3- H n'a pas de rapport avec le temps physique . exemple 1 : H(e12) = H(e21) et T(e21) < T (e12) . exemple 2 : H(e23) > H(e33) et T(e23) < T (e33)

40 III.4 Ordre total des événements
Deux événements peuvent avoir la même date logique (ils sont alors concurrents). Pour ordonner totalement les événements, on complète la date logique d'un événe-ment par le numéro du processus où il s'est produit : D(e) = (Hi, i), et on utilise la re-lation d'ordre : (Hi, i) < (Hj, j)  (Hi < Hj)  ( Hi = Hj  i < j ) Ce système de datation étendu respecte également la causalité : (a → b)  (Hi, i)a < (Hj, j)b

41 III.5 Applications Exclusion mutuelle répartie
Diffusion fiable et totalement ordonnée Datation des transactions pour gérer les verrous La datation logique permet d'ordonner totalement les requêtes et de fournir des garanties sur leur visibilité (voir le chapitre Exclusion mutuelle).

42 IV. Horloges vectorielles

43 IV.1 Principe Chacun des n processus Pi / site Si maintient une horloge virtuelle vectorielle Vi[1..n]. La valeur de cette horloge est véhiculée dans chaque message pour recaler les horloges locales entre elles. Au départ : Vi = (0, 0,.. 0) A chaque événement e sur Pi : - événement interne ou émission : Vi[i]++ D(e) = Vi - réception : Vi[j] = max (Vi[j], Vmsg[j])  j Vi[i]++ message Vemetteur Fidge, Mattern 1988 Chaque message transporte son passé sur tous les processus. Ve[k] est le nombre d'événements de Pk connus de e, i.e. appartenant à son passé EFREI

44 IV.2 Exemple t P1 V1 : P2 V2 : P3 V3 : P4 V3 : e11 e12 e13 e14
(0,0,0,0) (1,0,0,0) (2,0,0,0) (3,3,1,0) (4,3,1,0) e21 e22 e23 e24 P2 V2 : (0,0,0,0) (0,1,1,0) (1,2,1,0) (1,3,1,0) (1,4,1,0) e31 e32 e33 e34 e35 P3 V3 : (0,0,0,0) (0,0,1,0) (0,0,2,0) (0,0,3,1) (0,0,4,2) (1,4,5,2) P4 e41 e42 V3 : Même méthode de remplissage que les horloges logiques. (0,0,0,0) (0,0,0,1) (0,0,0,2) EFREI

45 IV.3 Propriétés On définit sur les vecteurs la relation :
- Vi  Vj   k, Vi[k]  Vj[k] - Vi < Vj  Vi  Vj  Vi  Vj C'est une relation d'ordre partiel. On note : - Vi ║ Vj   (Vi  Vj )   (Vj  Vi ) On a alors : - (a → b)  V(a) < V(b) - (a → b)  V(a) < V(b) - (a ║ b )  V(a) ║ V(b) les horloges vectorielles respectent la causalité les horloges vectorielles représentent exactement la causalité

46 IV.3 Propriétés (2) Les horloges vectorielles sont denses :
Ve[k] est le nombre d'événements de Pk dont e dépend causalement (Ve[k] – 1 si e est un événement local de Pk) (k Ve[k]) – 1 est le nombre total d'événement dont e dépend causalement tous processus confondus si Ve[k] < Ve'[k] et e' événement non local à Pk alors il existe un événement e" local à Pk tel que non (e" → e) et (e" → e')

47 IV.4 Applications Diffusion causale Debugging réparti
La densite des horloges vectorielles permet de déterminer qu'il n'y a plus d'événement intermédiaire à attendre. Debugging réparti La représentation exacte de l'ordre causal permet de déterminer si les événements observés correspondent à un état cohérent du système.

48 V. Comparatif

49 IV.4 Comparatif Propriétés Remarques Horloge physique Horloge logique
- respecte la dépendance cau-sale si la synchronisation des horloges est suffisante - ne représente pas la dépen-dance causale nécessite un protocole de synchronisation des horloges Horloge physique - respecte la dépendance cau-sale - ne représente pas la dépen-dance causale implémentation simple et peu couteuse Horloge logique respecte et représente la dépendance causale - implémentation couteuse en espace (vecteur) - peu souple lors de l'augmen- tation du nombre de sites Horloge vectorielle