Introduction aux systèmes distribués

Plan Naissance des systèmes distribués Avantages et inconvénients des systèmes distribués Architecture matérielle Conception de logiciel pour les systèmes distribués Applications

Naissance des systèmes distribués Jusqu’en 1985 époque des grands calculateurs centralisés très coûteux Début des années 80 Avènement des micro-ordinateurs Micro-processeurs puissants produits en quantité (faible coût) Réseaux locaux (LAN) Interconnexion d’un grand nombre de machines Il devient facile d’interconnecter des ordinateurs Système distribué Quel logiciel pour les systèmes distribués ? Ethernet : réseau à diffusion Token Ring : réseau en anneau

Avantages des systèmes distribués Par rapport aux systèmes centralisés économique excellent rapport performance/prix des microprocesseurs puissance de calcul un système multi-processeur offre une puissance de calcul supérieure à celle d ’un seul processeur : on peut tjrs augmenter la puissance de calcul en augmentant le nombre de processeurs distribution naturelle de certaines applications distribution géographique d ’agences bancaires haute disponibilité la défaillance d ’une machine n’affecte pas les autres Loi de Grosch : La puissance de calcul d’un processeur est proportionnelle au carré de son prix. Application : en payant le double, on quadruple la performance. Cette loi n’est plus valable pour les micro-processeurs. Pour quelques dollars, on a un microprocesseur qui exécute plus d’instructions à la seconde que le plus gros des mainframe des années 80.

Avantages des systèmes distribués Par rapport à des postes de travail indépendants partage de données entre les utilisateurs exemple : système de réservation aérienne partage de périphériques coûteux exemple : imprimante, périphériques d’archivage facilitation des communications entre personnes courrier électronique flexibilité (distribution de la charge) . permet d’exécuter un travail sur la machine la plus disponible

Inconvénients des systèmes distribués Logiciel relativement peu d’expérience de conception, mise en œuvre et utilisation de logiciels distribués Réseau de communication saturation perte de messages Sécurité facilité de partage de données rend nécessaire la protection des données confidentielles

Architecture matérielle Système distribué ensemble de processeurs interconnectés Différentes architectures selon le médium de communication la façon dont les processeurs communiquent

Architecture matérielle Système distribué = architecture MIMD dans la classification de Flynn’s Ordinateurs parallèles ou distribués (MIMD) Architectures faiblement couplées Architectures fortement couplées Multiprocesseurs (mémoire partagée) Multicomputers (mémoire privée) Bus Réseau Bus Réseau Réseau local Hypercube

Multiprocesseur à mémoire partagée fondé sur un bus Caches Processeurs Mémoire partagée P1 P2 P3 P4 Description: mémoire centrale unique, bus typique 32 lignes d’adresse, 32 lignes de données et 20 ou 30 lignes de contrôle. Quand un processeur veut lire une donnée en mémoire, il met l’adresse sur le bus. La mémoire répond en mettant la donnée sur le bus. En l’absence de caches, le système est cohérent car il n’y a qu’une seule mémoire. Le problème est qu’il y a de la contention sur le bus à partir de 4 ou 5 processeurs. Cache entre le processeur et le bus. Tous les accès processeur à la mémoire passent par le bus. Problème de cohérence de la mémoire : cache à écriture immédiate ou à écriture retardée. Snoopy caches : les caches observent les transactions sur le bus.

Multicomputer fondé sur un bus Réseau local de stations de travail Bus (LAN) Mémoire locale Chaque processeur a une connexion directe à sa mémoire locale. Le réseau sert à la communication entre les processeurs (pas pour le trafic processeur mémoire). Processeur

Terminologie Système parallèle Système distribué Système distribué utilisé pour l’exécution d’une application gourmande en calcul et/ou mémoire Multiprocesseurs à mémoire partagée Système distribué Système distribué dans une utilisation pour de plusieurs tâches indépendantes Réseaux de stations de travail La frontière n’est pas très nette …

Système distribué à grande échelle Fondé sur un réseau longue distance E Internet A D B Site C Passerelle (routeur) Réseau physique

Système d’exploitation pour système distribué Système intégré Vision d’une machine unique (Single System Image) Machine uni-processeur virtuelle La multiplicité des ressources et leur distribution doivent être transparentes pour l’utilisateur Un même système d’exploitation s’exécute sur chaque machine Chaque machine possède sa copie locale du système d’exploitation Communication par messages

Système à image unique (Single System Image) Architecture matérielle Ensemble de ressources physiques (mémoire, disque, processeur) distribuées sur différents nœuds Transparence Partage Extensibilité Haute disponibilité

