DC PC

Calcul Haute Performance :
SYSTÈMES PARALLÈLES et
DISTRIBUÉS
Mme. Saadia AZEMOUR, Saadia.azemour@gmail.com

Smart Systems Laboratory- ENSIAS, Mohamed V University of Rabat
SYSTÈMES PARALLÈLES DISTRIBUÉS

Introduction
High Performance Computing
SYSTÈMES PARALLÈLES DISTRIBUÉS 2 8

High Performance Computing Distributed Computing Parallel Computing
Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC
Définition
▪ High Performance Computing aussi appelé Calcul Haute Performance consiste à
combiner la puissance de plusieurs milliers de processeurs pour effectuer des calculs
complexes et des traitements de données massives en temps réel.
▪ Le traitement des données et des calculs complexes s’effectue à une très grande vitesse.
▪ Le terme HPC s'applique essentiellement aux systèmes fournissant plus d'un téraflop de
puissance, soit capables de traiter plus de 10^12 opération en virgule flottante par seconde.
▪ Le calcul haute performance consiste à utiliser le traitement parallèle pour exécuter des
applications de façon efficace, fiable et rapide.

Pourquoi HPC ??
▪ Le volume de données à disposition des entreprises a littéralement explosé au fil des
dernières années, avec l’essor des nouvelles technologies comme IoT ou AI ,3D imaging…
▪ Traiter les données en temps réel pour le streaming live d’un événement sportif, le suivi
d’une tempête en développement
Données massives ➔ Très large mémoire

Traitements en temps réel ➔ Augmentation de la puissance de calcul
HPC
Les avantages de HPC

▪ Haute puissance et vitesse supérieure : les architectures HPC sont composées de
processeurs, de systèmes de serveurs et de technologies telles que l’accès direct à la
mémoire à distance. Elles permettent donc d’exécuter des tâches complexes et coûteuses
avec davantage de capacités de calcul
▪ Réduction des coûts : grâce au HPC dans le Cloud, même les plus petites entreprises
peuvent traiter des charges de travail extrêmement importantes et complexes.
▪ Gain de connaissances : dans le secteur de la recherche, le HPC permet l’évaluation et
l’analyse en profondeur d’importants volumes de données(big data) et favorise les
innovations, les prévisions et l’acquisition de nouvelles connaissances.
▪ Gain de temps : grâce à haute puissance des système

Domaines utilisant HPC

▪ Laboratoires de recherche: surtout pour résoudre des simulation numérique intensive qui
demandent la réalisation d’opérations de calcul complexes impliquant des volumes de
données considérables
▪ Industrie : simulations et modèles, par exemple dans le domaine de Machine Learning et
l’intelligence artificielle pour développer les véhicules autonomes ou encore améliorer les
techniques de détection du cancer.
▪ Médias et du divertissement, le HPC peut être utilisé pour les effets spéciaux, animations
ou le streaming d’événements live.
▪ Finance : analyse des risques, détection des fraudes(doit analyser non seulement les millions
de transactions au fur et à mesure qu’elles se produisent, mais aussi les informations
permettant de contextualiser ces transactions), analyses commerciales ou création de modèles
financiers dans le cadre de la technologie financière

Domaines utilisant HPC

▪ Météorologie et climatologie : prévisions météorologiques, modèles climatiques, prévisions
et alertes liées aux catastrophes naturelles; puisque HCP est capable de gérer les équations
différentielles partielles complexes utilisées en physique climatique, ainsi que la quantité
massive de données météorologiques collectées par les satellites.
▪ Gestion des dossiers médicaux : Les systèmes HPC peuvent gérer et analyser les données
médicaux de manière infiniment plus performante que les systèmes de calcul normaux,
réduisant ainsi le temps consacré par le personnel médical à la saisie et à l’organisation des
données de façon à maximiser leur disponibilité pour les patients.
▪ Optimisation des voiture de course : Analyser et perfectionner la dynamique des fluides, en
vue d’identifier les points d’optimisation possibles des voitures tout en restant dans les limites
imposées par la FIA

Composants des solutions HPC

Les solutions HPC reposent sur trois principaux composants :
▪ Composant de calcul : Les processeurs et les ressources disponibles afin de réaliser
des calculs en parallèle qui permettent d'exécuter plusieurs tâches à la fois
▪ Composant de réseau : transmettre des données rapidement entre les composants
de calcul et le composant de stockage. dois être ultra rapide; très haut débit et à haute
résilience
▪ Composant de stockage : Permet de transférer les données vers les composants de
calcul et de les récupérer dès qu’elles sont traitées.

Fonctionnement
▪ Afin de former une architecture de calcul haute performance, les serveurs de calcul sont
mis en réseau sous forme de clusters ce qui permet de fonctionner au maximum de ses
performances
▪ Chaque serveur représente un nœud du cluster.
▪ Les logiciels et les algorithmes sont lancés simultanément sur les serveurs du même
cluster qui opèrent en parallèle.
▪ Le cluster est mise en réseau avec le stockage de données afin de capturer les résultats.
▪ Chaque composant doit être en rythme avec les autres. Par exemple, le composant
stockage doit être en mesure de transférer les données vers les serveurs de calcul et de les
récupérer dès qu’elles sont traitées. De même, le composant réseau doit pouvoir supporter
le transfert rapide des données entre les serveurs et le stockage. Dans le cas contraire, les
performances de l’infrastructure HPC seront amoindries.
▪ Tous les nœuds sont connectés par des connexions réseau ultrarapides
Dans cet exemple nous avons un ensemble

d’ordinateurs multicore qui sont mise en
réseau pour former un cluster:
▪ Chaque ordinateur est appelé un
nœud de calcul
▪ Chaque ordinateur a son propre
system d’exploitation et sa carte
réseau
▪ Supposant que chaque nœud est un
ordinateur quad core ➔ Le system
total a 16 processeurs


Summary
▪ Calcul à Haute performance ➔ demande des calculs parallèles

▪ Plusieurs processeurs effectuant des calculs en même temps
▪ Utilisez des processeurs standard, mais plusieurs milliers d'entre eux
▪ Processeurs de très grande puissance de calcul
▪ Réseau extrêmement rapide pour interconnecter les processeurs

Superordinateurs
▪ un supercomputer (ou supercalculateur) embarque plusieurs milliers de nœuds de

calcul contenant une ou plusieurs puces de calcul et sa propre mémoire.
▪ Ces nœuds peuvent être combinés pour compléter une ou plusieurs tâches.
▪ Utiliser un superordinateur revient à utiliser plusieurs milliers de PC simultanément pour
combiner leur puissances de calcul et effectuer des tâches trop complexes ou trop
longues pour une seule machine.

Processeur
❑ Programmation
▪ Permet d’executer le programme
▪ i.e. un seul cœur dans un processeur multicœur
❑ Hardware
▪ Le composant embarqué sur le circuit de la carte mere
▪ i.e. Le processeur multicoeur complet

Performance
▪ Les performances (délai de résolution) sur un seul ordinateur dépendent de:
o Vitesse d’horloge: une vitesse d'horloge plus élevée signifie un CPU plus rapide
o Unite à virgule flottante: Combien d'opérandes peuvent être utilisés et quelles
opérations peuvent être effectuées
o Latence de mémoire: le délai d’accès à la memoir
o Bande passante mémoire: la vitesse maximale à laquelle les données peuvent être lues
ou stockées par le processeur
o Vitesse pour accéder aux données persistantes
▪ Pour le calcul parallèle, vous pouvez également être limité par les performances de
l'interconnexion.

Cycle de travail d’un ordinateur

Stockage
Mémoire
Unité d’entrée
Unité de sortie
▪ Collecte de l’information
▪ Stockage de l’information
Unité de
contrôle
▪ Traitement de l’information
Traitement
Unité de calcul
Collecte
CPU

Calcul séquentiel
▪ Le programme est divisé en une série d’instructions de différentes tailles
▪ Les instructions sont exécutées séquentiellement une après l'autre
▪ Une instruction doit attendre que la première instruction s’exécute
▪ Un seul processeur avec de faibles performances et une charge de travail élevé
▪ Prend plus de temps car une seule instruction est exécutée à un moment donné
Problem
I9 I8 I7 I6 I5 I4 I3 I2 I1 CPU
Calcul parallèle et HCP

Calcul parallèle et Calcul haute performance sont fortement liés
▪ La haute performance demande l’existence de plusieurs processeurs(des milliers)
▪ Comprendre les différents modèles de programmation parallèle vous permet de
comprendre comment utiliser efficacement les ressources HPC.
▪ Permet également de mieux comprendre et critiquer les travaux qui utilisent le HPC
▪ Vous permet de choisir la ressource appropriée pour votre application.
▪ Permet de comprendre les moyens de paralléliser vos applications

Système de classification des ordinateurs:

Taxonomie de Flynn
❑ La taxonomie de Flynn est une classification des architectures d'ordinateur, proposée
par Michael Flynn (en) en 1966
❑ Cette taxonomie classifie les systèmes informatiques en fonction de la multiplicité du:
▪ Flot d'instructions : Séquence d’instructions exécutée par la machine
▪ Flot de données : Séquence de données appelée par le flot d’instructions

Taxonomie de Flynn
❑ SISD: Single Instruction flow Single Data Stream

❑ SIMD: Single Instruction flow Mingle Data Stream
❑ MISD: Mingle Instruction flow Single Data Stream
❑ MIMD: Mingle Instruction flow Mingle Data Stream
Une seule Plusieurs
instruction Instruction
Une seule
SISD MISD
donnée
Plusieurs
SIMD MIMD
donnée
SISD
▪ Les machines les plus simples qui
Pool d’Instruction possèdent un seul processeur
permettant de traiter une donnée à la
Pool de Donnée
fois
▪ Les systems avec un seul processeur
sont des systems SISD
▪ Un seul flot d’instruction est exécutée à
CPU un moment donné et un seul flot de
donnée (simple, non-structurée) est
traitée à un moment donné.
▪ Non paralélisme
▪ Ces systèmes sont dits « séquentiels ou
Von Neuman ».
SISD
Avantages
▪ Moin cher
▪ Faible consomation énergitique
Inconvénients
▪ Vitesse limitée à cause de l’utilisation d’un seul
processeur
Utilisations
▪ Les microcontroleurs
▪ Les anciennes unités centrales

SIMD
▪ Même instruction est appliquée
simultanément sur différents ensembles de
Pool d’Instruction données
▪ Nous avons plusieurs processeurs, chacun
Pool de Donnée
prends différents élements de donnée et execute

CPU 1 la même instruction.
▪ L’exécution sur les différents processeurs peut
CPU 2 se faire séquentiellement oubien en parallèle
▪ Cas des processeurs vectoriels ou des unités
CPU 3 de calcul gérant le traitement du signal comme
la vidéo ou le son.
CPU 4 ▪ Les systèmes traitant de grandes quantités de
données d'une manière uniforme ont intérêt à
être des SIMD
SIMD
Avantages
▪ Très éfficace lorsqu’on a besoin d’éxécuter la même instruction sur une grande
quantité de donnée
Inconvénients
▪ Limité à certaines applications(graphique, calcul scientifique)
Utilisations
▪ GPUs
▪ Traitements scientifiques
▪ travail avec de grandes matrices

MISD
▪ Plusieurs processeurs utilisent
Pool d’Instruction simultanément un seul flot de données
▪ Chaque processeur exécute une
Pool de Donnée
instruction différente sur le même flot

de donnée
▪ Ce type est beaucoup plus rarement
utilisé
CPU 1 CPU 2 CPU 3 ▪ Adapté à certains spécifique problèmes
▪ Utilisé pour revérifier si les choses sont
comme prévu “double check”

MISD
Avantages
▪ Utile dans les cas où la détection des pannes en temps réel est essentielle
Inconvénients
▪ Compliqué à mettre en œuvre ➔ applications très limitées
Utilisations
▪ Systèmes de vol de la navette spatiale, problèmes temps-réel

MIMD
Pool d’Instruction ▪ Plusieurs processeurs sont entrain
d’exécuter simultanément plusieurs
Pool de Donnée
différentes instructions sur plusieurs

CPU 1 CPU 5 différents éléments de donnée.
▪ Plusieurs instructions peuvent
CPU 2 CPU 6 s’exécuter en même temps en utilisant
différents données
▪ Les systèmes utilisant plusieurs
CPU 3 CPU 7 processeurs ou un processeur multi-
cœur
CPU 4 CPU 8
MIMD
Avantages
▪ Très utile dans les cas où la multitâche est nécessaire
▪ Machine avec multiprogrammation exécutant beaucoup de tâches simultanément
Inconvénients
▪ Trop cher dans les cas des architectures plus compliqués
Utilisations
▪ Les PCs moderne; SmartPhones; Supercomputers.

Architectures
▪ On a normalement deux architectures
principales
▪ La troisième combine les deux premières
« hybride ou architecture à mémoire
partagée distribuée»
Mémoire Mémoire Mémoire

partagée distribuée Hybride

Architecture de la Mémoire Partagée(SMP)
▪ Nous avons une seule mémoire qui est accessible par

tous les processeurs existants
▪ Tous les processeurs partagent un bus commun pour
accéder à la mémoire
▪ Plusieurs programmes peuvent accéder simultanément
à la mémoire
▪ Tous les processeurs sont sous le contrôle d'un système
d'exploitation unique
▪ Consiste à multiplier les processeurs identiques, de
manière à augmenter la puissance de calcul, tout en
conservant une unique mémoire

Mémoire Partagée(SMP)
Avantages
▪ La forme la plus rapide de communication interprocessus
▪ Simple et facile à apprendre
▪ Equilibrage de charge
Limitations
▪ Scalabilité limitée par le nombre de voies d'accès à la mémoire
▪ Problèmes d’accès concurrent
▪ La synchronization est difficile
▪ Difficulté de gérer les données localement
▪ Difficile à construire

