Soutenance mémoire
ETAT DE L’ART SUR LA DISTRIBUTION
Les besoins en informations et l’utilisation des données peuvent être variés en fonction du site. De ce fait, une organisation centralisée des données peut être non adéquate à cette architecture répartie. Par exemple un entrepôt de données réparti pourra répondre plus efficacement aux besoins des utilisateurs. Les données peuvent être organisées par sujet et une m eilleure utilisation de l’entrepôt est garantie. Cependant, nous présentons l’intérêt de la répartition en présentant trois systèmes répartis.
REPARTITION DES RESSOURCES
Les systèmes informatiques centralisés permettent une ut ilisation optimale des ressources mais surtout une gestion des données en mode centralisé ; ils se prêtent très bien aux traitements par lots (batch). En revanche, dans le cas des entrepôts des données, des contraintes signifient que la centralisation peut se refléter négativement sur sa performance et ses objectifs. Les systèmes centralisés ont subi une dégr adation due principalement aux avancées considérables de l’informatique qui ont favorisé l’émergence de nouvelles architectures constituées d’ordinateurs géographiquement distribués. Il s’agit des systèmes distribués . De nouveaux concepts sont proposés pour désigner ces systèmes, tels que: multiordinateur, ou réseau de stations de travail (Network of Workstation) ou, plus récemment, réseau pair à pair (Peer-to-Peer Computing) ou grille de calcul (Grid Computing) .
Les systèmes répartis
Principe
Un système réparti englobe une classe de systèmes classiques comme : système clientserveur, système multi-agents. Ils sont caractérisés par un principe de fonctionnement simplifié et permettent une g estion de données efficace à c ertaine échelle. Bien que, une multitude de travaux ont été proposées par la plus part des équipes de recherche dans ce domaine.
Avantages
Une gestion décentralisée nécessite quelques points qui sont :
• Plusieurs machines de natures différentes peuvent être reliées et ainsi pouvoir échanger de l’information. La configuration d’une architecture distribuée peut croître en fonction des besoins réels des utilisateurs.
• Une plus grande disponibilité c-à-d un élément défaillant d’une architecture peut être mis hors service sans entraîner un arrêt complet du système. Les traitements effectués par cet élément défaillant peuvent être éventuellement repris sur une autre machine de l’architecture distribuée.
Inconvénients
Sensibilité et instabilité aux défaillances : pour chaque nœud, il existe un chemin à tout autre nœud du gr aphe alors les sites peuvent communiquer soit directement, soit indirectement via les canaux de communications par conséquence, la défaillance d’un canal ou d’un processus modélise une défaillance affectant un nœud ou une l igne du réseau. Avec l ’architecture client-serveur, la mémoire commune est localisée sur un ou plusieurs sites serveurs. Elle n’est pas directement visible par les sites clients, mais seulement par l’intermédiaire d’une interface procédurale. Quand les clients accèdent fréquemment à l a mémoire commune, le serveur devient goulot d’étranglement, et le coût de c ommunication devient prohibitif : le client-serveur ne pas se pas à l’échelle. Ceci montre l’intérêt de la réplication, sur « le partage d’information dans les systèmes répartis de grande échelle » .
D’autre part, dans le paradigme des agents mobiles, la mémoire partagée est l’union des mémoires locales. C’est le programme applicatif lui-même qui se déplace vers les données dont il a besoin.
Bilan
Si les systèmes classiques ont permis la mise en œuvre de mécanismes efficaces de partage de données à petite échelle, d’autres types de s ystèmes répartis se sont focalisés sur la gestion des données à grande échelle. Cependant, un autre paradigme de stockage et calcul global a r écemment focalisé l’intérêt de l a communauté scientifique : systèmes pair-à-pair (peer to peer). Ce modèle complémente le monde classique client-serveur qui est aujourd’hui à la base de la plupart des traitements sur internet. Les systèmes pair-à-pair ont permit d’agréger des centaines de milliers de nœuds. En effet, les systèmes pair à pai r sont souvent plus tolérants aux pannes, assent plus facilement à l ’échelle, et sont plus adaptatifs que l eurs contreparties client/serveur.
Les systèmes pair-à-pair
a) Principe
Pair-à-pair désigne une classe d’applications informatiques dédiées à l ’échange point multipoint. Ces applications symétrisent la relation des machines (noeuds) qui interagissent.
b) Avantages
Les avantages des systèmes pair-à-pair ou s ystèmes dits à gr ande échelle sont nombreux. Ils donnent accès à un grand nombre de ressources, dont le nombre de pairs est supérieur à 10x (x > 2). Ils disposent d’une a dministration transparente. Un système pair à pai r évolue sans machine(s) dédiée(s) pour son administration. Ces systèmes sont conçus de telle sorte qu’aucun des pairs ne soit indispensable au fonctionnement général : le système n’est pas paralysé par la défaillance d’un o u plusieurs pairs. Les qualités de ce système (robustesse, disponibilité, performances…) augmentent avec le nombre d’utilisateurs, et présentent de nombreux avantages (décentralisation, pas de coûts d’infrastructure…).
c) Inconvénients
En contrepartie, de p ar la volatilité des pairs, le réseau est non fiable. De plus, des problèmes de s écurité peuvent survenir à cause de c ertains pairs malveillants non écartés du réseau. Ce système ne p eut pas assurer la confidentialité des données échangées et les vitesses de t ransfert sont aléatoires. Chaque utilisateur faisant office de c lient et de serveur, ils doivent partager leur bande passante entre ces deux activités. Cette bande passante doit, de plus, être partagée entre tous les clients qui téléchargent en m ême temps ce fichier, par conséquent, les temps de t éléchargement peuvent être relativement long. Donc, une ressource sur un tel système a une durée de vie parfois limitée. Un fichier accessible sur un réseau pair à pair peut très bien ne plus l’être dans l’heure qui suit. Il suffit pour cela que les rares possesseurs de ce fichier ne le mettent plus à disposition au même moment.
d) Bilan
Bien que le système pair à pair impose de par sa nature une gestion complexe, mais dispose d’une administration transparente et un accès à un grand nombre de ressources. Aujourd’hui, ces systèmes apparaissent sous différentes applications l’une différente de l’autre, en terme de qualité de service et les exceptions marquées entre ces dernières, d’après les rapports techniques et études comme ceux présenté dans [2]. Finalement, les inconvénients des systèmes pair-à-pair participent grandement à l a diminution de l’efficacité d’un tel système, ce qui favorise de penser à l’optimisation de l’ensemble de pr otocoles et techniques faisant partie de l’architecture pair-à-pair. Par conséquent, nous allons faire un passage à l’analyse d’un autre système à gr and échelle: les Grilles informatiques.
|
Table des matières
INTRODUCTION
I.1 Contexte
I.2 Objectifs
I.3Plan
II-1 REPARTITION DES RESSOURCES
II.1.1 Les systèmes répartis
II. 1.2 Les systèmes pair-à-pair
II.1.3 Les Grilles informatiques
A-2 Fonctionnement d’une grille : le middelware
Ces ressources sont en générale réparties en plusieurs types
III-1 L’INTERGICIEL D’ACCES AUX GRILLES DE CALCUL GLOBUS
III-1.1 La sécurité
III-1.2 La gestion de ressources et de données
III -2 ETUDE DETAILLEE DU MDS
III-2.1 Fonctionnement
III- 2 .2 Approche Mds
III-2.3 Composants du MDS
III-2-4 Insuffisances du MDS
III.3 PRINCIPALES ARCHITECTURES DISTRIBUEES
III.3.1 Table de hachage distribué Chord
III.3.1.2 Amélioration de l’Algorithme de base
II.3 ETUDE COMPARATIVE
IV.1 INTRODUCTION
IV.2 RAPPEL SUR LES ARBRE
IV.2.1 ARBRE BINAIRES
IV -2.2 ARBRES AVL
IV.3 STRUCTURE DE LA GRILLE
IV.4 NOTRE APPROCHE DE DISTRIBUTION DE L’ANNUAIRE
IV.5 L’AJOUT (NŒUD OU SITE)
IV.7 LA SUPPRESSION (NŒUDS OU SITE)
IV.8 LA RECHERCHE DE RESSOURCES
IV.4.1 SOLUTION 1 : Inondation
IV.4.2 SOLUTION 2
V.1 VALIDATION THEORIQUE
V.1.1 COMPLEXITE
V.1.2 OVERHEAD (charge)
V.1.3 GESTION RESSOURCE
V.1.4 Conclusion
V.2 VALIDATION PRATIQUE : EXPERIMENTATION
V.2.1 Choix d’un outil de simulation
IV.2.2 Expérimentation
IV.2.2 .3 Premiers résultats
V.1 CONCLUSIONS
V.2 PERSPECTIVES
CONCLUSION
