chapitre ii : architectures des systèmes répartis · architectures orientées objets et services...

Systèmes Répartis

Chapitre II :

Architectures des systèmes répartis Amine DHRAIEF

1ère année Master Pro Data Science

Systèmes Répartis 2

Introduction● Les systèmes distribués :

– des logiciels complexes – dont les composants sont par définition dispersés sur plusieurs machines.

→ Pour maîtriser leur complexité, il est essentiel que ces systèmes soient correctement organisés et structurés.

● Une structuration évidente → distinguer entre l’architecture logicielle et matérielle– Architecture matérielle : le réseau, la topologie, les technologies,… – Architecture logicielle : comment les différents composants logiciels

doivent être organisés et comment ils doivent interagir.


Introduction

● Les systèmes distribués utilisent une couche middelware (intergiciel) pour séparer les applications des plates-formes physiques sous-jacentes– l’objectif de la couche middelware est d’assurer

un accès transparent aux ressources (comme si les ressources étaient locales)

OS

Applications

OS

Applications

Middelware


Introduction● Les systèmes réparties peuvent avoir différentes

architectures, dites architectures réparties.

● Deux familles d’architectures réparties :– Centralisés → Client /Serveur, 2-tiers, 3-tiers, …, n-tiers

● Une machine serveur implémente la quasi-totalité des composants logicielles et des fonctionnalités

– Distribuées → P2P ● Les machines ont des rôles équivalents.


Styles Architecturaux


Architecture Logicielle & Style Architectural ?

● Architecture logicielle : l’organisation logique d’une système distribué en composants logiciels.

● Style Architectural : formulé en termes de composants :– comment les composants sont connectés les uns aux

autres ? – les données échangées entre les composants .– et finalement comment ces éléments sont conjointement

configurés dans un système ?


Un composant ?

● Un composant = un élément constitutif d’un logiciel → une pièce détachée

● Un composant : une unité modulaire + dotée d'interfaces + remplaçable dans son environnement.


Changement à chaud d’un composant

● Il est important de pouvoir remplacer un composant et, en particulier, pendant qu’un système continue à fonctionner. – Il n'est pas possible/envisageable d'arrêter un

système pour la maintenance. – Au mieux, seules certaines parties peuvent être

temporairement hors service. – Le remplacement d'un composant ne peut être

effectué que si ses interfaces restent intactes.


Connecteur ?

● un connecteur : un mécanisme qui assure la communication, la coordination ou la coopération entre les composants– C’est par les connecteurs que passent les flux de

contrôle & les flux de données entre les composants,


Connecteurs + Composants = Style Architectural

● En combinants les composants et les connecteurs, on obtient différentes configurations, qui à leur tour, sont classés en styles architecturaux :

– Architectures en couches– Architectures basées sur des objets– Architectures centrées sur les ressources– Architectures basées sur des événements


Styles ArchitecturauxArchitectures en couches


Architecture en Couches

● Les composants sont organisés en couches

● Un composant à la couche Lj envoie une requête à un composant situé à une couche inférieure Li (avec i <j) et attend généralement une réponse. – Dans des cas exceptionnels, un appel est effectué par

un composant de niveau inférieur à un autre situé à un niveau supérieur.


Architecture en Couches

● (a) architecture en couche ‘pure’ (b) architecture en couche ‘cross layer’ (c) architecture en couche avec des appels ascendants


Architecture en CouchesArchitecture ‘pure’

● Uniquement des appels descendants à la couche strictement inférieure.

● Modèle utilisé dans les piles protocolaires (TCP/IP, OSI,…)


Architecture en CouchesArchitecture ‘cross-layer’

● Cas fréquent dû aux contraintes de l’implémentation :– Par exemple, une application A qui utilise

une bibliothèque LOS pour l'interface avec un système d'exploitation.

– Dans le même temps, l'application utilise une bibliothèque mathématique spécialisée Lmath qui a été implémentée en utilisant LOS.

– Dans ce cas :● A est implémenté à couche N- 1,● Lmath au niveau de la couche N-2 et ● LOS qui leur est commune, à la couche N - 3.


