Un Système Réparti
ou Système Distribué
ou Architecture Répartie
est défini comme étant une classe de systèmes informatiques comportant plusieurs éléments pouvant fonctionner de manière autonome et reliés par un système de communication qui leur permet d'échanger de l'information en vue de coopérer à une tache commune ou d'accéder à des services communs.
Le médium de communication peut aussi bien être un réseau physique de lignes de communication de processeur à processeur qu'un bus dans une machine.
Le rôle d'un S.R. est d'assurer la communication et le partage d'informations entre des applications.
Un Système Réparti correspond aux classes MISD (bien que cette architecture soit assez rare) et MIMD. Il n'y a pas de grandes différences au niveau de la problématique entre les machines parallèles et les Systèmes Répartis.
Architectures multi-processeurs dans lesquelles la mémoire est partagée
Architectures multi-processeurs dans laquelle la mémoire n'est plus partagée. Les processeurs se retrouvent en réseau. La communication entre processeurs s'effectue donc uniquement par messages. De plus, les mémoires sont privées et ne sont accessibles que par le processeur local.
Différentes topologies sont utilisées au niveau réseau : bus, étoile, arborescence ou graphes complets.
En général, lorsqu'on parle de S.R., il s'agit de systèmes faiblement couplés avec une topologie prédéfinie au niveau du réseau. Une des caractéristiques du S.R. est l'absence d'état global perceptible à un instant donné par un observateur. Un processus ne connait que les messages qui lui ont été envoyés, ou qui sont passés par lui. Il ne connait pas l'état du réseau, c'est à dire ce qui circule à l'instant T. Pour cette raison, deux machines peuvent avoir une perception différentes de la même série d'évennements.
Exemple :On considère un S.R. servant à gérer des locations de costumes. 3 messages M1 à M3 signaleront un changement du stock :
On considère que le stock initial comporte 100 costumes. 4 machines (1) à (4) du S.R. reçoivent ces 3 messages dans un ordre différents. Leur vision du stock sera la suivante :
| (1) | (2) | (3) | (4) | ||||
|---|---|---|---|---|---|---|---|
| Message | Stock | Message | Stock | Message | Stock | Message | Stock |
| 100 | 100 | 100 | 100 | ||||
| M1 | 120 | M1 | 120 | M3 | 90 | M2 | 90 |
| M2 | 110 | M3 | 108 | M1 | 110 | M3 | 81 |
| M3 | 99 | M2 | 98 | M2 | 100 | M1 | 101 |
Ceci montre le besoin de synchroniser les entités d'applications. Ceci s'avère délicat pour la simple raison que toute l'architecture repose sur les réseaux.
Les modèles sont représentés avec les conventions suivantes :
On est ici dans un mode d'exécution asynchrone dans lequel l'emetteur cède le contrôle des informations à 1 récepteur tout en continuant sa propre exécution. On a donc exécution en parallèle de 2 processus. Ceci pose un problème car l'emetteur n'a pas de compte rendu de fin de traitement de l'information par le récepteur.
E ======*====
/
/
R ===o=======
Les applications sont vues comme un ensemble de procédures. Une entité d'apllication peut donc faire appel à une procédure qui s'exécute soit dans le même contexte que l'entité appelante, soit dans une entité qui se trouve sur la même machine, soit dans une entité qui se trouve sur une autre machine. On a un mode d'exécution synchrone, l'appelant restant bloqué pendant le déroulement de la procédure par l'entité chargée de son exécution. On n'a donc pas de parallélisme.
C ===o---------+====
\ /
\ /
S ------*===o-------
Le S.R. est vu comme un ensemble d'objets. Un objet propose des méthodes qui peuvent être appelées par d'autres objets. Ces objets peuvent être transparents pour l'utilisateur. Ce modèle peut être considéré comme une extension du modèle client/serveur. Le mode d'exécution est également synchrone.
Une application est vue comme un ensemble d'entités structurées en groupes. Le mode de communication entre entités d'une même application est alors la communication de groupe ou diffusion vers des groupes. Un message destiné à un groupe est reçu par chacune des entités du groupe. On peut avoir deux modes d'exécution :
Asynchrone : L'emetteur transmet le message à diffuser et poursuit son traitement. On utilise des FIFO au niveau des récepteurs pour stocker les messages jusqu'au moment de leur traitement. Chaque récepteur attend au moment souhaité un message diffusé, le traite, puis continue ensuite son exécution. On a ici un risque de non-reception d'un message par un récepteur.
E ===o==============
\
\
R1 ======x===+=======
\
\
R2 =========*========
\
\
R3 ========----*=====
Synchrone : Le demandeur émet un message à tous les accepteurs, et reste bloqué pendant le déroulement d'une procédure sur chacun de ces accepteurs. Il reprend son exécution lorsque chaque accepteur a retourné sa réponse. Un problème se pose, puisqu'on risque une attente infinie si un seul des accepteurs tombe en panne.
E ===o---------*-----*-----*====
\ / / /
\ / / /
R1 ------*===o-------------------
\ / /
\ / /
R2 ---------*===o----------------
\ /
\ /
R3 ------------*===o-------------
Un S.R. est un ensemble de composants matériels reliés par un réseau d'interconnexion fonctionnant de manière autonome pour réaliser une tâche commune. En raison de ces propriétés, la construction de systèmes et applications répartis pose des problèmes nouveaux pour lesquels des méthodes et outils spécifiques ont été développés :
 |
 |