Cours Decembre 2004

Laurent Bobelin, CS-SI

Du Client/Serveur aux architectures de grilles de calculs et de données

Du client serveur aux grilles de calcul et de données

Plan du cours

• Motivation générale

• Les différents types de parallélisme

• Les architectures parallèles et distribuées

• Les environnements de programmation parallèle

• Les paradigmes systèmes distribués grande échelle et de grille

• Architecture des grilles de calcul et de données

• Perspectives pour les grilles de calcul et de données


Plan : Motivation générale• Les besoins

• Physique• Des confins de la matière jusqu’à la simulation des surfaces

• Sciences de la terre• Observation de la terre

• Biologie• Analyse du génome humain

• Conception Assistée par Ordinateur• Modélisation automobile

• Autres

• Débouchés industriels• Industriels intéressés

• Les fournisseurs de services• Les fournisseurs de ressources• Les applications

• Les profils industriels • Conseil• Maîtrise d’œuvre• Conception, déploiement et administration• Middlewares• Application• Exploitation


Motivation générale : Les besoins : Physique

• Large Hadron Collider

• Modélisation de surface

• Applications nucléaires


Motivation générale : Les besoins : Physique : LHC

• Le CERN (Centre d’Etude et de Recherche Nucléaire) basé en Suisse, est le plus grand centre mondial de recherche en Physique des Hautes Energies et en physique des particules.

• Le Large Hadron Collider (LHC) est un projet du CERN : construire le plus puissant accélérateur de particule au monde, qui devrait être achevé en 2007.

• Le but : faire entrer en collision des protons et analyser les traces de cette collision pour prouver l’existence de particules sous-jacente, les bosons de Higgs



• Le LHC est constitué d’une boucle de 20km de

diamètre, dans laquelle sont injectés des protons.

• Le long de cette boucle, des capteurs sont disposés

pour percevoir les traces de particules.


The LHC Detectors

CMSATLAS

LHCb

~6-8 PetaBytes / year~108 events/year

~103 batch and interactive users

Le LHC :



• L’ensemble des capteurs une fois le LHC opérationnel

générera plusieurs péta-octets de données par an, qu’il

faudra analyser et stocker.

• Le CERN est donc de facto un des plus grands acteurs

des projets de recherche de grille européen.


Motivation générale : Les besoins : Physique : Modélisation de surface

• Modéliser une surface permet de prédire les changements climatiques.

• La structure des sols peut varier et induit des changements

• La végétation à une influence

• Plus le modèle est fin, plus la modélisation de surface est pertinente.

Plus les ressources informatiques mises à disposition de l’application sont importantes, meilleure sera la modélisation.


Motivation générale : Les besoins : Physique : Application nucléaire

• Modéliser le comportement du cœur d’un réacteur nucléaire

• Analyse des points chauds

• Modélisation des matériaux et de leur résistance

• Prédire le comportement en cas d’incident

De même que pour le cas précédent, plus les ressources informatiques mises à disposition de l’application sont importantes, meilleure sera la modélisation.


Les challenges des projets ESA :

• Environ 100 Gbytes de données par jour pour la mission(ERS 1/2)

• 500 Gbytes, pour la mission ENVISAT (2002).

Source: L. Fusco, June 2001

Motivation générale : Les besoins : Observation de la terre

• Envoi de satellite pour observer la terre


Medical images

Exam image patient key ACL ...

1. Query the medical image database and retrieve a patient image

Metadata

3. Retrieve most similar cases

Similar images Low score images

2. Compute similarity measures over the database images

Submit 1 job per image

• Bio-informatique :• Phylogenetique• Search for primers• Statistiques génétiques• Parasitologie• Data-mining sur des bases ADN• Comparaison géometrique

protéinique

• Imagerie Médicale• Modélisation et imagerie

numérique• Medical data and metadata

management• Analyse de mammographies

Motivation générale : Les besoins : Biologie


Motivation générale : Les besoins : Conception Assistée par Ordinateur

• Automobile :

• Construire un prototype est d’un coût très élevé

• Des défauts de conception peuvent apparaître à la construction du prototype

• De nombreux tests sur la sécurité, la vitesse, etc, peuvent demander de construire de nombreux prototypes.

Nécessité de modéliser finement les prototypes pour baisser le coût de conception d’un nouveau modèle


Renault :

simulations, modélisation,

Météorologie et climatologie

Industries Aéronautiques

simulation et modélisation, réalité virtuelle

Simulation grandes échelle : tectonique, modèles atmosphériques…

EDF : simulation Temps-réel

ONERA : simulation de phénomènes physiques

Motivation générale : Les besoins : Autres


Motivation générale : Débouchés industriels

• Industriels intéressés

• Les fournisseurs de services

• Les fournisseurs de ressources

• Les applications

• Profils industriels

• Conseil

• Maîtrise d’œuvre

• Conception, déploiement et administration

• Middlewares

• Application

• Exploitation


Motivation générale : Débouchés industriels : Industriels intéressés

• Les fournisseurs de services :

• Entreprise ayant pour activité de vendre des services (stockage, calcul, hébergement)

IBM par exemple.

• Les fournisseurs de ressources

• Entreprise voulant rentabiliser les ressources informatiques qu’elle possède, comme

CGG.

• Les applications

• Entreprise voulant entreprendre des calculs de grande échelle


Motivation générale : Débouchés industriels : Industriels intéressés : Les fournisseurs de services

• Les besoins des ressources sont multiples : calcul, stockage, intégration, portage, administration, mise en œuvre, développement de solutions logicielles ad-hoc.

• Quatre types :

• Ressources : • Grandes entreprises informatiques proposant des solutions « tout-en-

un » (IBM)

• Logiciels : Entreprises fournissant des logiciels génériques pour les grilles (Sun, Microsoft, …) et voulant dominer le marché.

• Les SSII : conseil, développement,maintenance, migration, etc. (CSSI, Atos, …)


Motivation générale : Débouchés industriels : Industriels intéressés : Les fournisseurs de ressources

• Certains industriels possèdent un grand nombre de ressources (calcul, stockage) inutilisées :

• Ordinateurs « personnels » • Ressources aléatoires dans leur nombre et leur disponibilités

• Ressources contraintes par le temps• Analyse à un instant T demandant beaucoup de ressources, mais peu

utilisées le reste de la journée• CGG, météorologie

• Ces ressources peuvent être vendues aux applications nécessitant beaucoup de ressources.


Motivation générale : Débouchés industriels : Industriels intéressés : Les applications

• Industriels ayant besoin d’un grand nombre de ressources :

• Simulation : PSA, EDF, CEA, …

• Prédiction : météorologie (Méteo de France, CGG)

• Nécessité de migrer leurs applications

• Nécessité d’améliorer les performances de leurs applications

• Rester/devenir les leaders sur leur marché


Motivation générale : Débouchés industriels : Les profils industriels

• Conseil :étude d’opportunité, expression des besoins, réalisation de cahier des

charges.

• Maîtrise d’œuvre et assistance à la maîtrise d’ouvrage.

• Conception, déploiement et administration des infrastructures de grille.

• Middlewares : développement,adaptation, installation.

• Application : développement, adaptation.

• Exploitation :gestion, évolution.


Motivation générale : Débouchés industriels : Les profils industriels : conseil

• Conseil :

• étude d’opportunité : est-il utile pour une application d’être migrée

vers une technologie de grille ?

• expression des besoins : quels sont les besoins d’une application ?

• réalisation de cahier des charges : comment peut-on faire, et dans

quel délais peut on obtenir un résultat ?


Motivation générale : Débouchés industriels : Les profils industriels : maîtrise d’œuvre et assistance à la maîtrise d’ouvrage

• Maîtrise d’œuvre :

• Coordination, relations entre la problématique applicative et les

technologies de grille

• Besoins lors de la migration ou du portage d’application sur grille


Motivation générale : Débouchés industriels : Les profils industriels : Conception, déploiement et administration des infrastructures de grille

• Conception : quelle est la meilleure architecture pour un

ensemble d’applications donné ?

• Déploiement : comment utiliser les ressources ?

• Administration : comment faire en sorte que les ressources

restent opérationnelles ?


Motivation générale : Débouchés industriels : Les profils industriels : middleware

• Développement : un middleware adapté aux besoins

• Adaptation : un middleware existant, l’adapter aux

besoins

• Déploiement : rendre l’utilisation effective


Motivation générale : Débouchés industriels : Les profils industriels : Applications

• Développement :

• Les grilles ont des spécificités qui sortent du domaine du calcul

parallèle classique

• Nécessité de développer des applications tirant un profit maximum des ressources

• Adaptation :

• Des applications peuvent bénéficier d’une « gridification » :

comment l’adapter aux problématiques grilles ?


Motivation générale : Débouchés industriels : Les profils industriels

• Exploitation :

• Gestion : gérer et administrer une grille dans une entreprise, veiller a son

bon fonctionnement, gérer les utilisateurs

• Évolution : redimensionner une grille, faire évoluer son middleware et les

logiciels associés.


Plan : Les différents types de parallélisme

• Introduction au parallélisme

• Les différents types de parallélisme

• Granularité


Introduction au parallélisme

• Parallélisme

• utiliser plusieurs ordinateurs ensemble pour résoudre des problèmes• plus gros (taille mémoire, espace disque)• plus rapidement (puissance CPU)

• Mot clé : efficacité

• Différents domaines

• théoriques• algorithmique• ordonnancement

• pratiques• supports• modèles

si on veut de l ’efficacité les deux sont évidemment liées


Les différents types de parallélisme

• Client/serveur

• Parallélisme de tâche : application exhibant un graphe de tâches dont certaines peuvent être effectuées en parallèle

• Parallélisme de données : application qui traite de la même façon plusieurs jeux de données.

• Parallélisme mixte : application exhibant du parallélisme de données et de tâches

• Parallélisme massif : application exhibant un gros potentiel parallèle


Granularité

• On appelle granularité la « taille » d’un traitement séquentiel dans une application parallèle

• Cette granularité dépend non seulement de l’application, mais aussi de son implémentation

• On parle de « gros grain » pour les applications ayant une forte exécution séquentielle

• Fréquence de communication moins grande

• Pas forcement moins gourmande en débit !

• On parle de « grain fin » pour les applications ayant une forte exécution parallèle de tâche

• Plus sensible à la latence du réseau


Granularité

• Parallélisation à gros grain

• Parallélisation à grain fin

Population

SP1

Division

SP2

SP4 SP3

Sous-Populations

Individus

A B C D E FDistribution

A B C

D E F

Processeurs


Plan : Les architectures parallèles et distribuées

• Les multiprocesseurs

• Les clusters

• Les environnements hétérogènes

• Les centres de calcul


Les multiprocesseurs – pourquoi

• En supposant que les microprocesseurs demeurent la technologie dominante pour les uniprocesseurs, il semble naturel d’imaginer en connecter plusieurs ensemble pour augmenter la performance

• Il n’est pas clair que le taux d’innovation au niveau de l’architecture pourra se continuer longtemps

• Il semble qu’il y ait des progrès constants dans les 2 domaines où les machines parallèles ont le plus de difficulté: le logiciel et les interconnexions


Accélération = gain de temps obtenu lors de la parallélisation du programme séquentiel.

Définition : Soit T1 le temps nécessaire à un programme pour résoudre le problème A sur un ordinateur séquentiel et soit Tp le temps nécessaire à un programme pour résoudre le même problème A sur un ordinateur parallèle contenant p processeurs, alors l ’accélération (Speed-Up) est le rapport : S(p) = T1 / Tp

Cette définition n’est pas très précise

Pour obtenir des résultats comparables il faut utiliser les mêmes définitions d ’Ordinateur Séquentiel et de Programme Séquentiel …

Notion d’accélération


0P = nombre de processeurs

S(p)

Région des accélérations sub-linéaires

Région des accélérations sur-linéaires

accéléra

tion lin

éaire

Notion d’accélération


Soit T1(n) le temps nécessaire à l’algorithme pour résoudre une instance de problème de taille n avec un seul processeur, soit Tp(n) celui que la résolution prend avec p processeurs et soit s(n,p) = T1(n) / Tp(n) le facteur d’accélération. On appelle efficacité de l ’algorithme le nombre

E(n,p) = S(n,p) / p

Efficacité = normalisation du facteur d ’accélération

Notion d’efficacité


Multiplication de matrices ( A moins bon que B)

Algorithme A

Temps en séquentiel : 10 minutesNombre de processeurs : 10Temps en // : 2 minutesAccélération : 10/2 = 5 (l'application va 5 fois plus vite)Efficacité : 5/10 = 1/2

Algorithme B

Temps en séquentiel : 10 minutesNombre de processeurs : 3Temps en // : 4 minutesAccélération : 10/4 = 5/2 = 2,5 < 5Efficacité : (5/2)/3 = 0,8 > 0,5

Efficacité/Accélération


Une accélération linéaire correspond à un gain de temps égal au nombre de processeurs (100% activité)

Une accélération sub-linéaire implique un taux d ’activité des processeurs < 100 % (communication, coût du parallélisme...)

Une accélération sur-linéaire implique un taux d’utilisation des processeurs > à 100 % ce qui paraît impossible (en accord avec la loi d ’Amdhal)

Cela se produit parfois (architecture, mémoire cache mieux adaptée que les machines mono-processeurs…)

Remarques


Nous retrouvons couramment MIPS ou FLOPS

MIPS (Machine Instructions Per Second) représente le nombre d ’instructions effectuées par seconde FLOPS (FLoating Point Operations Per Second) représente le nombre d ’opérations en virgule flottante effectuées par seconde

Les multiplicatifs : K = 210 ; M = 220 ; G = 230

Certains processeurs vectoriels ont une puissance de calcul de 300 Mflops par exemple.

Puissance de calcul


Les types de multiprocesseurs

• Taxonomie proposée par Flynn dans les années 60:

• SISD (Single Instruction Single Data): uniprocesseur

• SIMD (Single Instruction Multiple Data): plusieurs processeurs, qui exécutent en parallèle les mêmes instructions sur plusieurs données

• MISD (Multiple Instruction Single Data): pas d’exemple connu

• MIMD (Multiple Instruction Multiple Data): plusieurs processeurs qui opèrent de façon indépendantes ou semi-indépendantes sur leurs données


SIMD (Single Instruction Multiple Data) séquenceur unique tableau de processeurs

MISD (Multiple Instruction Single Data) classe bizarre pipeline ?

MIMD (Multiple Instruction Multiple Data) Classe la plus importante processeurs autonomes Mémoire partagée ou distribuée

Cette classification n’est pas en corrélation avec les machines réelles



MIMD: la mémoire

• Les deux classes de multiprocesseurs MIMD sont largement répandus ; le choix de MIMD-SD ou MIMD-DM dépendant du nombre de processeurs dans la machine

• Mémoire partagée centralisée (centralized shared memory) : « petit » nombre de processeurs.

• Mémoire distribuée : «grand » nombre de processeurs.


SIMD-SM Contrôle centralisé de données centralisées Machine vectorielles mono-processeurs Instruction unique appliquée de manière séquentielle à des données de type vecteur Fonctionnement en mode pipeline

Pipeline : Décomposition de l ’opérateur f = f3 ° f2 ° f1 On applique successivement f1, f2 puis f3 sur cette donnée circuits dans les processeurs circuit = composant électronique qui prend d en entrée et donne f(d) en sortie séquence de circuits en étages

Classification unifiée des types de multiprocesseurs


SIMD-DM : Contrôle centralisé, données distribuées Processeurs de faible puissance = éléments de calcul Séquenceur unique

MIMD-DM : Contrôle distribué, données distribuées Un processeur = entité de calcul autonome (processeur + mémoire) Communication par envoi de messages : importance du réseau d ’interconnexion Avantage : facile d ’augmenter le nb de proc Inconvénients : performances étroitement liées au réseau et besoin d ’OS nouveaux.



MIMD-SM :

Mémoire divisée en plusieurs bancs Synchronisation des accès à la mémoire, un seul processeur peut accéder en lecture ou écriture à un banc Machine multi-processeurs : Cray 2, NEC SX-3 Faible nombre de processeurs Puissance de la machine repose sur la puissance des processeurs et non sur le nombre



