You are on page 1of 62

Chapitre 7 - Systèmes d’exploitation répartis

Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis

Gabriel Girard

2007

1/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis

Chapitre 7 - Systèmes d’exploitation répartis

1 Étude de cas
Amoeba
Mach
NFS
AFS

2/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas

Chapitre 7 - Systèmes d’exploitation répartis

1 Étude de cas
Amoeba
Mach
NFS
AFS

3/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Amoeba

Système d’exploitation expérimental développé depuis 1984.


Deux hypothèses de travail :
le système aura beaucoup d’UCT
chaque UCT aura beaucoup de mémoire
Plus de frontière entre les ordinateurs

4/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Architecture

Chaque ordinateur a une tâche spécifique


gestionnaire de fichiers
station de travail
gestionnaire des communications
machine de traitement
Chaque ordinateur possède un noyau spécialisé pour son rôle
(7 noyaux)

5/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Architecture

Utilise le concept de micro-noyau


gestion des pcs et des fils
gestion de la mémoire (bas niveau)
gestion des communications (flip)
gestion des E/S de bas niveau (pilotes)
Tout est un objet
Tous les objets sont protégés par les pouvoirs

6/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Gestion de fichiers

Deux serveurs distincts


le serveur de fichiers
le serveur de répertoires

7/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Serveur de fichiers

Connaı̂t les fichiers par leur pouvoir


Fournit des fichiers immuables (lecture/écriture/destruction)
Allocation contiguë
Gère une cache avec LRU

8/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Serveur de répertoires

Traduction nom symbolique → pouvoir (non binaire)


Gère la liste des pouvoirs
Contient les pouvoirs de tous les objets (pas seulement les
fichiers)
Implante un hiérarchie graphique cyclique sans racine
Chaque usager possède son répertoire racine
L’usager Deamon possède un super-pouvoir
Implante un tableau

9/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Gestion des processus

Implante les multiples fils d’exécution


Fork ne copie pas le parent
Le RUN SERVER détermine où exécuter le pcs
Supporte l’hétérogénéité
Les fils sont semblables à ceux de Posix

10/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Gestion de mémoire

Pas de mémoire virtuelle


Un pcs est composé de segments
Les segments sont des objets sur lesquels on détient des
pouvoirs

11/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Protection

Par pouvoirs de 128 bits emmagasinés dans l’espace de


l’usager
48 bits pour le port du serveur
24 bits pour l’objet sur le serveur
8 bits pour les droits d’accès
48 bits pour l’encryptage

12/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Amoeba

Communication

Mémoire commune entre les fils


Par messages
RPC (point à point)
communication de groupe (avec tolérance aux fautes)

13/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Mach

C’est un micro-noyau (pas un système complet)


Racines : Rig (1975) → Accent (1981) → Mach (1986)
Les premières versions de Mach n’avaient pas un micro-noyau
Mach 3.0 avait un micro-noyau (1989)

14/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Micro-noyau

Base pour émuler Unix et d’autres systèmes


L’émulation est faite par des serveurs en dehors du noyau
Peut exécuter plusieurs émulateurs simultanément

15/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Micro-noyau

Fonctions du noyau
gestion des processus
gestion de la mémoire
gestion des communications
gestion des E/S

16/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Micro-noyau

Le noyau gère cinq abstractions :


le processus : environnement d’exécution
le fil (thread)
l’objet mémoire
le port de communication
le message

17/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Micro-noyau

La communication est entièrement basée sur le passage de


messages
Les messages transigent par des boı̂tes aux lettres protégées
(ports)
Le noyau gère les ports
Chaque port se voit associer un nombre max. de messages en
attente
Un pcs doit être autorisé à utiliser un port
Les permissions sont des pouvoirs (pointeur + droits)

18/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion des processus

Environnement auquel on assigne les ressources


Entités passives
Possède des ports pré-alloués
port processus (appels systèmes)
port bootstrap (pour initialisation)
port exception (pour rapporter les erreurs)
ports enregistrés (services standards)

19/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion des processus

États : prêt ou bloqué


Autres paramètres :
planification
adresse d’émulation
statistiques

20/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion des processus

Un processus n’a pas :


UID, GID, signal mask, répertoire de base
répertoire de base, répertoire courant
table des fichiers ouverts

21/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Opérations sur les processus

Se font par l’envoie de msgs au noyau (port processus)


Opérations :
création, terminaison
suspendre, résumer
priority, assign
info, threads

22/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion des fils

Entités actives
Fils de niveau noyau
Un port pré-assigné (thread port)
États des fils : prêt et bloqué
Synchronisation (mutex, condition)
Utile sur les multiprocesseurs

23/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion de l’UCT

Les UCTs sont assignés à des ensembles de processeurs par