Architecture en CouchesArchitecture avec des appels ascendants

● Dans certains cas, une couche inférieure a besoin de faire un appel vers sa couche supérieure à travers une interface de la couche supérieure.


Applications distribuées & architecture en couches

● Une large classe d’applications distribuées permet l’accès à une base de donnée à une application ou un utilisateur .

● On a préconisé une distinction entre trois niveaux logiques, ou couches :– Le niveau interface (interaction avec un utilisateur ou

une application)– Le niveau traitement (les fonctionnalités)– Le niveau data


Applications distribuées & architecture en couches

● Exemple : moteur de recherche


Styles ArchitecturauxArchitectures orientées objets et services


Architectures orientées objets et services

● Chaque objet correspond à un composant.– Les composants sont

connectés via un mécanisme d'appel de procédure.

● Dans le cas de systèmes distribués, un appel de procédure peut également être distant (via un réseau)– c'est-à-dire que l'objet appelant

n'a pas besoin d'être exécuté sur la même machine que l'objet appelé.



● Les architectures basées sur les objets permettent d'encapsuler (i) les données (état d'un objet (state)) (ii) et les opérations qui peuvent être effectué sur ces données (appelées méthodes de l’objet) dans une seule entité.

● L'interface offerte par un objet cache les détails d'implémentation, ce qui signifie essentiellement que nous pouvons, en principe, considérer un objet totalement indépendant de son environnement.



● Comme pour les composants, cela signifie également que si l'interface est clairement définie et laissée intacte, un objet doit pouvoir être remplacé par un autre ayant exactement la même interface.

● Cette séparation entre les interfaces et les objets implémentant ces interfaces nous permet de placer une interface sur une machine, alors que l'objet lui-même réside sur une autre machine.

● Cette architecture est généralement appelée objet distribué.


Architectures orientées objets et servicesun stub ?

● Un stub est un portion du code qui convertit les paramètres passés entre le client et le serveur lors d'un appel de procédure à distance (RPC).– L'idée principale d'un RPC est de permettre à un ordinateur local (client)

d'appeler à distance des procédures sur un autre ordinateur (serveur).

● Le client et le serveur utilisent des espaces d'adressage différents, de sorte que les paramètres utilisés dans un appel de fonction (procédure) doivent être convertis (marshelling), sinon les valeurs de ces paramètres ne peuvent pas être utilisées.

● Le client et le serveur peuvent également utiliser différentes représentations de données– par exemple, big-endian vs little-endian.


Architectures orientées objets et servicesun stub ?

● Les bibliothèques de stub doivent être installées du côté client et du côté serveur.

● Un stub client est responsable de la conversion (marshalling) des paramètres utilisés dans un appel de fonction et de la déconversion (unmarshalling) des résultats transmis par le serveur après exécution de la fonction.

● Un skeleton de serveur, le stub côté serveur, est responsable de la dé-conversion (unmarshalling) des paramètres transmis par le client et de la conversion (marshalling) des résultats après l'exécution de la fonction.



● Les architectures basées sur les objets sont à la base de l’encapsulation des services dans des unités indépendantes.

● Le service dans son ensemble est réalisé comme une entité autonome, bien que le service peut éventuellement utiliser d'autres services.

● En séparant clairement les différents services de telle sorte qu'ils peuvent opérer de manière indépendante, nous obtenons une architectures orientées services, généralement abrégées en SoA.



● Dans une architecture orientée services (SoA), une application ou un système distribué est essentiellement construit comme une composition de nombreux services différents.– Tous ces services ne peuvent pas appartenir à la

même organisation administrative.



● Le problème du développement d’un système distribué est en partie un problème de composition des services et faire en sorte ces services fonctionnent en harmonie.


Styles ArchitecturauxArchitectures centrées sur les ressources


Architectures centrées sur les ressourcesRESTful

● Avec l'augmentation du nombre de services disponibles sur le Web et le développement de systèmes distribués via la composition des services, les chercheurs ont commencé à repenser l'architecture de systèmes distribués principalement basés sur le Web.