Types de multiprocesseurs utilisés

• Les premiers multiprocesseurs étaient du type SIMD, et cette architecture est encore utilisée pour certaines machines spécialisées

• Le type MIMD semble être la cible de choix de nos jours pour des ordinateurs d’application courante:

• Les MIMD sont flexibles: on peut les utiliser comme machines à un seul utilisateur, ou comme machines multi-programmées

• Les MIMD peuvent être bâties à partir de processeurs existants


IBM SP

IBM SP-2 (from MHPCC)

IBM SP

IBM SP 680

IBM SP 680 specs

IBM X server

Cray T3E

Compaq (DEC) Alpha Chips ( Alpha white paper )

Cray white paper

SGI Origin 2000 , (3000)

performance Tuning for the Origin2000

R10000 Chip , R10000 Brief , Other MIPS Chips , MIPS

Architectures parallèles : exemple MIMD


Compaq Servers, GS320 server

Distributed Memory Vector

NEC (Japan)

Fujitsu (Japan)

Hitachi (Japan)

Beowulf Projects

Beowulf slides (Modi)

Intel Teraflop Machine , ( Performance Tuning )

Linux Intro , Installing Linux , Linux Palmtops

Windows NT/2000 based Beowulf Systems , ( MPICH )

Architectures parallèles : exemple MIMD