logiciel
Chaque UCT appartient à exactement un ensemble
Les fils peuvent aussi être affectés à un ensemble de
processeur
Planification efficace et équitable
Tout se passe dans un ensemble

24/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion de l’UCT

Planification basée sur des priorités (0-31) et les tranches de


temps.
Chaque fil possède trois priorités (base, minimale, courante)
Chaque ensemble de processeurs possède un vecteur de files
d’attente contrôlée par un mutex (global run queues)
Chaque UCT possède des files d’attente locales pour les
processus attachées en permanence à cet UCT
Tranche de temps variable (dépend du nbr de fils et du nbr de
processeurs)
Vieillissement
Affinity scheduling

25/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion de la mémoire

Basée sur la pagination


Séparée en deux parties :
celle dépendante du matériel
celle indépendante du matériel
Interagit beaucoup avec le système de communication

26/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Gestion de la mémoire

Le code est séparé en trois modules :


module pmap : dans le noyau, gère le mmu
module noyau : dans le noyau mais indépendant de la machine
(fautes, adresses, remplacement)
external pager : gère le swap..
Le noyau et le paginateur externe communique par une
protocole spécial.
Un usager peut écrire son propre gestionnaire

27/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Mémoire virtuelle

Espace d’adresses de de 232 cellules divisée en sections


(régions)
Les sections sont de dimensions quelconques
Représentent des sections distinctes de la mémoire
Allocation dynamique

28/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Mémoire virtuelle

Autre concept important : objet mémoire


Peut être une page, un ensemble de pages, un fichier ou une
autre structure spécialisée
Peut être projeté sur une section inoccupée
Chaque classe d’objets possèdent sont propre paginateur
externe
Grâce aux objets mémoire, on peut projeter les fichiers en
mémoire

29/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Mémoire virtuelle

Les processus partagent des objets pour éviter les copies


inutiles
Attributs d’héritage :
non utilisé,
partagé,
copie on write

30/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Communication

Msg et ports (boites aux lettre protégées)


Supporte : communication asynchrone, RPC, byte streams, ...
Communication unidirectionnelle
Fiable (pas de perte et arrive dans l’ordre)
Format d’un message complexe
Une seul opération sur les messages (paramétrisée)

31/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Communication

À la création d’un port : descripteur (indice dans table des


pouvoirs)
Valide uniquement dans un processus
Les ports sont conservés par processus
Transmission par copies
Un port peut appartenir à un ensemble de ports
On peut recevoir d’un ensemble
un seul processus peut recevoir d’un port

32/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
Mach

Pouvoirs

Le noyau maintient un table de pouvoirs par processus


Un pouvoir contient : pointeur vers le port et les droits d’accès
Un compte du nombre de fils ayant accès au port est maintenu
Transmission par copies
Un port peut appartenir à un ensemble de ports
On peut recevoir d’un ensemble

33/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

NFS

Un des premiers système de fichiers répartis commercial


Caractéristiques importantes :
la description est publique
VFS
RPC
XDR

34/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

NFS

Permet à différents sites de partager des fichiers


Basé sur le concept clients/serveurs

35/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Serveurs

Un serveur par machine


Accès est donné en exportant les répertoires (/etc/exports ou
fstab)

36/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Clients

Les clients  montent les répertoires


Le répertoire fait ensuite partie de la hiérarchie
Accès comme si fichier local
Le  mount crée un lien
Si plusieurs clients montent le même répertoire → partage

37/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Montage

La demande de montage est reçue par mountd


Pour savoir où accrocher le répertoire :
interactif
fichiers spéciaux : global (NIS) ou local (fstab, vfstab ...)
Pour savoir quand monter :
au démarrage (/etc/rc)
à la première référence
manuellement (commande mount)
On peut  démonter périodiquement

38/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Protocole

NFS fournit deux protocoles :


le premier gère les mount
le second gère les accès
Ces protocoles sont basés sur les RPC et XDR
Peuvent aussi utiliser d’autres normes (TCP/IP, UDP/IP, ...)

39/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Protocole mount

Le client envoie le chemin et demande la permission de monter


Le serveur retourne un  handle (type de fichier, disque,
i-node, protection)

40/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Protocole d’accès

C’est un protocole stateless


Le client envoie un message pour :
manipuler des répertoires
lire ou écrire des fichiers (pas de open/close)
obtenir les attributs d’un fichier,
...

41/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Protocole d’accès

Lecture ou écriture
envoie un lookup avec le nom pour obtenir un handle
envoie des lectures contenant le handle , le déplacement et
le nombre d’octets
le client conserve l’information dans sa table de fichiers ouverts
Difficile de conserver la sémantique de UNIX (open + lock)

42/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Architecture

