Introduction aux systèmes distribués

Introduction aux systèmes
distribués
1
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
2
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 ?
3
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
4
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
5
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
6
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
7
Architecture matérielle
Système distribué = architecture MIMD dans la classification de Flynn’s
Architectures
fortement
couplées
Ordinateurs parallèles
ou distribués (MIMD)
Multiprocesseurs
(mémoire partagée)
Bus
Réseau
Architectures
faiblement
couplées
Multicomputers
(mémoire privée)
Bus
Réseau local
Réseau
Hypercube
8
Multiprocesseur à mémoire
partagée fondé sur un bus
Mémoire
partagée
Bus
Caches
Processeurs
P1
P2
P3
P4
9
Multicomputer fondé sur un bus
Réseau local de stations de travail
Bus
(LAN)
Mémoire
locale
Processeur
10
Terminologie
• Système parallèle
– 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 …
11
Système distribué à grande échelle
• Fondé sur un réseau longue distance
E
Internet
A
D
Site
B
Réseau physique
C
Passerelle
(routeur)
12
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
13
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é
14
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.
15
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
16
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
17
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
18
Applications
• Applications scientifiques
– 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
19
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.
20
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.
21
NFS : Protocoles
1.
2.
3.
4.
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 22
serveurs et monte le répertoire contenant le fichier
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.
23
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 :
1. 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.
24
2ème protocole : Protocole d’accès
1.
Le client envoie au serveur des requêtes de manipulation des répertoires ou des
fichiers
2. 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.
25
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.
26
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)
27
Implantation de NFS
Client
Serveur
Couche appel système
Couche système de fichiers virtuel
Couche système de fichiers virtuel
OS
local
D local
client NFS
serveur NFS
msg
vers serveur
msg
vers serveur
OS
local
D local
Réseau
28
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éé.
29
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. .
30
Domain Name System
31
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
32
avait spécifié une adresse IP : telnet 193.148.37.201
Principe (illustration)
$ telnet
DNS
m1.centralweb.fr
Demande de résolution
m1.centralwebfr ????
client
Réponse
Telnet
193.148.37.201
serveur
DNS
serveur
DNS
193.148.37.201
serveur
Telnetd
serveur
DNS
33
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
34
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
35
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
36
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.
37
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
38
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
39
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
•
40
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
41