● L'un des problèmes de la composition des services est que la connexion de divers composants peut facilement se transformer en un cauchemar d'intégration.



● Comme alternative, on peut également voir un système distribué comme une énorme collection de ressources gérées individuellement par les composants.

● Des ressources peuvent être ajoutées ou supprimées par des applications (distantes) et peuvent également être récupérées ou modifiées.

● Cette approche a été largement adoptée pour le Web et est connue sous le nom de Representational State Transfer (REST).



● Il existe quatre caractéristiques principales de ce que l'on appelle les architectures RESTful :

1) Les ressources sont identifiées par un schéma de nommage unique

2) Tous les services offrent la même interface, comprenant au maximum quatre opérations (les verbes HTTP: PUT, GET, DELETE, POST)

3) Les messages envoyés depuis/à un service sont contiennent suffisamment d’information pour décrire comment traiter le message.

4)Après avoir exécuté une opération sur un service, ce composant oublie tout chose à propos de l'appelant (stateless execution)


Architectures centrées sur les ressourcesRESTful. Exemple Amazon S3

● Amazon S3 : Amazon Simple Storage Service– Propose des services de stockage à travers des services Web

● Prend en charge uniquement deux ressources: – Les objets, qui sont essentiellement l'équivalent des fichiers, – et les buckets, l'équivalent des répertoires. – Il n'y a pas de concept de placement de buckets dans des buckets.

● Un objet nommé ObjectName contenu dans BucketName est référencé à l'aide de l'URI (Uniform Resource Identifier) suivant:

http://BucketName.s3.amazonaws.com/ObjectName


Architectures centrées sur les ressourcesRESTful. Exemple Amazon S3

● Pour créer un bucket ou un objet, une application envoie une demande PUT avec l'URI du bucket/objet. – Il s'agit simplement d'une autre requête HTTP, qui sera

ensuite correctement interprétée par S3. – Si le bucket ou l'objet existe déjà, un message d'erreur

HTTP est renvoyé.

● De manière similaire, pour savoir quels objets sont contenus dans un bucket, une application envoie une requête GET avec l'URI de ce bucket. – S3 renverra une liste de noms d'objet, toujours sous la

forme d'une réponse HTTP ordinaire.


Architectures centrées sur les ressourcesRESTful.

● Un service ne peut pas être rendu plus facile ou plus difficile à cause de la interface particulière qu'il offre. – Un service offre des fonctionnalités, et au mieux la manière

d'accès au service est déterminé par l'interface.

● Amazon S3, qui offre un Interface REST et une interface plus traditionnelle (appelée SOAP interface). On va comparer en détail les deux interfaces.


Architectures centrées sur les ressourcesRESTful.

● L'interface Amazon S3 SOAP comprend 16 opérations.

● Par contre, l’interface REST offre très peu d'opérations (PUT,GET,DELETE,POST)


Styles ArchitecturauxArchitectures basées sur les événements


Architecture Publish-Subscribe ● Dans les systèmes distribués les processus doivent

rejoindre ou quitter le système le plus facilement possible– Il est important d'avoir une architecture dans laquelle les

dépendances entre les processus deviennent le moins couplées que possible.

● Une classe de systèmes distribués a une architecture dans laquelle il existe une forte séparation entre traitement et coordination. – L’idée est de voir un système comme une collection de processus

de fonctionnement autonome. – Dans ce modèle, la coordination englobe la communication et la

coopération entre les processus.


Architecture Publish-Subscribe

● Une classification possible des différents types de coordinations entre processus selon les axes temporels et référentiels :


Architecture Publish-Subscribecouplage temporel – couplage référentiel ● Le couplage référentiel apparaît généralement sous

la forme d'un référencement explicite en communication. Par exemple, un processus ne peut communiquer que s'il connaît le nom ou identifiant des autres processus avec lesquels il souhaite échanger des informations.

● Le couplage temporel signifie que les processus qui communiquent doivent être dans l’état running


Architecture Publish-Subscribemailbox coordination

