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
Du client serveur aux 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
Du client serveur aux grilles de calcul et de données
Motivation générale : Les besoins : Physique
• Large Hadron Collider
• Modélisation de surface
• Applications nucléaires
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Motivation générale : Les besoins : Physique : LHC
• 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.
Du client serveur aux grilles de calcul et de données
The LHC Detectors
CMSATLAS
LHCb
~6-8 PetaBytes / year~108 events/year
~103 batch and interactive users
Le LHC :
Du client serveur aux grilles de calcul et de données
Motivation générale : Les besoins : Physique : 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.
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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, …)
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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é
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
Plan : Les différents types de parallélisme
• Introduction au parallélisme
• Les différents types de parallélisme
• Granularité
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de donné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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Plan : Les architectures parallèles et distribuées
• Les multiprocesseurs
• Les clusters
• Les environnements hétérogènes
• Les centres de calcul
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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é
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Les types de multiprocesseurs
Du client serveur aux grilles de calcul et de 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
Les types de multiprocesseurs
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Classification unifiée des types de multiprocesseurs
Du client serveur aux grilles de calcul et de données
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
Classification unifiée des types de multiprocesseurs
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architectures parallèles : exemple SIMD
Architectures de grappes de PC
Du client serveur aux grilles de calcul et de données
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 »
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Processeur
Pentium Alpha
NTLinux
OS
Solaris,...
SCI
Réseau
Ethernet
Giganet, ServerNet, ...Myrinet
SMP
biproc
quadriprocMono
Technologies :
? IA64
Du client serveur aux grilles de calcul et de données
L’interconnexion réseau
SCIVIA
Fibre Channel
HIPPI
FDDI
WDM
Infiniband
Ethernet
PCI
SAN WANMANLAN
...
ATM
...SCSI
Myrinet
...
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Les centres de calcul une architecture pour le calcul intensif et le
stockage de masse : le centre de calcul de la Doua
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture
• Architecture distribuée
• Stockage et calcul sont séparés
• Réseau local Gbits Ethernet
Du client serveur aux grilles de calcul et de données
Cluster
• 1000 processeurs (90% Linux Redhat 7.2)
• 500 KSpecInt2000 (P3 1GHz = 400 SpecInt2000)
• Soumission de job : BQS
• Calcul parallèle
Du client serveur aux grilles de calcul et de données
Stockage sur bande
• 6 silos gérant
36000 cartouches
• 720 To avec
cartouche 20 Go
• Données accessibles par HPSS
Du client serveur aux grilles de calcul et de données
Espace occupé sur serveur
• Serveur AFS 3 To
• Montage NFS1,5 To
• Cache HPSS6 To
• Serveur Objectivity20 To
• Capacité totale 60 To
Du client serveur aux grilles de calcul et de données
Réseau
• Hébergement d’un nœud Renater International NRI
• Très bonne connectivité
• Domaine in2p3.fr
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 …
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et 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)
Du client serveur aux grilles de calcul et de données
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 ...
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Intégration des applications
DomaineDomaineDomaineDomaine
UtilisateursUtilisateursUtilisateursUtilisateurs MachinesMachinesMachinesMachines ApplicationsApplicationsApplicationsApplications
FinanceFinanceFinanceFinance RHRHRHRH
PériphériquesPériphériquesPériphériquesPériphériques
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
MachinesMachinesMachinesMachines ApplicationsApplicationsApplicationsApplicationsPériphériquesPériphériquesPériphériquesPériphériques
Stockage hiérarchique
DomaineDomaineDomaineDomaine
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
Du client serveur aux grilles de calcul et de données
UUUU UUUU UUUU
AAAA AAAA AAAA
Modélisation sous forme d’objets
DomaineDomaineDomaineDomaine
UtilisateursUtilisateursUtilisateursUtilisateurs MachinesMachinesMachinesMachines ApplicationsApplicationsApplicationsApplications
CCCC CCCC CCCC
MarketingMarketingMarketingMarketing
PériphériquesPériphériquesPériphériquesPériphériques
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
LDAPUtilisation de LDP
Du client serveur aux grilles de calcul et de données
LDAPUtilisation de LDP
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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é.
Du client serveur aux grilles de calcul et de données
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).
Du client serveur aux grilles de calcul et de données
É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.
Du client serveur aux grilles de calcul et de données
Évolution de la sécurité JAVA
La SandBox 1.0
Du client serveur aux grilles de calcul et de données
Évolution de la sécurité JAVA
• 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 ».
Du client serveur aux grilles de calcul et de données
Évolution de la sécurité JAVA
Du client serveur aux grilles de calcul et de données
Évolution de la sécurité JAVA
• 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 ».
Du client serveur aux grilles de calcul et de données
Évolution de la sécurité JAVA
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
• Quelques exemples de tout cela :
- Une applet critique exécutée localement fonctionne sans problème.
C:\> java WriteFileApplet
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
• Quelques exemples de tout cela :
• 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
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
• Quelques exemples de tout cela :
- Un outil permettant d’écrire facilement des fichiers « policy » : Policytool.exe
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
• Quelques exemples de tout cela :
• 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
Du client serveur aux grilles de calcul et de données
La protection de l’utilisateur
• Quelques exemples de tout cela :
• Un dernier exemple avec un browser.
• Il est plus difficile de spécifier le fichier « policy » à utiliser…..
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Java Authentification & Autorisation
• 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.
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• 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
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification (chronologie)
new LoginContext( "Nom de configuration", MyCallbackHandler);
LoginContextLoginContext
ConfigurationConfiguration
Configuration.jaas (liste des modules
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification (chronologie)
LoginContextLoginContext
ConfigurationConfiguration
Configuration.jaas (liste des modules)
LoginModule 1LoginModule 1
LoginModule 2LoginModule 2
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification (chronologie)
LoginContextLoginContext
ConfigurationConfiguration
Configuration.jaas (liste des modules)
LoginModule 1LoginModule 1
LoginModule 2LoginModule 2
Login( )
USERCallBackHandlerCallBackHandler
Login( )
Login( )
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification (chronologie)
LoginContextLoginContext
LoginModule 1LoginModule 1
LoginModule 2LoginModule 2
Login( )
USERCallBackHandlerCallBackHandler
SubjectSubject
Droits.policy
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification (chronologie)
LoginContextLoginContext
LoginModule 1LoginModule 1
LoginModule 2LoginModule 2
Login( )
USERCallBackHandlerCallBackHandler
SubjectSubject DoAsPrivileged( ) PrivilegedActionPrivilegedAction
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
Focus sur les CallbackHandler
- Le dialogue est délégué :
LoginContextLoginContext
LoginModuleLoginModule
CallbackHandlerCallbackHandler
USERUSER
CallBack[]CallBack[]
Du client serveur aux grilles de calcul et de données
Focus sur les CallbackHandler
• Les callback sont utilisés pour compléter le « Subject ».
LoginContextLoginContext
LoginModuleLoginModule
CallbackHandlerCallbackHandler
CallBack[]CallBack[]
SubjectSubject GetSubject()
Du client serveur aux grilles de calcul et de données
Focus sur les Callback
• Les differents types de Callbacks :
• Language Callback
• Name Callback
• Password Callback
• TextInput Callback
• TextOutput Callback
• Choice Callback
• Confirmation Callback
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• 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
};
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• Les mots clés du fichier .jaas :
• Required : non bloquant
• Requisite : bloquant
• Sufficient : bloquant
• Optional : non bloquant
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• Exemple :
Module Criterion Pass/Fail
SampleLoginModule Required OK
NTLoginModule Sufficient !OK
SmartCard Requisite OK
Kerberos Optional !OK
Overallauthentication
OK
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• Exemple :
Module Criterion Pass/Fail
SampleLoginModule Required !OK
NTLoginModule Sufficient OK
SmartCard Requisite
Kerberos Optional
Overallauthentication
OK
Du client serveur aux grilles de calcul et de données
JAAS : L’authentification
• 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>
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
JAAS : L’ autorisation
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";};
Du client serveur aux grilles de calcul et de données
JAAS : L’ autorisation
• 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);
Du client serveur aux grilles de calcul et de données
JAAS : L’ autorisation
• 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; }}
Du client serveur aux grilles de calcul et de données
JAAS : L’ autorisation
• 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>
Du client serveur aux grilles de calcul et de données
JAAS : Mise en place
• Mise en place d’une authentification JAAS :
• Implémenter les interfaces suivants :• CallBackHandler
• Handle()
• LoginModule• initialize()• login()• commit()• Abort()
Du client serveur aux grilles de calcul et de données
JAAS : Mise en place
• Mise en place d’une authentification JAAS :
• Implémenter les interfaces suivants :
• Principal• getName()
• PrivilegedAction• run()
Du client serveur aux grilles de calcul et de données
Java Authentification & Autorisation
• 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
Du client serveur aux grilles de calcul et de données
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.”); }}
Du client serveur aux grilles de calcul et de données
Example
import javax.security.auth.*;import javax.security.auth.login.*;
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 }}
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.”); }}
• Establish a context by which a user can be authenticated
• Argument references a line in a config file (later)
Du client serveur aux grilles de calcul et de données
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 {try { lc.login();lc.login(); } catch (Exception e) {} catch (Exception e) { // login failed -- handle and exit// login failed -- handle and exit }}
Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); }}
• Authenticate the user following steps in configuration file
Du client serveur aux grilles de calcul et de données
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.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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Objet distribué (rmi)
Du client serveur aux grilles de calcul et de données
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}
Du client serveur aux grilles de calcul et de données
Middleware implicite
Du client serveur aux grilles de calcul et de données
Architecture multi-tiers
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture d’une application J2EE
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Les technologies
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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) {}
}
Du client serveur aux grilles de calcul et de données
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;
}
Du client serveur aux grilles de calcul et de données
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;
}
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
Déploiement (suite)
<assembly-descriptor>
<method-permission>
<role-name>user<role-name/>
<method>
<ejb-name>CartEJB</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getContents</method-name>
<method-params />
</method>
</method-permission>
<container-transaction>
<method>
<ejb-name>CartEJB</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getContents</method-name>
<method-params />
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
Du client serveur aux grilles de calcul et de données
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();
}
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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() { }
}
Du client serveur aux grilles de calcul et de données
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;
}
Du client serveur aux grilles de calcul et de données
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;
}
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
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()
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
EJB Object
Du client serveur aux grilles de calcul et de données
Paquetage d’application
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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é
• …
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
Exemple d’application J2EE
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
Application multi-tiers
L’application Web est décomposée en plusieurs
parties (tiers)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Configuration Tomcat (3)
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"
Du client serveur aux grilles de calcul et de données
Configuration Tomcat (4)
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"
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Hello World
Le conteneur de servlets fait l’association entre l’URL et la servlet
Du client serveur aux grilles de calcul et de données
Hello World (2)
Répertoires sur le serveur
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Informations sur la requête (3)
Informations sur la requête
URL complète
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
En-têtes de la requête
Entêtes
Informations sur la requête
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
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"
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
Les formulaires GET (2)
Utilisation des méthodes getParameter*()
protected void doGet(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
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Inclusion & Redirection (2)
La redirection n’est pas visible au niveau du client
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
getServletContext().getRequestDispatcher("/index.html"). forward(request,response); }
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Session (3)
Ouverture et fermeture d’une session
Du client serveur aux grilles de calcul et de données
Session (4)
Requête GET sur la servlet
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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>
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Authentification : Servlet (2)
Authentification avant l’appel à la servlet
Du client serveur aux grilles de calcul et de données
Les filtres
ServletFiltre Filtre
Requête
RequêteRequête
Réponse
RéponseRéponse
Hello World
Hello World Filtré
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Administration de Tomcat
Même informations que dansle fichier server.xml
Du client serveur aux grilles de calcul et de données
Ajouter un nouveau rôle
Sur les Rôles
Créé un nouveau rôle
Rôle manager créé
Du client serveur aux grilles de calcul et de données
Ajouter un rôle à un utilisateur
L’utilisateur admindevient un manager
de servlets
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Manager de Servlet
Du client serveur aux grilles de calcul et de données
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})" />
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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’
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)) !
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Définition
Approche pour la distribution de la puissance électrique = le réseaux électrique et la haute-tension
Du client serveur aux grilles de calcul et de données
Définition
Approche pour la distribution de la puissance informatique = le réseau Internet et la haute-performance
(parallélisme et distribution)
Du client serveur aux grilles de calcul et de données
Et ses différentes incarnations…
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 »
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture des grilles de calcul et de données : gestion de ressources
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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”
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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)
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
• 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
Du client serveur aux grilles de calcul et de données
• 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
Du client serveur aux grilles de calcul et de données
• Clé publique• Sert à chiffrer le message
• Clé privée• Sert à déchiffrer le message
CryptographieChiffrement Asymétrique
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
• 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
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
• 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
Du client serveur aux grilles de calcul et de données
• Algorithme RSA = Réversible
• ((Mess)CPu)CPr = ((Mess)CPr)CPu
• Confidentialité
• Authentification
Technique A Clé PubliquePrincipe
Du client serveur aux grilles de calcul et de données
Technique A Clé PubliqueConfidentialité
Le Texte est totalement confidentiel car le
destinataire est le seul a avoir la clé privée
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
– 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)
Du client serveur aux grilles de calcul et de données
–Pb du hachage : on est pas sur de l’expéditeur Scellement des données
Signature électronique (2)
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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é.
Du client serveur aux grilles de calcul et de données
CertificationCertificatX509
Du client serveur aux grilles de calcul et de données
CertificationExemple Certificat X509
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
PKI - Organisation
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Microsoft .NET Passport
• 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
Du client serveur aux grilles de calcul et de données
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
Microsoft .NET Passport
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• PGP
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
• 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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Sommaire
• Introduction
• Cryptographie
• Authentification
• Certification
• PGP
• Microsoft .NET Passport
• Kerberos
• SSL
Du client serveur aux grilles de calcul et de données
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, …)
Du client serveur aux grilles de calcul et de données
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://
Du client serveur aux grilles de calcul et de données
SSLPhase de Négociation
• Authentification
• 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
Du client serveur aux grilles de calcul et de données
mécanismes
• Infrastructure de Gestion de Clés
• Infrastructure de Gestion des Privilèges
• Délégation
Du client serveur aux grilles de calcul et de données
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, ..)
• …
Du client serveur aux grilles de calcul et de données
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
• …
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Infrastructure de gestion des privilèges (2)
• 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)
Du client serveur aux grilles de calcul et de données
Infrastructure de gestion des privilèges (3)
• 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
•
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture de confiance
• Architecture PKI
• Architecture PMI
• Association PKI et PMI
• Application Au Grid
Architecture PKI
Du client serveur aux grilles de calcul et de données
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é
Du client serveur aux grilles de calcul et de données
Architecture PKI (2)
• 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é
Du client serveur aux grilles de calcul et de données
Architecture PKI (3)
• 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
Du client serveur aux grilles de calcul et de données
Architecture PKI (4)
• 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
Du client serveur aux grilles de calcul et de données
Architecture PKI (5)
• 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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture avec même source de confiance PKI et PMI
• 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
Du client serveur aux grilles de calcul et de données
• 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
Architecture avec même source de confiance PKI et PMI
Du client serveur aux grilles de calcul et de données
Architecture avec même source de confiance PKI et PMI
• 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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Grids
Du client serveur aux grilles de calcul et de données
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)
• …….
Du client serveur aux grilles de calcul et de données
Grid : Quelques caractéristiques (2)
• 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
Du client serveur aux grilles de calcul et de données
Grid : Quelques caractéristiques (3)
• 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
Du client serveur aux grilles de calcul et de données
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
• ……
Du client serveur aux grilles de calcul et de données
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é
Du client serveur aux grilles de calcul et de données
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..
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Architecture de sécurité : délégation (3)
• 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
Du client serveur aux grilles de calcul et de données
Architecture de sécurité : délégation (4)
Canal sécurisé TLS
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
Tâche
Du client serveur aux grilles de calcul et de données
Architecture de sécurité : délégation (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
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
Du client serveur aux grilles de calcul et de données
Architecture de sécurité : délégation (6)
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Environnement des communications
• Problèmes
• Support des architectures grilles
• Routage
• Multiplexage
• Dynamicité
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Infrastructure
Processus
Gestionnaire de communications
Dynamicité
Support d’architectures évolutives
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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 ?
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Plan : Perspectives pour les grilles de calcul et de données
• Perspectives• Prochain standards• Projets en cours• Tendances actuelles
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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.
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
Liste des sources/auteurs (fin ?)
• … Et tout ceux que j’ai pu oublier
Du client serveur aux grilles de calcul et de données
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
Du client serveur aux grilles de calcul et de données
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