La machine de chez CRAY, deux types de modèles, refroidissement à air (pas plus de 128 processeurs) ou par un liquide (jusqu'à 2048 processeurs). En amalgamant les deux de 16 à 2048 nœuds comprenant chacun :

un DEC Alpha EV5 (600 MFlops) de 64 Mo à 2 Go de mémoire vive un réseau d'interconnexion en tore 3D (bande passante de 2 à 128 Go/s).

Performance de crête de 9.6 GFlops à 1.2 TFlops, jusqu'à 4 To de mémoire vive.

Architectures parallèles : exemple MIMD : le Cray T3E


CM-1, CM-2, & CM-200 ( NPAC )

Maspar MP-1 & MP-2

Cambridge Parallel Processing ( NPAC pages , Overview )

Oxford Micro

Pentium 4

Intel SIMD

Intel MMX SIMD (UBC)

Motorola 7450

Motorola 7400 processor

Motorola Altivec

Architectures parallèles : exemple SIMD


Architectures parallèles : exemple SIMD

Architectures de grappes de PC


Définition

• Une grappe (cluster) est une collection de machines interconnectées, utilisée comme une ressource de calcul unifiée

• Une grappe « Beowulf » se définit par les propriétés suivantes :

• composants à grande diffusion

• composants réseau à faible coût

• système d ’exploitation « open source »

• hardware non propriétaire

• logiciel « open source »


Des grappes de référence : le Top500

• Sandia 592 procs alphas, myrinet, linux, #44

• NCSA 256 pentiums, myrinet, NT, #68

• Cornell 256 pentiums, giganet, NT, #198

• Los Alamos 140 alphas, Ether100/1000, linux, #265

• Paderborn 192 pentiums, SCI, solaris, #351

• Bonn 144 pentiums, myrinet, linux, #454

• Chiba, Los Lobos, CEA, FSL, … en 2000


Processeur

Pentium Alpha

NTLinux

OS

Solaris,...

SCI

Réseau

Ethernet

Giganet, ServerNet, ...Myrinet

SMP

biproc

quadriprocMono

Technologies :

? IA64


L’interconnexion réseau

SCIVIA

Fibre Channel

HIPPI

FDDI

WDM

Infiniband

Ethernet

PCI

SAN WANMANLAN

...

ATM

...SCSI

Myrinet

...


La technologie Myrinet

• Commutation de paquets

• Topologie très souple

• Carte réseau muni d ’un processeur RISC pilotant plusieurs contrôleurs DMA

PCIBRIDGE

DMAcontroller

RISCprocessor

Hostinterface

PacketInterface

Local memory

PCIbus

network


La technologie SCI

Interconnexion SCI

Processus A

Espace d'adressage

virtuel

Bus PCI

PCI-SCI

Processus B

Espace d'adressage

virtuel

Bus PCI

PCI-SCI

Mémoire physique

• réseau à capacité d’adressage

• adressage des mémoires distantes

• lecture/écriture distante sans interrompre le processeur distant

• plus de nécessité de programmation par échanges de messages

• Topologie en grille


La technologie VIA

Une interface logicielle dont l’objectif est de limiter les accès au système et les copies de buffers.

Peut être implémentée en hardware

Standard industriel proposé par Microsoft, Intel, Compaq. Aujourd’hui par Dell, Intel, Compaq

application application

Système d ’exploitation

Contrôleur réseau Contrôleur réseau VIA

Systèmed ’exploitation

VIcontrôle contrôle

données

données

Architecture TCP/IP Architecture VIA


Les autres

• Memory channel :

• espace d ’adressage mémoire unique

• bonne latence

• passage à l ’échelle par SMP donc limité

• SupperHIPPI, FibreChannel, Infiniband, ATM, WDM, Quadrics, ...

• offre cluster balbutiante ou de luxe


SCI : pour/contre

• espace d ’adressage mémoire unique

• latence/messages de petite taille

• manque de maturité

• monopolise le CPU

• quelle fiabilité en cas de panne d ’un nœud

Myrinet : pour/contre• Plus grande maturité

• intégrateurs en France

• bande passante

• Autant de MPI/drivers/firmware que de grappes


Les autres possibles

• ServerNet II• VIA

• orienté haute disponibilité : contrôle d ’erreurs en hardware, redondance

• support de Compaq

• Giganet• VIA

• disponible sur NT/linux

• débit/messages de grande taille

Mais quelle maturité ?Quel avenir pour VIA ?


Les autres possibles• (Double) Fast Ethernet

• standard

• le moins cher

Mais latence importanteet très forte utilisation du CPU (en attendant VIA et des cartes avec processeur)

• Gigabit Ethernet

• standard, plusieurs fournisseurs

• de moins en moins cher

• switches 64 ports


L’intégrateur/vendeur

• support scientifique

• support technique

• maintenance

• intégration hardware

• intégration software

Minimum : intégration hardware et validation par déploiement du système et de benchmarks


Des options coûteuses :

• Racks

• contrôle souhaité (BIOS, wake on line, boot PXE, lien série, …)

• concentrateurs d ’alimentation électrique

• écrans, switchs d ’écran ?

• disques locaux

• des serveurs supplémentaires : contrôle, login, fichier, développement, scheduler

Les environnements hétérogènes


Les environnements hétérogènes : définition

• Un environnement distribué hétérogène est le regroupement de ressources informatiques (CPU, Disk, mémoire) d’origine, de taille et de type divers.

• Absence de réseau de communication spécifique

• Souvent appelé « le cluster du pauvre », la récupération de ressources informatique inutilisée, par exemple les stations de travail la nuit, pour former une machine multiprocesseurs virtuelle hétérogène, est une pratique courante des laboratoires


Les environnements hétérogènes : Caractéristiques

Hétérogénéité– Réseaux (couches de communications multi-protocoles), processeurs,

hiérarchies mémoire profondes– Systèmes– Équilibrage des charges (ordonnancement)– Distribution des données (statique et dynamique)– Évaluation des performances, modélisation des architectures– Simulation


Les environnements hétérogènes : Problématique spécifique

• Hétérogénéité des performances :

• L’hétérogénéité des performances induit d’avoir un modèle de description des performances pour chaque architecture et des algorithmes d’ordonnancements ad hoc.

• Hétérogénéité des systèmes :

• Les machines peuvent être sous Linux, Windows

• Perte de fiabilité :

• Les réseaux locaux sont moins fiables qu’un réseau dédié et les machines plus sujettes aux pannes.

• Perturbation par les utilisateurs


Les centres de calcul une architecture pour le calcul intensif et le

stockage de masse : le centre de calcul de la Doua


Centre de calcul de l’IN2P3

• IN2P3 : Institut National de la Physique Nucléaire et de la Physique des Particules

• Centre de calcul crée en 1986. Situé à Lyon sur le campus de la DOUA

• 35 ingénieurs pour la conception, la mise en place et l’exploitation de l’infrastructure informatique


Qui sont les utilisateurs ?

• 2500 utilisateurs réguliers issus de la physique des particules, nucléaire et astrophysique

• 50 expériences, dont :

- LHC : CERN à Genève 3 Po/an à partir de 2008

- D0 : FERMILAB à Chicago 150 To/an

- BABAR : SLAC en Californie 150 To/an


Architecture

• Architecture distribuée

• Stockage et calcul sont séparés

• Réseau local Gbits Ethernet


Cluster

• 1000 processeurs (90% Linux Redhat 7.2)

• 500 KSpecInt2000 (P3 1GHz = 400 SpecInt2000)

• Soumission de job : BQS

• Calcul parallèle


Stockage sur bande

• 6 silos gérant

36000 cartouches

• 720 To avec

cartouche 20 Go

• Données accessibles par HPSS


Espace occupé sur serveur

• Serveur AFS 3 To

• Montage NFS1,5 To

• Cache HPSS6 To

• Serveur Objectivity20 To

• Capacité totale 60 To


Réseau

• Hébergement d’un nœud Renater International NRI

• Très bonne connectivité

• Domaine in2p3.fr


La bio-informatique au centre de calcul de la Doua

• Biométrie évolutive - CPU pour calcul d’arbre de philogénie

• Prédiction de structure de protéine- CPU pour comparaison de séquences

• Aide au diagnostic pour dépistage cancer du sein- STOCKAGE des images et des métadonnées

• Recherche des facteurs génétiques impliqués dans la polyarthrite rhumatoïde - CPU pour identifier les régions candidates


Conclusion

• Le CC-IN2P3 est un centre multi-services :

- Calcul, stockage de masse

- Réseau à haut-débit, User Support

- Service annexe : Hébergement de service web (SFP,…), webcasting et

visioconférence Base de donnée, informatique administrative (DSI du

CNRS

Les environnements de programmation parallèle


Logiciels

• gestionnaire de batch/ressources

• Compilateurs

• MPI, OpenMP : bibliothèques

• outils de trace et de debug

• outils de déploiement et d ’administration

• systèmes de fichiers

• image unique de système


gestionnaire de batch/ressources

• gestionnaire de batch

• Logiciel coordonnant l’activité des nœuds d’une architecture distribuée

• Responsable de l’ordonnancement effectif, et du partage des ressources entre utilisateur

• Fournit une abstraction d’un ensemble de queues dans lesquelles sont mises en attente les applications des utilisateurs

• PBS, BQS, Mosix, Sun Grid Engine …


Programmation parallèle et répartie

• Conception

• Modélisation

• Algorithmique

• Langage

• Compilation

• Exécution

• Gestion d’activités

• Communications

• Mise au point

• Régulation de charge

• Gestion de données

• Sécurité

• …

Application

Programme parallèle

Proc. 0 Proc. 1 Proc. 2 Proc. 3


Supports et environnements d’exécution (1)

• Pour les utilisateurs et leurs applications

• Abstractions de haut niveau

• Portabilité

• Efficacité !

Support d’exécution

Grappes, grilles, machines parallèles, réseaux,…

Systèmes d’exploitation (OS)

Interface de programmation (API)

Applications


Supports et environnements d’exécution (2)

• Etendre et spécialiser les OS

• Centralisés et complétés pour le “distribué”

• Nouveaux modèles (tâches, communication, fichiers,…)

• Exemple: Stockage de fichiers, réplication, cache, …

Support d’exécution

Grappes, grilles, machines parallèles, réseaux

Systèmes d’exploitation (OS)

Interface de programmation (API)

Applications


Plan : Les paradigmes systèmes distribués grande échelle et de grille

• LDAP• Les systèmes peer to peer• Internet computing• Metacomputing• Grille de service• Grille ASP• Grille de calcul• Grille de données


Pourquoi vous parler de LDAP ?

• Des qu’on passe d’une échelle locale à une échelle plus large, apparaît le besoin de centraliser les connaissances à propos des ressources qui sont à disposition

• LDAP est un protocole standardisé d’annuaire, utilisée dans la plupart des entreprises qui ont au moins plusieurs agences

• LDAP est utilisé comme protocole de communication dans plusieurs produits d’annuaires (Active Directory de Microsoft, Novell Directory Server (NDS), Sun One)


LDAP• Lightweight Directory Access Protocol

• A l’origine un projet de l’Université du Michigan

• Popularisé par Netscape

• Normalisé par l’IETF• LDAP v2 : RFCs 1777 à 1779, RFC 1798, RFC 1960• LDAP v3 Core : RFCs 2251 à 2256• LDAP C API : RFC 1823• 3 groupes de travail : LDAPEXT, LDUP, LSD

• Initialement: version «light» de DAP sur TCP/IP

• Evolution vers un service d’annuaire complet• communications serveur/serveur, sécurité…

• Acceptation quasi globale comme protocole d’accès à un annuaire ...


LDAP

• On parle d’annuaire pour un système d’information permettant de stocker des données relativement statiques sur un grand nombre d’entités (ressources, utilisateur)

• Structure arborescente

• Standard de communication pour l’interrogation d’un annuaire

• Implémentation : open LDAP, Active Directory


Problématiques

• Au sein des Fortune 500, il existe en moyenne plus de 150 référentiels stockant des données sur les composants du système d’information (source Gartner Group)

UtilisateursUtilisateurs• ComptesComptes• PrivilègesPrivilèges• ProfilsProfils• StratégiesStratégies

ApplicationsApplications• ConfigurationConfiguration• SécuritéSécurité• ParamètresParamètres• StratégiesStratégies• DonnéesDonnées

PostesPostes• ProfilsProfils• RéseauRéseau• StratégiesStratégies

ServeursServeurs• ProfilsProfils• RéseauRéseau• ServicesServices• ImprimantesImprimantes• PartagesPartages• StratégiesStratégies

InternetInternet

FirewallFirewall• ConfigurationConfiguration• SécuritéSécurité• Stratégie VPNStratégie VPN

RéseauRéseau• TéléphonieTéléphonie• ConfigurationConfiguration• QoSQoS• SécuritéSécurité

MessagerieMessagerie• Boîtes aux lettresBoîtes aux lettres• StratégiesStratégies• Carnets d’adressesCarnets d’adresses

AnnuairesAnnuaires• UtilisateursUtilisateurs• PostesPostes• ServeursServeurs

Accès à l’information ?Accès à l’information ?Administration ?Administration ?

Accès à l’information ?Accès à l’information ?Administration ?Administration ?


WindowsWindows20002000

WindowsWindows20002000RessourcesRessourcesRessourcesRessources

KerberosKerberos

RADIUSRADIUS

X.509/PKIX.509/PKI

CertificatsCertificats

AuthentificationAuthentificationAutorisationAutorisation

Active DirectoryActive Directory

Référentiel de sécurité unique

IntranetIntranet

ExtranetExtranetTickets KerberosTickets Kerberos

• Windows 2000 supporte plusieurs modèles d’authentification et un modèle d’autorisation unique

• Active Directory fournit un point focal d’administration, des services de certificats et un serveur de clés Kerberos

• Facilite la liaison des Intranets & Extranets


Administration des ressources

DomaineDomaineDomaineDomaine

UtilisateursUtilisateursUtilisateursUtilisateurs MachinesMachinesMachinesMachines ApplicationsApplicationsApplicationsApplications

FinanceFinanceFinanceFinance RHRHRHRH

PériphériquesPériphériquesPériphériquesPériphériques

Déployer l’application Ressources Déployer l’application Ressources HumainesHumaines

Déployer l’application Ressources Déployer l’application Ressources HumainesHumaines

Déléguer l’administration des Déléguer l’administration des utilisateurs au Helpdeskutilisateurs au Helpdesk

Déléguer l’administration des Déléguer l’administration des utilisateurs au Helpdeskutilisateurs au Helpdesk

Donner aux personnes de RH Donner aux personnes de RH accès au menu ‘Modif Salaire’ accès au menu ‘Modif Salaire’

de l’appli de gestion des de l’appli de gestion des ressources humainesressources humaines

Donner aux personnes de RH Donner aux personnes de RH accès au menu ‘Modif Salaire’ accès au menu ‘Modif Salaire’

de l’appli de gestion des de l’appli de gestion des ressources humainesressources humaines


Réplique ARéplique A

BostonBoston

SeattleSeattle

ChicagoChicago

SeattleSeattle

Réplique CRéplique C

BostonBoston

BostonBoston

ChicagoChicago

SeattleSeattle

Disponibilité globale des données

• Chaque réplique stocke une copie des données du domaine

• Chaque réplique peut résoudre une requête

• Support idéal des données d’identité des utilisateurs…

RéplicationRéplication RéplicationRéplication

Domaine d’entrepriseDomaine d’entreprise

Réplique BRéplique B

BostonBoston

ChicagoChicago

ChicagoChicago

SeattleSeattleTrouver:Trouver:‘‘Tous lesTous les Dupont’ Dupont’

Trouver:Trouver:‘‘Tous lesTous les Dupont’ Dupont’

RéponseRéponseRéponseRéponse


Intégration des applications



FinanceFinanceFinanceFinance RHRHRHRH


Application RH: Stockage du Application RH: Stockage du profil métier de l’utilisateurprofil métier de l’utilisateur

Application RH: Stockage du Application RH: Stockage du profil métier de l’utilisateurprofil métier de l’utilisateur

Exchange: stockage des Exchange: stockage des informations de B.A.L. de informations de B.A.L. de

l’utilisateurl’utilisateur

Exchange: stockage des Exchange: stockage des informations de B.A.L. de informations de B.A.L. de

l’utilisateurl’utilisateur


Active Directory au cœur de l’entrepriseUtilisateursUtilisateurs• Informations compteInformations compte• PrivilègesPrivilèges• ProfilsProfils• StratégiesStratégies

ClientsClients• Profils de gestionProfils de gestion• Infos réseauInfos réseau• StratégiesStratégies

ServeursServeurs• Profils de gestionProfils de gestion• Infos réseauInfos réseau• ServicesServices• ImprimantesImprimantes• Ressources partagéesRessources partagées• StratégiesStratégies

Point Central de GestionPoint Central de Gestion• Utilisateurs & ressourcesUtilisateurs & ressources• SecuritéSecurité• Délégation Délégation • StratégieStratégie

ActiveActiveDirectoryDirectory


Stockage hiérarchique Stockage hiérarchique des donnéesdes données

• Création d’arborescences possibleCréation d’arborescences possible• S’adapter à la structure de l’organisationS’adapter à la structure de l’organisation

Services de l’Active Directory

Modélisation des Modélisation des éléments sous forme éléments sous forme

d’objetsd’objets

• Ressources vues comme des objetsRessources vues comme des objets• Dotés d’attributs définis ds 1 SchémaDotés d’attributs définis ds 1 Schéma

Interrogation soupleInterrogation souple• Modes d’accès aux données multiplesModes d’accès aux données multiples• Optimisé pour traiter les requêtesOptimisé pour traiter les requêtes

Contrôle d’accès Contrôle d’accès évolué et granulaireévolué et granulaire

• Sécurisation au niveau des attributsSécurisation au niveau des attributs• Délégation d’administrationDélégation d’administration

Réplication multi-Réplication multi-maîtremaître

• Serveurs accessibles en lecture/écritureServeurs accessibles en lecture/écriture• Optimisé pour un fonctionnement WANOptimisé pour un fonctionnement WAN


MachinesMachinesMachinesMachines ApplicationsApplicationsApplicationsApplicationsPériphériquesPériphériquesPériphériquesPériphériques

Stockage hiérarchique


UtilisateursUtilisateursUtilisateursUtilisateurs

MarketingMarketingMarketingMarketing RHRHRHRH

= Organizational Unit= Organizational Unit

= Objet= Objet

• L’arborescence fournie un support pour modéliser, chercher et administrer les informations au moyen de stratégies


UUUU UUUU UUUU

AAAA AAAA AAAA

Modélisation sous forme d’objets



CCCC CCCC CCCC

MarketingMarketingMarketingMarketing


DDDD DDDD DDDD

Object Class: Object Class: UserUser• Name: Name: Jean DupontJean Dupont• Email: Email: [email protected]@abc.fr• Phone: Phone: 555-1234555-1234

Object Class: Object Class: UserUser• Name: Name: Jean DupontJean Dupont• Email: Email: [email protected]@abc.fr• Phone: Phone: 555-1234555-1234

Object Class: Object Class: ComputerComputer• Name: Name: JEAND01JEAND01• IP Address: IP Address: 12.34.56.7812.34.56.78• OS: OS: Windows 2000Windows 2000

Object Class: Object Class: ComputerComputer• Name: Name: JEAND01JEAND01• IP Address: IP Address: 12.34.56.7812.34.56.78• OS: OS: Windows 2000Windows 2000


Méthodes d’accès à l’information

LDAP Version 3LDAP Version 3

• Standard de l’industrie des protocoles Standard de l’industrie des protocoles d’accès aux annuairesd’accès aux annuaires

• Support natif Support natif • Expose l’ensemble des fonctionnalitésExpose l’ensemble des fonctionnalités


Limite du domaineLimite du domaine

WANWAN

Site de SeattleSite de Seattle

DC 2DC 2

DC 1DC 1

DC 3DC 3

Site de BostonSite de Boston

DC 7DC 7

DC 9DC 9

DC 8DC 8

Site de ChicagoSite de ChicagoDC 5DC 5

DC 4DC 4

DC 6DC 6Ajout Utilisateur: Ajout Utilisateur: BillBill

Ajout Utilisateur: Ajout Utilisateur: BillBill

RéplicationRéplication


LDAPUtilisation de LDP


LDAP : quelques mots sur LDIF

• LDIF est le format le plus répandu de stockage de LDAP.

• Format texte, assez lisible

• Autant de versions des objets présents que d’implémentation de ldap.


Exemple de LDIF:

# Define top-level entry dn: dc=mycompany,dc=com objectClass: dcObject dc:mycompany # Define an entry to contain people # searches for users are based on this entry dn: ou=people,dc=mycompany,dc=com objectClass: organizationalUnit ou: people # Define a user entry for Janet Jones dn: uid=jjones,ou=people,dc=mycompany,dc=com objectClass: inetOrgPerson uid: jjones sn: jones cn: janet jones mail: [email protected] userPassword: janet


LDIF : exemple (suite)

# Define an entry to contain LDAP groups # searches for roles are based on this entry dn: ou=groups,dc=mycompany,dc=com objectClass: organizationalUnit ou: groups # Define an entry for the "tomcat" role dn: cn=tomcat,ou=groups,dc=mycompany,dc=com objectClass: groupOfUniqueNames cn: tomcat uniqueMember: uid=jjones,ou=people,dc=mycompany,dc=com uniqueMember: uid=fbloggs,ou=people,dc=mycompany,dc=com # Define an entry for the "role1" role dn: cn=role1,ou=groups,dc=mycompany,dc=com objectClass: groupOfUniqueNames cn: role1 uniqueMember: uid=fbloggs,ou=people,dc=mycompany,dc=com

Cas pratique : utilisation de java pour l’authentification et l’autorisation en

Java avec JAAS


Plan

• Les différents aspects de la sécurité JAVA.

• Évolution de la sécurité depuis JAVA 1.0

• La protection de l’utilisateur.

• La protection du système (JAAS).• Authentification• Autorisation• Étude détaillé• Démo


La sécurité JAVA.

• Aspect fondamentale, dès la première version.

• Principe de Sand-Box.

• Évolution => Granularité très fine:

• Définition de stratégies de sécurité.


La sécurité JAVA.

• Nouveaux dans JDK 1.4 :

• JCE 1.2 (Java Cryptography Extension).

• JSSE (Java Secure Socket Extension).

• JAAS (Java Authentification & Autorisation Service).


Évolution de la sécurité JAVA

• JAVA 1.0 (1995)

• But : Protéger l’utilisateur du système.

• Concernait principalement les applets.

• Apparition du principe « SandBox » .

• Un code non approuvé est limité • Pas d’accès aux systèmes de fichiers.• Pas d’accès réseaux.



La SandBox 1.0



• JAVA 1.1 (1996)

• Raffinement du modèle de SandBox.• Possibilité de «signer» une applet.• Le code approuvé possède alors les même droits qu’un code local.

• Problème : Violation du principe du « moindre privilège ».



• JAVA 1.2 (1997)

• Évolution majeure en terme de sécurité

• Possibilité de définir une politique de sécurité par l’intermédiaire des fichiers « policy ».


La protection de l’utilisateur



• Quelques exemples de tout cela :

- Une applet critique exécutée localement fonctionne sans problème.

C:\> java WriteFileApplet




• Une applet critique exécutée localement fonctionne sans problème.

• Si on ajoute un « Security Manager », rien ne va plus.

C:\>java -Djava.security.manager WriteFileApplet




- Un outil permettant d’écrire facilement des fichiers « policy » : Policytool.exe




• Avec un fichier de configuration, le SecurityManager ne pose plus de problème.

grant { permission java.io.FilePermission "<<ALL FILES>>", "write";};

java -Djava.security.manager -Djava.security.policy=all.policy WriteFileApplet




• Un dernier exemple avec un browser.

• Il est plus difficile de spécifier le fichier « policy » à utiliser…..


Java Authentification & Autorisation

• But : • Protéger le système de l’utilisateur.

• Comment :• Créer un objet partagé par l’authentification et l’autorisation.

• Étendre le modèle de sécurité standard ( security policy) pour gérer cet objet.

AuthentificationAuthentification

AutorisationAutorisationSubjectSubject Interactions



• Comment ça marche ?

1. Authentification1. On « branche » des modules de connexion à une entité.

2. Si l’utilisateur « passe » tout ces modules, il acquière alors une identité virtuelle.

2. Autorisation1. Il peut alors tenter d’exécuter des actions « critiques ».

2. Ces actions sont soumises au système de restrictions d’accès.


JAAS : L’authentification

• Les classes importantes pour l’identification:

• Subject:• Représente un individu ou une organisation avec plusieurs identités de principal ; les décisions

en matières d’autorisation sont prises en fonction d’un sujet authentifié.

• Logincontext:• Fournit une API de base, permettant aux sujets de se connecter/déconnecter du système.

• LoginModule:• Définit l’interface que les fournisseurs de services d’authentifications qui supportent JAAS

doivent implémenter.

• Configuration:• Encapsule l’entité utilisée pour configurer une application avec des connexion particulièrs.



• Les classes importantes pour l’identification:

• CallbackHandler:• Définit l’interface à implémenter par les applications qui souhaitent autoriser le

service d’authentification à leur passer des informations.

• Callback:• Définit une interface de marqueurs implémentée par les objets qui sont passés à

une implémentation CallbackHandler. L’objet Callback contient les données à passer à l’application.

• PrivilegedAction:• Les actions critiques y sont stockées


JAAS : L’authentification (chronologie)

new LoginContext( "Nom de configuration", MyCallbackHandler);

LoginContextLoginContext

ConfigurationConfiguration

Configuration.jaas (liste des modules





Configuration.jaas (liste des modules)

LoginModule 1LoginModule 1






Configuration.jaas (liste des modules)



Login( )

USERCallBackHandlerCallBackHandler

Login( )

Login( )






Login( )


SubjectSubject

Droits.policy






Login( )


SubjectSubject DoAsPrivileged( ) PrivilegedActionPrivilegedAction


Focus sur les CallbackHandler

• Le but de l’authentification est de créer un objet « Subject ».

• Pour communiquer, les objects utilisent des Callback.

• Ces Callback sont gérés par les CallbackHandler.



- Le dialogue est délégué :


LoginModuleLoginModule

CallbackHandlerCallbackHandler

USERUSER

CallBack[]CallBack[]



• Les callback sont utilisés pour compléter le « Subject ».


LoginModuleLoginModule

CallbackHandlerCallbackHandler

CallBack[]CallBack[]

SubjectSubject GetSubject()


Focus sur les Callback

• Les differents types de Callbacks :

• Language Callback

• Name Callback

• Password Callback

• TextInput Callback

• TextOutput Callback

• Choice Callback

• Confirmation Callback



• Le fichier de configuration des modules de connexion:

configuration.jaas

Nom de configuration {

JndiLoginModule Requisite

Krb5LoginModule Sufficient

NTLoginModule Optional

UnixLoginModule Optional

SampleLoginModule Required debug=true;

};

Autre type d’analyse{AnalyseRetineModule Required

};



• Les mots clés du fichier .jaas :

• Required : non bloquant

• Requisite : bloquant

• Sufficient : bloquant

• Optional : non bloquant



• Exemple :

Module Criterion Pass/Fail

SampleLoginModule Required OK

NTLoginModule Sufficient !OK

SmartCard Requisite OK

Kerberos Optional !OK

Overallauthentication

OK



• Exemple :

Module Criterion Pass/Fail

SampleLoginModule Required !OK

NTLoginModule Sufficient OK

SmartCard Requisite

Kerberos Optional

Overallauthentication

OK



• Comment définir l’emplacement du fichier .jaas ?

• Ligne de commande : • Java –Djava.security.auth.login.config=<location>

• Modification du fichier java.security :• Login.config.url.1=<location>


JAAS : L’ autorisation

• Une fois l’utilisateur reconnu...

• JAAS étend le modèle de sécurité JAVA2.

• On définit donc une politique de sécurité pour un utilisateur spécifique ou pour un domaine.



Pour cela, on utilise des fichiers .policy :

Exemple :

grant Principal Administrateur "root" { permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "user.home", "read"; permission java.io.FilePermission "c:\\foo.txt", "write,read";};

grant Principal Etudiant {permission java.io.FilePermission "c:\\foo.txt", "read";};



• Une fois identifié, le «Subject » utilise des « PrivilegedAction ».

• On lance le traitement avec la méthode static suivante :

Static Subject.doAsPrivileged(SujetCourant s, PrivilegeAction x);



• Exemple :

public class SampleAction implements PrivilegedAction {

public Object run() {

try{ FileWriter writer = new FileWriter(new File("c:/foo.txt"));

writer.write("blabla"); }catch (IOException ioe){}

return null; }}



• Comment définir la source du fichier .policy ?

• Ligne de commande : • Java –Djava.security.policy=<location>

• Modification du fichier java.security :• auth.policy.url1=<location>


JAAS : Mise en place

• Mise en place d’une authentification JAAS :

• Implémenter les interfaces suivants :• CallBackHandler

• Handle()

• LoginModule• initialize()• login()• commit()• Abort()


JAAS : Mise en place

• Mise en place d’une authentification JAAS :

• Implémenter les interfaces suivants :

• Principal• getName()

• PrivilegedAction• run()



• Où trouver JAAS ?

• API d’extension pour JAVA 1.3

• Incorporé à JAVA 1.4

• Incorporé aux spécifications J2EE 1.3

Cas pratique : sécuriser une application via JAAS par un LDAP


Example

import javax.security.auth.*;import javax.security.auth.login.*;

public class CountFiles { public static void main(String[] args) { LoginContext lc = null; try { lc = new LoginContext(“CountFiles”); } catch (LoginException le) { // handle it }

try { lc.login(); } catch (Exception e) { // login failed -- handle and exit }

Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); }}


Example


public class CountFiles { public static void main(String[] args) { LoginContext lc = null;LoginContext lc = null; try {try { lc = new LoginContext(“CountFiles”);lc = new LoginContext(“CountFiles”); } catch (LoginException le) {} catch (LoginException le) { // handle it// handle it }}



• Establish a context by which a user can be authenticated

• Argument references a line in a config file (later)


Example



try {try { lc.login();lc.login(); } catch (Exception e) {} catch (Exception e) { // login failed -- handle and exit// login failed -- handle and exit }}


• Authenticate the user following steps in configuration file


Example




Object o = Subject.doAsObject o = Subject.doAs (lc.getSubject(),(lc.getSubject(), new CountFilesAction());new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); }}

• A Subject represents an authenticated user

• Uses an array of Principal objects

• A Principal is an identifying characteristic• Username• Group• Database username

• doAs attempts to execute the run method of the named object on behalf of the Subject


An example action

import java.security.*;

class CountFilesAction implements PrivilegedAction { public Object run() { File f = new File(File.separatorChar+”files”); File farray[] = f.listFiles(); return new Integer(farray.length); }}

• Note partitioning of development into checks and actions


Configuration 1. Login

CountFiles { com.sun.security.auth.module.LDAPLoginModule required;}

• pluggable:

loaded dynamically, poss 3rd party, so code is not tied to a particular type of authentication, and can introduce new ones as technology improves (eg retinal scans, fingerprints)

• stackable:

more than one can be specifiedeach returns one or more Principals


Configuration 1. Login

CountFiles { com.sun.security.auth.module.SolarisLoginModule required; com.sun.security.auth.module.JndiLoginModule optional;}

required: user must pass authentication

sufficient: if user passes this, no others need to be called

requisite: if user passes, others called but don’t need to pass

optional: user allowed to fail this (but must pass at least one!)

Cas pratique : Utilisation de LDAP pour une authentification/autorisation avec

JAAS avec JBoss

Introduction aux Entreprise Java Beans


Problème

• Construire des applications pour entreprises

• Sures

• Sécurisées

• Supportant la montée en charge (scalable)

• Disponibles

• Favorisant la réutilisation

• Maintenables et extensibles

• Pour moins cher


Moyen

• Utiliser une architecture distribuée

• Plusieurs tiers

• Les clients (front end)

• Les sources de données (back end)

• Un ou plusieurs tiers entre eux pour• Implanter les nouveaux services• Intégrer les différentes sources de données• Masquer la complexité de l’entreprise aux clients


Architecture à composants distribués

• Permettent la construction d’applications multi-tiers

• Objectif

• Simplifier la création d’application à base d’objets distribués.

• Promouvoir la programmation par composant pour le coté serveur


Composant logiciel

• Doit permettre la construction de logiciel par composition

• Exporte des propriétés et des méthodes

• Peut être configuré de façon externe

• Un composant peut être réutilisable à différent degré

• Composants connus :

• COM/DCOM

• Java Beans

• Enterprise Java Beans

• Composants Corba


Objet distribué (rmi)


Middleware Explicite

transfer(Account account1, Account account2, long amount) {

// 1: Call middleware API to perform a security check// 2: Call middleware API to start a transaction// 3: Call middleware API to load rows from the

database// 4: Subtract the balance from one account, add to the

other// 5: Call middleware API to store rows In the database// 6: Call middleware API to end the transaction}


Middleware implicite


Architecture multi-tiers


Les solutions existantes

• Microsoft DNA (Distributed interNet Applications Architecture)

• Windows NT + DCOM + MSMQ (message queue) + MTS (transactions) + Wolfpack (clustering) + IIS (web server)+ MMC (administration et déploiement)

• Sun J2EE (spécification)

• OMG Corba (specification) et les composants Corba.


J2EE

• Définit une architecture standard incluant

• Un modèle de programmation (application multi-tiers, client légers)

• Une plate-forme (ensemble de spécifications et de politiques requises)

• Un ensemble de test de compatibilité

• Une implantation de référence


Architecture d’une application J2EE


La plateforme J2EE

• EJB : définit la façon dont les composant doivent être écrit et le contrat qu’ils doivent respecter avec le serveur d’application

• RMI : communication inter procédés

• JNDI : service de nommage

• JDBC : connection vec les bases de données

• JTA : service de transaction

• JMS : service de messagerie

• JSP : servlet et Java Server Page adapté à la construction de composant réseau

• Java IDL : permet l’intégration avec d’autres langages (en particulier à travers CORBA)

• JavaMail

• Connectors : intégration à des systèmes d’information existant

• XML


Les technologies


Enterprise Java Beans (EJB)

• Modèle client/serveur distribué

• Code exécuté sur le serveur

• proche des données

• serveur souvent plus puissant que le client

• Code localisé sur le serveur

• changer le code du serveur ne change pas le code du client

• Un EJB est juste une collection de classes Java et d’un fichier XML. Les classes Java suivent un certains nombre de règles et fournissent des callbacks comme définis dans l’environnement J2EE et les spécifications EJB.


Container EJB

• Un container EJB est un environnement d’exécution pour un composant EJB.

• Un EJB s’exécute sur un container EJB.

• Un container EJB s’exécute par un serveur d’applications et prend la responsabilité des problèmes au niveau système

• Le container EJB gère le cycle de vie de l’EJB.

• Le container EJB fournit aussi un nombre de services additionnels

• Gestion de la persistance

• Transactions

• Sécurité

• Cadre de travail

• Dimensionnement

• Portabilité

• Gestion des erreurs


Beans entité

• Un bean entité est un objet persistant

• Un bean entité peut avoir plusieurs clients

• Bean Managed Persistance (BMP) : le container EJB est responsable de la persistance du bean.

• Container Manager Persistance (CMP) : le bean est responsable de sa propre persistance.


Beans session

• Un bean session pour chaque client

• Il y a deux types de beans session

• sans état• pas d ’état entre les invocations• rapide et efficace

• avec état• maintient les états entre les invocations• persistance limitée


Structure EJB

• Interface home

• fournit un moyen pour le client EJB de récupérer une instance d’un EJB

• Interface distante

• expose les méthodes que le client EJB peut utiliser

• Code EJB

• implémente l’interface distante et l’interface EJB approprié (SessionBean ou EntityBean par exemple)


Les Enterprise JavaBeans

• Spécification d’une architecture permettant la création d’applications distribuées

• 2 versions• 1.1 : la plus courante• 2.0 : la plus récente

• Implantations de la spec : • BEA WebLogic, Jonas, Borland Appserver, IBM Websphere, Jboss (open

source)

• Composant développé pour être exécuté sur un serveur d’EJB

• Ne pas confondre avec un java bean


Objectifs des EJB

• Fournir une plate-forme standard pour la construction d’applications distribuées en Java

• Simplifier l’écriture de composants serveurs

• Portabilité

• Considérer le développement, le déploiement et l’exécution des applications


Division des responsabilités

• Le fournisseur de bean

• Produit les composants métier

• Le fournisseur de conteneur EJB

• Fournit l’environnement permettant l’exécution des beans

• Le fournisseur de serveur EJB

• Fournit l’environnement d’exécution pour un ou plusieurs conteneurs

• L’assembleur d’application

• Le déployeur (installateur)

• L’administrateur


Les Enterprise Beans

• Composants qui peuvent être déployés dans un environnement multi-tiers et distribué.

• Exposent une interface qui peut être appelé par ses clients

• Configurés de façon externe

• L’interface et l’implantation du bean doivent être conforme à la spécification EJB

• Les clients peuvent être

• Un servlet

• Une applet

• Un autre bean


Les types de Beans

• Session Beans : contiennent la logique métier de l’application

• Stateful session bean

• Stateless session bean

• Entity Beans : contiennent la logique de gestion des données persistantes

• Message bean : contiennent la logique orientée message


Session Bean

• Fournit un service à un client

• Durée de vie limitée à celle du client

• Effectue des calculs ou des accès à une base de donnée

• Peut être transactionnel

• Non recouvrable

• Peuvent être sans état ou conversationnel (stateless ou stateful)


Exemple de Session bean

public class CartBean implements SessionBean {

String customerName;

Vector contents;

public void ejbCreate(String person) throws CreateException {

… initialisation du bean

}

// business method

public void addBook(String title) { … // code de la méthode}

public void removeBook(String title) throws BookException {… }

public Vector getContents() {…}

// methodes appelées par le conteneur

public void ejbRemove() {}

public void ejbActivate() {}

public void ejbPassivate() {}

public void setSessionContext(SessionContext sc) {}

}


L’interface

L’interface décrit le contrat avec les clients

public interface Cart extends EJBObject {

public void addBook(String title) throws RemoteException;

public void removeBook(String title) throws BookException, RemoteException;

public Vector getContents() throws RemoteException;

}


La factory

• Définit les méthodes permettant de créer, trouver et détruire des objets EJB

public interface CartHome extends EJBHome {

Cart create(String person) throws RemoteException, CreateException;

}


Le descripteur de déploiement

• Fournit les informations nécessaires au déploiement dans le conteneur et pour la configuration des intercepteurs

<enterprise-beans>

<session>

<display-name>CartEJB</display-name>

<ejb-name>CartEJB</ejb-name>

<home>CartHome</home>

<remote>Cart</remote>

<ejb-class>CartBean</ejb-class>

<session-type>Stateful</session-type>

<transaction-type>Container</transaction-type>

<security-identity>

<description></description>

<use-caller-identity></use-caller-identity>

</security-identity>

</session>

</enterprise-beans>


Déploiement (suite)

<assembly-descriptor>

<method-permission>

<role-name>user<role-name/>

<method>


<method-intf>Remote</method-intf>

<method-name>getContents</method-name>

<method-params />

</method>

</method-permission>

<container-transaction>

<method>


<method-intf>Remote</method-intf>

<method-name>getContents</method-name>

<method-params />

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

</ejb-jar>


Le client

public class CartClient {

public static void main(String[] args) {

Context initial = new InitialContext(); // context JNDI

CartHome home = initial.lookup("java:comp/env/ejb/SimpleCart");

// Recherche de l’interface de la factory

// Creation de l’objet session

Cart shoppingCart = home.create("Duke DeEarl« xs);

// appel de quelques business méthodes

shoppingCart.addBook("The Martian Chronicles");

Vector bookList = new Vector();

bookList = shoppingCart.getContents();

shoppingCart.removeBook("Alice in Wonderland");

// suppression de l’objet session

shoppingCart.remove();

}


Les entity beans

• Implantation d’objets métiers persistants (client, compte,…)

• Persistance gérée par

• Les conteneurs (CMP)

• Le bean lui-même (BMP)

• Le conteneur gère également les transactions et la sécurité pour le composant.

• Utile pour gérer les accès concurrents à des données persistantes.


Exemple d’entity bean (CMP)

public class BookEJB implements javax.ejb.EntityBean {

public String author;

public String titlel;

public int price;

private EntityContext context;

public String getTitle() {return title;}

public String getAuthor() {return author;};

public int getPrice() {return price;}

public void setPrice(int _price)

{price=_price;}

public String ejbCreate (String _author, String _title) throws CreateException {

author=_author;

title=_title;

price=0;

return null;

}

…

…

// Méthodes requises par le conteneur

public void ejbPostCreate(String _author,String _title) { }

public void ejbRemove() { }

public void ejbLoad() { }

public void ejbStore() {}

public void setEntityContext(EntityContext context) {

this.context = context;}

public void unsetEntityContext() {

context=null; }

public void ejbActivate() { }

public void ejbPassivate() { }

}


Home interface

public interface BookHome extends EJBHome

{

public Book create(String id, String url) throws RemoteException, CreateException;

public Book findByPrimaryKey (String id) throws RemoteException, FinderException;

public Collection findAll() throws RemoteException, FinderException;

Public Collection findByAuthor(String author) throws RemoteException, FinderException;

}


Interface de l’Entity Bean

public interface Book extends EJBObject {

public String getAuthor() throws RemoteException;

public String getTitle() throws RemoteException;

public int getPrice() throws RemoteException;

public void setPrice(int mode) throws RemoteException;

}


Le descripteur de l’entity bean

<entity>

<display-name>Book</display-name>

<ejb-name>Book</ejb-name>

<home>BookHome</home>

<remote>Book</remote>

<ejb-class>BookEJB</ejb-class>

<persistence-type>Container</persistence-type>

<prim-key-class>java.lang.String</prim-key-class>

<reentrant>False</reentrant>

<cmp-field><field-name>title</field-name></cmp-field>

<cmp-field><field-name>author</field-name></cmp-field>

<cmp-field><field-name>price</field-name></cmp-field>

<primkey-field>title</primkey-field>

<query>

<description></description>

<query-method>

<method-name>findByAuthor</method-name>

<method-params><method-param>java.lang.String</method-param></method-params>

</query-method>

<ejb-ql>select distinct object(b) from Book b where b.author=?1</ejb-ql>

</query>

</entity>


Message Driven Bean (ejb2.0)

• Intégration des EJB et de JMS

• Interactions asynchrones

• Utilisé pour réagir à des messages JMS

• Stateless bean

• Une seule méthode dans l’interface

• onMessage()


Exemple de message bean

<message-driven>

<ejb-name>ValueContainerListener</ejb-name>

<ejb-class>hero.container.ValueContainerListener</ejb-class>

<message-selector>JMSType='ValueContainer'</message-selector>

<transaction-type>Container</transaction-type>

<ejb-ref>

<description>Value Container Home</description>

<ejb-ref-name>ejb/valuecontainer</ejb-ref-name>

<ejb-ref-type>Entity</ejb-ref-type>

<ejb-link>ValueContainer</ejb-link>

<home>hero.container.ValueContainerHome</home>

<remote>hero.container.ValueContainer</remote>

</ejb-ref>

<message-driven-destination>

<destination-type>javax.jms.Topic</destination-type>

<subscription-durability>NonDurable</subscription-durability>

</message-driven-destination>

</message-driven>


EJB Object


Paquetage d’application


Déploiement

• Création d’un paquetage contenant

• Les classes des beans

• Le fichier de description

• Les fichiers de configuration spécifique au serveur

• D’autres librairies

• Mise en place dans le serveur (outils spécifique ou déploiement à chaud)


Intérêt des EJB

• Simplicité de l’écriture des composants

• Mais le design est plus complexe

• Portabilité des composants

• A l’exception des adaptations des serveurs

• Réutilisation/Composition

• Il faut quand même programmer

• Indépendance par rapport aux vendeurs


Bénéfices d’un serveur d’EJB

• Gestion automatisée des stocks de ressources

• Gestion automatisée du cycles de vie des composants

• Gestion de la concurrence

• Scalabilité

• Fonctionnalités déclaratives

• Disponibilité et tolérance aux pannes

• Modèle d’objet distribué

• …


Limites actuelles (variables selon les serveurs)

• Maturité de la spécification, des technologies,…

• Moins vrai depuis la version 2.0

• Performances ?

• Environnements de développement

• Complexité du design

• Expérience des développeurs


Bibliographie et sources des schémas

• J2EE Specification

• Java.sun.com/products/j2ee

• Enterprise Java Beans Specification 1.1 et 2.0

• Java.sun.com/products/ejb

• Mastering Enterprise JavaBeans and the Java 2 Platform Enterprise Edition – Ed Roman – Wiley Computer publishing 1999

• www.theserverside.com

• java.sun.com/j2ee/tutorial

• www.jboss.org (serveur Open Source)

• Support de cours de Didier Donsez (université de Valenciennes)

• J2EE blueprints (java.sun.com)

• Mastering Enterprise JavaBeans II – Ed Roman -(www.theserverside.com)


Exemple d’application J2EE


Jboss - client

sampleApp {

// jBoss LoginModule

org.jboss.security.LDAPLoginModule required;

// Put your login modules that need jBoss here

};

• Idem que pour une application classique dans un fichier policy

Jboss - serveur

<application-policy name = « sampleServerApp">



<authentication>

<login-module code = "org.jboss.security.auth.spi.LDAPLoginModule"

flag = "required" />

</authentication>

</application-policy>

Cas pratique : Utilisation de LDAP pour une authentification/autorisation avec

JAAS avec Tomcat

Tomcat : présentation

Tomcat et les Servlets


Spécification J2EE

• Servlet, JSP

• JAX (JAX-P, JAX-B, JAX-R, JAX-RPC)

• JNDI, JMS

• EJB, JTA, JTS

• JavaMail, JDBC

• JMX, J2EE Connector, etc.


Application multi-tiers

L’application Web est décomposée en plusieurs

parties (tiers)


Conteneurs de Servlet

• Tomcat 4.1

• IronFlare Orion 1.5

• Jetty 4.1

• Caucho Resin 2.1

• Sun ONE 7.0

• IBM WebSphere 4.0

• BEA WebLogic 7.0


Tomcat

• Tomcat 4.1 (Catalina)

• Projet Apache (Apache Apache Httpd)

• Open source

• Implantation de référence de la spécification

• Spécification Servlet 2.3 et JSP 1.2(bientôt Servlet 2.4 et JSP 2.0)


Servlet & Conteneur

Le conteneur de servlets associe àdes URLs virtuels une servlet

Browser HTTP

Conteneur de Servlets

/admin/*

/vignette/*.html

/examples/*.html

servlet 1

servlet 2

Requête

Réponse


Répertoire de Tomcat

Organisation des répertoires de Tomcat

/bin/common/lib/conf/logs/server/lib/shared/lib/webapps

scripts startup & shutdown

jar utilisés par Tomcat (Ant, Servlet, etc.)

configuration: server.xml, web.xml, users.xml

fichiers de logs

fichiers jar propres à tomcat

fichiers jar communs à toutes les servlets

zone de déploiement


Configuration Tomcat

Le fichier server.xml

• Server Racine, spécifie le port de shutdown.

• ServiceAssocie des connecteurs à un engine.

• ConnectorIls correspondent à un point d’accès à un service,soit via un serveur soit en connexion directe.

• Engine correspond au conteneur de servlet en lui-même.

• Logger Ils effectuent la journalisation.

• HostDéclare où sont stockées les servlets pour un nom de machine.

• ContextChaque Context représente la configuration associée à un chemindans la hiérarchie


Un Connector point d’accès utilisable par un client :• port="8080"• minProcessors="5" • maxProcessors="75"• enableLookups="true" • acceptCount="100" • connectionTimeout="20000"

Le conteneur Engine• name="Standalone" • defaultHost="localhost"

Configuration Tomcat (2)

port d’écoute

nombre de threads minimum

nombre de threads maximum

DNS inverse

nombre de connections pendantes

Nom de l’host si pas HTTP 1.1



Le Logger effectue la journalisation des requêtes• prefix="catalina_log. "• suffix=".txt"• timestamp="true"

Le tag Host définit les paramètres pour un host virtuel• name="localhost" • appBase="webapps" • unpackWARs="true" • autoDeploy="true"



Gestion des associations entre un URI

et un chemin sur le disque

URI d’accès

Chemin d’accès des fichiers(relatif ou absolu par rapport à webapps)

Détection automatique des changementset rechargement si besoin

Un Context représente l’association entre un cheminsur le serveur (URI) et un chemin sur le disque

• path= "/examples"• docBase="examples"• reloadable="true"


Architecture d’une appli Web

Une application Web possède dans un repertoire lui-même dans webapps une architecture spécifique

*.html, *.jsp/WEB-INF/web.xml/WEB-INF/classes//WEB-INF/lib/

fichiers HTML

fichier de configuration (XML)

classes des servlets

fichiers jar des servlets

L’ensemble des fichiers et répertoire peut être mis dans un war (Web Archive)grâce à la commande jar. Le war est automatiquement dé-jarré s’il est placé

dans le répertoire webapps.


Configuration d’une appli Web

Le fichier web.xml

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

<web-app> <display-name>Mon application Web</display-name> <servlet> <servlet-name>maServlet</servlet-name> <servlet-class>fr.umlv.myservlet.MaServlet</servlet-class> </servlet>

<servlet-mapping> <servlet-name>maServlet</servlet-name> <url-pattern>*.test</url-pattern> </servlet-mapping>

<servlet-mapping> <servlet-name>maServlet</servlet-name> <url-pattern>/toto</url-pattern> </servlet-mapping></web-app>

nom de la servletnom de la servletnom de la servlet

URI d’accèsURI d’accès


Configuration d’une appli Web

Paramètres d’initialisation d’une servlet

<servlet> <servlet-name>maServlet</servlet-name> <servlet-class>fr.umlv.myservlet.MaServlet</servlet-class> <init-param> <param-name>parametre1</param-name> <param-value>valeur1</param-value> </init-param> <init-param> <param-name>parametre2</param-name> <param-value>valeur2</param-value> </init-param></servlet>

association name/value


Generic vs HTTP Servlet

Il existe deux types de servlets

• Les GenericServlet qui ne pré-suppose pas d’un protocole

• Les HttpServlet qui repondent à des clients par le protocole HTTP

GenericServlet est une classe du paquetage javax.servlet tandis queHttpServlet est une classe du paquetage javax.servlet.http


La synchronisation est gérée par l’objet Response

Cycle de vie d’une servlet

Le cycle de vie d'une servlet :

1. la méthode init() est appelée après le chargement ;

2. une méthode service() est appelée à chaque requête dans une nouvelle thread.

3. la méthode destroy() est appelée pour le déchargement.


HelloServlet

La méthode service() est appelée avec un objet requête et un objet réponse

import java.io.*;import javax.servlet.*;

public class HelloServlet extends GenericServlet {

public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException { PrintStream out = new PrintStream(response.getOutputStream()); out.println("Hello World!"); } public String getServletInfo() { return "Hello World Servlet"; } } L’objet réponse permet d’obtenir

le flux de sortie en écritureInformation textuelle sur la servlet


L’interface Request

L'interface ServletRequest permet de récupérer les paramètres de la requête :public abstract int getContentLength() public abstract String getContentType() public abstract String getProtocol() public abstract String getScheme() public abstract String getServerName() public abstract int getServerPort() public abstract String getRemoteAddr() public abstract String getRemoteHost() public abstract ServletInputStream getInputStream() throws IOException public abstract String getParameter(String name) public abstract String[] getParameterValues(String name) public abstract Enumeration getParameterNames() public abstract Object getAttribute(String name)

Description du client

Il est possible de rajouterdes attributs (non HTTP)

Description du serveur


L’interface Response

L'interface ServletResponse permet de renvoyer une réponse :public abstract void setContentLength(int length) public abstract void setContentType(String type) public abstract ServletOutputStream getOutputStream() throws IOException

L’objet réponse permet d’obtenirle flux de sortie en écriture

Type de contenu auformat MIME

Taille de la réponse(peut être omis)


Fichier de configuration

Le fichier web.xml correspondant

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app> <display-name>Appli de Demo</display-name> <description>Ceci est une série de servlets de démo</description>

<servlet> <servlet-name>hello</servlet-name> <servlet-class>fr.umlv.servletdemo.HelloServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>hello</servlet-name> <url-pattern>/hello.html</url-pattern> </servlet-mapping></web-app>

Le ‘/’ ici est par rapportà l’application Web


Hello World

Le conteneur de servlets fait l’association entre l’URL et la servlet


Hello World (2)

Répertoires sur le serveur


Les servlets HTTP

• La méthode service de la classe HttpServlet est déjà implantée et redirige les requêtes vers les méthodes do*

• Les méthodes sont doDelete, doGet, doHead, doOptions, doPost, doPut, doTrace

protected void do*(HttpServletRequest req, HttpServletResponse resp) throwsServletException, IOException


HTTP HelloWorld

HelloWorld réécrit avec une servlet HTTP

import java.io.*;import javax.servlet.*;import javax.servlet.http.*;

public class HelloHttpServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); out.println("HTTP Hello World!"); } public String getServletInfo() { return "HTTP Hello World Servlet"; } }

L’objet réponse permet d’obtenirle flux de sortie en écriture


Informations sur la requête

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out= response.getWriter(); out.println("Protocol: " + request.getProtocol()); out.println("Scheme: " + request.getScheme()); out.println("ServerName: " + request.getServerName()); out.println("ServerPort: " + request.getServerPort()); out.println("RemoteAddr: " + request.getRemoteAddr()); out.println("RemoteHost: " + request.getRemoteHost()); out.println("Method: " + request.getMethod()); out.println("requestuestURI: " + request.getRequestURI()); out.println("ServletPath: " + request.getServletPath()); out.println("PathInfo: " + request.getPathInfo()); out.println("PathTranslated: " + request.getPathTranslated()); out.println("QueryString: " + request.getQueryString()); out.println("RemoteUser: " + request.getRemoteUser()); out.println("AuthType: " + request.getAuthType()); }

GET, POST, PUT etc.

Chemin virtuel complet

Chemin de laressource

Chemin sur le serveur

Chemin de la servlet


Informations sur la requête (2)

Déclaration de la servlet « header »

<servlet> <servlet-name>header</servlet-name> <servlet-class>fr.umlv.servletdemo.HeaderServlet</servlet-class></servlet><servlet> …</servlet>...<servlet-mapping> <servlet-name>header</servlet-name> <url-pattern>/header/*</url-pattern></servlet-mapping>

Définition des servlets

Chemin de la servlet

Définition des associations


Informations sur la requête (3)


URL complète


Entêtes de la requête

En-tête = Informations envoyées par le browser

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/plain"); PrintWriter out= response.getWriter();

Enumeration e= request.getHeaderNames(); for (; e.hasMoreElements();) { String name= (String) e.nextElement(); out.println(name + ' ' + request.getHeader(name)); }}

Ensemble des nomsdes entêtes

Valeur d’un entête


En-têtes de la requête

Entêtes



Réponse HTTP

L’objet HttpServletResponse permet en plus de renvoyer des codes d’erreurs

public class HttpRedirectServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

if ("/index.html".equals(request.getPathInfo())) response.sendRedirect("/demo/header/index.html"); else response.sendError(HttpServletResponse.SC_NOT_FOUND); } }

Redirection HTTPSC = Status Code


Paramètres d’initialisation

Les paramètres sont déclarés dans le fichier web.xml

<servlet> <servlet-name>initParam</servlet-name> <servlet-class>fr.umlv.servletdemo.InitParamServlet</servlet-class> <init-param> <param-name>count</param-name> <param-value>5</param-value> </init-param> <init-param> <param-name>message</param-name> <param-value>hello config</param-value> </init-param></servlet>


Paramètres d’initialisation (2)

L’objet ServletConfig permet de récupérer les paramètres

public class InitParamServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/plain"); PrintWriter out= response.getWriter(); for(int i=0;i<count;i++) { out.println(message); } } public void init(ServletConfig config) throws ServletException { count = Integer.parseInt(config.getInitParameter("count")); message = config.getInitParameter("message"); } private int count; private String message;}

Demande la valeur duparamètre "count"


Paramètres d’initialisation (3)

Le destroy doit libérer les ressources !!

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { … }

public void init(ServletConfig config) throws ServletException { super.init(config); count = Integer.parseInt(config.getInitParameter("count")); message = config.getInitParameter("message"); }

public void destroy() { message=null; } private int count; private String message;

Stockage des paramètres

Libération des paramètres


Les formulaires

Deux méthodes de passage de paramètres :

• GET (dans l’URL)

• POST (dans la requête HTTP)

Gestion uniforme au niveau des servlets


Les formulaires GET

HTML pour la méthode GET

<form enctype="application/x-www-form-urlencoded" action="subscribe" method=GET> Titre : <select name=title> <option value="Mr">Mr <option value="Ms">Mme </select> Nom : <input type=text size=20 name=username> Prénom : <input type=text size=20 name=firstname> <hr> <input type=submit value="Envoi"> <input type=reset value="Réinitialiser"> </form>


Les formulaires GET (2)

Utilisation des méthodes getParameter*()


response.setContentType("text/html"); PrintWriter out= response.getWriter(); out.println("<html><body bgcolor=\"white\">");

Enumeration e=request.getParameterNames(); for(;e.hasMoreElements();) { String name=(String)e.nextElement(); String value=request.getParameter(name);

out.println(name+'='+value+"<br>"); } out.println("</body></html>"); }

Ensemble des paramètresde la requète

Valeurs d’un paramètrede la requète


Les formulaires POST

HTML pour la méthode POST

<form enctype="application/x-www-form-urlencoded" action="subscribe" method=POST> Titre : <select name=title> <option value="Mr">Mr <option value="Ms">Mme </select> Nom : <input type=text size=20 name=username> Prénom : <input type=text size=20 name=firstname> <hr> <input type=submit value="Envoi"> <input type=reset value="Réinitialiser"> </form>


Les formulaires POST (2)

Utilisation des méthodes getParameter*()

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html"); PrintWriter out= response.getWriter(); out.println("<html><body bgcolor=\"white\">");

Enumeration e=request.getParameterNames(); for(;e.hasMoreElements();) { String name=(String)e.nextElement(); String value=request.getParameter(name);

out.println(name+'='+value+"<br>"); }

out.println("</body></html>"); }

Ensemble des paramètresde la requète

Valeurs d’un paramètrede la requète


Inclusion & Redirection

• L’interface RequestDispatcher :- include(request,response)- forward(request,response)

• Obtenir un RequestDispatcher :getServletContext().getRequestDispatcher(path)

Chemin correspondant• soit à une servlet• soit à un fichier


Inclusion & Redirection (2)

La redirection n’est pas visible au niveau du client


getServletContext().getRequestDispatcher("/index.html"). forward(request,response); }


response.setContentType("text/html"); getServletContext().getRequestDispatcher("/hello.html"). include(request,response); getServletContext().getRequestDispatcher("/hello.html"). include(request,response); }

L’inclusion permet d’inclure plusieurs fois des ressources

fichier

servlet


Inclusion & Redirection (3)

Plusieurs problèmes :

• Forward :- ne pas faire de setContentType() avant- ne rien faire après un forward sur le flux de sortie

• Inclusion :- eviter setContentType() après,- enlever les balises <html> et <body> dans la ressource inclue


Session

Permettre de garder des informations d’une requête à l’autre

• Problème :HTTP est un protocole sans état

• Solutions :

• Authentification

• Session (Cookie, URL rewriting)


Session (2)

L’objet HttpSession gère les sessions

Création :request.getSession()request.getSession(boolean create)

Gestion d’association clé/valeur :session.getAttributeNames()session.getAttribute(String name)session.setAttribute(String name, Object value)session.removeAttribute(String name)

Destruction :session. invalidate()session. logout()

Invalide toutes les sessionspour un client

Créé une session sinon existante


Session (3)

Ouverture et fermeture d’une session


Session (4)

Requête GET sur la servlet


response.setContentType("text/html"); PrintStream out = new PrintStream(response.getOutputStream()); out.println("<html><body bgcolor=\"white\">");

HttpSession session=request.getSession(false); if (session!=null) { out.println("<h1>Welcome "+session.getAttribute("username")+ ' '+session.getAttribute("firstname")+"</h1><hr>"); }

getServletContext().getRequestDispatcher("/session-part.html"). include(request,response);

out.println("</body></html>"); }

Demande une sessionsans création automatique


Session (5)

Requête POST sur la servlet

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

HttpSession session=request.getSession();

if (request.getParameter("logout")==null) { session.setAttribute("username", request.getParameter("username")); session.setAttribute("firstname", request.getParameter("firstname")); } else session.invalidate();

doGet(request,response); } Demande une session

avec création automatique


Authentification : les rôles

login-config: schéma d’authentificationsecurity-role: rôles de l’appli Web

<login-config> <auth-method>BASIC</auth-method> <realm-name>univ-mlv</realm-name></login-config>

<security-role> <description> Client Rôle </description> <role-name>client</role-name></security-role>


Authentification : Tomcat

Services d’authentification fournis :

• Fichier XML (tomcat-user.xml)

• JDBC (base de données)

• LDAP

<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="client"/> <role rolename="admin"/> <user username="toto" password="toto" roles="client"/> <user username="admin" password="admin" roles="admin,client"/></tomcat-users>

Définition des rôles

Définition des utilisateurs


Authentification : Servlet

L’interface java.security.Principal correspond à l’utilisateur et ses différents rôles

public class Authentication2Servlet extends HttpServlet { protected void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/plain"); PrintWriter out=response.getWriter(); out.println("RemoteUser "+request.getRemoteUser()); out.println("UserPrincipal "+request.getUserPrincipal()); out.println("is a client ? "+request.isUserInRole("client")); }}

Nom de l’utilisateur

L’utilisateur possède-t-il le rôleRegroupe un utilisateur

et ses rôles


Authentification : Servlet (2)

Authentification avant l’appel à la servlet


Les filtres

ServletFiltre Filtre

Requête

RequêteRequête

Réponse

RéponseRéponse

Hello World

Hello World Filtré


Les filtres

Il est possible d’ajouter des filtres qui seront exécutés avant les servlets

<filter> <filter-name>footer</filter-name> <filter-class>fr.umlv.servletdemo.FooterFilter</filter-class> </filter>

<filter-mapping> <filter-name>footer</filter-name> <url-pattern>/filter/*</url-pattern> </filter-mapping>

<filter-mapping> <filter-name>footer</filter-name> <servlet-name>hello</servlet-name ></filter-mapping>

Filtre à partir d’un URL

Filtre à partir d’une servlet


Les filtres

Des wrappers permettent d’interagir avec la servlet

public void doFilter(ServletRequest request,ServletResponse response, FilterChain chain) throws IOException, ServletException {

response.setContentType("text/html"); PrintWriter out=response.getWriter(); out.println("<html><body bgcolor=\"white\"><h1>");

HttpServletResponseWrapper newResponse=new HttpServletResponseWrapper( (HttpServletResponse)response) { public void setContentType(String contentType) { } }; chain.doFilter(request,newResponse);

// context.getRequestDispatcher("/footer.html").include(request,response);

out.println("</h1></body></html>"); }

Appelle les autres filtresou la servlet

Exécuté avant

Exécuté après


Administration de Tomcat

Tomcat possède un outil d’administration à distance

Pour l’activer il est nécessaire de rajouter un utilisateur ayant le

rôle admin


Administration de Tomcat

Même informations que dansle fichier server.xml


Ajouter un nouveau rôle

Sur les Rôles

Créé un nouveau rôle

Rôle manager créé


Ajouter un rôle à un utilisateur

L’utilisateur admindevient un manager

de servlets


Manager de Servlet

• Permet de deployer/ démarrer/ arrêter/ recharger des servlets

• Trois modes d’exécutions :- dans une URL- dans le HTML- avec Ant

Reload démandé directementdans l’URL


Manager de Servlet


Tomcat : utilisation de LDAP pour l’authentification et l’autorisation

• On passe par le JNDIRealm ou le JAASRealm

• Un realm est une base d’utilisateurs, de droits et de passwords

• JAASRealm : Fonctionnement différent de la pile JAAS classique : union des droits, pas intersection

• Dans le server.xml :

<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99" connectionURL="ldap://localhost:389" userPattern="uid={0},ou=people,dc=mycompany,dc=com" roleBase="ou=groups,dc=mycompany,dc=com" roleName="cn" roleSearch="(uniqueMember={0})" />


Modèles de déploiement des grilles :le modèle distribué pair-à-pair

• Essentiellement utilisé dans pour les grilles de stockage

• Ne pas être vulnérable

• Pas d’état global

• Découverte des ressources par diffusion

PC

PC

PC

PC

PCPC

PC

PC

PC

PCDiffusion

DiffusionDiffusion

Table des voisins :

@IP 1

@IP 2

@IP x

Table des voisins :

@IP a

@IP b

@IP z

Exemples: Gnutella, Freenet KaZaA, JXTA OceanStore FreeHaven


Modèle client/serveur pour les grilles de stockage : le cas Napster

• Entre le client/serveur et le P2P

• Accès à des données via un site unique contenant un index

• Stockage de données

• Partage des données

• Données « inaltérables »

• Copies multiples sans aucun contrôle

• Limites de l’approche

• Plutôt du client/serveur que réellement du P2P

• Serveur « vulnérable »• Par les tribunaux…• Ou par d’autres…

Utilisateur B Napster(Client + Serveur)

Serveur NapsterAssociation musique-@IP

Utilisateur A Napster(Client + Serveur)


Modèle par annuaire

• OceanStore• Annuaire distribué

• Exemple de Napster• Un seul serveur central

• Annuaire• NomDeFichier <-> Pair

• Liens statiques pairs-serveur• Annonce de présence• Ressources locales• Capacités de communication• Charge en cours

• Communication continue• Heartbeat

Serveur d’annuairewww.napster.com

Pairs sur Internet


Recherche d’un fichier

• Le Pair A veut un fichier

• Requête au serveur central• Une liste complète est aussi

disponible

• « Search *.mp3 »

• Réponse du serveur• Fichiers sur C et D• S’assure que les machines sont

actives

Pair A

Pair C

Pair D

Requête Réponse


Récupération du fichier

• Connexion directe

• De A à C

• « Get *.mp3 »

• Protocole de download direct

• Gestion d’erreurs triviale

• Pas de gestion des reprises

• Pas de hammering• Une seule source

• Beaucoup mieux aujourd’hui

• Kazaa, eDonkey2000, WinXP

Pair A

Pair C

Pair D

Demande Download


Modèle par inondation

• C’est un modèle isotropique

• Les pairs sont libres et égaux en dignité et en droit

• Chacun dispose de données locales

• Aucune notion de réplication

• Chaque recherche repart de zéro

• Diffusion en vague d’une requête


Gnutella

• Liste de pairs

• Locale à chacun

• Quelques centaines

• Evolutive• En fonction d’événements divers

• Sessions permanentes

• Sur 5 à 9 pairs

• Routage des messages• Continuel


Gnutella : Les messages

• Messages• Ping

• Annonce de présence

• Pong• Réponse au ping• IP/port du réceptionnaire attachée• File padding

• Query• Requête de recherche• Vitesse minimum du répondant

• QueryHits• Réponse au message Query• Nombre de fichiers en réponse avec leurs index


Gnutella : Query

• Routage par broadcast contraint

• Requête en vague (ou inondation)• Vers tous les voisins

• Chacun fait une recherche locale…

• …et relaie la requête à tous ses voisins

• Les messages déjà reçus sont ignorés• Evite les cycles

• Chaque message a un Time-To-Live

1

2

2

34

4

3’


hit

Gnutella : QueryHit

• Recherche locale

• Par chaque pair lors du Query

• Relais inverse

• Adresse / Descripteur de fichier

• Réponses positives seulement

• Aggrégation des retours• Padding ou stuffing

• L’émetteur original choisit un fichier (et le pair associé)

• Le download se fait alors en direct

3

2

1

Download


Passage a l’échelle de Gnutella

• Ca ne marchera jamais !

• Au passage des 20 000 utilisateurs, écroulement

• Observé en été 2000

• Why Gnutella Can't Scale. No, Really. [Ritter2000]

• Les leçons tirées

• Nécessité de modéliser/simuler/émuler

• Hubs BearShare• SuperPeers permettant d’étendre le système• Mais pas en O(log(N)) !


Modèle client/serveur pour les grilles de calcul : l’Internet Computing

• Principe• Des millions de PC en attente…

• Récupération des cycles processeurs inutilisés (environ 47% en moyenne dans une entreprise*) via un économiseur d’écran)

• Exemples• SETI@home (ce n’est pas du P2P !)

• Recherche de signaux extra-terrestres• 33,79 Teraflop/s (à comparer aux 12,3

Teraflop/s de l’ordinateur le plus puissant au monde au LLNL !)

• Décrypthon• Etablir la carte des 500 000 protéines du

vivant

• RSA-155• Casser des codes cryptographiques

* d’après une enquête d’Omni Consulting Group


Modèle client/serveur pour les grilles de calcul : le metacomputing / ASP

• Principe

• Acheter du service de calcul sur l’Internet

• Service = applications pré-installées + calculateurs

• Exemples

• Netsolve (Univ. Tennessee)

• NINF (Univ. Tsukuba)

• DIET (ENS Lyon/INRIA)

AGENT(S)

S1 S2 S3 S4

Client

A, B, C

Réponse (C)

S2 !

Requête

Op(C, A, B)

Serveur Serveur Serveur Serveur


Plan : Architecture des grilles de calcul et de données

• Définition

• Vue générale : les principaux composants d’une grille

• Système d’information

• Gestion de ressources

• Sécurité & Organisations virtuelles

• Environnement d’une application

• Réseaux


Définition

Approche pour la distribution de la puissance électrique = le réseaux électrique et la haute-tension


Définition

Approche pour la distribution de la puissance informatique = le réseau Internet et la haute-performance

(parallélisme et distribution)


Et ses différentes incarnations…


Vue générale : les principaux composants d’une grille

• Dans tous les systèmes déjà présentés, certains besoins sont apparus :

• Système d’information : comment savoir quelles ressources sont disponibles ?

• Gestion des ressources : pourquoi et comment attribuer les ressources aux différentes applications

• Sécurité : assurer authentification, confidentialité, non-répudiation, autorisation, etc …

• Environnement d’une application : comment assurer un ensemble de services à des applications ?


Architecture générale : vue logique

Interface utilisateur

Gestion de ressources

chargement

Allocation

Système d'information

Publi

S.I.

Sécu

rité

Hétérogénéité

C.M

.P.P

.

Migration des donnéesEnvironnements

de communication

Transfert HDStockageFile SystemDSM MPI

Environnement d’exécution


S.I.

Architecture générale : Déploiement possible

Allocation

Machines noyau

Machines ressources

e-Toile

Publi

C.M.P.P. Hétérogénéité

Chargement

U.I

Architecture des grilles de calcul et de données : systèmes d’information


Le besoin d’informations

• Système d’information point crucial pour les opérations sur la grille et la construction d’applications

• Comment une application détermine quelles ressources sont disponibles ?

• Quel est « l’état » de la grille

• Besoin d’un système d’information général pour répondre à ces questions


Quelques informations utiles

• Caractéristiques d’un serveur de calcul

• Adresse IP, logiciels disponibles, administrateur système, connections aux réseaux, version d’OS, charge

• Caractéristiques d’un réseau

• Bande passante et latence, protocoles, topologie logique

• Caractéristiques de l’infrastructure logicielle

• gestionnaire de ressources, etc.


Service d’information

• Fournir un accès à des informations statiques et dynamiques sur les composants

• Base pour la configuration et l’adaptation de systèmes dynamiques et hétérogènes

• Besoins et caractéristiques

• Accès uniforme et flexible à l’information

• Accès efficace et extensible aux données dynamiques

• Accès à des sources d’informations multiples

• Maintenance décentralisée


Approche MDS

• Basée sur LDAP

• Lightweight Directory Access Protocol v3 (LDAPv3)

• Modèle de données standard

• Protocole de requête standard

• Schéma spécifique à Globus

• Représentation centrée sur l’hôte

• Outils spécifiques Globus

• GRIS, GIIS

• Découverte, publication de données

GRIS

NIS

NWS

LDAP

API LDAP

Middleware

…

Application

GIIS…

SNMP


Le MDS

• Metacomputing Directory Service

• Annuaire de ressource de Globus

• Contient toutes les informations sur tous les nœuds globus

• Consultable sur Internet

• http://www.globus.org/mds

• Distribué depuis la version 1.1.3

• Permet de créer son propre « sous-Globus »


Metacomputing directory service

nn=SP-switch

MDSRepresentation

Carl Steve

Switch

Ethernet

Ian Gregor Steve Warren

sunny

hot

IBMSP

dark coldLAN

LANWAN

USC/ISI ANL/MCS

c=US

o=globus

o=USC o=ANL

ou=MCSou=ISI

nn=WAN

cn=Iancn=Gregor

cn=Warren

cn=Steve

nn=SP-ether

nn=MCS-lan

hn=sp1.mcs.anl.gov

hn=spN.mcs.anl.gov

cn=Carl

cn=Steve…

…

……

Structure physique

Architecture des grilles de calcul et de données : gestion de ressources


Gestion de ressources• Un langage de spécification de ressources flexible qui fournit

la puissance nécessaire pour exprimer les contraintes requises

• Des services pour la co-allocation de ressources, l’organisation d’exécutables, l’accès à des données distantes et la gestion des flux d’entrées/sorties

• Intégration de ces services dans des outils de haut niveau

• Globus : • MPICH-G: un MPI pour la grille• globus-job-*: commandes flexible d’exécution à distance


Gestion de ressources

• Resource Specification Language (RSL) est utilisé pour communiquer les besoins

• L’API du Globus Resource Allocation Manager (GRAM) permet de lancer les programmes sur des ressources distantes, sans tenir compte de l’hétérogénéité locale

• Une architecture en couche permet de définir des courtiers de ressources et des co-allocateurs spécifiques aux applications comme étant des services GRAM


Modèle d’ordonnancement

• GRAM supporte le modèle suivant

suspendu actif terminé

échec

• Suspendu : ressources non encore allouées

• Actif : ressources allouées, exécution en cours

• Échec : terminaison prématurée (erreur ou arrêt)

• Terminé : terminaison avec succès


Composants GRAM

Globus SecurityInfrastructure

Job Manager

Appels GRAM pour requête d’allocation de ressources et création de processus.

Appels MDS pour localiser les ressources

Requête sur l’état de la ressource

Création

Bibliothèque RSL

Parse

RequêteAllocation &

création des processus

Processus

Processus

Processus

Monitoring &contrôle

Limite du site

Client MDS: Grid Index Info Server

Gatekeeper

MDS: Grid Resource Info Server

Local Resource Manager

Appels MDS pour avoir des infos sur les ressources

Mise à jour GRAM


GRAM GRAM GRAM

LSF EASY-LL NQE

Application

RSL

Simple ground RSL

Service d’Information

Gestionnairesde ressourceslocaux

spécialisation RSLCourtier

Ground RSL

Co-allocateur

Requêtes

& Info

Architecture de la gestion de ressources


Langage de spécification de ressource

• Notation commune pour l’échange d’information entre composants

• RSL fournit deux types d’informations :

• Besoins en ressources : type de machine, nombre de nœuds, mémoire, etc.

• Configuration d’un job : Répertoire, exécutable, arguments, environnement

• API fournie pour manipuler RSL


Syntaxe RSL

• Forme élémentaire : clauses parenthésées

• (attribut op valeur [ valeur … ] )

• Opérateurs supportés:

• <, <=, =, >=, > , !=

• Quelques attributs supportés :

• exécutable, arguments, environnement, stdin, stdout, stderr, resourceManagerContact,resourceManagerName

• Les attributs inconnus sont ignorés

• Peut-être gérés par d’autres outils


Contraintes : “&”

• Par exemple :

& (count>=5) (count<=10)

(max_time=240) (memory>=64)

(executable=myprog)

• “Créer entre 5-10 instances de myprog, chacune sur une machine with ayant au moins 64 MB de mémoire et disponible pour moi pendant 4 heures”


Multi-requêtes : “+”

• Une multi-requête permet de spécifier plusieurs besoins de ressources, par exemple :

+ (& (count=5)(memory>=64)

(executable=p1))

(&(network=atm) (executable=p2))

• Exécuter 5 instances de p1 sur une machine ayant au moins 64Mb de mémoire

• Exécuter p2 sur une machine ayant une connexion ATM

• Multi-requêtes sont le cœur de la co-allocation


GRAM

• Globus Resource Allocation Manager

• Permet à un programme d’être lancé sur des ressources distantes malgré l’hétérogénéité locale

• Utilise le langage de spécification de ressources (RSL)


DUROC

• Dynamically Updated Request Online Co-allocator

• Co-allocation : allocation simultanée d’un ensemble de ressources

• Basée sur des prédictions concernant les nœuds libres et la taille des files d’attentes

Architecture des grilles de calcul et de données : sécurité

Mécanismes primitifs


Sommaire

• Introduction

• Cryptographie


• Certification

• Microsoft .NET Passport

• Kerberos

• SSL


Authentification & ApplicationIntroduction

• Apparition des systèmes distribués

• Réseaux à grande échelle

• préserver la confidentialité des données

• préserver l'intégrité des données

• authentifier le correspondant

• Assurer la non-répudiation


Sommaire

• Introduction

• Cryptographie


• Certification


• Kerberos

• SSL


Cryptographie

• Définition

• Science du chiffrement

• Meilleur moyen de protéger une information = la rendre illisible ou incompréhensible

• Bases

• Une clé = chaîne de nombres binaires (0 et 1)

• Un Algorithme = fonction mathématique qui va combiner la clé et le texte à crypter pour rendre ce texte illisible


• Une Clé Secrète (Unique) partagée entre les 2 parties qui sert pour le chiffrement et le déchiffrement du message

CryptographieChiffrement Symétrique


• Algorithmes utilisant ce système :

• DES (Data Encryption Standard, très répandu) : les données sont découpées en blocs de 64 bits et codées grâce à la clé secrète de 56 bits propre à un couple d’utilisateurs

• IDEA, RC2, RC4

• Avantage :

• Rapide

• Inconvénients :

• Il faut autant de paires de clés que de couples de correspondants

• La non-répudiation n’est pas assurée. Mon correspondant possédant la même clé que moi, il peut fabriquer un message en usurpant mon identité

• Transmission de clé

CryptographieChiffrement Symétrique


• Clé publique• Sert à chiffrer le message

• Clé privée• Sert à déchiffrer le message

CryptographieChiffrement Asymétrique


CryptographieChiffrement Asymétrique

• Algorithmes utilisant ce système :• RSA (Rivest, Shamir, Adelman)

• DSA

• ElGamal

• Diffie-Helmann

• Avantage :• pas besoin de se transmettre les clés au départ par un autre vecteur de

transmission.

• Inconvénient : • Lenteur


• Chiffrement symétrique

• Problèmes d’échanges de clés

• Chiffrement asymétrique

• Problème de lenteur

combinaison des 2 = clé de session

CryptographieCombinaison des 2 Chiffrements


Sommaire

• Introduction

• Cryptographie


• Certification


• Kerberos

• SSL


AuthentificationDéfinition

• La personne à qui j'envoie un message crypté est-elle bien celle à laquelle je pense ?

• La personne qui m'envoie un message crypté est-elle bien celle à qui je pense ?


• Prouveur

• Celui qui s’identifie, qui prétend être…

• Vérifieur

• Fournisseur du service

• Challenge

• Le Vérifieur va lancer un challenge au prouveur que ce dernier doit réaliser

AuthentificationTechnique d’Identification


• Algorithme RSA = Réversible

• ((Mess)CPu)CPr = ((Mess)CPr)CPu

• Confidentialité


Technique A Clé PubliquePrincipe


Technique A Clé PubliqueConfidentialité

Le Texte est totalement confidentiel car le

destinataire est le seul a avoir la clé privée


Technique A Clé PubliqueAuthentification

On est sûr de l’identité de l’émetteur car il est

le seul à pouvoir chiffrer un message avec cette clé privée


Technique A Clé PubliqueProtocole

Serveur d’authentification – Annuaire

(Clé Publiques de F & D…)

1

2

3 M1

4

5

6 M2

7 M3

1) F demande la Clé Publique de D

F D

2) S envoie la Clé Publique de D à F

3) F envoie le « challenge » à D: Décrypte mon message M1(If) et renvoie mon If pour me le prouver!

4) D décrypte M1 et demande à S la Clé Publique de F

5) S envoie la Clé Publique de F à D

6) A son tour D envoie un « challenge » à F: Décrypte mon message M2(If, Id) et renvoie mon Id !

7) F décrypte M2 et renvoie M3(Id) à D pour lui montrer qu’il y est arrivé

8) F & D peuvent maintenant par ex s’envoyer des messages en créant une Clé Privée à partir de (If,Id)

8


Technique A Clé SecrèteProtocole deNeedham – Schroeder

1

2 M1

3 M2

4 M3

5 M4

F D

Serveur d’authentification – Annuaire

(Clés Secrètes de F & D)

1) F demande une Clé de Session pour pouvoir parler avec D

2) S envoie à F M1 crypté par la Clé Secrète de F:

M1 = une Clé de Session CSfd en clair et une cryptée par la Clé Secrète de D (CSfd)CPd

3) F envoie le « challenge » à D: Décrypte mon message M2((CSfd)CPd) et renvoie un Id crypté par CSfd

4) D décrypte M2 et envoie son « challenge » : Décrypte mon message M3((Id)CSfd) et renvoie Id-1

5) F décrypte M3 et renvoie M4((Id-1)CSfd)

6 6) F & D peuvent donc s’envoyer des messages avec la Clé de Session (MESSAGE)CSfd


– Comment savoir que le message n’a pas été altéré ?

fonction de hachage

– algorithmes de hachage les plus utilisés: MD5 (128 bits) et SHA (160 bits)

Signature électronique (1)


–Pb du hachage : on est pas sur de l’expéditeur Scellement des données

Signature électronique (2)


Sommaire

• Introduction

• Cryptographie


• Certification


• Kerberos

• SSL


CertificationPrincipes

• Besoins

• Chiffrement asymétrique = basé sur la distribution de clés publiques (Annuaire)

• rien ne garantit que la clé est bien celle de l'utilisateur a qui elle est associée…

Certificats

• Certificats

• Carte d’identité électronique, composée de la clé publique du porteur et d’informations relatives à ce dernier.

• Délivré par une autorité appelée tiers de confiance, qui, par sa signature, en garantit l’authenticité.


CertificationCertificatX509


CertificationExemple Certificat X509


CertificationPKI (Public Key Infrastructure)IGC (Infrastructure de Gestion de Clés)

• Système permettant la gestion de clés de chiffrement et la délivrance de certificats numériques

• Repose sur l’utilisation de la cryptographie à clé publique


PKI - Organisation


Sommaire

• Introduction

• Cryptographie


• Certification


• Kerberos

• SSL


Microsoft .NET Passport

• service en ligne gratuit

• permet de se connecter (en toute sécurité ?) à n'importe quel service ou site Web Passport participant

• Utilisation d’une adresse de messagerie et d’un mot de passe unique



• Contenu obligatoire

• Email (nom d’utilisateur)

• Mot de passe

• Contenu optionnel

• Phrase de rappel

• Clé de sécurité

• Numéro de mobile

• Date de naissance, coordonnées

• Informations bancaires


P a rtic ipa tin g S ite C

In te rn e t

P a ssp ort (C o - B randed by

re fe rring site )

P a rtic ipa tin g S ite A

P a rtic ipa tin g S ite B

U se r

–L’utilisateur contacte un site

–L’utilisateur est redirige sur le site PassPort

–L’utilisateur S’authentifie et reçoit un cookie chiffré

–L’Utilisateur est redirigé vers le premier site qui lit le cookie

–L’utilisateur reste authentifié pour tout autre site



Sommaire

• Introduction

• Cryptographie


• Certification

• PGP


• Kerberos

• SSL


• Conditions de fonctionnement

• Les serveurs ne font aucune confiance aux clients

• Les clients n’accordent qu’une confiance limitée aux serveurs

• Authentification contrôlée par des serveurs spécialisés

KerberosIntroduction


KerberosService d’Authentification

• Pré-requis

• Le serveur Kerberos détient les mots de passe utilisateurs

• Le serveur détient la clé privée du serveur de tickets

• Le serveur de tickets détient les clés privés de tous les serveurs


KerberosLexique

• Ticket

Caractérise une session entre un client C et un serveur S

Tcs={S, C, adr, Td, durée, Kcs}Ks• Adr : adresse IP du client• Td : heure de début de session• Durée : durée max de session• Kcs : clé de session partagée par C et S• Ks : clé permanente (secrète) de S


KerberosLexique

• Authentifieur

caractérise le client à un instant, vis à vis d’un serveur

Acs(t)={C, adr, t}Kcs• Engendré par le client• Permet une authentification permanente par le serveur


Sommaire

• Introduction

• Cryptographie


• Certification

• PGP


• Kerberos

• SSL


SSL (Secure Sockets Layer)

• Définition

• « Couche de Sockets Sécurisée »

• Protocole d’échange de données au dessus de TCP/IP qui assure:• Confidentialité des échanges entre 2 applications• Authentification des serveurs

• Indépendant du protocole Utilisé (HTTP, FTP, …)


SSL (Secure Sockets Layer)

• Principe

• Utilise RSA (clé publique) pour s’échanger des clés DES (clé Secrète)• Protocole de négociation (choix clés)• Protocole d’échange (chiffré par DES)

• Authentifie un navigateur, pas une personne

• Compatibilité

• Presque Tous les Navigateurs

• Affichage du cadenas en bas pour les sites Sécurisés

• Un serveur sécurisé possède une URL commencant par https://


SSLPhase de Négociation


• Utilise des certificats émis par une autorité de certification

• Authentifier le serveur vis à vis du client (navigateur)

• Authentifier le navigateur vis à vis du serveur

• Génération des clés de session

• Technique à clé publique vue précédemment

• Création des clés de session

• Fin de négociation

• Client & serveur sont authentifiés mutuellement

• Ils ont leurs clés secrètes pour la phase d’échange


mécanismes

• Infrastructure de Gestion de Clés

• Infrastructure de Gestion des Privilèges

• Délégation


Infrastructure de Gestion de Clés (1)

• Infrastructure de Gestion à clés Publique (PKI)• AE : Autorité d’Enregistrement enregistre et vérifie les informations

propres aux utilisateurs

• AC : Autorité de Certification délivre les certificats aux utilisateurs

• Annuaire de publication des certificats fournit les données de validation des certificats des utilisateurs

• politiques de certification

• Utilisation des Certificats X.509 à clés publiques « PKI » (long time certificate)

• Certificat PKC: utilisé pour mettre en place un service d’identification des utilisateurs

• Protection des clés privées des utilisateurs (carte à puce, …)

• validation et révocation des certificats d’authentification (CRLs, ARLs, ..)

• …


Authentification forte des utilisateurs (2)

• Certificat d’authentification pièce d’identité électronique permettant l’authentification des utilisateurs

• Certificat d’authentification contient des informations pérennes (durée de vie 1 à 2 ans)

• Format du certificat d’authentification RFC 2459, 3280

• DN du sujet Nom distinct de l’utilisateur

• DN de l’émetteur Nom distinct de la communauté de l’utilisateur

• KeyUsage utilisation de la clé = authentification

• CertificatePolicies politique de certification

• …


Certificat d’attributs

• Il est signé par une autorité d’attributs qui n’est pas nécessairement une autorité de certification

• Il ne permet pas d’identifier un utilisateur ou un process

• Il spécifie les attributs d’un utilisateur

• Rôle

• (objet (permission)*)*

• Il est associé à un certificat d’authentification

• Unification des DN


Infrastructure de gestion des privilèges (1)

• PMI

• Composantes

• Autorité d’Attribut (AA)

• Source d’Autorité (SOA)

• Vérificateur de privilèges

• Déclarant de privilèges

• Politique de privilèges



• Utilisation des certificats d’authentification dans PMI

• Utilisation de l’Extension SubjectDirectoryAttribute pour définir les attributs des utilisateurs dans leurs certificats d’authentification

• Durée de validité du certificat = durée de validité des attributs

• Révocation des attributs Révocation du certificat l’authentification

• Autorité d’attribut (AA)= Autorité de gestion des certificats (AC)



• Utilisation des certificats d’attributs

• Définition X509 ISO IEC 9594-8 (cf aussi RFC 3281)

• les attributs sont des OID (rôle, groupe, ACL)

• durée de vie du certificat d’attributs est différente du certificat d’authentification

• Verification

• le certificat d’attribut est vérifié par un « vérificateur » qui peut un moniteur

• Droits et privilèges non publiés (à compléter)

• Remontée d’une chaîne de signature jusqu’au SOA

•


Délégation

• Transfert d'un privilège d'une entité détentrice vers une autre entité.

• Délégation du droit d’authentification d’un utilisateur par la création de certificat proxy

• attributs associés au certificat proxy sont inclus dans les attributs associés au certificat PKC.

Att

PKC

Proxy proxy

Att Att

Att

Att

associé

Signé par

Signé par


Certificats proxy

• Le certificat est signé par un certificat utilisateur X.509.

• Le certificat proxy peut signé par un autre certificat proxy

• le bi-clé du certificat proxy est différent du bi-clé du certificat utilisateur émetteur

• le certificat proxy d’authentification trace (mémorise) l’identité de son émetteur

• le certificat proxy contient une extension spécifique Extension ProxyCertInfo qui le distingue des autres certificats.

Architecture de confiance


Architecture de confiance

• Architecture PKI

• Architecture PMI

• Association PKI et PMI

• Application Au Grid

Architecture PKI


Architecture PKI (1)

• Architecture PKI structure arborescente (1 communauté )

• Génération du certificat MTC Root pour toute la communauté

• Génération d’un certificat « AC déléguée » pour chaque entité de la communauté

• Génération des certificats des utilisateurs

• Validation d’un certificat par la validation du chemin de certification menant au MTC

user1

MTC

CA 1 CA 2

user2

user3

user4

LAR

LCR

Communauté



• Architecture PKI structure arborescente

• même source de confiance pour tous les utilisateurs

• une gestion simplifiée

• une infrastructure simple

• politique de certification commune

user1

MTC

CA 1 CA 2

user2

user3

user4

LAR

LCR

Communauté



• Architecture réseaux de PKI

• Plusieurs communautés

• Plusieurs MTC

• Cross Certification mutuelle entre les communautés

• plusieurs politiques de certification

• Critères de cross certification entre les communauté

• des équivalences de politiques de certification

u1

CA 1 CA 2

u2 u3 u4

MTC

LAR

LCRu1

MTC

CA 1

u2

MTC

u1

u2

Cross Certification

MTC

u1

u2



• Architecture réseaux de PKI

• La complexité de l’architecture augmente avec le nombre des communautés

• Chaînes de certification complexe (multiples)

• Gestion de l’infrastructure devient complexe

• Problèmes d’interopérabilité entre les PKI

• La validation des certificats devient plus complexe.

u1

CA 1 CA 2

u2 u3 u4

MTC

LAR

LCRu1

MTC

CA 1

u2

MTC

u1

u2

Cross Certification

MTC

u1

u2



• Architecture Bridge CA

• Création d’une communauté virtuelle

• Établir des relations de Cross certification entre la communauté virtuelle et l’ensemble des communautés

• Simplification des itinéraires de certification

u1

CA 1 CA 2

u2 u3 u4

MTC

LAR

LCR

u1

MTC

CA 1

u2

MTC

u1

u2

Cross Certification

MTC

u1

u2

CommunautéVirtuelle

Architecture PMI


Architecture PMI

• Principe d’Arborescence PMI

• une Source d’Autorité de confiance SOA

• plusieurs Autorités d’Attributs AA

• Certificats d’Attributs signée par les AA

• la validation d’un certificat d’attribut par la validation du chemin menant au SOA

A1

SOA

AA 1 AA 2

A2

A3

A4

Association PKI et PMI


Association PKI et PMI

• Architecture avec même source de confiance pour les deux infrastructures PKI et PMI

• Indépendance des deux infrastructures PKI et PMI


Architecture avec même source de confiance PKI et PMI

• Origines de confiance des droits d’identification et des privilèges sont confondues : MTC = SOA

• politiques de certification et politiques de privilège sont sous la responsabilité de la même Autorité

• Compromission du MTC Compromission du SOA

• la validation des droits d’identification et d’attributs peut être effectuée par l’ensemble des composantes de l’infrastructure (visibilité globale)

• La délégation des droits d’authentification et des privilèges des utilisateurs peut être effectuée dans l’ensemble de l’infrastructure



• Fusion des architectures PKI et PMI

• l’autorité de certification est l’autorité d’attribut : les administrations des droits d’identification et des attributs sont fusionnés

• les Certificats PKC et Certificat d’Attributs d’un utilisateurs sont émis par la même Autorité

• révocation de l’AC révocation de AA

MTCSOA

U 4

A’3

AC 2AA 2

U 3

A’1 A’2

AC 1AA 1

A1 A2

U 1 U 2

A3 A4


• Séparation de l’administration des droits d’authentification et d’attribut

• l’autorité de certification et l’autorité d’attribut sont indépendante

• l’administrateur de certification # administrateur des privilèges

• révocation de l’AC # révocation de AA

AC

U1 U2

AA

MTCSOA

A1 An




• délégation du droit de génération des certificats d’attributs

• l’autorité de certification et l’autorité d’attribut sont indépendante

• délégation de l’AA du droit de génération des certificats d’attributs à l’AC

AC

A1 A2

AA

MTCSOA

U 1 U 2

Délégation


Indépendance des Architectures PKI et PMI

•Origines de confiance des droits d’identification et des privilèges sont différentes: MTC # SOA

• Politiques de certification et politiques de privilège sont sous la responsabilité de plusieurs autorités différentes

•Compromission du MTC n’a aucune conséquence sur le SOA et réciproquement

•La validation des droits d’identification est globale PKI, la validation des certificats d’attributs est locale PMI

•La délégation des droits d’authentification peut se faire dans l’ensemble de l’infrastructure PKI

•La délégation d’attributs ne peut pas être effectuée


Indépendance des Architectures PKI et PMI

• Origine de confiance des droits d’identification et des privilèges sont séparée

• les autorités de certification et les autorités d’attributs sont indépendantes

• les chemins de certification et d’attributs sont indépendants

• les révocations des droits d’identification est indépendante de la révocation des privilèges

AC1

U1 U2

AA2

SOA1

A3 A4

AA1

A1 A2

MTC

AC2

U3 U4

AA4

SOA2

A7 A8

AA3

A5 A6

PKI

PMI

PMI


Grid : Quelques caractéristiques (1)

• Composant physique

• chaque organisation peut être composée de plusieurs entités

• chaque organisation a un ensemble d’utilisateurs

• chaque organisation possède le contrôle total sur l’attribution et la révocation des droits d’identification des utilisateurs (administration des droits I&A)

• chaque entité d’une organisation possède un ensemble de ressources qui lui sont propres

• chaque entité veut possède un contrôle total sur l’attribution et la révocation des doits d’accès (privilèges) des utilisateurs à ces ressources (administration des des droits d’accès aux ressources)

• …….



• utilisateurs

• un utilisateur appartient à une seule organisation physique

• un utilisateur peut appartenir à plusieurs entités physiques d’une même organisation physique

• le droit d’authentification d’un utilisateur lui est délivré par une autorité de certification de son organisation

• un utilisateur bénéficie de l’ensemble des privilèges qui lui sont nécessaires pour effectuer ces tâches dans son organisation

• les privilèges d’un utilisateur lui sont délivrés par les administrateurs des droits d’accès aux ressources de chaque entité de son organisation



• organisation virtuelle

• une organisation virtuelle regroupe des utilisateurs de plusieurs organisations physiques afin d’effectuer des travaux nécessitant l’accès aux ressources de une ou plusieurs entités ; chaque entité appartient à une organisation physique.

• L’utilisateur d’une organisation virtuelle doit bénéficier pour effectuer son travail des droits I&A dans plusieurs organisations physiques, et des droits d’accès aux ressources dans plusieurs entités des organisations physiques


Grid : Contraintes fonctionnelles

• I&A

• l’I&A d’un utilisateur dans une organisation virtuelle est effectuée grâce au droit d’I&A qui lui ont été attribués par son organisation physique

• au cours d’une même session un utilisateur d’une organisation virtuelle n’a pas besoin de se re-authentifier à chaque accès à une organisation physique

• La protection des échanges électroniques entre l’utilisateur et les entités ne nécessite pas la re-utilisation du droit d’I&A de l’utilisateur

• ……


Grid : définitions

• Allocateur des ressources : dispositif permettant d’allouer ..

• Statique

• dynamique

• Moniteur : dispositif chargé de contrôler la légitimité des tentatives d'accès des utilisateurs sur les ressources

• Base d’informations d’attributs

• Chargeur :

•

Architecture de sécurité


Définir les objectifs de sécurité

• I&A : • Toutes les actions autorisées sur le Grid ne peuvent être exécutées que par des

utilisateurs dûment authentifiés

• Etc..

• Droits d’accès : • Les utilisateurs authentifiés peuvent accéder uniquement aux ressources sur

lesquelles ils bénéficient d’une autorisation.

• Etc..

• Communication : • L’ensembles des échanges électroniques doivent être protéger en intégrité et

confidentialité

• Etc…

• Audit

• Etc..


Définitions complémentaires

• Client proxy utilisateur : dispositif qui utilise un certificat proxy délégué d’un utilisateur pour effectuer des demandes de tâche (ou job) à un allocateur des ressources, ou à un serveur proxy ressource

• Serveur proxy ressource : serveur proxy permettant d’authentifier les demandes d’accès à des ressources

• Base d’information d’attributs : base de stockage des informations de validation des certificats d’attributs d’un ensemble d’utilisateur

• Base d’information de certification : base de stockage des information de validation des certificats à clés publiques des utilisateurs


Architecture de sécurité : délégation (1)

• Authentification du user • Génération d’un nouveau bi-clé• Génération d’un certificat proxy délégué par le user• Lancement d’un client proxy sur le poste du user• requête d’exécution d’un job de l’user

Étape 2

• réception de la Requête d’exécution du job par l’allocateur• Authentification mutuelle entre client proxy 1 et serveur I&A• Demande de vérification des attributs du user au moniteur• vérification des attributs du user par le moniteur (accès à la base d’information d’attributs)• réponse de vérification des attributs du user• Demande de chargement des taches au chargeur

Serveur I&A

Serveur I&A

Allocateur

MoniteurBase

d’information des attributs

Chargeur

User

Client Proxy 1

Client Proxy 1

Étape 1

ServeurI&A

ServeurI&A

Client Proxy 1

Client Proxy 1

Étape 1

ServeurI&A

ServeurI&A


Architecture de sécurité : délégation (2)Étape 3

• génération d’un certificat proxy 2 pour le lancement des taches sur les serveurs distants

• génération d’un nouveau bi-clé•demande d’un certificats proxy délégué au client proxy 1 pour effectuée le lancement des taches distantes• réception du certificat proxy 2 du client proxy 1•Lancement du client proxy 2

Étape 4

User

Client Proxy 1

Client Proxy 1

ServeurI&A

ServeurI&A

Serveur I&A

Serveur I&A

Allocateur

Moniteur Base d’information des attributs

Chargeur

•Réception de la demande de certificat délégué •Génération d’un certificat proxy délégué 2 par le le client proxy 1• envoie du certificat proxy 2

Client Proxy 2

Client Proxy 2



• demande de lancement d’une tâche distante

Étape 5

User

Client Proxy 1

Client Proxy 1

ServeurI&A

ServeurI&A

Serveur I&A

Serveur I&A

Allocateur

Moniteur Base d’information des Attributs

Chargeur

Client

Proxy 2

Client Proxy 2

Serveur Proxy

Ressource

Serveur Proxy

Ressource

• réception de la demande de lancement de la tâche•authentification mutuelle entre client proxy 2 et serveur proxy ressource• lancement de la tache

Tâche

Étape 6



Canal sécurisé TLS

User

Client Proxy 1

Client Proxy 1

ServeurI&A

ServeurI&A

Serveur I&A

Serveur I&A

Allocateur


Chargeur

Client

Proxy 2

Client Proxy 2

Serveur Proxy

Ressource

Serveur Proxy

Ressource

Tâche



User

Client Proxy 1

Client Proxy 1

ServeurI&A

ServeurI&A

Serveur I&A

Serveur I&A

Allocateur


Chargeur

Client

Proxy 2

Client Proxy 2

Serveur Proxy

Ressource

Serveur Proxy

Ressource

Tâche

Serveur Proxy

Ressource

Serveur Proxy

Ressource

Tâche

Tâche

Client Proxy

3

Client Proxy

3

Serveur Proxy

Ressource

Serveur Proxy

Ressource

Tâche

Tâche

Itinéraire de délégation des droits d’authentification de longueur 3

Liaison TLS



User ServeurI&A

ServeurI&A

Client Proxy

1

Client Proxy

1

Serveur I&A

Serveur I&A

Allocateur

Moniteur Base des Attributs

Chargeur

Client Proxy

2

Client Proxy

2

Tâche

Client Proxy

3

Client Proxy

3

Serveur Proxy

Serveur Proxy

Tâche

Serveur Proxy

Serveur Proxy

Tâche

Tâche

Serveur Proxy

Serveur Proxy

Tâche

Tâche

Client Proxy

3

Client Proxy

3

Serveur Proxy

Serveur Proxy

Tâche

Client Proxy

3

Client Proxy

3Serveur

Proxy

Serveur Proxy

Tâche

Serveur Proxy

Serveur Proxy

Tâche

Tâche

Serveur Proxy

Serveur Proxy

Tâche Tâche

Serveur Proxy

Serveur Proxy

Tâche

Serveur I&A

Serveur I&A

Allocateur

Moniteur

Base des AttributsChargeur

Client Proxy

2

Client Proxy

2

Serveur I&A

Serveur I&A

Allocateur

Moniteur

Base des AttributsChargeur

Client Proxy

2

Client Proxy

2

Organisation 1

Organisation 2

Organisation 3


Dispositifs de sécurité

• PKI :

• module CA (génération de certificat PKC, révocation, … ),

• module RA

• module de publication

• PMI :

• modules AA (génération des certificats d’attributs, révocation, …)

• module de publication

• Base d’information de certification par exp : Annuaires LDAP

• Base d’information d’attribut par exp : Annuaires LDAP

• Moniteurs par exp : un vérificateur des certificats d’attributs


Dispositifs de sécurité

• Serveurs Proxy ressources :

• TLS (serveur)

• Module de lancement des proxy client

• Proxy client

• Module de génération des bi-clés

• TLS délégation protocol client (requête des certificats proxy)

• Module de génération des certificats proxy (pour d’autres clients proxy)

• TLS délégation protocol Serveur (réponse des demandes de certificats proxy)

Environnement d’une application


Environnement des communications

• Problèmes

• Support des architectures grilles

• Routage

• Multiplexage

• Dynamicité


Support grille

• Exploitation des Grappes de grappes• Réseaux intra-grappes rapides

• Liens inter-grappes rapides

• Hétérogénéité au niveau réseau

Réseau à haut débitRéseau haute

performanceRéseau haute performance


Principe

• Canaux réels

• Liés à un réseau

• Ne couvrent pas nécessairement tous les noeuds

• Canaux virtuels

• Couvrent tous les noeuds

• Contiennent plusieurs canaux réels

MyrinetSCI

Virtuel


Infrastructure

Processus

Gestionnaire de communications

Dynamicité

Support d’architectures évolutives


Points clés

Granularité

• Niveau processus

• Niveau grappes

La dynamicité a un coût

• Scrutations supplémentaires

• Prise en compte du changement de topologie

La dynamicité est parfois impossible

• Interfaces de communication à lanceur propriétaire

• Interfaces sans primitives/potentiel de connexion dynamique


Changement de topologie

• Propagation à toute la configuration

• Serveur de gestion des communications

• Processus applicatifs

• Deux conséquences

• Vraisemblablement une synchronisation globale• Impact fort sur l’exécution

• Prise en charge d’événements asynchrones de la gestion des communications sur les nœuds applicatifs

• Nécessité d’un thread dédié• Verrouillages délicats


Changement de topologie

Cas du routage multi-réseau

• Nécessité d’un recalcul des routes

• Opération coûteuse

• Problème pour les blocs de données en transit sur les passerelles

• Routage dynamique ?

• Ordre des messages

• Refaire IP ?


Conclusion – support dynamicité

• Réalisable

• pour une dynamicité à gros grain (grappes)

• pour une faible dynamicité au niveau processus

• Prohibitif

• pour une forte dynamicité au niveau processus

• Impossible

• Interfaces à lanceurs spécifiques

• Interfaces sans possibilités de connexions dynamiques• MPI, BIP


Plan : Perspectives pour les grilles de calcul et de données

• Perspectives• Prochain standards• Projets en cours• Tendances actuelles


MPICH-G - Description & Technologie

• MPICH est une implémentation libre et disponible du standard MPI qui peut s’exécuter sur un large panel de systèmes.

• MPICH est dérivé de MPI et de Chameleon; Caméléon parce que MPICH peut s’exécuter sur un large panel d’environnements et aussi parce que l’implémentation initiale de MPICH utilise le Chameleon message-passing portability system.

Perspectives


Prochains standards

• Une organisation, le Global Grid Forum, a été depuis quelques années et défini les standards de demain, le dernier étant une extension d’OGSA, WSRF (Web Service Resource Framework), basé sur la notion de l’exposition de ressources comme étant des WS à état.

• La technologie n’est pas encore stable, et il est probable que les standards définis actuellement ne seront pas les derniers.


Projets en cours

• Plusieurs projets de recherche en France via l’Action Concerté Incitative GRID Globalisation des Ressources Informatiques et des Données et en Europe via la PCRD.

• Le projet faisant suite à DataGrid, dans l’optique de l’exploitation pour le LHC d’une grille de données, vient de passer sa première revue annuelle. Il compte 72 partenaires répartis en Europe, industriels et scientifiques.


Perspectives

• Les grilles génériques, dédiées a tout type d’applications, tendent à disparaître pour être remplacés par des projets communautaire, soit par spécialité (physique, biologie) soit par type d’application (stockage de données à grande échelle, calcul matriciel et algèbre linéaire.

• Les projets de grande ampleur semblent ralentir pour laisser la place aux grilles d’entreprises.


Quelques mots sur ce cours/références

• Ce cours ayant été préparé en peu de temps, l’essentiel des transparents présenté ici proviennent d’autres sources. Je prie les auteurs de me pardonner cet emprunt.

• Liste des auteurs/présentations :

• Architectures de grappes de PC Philippe Augerat ID-IMAG

• Les architectures parallèles et leur programmation pour le calcul scientifique Yves Denneulin

• GRAAL Algorithmique pour les plateformes distribuées et hétérogènes LIP ENS Lyon INRIA Rhône-Alpes

• Madeleine - Marcel Olivier Aumage Raymond Namyst LIP - ENS Lyon

• Introduction to Grid computing and overview of the EU Data Grid Project The European DataGrid Project Team


Liste des sources/auteurs (suite)

• Bioinformatique distribuée : application dans le domaine de la parasitologie N. Jacq, E. Cornillot Laboratoire de Biologie des Protistes - CNRS - Clermont-Ferrand

• DIET Une approche extensible pour les serveurs de calcul E. Fleury,E. Jeannot INRIA Lorraine LORIA Nancy, France E. Caron, F. Desprez, M. Quinson, F. Suter INRIA Rhône-AlpesLIP ENS Lyon, France S. Contassot, F. Lombard, J.-M. Nicod, L. Philippe LIFC Besançon, France

• Supports d’exécution parallèles et répartis Raymond Namyst LaBRI Université de Bordeaux I Jean-François Méhaut GRIMAAG Université des Antilles-Guyane

• Le centre de calcul de l'IN2P3 : une architecture pour le calcul intensif et le stockage de masse Pascal Calvat

• Programmation Répartie Tronc commun – Module réseau Philippe Lalevée IAAI – 2004

• Étude de la parallélisation de méthodes heuristiques d’optimisation combinatoire. Application au recalage d’images médicales. LSIIT-ICPS Illkirch, le 11 décembre 2001 Michel Salomon


Liste des sources/auteurs (fin ?)

• … Et tout ceux que j’ai pu oublier


Pour en savoir plus …

• Applications scientifiques : • http://public.eu-egee.org/

• Architectures parallèles :• Algorithme et architecture parallèles, Michel Cosnard, InterEdition.

• LDAP : • http://www.openldap.org/ (OpenLDAP)• http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.

mspx (Active Directory)

• JBoss: • http://www.jboss.org/

• Tomcat : • http://jakarta.apache.org/tomcat/

• JAAS :• http://java.sun.com/products/jaas/

Annexe : scénario utilisateur


Allocateur

Un scénario utilisateur : soumission d'application

S.I.C.

e-Toile

S.P.A.M.

Globus Gram C.M.P.P.

Chargeur

G.U.I.D.E.

Application utilisateur

Cours Decembre 2004

Documents

Transcript of Cours Decembre 2004