Architecture de la Mémoire Distribuée(Cluster)

▪ La mémoire est répartie en plusieurs nœuds chaque portion
est accessible par un processeur
▪ Chaque processeur possède sa propre mémoire privée séparée
des autres processeurs.
▪ Les différents noeuds(processeurs+mémoire…) sont
connéctés via un reseau de communication
▪ Chaque noeud execute sa propre copie de système
d’exploitation
▪ L’échange de donnée se fait explicitement par le passage de
message
▪ On peut ajouter un très grand nombre de processeurs sans
avoir problème au niveau de memoir puisque chacun possède
sa propre mémoire
Architecture de la Mémoire Distribuée(Cluster)

Avantages
▪ La mémoire totale augmente en ajoutant plus de nœud
▪ Scalabilité
▪ Très facile à construire un réseau qui connecte plusieurs nœuds
Limitations
▪ Plusieurs copies séparées de système d’exploitation
▪ Communication entre processeurs plus difficile
▪ Trop cher

Architecture de la Mémoire Partagée Distribuée(DSM)

▪ Nous avons plusieurs noeuds connéctés via un reseau de
communication
▪ Chaque noeud se compose d’un ou plusieurs processeurs et
d’une unite de mémoire
▪ Partage de mémoire entre les processeurs constituant le noeud
▪ Les noeuds sont connecté via un reseau de communication à
grande vitesse (partie distribué)
▪ Un système de transmission de message simple permet à des
processeurs sur des noeuds completement differents de
s’échanger
▪ La mémoire n’est pas partagée physiquement, mais fournit une
zone d’adresse virtuelle partagée entre les noeuds

Architecture de la Mémoire Partagée Distribuée(DSM)

Avantages
▪ Le programmeur n’a pas à se soucier du déplacement des données
▪ Elimine la phase d’échange de données.
▪ Fournit un espace mémoire virtuel important, la taille totale de la mémoire est la
somme de la taille de la mémoire de tous les nœuds
▪ Améliore les performances et l’efficacité en accélérant l’accès aux données
▪ Moins cher par rapport à l’utilisation d’un système multiprocesseur
▪ Scalabilité : les échelles sont assez bonnes avec un grand nombre de nœud
Limitations
▪ Généralement accès plus lent que la mémoire partagée non distribuée
▪ Problème d’accès simultané à la donnée dois assurer une protection supplémentaire.

Introduction et définition Modes de communication et architecture Problème de consensus Blockchain
MIMD
▪ Multitache
Pool d’Instruction
▪ Plusieurs processeurs +
*
Pool de Donnée
▪ Plusieurs instruction, données CPU 1 CPU 5
multiple
▪ Large problèmes CPU 2 CPU 6
▪ Gain de temps CPU 3 CPU 7
▪ SMP, Cluster, Hybride
CPU 4 CPU 8
▪ CD CP
Calcul distribué
▪ Un traitement réparti sur plusieurs machines P1 S1
chacune s’occupe de l’exécution d’une partie du
problème entier pour réduire le temps P2 S2
Problème
d’exécution(augmenter la performance)
▪ Le calcul distribué est souvent réalisé sur des P3 S3
clusters de calcul spécialisés, mais peut aussi être
réalisé sur des stations informatiques
individuelles(des ordinateurs) multicœurs
P4 S4
▪ Utilisé pour résoudre les large problèmes
P5 S5
Système distribué
▪ Ensemble d’équipements autonomes et indépendants connectés
par un réseau
▪ Ces composants communiquent et coordonnent leur actions par
le passage de message « message passing » via le réseau de
communication
▪ Ces composants sont de différents types de différents niveaux de
performance et collaborent pour réaliser une tache commune
▪ L’ensemble des composant apparait aux utilisateurs comme un seul
système cohérent
▪ Chaque élément possède sa propre copie de SE et sa propre
mémoire(pas de mémoire partagée physiquement)
▪ Equipé d'un logiciel dédié à la coordination des activités du
système ainsi qu'au partage des ressources
S.Centralisé VS S.Distribué
Système Centralisé Système distribué
▪ les calculs sont effectués par une seule ▪ Les composants autonomes et indépendants
machine. collaborent et fonctionnent simultanément
▪ Une seule Unité qui coordonne tous les pour effectuer une tache commune
autres nœuds, point de contrôle unique ▪ Distribution de la charge entre les nœuds
▪ Accès locale aux ressources nécessaires ▪ Coordonnent via des messages sur un réseau
(données, code, périphériques, mémoire ...) ▪ Partage et utilisation des ressources sur
▪ Mémoire partagée plusieurs nœuds distincts
▪ Présence d’une horloge globale(du nœud ▪ Mémoire non partagée
central) ▪ Absence de l’horloge globale(diff horloges)
▪ Point de défaillance unique ▪ Défaillance indépendantes (tolérance au
panne)
Exemples
▪ Les serveurs de google sont répartis sur

différentes zones géographiques,
▪ Facebook, Amazone…
▪ Toute application ou service basé sur le
cloud computing
▪ Blockchain

Confidentialité
Transparence
Evolutivité
Les
Avantages
Partage
Fiabilité d’un système
distribué
Accès distant Simultanéité
Economic

Avantages des SD
▪ Évolutivité : la capacité de calcul et de traitement peut être mise à l'échelle selon les besoins
lorsqu'elle est étendue à des machines supplémentaires.
▪ Tolérance au panne : Les membres d'un système distribué peuvent échouer à un moment
ou à un autre tandis que d'autres peuvent continuer d'exécuter, sans réel impact.
▪ Détection des erreurs : les défaillances peuvent être détectées plus facilement
▪ Partage des ressources : un système distribué peut partager du matériel, des logiciels ou
des données.
▪ Transparence : l’ensemble des composants se voit comme une unité de calcul unique, et
l’accès à tous les ressources se fait d’une façon identique et en ignorant leurs situations
géographiques
▪ Confidentialité : On a la mémoire qui n’est pas partagée physiquement d’où les données
brutes ne sont pas disponibles partout et en même temps, seules certaines vues qui sont
exportées.
Avantages des SD
▪ Performance : la mise en commun de plusieurs unités de calcul permet d’effectuer des
calculs parallèle en des temps plus courts.
▪ Traitement simultané(concurrence) : Chaque membre du système distribué effectue en
parallèle, un travail simultané avec les autres.
▪ La redondance : des systèmes redondants permettent de pallier une faute matérielle ou de
choisir le service équivalent avec le temps de réponse le plus court. et permet de diminuer les
pertes de données
▪ Accès distant : un même service peut être utilisé par plusieurs acteurs situés à des endroits
différents.
▪ Economique : Un bon rapport performances/prix

Transparence
Hétérogénéité
Les Défis
Concurrence
Sécurité d’un système
distribué
Evolutivité Ouverture
Imparfaite
Fiabilité

Hétérogénéité
▪ Des machines utilisées (puissance, architecture
matérielle...)
▪ Des systèmes d'exploitation tournant sur ces machines
▪ Des langages de programmation des éléments logiciels
formant le système
▪ Des types de données : structurée, semi structurée,
non structurée
▪ Des réseaux utilisés : impact sur performances, débit,
disponibilité ...
o Réseau local rapide
o Internet

Sécurité
▪ Les contrôles d’accès aux objets partagés sont plus complexes à sécuriser car les voies d’accès au
même objets sont multiples
▪ Communications à travers le réseau peuvent être interceptées
▪ Un seul maillon faible dans un système de fichiers ou un réseau plus vaste du système distribué
peut exposer l’ensemble du système à des attaques
▪ On ne connaît pas toujours bien un élément distant avec qui on communique, ce qui élargit
considérablement la surface d’attaque et expose les organisations aux menaces
▪ La sécurité dans les SD repose sur 3 point essentiels:
o Confidentialité : protection contre tout divulgation à des personnes non autorisées
o Intégrité : protection contre toute altération
o Disponibilité : protection contre les interférences empêchant le bon fonctionnement du
système et l'accès aux ressources(les attaques de déni de service)

Evolutivité
Doubler le nombre de nœuds d’un système distribué ne double pas nécessairement les
performances(conception soigneuse)
Les défis de la conception de systèmes distribués évolutifs incluent :
▪ Contrôler le coût des ressources physiques.
▪ Contrôler la perte de performance(ex: équilibrer la charge de traitement entre les divers matériels partagés,
gestion de la bande passante )
▪ Prévenir l’épuisement des ressources logiciels(Le manque d'évolutivité est illustré par les adresses IP 32
bits. La nouvelle version (IP v6) utilisera des adresses 128 bits)
Les systèmes distribués sont plus complexes à concevoir, à gérer et à comprendre que les
environnements informatiques traditionnels

Fiabilité
La défaillance dans les SD est partielle, certains éléments tombent en panne alors que d’autres
continue de fonctionner, cependant la gestion des panne peut être difficile et complexe(risque de
perdre la performance)
▪ Réseau
o Perte des données transmises si une partie du réseau est inaccessible
o Les temps de communication peuvent varier considérablement selon la charge du
réseau(retard)
o Un segment d’internet surchargé ou indisponible diminue la performance du SD
▪ Machine
o Une ou plusieurs machines peuvent planter, engendrant une paralysie partielle ou totale du
système

Fiabilité
Quelques techniques/conseils à prendre en considération à utiliser pour gérer les pannes:
▪ Détecter les pannes : utiliser des contrôles pour détecter la faille, suspécter l’existence d’une
panne dans un tel segment pour pouvoir la gérer en temps réel
▪ Cacher les pannes : certaines pannes qui ont été détectées peuvent être masquées/cachées ou
rendues moins graves(serveur indisponible, disque corrompu)
▪ Tolérer les pannes : utilisateur peuvent être conçus pour tolérer les pannes , un message
indiquant que le serveur est inaccessible et que l'utilisateur peut essayer plus tard.
▪ Récupération des données après une panne : ajouter des outils(logiciels, techniques) qui
permettent de restaurer les données perdues(serveur de BD)
▪ La redondance : ➔ avoir au minimum deux routes différentes entre deux routeurs
➔ replication des tableaux de nom dans DNS sur deux serveurs(minimum)
➔ données répliquées sur deux serveurs BD
Concurrence
Plusieurs clients peuvent accéder

▪ Il se peut que plusieurs utilisateurs veulent d'accéder à une ressource partagée en même temps
▪ On doit avoir des serveurs concurrent qui permettent de traiter plusieurs requêtes(transactions)
simultanément au lieu d’avoir des serveurs itératifs(requête par thread)
▪ Il faut s'assurer que l'accès simultané aux objets dans une application distribuée est sûr en
utilisant des techniques de synchronisation appropriées

Transparence
▪ Masquer/cacher à l’utilisateur la séparation des composants dans un système distribué, de telle