Transparence Transparence à l’emplacement : les utilisateurs ne peuvent pas dire où sont situées les ressources. Transparence à la migration : les ressources peuvent être déplacées sans modification de leurs noms. Transparence à la duplication ( replication ) : les utilisateurs ne connaissent pas le nombre de copies existantes. Transparence à la concurrence : plusieurs utilisateurs peuvent partager automatiquement des ressources. Transparence au parallélisme : des tâches peuvent s’exécuter en parallèle sans que l’utilisateurs le sachent.

Extensibilité Extensibilité des performances L’augmentation des ressources physiques conduit à une augmentation des performances globales du système Décentralisation Aucun nœud ne connaît l’état global du système Chaque nœud doit prendre des décisions en fonction des informations disponibles localement La défaillance d’un nœud ne doit pas empêcher le bon fonctionnement du système Il n’existe pas d’horloge globale dans le système

Extensibilité Transparence à l’extensibilité Ajout de nouveaux nœuds Retrait (prévu) de nœuds Intégration ou suppression de ressources sans arrêt du système et sans perturbation pour les applications en cours d’exécution

Haute disponibilité Défaillance d’un nœud n’entraîne pas l’indisponibilité du système sur les autres nœuds. Seules les applications utilisant les ressources physiques du nœud défaillant peuvent être perturbées. La réplication : on général plus on fait de copies, plus on augmente la fiabilité. La tolérance aux pannes

Applications Applications scientifiques Applications coopératives Calcul parallèle Besoin de puissance de calcul et de mémoire Minimisation du temps de réponse Partage de mémoire sur une architecture à mémoire distribuée (mémoire virtuellement partagée) Applications coopératives Système de réservation de places d’avion Système de gestion d’agences bancaires

Network File System de Sun (NFS) Une autre solution que les systèmes exploitation réseaux ( rlogin, ftp, rcp …) NFS = système de fichiers distribué. Idée de base = pouvoir partager entre plusieurs clients et serveurs hétérogènes un même système de fichiers. Une machine peut être à la fois client et serveur. Un serveur NFS exporte ses directories pour qu'elles soient accessibles par des clients. Si une directory est exportée, c'est tout le sous-arbre qui est exporté. Liste des directories exportées dans /etc/exports.

NFS : Architecture Un client qui veut accéder à une directory distante doit la monter dans sa propre hiérarchie. Une station cliente sans disque (diskless) peut faire "comme si" elle avait un disque en montant des systèmes distants. Une station avec un disque local aura une hiérarchie en partie locale et distante. Pour les programmes du client  pas de différence entre fichiers locaux ou distants. Si deux clients ont monté la même directory, ils en partagent les fichiers. Systèmes d’exploitation locaux peuvent être !=.  simplicité de NFS.

1er protocole : Protocole de montage NFS : Protocoles 1er protocole : Protocole de montage Le client envoie une requête contenant le chemin d’accès à un répertoire du serveur et une demande de l’autorisation de le monter dans son arborescence Si le chemin est correct et le répertoire est exportable, le serveur renvoie au client une clé de fichier (file handle) concernant ce répertoire. Cette clé comporte des champs qui identifient uniquement le type de Système de fichiers, le disque, le n° de i-node du répertoire et les informations sur les protections. Classiquement, le client a un fichier script /etc/rc contenant entre autre les commandes de montage. Ce Shell sera exécuté automatiquement au lancement du système Automontage (Unix de Sun) : le montage se fait automatiquement à la 1ere ouverture d’un fichier à distance, le client contacte les serveurs et monte le répertoire contenant le fichier

Soit C le client et S le serveur Soit C le client et S le serveur.C envoie à S un chemin d'accès (le nom de la directory à monter) et demande la permission de monter la directory chez lui. L'endroit où C va monter la directory n'est pas important pour S. Si le chemin d'accès est correct et si la directory se trouve dans /etc/exports, S renvoie un file handle à C. Le handle est composé : du type du système de fichiers ; du disque ; du numéro de i-node de la directory ; d'infos de sécurité (droits d'accès). Pour lire ou écrire dans la directory montée, il faut utiliser ce handle.Un client peut monter des directory sans intervention humaine. Ces clients ont un fichier /etc/rc shell script qui contient les commandes de mount et lancé automatiquement au boot. C'est le static mounting.

Les versions récentes de Sun Unix ont l' automounting : Des directory distantes sont associées à des directories locales, mais elles ne sont pas montées, et leurs serveurs ne sont pas contactés au boot. La première fois qu'un client accède à un fichier distant, les serveurs sont contactés. Le premier qui répond gagne. Automounting vs Static mounting Avantages de l'automounting sur le static mounting : dans le static mounting, on ne contacte qu'un serveur pour chaque directory, alors qu'on peut en contacter plusieurs dans le automounting tolérance aux fautes. Inconvénient : tous les serveurs "alternatifs" pour une même directory doivent être cohérents surtout utilisé pour des systèmes de fichiers read-only.