NFS est organisé en trois couches


la couche interface au système de fichiers local (open, close,
read, write)
la couche VFS qui est un interface restreint et indépendant des
autres systèmes de fichiers
la couche des appels systèmes reçoit les demandes des
applications et les traduit en appels vers VFS

43/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

VFS

VFS utilise des vnodes pour représenter les fichiers


Operations : open, close, rewr, ioctl, ...
Chaque opération est un appel :
au système d’exploitation sous-jacent si le fichier est local
au client NFS si le fichier est éloigné
VFS maintient maintient une table de fichiers ouverts

44/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Structure de NFS

45/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Exemple mount

Client contacte le serveur


Le client reçoit un handle


Le noyau construit un  vnode pour le répertoire éloigné


Le noyau demande au client NFS de créer un rnode pour
ses tables internes qui contiendra le handle
Le  vnode pointe vers un  rnode ou un  inode

46/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Exemple ouverture

On retrouve le répertoire où est monté le système de fichier


Si éloigné : trouve le rnode dans le vnode
Demande au client NFS d’ouvrir le fichier
Le client NFS demande le handle (lookup)
Le client NFS construit un rnode et retourne à VFS
VFS ajoute un Vnode dans ces tables qui pointe vers le rnode
Tous les fichiers ouverts ont un  vnode qui pointent vers un
inode ou un rnode

L’appelant reçoit un descripteur qui correspond à l’entrée dans


la table de VFS.

47/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Exemple lecture

VFS trouve le vnode


Si local, utilise le inode
Si éloigné : trouve le rnode dans le vnode et l’utilise
Les transferts se font par blocs de 8k
VFS fait de la lecture à l’avance (read ahead)
L’écriture est similaire

48/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Cache

Fait de l’accès éloigné


Utilise une cache sur le client (mémoire et disque (cacheFS))
Incohérences :
Timer associé à chaque bloc (3 sec. pour les données et 30 sec
pour les attributs)
Lors de l’ouverture, si le fichier est dans la cache on vérifie la
date de dernière modification avec le serveur
Les modifications sont envoyées à toutes les 30 secondes

49/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

Problèmes

Ne fournit pas la sémantique exacte de Unix


Une écriture peut ne pas être visible immédiatement
Un fichier peut devenir visible 30 secondes après sa création
Ce n’est pas une sématique de session ni la sémantique de
Unix

50/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
NFS

AFS

Andrew File System


Le développement débute en 1983 à CMU
AFS-1, AFS-2, AFS-3 (RFS dans OSF)

51/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Buts

Produire un système de fichiers aptes à supporter une très


grande communauté d’usagers
Sécurité
Efficacité
Capacité d’expabsion (scalability)

52/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Basé sur le concept de clients/serveurs


Utilise les RPC
C’est un système de fichiers global (apparaı̂t comme un
branche dans Unix)
Répertoires additionnels pour tous :
/cache : contient les fichiers éloignés qui sont dans la cache
/cmu : sytème de fichiers global (le système de fichier éloigné
est monté à ce point)

53/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Le serveur exécute un processus appelé Vice


Le client exécute un processus appelé Venus
Tout comme NFS, utilise  VFS qui nécessite une
modification du noyau
Tout comme NFS, VFS fournit un interface commune pour
tous les fichiers (locaux ou éloignés)

54/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Structure deAFS

55/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Basé sur le modèle  upload/download (file caching)


La mémoire disque locale sert principalement de cache
Veut minimiser les communications en faisant le plus de
travail possible localement

56/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Les fichiers sont immuables


Un client transfère le fichier, le modifie et crée une nouvelle
version
Si aucun autre client n’a obtenu le fichier entre-temps, cette
version devient la nouvelle version par défaut
Si un autre client a obtenu la version originale entre-temps, l’a
modifié et l’a ré-écrit sur le serveur, elle recevra un nouveau
numéro de version unique
Les deux version incohérentes peuvent coexister comme
différentes versions

57/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Lors d’une destruction, la plus vieille version est détruite


Lors d’une ouverture, la version la plus récente est ouverte

58/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

La cohérence est maintenue par le serveur


Si le fichier est modifié sur le serveur, ce dernier utilise un
mécanisme de callback pour invalider les caches des clients

59/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Concepts et structure

Sémantique de session pour les données


Écriture immédiate (write through) pour les répertoires
Invalidation de cache
Dans les nouvelles version, les fichiers ne sont pas tranférés en
totalité

60/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Sécurité

ACL
Authentification et cryptographie

61/62 Processus concurrents et parallélisme


Chapitre 7 - Systèmes d’exploitation répartis
Étude de cas
AFS

Étude de cas

FIN

62/62 Processus concurrents et parallélisme

You might also like