Soutenance mémoire
Architecture à mémoire partagée : Shared-Memory
Dans une architecture à mémoire partagée, les disques et les mémoires centrales sont physiquement partagés par tous les processeurs du système. Cette architecture présente l’intérêt de fournir un modèle de programmation simple dans la mesure où chaque processeur accède de manière transparente à la mémoire commune. L’équilibre de charge entre les processeurs est facile à réaliser et l’accès aux données est possible même en cas de panne d’un ou de plusieurs processeurs. Cependant, les accès conflictuels peuvent créer un goulot d’étranglement et dégrader considérablement les performances du système. De plus, l’ajout d’un nouveau nœud entraîne des modifications importantes au niveau du matériel. Ce modèle est n’est donc pas extensible et assez coûteux.
Architecture Client/Serveur
C’est un modèle d’architecture où les programmes sont répartis entre processus clients et processus serveurs. Le client envoie une requête au serveur sachant son adresse et son port d’écoute spécifique au service demandé. Le serveur reçoit la demande, la traite puis envoie la réponse au client. Dans un environnement purement client/serveur, les clients ne peuvent voir que le serveur. Il n’y a donc pas de dialogue ente les clients. Ces derniers peuvent être supprimés ou rajoutés sans perturber le fonctionnement du réseau ni modifier son architecture. Le réseau est donc évolutif. Le serveur gère les ressources communes à tous les utilisateurs évitant ainsi les problèmes de cohérence et améliore la sécurité. Le serveur est donc au centre du réseau, ce qui facilité certes son administration mais rend le système très vulnérable aux pannes.
Stratégies de distribution des données
L’une des composantes essentielles d’un système distribué est le gestionnaire de fichiers distribués (DFS : Distributed File System). Il se charge de répartir les données et les programmes sur les différents sites (nœuds) du réseau offrant ainsi une plus grande disponibilité des fichiers. La première approche de distribution utilisée dans un système de fichiers distribués est celle qui consiste à stocker chaque fichier sur un site unique. Plusieurs produits commercialisés ont adopté cette technique, en particulier NFS (Network File System) et AFS (Andrew File System). Cette approche engendre des limitations bien connues concernant d’une part, la taille du fichier qui est limitée par l’espace disque disponible sur un seul site, et d’autre part, la scalabilité des performances d’accès et la vulnérabilité aux pannes. Pour dépasser ces limitations, de nouvelles méthodes, reposant sur l’idée de distribuer le fichier sur plusieurs serveurs, sont apparues. Il en existe deux catégories : statiques et dynamiques.
Principe des SDDS
Un fichier SDDS réside initialement sur un seul site de stockage ; il est ensuite étendu dynamiquement à n’importe quel nombre de sites appelés nœuds ou serveurs. Contrairement aux schémas classiques où l’ajout d’un nouveau nœud nécessite une réorganisation totale du fichier, les SDDS permettent une extension du nombre de serveurs avec un coût minimal. Cette extension se fait par des éclatements de sites débordés suite à des insertions d’enregistrements. Et les enregistrements sont répartis sur les serveurs suivant la valeur de leur clé et l’état du fichier. Les serveurs sont accessibles à partir de stations autonomes appelées clients. L’un des objectifs majeurs des SDDS est de minimiser le nombre de messages nécessaires pour accéder à un enregistrement du fichier. Typiquement, l’accès à un enregistrement nécessite deux messages : un message pour envoyer la requête et un autre pour envoyer l’enregistrement demandé. Chaque client a sa propre image de la structure du fichier. Elle lui permet de calculer l’adresse du serveur où est supposé se trouver un enregistrement de clé c. Cette image n’est pas globalement exacte, car les mises à jour de la structure du fichier ne sont pas envoyées aux clients d’une manière synchrone. Cette stratégie permet de minimiser les coûts de communication entre clients et serveurs car une mise à jour synchrone des images deviendrait très coûteuse lorsque le nombre de clients est élevé. Un client peut alors faire une erreur d’adressage par suite d’une image devenue inexacte. Le serveur cible lui envoie alors un message correctif. Ce message est appelé message d’ajustement de l’image du client (IAM : Image Adjustment Message). Le client corrige son image pour ne pas refaire la même erreur. Parallèlement à la mise à jour de l’image du client, le serveur redirige la requête vers le serveur adéquat. Ce dernier l’exécute et s’il n’y a pas d’erreur d’adressage il envoie la réponse au client.
Les variantes à haute disponibilité
Ces variantes permettent de préserver la disponibilité des données en cas de panne d’un ou de n serveurs. Plus la taille du fichier augmente plus n doit être grand afin de compenser la baisse de fiabilité due à l’étalement du fichier. Car, Un fichier distribué sur N nœuds a une probabilité de disponibilité égale à pN , où p désigne la probabilité de disponibilité d’un nœud. Notons que, quand N croit, pN converge vers zéro. Pour pallier cet inconvénient, le concept de haute disponibilité a été appliqué à LH*. Plusieurs techniques de récupération sont actuellement connues.
1) Technique des miroirs (mirroring) :Le principe des miroirs ou haute disponibilité par réplication, découle du principe de sauvegarde. Il consiste à sauver les données sur d’autres nœuds de stockage et à définir une stratégie de propagation des mises à jour (synchrone ou asynchrone) vers les sites miroirs [MOU04]. L’atout majeur est que les sites miroirs sont fonctionnels et interrogeables. Par contre, le principal inconvénient des solutions à base de réplication de données est le coût de stockage qui est facteur du nombre de répliques. Un exemple de l’utilisation des miroirs dans LH* est LH*M [LIT96a].
2) Technique de fragmentation (Stripping) :Ce schéma nécessite moins d’espace de stockage que le schéma à miroirs mais les opérations de mises à jour demandent plus de temps et utilisent plus de messages. La segmentation peut être effectuée au niveau bit, bloc ou attribut. LH*S [LIT97a] est une amélioration de LH* se basant sur la fragmentation. Un fichier LH*S est constitué de k+1 fichiers segments LH*, S1… Sk+1. Le fichier segment de parité Sk+1 permet la récupération des données perdues appartenant à un fichier segment de données. Le schéma LH*S est dit 1-disponible car il tolère l’échec d’un seul nœud. Il présente également un aspect de sécurité renforcé. En effet, pour une segmentation au niveau bit, chaque fichier segment n’a qu’un bit de k bits consécutifs d’un enregistrement. En désignant par x le nombre de bits manquants, un intrus doit énumérer les 2x possibilités pour reconstituer l’article. La sécurité de LH*S est au prix d’une complexité dans la restitution et la recherche des enregistrements, puisque les manipulations du client nécessitent une coopération de tous les segments. Ainsi, une variante de LH*S, se propose de faire la fragmentation au niveau attributs
SDDS basées sur les arbres
Le schéma de distribution RP* (acronyme de Range Partitioning) a été proposé par Litwin, Neimat et Schneider [LIT94]. Un fichier RP* est une collection de cases, contenant des enregistrements identifiés par un champ clé. Chaque case est organisée en B-arbre et un intervalle ]!, »] lui est associé. Cet intervalle détermine l’ensemble des clés des enregistrements appartenant à la case. Initialement, un fichier RP* ne contient qu’une seule case : la case 0. Cette dernière est d’intervalle ] – #, + # [. Le fichier évolue à travers les éclatements de cases. En effet, chaque case RP* a une capacité maximale de b enregistrements. Une case surchargée éclate. L’éclatement consiste à transférer approximativement la moitié du contenu de la case surchargée vers une nouvelle case RP*. La définition de la clé de division est stratégique pour l’équilibre de charge. Plusieurs variantes du schéma RP* ont été développées, notamment RP*N, RP*C et RP*S ainsi que des variantes gérant l’accès multi-clé [LIT95] et la haute disponibilité [DIE01]. Dans la suite de cette section, nous présentons brièvement chacune de ces variantes.
Act21
Ce projet a été développé à l’Institut National d’Informatique (Algérie) [HID03]. Il visait la création d’un nouveau modèle pour des bases de données réparties ou parallèles à base d’objets actifs (acteurs) et utilisait les structures de données distribuées et scalables comme méthode de distribution. Ainsi, une nouvelle méthode SDDS a été mise au point, CTH* (Distributed Compact Trie Hashing).
|
Table des matières
Introduction
Chapitre I : Systèmes Distribuées et Structures de Données Distribuées et Scalables
1 Systèmes distribués
1.1 Architectures matérielles
1.2 Architectures logiques
1.3 Stratégies de distribution des données
2 Les SDDS (Structures de Données Distribuées et Scalables)
2.1 Principe des SDDS
2.2 Caractéristiques des SDDS
2.3 Performances d’accès d’une SDDS
2.4 Classification des SDDS
2.5 Projets sur les SDDS
3 Synthèse
Chapitre II : Hachage Digital Compact Distribué (CTH*)
1 Hachage digital compact (Compact trie hashing)
1.1 Mécanisme de construction
1.2 Expansion de l’arbre
1.3 Opérations sur le fichier
1.4 Performances de la méthode CTH
2 Hachage digital compact distribué (Distributed Compact Trie Hashing).
2.1 Concepts
2.2 Expansion du fichier
2.3 Opérations sur le fichier
2.4 Mise à jour de l’image du client
2.5 Travaux sur CTH*
2.6 Plateforme existante
3 Synthèse
Chapitre III : Environnements mobiles
1 Schéma d’architecture des réseaux mobiles
2 Générations des réseaux mobiles
2.1 Première Génération (1G)
2.2 Deuxième génération (2G)
2.3 Evolutions de la deuxième génération (2,5G)
2.4 Troisième génération (3G)
2.5 Quatrième génération (4G)
3 Transmission de données dans les réseaux mobiles
4 Protocoles de transmission de données
4.1 WAP (Wireless Application Protocol)
4.2 i-mode
5 Téléphone mobile
5.1 Composants matériels
5.2 Plateforme logicielle
6 Limitations des environnements mobiles
6.1 Contraintes liées au réseau mobile
6.2 Contraintes liées au téléphone mobile
7 Synthèse
Chapitre IV : Conception et réalisation
1 Architectures
1.1 Architecture générale
1.2 Architecture du client fixe
1.3 Architecture du serveur
1.4 Architecture de coordinateur
1.5 Architecture du client mobile
1.6 Architecture du préserveur
2 Protocole de communication CTH*
2.1 Description du protocole CTH*
3 Implémentation et mise en œuvre
3.1 Environnement de développement
3.2 Outils techniques de mise en oeuvre
4 Interface de l’application
5 Synthèse
Chapitre V : Validation et tests
1 Environnement expérimental
2 Tests de validité
3 Tests de performances
Insertion
Requête à intervalle
Facteur de chargement
4 Synthèse
Conclusion
Bibliographie
Liste des abréviations
Télécharger le rapport complet