● Les processus sont découplés temporellement, mais ayant un couplage référentielle, ce que nous appelons la coordination des boîtes aux lettres (mailbox coordination).

● Dans ce cas, il n'est pas nécessaire que deux processus qui communiquent s'exécutent en même temps pour permettre la communication.

● La communication a lieu en mettant des messages dans une boîte aux lettres (éventuellement partagée).

● Comme il est nécessaire d'adresser explicitement la boîte aux lettres qui contiendra les messages à échanger, il existe un couplage référentiel.



● La combinaison de systèmes découplés par référence et couplés temporellement constitue le groupe de modèles de coordination basée sur les événements.

● Dans les systèmes découplés de manière référentielle, les processus ne se connaissent pas explicitement.

● La seule chose qu'un processus puisse faire est de publier une notification décrivant l'occurrence d'un événement (par exemple, qu'il souhaite coordonner des activités ou qu'il n'a produit que des résultats intéressants).



● En supposant que les notifications soient de toutes sorte, les processus peuvent souscrire à un type spécifique de notification.

● Dans un modèle de coordination basé sur les événements, une notification publiée sera livrée exactement aux processus qui y sont abonnés.

● Cependant, il est nécessaire que l'abonné soit opérationnel au moment de la publication de la notification.


Architecture Publish-Subscribe● Un modèle de coordination bien connu est la combinaison de

processus découplés de manière référentielle et temporelle, conduisant à ce que l'on appelle un espace de données partagé (shared data space).

● L'idée principale est que les processus communiquent entièrement via des tuples, qui sont des enregistrements de données structurés constitués d'un certain nombre de champs, très similaires à une ligne dans une table de base de données.

● Les processus placent des tuples dans l'espace de données partagé. – Afin de récupérer un tuple, un processus fournit un motif de recherche

correspondant aux tuples. – Tout tuple correspondant est retourné.



● Les espaces de données partagés sont souvent associés à une coordination basée sur les événements: – un processus s'abonne à certains tuples en fournissant un

modèle de recherche; – lorsqu'un processus insère un tuple dans l'espace de

données, les abonnés correspondants sont notifiés.

● Il s’agit d’une architecture de type publish-subscribe– sa caractéristique principale est que les processus ne font

aucune référence explicite les uns aux autres.



Event-based Shared-data space


Les architectures des système distribuées

15/10/2018 Systèmes Répartis 49


Architectures

Centralisées : client-serveur

Distribuées : P2P



Architectures centralisées


Les architectures centralisésclient-serveur

● Les processus sont divisés en deux groupes (éventuellement superposés) :– Un serveur est un processus

implémentant un service spécifique, par exemple un service de système de fichiers ou un service de base de données.

– Un client est un processus qui demande un service à un serveur en lui envoyant une demande et en attendant la réponse du serveur.



● La communication entre un client et un serveur peut être mise en œuvre au moyen d'un protocole simple sans connexion lorsque le réseau sous-jacent est assez fiable, comme dans de nombreux réseaux locaux.

● Dans ces cas, lorsqu'un client demande un service, il crée simplement un message pour le serveur, identifiant le service qu'il souhaite, ainsi que les données d'entrée nécessaires. Le message est ensuite envoyé au serveur.

● Le serveur attends une demande entrante, la traite et regroupe les résultats dans un message de réponse qui sera ensuite envoyé au client.



● L'utilisation d'un protocole sans connexion présente l'avantage évident d'être efficace.– Tant que les messages ne sont pas perdus ou corrompus, le protocole

de requête / réponse fonctionne correctement.

● Malheureusement, rendre le protocole résistant aux défaillances de transmission occasionnelles n’est pas anodin. – La seule chose que nous puissions faire est de laisser le client

renvoyer la requête quand aucun message de réponse n’intervient. – Le problème, cependant, est que le client ne peut pas détecter si le

message de la requête initiale a été perdu ou que la transmission de la réponse a échoué.



● Si la réponse a été perdue, le renvoi d'une demande peut entraîner l'exécution de l'opération deux fois. – Si l'opération consistait en quelque chose comme «transférer X Dinars de