2ème protocole : Protocole d’accès Le client envoie au serveur des requêtes de manipulation des répertoires ou des fichiers La plupart des appels système UNIX sont supportés par NFS, à l’exception de OPEN et CLOSE. L’omission de ces opérations permet au serveur de ne pas gérer les fichiers ouverts ( serveur sans état ( stateless ) ). Chaque requête d’accès se suffit à elle même. L’appel READ contient la clé du fichier, la position courante et le nombre d’octets à lire. On utilise LOOKUP à la place de OPEN. L’inconvénient est l’absence du contrôle de cohérence : on ne peut pas verrouiller le fichier( car il est toujours à l’état fermé), donc le partage d’accès peut introduire des incohérences. De plus, pour des raisons de performance, les clients utilisent des caches => MAJ incohérentes Rque: il existe sous UNIX système V, le Remote File System (RFS) qui demande que le fichier soit ouvert avant la lecture. Le serveur doit gérer dans ce cas un descripteur de fichier pour tt fichier ouvert à distance.

Les clients envoient des messages pour manipuler des directories, lire et écrire des fichiers et leurs attributs (taille, date de modification, propriétaire, etc.). Tous les appels systèmes sont pris en charge par NFS sauf OPEN et CLOSE. OPEN et CLOSE ne sont pas utiles : pour chaque opération read ou write, le client d'abord envoie une demande LOOKUP qui renvoie un file handle, le serveur ne garde pas trace de cette demande ; une opération read ou write est accompagné du handle. Si le serveur crashe aucune info sur les fichiers ouvert est perdue (puisqu'il n'y en a pas). Un serveur NFS est stateless.

Problèmes Un fichier Unix peut être ouvert et verrouillé (locked) pour empêcher les autres processus de l'utiliser. Fichier fermé verrous relachés. NFS est stateless, on ne peut pas associer de verrous à l'ouverture d'un fichier. Il faut un mécanisme externe à NFS pour gérer le verouillage. NFS utilise quand même le système de protection Unix (bits rwx pour le owner, group et world). MAIS : le serveur NFS croit toujours le client pour valider un accès. Que faire si le client ment ? Utilisation de la cryptographie pour valider les requêtes. Problème : les données, elles, ne sont pas cryptées. Les clés sont gérées par le NIS ( Network Information Service, ou yellow pages)

Implantation de NFS Client Serveur Réseau OS local OS local Couche appel système Couche système de fichiers virtuel Couche système de fichiers virtuel OS local serveur NFS OS local client NFS msg vers serveur msg vers serveur D local D local Réseau La couche VFS maintient une table pour chaque fichier ouvert. Chaque entrée est un v-node (virtual i-node). On indique si le fichier est local ou distant.

MOUNT : le sysop envoie mount + remote directory + local directory + other ; le programme mount parcours le nom de la remote dir et trouve le nom de la machine distante associée ; mount contacte la machine et demande un handle pour cette directory ; le serveur renvoie le handle si la requête est correcte ; mount fait un appel système MOUNT (kernel). Le kernel a la main : il construit un v-node pour la remote dir ; demande au client NFS de créer un r-node (remote i-node) dans sa table pour le file handle ; le v-node pointe sur le r-node. OPEN le kernel parcours le nom du chemin d'accès, trouve la directory, voit qu'elle est distante et dans le v-node de la directory trouve le pointeur sur le r-node ; le kernel demande au client NFS d'ouvrir le fichier ; le client NFS récupère le nom du serveur dans le nom du chemin d'accès et un handle ; le client crée un r-node et averti la VFS qui crée un v-node pointant sur le r-node ; le processus appelant récupère un file descriptor, relié au v-node de la VFS. Côté serveur, rien n'est créé.

READ la VFS trouve le v-node correspondant ; la VFS détermine si c'est local ou distant et quel est le i-node ou r-node à utiliser ; le client NFS envoie une commande READ, avec le handle. Les transferts se font normalement 8ko / 8ko, même si moins d'octets sont demandés. Automatiquement, dès que le client a reçu les 8ko demandés, une nouvelle requête de 8ko est envoyée. WRITE Les transferts se font aussi 8ko / 8ko.Tant que les données écrites sont < 8ko, elles sont accumulées localement. Dès que le client a écrit 8ko, les 8ko sont envoyé au serveur. Quand un fichier est fermé, ce qui reste à écrire est envoyé au serveur. Utilisation du caching : problèmes de cohérences. Cohérence du cache Pas de solution "propre" : on essaie de réduire le risque au maximum, mais sans l'éviter tout à fait. .

Domain Name System