sort qu’il apparait comme un seul système unique cohérent plutôt qu’une collection de
composants
▪ Un élément doit être invisible ou caché à l'utilisateur ou un autre élément formant le système
distribué (devrait plutôt parler d'opacité dans certains cas ...)
▪ On distingue 8 types de transparence : Transparence d'accès, Transparence de localisation,
Transparence de concurrence, Transparence de réplication, Transparence de mobilité,
Transparence de panne, Transparence de performance, Transparence d'échelle

Transparence
▪ Transparence d'accès
o Accès à des ressources distantes aussi facilement que localement(identique)
o Accès aux données indépendamment de leurs formats de représentation
▪ Transparence de localisation
o Accès aux éléments/ressources sans connaitre de leurs emplacements
o Transparence à la migration
▪ Transparence de concurrence
o Permet à plusieurs processus de fonctionner simultanément en utilisant des ressources
partagées sans provoquer d’interférence
▪ Transparence de réplication
o Possibilité de dupliquer certains éléments/ressources pour augmenter la fiabilité et la
performance sans que les utilisateurs connaissent les répliques
Transparence
▪ Transparence de panne
o Permet de masquer les pannes et réincarnations aux utilisateurs
o Possibilité de terminer les traitements des tâches malgré la défaillance des composants
matériels ou logiciels
▪ Transparence de mobilité
o Permet le mouvement des utilisateurs et des ressources au sein d'un système sans affecter le
fonctionnement du SD
▪ Transparence de performance
o Possibilité de reconfigurer le système pour en augmenter les performances lorsque les
charges varient
▪ Transparence d'échelle
o Doit supporter l'augmentation de la taille du système sans modification interne des
algorithmes d’application
Un SD doit offrir au minimum la transparence d’accès de localisation et de concurrence
Transparence

Types des systèmes distribué Subtransaction 1
Nested transaction
▪ Distributed Computing systems
Hotel
o Cluster computing Subtransaction 2
o Grid computing
▪ Distributed Information systems
Airline
o Systèmes de traitement de transaction
o Enterprise application integration Use 3 different independent DB
Subtransaction 3
▪ Distributed Pervacive Systems(omniprésent)

o Electronic health system
o Sensor network(IoT devices)

Distributed computing system

▪ Grid Computing
o Ensemble de ressources informatiques de types souvent très différents(ordi, serveur,
cluster) et de domaine de fonctionnement différents
o Distribuées dans des lieux éventuellement très éloignés
o Relié par internet ou autres types de réseaux spécialisés
▪ Cluster Computing
o Ensemble de stations de travail ou des Pcs(nœuds), généralement homogènes(identiques) et
sont étroitement interconnecté par le même réseau local à haut débit
o Généralement réunies en un seul lieu
o Coopèrent et forment une seule unité informatique virtuelle
o Souvent utilisé pour la programmation parallèle dans laquelle un seul programme (calcul
intensif) est exécuté en parallèle sur les différents nœuds d’un cluster
o Un nœud maitre s’occupe de la gestion(répartition) des taches entre les nœuds esclaves
Cluster computing Grid computing

Clusters dans un system HPC

Architecture des systèmes distribués

▪ Une telle architecture est décrite par :
o le placement des entités sur le réseau (distribution des données, charge effective)
o les relations existantes entre ces entités (rôles fonctionnels, communications)
▪ Les architectures des systèmes distribués les plus courantes sont les suivants:
o Architecture client/serveur
o Architecture client/serveur à plusieurs niveaux(n-tiers)
o Architecture Pair à Pair (P2P)
o …

Architecture Client/Serveur
▪ Le client déclenche la communication(établi une Demande
connexion) avant d’envoyer le message contenant la de service
demande au serveur
▪ Le serveur attend passivement les requêtes des clients. Client Serveur
▪ Le serveur exécute le service associé à la demande émise
par le client et utilise généralement la même connexion
pour retourner au client le message contenant le résultat Résultat
du service effectué
▪ Pour les applications client/serveur, le client est
responsable de la présentation de l'interface utilisateur, et
c’est à travers cette interface qu’on se connecte au serveur
via le réseau, et le serveur est responsable de la gestion
des données et de la partie de traitement métier
Architecture Client/Serveur
▪ Une architecture client-serveur peut facilement se
transformer en architecture centralisée si le serveur
n'est pas redondant
Client Serveur
▪ Une configuration client-serveur réellement
distribuée comportera plusieurs nœuds de serveur
pour distribuer les requêtes des clients
Serveur
▪ La plupart des architectures client-serveur Serveur
modernes sont des clients qui se connectent à un
système distribué encapsulé sur le serveur.
Architecture à plusieurs niveau n Tiers

3-Tiers
▪ Ce type d'architecture permet de distribuer plus librement la Accès au
données
logique applicative, ce qui facilite la répartition de la charge entre
tous les niveaux.
Métier
▪ le serveur se décompose en d'autres nœuds granulaires, qui
découplent les responsabilités supplémentaires du serveur
principal Présentation
▪ l'architecture n-tiers qualifie la distribution d'application entre de

multiples services et non la multiplication des niveaux de service.
▪ Les taches sont logiquement et physiquement réparties sur
plusieurs machines, chaque machine étant adaptée à un type
spécifique de taches
▪ Un serveur peut parfois avoir besoin d'agir comme un client
Architecture Pair à Pair(P2P)

▪ Chaque participant est connecté avec les participants d’un groupe et tout
le monde effectue les mêmes types d'actions A(f1)
▪ Les pairs mettent une partie de leurs ressources(puissance de traitement, le
stockage sur disque,…) à la disposition des autres participants du réseau
▪ Répartition des taches et de charge entre les pairs
▪ Dans les réseaux pair-à-pair un nœud peut être client et serveur en même
B(f2)
temps
o Pure(Décentralisée) : tous les nœuds participants sont des Pairs et
aucun serveur central n'est utilisé pour contrôler, coordonner ou gérer
les échanges entre Pairs
o Hybride(Centralisée) : un serveur central qui effectue un certain C(f3)
nombre de fonctions essentielles(gère la liste des pairs, le client se
connecte au serveur grâce à un logiciel de partage)
Communication
▪ Toutes les communications dans un système distribué sont basées sur la
transmission de messages(envoie et réception).
▪ Les processus s'exécutent sur différentes machines et échangent des
informations via la transmission de message
▪ Un bon modèle de communication est celui qui masque ou simplifie la
transmission des messages.

Rappelle : Modèle OSI

▪ Lorsqu’un processus A veut communiquer avec un
processus B situé dans une machine distante, il crée
un message dans son espace d’adresse et le
transmet à la couche application
▪ Le logiciel de la couche application ajoute ensuite un
en-tête au début du message et transmet le
message résultant à la couche présentation à travers
l'interface de couche 6/7

Rappelle : Modèle OSI

▪ La couche de présentation, à son tour, ajoute son
propre en-tête et transmet le résultat à la couche de
session, et ainsi de suite
▪ la couche physique transmet le message en le plaçant
sur le support de transmission physique
▪ Lorsque le message arrive sur la machine distante
exécutant le processus B, il est transmis vers le haut,
chaque couche supprime et examine son propre en-tête.
▪ Enfin, le message arrive au récepteur, processus B
Communication
▪ Bas niveau : communication se fait directement en appelant les services des couches
TCP ou UDP
o Exemple : utilisation des sockets
▪ Haut niveau : définition des couches offrant des services plus complexe
o Couches réalisées en s’appuyant sur les couches TCP/UDP(middleware)
o Exemple appelle d’une méthode chez une entité distante
o RPC(Remote Procedure Call)
o RMI(Remote Method Invocation)

Socket
Une socket correspond à un port d'écoute sur
une machine (cliente / serveur) et sert donc à
pouvoir échanger des données entre plusieurs
ordinateurs connectés au réseau
▪ Une entité envoie des données à une
deuxième entité
▪ La deuxième entité envoie un acquittement
pour prévenir qu'elle a bien reçue les données

Middleware(intergiciel)
▪ Le middleware est une couche
intermédiaire(couche logiciel) qui s’intercale
entre l’infrastructure de communication
d’un réseau et les élément de l’application
distribuée
▪ Pour assurer la communication entre les
applications quelles que soient les
caractéristiques matérielles, logicielles(réseau, SE)

Principe de RPC
▪ Un processus appelle localement une procédure

qui est réellement implémentée sur une machine
distante
▪ Il faut que les appelles soit transparents
▪ La procedure appelante ne doit pas savoir que la
procedure appelée s’execute sur une machine
différente ou inversement

Vertical scaling
▪ Consiste à augmenter les ressources des serveurs(RAM, CPU)

▪ Cette méthode est très efficace dans le cas de services qui
peuvent se paralléliser.
▪ C’est ce qu’on appelle le « Scale up »
▪ On peut rapidement atteindre les limites de cette méthode
▪ A un moment donné on ne peut plus augmenter les ressources
▪ En adoptant le Vertical Scaling on perd en
disponibilité(serveur tombe en panne)
▪ Par contre on gagne en cohérence(lecture de la donnée
modifée)

Horizontal scaling
▪ Consiste à augmenter le nombre de serveurs (de manière

automatique ou manuelle, définitive ou temporaire) pour
augmenter les capacités et ressources disponibles selon la charge
▪ C’est ce qu’on appelle le « Scale out »
▪ La bonne gestion nous permet de gagner la disponibilité(en cas
de défaillance matérielle sur un serveur)
▪ On aura besoin d’un Load Balancer pour équilibrer les charges

Vertical vs Horizontal scaling


Equilibrage de charge
▪ Le load balancing, ou répartition de charge, est une technologie(processus) conçue pour
distribuer la charge de travail(les taches) entre différents serveurs ou applications.
▪ Permet d’équilibrer la charge de travail entre les serveurs, pour maintenir leur capacité à un
niveau optimal
▪ Empêche un serveur de devenir surchargé
▪ limite les risques de pannes liés à une surcharge (prévoir une solution de secours)
▪ Optimiser la performance globale de l’infrastructure, son rendement et sa capacité.
▪ Réduire le temps de réponse d’un site suite aux requêtes des utilisateurs
Algorithmes
d’équilibrage de charge
Algorithmes Algorithmes
statiques dynamiques
▪ Ne prend pas en compte l’état du ▪ La charge de chacun des nœuds
système dans la répartition des tâches du système est pris en compte
▪ Envoient une quantité égale de trafic ▪ Les nœuds moins chargés vont
à chaque serveur d'un groupe avoir plus de demande
▪ Round Robin, weighted Round ▪ Least connections, weighted
Robin least connections
Round Robin
▪ Cette méthode crée une file d’attente pour les
demandes entrantes. Ces dernières sont ensuite
gérées par le répartiteur de charge, qui les
distribue vers une liste de serveurs en rotation en
utilisant le (DNS). Les requêtes sont assignées
de manière séquentielle, selon la disponibilité des
machines.
▪ Ne tient pas compte de l’urgence de la demande,
ni de la charge qu’elle va représenter pour le
serveur concerné
▪ Il est donc adapté aux environnements où les
serveurs disposent de ressources identiques

Weighted Round Robin

▪ Permet à un administrateur d'attribuer des poids
différents à chaque serveur selon sa capacité et
sa puissance.
▪ Les serveurs jugés capables de gérer plus de
trafic en recevront un peu plus. La pondération
peut être configurée dans enregistrements DNS.
▪ Cette méthode convient donc mieux à un
environnement dont les ressources entre les
serveurs diffèrent : la charge est optimisée en
fonction de leurs capacités
▪ Le load balancer attribue plus de charge à la
machine la plus robuste

Least connections
▪ Il tient compte en effet des demandes déjà
existantes sur le serveur web durant la
distribution
▪ Détermine le serveur qui a moins de demande
et assigne la nouvelle demande à ce serveur
▪ Ne tient pas compte des capacités techniques
des serveurs.
▪ adapté aux environnements dont les ressources
serveur sont identiques
▪ Cela suppose que toutes les connexions
nécessitent une puissance de traitement à peu
près égale.

Weighted Least connections
▪ Donne aux administrateurs la possibilité

d'attribuer des poids différents à chaque serveur,
en partant du principe que certains serveurs
peuvent gérer plus de connexions que d'autres.
▪ le serveur le plus puissant a une pondération plus
importante.
▪ Permet de maintenir une répartition optimale des
requêtes dans un cluster

Tolérance aux pannes
❑ Le système peut fournir ses services même en

présence de pannes.
❑ Le système continue à fonctionner de manière
acceptable pendant les réparations.
❑ Haute disponibilité
❑ Transparence de panne
SYSTÈMES PARALLÈLES DISTRIBUÉS _81 8

Difficulté de détection des pannes
❑ Le nœud 4 est très lent : le problème n’est pas

nécessairement lié à ce nœud si N4 attends le
résultat de N1 pour continuer ses traitements
▪ Problème lié au Nœud 1
▪ Problème lié au Nœud 2
▪ La route n’est plus accessible

Types de pannes
▪ Panne franche : Le système fonctionne correctement jusqu’à se qu’il s’arrête de répondre à
toute sollicitation, c’est une panne permanente(fail stop, Crush)
▪ Panne par omission: pas de réponse aux demandes(msg perdus en émission/en réception)
▪ Omission en émission: Le serveur effectue ses traitement mais, il échoue d’une façon ou
d’autre à envoyer la réponse(le tampon d’émission est plein et le serveur n’est pas préparé
pour une telle situation)
▪ Omission en réception: Peut être que le serveur n’a pas reçu la demande pour qu’il puisse
répondre(la connexion est bien établie mais y avais pas de thread en écoute ) cette faute
n’affecte pas l’état du serveur puisqu’il n’est pas en courant qu’un msg lui est envoyé
Types de pannes
▪ Panne temporelle : le temps de réponse du système dépasse les exigences des spécifications
▪ Une étape du processus s'exécute en plus de temps que la borne prévue
▪ Un message émis est reçu après un délai supérieur à la borne prévue
▪ Panne Byzantine: fautes arbitraires, fautes difficilement détectable et plus complexe à gérer
▪ Le processus envoie des valeurs fausses et/ou fait n’importe quoi
▪ Le processus fait des calculs erronés ou non fait
▪ Message modifié, dupliqué lors de transmission via le canal

Tolérance aux pannes
Comment la tolérance aux pannes peut-elle

réellement être atteinte dans les systèmes
distribués ???
➢ Redondance des services
➢ Réplication des données

Réplication
❑ La réplication consiste à conserver plusieurs copies de données
à différents endroits.
❑ Base de donnée, système de fichier,…
❑ Améliorer les performances(mise à l’echelle, répartir workload)
❑ Améliore la disponibilité des données.
❑ Augmente la tolérance aux pannes
❑ Très utile si on veut faire la maintenance du système
❑ Fournir une meilleure protection contre les données
corrompues
Problème avec Réplication

❑ La réplication est simple si les données sont statiques
(inchangeables)
❑ L'un des problèmes majeurs est de maintenir la cohérence
des répliques
❑ Les mises à jour doivent être propagées plus ou moins
immédiatement entre les répliques
❑ lorsqu’une opération est effectuée sur copie, la mise à jour
doit être propagée à toutes les copies avant qu’une
opération ultérieure s’effectue
Réplication des BD
Replication Master-Slave : Créer deux nouveaux
serveurs de base de donnée (esclaves) qui synchronisent
avec le principal(maître)
▪ Le maître reçoit des requêtes en lecture ou en
écriture des clients. Lorsque le maître reçoit une
requête en écriture, il valide et exécute localement
cette requête avant de la faire suivre aux esclaves
pour qu'ils exécutent localement le même
changement et obtenir le même état que maître. On peut perdre la cohérence

Réplication des BD
Multi-Master Replication : plusieurs nœuds maîtres
qui supportent les lectures et les écritures.
▪ Les mises à jour par n'importe quel membre du
groupe.
▪ Tous les membres peuvent répondre aux requêtes
des clients
▪ Possibilité de créer des conflits (par exemple,
insertion de deux enregistrements avec le même ID)
Conflits

fragmentation de BD
Fragmentation : Vous divisez votre base de donnée en
plusieurs base de données plus petites, appelés fragments.
Ces fragments contiennent tous des enregistrements
différents.
▪ la machine 1 contiendrait les noms de A à L, la machine
2 de M à R et la machine 3 de S à Z.
▪ le vrai point faible de cette approche est que si l'une des
machines plante, toute une partie des données sera
On risque de perdre la disponibilité
inaccessible
Théorème de CAP
▪ En 2000, Eric A. Brewer a formalisé un théorème très

intéressant reposant sur 3 propriétés fondamentales
pour caractériser les bases de données:
▪ Un système de base de donnée distribué ne peut
fournir que deux des trois caractéristiques souhaitées :
cohérence (Consistency), disponibilité (Availability)
et tolérance au partitionnement (Partition
Tolérance).
Théorème de CAP
▪ Cohérence: le système renvoie les données les plus
récentes, les clients ont le même affichage quel que soit le
nœud auquel ils se connectent.
▪ Disponibilité : Le système répond toujours aux requêtes
des clients, peu importe qu’il retourne la copie la plus
récente ou non.
▪ Tolérance de partition : Le système continuera à
fonctionner lorsque des partitions réseau se
produisent(coupure de communication)
CA = Consistency + Availability
▪ Cette combinaison n'est possible que dans le contexte de

bases de données transactionnelles telles que SGBDR
▪ Lors d'opérations concurrentes sur une même donnée,
les requêtes L1 et L2 retournent la nouvelle version (v2)
et sans délai d'attente
▪ Le client effectue une transaction(retirer une somme
d’argent) dans un guichet automatique
▪ Les autres branches ont la même vue cohérente du solde

CP = Consistency + Partition
▪ il est nécessaire de vérifier la cohérence
▪ La gestion de cette cohérence nécessite un protocole de synchronisation
des réplicas, introduisant des délais de latence dans les temps de réponse (L1
et L2 attendent la synchronisation pour voir v2)
▪ C’est le cas de la base de donnée NoSQL MongoDB
▪ Le client effectue une transaction(retirer une somme d’argent) dans un
guichet automatique
▪ Le guichet ne va pas accepter de retirer la somme d’argent, puisqu’il ne peut
pas partager la mise à jour avec le deuxième guichet, ce n’est pas sûr
▪ Dans ce cas on gagne la cohérence mais on perd la disponibilité

AP = Availability + Partition
▪ Lorsqu’on a une partition réseau qui empêche la communication,
les différentes parties fonctionnent indépendamment
▪ C’est le cas de la base de donnée Cassandra où les temps de
réponse sont appréciables mais avec possibilité d’incohérence
▪ Dans ce cas le guichet automatique valide la transaction du client
et lui permet de retirer la somme d’argent
▪ Dans ce cas on a le service qui est disponible, mais les deux
serveurs n’ont pas le même solde
▪ On gagne la disponibilité mais on perd la cohérence
Théorème de CAP

Problème de consensus
❑ Il faut garantir la cohérence des donnée dans les différentes
répliques(CP)
❑ Il faut que l’ensemble de nœuds se mettent d'accord sur une
décision de validation ou annulation d’une telle transaction
❑ Le problème de décider s'il faut valider une transaction dans
une base de données pourrait être résolu par un algorithme
de consensus entre une majorité de répliques
❑ Algortithme 2PC, 3PC

Problème de consensus
❑ La résolution du consensus est primordiale pour la coordination des systèmes distribués et
pour la consistance des systèmes répliqués malgré la défaillance d'une partie de leurs
composants
❑ Résoudre le problème de consensus entre les différents nœuds d’un système distribué est simple
dans un contexte sans défaillance mais difficile à réaliser dans un contexte avec défaillance
❑ Il existe plusieurs algorithmes qui permettent de résoudre le problème de consensus dans un
environnement synchrone
❑ C’est impossible de résoudre le problème de consensus avec ces algorithmes dans certain
environnement asynchrone
Impossibilité FLP: Fischer, Lynch et Paterson.
❑ Dans un environnement asynchrone où un processus peut produire au moins une défaillance, le

problème du consensus binaire ne peut être résolu par un algorithme déterministe
❑ Ce résultat peut être contourné par l'utilisation d'algorithmes aléatoires qui résolvent le
consensus avec probabilité 1 avec un temps d'exécution infini.

Principe générale
Des processus doivent se mettre d'accord sur une valeur commune

❑ Chaque processus fait une mesure ou un calcul pour décider une telle valeur : valeur locale
proposée et la diffuse à tous les autres processus
❑ A partir de toutes les valeurs proposées, les processus doivent se décider sur une valeur
unique commune
▪ Soit un processus initie la phase d'accord
▪ Soit la phase d'accord est lancée à des instants prédéterminés(limité)

Principe générale(Contexte sans panne)

{v1,v2,v3,v4,v5}
▪ Après la proposition d’une valeur, chaque processus envoie sa valeur à tous
P1
les autres via une diffusion fiable

▪ A la réception de toutes les valeurs, chaque processus applique une fonction P5 P2
donnée sur l'ensemble des valeurs qu’il a reçu pour prendre la décision finale
▪ La décision finale est envoyée à tous les processus P4 P3
▪ Chaque processus est donc certain d'avoir récupéré la valeur commune qui P1
sera la même pour tous

P5 P2
➢ Passer par un processus coordinateur qui centralise la réception des valeurs

P4 P3
proposées et fait la décision, puis la diffuse
Conditions à valider
❑ Terminaison: La phase de décision se déroule en un temps fini : tout processus correct
décide en un temps fini
❑ Intégrité: Un processus décide au plus une fois : pas de changement de choix de valeur
❑ Accord: La valeur décidée est la même pour tous les processus corrects
❑ Validité: La valeur choisi ‘finalement’ par un processus est une des valeurs proposées par
l'ensemble des processus

Principe générale(Ex : transaction distribuée)

➢ Pour une transaction : il faut exécuter toutes les actions de la transaction ou annuler le tous
➢ Dans un SD(BD) on peut avoir des transactions provenant d’un seul nœuds mais doivent
s’exécuter sur plusieurs nœuds qui vont participer à la transaction(diff zones, synchronise)
➢ Donc on doit s’assurer que la transaction est exécutée par tous les nœuds ou bien annulée par
tous les nœuds
▪ Transfert d'argent d'un compte vers un autre
▪ Nécessite un débit puis un crédit
▪ Il faut faire les 2 actions ou aucune sinon on se retrouve dans un état incohérent
▪ Begin Transaction Debiter (#1244, 1000$) Crediter (#8812, 1000$) End Transaction
Principe générale(Ex : transaction distribuée)

➢ Tous les serveurs doivent se mettent d'accord sur la faisabilité de la transaction
➢ Détermination d'une décision globale entre
➢ Valider : l'action de la transaction sera exécutée par tous les processus
➢ Annuler : aucune action ne sera exécutée par aucun processus
➢ Le coordinateur demande l'avis de tous les processus sur la faisabilité de l'action
➢ Si tous les processus répondent « Oui» P1
➢ La décision est de valider, chacun exécute l'action

P5 P2
➢ Sinon, si au moins un processus avait répondu « non »

P4 P3
➢ La décision est d'annuler, personne n'exécute l'action

Principe aller/retour
La détection d’une telle panne se fait à l’aide du principe aller – retour de message
➢ On envoie un message à un élément
➢ On attend sa réponse dans un intervalle de temps (délai de garde)
➢ Estimé à 2 fois le temps de transit d'un message (+ delta éventuel)
➢ Si on a pas reçu de réponse avant l'expiration du délai de garde
➢ Message perdu ou l'élément avec qui on communique est planté
➢ Pb dans un système asynchrone : estimation du délai de garde

2 phase Commit(2PC): Types d’éléments
Dans 2PC on parle de deux types d’éléments :

❑ Un coordinateur qui est le responsable de la coordination et de
l’initialisation du protocol (qui a reçu la transaction du client) CT
❑ Les autres entités sont des participants à la transaction

▪ On demandera à chacun d'entre eux s'il peut ou pas valider la
transaction P1 P4
P2
Le protocole fait en sorte que tous les nœuds lancent la transaction
P3
ou la quittent.

2 phase Commit(2PC)
Dans 2PC on a deux phases. Une phase de préparation et une

deuxième phase de commit. Cet algorithme assure l’atomicité des
transactions distribuées.
❑ Phase de préparation(vote) : l’envoie de la demande de vote à
tous les participants, et la réception des résultats
❑ Phase de commit(validation) : Diffusion de la décision
globale(prise) par le coordinateur et envoie des ACK de la
réception de la décision globale
2PC : Phase de preparation
Participant 1
▪ Une fois qu’un nœud reçoit une demande du

client contenant la transaction à valider, il va
initier le protocol(coordinateur) Can commit?
Coordinateur Participant 2
▪ Le coordinateur envoie une demande de vote à
tous les participants il leur propose de se préparer
pour valider la transaction
Participant 3


▪ Chaque participant étudie la demande du
Participant 1
coordinateur selon son contexte local
▪ Le participant vérifie est ce qu’il est capable
d’exécuter la transaction ou non(a une contrainte
Yes/No
qui l’empêche d’exécuter) Coordinateur Participant 2
▪ Le participant répond par oui s’il est

définitivement capable de valider la transaction
▪ Le participant n’a pas le droit de changer sa Participant 3
décision
2PC : Phase de commit(décision)

▪ Une fois que le coordinateur reçoit les réponses
Participant 1
des participants, il les étudie et prend la décision
globale(finale)
▪ Si tous les participant on voté par oui : la décision
Do commit?
Coordinateur Participant 2
finale sera valider la transaction tous
▪ Si au moins un participant à envoyé non la
décision finale sera annuler la transaction
▪ Le coordinateur diffuse la décision globale(finale) Participant 3
à tous les participants

Participant 1
▪ Si la décision globale est Valider tous les
participants vont exécuter la transaction et
envoyer un acquittement au coordinateur pour lui
ACK
préciser qu’ils ont reçu la décision globale(finale) Coordinateur Participant 2
▪ Si la décision globale est Annuler les participants

vont annuler la transaction même ceux qui ont
voté par oui, tous les participants vont appliquer Participant 3
la décision prise par le coordinateur, envoie ACK

Scénario de panne : Phase de préparation
Participant 1
▪ P3 a planté après la réception du message du

coordinateur Can commit?
Coordinateur Yes Participant 2
➔ Annulation de la transaction
Participant 3

Scénario de panne : Phase de Commit

▪ P3 a planté après envoyer sa réponse au
Participant 1
coordinateur
▪ Pour le coordinateur tous le monde à voté par oui
donc la décision globale est
Can commit?
➔Validation de la transaction
▪ Tous les participants vont executer la transaction
sauf P3 qui est planté
▪ P3 se reveille ➔ contacter le coordinateur pour Participant 3
S’il a voté non il sait que la
lui envoyer la décision globale(fich.log) décision est annulation

Participant 1
▪ Coordinateur a planté après distribuer la décision

globale qui est valider à tous les participant
▪ Coordinateur va se diriger au fichier log pour Can commit?
Coordinateur Do commit Yes Participant 2
appliquer les modifications ➔ voir qu’il a valider
la transaction
▪ Envoyer la décision finale encore une fois pour
Participant 3
s’assurer que tous les participants l’ont reçu

Participant 1
▪ Coordinateur plante avant de distribuer la
décision globale
▪ Le coordinateur doit se réveiller pour prendre la
Can commit?
décision finale et l’envoyer aux participants
▪ Les participants ne savent pas quoi faire
▪ Tous les participants attendent la décision globale
prise par le coordinateur(en panne) Si aucune décision n'a été prise = Participant 3
recommencer le protocol dés le départ
➔Etat de blocage
2PC Gestion de problèmes

❑ Si un Pi n’a pas reçu la décision finale du coordinateur:
▪ Le coordinateur est planté (avant/après la prise de décision finale)
▪ Le msg envoyé par le coordinateur est perdu
o Pi peut contacter les autres participants pour savoir s’ils ont reçu la décision finale
o Si aucun participant ne lui répond(ont rien reçu)
o Si Pi a voté non ➔ décision finale = Annulation de transaction
o Si Pi a voté oui ➔ Aucune idée sur la décision finale, Pi ne sait pas quoi
faire Pi bloqué

❑ Phase de préparation : Si le coordinateur n’a pas reçu la réponse de Pi et le délai de
garde est expiré :
▪ Pi est planté
▪ La réponse de Pi est perdu
▪ Pi n’a pas reçu la demande de vote(relancer la demande de vote à Pi va déclencher d’autre problème)
La décision globale(finale) ➔ Annulation de la transaction


❑ Phase de commit : Si le coordinateur n’a pas reçu tous les acquittements:
▪ Le coordinateur ne sait pas si tout le monde a reçu la décision
▪ Si la décision était annuler, pas si grave
▪ Si la décision était valider : est ce que tous les participants ont validé la transaction
➢ envoyer la décision globale à ces participants en espérant recevoir les ACK

Coordinateur diagramme d’état

Processus Pi diagramme d’état

Propriétés à respecter
❑ Safety : Le système ne doit pas se trouver dans un état d’incohérence,

on peut pas trouver des nœuds qui valident la transaction et d’autres
qui l’annulent
❑ Liveness : Un système ne doit pas se trouver dans un état bloquant

2PC vers 3PC
❑ Liveness n'est pas assurée par 2PC, ce protocole est potentiellement bloquant
▪ Un nœud peut se retrouver dans un état où il ne sait pas quoi faire
▪ État de blocage jusqu’à ce que le coordinateur se réveille
❑ 3 phase Commit(3PC) est un protocol non bloquant utilisé pour surmonter ce problème
❑ 3PC est une extension de 2PC qui ajoute une nouvelle phase entre préparation et
commit pour informer les participants de la décision globale avant de leur demander
l’exécution de la transaction pour éliminer l’état de blocage

3 Phase Commit (3PC)

❑ Première phase : la demande de préparation et attente des votes (idem que pour 2PC)
❑ Deuxième phase : l’envoie du message « preCommit » à tous les participants si la
décision globale est valider, attente des acquittements de la réception
❑ Troisième phase : diffusion de la demande de validation de la transaction (si la décision
était valider) ou d’annulation de la transaction

Validation à 3PC (cas sans panne)

❑ Phase de préparation
▪ Le coordinateur envoie une demande de participation à tous les participants
▪ Chaque processus étudie la demande selon son contexte local et vote par oui ou non(envoie son
vote au coordinateur)
❑ Phase de pré-validation(preCommit) :
▪ Si tous les participants ont voté par oui le coordinateur leurs envoie un message preCommit
Pour qu’ils sachent que la décision globale est valider mais ne vont pas encore valider
▪ Chaque participant envoie au coordinateur un acquittement de la réception de la demande de
preCommit
Validation à 3PC (cas sans panne)

❑ Phase de Commit
▪ Après la phase de preCommit le coordinateur
diffuse la demande de validation finale aux
participants pour qu’ils exécute la transaction
▪ Si au moins un participant a voté par non, on passe
directement de la phase de préparation à la phase
Commit sans passer par la phase preCommit
▪ Dans ce cas le coordinateur diffuse la demande
d’annulation de la transaction
Scénario de panne : Phase de préparation
Participant 1
▪ P3 a planté après la réception du message du

coordinateur Can commit?
➔ Annulation de la transaction
Participant 3

Scénario de panne : Phase PreCommit

P3 a planté après recevoir le message preCommit
Participant 1
▪ P3 se reveille ➔ consulte sa mémoire et va
savoir qu’il a reçu preCommit et envoie ACK
▪ Après l’expiration du délai de garde le
PreCommit?
Coordinateur ACK Participant 2
coordinateur va envoyer la demande de validation
à tous les participant
▪ P3 n’a pas reçu la demande de validation, il
connaît déjà que la décision globale est valider Participant 3
PreCommit n’est envoyé que
car il a déjà reçu PreCommit si la décision prise est valider

Scénario de panne : Phase de PreCommit
Participant 1
P3 a planté avant recevoir le message preCommit

▪ P3 se reveille ➔ contacter les participants PreCommit?
▪ Si au moins un a reçu preCommit ➔Valider
▪ Si aucun n’a reçu preCommit ➔ Annuler
▪ P3 se reveille ➔ contacter le coordinateur
Participant 3
S’il a voté non il sait que la
décision est annulation


▪ Coordinateur plante après PreCommit, avant de
Participant 1
distribuer la demande de validation

▪ Les participants vont se contacter, ils ont reçu
preCommit ➔ Valider la transaction PreCommit
▪ Une fois que le coordinateur se réveille il va
consulter sont fichier log et voir qu’il a envoyé
preCommit et va donc savoir que la transaction
Participant 3
a été validé, et passe également à la valider Les participants connaissent déjà la
décision globale : ils ont reçu
preCommit
Diagramme d’état du coordinateur

Diagramme d’état d’un processus Pi

3PC Conclusion
❑ Si un participant reçoit un « preCommit » de la part du coordinateur, il sait alors que
quoiqu'il arrive tous les processus ont décidé de valider la requête
❑ Principe est qu'un coordinateur ou un participant n'a pas de doute sur le fait de transiter
vers annuler ou valider
▪ Pas de possibilité d'aller vers les 2 états finaux directement
▪ Comme on peut l'avoir en 2PC : pour participant, en attente de la décision
globale a une transition vers valider et une vers annuler(blocage)
❑ Dans ces cas 3PC assure Liveness pas d’état bloquant

Principe general de Paxos
▪ Paxos est similaire à 2PC, mais avec quelques modifications

▪ Un (ou plusieurs) nœud décide d'être coordinateur(accepteurs/acceptors)
▪ Un proposeur(proposer) propose une valeur et demande l'acceptation des autres accepteurs
(acceptors)
▪ L’accepteur annonce la valeur choisie ou réessaye s'il n'a pas réussi à converger vers une valeur
▪ Les apprenants (learners) execute la valeur choisie

Paxos est très utilisé
▪ Google: Chubby (distributed lock service based on Paxos)

▪ Yahoo: Zookeeper (distributed lock service based on Paxos)
▪ MSR: Frangipani (distributed lock service based on Paxos)
▪ YFS labs contain a Paxos assignment.
▪ UW: Scatter (coherent DHT based on Paxos)
▪ Open source: libpaxos (atomic diffusion based on Paxos) and Zookeeper is open-source and
integrates with Hadoop

Paxos : Les roles des processus
Paxos distingue 3 rôles :

▪ Proposers : leurs rôle est de proposer des valeurs(requêtes) pour le consensus
▪ Acceptors : leurs rôle est de choisir une valeur(requête) proposée par les proposers
▪ Learners : apprend quelle valeur à été choisie et agissent sur cette valeur
Une machine peut jouer l’un des 3 rôles, et/ou tous les rôles

Les roles des processus

Une base de donnée joue tous les rôles :
▪ Proposeur : lorsqu’elle reçoit une requête du client,
elle va la proposer la validation(exécution)
▪ Accepteur : en executant un protocol pour decider
(avec les autres repliques/acceptors) quelle requête va
être exécutée
▪ Apprenant : exécute(valide) la requête choisie
Une fois une valeur(requête) a été choisie il n y a plus de
divergence possible même si d’autres proposeurs proposent
▪ Chaque accepteur accepte plusieurs propositions

▪ Pour qu’une proposition soit acceptée il faut quelle reçoit un vote majoritaire
▪ Sinon, répéter la demande de vote
▪ Une proposition est définie par un tuple(numéro de séquence, ,valeur)
▪ Numéro de séquence : strictement croissante et unique


▪ Proposeur
▪ Choisir un numéro de séquence np unique, plus élevé que les numéros de séquence dejà
choisi
▪ Si les accepteurs ont déjà accepté des propositions(valeurs v)
▪ choisir la valeur v associée au numéro n le pus élevé
▪ Sinon, proposer une valeur vp
▪ Le but est d’atteindre le consensus et non pas de gagner
▪ Accepteurs : essaie d’accepter la valeur avec le numéro de séquence le plus élevé
▪ Apprenants : sont passifs et attends le résultat du consensus pour l’exécuter
Paxos : Phase 1
Proposeur:
Choisi un numéro de sequence np, et envoie un message prepare(np) aux accepteurs
Accepteurs:
Si np > na
na = np ← promise not to accept any new proposals n’ < n
Si aucune proposition préalable n’a été acceptée
Envoie promise(np,Ø) ← dans ce cas va = Ø
Sinon
Envoie promise(np, va) ← dans ce cas va = (n,v)
Else
envoie prepare-failed

Paxos : Phase 2
Proposeur:
Si recevoir promise de la majorité(f+1) des accepteurs,
Si majorité des promise reçus ont va= Ø
proposer une valeur vp
Sinon determiner v renvoyée avec n le plus elevé
envoie accept(np,v||vp) aux accepteurs
Accepteurs:
Dès recevoir accept(np, vp) , Si np ≥ na
Accepter la valeur propose vp et notifier les apprenants
va = (na, vp)

Paxos : Phase 3
Les apprenants ont besoin de savoir la valeur choisie

Approach #1
Chaque accepteur notifie tous les apprenants
Approach #2
Élire un « Apprenant » , et les accepteurs informent l'apprenant
élu, qui va s’occuper d’informer les autres

Paxos
Phase 1 Phase 2 Phase 3

➔Proposeur envoie ➔Si le proposeur reçoit au moins f+1 Promise avec va= Ø il a le ➔Envoie de
Prepare(np) droit de proposer une valeur vp de son choix notification aux
➔Si np > na → l’accepteur ➔Sinon(va =(n,v)) il va choisir la valeur v associée au plus grand learners
envoie Promise(np, va) et na = numéro de séquence n ➔Si un learner
np Sinon il va annuler ➔ Le proposeur envoie Accept(np, v|| vp) reçoit f+1 notif
➔ Si proposeur reçoit la ➔ Si np ≥ na l’accepteur valide la requête(vp) et mis à jour sa pour le même
majorité des votes f+1 il passe à Valeur(va=(na,vp)) Sinon il va l’annuler couple(n,v) il va
la phase 2 ➔ Si la majorité acceptent on dit : vp est acceptée par le protocol exécuter

Paxos : Phase 1
On considère un système de 3 accepteurs et deux proposeurs P1 et P2 et qu’on vient de commencer
le protocol et qu’aucune requête n’a été acceptée na=0 et va= Ø pour tous les accepteurs
▪ P1 veut premièrement proposer une valeur : il choisi un numéro de séquence unique np1=2
▪ Le proposeur P1 envoie une requête Prepape(2) à l’ensemble des accepteurs
▪ Chaque accepteur reçevant Prepare(2) va effectuer la comparaison np1 > na ➔2>0 ➔na=2
▪ Tous les accepteurs vont envoyer promise(2, Ø)
▪ Si P2 veut proposer une valeur : et il choisi un numéro de séquence unique np2=1
▪ On a np2 <na➔1 < 2
▪ Tous les accepteurs vont répondre par prepare-failed
Paxos : Phase 1
P1
Prepare(2)
P2
Prepare(1)
Pomise(2,Ø)
prepare-failed
na1=2
A1
na1=0
va1= Ø Pomise(2,Ø) prepare-failed
na2=2
A2
na2=0
va2= Ø Pomise(2,Ø)
prepare-failed
na3=2
A3
na3=0
va3= Ø P1 a reçu la majorité des réponses valides ➔ P1 peut passer à la Phase 2
Paxos : Phase 2
Une fois qu’un Proposeur P1 a reçu la majorité des réponses valides il passe à la phase 2 :
▪ P1 propose une valeur si toutes les réponse Promise contient va= Ø sinon il va choisir la valeur
associée au plus grand numéro de sequence na
▪ Dans notre cas P1 a reçu trois promise(2, Ø) donc P1 va proposer une valeur np1
▪ Le proposeur P1 envoie une requête Accept(2, vp1) à l’ensemble des accepteurs
▪ Chaque accepteur recevant Accept(2, vp1) doit décider s’il va accepter ou refuser la requête
▪ l’accepteur va accepter la requête qui contient np≥na Sinon il va annuler
▪ Si la requête est acceptée par la majorité qui est f+1 ➔ Acceptation ; (on a 2≥2, accepter vp1)
▪ Une fois qu’un accepteur accepte une requête il mis à jour sa variable va=(2, vp1)
Paxos : Phase 2
P1
Prepare(2)
P2
Pomise(2,Ø) Accept(2,vp1)
na1=2
Va1=(2 ,v p1)
A1
na1=0
na2=2 Va2=(2,v p1)
A2
na2=0
na3=2 Va3=(2,v p1)
A3
na3=0 P1 à le droit de décider une valeur de son choix car va= Ø
va3= Ø La requête est acceptée par la majorité ➔ passer à la phase 3
Paxos : Phase 3
L1
L2
P1
Prepare(2)
P2
Pomise(2,Ø) Accept(2,vp1)
Notify(2,Vp1)
na1=2
Va1=(2 ,v p1)
A1
na1=0
na2=2 Va2=(2,v p1)
A2
na2=0
na3=2 Va3=(2,v p1)
A3
na3=0
va3= Ø Les apprenants sont les répliques qui vont exécuter la transaction contenue dans Vp1

Convergence de Paxos ➔P2 envoie une requête

Prepare(3)
Si on a 2 deux accepteurs avec va= Ø quelle est la valeur qui va être choisi
➔A1 et A2 envoient
P1 Promise(3,(2,vp1))
Prepare(2)
P2 ➔ A3 envoie Promise(3, Ø)
Accept(3,vp1)
Promise(2,Ø) Accept(2,vp1) Prepare(3) ➔P2 n’a pas reçu f+1 promise
na1=2 Promise(3,(2,vp1)) avec va= Ø
Va1=(2 ,v p1 ) na1=3
A1
na1=0 ➔Pas possible pour P2 de
va1= Ø Promise(2,Ø) Promise(3,(2,vp1)) proposer une valeur de son
na2=2 Va2=(2,v p1) na2=3
A2 choix, il est forcé d’envoyer
na2=0
va2= Ø Promise(2,Ø) Promise(3,Ø) Accept(3,vp1)
A3
na3=2 X na3=3
➔la requête Accept(3, vp1) est
na3=0
va3= Ø La convergence est vérifiée même si P2 voulait proposer une nouvelle valeur acceptée par la majorité

Convergence de Paxos
Si A2 tombe en panne après recevoir prepare(3)
➔P2 envoie une requête
P1
Prepare(2) Prepare(3)
P2
Prepare(3) Accept(3,vp1) ➔A2 ne va pas traiter la
Promise(2,Ø) Accept(2,vp1)
Promise(3,(2,vp1)) requête puisqu’il est planté
na1=2 Va1=(2 ,vp1)
A1 na1=3
➔A1 et A3 envoie Promise
na1=0
va1= Ø Promise(2,Ø) ➔on a Accept(3, vp1) qui
na2=2 Va2=(2,v p1)
A2
na2=0
X est accépté par la majorité 2
va2= Ø Promise(2,Ø) Promise(3,Ø) ➔Donc vp1 est toujours
A3
na3=2 X na3=3
na3=0
considérée comme stable
va3= Ø La convergence est vérifiée même si un ou plusieurs accepteurs tombent en panne
Si A2 se réveille
P1
Prepare(2) ➔les valeurs de A2
P2
Accept(3,vp1) sont les même avant
Promise(2,Ø) Accept(2,vp1) Prepare(3)
Pomise(3,(2,vp1)) la panne na2 =2 et
na1=2 Va1=(2 ,vp1) Accept(3,vp1)
A1 na1=3
va2=(2,vp1)
na1=0
va1= Ø Promise(2,Ø) Pomise(3,(2,vp1)) ➔A2 envoie la
na2=2 Va2=(2,v p1)
na2=3
A2
na2=0
X X requête promise
va2= Ø Promise(2,Ø) Pomise(3,Ø) ➔il s’agit toujours
A3
na3=2 X na3=3
de la même valeur
na3=0
va3= Ø La convergence est vérifiée même si A2 se réveille avant que le consensus termine vp1
L1
L2
P1
Prepare(2)
P2
Accept(3,vp1) Accept(3,vp1)
Pomise(3,(2,vp1))
na1=2 Va1=(2 ,vp1)
A1 na1=3
na1=0
va1= Ø Promise(2,Ø) Notify(2,vp1) Pomise(3,(2,vp1))
na2=2 Va2=(2,v p1) na2=3
A2
na2=0
X X
va2= Ø Promise(2,Ø) Pomise(3,Ø) Notify(2,vp1)
A3
na3=2 X na3=3
na3=0 Les learners on reçu plus que f+1 notification pour le même couple (2,vp1) = exécute
va3= Ø la requête compris dans la valeur vp1
L1
L2
P1
Prepare(2)
P2
Accept(3,vp1) Accept(3,vp1)
Pomise(3,(2,vp1))
na1=2 Va1=(2 ,vp1)
A1 na1=3
na1=0 Notify(2,vp1)
Pomise(3,(2,vp1))
va1= Ø Promise(2,Ø)
na2=2 Va2=(2,v p1) na2=3
A2
na2=0
X X
va2= Ø Promise(2,Ø) Pomise(3,Ø) Notify(2,vp1)
A3
na3=2 X na3=3
na3=0 ▪ Learners se rond compte qu’il s’agit toujours de la même instance de consensus vp1 : ignorer la notif
va3= Ø ▪ S’ils n’ont pas reçu f+1 notifications : ils vont aussi ignorer la notif
Problème de Livelock
L1
L2
P1
P2
Pomise(1,Ø) Pomise(2, Ø)
na1=1
A1 na1=2
na1=0
va1= Ø Pomise(1,Ø) Pomise(2,Ø)
na2=1 na2=2
A2
na2=0
va2= Ø Pomise(1,Ø) Pomise(2,Ø)
na3=1 na3=2
A3
na3=0 Le message Prepare(2) de P2 empêche que P1 fini son consensus avec n=1, passer à n=3
va3= Ø Le message Prepare(3) de P1 empêche que P2 fini son consensus avec n=2, passer à n=4,…
Problème de Livelock
▪ Paxos risque d’être livelock si un autre proposeur interagie avant que le premier termine ces
deux phases
▪ Chaque proposeur essaye de tirer la convergence à lui et d’empêcher l’autre proposeur de

faire aboutir le consensus
▪ Solution : Garantir la présence d’un seul proposeur dans le système et de ne pas accepter de
nouveau proposeur qu’après l’expiration du délai de garde nécessaire pour terminer les deux
phase

Leader pour éviter livelock

▪ Le leader collecte les valeur des différent proposeurs et choisi une pour initier le protocol
▪ Election du leader :
▪ Paxos peut être utilisé pour l’élection du leader
▪ Avec possibilité de livelock
▪ La meilleur façon de le faire est d’utiliser l’algorithme de Bully
▪ Chaque serveur envoie son ID à tous les autres
▪ Le serveur ayant l’ID le plus élevé est le leader

Safety & Liveness
▪ Paxos assure la propriété sûreté(safety) dans le sens où seules les opérations validées seront
exécutées, et qu'au plus une opération sera apprise à la fois
▪ Dans les environnement synchrones : Paxos assure les deux propriétés sûreté(safety) et
vivacity (liveness)
▪ Dans les environnement asynchrones : dans certains cas Paxos assure uniquement la propriété
Safety
▪ Problème de Livelock si on a plusieurs proposeurs qui tirent la convergence à eux

Paxos : Scénarios de pannes

▪ Avec un seul proposeur
▪ Si un ou plusieurs accepteurs tombent en panne
▪ Possibilité d’atteindre le consensus si la majorité(f+1) n’est pas plantée
▪ Si le proposeur se plante dans la 1ère phase après recevoir la requête Promise
▪ Un autre proposeur va commencer sa phase de préparation
▪ Si le proposeur se plante dans la 2ème phase après envoyer la requête Accept
▪ Un autre proposeur peut prendre son rôle et termine le protocol
▪ Avec deux proposeurs simultanément ➔ Livelock, éviter ce problème avec l’élection

Consensus :Faute byzantine env synhrone
▪ Contrairement aux pannes franches, il n'est pas toujours possible d’atteindre le consensus
dans un contexte de fautes byzantines
▪ Lamport, Shostak et Pease ont montré en 1982, via le problème des généraux byzantins, que
▪ Si f est le nombre de processus fautifs, il faut avoir au minimum 3f + 1 processus (au
total) pour que le consensus soit assuré
▪ En dessous, il n'est pas assuré

Généraux byzantine
Les généraux veulent attaquer une ville

Pour réussir cette attaque il faut que tous les généraux atteint le consensus
Problème des généraux byzantins

▪ Un ensemble de généraux doivent se coordonner pour mener une attaque
▪ Doivent tous faire la même chose (attaque ou retraite)
▪ Le commandant prend l'ordre et l'envoie aux autres généraux (ses
lieutenants)
▪ Ces derniers se renvoient l'ordre entre eux pour s'assurer qu'il est bien
reçu et qui est le bon
▪ Le problème est qu’un certain nombre de généraux peuvent être des traîtres
“attack”
▪ Ils vont envoyer des ordres falsifiés aux autres généraux
▪ Les généraux loyaux doivent détecter les traîtres et ignorer leurs ordres
Problème des généraux byzantines

▪ Cas 1 : le commandant envoie un ordre pour attaquer
• Le lieutenant 2 est le traitre, il a modifié l’ordre du commandant
“attack”
“attack”
• lieutenant 1 reçoit deux ordres contradictoires, il est incapable
“retreat”
de savoir lequel est le vrai(correct)
Ltn 1 “attack”
o Cas 2 : le commandant est le traitre, il a envoyé deux ordres Ltn 2
différents
▪ lieutenant 1 reçoit deux ordre contradictoires en étant
“attack” “retreat”
incapable de savoir le vrai
“retreat”
Avec 3 généraux il est impossible de détecter le traitre
Ltn 1 “attack” Ltn 2
Besoin d’un 4ième pour recevoir un message de plus et savoir le vrai ordre
Algorithme des généraux byzantins

▪ Contraintes à assurer par l'algorithme
▪ IC1 : tous les lieutenants loyaux obéissent au même ordre
▪ IC2 : si le commandant est loyal, les lieutenants loyaux doivent obéir à son ordre
▪ Si le nombre de traitres est limité égale à m
▪ Il faut : n > 3m avec n = nombre de généraux


Commandant
A
➔ P(0) : pas de traitre L1
▪ Le commandant diffuse son ordre « attaque » à tous les V1=A

A
lieutenants Li A
▪ Pour tout Li, à la réception de la valeur du chef, chaque

lieutenant positionne vi à la valeur reçue
L3 L2
▪ S’il ne reçoit rien vi= DEF
V3=A V2=A
▪ Les lieutenants suivent l’ordre vi si elle n’est pas vide

Algorithme des généraux byzantins A,A,R

f=1, n=4 v1=A
➔ P(f) : f traitres Commandant Val=A
▪ Le commandant diffuse sa valeur à tous les lieutenants Li A
▪ Pour chaque Li, à la réception de la valeur du chef, chaque

R
A
lieutenant positionne vi à la valeur reçue
A R A
▪ Chaque lieutenant diffuse sa valeur vi aux n-2 en jouant le rôle
A
du commandant
R
▪ Une fois Li reçoit les valeur vj des autres lieutenants, il
A
détermine la valeur locale vi A,A,R
A,A,R v2=R
v3=A
➔ val = la valeur majoritaire ou vi = DEF si pas de majorité Val=A
Val=A


▪ Chaque lieutenant Li possède une valeur locale vi qui est l'ordre qu'il a décidé de suivre
▪ Déterminé en fonction de ce qu'il a reçu des autres généraux
▪ P(m) : algorithme pour m traitre au plus

▪ S'appliquera de manière récursive : P(m– 1), P(m– 2) jusqu'à atteindre P(0)
▪ Pour un P(x), un lieutenant joue le rôle du commandant et diffuse sa valeur à tous les
autres lieutenants
▪ Plus il y a de traîtres possibles, plus on s'échange de messages
▪ Nombre de messages : O( n^m) avec n > 3m


▪ Cas P(0) (aucun participant est byzantin : m = 0) :
• Le commandant L0 envoie la valeur v à tous ses lieutenants.
• Si le lieutenant Lj reçoit la valeur v alors vj = v sinon vj = DEF (détection d’une non
réception d’un message).
▪ Cas P(m) (m participants byzantins, m > 0, n > 3m > 0) :
• Le commandant L0 envoie la valeur v à tous ses lieutenants.
• Pour chaque lieutenant Lj , si il reçoit la valeur v alors vj = v sinon vj = DEF
• Pour chaque lieutenant Li et tout j ≠ i
• Soit vj = la valeur v que Li reçoit de Lj lors de P(m-1); vj = DEF si aucune valeur est
reçue
• val = majorité(v0, . . . , vn−1) définie par {majorité(v0, . . . , vn−1) = v si v est
majoritaire ou DEF s’il n’existe aucune valeur majoritaire}
• val est la valeur décidé dans ce tour
Analogie avec le problème de consensus
▪ Les processus sont identifiable et se connaissent: chaque processus peut envoyer

un message à n'importe quel autre processus
▪ Les messages ne sont pas perdus ou modifiés pendant leur transfert :
Communication fiable
▪ Pas de panne franche


▪ L’algorithme des généraux byzantins
▪ Correspond à une réalisation de consensus dans un contexte de fautes byzantines
▪ Certains processus effectuent des fautes byzantines : envoi de valeur erronée voire aucun
envoi de valeur
▪ Les processus correct doivent aboutir à prendre une décision commune
▪ Les processus effectuant les fautes byzantines ne doivent pas aboutir au fait que la prise
de décision des processus corrects soit mauvaise ou pas identique chez tous

Problème byzantin Problème de consensus
Les n généraux Les n processus
Les f traitres (byzantins) Les f pannes
Ordre envoyé par le général i V(i) suggestion du processus i
Résultat : attaque ou retraite Décision finale prise en consensus

Registre répliqué et distribué Utilise un réseau P2P pour fournir

plusieurs copies des mêmes données
Les transactions sont effectuées de

Une chaine de blocs horodatés
manière décentralisée
L'autorité centrale est remplacée par

Reliés par la cryptographie
le protocole de consensus (CP)
Blockchain
Résistant à la modification de ses CP assure l’accord des pairs sur l’état
données du register (grand livre)
Les transaction sont représentées Système BC peut être public, privé et

par l’arbre de Merkle dans un bloc. fédéré

Blockchain
▪ Un registre, un grand livre(fichier) répliqué sur
l’ensemble des utilisateurs appartenant au réseau
blockchain(nœuds)
▪ Toutes les transactions effectuées sur un réseau
sont écrites et enregistrées sur ce livre
▪ Toutes les transactions sont anonymisés, et
visibles par tous les utilisateurs du réseau
▪ Peut être vue comme une énorme base de
donnée totalement distribuée
Blockchain
▪ Une technologie transparente distribuée qui se base sur le
réseau pair à pair(P2P)
▪ Permet de faire un transfert d’argent directement entre deux
personnes
▪ Sans aucune autorité de contrôle
▪ AC est remplacée par un mécanisme de consensus
▪ Les données sont infalsifiable et non supprimables
▪ Disposant d’un haut niveau de sécurité grâce aux
mécanismes liés à la cryptographie.
Blockchain & Bitcoin

▪ Blockchain n’est pas Bitcoin, c’est une technologie utilisée par Bitcoin pour assurer des
transactions rapides et sécurisées
▪ Bitcoin est le token numérique et blockchain est le registre permettant de savoir à qui
appartiennent les tokens numériques
Vous ne pouvez pas avoir Bitcoin sans blockchain, mais vous pouvez avoir blockchain sans bitcoin
La technologie Blockchain est utilisées dans plusieurs utilisations (cryptocurrency, logistique, e-
santé, …) tandis que le Bitcoin se limite aux échanges de devises numériques.
Blockchain
≠
SYSTÈMES PARALLÈLES DISTRIBUÉS
Bitcoin
173 8
Types de blockchain
▪ Publique
• Les blocs sont visibles par tout le monde sur Internet.
• Tout le monde peut accéder au réseau public blockchain
• Tout le monde peut participer au mécanisme de consensus(vérifier,
valider et ajouter)
▪ Privée
• Ouvert à un groupe spécifique de participants, c’est un réseau fermé
• La blockchain est contrôlée par une seule organisation qui définie les
niveaux d'autorisation et d'accessibilité
▪ Hybride
• Contrôlée par une seule organisation, certaines transactions sont
distribuées au réseau publique pour la vérification
▪ Consortium
• Contrôlée par plusieurs organisations

Traceabilité
Security & Privacy
Immuabilité
Blockchain Transparence
Features
Décentralisation
Consensus mechanism

Caractéristiques de blockchain
▪ Traçabilité : au sein de la chaîne, aucune information ne peut être supprimée. Chaque nœud du
réseau dispose d’une copie intégrale du registre de la blockchain
▪ Immuabilité : signifie que la blockchain est un réseau permanent et inaltérable. Tout
enregistrement validé est irréversible et ne peut être modifié. Cela signifie qu’aucun utilisateur
du réseau ne pourra le modifier ou le supprimer.
▪ Décentralisation : Le réseau blockchain est décentralisé, ce qui signifie qu’il n’y a pas d’autorité
centrale qui sera responsable de toutes les décisions.

▪ Transparence : Tous les participants au réseau disposent d’une copie du registre pour une
transparence totale
▪ Sécurité : Tous les enregistrements de la blockchain sont cryptés individuellement. L’utilisation
du cryptage ajoute une autre couche de sécurité à l’ensemble du processus sur le réseau
blockchain.
▪ Consensus : pour prise de décision par le groupe de nœuds actifs sur le réseau afin de parvenir
à un accord rapidement et pour le bon fonctionnement du système

▪ Transparence : Tous les participants au réseau disposent d’une copie du registre pour une
transparence totale
▪ Sécurité : Tous les enregistrements de la blockchain sont cryptés individuellement. L’utilisation
du cryptage ajoute une autre couche de sécurité à l’ensemble du processus sur le réseau
blockchain.
▪ Consensus : pour prise de décision par le groupe de nœuds actifs sur le réseau afin de parvenir
à un accord rapidement et pour le bon fonctionnement du système

Composants du bloc
Chaque bloc contient :
▪ un horodatage pour déterminer le moment exact
auquel le bloc a été crée et validé par le réseau
▪ Le hash du bloc et le hash du bloc précédent
▪ Un nonce qui est un nombre aléatoire utilisé une
seule fois, dans le cas où la blockchain adopte PoW
comme algorithme de consensus.
▪ Les transactions

Transaction : arbre de merkle

▪ l’arbre de Merkle est une structure
optimisée pour calculer et vérifier un
hash de plusieurs transactions
▪ Pour calculer un arbre de Merkle on
prend le hash de chaque transaction,
puis on concatène les hashs deux par
deux

Architecture blockhain
▪ Blockchain est une chaîne de blocs contenant des informations. Les données stockées dans
un bloc dépendent du type de la blockchain
▪ Par exemple, un bloc Bitcoin contient des informations sur l'expéditeur, le destinataire, le
nombre de bitcoins à transférer.

Architecture blockhain
▪ Le premier bloc de la chaîne est appelé le bloc

Genesis. Chaque nouveau bloc de la chaîne est
lié au bloc précédent.
▪ Chaque bloc contient un hash cryptographique
et le hash du block précédent.

Architecture Blockchain
Bloc 1 Bloc 2 Bloc 3
▪ Previous hash ▪ Previous hash ▪ Previous hash
▪ Data ▪ Data ▪ Data
▪ Ttimestamp ▪ Ttimestamp ▪ Ttimestamp
▪ Hash ▪ Hash ▪ Hash
▪ Les données et les transactions sont enfermées dans des blocs horodatés
▪ Chaque bloc est identifié par un hash unique (son empreinte digitale)
▪ Les blocs sont ordonnés et fortement liés pour construire une chaine de blocs
▪ Blockchain est sécurisée par des techniques cryptographiques et des algorithmes de consensus
Sécurité de la Blockchain
▪ Distribution de la blockchain sur tous les participants du réseau(P2P)
▪ Préservation de l’anonymat : moyen d'identifier un utilisateur ou toute autre information
personnelle à partir d’une transaction
▪ Techniques cryptographique
▪ Algorithme de hachage
▪ Signature électronique
▪ Les mécanisme de consensus qui remplace l’utilisation de l’autorité centrale(décentralisation)
▪ La validation et la vérification des transaction se fait par un ensemble de
participants(mineurs, validateurs)
Algorithme de hachage
▪ Fonction mathématique permettant de Previous Data Timestamp
transformer un ensemble de donnée de départ en hash
une suite de caractères unique(le hash)

▪ Irréversible, donc impossible de trouver le
message initial à partir du hash SHA-256
▪ Garantie que les données de départ non pas été
modifié par quelqu’un
000012fa9b916eb9078f8d98
▪ Un tout petit changement dans le message a7864e697ae83ed54f5146b
d84452cdafd043c19
implique un changement important dans le hash
Sécurité de blockchain : hachage

▪ Un hash peut être compris comme une empreinte digitale unique
pour chaque bloc.
▪ Il permet d’identifie un bloc et tout son contenu, et il est toujours
unique.
▪ Ainsi, une fois qu'un bloc est créé, toute modification à l'intérieur
du bloc entraînera la modification du hash.
▪ Par conséquent, le hachage est très utile lorsque vous souhaitez
détecter les modifications apportées. Si l'empreinte digitale d'un
bloc change, il ne reste pas le même bloc.
Sécurité de blockchain : hachage
La modification d'un seul bloc peut rapidement rendre invalides tous les blocs suivants.

Signature électronique
▪ Chaque demande de transaction dans la BC doit être signée par l’émetteur pour vérifier son
intégrité et valider le bloc
▪ La signature s’appuie sur la cryptographie asymétrique, en générant une pair de clé :
▪ Une clé privée : qui ne doit pas être communiquée à personne, avec laquelle on chiffre le
hash des données à signer
▪ Une clé public : partagée avec tous les participants du réseau, permet de déchiffrer le hash
des données
▪ Ces deux clés sont liées mathématiquement, chaque message chiffré par la clé privé de l’émetteur
va être déchiffré à la réception par sa clé public correspondante
Signature électronique
Tous les nœuds participants à la blockchain disposent de deux clés : une clé privée qui leur permet de
signer numériquement leurs transactions, et une clé publique pour la vérification de la signature
Fonctionnement
▪ Pour qu’un User 1 envoie une somme d’argent à

User 2 il faut obligatoirement passer par la banque
▪ La banque vérifie que les fonds existe et que user 1
possède de montant nécessaire et valide la User 1 User 2
transaction à destination de user 2
▪ La banque dans ce cas a un rôle d’intermédiaire
(tiers de confiance)

Fonctionnement
▪ Avec la blockchain on peut effectuer des transactions de tous type sans passer par une
autorité centrale
▪ le transfert se fait via un wallet, un portefeuille qui s’achète et qui appartient à l’utilisateur
▪ À partir de ce wallet on peut soit envoyer ou recevoir des cryptomonnaies
▪ La validation de la transaction et la création des blocs se fait par des validateurs/mineurs via
le processus de vaidation/minage qui se base sur les algorithmes de consensus

Fonctionnement
▪ User 1 veut envoyer une transaction à User 2 (transfert d’argent)
User 1 User 2
▪ La transaction signée est envoyée à tous les nœuds du réseau
blockchain
▪ Ces nœuds vérifient la transaction(signature) et vérifient que user 1
possède le montant qu’il veut transférer
▪ Si la transaction est vérifiée chaque nœud travaille à créer un
nouveau bloc contenant cette transaction et vérifiant la condition de
l’algorithme de consensus utilisé
▪ Transmission du 1er bloc crée à tous les validateurs pour le valider
Fonctionnement général
La transaction signée(clé privé A) est Chaque validateur vérifie la transaction en Le premier validateur qui a réussi à créer le bloc
envoyée à tous les nœuds du réseau utilisant la clé public de A, enferme la transaction (contenant la transaction, previous hash… et
valide, dans un bloc horodaté respectant la condition de l’algorithme de consensus)
doit le transmettre aux autres nœuds
B reçoit la transaction de A Le bloc validé par la majorité est ajouté à la autres noeuds vérifient que le bloc respecte la
blockchain, transmis à tous les participants du reseau condition de AC, les transaction sont valides et
pour mettre à jours leur blockchain que le bloc fait reference au bloc precedent,

Mécanisme de consensus BC
▪ Permet au réseau BC de se mettre d’accord sur une
version unique de la chaine de bloc
▪ Se mettre d’accord sur le premier bloc à ajouter à la
BC(éviter d’avoir plusieurs blocs valides)
▪ Un processus très particulier permettant la vérification
et la validation d'un bloc pour l'ajouter à la chaine
▪ Assure le bon fonctionnement du réseau en veillant à
ce que seules les transactions légitimes soient ajoutées
au bloc(l’intégrité de la blockchain)
Preuve de travail(Proof of work)

▪ Consiste à créer des blocs en résolvant un problème cryptographique
complexe qui demande une très haute puissance de calcul (miner)
▪ Le problème cryptographique est difficile à faire mais facile à vérifier
▪ Eviter que le blocs arrivent trop vite et prouver que le mineur à dépenser de l'énergie
▪ Les participants à ce consensus sont appelés des mineurs
▪ Le mineur qui a la plus haute puissance de calcul a plus de chance
▪ Le premier mineur qui a pu résoudre le problème cryptographique va
créer le bloc, qui satisfait la règle de difficulté, et l’envoie au autres mineur
pour le valider (rare que deux mineurs réussissent en même temps)
Bitcoin PoW
▪ Bitcoin se base sur cet algorithme pour la validation
Previous hash
et la création de ces blocs
Timestamp
▪ Les mineurs de bitcoin doivent trouver une valeur
Transaction
nonce pour laquelle le hash du bloc commence par
un certain nombre de zéro Nonce
▪ Le mineur qui a pu trouver cette valeur crée le bloc Valid Hash block
et le transmet aux autres mineurs pour le valider
▪ Ce mineur reçoit un nombre déterminé de bitcoins
en récompense de son travail
Fonctionnement PoW
▪ User 1 veut transférer un nombre de bitcoin à User 2, il
transmet cette transaction(signée) à l’ensemble du réseau
▪ Les mineurs vérifient d’abord la validité de la transaction et
que User 2 possède ce nombre de bitcoin sur sont wallet
User 1 User 2
▪ Si la transaction est valide il vont commencer leurs calculs
pour trouver la valeur nonce pour créer le bloc
▪ Les mineurs vérifient que les transactions du blocs sont
valides et recalculent le hash du bloc pour s’assurer que le
mineur gagnant a trouver la valeur valide
Exemple d’équipements utilisés pour le minage
▪ Les mineurs
▪ Le premier mineur qui a pu résoudre le problème cryptographique va créer le bloc et l’envoie
au autres mineur pour le valider (rare que deux mineurs réussissent en même temps)
Avantages Inconvénient
▪ Avantages
▪ La participation au consensus est ouvert
▪ Réseau très robuste et permet de sélectionner le mineur qui a fourni plus d’effort
▪ Inconvénient
▪ Coût élevé pour l’achat des serveurs de très haute puissance de calcul et leur maintenance
▪ Consommation incroyable d'électricité en faisant fonctionner et chauffer les serveurs,
Bitcoin consomme plus d'énergie électrique par an que l'Argentine tout entière
▪ Vulnérabilité face aux attaque 51% : si un mineur arrive à contrôler 51% des puissance de
calcul (en théorie relativement possible, en réalité il y a énormément de diff mineurs )
Preuve d’enjeu(Proof of stake)

▪ Remplace le mécanisme basé sur la puissance de calcul par un autre
basé sur le verrouillage des cryptomonnaies
▪ La cryptomonnaie mise sous séquestre ‘‘verrouillée’’ est utilisée
pour garantir la sécurité du réseau
▪ On utilise le terme validateur pour désigner les nœuds participants
▪ Le validateur doit verrouiller un nb de cryptomonnaie pour participer
▪ Ce mécanisme donne l’autorité de créer des blocs au validateur
verrouillant le plus grand nombre de cryptomonnaie
▪ Le validateur possédant plus de cryptomonnaie a plus de chance
Preuve d’enjeu(Proof of stake)

▪ Chaque fois qu’on a des transaction le PoS sélectionne un validateur selon le nombre de
cryptomonnaie qu’il a mis en séquestre pour la création du nouveau bloc
▪ Les autres validateurs doivent vérifier la validité du bloc crée et des transactions qu’il contient
▪ Les validateurs reçoivent une récompense pour la création et la validation(attestation) du bloc
▪ Ce mécanisme utilise une méthode de punition appelée « Slashing », dont la cryptomonnaie
mise sous séquestre va être récupérer si le validateur ne fait pas son travail correctement
▪ Si le validateur gagnant a crée un bloc non valide il perdra ses cryptomonnaies verrouillées
▪ Les validateurs reçoivent des récompenses sur la création et la validation des blocs
▪ Pour Ethereum les validateurs doivent verrouiller 32 Ethers pour participer au processus
Avantages Inconvénient
▪ Avantages
▪ Pas besoin de matériel hyperpuissant
▪ Consommation d’énergie réduite par rapport au PoW
▪ Augmentation du nombre de transactions traitées par second(vitesse plus élevé)
▪ Inconvénient
▪ Accès plus difficile puisqu’il faut avoir des cryptomonnaies à mettre en séquestre
▪ Les validateurs ayant plus de cryptomonnaies continuent à gagner plus

Preuve d’enjeu déléguée(Proof of delgated stake)

▪ Fonctionne selon le principe de PoS en se basant sur le nombre de vote
▪ Le nœud ayant plus de vote aura l’autorité de créer un nouveau bloc
▪ les détenteurs de cryptomonnaie peuvent élire des délégués qui
validerons les transaction à leurs place
▪ Les délégués doivent donner une partie de leurs revenues à leur électeurs
▪ Si un délégué ne valide pas correctement les électeurs lui retirent leur
vote et voteront pour un autre délégué
▪ Le nombre de délégué doit être suffisamment grand pour ne pas avoir
une minorité qui prend le contrôle du consensus
Autres algorithmes de consensus

▪ Proof of Authority :
▪ Les blocs et les transactions sont validés par des nœuds approuvés à l’avance
▪ Les validateurs sont formellement identifiés et leur identité est affichée sur le réseau BC
▪ Se base sur la réputation liée à l’identité des validateurs
▪ Proof of Capacity : aussi appelé preuve d’espace ou preuve de stockage, se base sur la
capacité de stockage au lieu de la capacité de calcul pour PoW
▪ Proof of Service : ce mécanisme demande au nœuds intéressés de fournir un service défini par
le protocol

Introduction et définition Méthodologie de Parallélisme Évaluation des performances JVM parallélisme
Traitement en Série Vs Parallèle

Principe générale : Diviser-pour-régner

▪ Décomposition du large problème en plusieurs petits sous-problèmes (processus, threads,
tâches,…) qui peuvent s’exécuter simultanément
▪ Répartition des sous-problèmes sur les différents cœurs ou processeurs
▪ Chaque sous problème est découpé en une série d’instructions
▪ Possibilité de partage de la mémoire (mémoire partagée) ou échange de messages
(mémoire distribuée) au cours du traitement
▪ Combinaison des résultats des sous-problèmes afin de résoudre le problème de départ
▪ Nécessite l’utilisation d'un ensemble de processeurs capable de communiquer et de
coopérer afin d'accélérer la résolution d'un seul problème
Pourquoi le traitement parallèle
▪ Mieux adapté pour modéliser, simuler et comprendre des

phénomènes complexes du monde réel.
▪ Gagnez en temps et en ressource(Traitements
simultanés)
▪ Permet de résoudre des problèmes complexes.
▪ Utilisation de ressources non locales.
▪ Calcul haute performance(HPC)

Système HPC permet d’exécuter plusieurs taches à la fois

Machine parallèle
▪ C’est une machine équipée de p processeurs ou d’un processeur à
p cœurs
▪ Intel i9(de 10 à 18 cœurs physique et 20 à 36 cœurs logiques
▪ Intel core i7 (jusqu'à 10 cœurs physiques), i5 (jusqu'à 6 cœurs
physiques)

Classification des systèmes parallèles

▪ Classification de Flynn (1966)
▪ SISD : Pipeline pour donner l’impression d’avoir un paréllélisme
▪ SIMD : Utilise le parallélisme au niveau de la mémoire,
▪ MISD : Peu d’implementation
▪ MIMD : L’architecture parallèle la plus utililisée
▪ Classification structurelle
▪ Système à mémoire partagée (Multiprocesseurs, il faut avoir une bonne stratégie de synchronisation)
▪ Système à mémoire distribuée (Tableau de processeurs, faut avoir réseau de communic performant)
▪ Système à mémoire partagée distribuée(superordinateurs)
Classic RISC pipeline

Avec ce pipeline, 5 étapes sont nécessaires pour traiter une instruction :
• IF (Instruction Fetch) charge l'instruction à exécuter dans le pipeline.
• ID (Instruction Decode) décode l'instruction et adresse les registres.
• EX (Execute) exécute l'instruction (par la ou les unités arithmétiques et logiques).
• MEM (Memory), dénote un transfert depuis un registre vers la mémoire dans le
cas d'une instruction du type STORE (accès en écriture) et de la mémoire vers un
registre dans le cas d'un LOAD (accès en lecture).
• WB (Write Back) stocke le résultat dans un registre. La source peut être la
mémoire ou bien un registre.
Classic RISC pipeline

En supposant que chaque étape met 1 cycle d'horloge pour
s'exécuter, il faut normalement 5 cycles pour exécuter une
instruction, 15 pour 3 instructions :
▪ Séquençage des instructions dans un processeur sans
pipeline. Il faut 15 cycles pour exécuter 3 instructions.
▪ Séquençage des instructions dans un processeur doté
d'un pipeline à 5 étages. Il faut 9 cycles pour exécuter 5
instructions. À t = 5, tous les étages du pipeline sont
sollicités, et les 5 opérations ont lieu en même temps.
Classification sructutrelle

Méthodologie de Parallélisme
▪ Etape 1 : créer l’algorithme séquentiel et s’assurer que l’algo
est logique cohérent et les résultats sont corrects
▪ Etape 2 : étudier les propriétés de l’algorithme séquentiel et
analyser le code pour définir la première tache et les taches
indépendantes qui peuvent s’exécuter en parallèle
▪ Etape 3 : Choisir le grain de parallélisme en function du
système cible
▪ Etape 4 : implementer l’algorithme parallèle

Grain de Parallélisme
▪ La taille moyenne des différentes taches que nous allons exécuter en parallèle, c’est le nombre
d’opération dans une tache
▪ Souvent on mesure le grain par :
▪ Nombre d’instruction machine
▪ Taille de la mémoire employée (quantité de données traités par le grain)
▪ durée d’exécution (temps de calcul)
le choix du grain parallélisme est fortement lié à l'architécture de la machine(au matériel)

Grain de Parallélisme
▪ On parle souvent de Gros grain(coarse grain) et grain fin (fin grain)
▪ Gros grain : on met beaucoup d’instruction dans une tache, adapté au CPU
▪ Grain fin : peu d’instruction dans une tache, plus adapté au GPU
▪ plus le nombre de taches est élevé, plus le programme passe son temps à effectuer des
verrouillages et plus il passe son temps à échanger des messages entre tâches
▪ Ralentissement parallèle ce qui provoque un Overhead

Parallélisme pour une application

▪ Trouver des tâches qui peuvent s’exécuter en parallèle
a= b+1
▪ Granularité: trouver la bonne taille pour les tâches parallèles b= d+1
Processor 1
▪ Localité: les accès mémoire ou communications coûtent

plus que le calcul
c= a+2
a= b+c Processor 2
▪ Equilibrage de charge: ne pas avoir des processeurs qui ne
d= c+3
font rien
▪ Coordination et synchronisation: ne pas bloquer
inutilement

Types du Parallélisme
▪ Parallélisme de données
• lorsqu’on a plusieurs données à traiter, grand nombre de pixels dans une image (SIMD)
• Répéter une action sur un grand nombre de donnée(tableau, chèques de paye à mettre à jour)
• Répartir les données entre plusieurs processeurs pour obtenir un parallélisme des données.
▪ Parallélisme de tache
▪ Lorsqu’on a plusieurs taches à exécuter
▪ Identifier les taches indépendante(peuvent s’exécuter en parallèle)

Défis du Parallélisme
▪ Dépendance de donnée
▪ x=y+1, z=x+2 : 2ème instruction a besoin du résultat de la 1ière instruction(flow-dependency)
▪ x=y+1, y=z+2 : pas d’accès simultané à la même donnée(anti-dependency)
▪ x=y+1, x=z+1 : on peut pas effectuer une modification sur la même donnée simultanément
(output dependency)

▪ Dépendance de contrôle
1. a=b+c;
2. if(a<0)
3. {d=e+f;}
4. g=d+h;
Dans cet exemple nous avons l’instruction 1 et 4 sont indépendantes cepandant la valeur de la
variable d depend de la valeur de la variable a

▪ Dépendance de ressources
Le nombre de processeurs est insuffisant pour
effectuer des taches parallèles
▪ Temps de communication
La communication entre processeurs peut augmenter
le temps d’exécution

Accélération
▪ le gain du temps obtenu lors de la parallélisation du programme
séquentiel.
▪ 𝑇𝑠𝑒𝑞 le temps nécessaire à un programme pour résoudre le
problème A sur un ordinateur séquentiel ;
▪ 𝑇𝑝 le temps nécessaire à un programme pour résoudre le même
𝑇𝑠𝑒𝑞
problème A sur un ordinateur parallèle à 𝑝 processeurs 𝑆 =
𝑇𝑝
▪ Le programme parallèle est S fois plus rapide que le programme

séquentiel
L’efficacité
▪ L’efficacité fournit une indication sur
l’utilisation effective de tous les processeurs
𝑆
E= 𝑛𝑝
▪ E = 1 indique que A// s’exécute p fois plus

vite, cela signifie que les p processeurs font
du travail utile pendant tout le calcul
▪ L’algorithme B est plus performant que
l’algorithme A
Exercice
▪ On exécute le programme suivant sur un 1) En répartissant les boucles I sur les 4
monoprocesseur, puis sur quadriprocesseur. processeurs (4 itérations de 1 à 4 sur le premier
On suppose que le temps d’exécution du processeur, puis 5 à 8 sur le second, etc …),
programme est proportionnel au nombre quelle est l’accélération obtenue par rapport à
d’exécutions de l’itération de la boucle interne. l’exécution sur le monoprocesseur ?
2) Modifier la parallélisation pour obtenir une
For (i=1 ; i <= 16 ; i++) {
sum (i) = 0 ; exécution équilibrée (même temps d’exécution
for (j=1; j<=i ; j++) sur chaque processeur). Quelle est alors
sum(i) += T[i][j];
} l’accélération obtenue ?
Processus vs Thread
▪ un programme sous forme de code
source
▪ On le compile on a le programme
sous forme de code exécutable (objet
statique)
▪ On double clique donc il s’exécute il
est en ram c’est un processus (objet
dynamique)
▪ À l’intérieur on a le main thread qui
contient des taches à exécuter

Processus
▪ Programme en cours d’exécution
▪ un processus a un espace d'adresse protégé à lui, les
autres processus ne peuvent pas modifier l'espace
d'adressage mémoire du processus
▪ Dans le processus s’exécute au moins une tache(main
thread)
▪ La durée de vie du processus est lié à la durée de vie de
son main thread

Thread
▪ Plusieurs threads partagent le même espace mémoire
▪ il n'y a pas de protections entre les threads d'un même processus
▪ Les taches sont implémentées sous forme de threads
▪ Elle permettent à plusieurs exécutions d'avoir lieu dans le même processus
▪ Le main thread peut démarrer d'autre threads à l’intérieur du processus, et démarrer d’autre
processus
▪ Les threads sont appelés processus légers

Thread
Main Thread
▪ Lorsqu'un nouveau processus ou

Child Thread A Child Thread B
programme commence à s'exécuter, il
démarre avec un seul thread - thread
Child Thread C
principal –

Thread : Cycle de vie

Création des thread en java

Java.lang.Thread Java.lang.Thread
---------------------
+Thread() + run():void
+Thread(Runable target)
+Thread(String name)
+getName() : String
---------
+setName() : void
+currentThread()
+join():void
+run():void B
+strart(): void
+g()
+h()
▪ créer une classe fille qui hérite de la classe

A Thread
+f()
▪ une classe qui implémente l'interface Runnable
Méthode utiles
▪ start(): Demarrer le thread en appellant la méthode run()
▪ Thread.sleep(long millis) : met le thread courant en sommeil un certain nombre de
millisecondes.
▪ Join() : attend qu'un autre thread termine son exécution. Le thread entre dans un état de bloc
▪ setPriority(int i) : modifier la priorité du thread (priorité d'accès au temps CPU (1 – 10))
▪ Thread.yield() : suspend l'exécution du thread qui est en train de s'exécuter pour donner la
main à un autre
▪ isAlive() : renvoie vrai si le thread est actif ou endormi
▪ Thread.state getState() : renvoie l’état du thread
Exemple : Multiplication matricielle
Les opérations mathématiques complexe peuvent être divisées en sous-parties indépendantes.

L'exécution de ces parties en parallèle sur des processeurs distincts peut vraiment accélérer les
choses.

Langue

DC PC

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

DC PC

Titre original :

Transféré par

Droits d'auteur :

Calcul Haute Performance :

Mme. Saadia AZEMOUR, Saadia.azemour@gmail.com

SYSTÈMES PARALLÈLES DISTRIBUÉS

SYSTÈMES PARALLÈLES DISTRIBUÉS 2 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 3 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Données massives ➔ Très large mémoire

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Les avantages de HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 5 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Domaines utilisant HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 6 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Domaines utilisant HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 7 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Composants des solutions HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 8 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

Dans cet exemple nous avons un ensemble

SYSTÈMES PARALLÈLES DISTRIBUÉS 10 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 11 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

▪ Calcul à Haute performance ➔ demande des calculs parallèles

SYSTÈMES PARALLÈLES DISTRIBUÉS 12 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

▪ un supercomputer (ou supercalculateur) embarque plusieurs milliers de nœuds de

SYSTÈMES PARALLÈLES DISTRIBUÉS 13 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 14 8

Introduction Fonctionnement Notions Fondamentales Taxonomie de Flynn Architectures HPC

SYSTÈMES PARALLÈLES DISTRIBUÉS 15 8

Cycle de travail d’un ordinateur

SYSTÈMES PARALLÈLES DISTRIBUÉS 16 8

Calcul parallèle et HCP

SYSTÈMES PARALLÈLES DISTRIBUÉS 18 8

Système de classification des ordinateurs:

SYSTÈMES PARALLÈLES DISTRIBUÉS 19 8

❑ SISD: Single Instruction flow Single Data Stream

SYSTÈMES PARALLÈLES DISTRIBUÉS 22 8

prends différents élements de donnée et execute

SYSTÈMES PARALLÈLES DISTRIBUÉS 24 8

instruction différente sur le même flot

SYSTÈMES PARALLÈLES DISTRIBUÉS 25 8

SYSTÈMES PARALLÈLES DISTRIBUÉS 26 8

différentes instructions sur plusieurs

SYSTÈMES PARALLÈLES DISTRIBUÉS 28 8

Mémoire Mémoire Mémoire

SYSTÈMES PARALLÈLES DISTRIBUÉS 29 8

Architecture de la Mémoire Partagée(SMP)

▪ Nous avons une seule mémoire qui est accessible par

SYSTÈMES PARALLÈLES DISTRIBUÉS 30 8

SYSTÈMES PARALLÈLES DISTRIBUÉS 31 8

Architecture de la Mémoire Distribuée(Cluster)

Architecture de la Mémoire Distribuée(Cluster)

SYSTÈMES PARALLÈLES DISTRIBUÉS 33 8

Architecture de la Mémoire Partagée Distribuée(DSM)

SYSTÈMES PARALLÈLES DISTRIBUÉS 34 8

Architecture de la Mémoire Partagée Distribuée(DSM)

SYSTÈMES PARALLÈLES DISTRIBUÉS 35 8