mon compte bancaire», il aurait été préférable de signaler une erreur à la place.

– En revanche, si l’opération était «dites-moi combien d’argent me reste», il serait parfaitement acceptable de renvoyer la demande.

● Lorsqu'une opération peut être répétée plusieurs fois sans dommage, on dit qu'elle est idempotente. – Étant donné que certaines demandes sont idempotentes et que d'autres

ne le sont pas, il devrait être clair qu'il n'existe pas de solution unique pour traiter les messages perdus.



● Comme alternative, de nombreux systèmes client-serveur utilisent un protocole fiable orienté connexion. – Bien que cette solution ne soit pas tout à fait appropriée dans un réseau local

en raison des performances relativement faibles, elle fonctionne parfaitement dans les systèmes étendus dans lesquels la communication est intrinsèquement peu fiable.

– Par exemple, pratiquement tous les protocoles d'application Internet sont basés sur des connexions TCP / IP fiables. Dans ce cas, chaque fois qu'un client demande un service, il établit d'abord une connexion au serveur avant d'envoyer la demande.

– Le serveur utilise généralement cette même connexion pour envoyer le message de réponse, après quoi la connexion est terminée.

– Le problème peut être que les procédures d’ouverture et de fermeture d’une connexion sont relativement coûteuses, en particulier lorsque les messages de demande et de réponse ont de tailles minimes.



● Le modèle client-serveur a fait l’objet de nombreux débats et controverses au fil des ans.

● L'un des principaux problèmes était de savoir comment distinguer clairement un client et un serveur. – Sans surprise, il n'y a souvent pas de distinction claire. – Par exemple, un serveur pour une base de données distribuée peut

continuellement agir en tant que client, car il transfère les demandes vers différents serveurs de fichiers chargés d’implémenter les tables de base de données.

– Dans ce cas, le serveur de base de données ne traite que les requêtes.


Architectures à plusieurs niveaux● La distinction en trois niveaux logiques, discutés ‘(interface,

traitement, données) suggère un nombre des possibilités de distribution physique d'une application client-serveur à travers plusieurs machines.

● L’organisation la plus simple est de n'avoir que deux types de Machines:– Une machine cliente contenant uniquement les programmes

implémentant (en partie) le niveau de l'interface utilisateur– Une machine serveur contenant le reste, c’est-à-dire les

programmes implémentant le traitement et les données


Architectures à plusieurs niveaux

● Dans cette organisation, tout est géré par le serveur alors que le client n’est qu’un simple terminal, éventuellement avec une interface graphique.

● L'une des méthodes d'organisation des clients et des serveurs consiste à distribuer les couches interfaces, traitements, données, sur différentes machines.


Architectures à plusieurs niveauxArchitecture deux-tiers

● Dans un premier temps, nous ne distinguons que deux types de machines:– machines client et machines serveur, conduisant à

ce que l'on appelle aussi architecture deux-tiers (physique)



● N'avoir que la partie dépendante du terminal de l'interface utilisateur sur la machine client

● Donner aux applications le contrôle à distance sur la présentation de leurs données



● Une alternative consiste à placer l’ensemble du logiciel d’interface utilisateur du côté client.

● Dans de tels cas, nous divisons essentiellement l'application en une interface graphique, qui communique avec le reste de l'application (résidant sur le serveur) via un protocole spécifique à l'application.

● Dans ce modèle, le frontend (le logiciel client) ne fait aucun autre traitement que nécessaire pour présenter l’interface de l’application.



● Nous pouvons également déplacer une partie de l’application vers l’avant. – Un exemple où cela a du sens est celui où

l'application utilise un formulaire qui doit être entièrement rempli avant de pouvoir être traité.

– Le frontend peut alors vérifier l'exactitude et la cohérence du formulaire et, le cas échéant, interagir avec l'utilisateur.

– Un autre exemple d'organisation est celui d'un traitement de texte dans lequel les fonctions d'édition de base s'exécutent du côté client où elles opèrent sur des données mises en cache localement ou en mémoire, mais où les outils de support avancés tels que vérifier 'orthographe et la grammaire du côté serveur.