Le principe basé sur le modèle client / serveur le logiciel client interroge un serveur de nom; typiquement : l’utilisateur associe un nom de domaine à une application ; exemple : telnet m1.centralweb.fr l’application cliente requiert la traduction du nom de domaine auprés d’un serveur de nom (DNS) : cette opération s’appelle la résolution de nom le serveur de nom interroge d’autres serveurs de nom jusqu’à ce que l’association nom de domaine / adresse IP soit trouvée le serveur de nom retourne l’adresse IP au logiciel client : 193.148.37.201 le logiciel client contacte le serveur (telnetd) comme si l’utilisateur avait spécifié une adresse IP : telnet 193.148.37.201

Principe (illustration) $ telnet m1.centralweb.fr DNS Demande de résolution m1.centralwebfr ???? serveur DNS client Telnet Réponse 193.148.37.201 serveur DNS 193.148.37.201 serveur Telnetd serveur DNS

Les noms de domaine Un nom de domaine est est la séquence de labels depuis le noeud de l’arbre correspondant jusqu’à la racine . fr M1.centralweb.fr centralweb m1 Deux noeuds fils ne peuvent avoir le même nom ==> unicité d’un nom de domaine au niveau mondial

Le domaine Un domaine est un sous-arbre de l’espace nom de domaine Domaine complet fr Domaine fr centralweb Domaine centralweb inria m1 noeud m1.centralweb.fr Des noeuds peuvent avoir les mêmes noms dans des domaines différents : ns.centralweb.fr et ns.renault.fr

Concepts, résumé et extension Un domaine est un sous-arbre de l’espace Nom de domaine Un domaine est constitué de noms de domaine et d’ autres domaines Un domaine intérieur à un autre domaine est appelé un sous domaine Exemple : le domaine fr comprend le noeud fr et tous les noeuds contenus dans tous les sous-domaines de fr Un nom de domaine est un index dans la base DNS; exemple : m1.centralweb.fr pointe vers une adresse IP centralweb.fr pointe vers des informations de routage de mail et éventuellement des informations de sous-domaines fr pointe vers des informations structurelles de sous-domaines Les machines sont reliées entre elles dans un même domaine logiquement et non par adressage. Exemple : 10 machines d’un même domaine appartiennent à 10 réseaux différents et recouvrent 6 pays différents.

Domaines racine Le système DNS impose peu de règles de nommage : noms < 63 caractères majucules et minuscules non significatives pas de signification imposée pour les labels Le premier niveau de l’espace DNS fait exception à la règle : 7 domaines racines prédéfinis : com : organisations commerciales ; ibm.com edu : organisations concernant l’education ; mit.edu gov : organisations gouvernementales ; nsf.gov mil : organisations militaires ; army.mil net : organisations réseau Internet ; worldnet.net org : organisations non commerciales ; eff.org arpa : domaine reservé à la résolution de nom inversée organisations nationales : fr, uk, de, it, us, au, ca, se, etc.

Domaines racine (suite) Nouveaux domaines racine en cours de normalisation: firm, store, web, arts, rec, info, nom Certaines organisations nationales peuvent être gérées administrativement par un consortium : RIPE Les divisions en sous-domaines existent dans certains pays et pas dans d’autres : edu.au, com.au, etc. co.uk, ac.uk, etc. ca.ab, ca.on, ca.gb pas de division du .fr

Lecture des noms de domaine A l’inverse de l’adressage IP la partie la plus significative si situe à gauche de la syntaxe : sun2.ethernet1.centralweb.fr 193.148.37.201 vers le plus significatif vers le plus significatif sun2. ethernet1. centralweb.fr domaine français (.fr) domaine de l’organisation CentralWeb sous-domaine CentralWeb machine sun2 du domaine ethernet1. centralweb.fr

Délégation Le système DNS est entièrement distribué au niveau planétaire; Le mécanisme sous-jacent est la délégation de domaine A tout domaine est associé une responsabilité administrative Une organisation responsable d’un domaine peut découper le domaine en sous-domaines déléguer les sous-domaines à d’autres organisations : qui deviennent à leur tour responsables du (des) sous-domaine(s) qui leurs sont délégué(s) peuvent, à leur tour, déléguer des sous-domaines des sous-domaines qu’elles gèrent Le domaine parent contient alors seulement un pointeur vers le sous-domaine délégué; exemple : centralweb.fr est délégué à l’organisation CentralWeb La société CentralWeb gère donc les données propres à ce domaine. centralweb.fr (en théorie seulement) pourrait être géré par l’organisation responsable du domaine .fr (NIC France) qui gèrerait alors les données de centralweb.fr

Utilisation du sytème DNS Utiliser un serveur de nom machine elle-même serveur de nom : 127.0.0.1 machine non serveur de nom : spécfier un ou plusieurs serveur de nom : adresses IP obligatoirement. éventuellement son domaine. sous UNIX : fichier /etc/resolv sous NT, W95 : administration TCP/IP Administrer un serveur de nom plateformes UNIX, NT mémoire importante : mini 16/32 MB pour le service. impératif : ne pas swapper laisser passer le port 53 sur UDP et TCP Commande Nslookup