● Le client est un PC ou un poste de travail, connecté via un réseau à un système de fichiers ou à une base de données distribués.– Essentiellement, la majeure partie de

l'application s'exécute sur l'ordinateur client, mais toutes les opérations sur les fichiers ou les entrées de base de données vont au serveur.

– Par exemple, de nombreuses applications bancaires s'exécutent sur la machine d'un utilisateur final où l'utilisateur prépare des transactions, etc. Une fois terminé, l’application contacte la base de données sur le serveur de la banque et télécharge les transactions pour un traitement ultérieur.



● La figure représente la situation où le disque local du client contient une partie des données. – Par exemple, lors de la

navigation sur le Web, un client peut progressivement créer un énorme cache sur le disque local des pages Web les plus récemment inspectées.


Architectures à plusieurs niveauxArchitecture trois-tiers

● En ne distinguant que les machines client et serveur comme nous l’avions fait jusqu’à présent, il n’est pas évident qu’un serveur doit parfois agir en tant que client, ce qui conduit à une architecture à trois niveaux (physique).



● Dans cette architecture, traditionnellement, les programmes faisant partie de la couche de traitement sont exécutés par un serveur distinct, mais peuvent en outre être partiellement répartis sur les machines client et serveur.– Un exemple typique d'une architecture à trois niveaux

est le traitement des transactions. – Un processus distinct, appelé moniteur de traitement

des transactions, coordonne toutes les transactions sur des serveurs de données éventuellement différents.



● Un autre exemple, mais très différent, est que nous voyons souvent une architecture à trois niveaux dans l’organisation des sites Web. – Dans ce cas, un serveur Web agit en tant que point d’entrée sur un site,

transmettant les demandes à un serveur d’application où le traitement proprement dit a lieu.

– Ce serveur d’application interagit à son tour avec un serveur de base de données.

– Par exemple, un serveur d'applications peut être responsable de l'exécution du code pour inspecter l'inventaire disponible de certaines marchandises proposé par une librairie électronique.

– Pour ce faire, il peut être nécessaire d'interagir avec une base de données contenant les données d'inventaire brutes.



Architectures distribuées


Les architectures distribuées Les systèmes Peer-to-Peer

● Les architectures client-serveur à plusieurs niveaux sont une conséquence directe de la division des applications distribuées en une interface utilisateur, des composants de traitement et des composants de gestion des données. – Les différents niveaux correspondent directement à

l'organisation logique des applications.

● Dans de nombreux environnements d'entreprise, le traitement distribué équivaut à organiser une application client-serveur en tant qu'architecture à plusieurs niveaux. – Nous appelons ce type de distribution la distribution verticale. – La caractéristique de la distribution verticale est qu’elle est

obtenue en plaçant des composants logiquement différents sur des machines différentes.



● Du point de vue de la gestion des systèmes, une distribution verticale peut aider: – Les fonctions sont logiquement et physiquement

réparties sur plusieurs machines, chaque machine étant adaptée à un groupe de fonctions spécifique.

– Cependant, la distribution verticale n'est qu'un moyen d'organiser les applications client-serveur.

● Dans les architectures modernes, c'est souvent la distribution des clients et des serveurs qui compte, que nous appelons la distribution horizontale.



● Dans la distribution horizontale, un client ou un serveur peut être physiquement divisé en parties logiquement équivalentes, mais chaque partie fonctionne sur son propre partage du jeu de données complet, équilibrant ainsi la charge.

● Les systèmes peer-to-peer est une classe d’architectures de systèmes modernes prenant en charge la distribution horizontale.



● Dans une perspective de haut niveau, les processus qui constituent un système P2P sont tous égaux.

● Cela signifie que les fonctions à exécuter sont représentées par chaque processus constituant le système distribué.

● En conséquence, une grande partie de l'interaction entre les processus est symétrique: chaque processus agira en tant que client et serveur en même temps (ce qui est également appelé agir en tant que servant).


The End !

chapitre ii : architectures des systèmes répartis · architectures orientées objets et services...

Documents