Université de Technologies de Troyes. Distribution des données et des métadonnées médicales dans un environnement de grille

Transcription

1 Université de Technologies de Troyes Ecole Doctorale SSTO DEA Réseaux Avancés de Connaissances et Organisations (RACOR) Rapport de Stage de DEA Distribution des données et des métadonnées médicales dans un environnement de grille Rida Khatoun Encadrant : Johan Montagnat Laboratoire CNRS-I3S, Université de Nice Sophia-Antipolis 01 Mars 2004 au 01 Septembre 2004

2 Remerciements Mes premiers remerciements, et sans doute les plus vifs, sont adressés à mon encadrant de stage, monsieur Johan Montagnat. Je lui suis également reconnaissant pour les qualités scientifiques et pédagogiques de son encadrement, pour l organisation impressionnate de ce stage et pour la disponibilité sans faille dont il a fait preuve durant ces six mois du travail. Je tiens à remercier aussi mon responsable de stage à Troyes monsieur Marc Lemercier pour son encadrement J adresse également de sincères remerciements à l ensemble du personnel du laboratoire I3S (Informatique signaux et systèmes de Sophia Antipolis) de m avoir aussi bien accueilli au sein de leurs établissement. Enfin, je remercie mes parents, mes amis et mes collègues pour le soutien moral tout au long de ce stage.

3 Table des matières 1 Introduction La gestion des données et des métadonnées médicales Particularités des données et des métadonnées médicales Contexte Objectifs État de L Art Gestion de données Duplication des données Modèle centralisé versus modèle décentralisé Modèle Client/Serveur Modèle Pair-à-Pair JuxMem : gestion de données P2P sur JXTA La plate-forme générique pair-à-pair JXTA JuxMem : Juxtaposed Memory Gestion de données avec Storage Resource Broker Conclusion Storage Resource Broker Définitions Les composants de SRB L architecture de SRB Interfaces de SRB Gestion des données en SRB Duplications des données Gestion des groupes et des utilisateurs Ticketing et Schmod Sécurité des données et des transmissions SRB et la gestion des données médicales SRB : Mise en oeuvre et evaluation de la performance Concept de l évaluation de la performance Mise en oeuvre de SRB Environnement de développement Méthodologies de tests i

4 TABLE DES MATIÈRES ii 4.3 Evaluation de la performance Metadata Catalogue database MCAT Serveur MCAT et Serveurs non-mcat Conclusion SRB et la distribution des données médicales Le modèle pair à pair et SRB Perspectives

5 Chapitre 1 Introduction 1.1 La gestion des données et des métadonnées médicales A l heure actuelle les centres radiologiques d acquisation d images médicales utilisent des systèmes de génération d images numériques de haute résolution. Une simple image médicale 3D (donnée médicale) de ce genre peut contenir plus qu un Gigaoctet de données. Ceci résulte en un volume d images générées de 10 To par an environ dans un centre radiologique et entraine une grande quantité d informations à stocker et à traiter. Traditionnellement et pour résoudre les problèmes de sécurité, les images numériques générées par les appareils d imagerie sont stockées et traitées sur un réseau local interne à l hôpital, ce qui limite les possibilités en fonction de la capacité de calcul et de stockage disponible. L état actuel de la génération des images médicales dans les centres radiologiques ou les hôpitaux est illustré dans la figure 1.1. Un des principaux objectifs de la réalisation d un réseau médical de données consiste à faciliter et assurer une meilleure diffusion de ces données aux médecins et aux autres intervenants du domaine de la santé. Ce réseau ne prend tout son sens que si les données convoyées sont complètes et facilement accessibles quel que soit la localisation de l utilisateur. Dans ce contexte, le développement considérable des systèmes de stockage et de communication numérique de l information ainsi que du matériel informatique permet un accès de plus en plus facile aux images sous forme numérique. Le problème majeur des images médicales est la taille considérable qu elles occupent lorsqu elles sont manipulées sous forme numérique. Un autre problème des images médicales est la confidentialité de ce type de données. Des mécanismes de gestion des droits d accès aux images et de chiffrement durant les transmissions sont nécessaires pour sécuriser les données. En fait, les informations associées aux images (nom du patient, taille de l image,...), qui sont appelées les métadonnées, doivent également être prises en considération. La nature d accès aux données et aux métadonnées n est pas la même, ceci complique aussi le problème. Dans l environnement des différents hôpitaux et des centres radiologiques où les images médicales sont acquises par différentes sources (IRM, scanners, échographes, etc) les images sont stockées dans un format standard DICOM pour Digital Imaging and Communications in Medicine. DICOM est le nom d une norme utilisée pour enregistrer les images médicales sur support numérique. De plus DICOM introduit la notion des métadonnées. En effet, un fichier DICOM contient des informations textuelles concernant le patient (état civil, âge, 1

6 1.2 Particularités des données et des métadonnées médicales 2 poids), l examen (région explorée), la technique utilisée (scanner, IRM, etc...), mais aussi des données brutes qui sont les images elles même. Dans les formats d image classiques (à part quelques exceptions récentes), il n est pas possible d ajouter des données textuelles comme dans une base de données. DICOM permet, pour chaque image, de spécifier toutes les caractéristiques du patient et de l examen. Dans le milieu hospitalier on assiste aussi à des developpements de systèmes d archivage et de communications des examens radiologiques sous forme numérique (PACS : Picture Archiving and Communication Systems). Le PACS est l architecture informatique qui permet de récupérer les images et les métadonnées associées, de les archiver et de les mettre à la disposition des médecins et des spécialistes. Cependant, les PACS actuels sont dans une large mesure limités au réseau local de l hôpital. 1.2 Particularités des données et des métadonnées médicales Les données et les métadonnées médicales sont des données informatiques avec des particuliarités spécifiques dépendant de leur nature dans le domaine médicale et de leur distribution dans un réseau. Ces particularités peuvent être définies par trois points : Modes d accès : Les métadonnées représentent de petites quantités d informations et peuvent être mises à jour fréquement : il est nécessaire qu elles soient accessibles de manière classique en lecture-écriture (mode R/W : read-write). En revanche, la plupart des images médicales ne sont accessibles qu en lecture seule (on ne veut en aucun cas détruire les images sources). Dans le cas d image secondaire (c est à dire d images obtenues après traitement des images sources acquises, et donc reproductible), il peut être souhaitable de détruire ou de remplacer ces données. Le remplacement se faisant sous la forme d une mise à jour complète du fichier image (il n est pas utile de pouvoir mettre à jour une partie du fichier seulement), on parlera de mode read-replace (mode R-R). Les données médicales et leurs métadonnées sont confidentielles et nécessitent la mise en oeuvre d un mécanisme (ex. droits d accès) pour assurer la protection des patients. Droits d accès : Les données médicales et leurs métadonnées peuvent être consultées par plusieurs catégories d utilisateurs : le patient qui veut accéder à son dossier médical (lecture seule), le médecin qui doit avoir l accès aux données des patients traités dans son service (lecture et écriture) et le chercheur qui a besoin d accéder aux données à des fins de recherche (lecture avec des droits d accès restreints). La distribution : Les données médicales sont naturellement distribuées sur plusieurs sites. Des images d un même patient ont pu être acquises dans differents centres radiologiques. Pour qu un médecin puisse accéder à toutes les images d un patient, il faut que ces images soient accessibles depuis les sites ou les départements d un ou plusieurs hôpitaux. La distribution de ces images nécessite un mécanisme de gestion des données réparties sur plusieurs sites. Lorsque le nombre des sites augmente, surtout sur des grandes échelles, la distribution et la gestion de ces images avec leurs métadonnées devient de plus en plus complexe. 1.3 Contexte Les images médicales sont des demandeurs de grandes capacités de stockage et de calcul. Les technologies de grille (grid en anglais) sont l objet d un gros effort de recherche ces dernières années et apportent des solutions intéressantes à notre problème. Une grille de

7 1.3 Contexte 3 Fig. 1.1 Distribution des données médicales dans un hôpital calcul est une infrastructure logicielle et matérielle à très grande échelle qui procure à un utilisateur final un accès à des capacités de calcul et de stockage de masse hautement distribué, fiable, cohérent, efficace et économique [17]. La grille offre à l utilisateur une interface unique pour accéder aux applications et aux données. Le logiciel qui s occupe de cette interface est le middleware. Un middleware est un programme qui connecte les applications ensemble, afin de leur permettre d échanger des données. En agissant comme une couche d abstraction, le middleware permet aux différentes applications de discuter entre elles via un composant logiciel transparent. Un des avantages de l utilisation d un middleware est la simplicité. Chaque application a juste besoin d une interface avec le middleware lui même, indépendamment du nombre de plateformes différentes à laquelle elle est intégrée. De plus, et grâce au concept d abstraction, l application n a pas besoin d être réécrite afin d être intégrée dans les nouvelles plateformes. A l heure actuelle, la grille et le middleware sont considérés comme l infrastructure primordiale pour la distribution des données à très grande échelle. Ce travail s inscrit dans le cadre du projet MEDIGRID (Medical data storage and processing on the GRID [25]) dont l objectif est le déploiement d un système d informations médicales distribué afin de gérer d énormes bases de données d images médicales telles qu on les trouve aujourd hui dans les hôpitaux. Une partie intéressante à étudier dans le cadre du projet MEDIGRID sera la gestion des données et des métadonnées médicales distribuées dans un environnement de grille.

8 1.4 Objectifs Objectifs Pour prendre en compte les différents modes d accès aux données et leurs métadonnées, la différence de nature entre les données et leurs métadonnées et les besoins importants de calcul et de stockage, un nouveau service de gestion sera nécessaire. Le but de mon stage est d étudier un service de gestion des données et des métadonnées médicales qui sont distribuées sur plusieurs sites. La problèmatique du développement de notre service est comment gérer la cohérence entre les copies distribuées? Comment assurer la transparence d accès? Comment gérer les duplications? Quel est le meilleur système de gestion à utiliser? Le travail consiste donc dans un premier temps à étudier des systèmes distribués proposés dans le cadre des grilles de calcul pour la gestion de données à grande échelle. Ce qui nous interesse, est d étudier comment les mécanismes de duplication et de distribution mis en oeuvre peuvent êtres utilisés pour le stockage et l accès aux données médicales. En raison de la nature du système envisagé, un compromis entre un système pair à pair totalement décentralisé et un système client/serveur devra probablement être étudié. La figure 1.2 illustre la couche de la gestion des données entre les hôpitaux et illustre son rôle comme un middleware qui qui assure la transparence de liaison entre les hôpitaux. Dans ce rapport, le chapitre 2 présente une étude non exhaustive des différents modèles (pair-à-pair, Client/Serveur), et des systèmes existants (JuxMem : Juxtaposed Memory), SRB : Storage Resource Broker... Ensuite le chapitre 3 détaille le système SRB avec son architecture. Dans le chapitre 4, il sera présenté la mise en oeuvre du SRB avec l évaluation de sa performance. Enfin la conclusion (chapitre 5) présente les contributions apportées ainsi que les perspectives pour la mise en oeuvre d un système d informations médicales distribué. Fig. 1.2 Service de gestion des données médicales à developper

9 Chapitre 2 État de L Art Dans cet état de l art, nous étudions les principales architectures des systèmes de gestion de données centralisés et décentralisés developpés pour la gestion de grands volumes de données. Nous dégagerons ensuite les principaux avantages et inconvenients de ces deux approches surtout par rapport à notre système de distribution des données médicales. Nous détaillerons plus particulièrement les systèmes JXTA [28] et SRB (Storage Resource Broker) [1]. Nous aborderons aussi les problèmes de la gestion de la cohérence des données distribuées sur plusieurs sites et ses duplications. 2.1 Gestion de données La distribution des données de grande volume au niveau de grille ou à grande échelle motive la conception d un service de partage de données à cette échelle permettant une gestion efficace des données entre les différents sites de la grille. Le gestion de données vise plusieurs objectifs importants qui doivent être respectés pour n importe quel service de partage de données : Persistance : les applications de grille doivent échanger des données de grandes tailles ce qui est coûteux pour le système et pour le réseau utilisé. Pour limiter ces échanges le service de partage de données doit utiliser une stratégie qui permet de réutiliser les données déjà echangées [13], et approvisionner le système par des informations de localisation des données pour optimiser l accès aux données. Transparence : De manière générale la transparance consiste à décharger les applications de la gestion de la localisation et du transfert des données entre les sites en ayant besoin [20]. Extensibilité : c est la capacité d un système à être accessible malgré la croissance du nombre des noeuds et les éléments du système. Cohérence : les données sont partagées sur plusieurs sites. Il est possible qu elles soient modifiées par plusieurs utilisateurs. Un mécanisme de cohérence sera nécessaire. Volatilité : la disponibilité des ressources sur le réseau n est pas garantie. Les noeuds constituant une grille ne sont pas toujours disponibles, ils peuvent être arrêtés puis redémarrés suite à des problèmes techniques ou suite à l indisponibilité temporaire des ressources. Il faut donc un mécanisme de contrôle de la volatilité des ressources. Performance : La gestion de données doit assurer aussi la bonne performance du service de partage de données. La performance signifie le temps de lecture, écriture, et inseration des nouveaux noeuds dans le réseau. 5

10 2.2 Duplication des données 6 Maintenance : Une bonne maintenance du service dépend de la complexité du code, de la représentation des données, et de la structure du réseau [11]. 2.2 Duplication des données La duplication des données (ou réplication) est l une des meilleures stratégies utilisées pour réaliser un haut niveau de disponibilité, de tolérance aux pannes, aussi bien qu un temps d accès minimum aux noeuds dans un réseau de grande taille. La duplication consiste à copier un fichier sur plusieurs sites. La stratégie de duplication d un objet définit comment les copies de cet objet reçoivent, traitent, et répondent à une requête [21]. Cette stratégie vise à garantir une forte cohérence entre les copies d un composant dupliqué. Ceci revient à s assurer que l état de chaque copie est identique. Cependant, il existe plusieurs stratégies de duplication [21] : la duplication active, la duplication passive, et la duplication semi-active. La duplication active (active replication) se caractérise par la symétrie des comportements des copies d un composant dupliqué. Dans ce type de duplication, toutes les copies reçoivent les même requêtes en même temps. La duplication passive (passive replication) est asymétrique. Elle distingue deux comportements pour les copies d un composant dupliqué : la copie primaire (primary copie) et les copies secondaires (backups). La copie primaire est la seule à effectuer tous les traitements. Les copies secondaires surveillent la copie primaire. En cas de défaillance de la copie primaire, une copie secondaire devient la nouvelle copie primaire. La duplication semi-active (semi-active replication) se situe à mi-chemin entre les deux duplication précédentes. Cette duplication est considéré aussi comme une duplication asymétrique. Toutes les copies reçoivent les mêmes requêtes et traitent toutes les requêtes. Mais la copie primaire traite une requête dès qu elle la reçoit, tandis que une copie secondaire attend une annonce de la copie primaire pour faire le traitement. 2.3 Modèle centralisé versus modèle décentralisé Un système de gestion de données a besoin d un certain modèle pour gérer d une façon sophistiquée ses fonctionnalités. Un modèle signifie l architecture logique qui relie les composants du système. Dans notre cas, nous avons besion de savoir quel modèle il faut appliquer pour notre système de distribution de données. En fait, il existe deux grandes catégories de modèles de gestion de données : les modèles centralisés (client/serveur) et les modèles décentralisés (pair-à-pair) Modèle Client/Serveur De nombreuses applications fonctionnent selon un modèle client/serveur, cela signifie que des machines clientes (n offrant pas le service elle-même) contactent un serveur, une machine généralement très puissante en terme de capacités d entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l heure, des fichiers, une connexion... Les services sont exploités par des programmes, appelés clients (client FTP, client de messagerie,...). Dans un environnement purement Client/serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur mais pas les autres clients (Figure 2.1), c est un des principes de ce modèle. Ce modèle est particulièrement recommandé pour des réseaux nécessitant un grand niveau de fiabilité.

11 2.3 Modèle centralisé versus modèle décentralisé 7 Caractéristiques du modèle C/S Des ressources centralisées : le serveur est au centre du réseau, il peut gérer des ressources communes à tous les utilisateurs, comme par exemple une base de données des patients dans un hôpital, afin d éviter les problèmes de redondance et de cohérence. Extensibilité : Le modèle C/S est relativement extensible surtout avec l infrastructure serveur à serveur et la répartition des charges entre les serveurs. Sécurité et anonymat : le nombre de points d entrée permettant l accès aux données est moins important. Mais aussi le serveur a une grande fragilité puisque l attaque à un serveur correspond à l attaque de tout le système. Dynamicité du réseau : grâce à cette architecture il est possible de supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sans modifications majeures, l administration de ce phénomène se fait au niveau du serveur. Durant la période de la recherche bibliographique j ai analysé et comparé plusieurs modèles du C/S ou bien des systèmes de stockages High Performance Storage System[2] ou des protocoles de transfert comme Internet Backplane Protocol [26] qui reposent sur l architecture centralisée. Ces systèmes étaient développés pour des objectifs differents, mais chacun d eux nous intéresse pour un besoin donné. Le HPSS pour le stockage et l accès à des Téraoctets de données, le IPB est utilisé pour le transfert des fichiers par des méthodes non traditionnelles [26]. L architecture client/serveur a un grand problème dépendant de sa structure, le serveur est le maillon faible du réseau client/serveur, étant donné que tout le réseau est dépendant de son bon fonctionnement. Malgré que le serveur a une tolérance aux pannes assez grande la centralisation de ce modèle rend le système qui l utilise fragile aux pannes. Dans le cas du système de distribution de données médicale, le modèle client/serveur actuel augmente le goulot d étranglement du serveur surtout avec le nombre élevé des clients connectés et avec la grande volume des images médicales à stocker et à traiter. Un système décentralisé appelé système pair-à-pair propose une alternative intéressante. Fig. 2.1 Modèle Client/Serveur

12 2.3 Modèle centralisé versus modèle décentralisé Modèle Pair-à-Pair Pair à pair (P2P), ou peer-to-peer en anglais, est un concept qui introduit une relation d égal à égal entre deux ordinateurs ou plus qui partagent la même fonction. Une définition est [16] :«peer-to-peer refers to a class of systems and applications that employ distibuted resources to perform a critical function in a decentralized manner». Dans son essence, l informatique pair à pair se définit comme le partage des ressources et des services par échange direct entre systèmes (Figure 2.2). Ces échanges peuvent porter sur les informations, les cycles de traitement, la mémoire cache ou encore le stockage sur disque des fichiers. Le P2P désigne donc une classe d applications qui tirent partie des ressources matérielles ou humaines qui sont disponibles sur le réseau Internet et permet de modéliser l échange direct des ressources et services entre ordinateurs, tel que chaque noeud est client et serveur à la fois. De point de vue général le réseau P2P est un réseau dynamique distribué dont les noeuds communiquent en utilisant des informations locales sur leurs voisins [12]. Un des principaux avantages est une utilisation maximale de la puissance du réseau, en évitant l engorgement afin d assurer une bonne communication entre les noeuds. Du fait du déploiement massif des ordinateurs représentant un fort potentiel inactif en bordure de l Internet, le P2P retient de plus en plus l attention des chercheurs, des développeurs et des investisseurs. L inconvénient est la structure dynamique du réseau P2P et les difficultés d administation en découlant. Fig. 2.2 Modèle Pair-à-Pair : égalité entre les pairs Caractéristiques du modèle P2P Extensibilité. L objectif est de supporter un grand nombre de pairs, de l ordre de plusieurs millions. L extension de ressources se fait de manière dynamique. On augmente le nombre de ressources, en augmentant le nombre d utilisateurs tout en assurant la bonne performance du système. Volatilité. En client-serveur, la chute des serveurs entraine irrémédiablement la panne du service. En P2P, l instabilité du réseau est compensée par la redondance des informations

13 2.3 Modèle centralisé versus modèle décentralisé 9 (duplication de données) ce qui garantit, lors du retrait de pairs, un cerain niveau de persistance de données. La volatilité ou aussi la disponibilité des données doit être assurée par l utilisation de mécanismes de caches. Les systèmes P2P souhaitent minimiser le temps de récupération des données pour un débit fixé. L objectif consiste donc à placer une donnée le plus près possible d un pair qui va en faire la demande. La technique utilisée est largement basée sur la popularité d une donnée : si une donnée est populaire, elle est demandée par de nombreux pairs, donc elle va être dupliquée dans les caches des pairs intermédiaires contactés lors de la recherche. Ainsi, lorsqu un pair souhaite récupérer cette donnée, le nombre de pairs intermédiaires à contacter est plus faible. Performance. Le P2P confère une rapidité d exécution accrue notamment grâce à l extension des ressources mises à disposition, et à la réduction des temps de transits (pas de passage par un serveur : connexion directe). La performance des pairs ne se perturbe pas lors de l ajout des nouveaux pairs (au contraire du modèle C/S). Sécurité et anonymat des données et aussi des utilisateurs. Un certain niveau de sécurité doit être assuré par les mécanismes de chiffrement de données et d authentification des utilisateurs afin de contrôler l accès aux ressources du système. Adaptivité aux capacités des pairs. C est la réaction efficace et rapide du système aux changements. Ce point ressemble à la dynamicité du système. Par exemple, un pair peut diminuer l espace disque acordée au système P2P pour en faire un usage privé. De façon similaire, les débits sur les connections reliant les pairs peuvent varier, le système P2P n étant pas le seul à disposer de cette ressource. Il faut donc disposer de mécanismes permettant de tenir compte de ces variations afin d optimiser l architecture d un système P2P pour effectuer une meilleure répartition de la charge d utilisation sur l ensemble des pairs. L extensibilité du système P2P dépend de l extensibilité du protocole de routage. Le routage est la technique d acheminement des messages entre les pairs. Il nécessite de définir des adresses de niveau réseau permettant d aiguiller un message quelconque émis par un noeud source vers un noeud destination pouvant être sur un autre réseau. La mesure de la performance du protocole de routage dépend de l évaluation du nombre des noeuds dans le réseau et le nombre de sauts nécessaire pour atteindre la destination. En fait, j ai étudié durant la recherche bibliographique plusieurs protocoles de routage existants et utilisés dans le modèle P2P comme Napster [18], Gnutella [3], Pastry [27], Plaxton [11], Kazaa [23], Free- Net [4] ou Tapestry [10]. Le tableau 2.1 [11] montre l evaluation de fonctionnement de ces protocoles. On ne veut pas dans ce rapport entrer dans les détails de chaque protocole, mais ce qui nous intéresse le plus entre ces protocoles sont Tapestry et Pastry puisqu ils ont des bonnes évaluations selon les critères du tableau surtout en fiabilité et extensibilité qui sont deux crières essentiels dans le système de gestion des données médicales. Et ils peuvent être importants pour une proposition d un modèle semi-centralisé notre système de gestion (Chapitre Conclusion et prespectives). Les critères des systèmes centralisés et décentralisés, telles que la dynamicité, l extensibilité et la tolérance aux fautes, ont conduit à l élaboration de nouvelles techniques de gestion de données (partage de données modifiables ou non modifiables, duplication...). Dans ce contexte, deux approches l une centralisée et l autre décentralisée qui possédent des

14 2.4 JuxMem : gestion de données P2P sur JXTA 10 Critère Napster Gnutella Pastry Plaxtron Tapestry Extensibilité Mauvaise Mauvaise Bonne Bonne Bonne Volatilité Mauvaise Bonne Bonne Faible Bonne Performance Mauvaise Mauvaise Bonne Bonne Bonne Maintenance Optimale Optimale Bonne Mauvaise Bonne Tab. 2.1 Comparaison entre les protocoles. critères convenables avec le service de gestion des données médicales ont été bien étudiées. Ces deux approches sont le SRB Storage Resource Broker et JuxMem (Juxtaposed Memory) le service de partage de données modifiable sur une infrastructure pair-à-pair. La figure 2.3 montre une comparaison entre les protocoles cités ci dessus selon deux critères, la centralisation et l extensibilité. Dans cette figure j ai mis JuxMem et SRB (parties 2.4 et 2.5) qui utilisent des protocoles de même rôle (recherche des données) que celles qui sont déjà cités et cela pour montrer l évaluation de leurs extensibilité et centralisation entre ces protocoles afin de proposer des améliorations sur JuxMem et SRB. Fig. 2.3 Les protocoles entre l extensibilité et la centralisation 2.4 JuxMem : gestion de données P2P sur JXTA JuxMem (Juxtaposed Memory) est un service de partage de données sur une infrastructure pair-à-pair. Ce service est volatile, extensible, hétérogène, et permet la modification des données. L infrastructure sur laquelle repose JuxMem est JXTA [28]. JXTA signifie juxtapose qui souligne la juxtaposition du modèle P2P par rapport au modèle client/serveur et non son opposition. JXTA est considéré comme un middleware puisqu elle assure une infrastucture logicielle avec un certain niveau d abstraction par rapport au service utilisé. Une autre exemple du middleware est le SRB Storage Resource Broker (partie 2.5) La plate-forme générique pair-à-pair JXTA La plupart des applications P2P, actuellement existantes, ne peuvent s executer que sur un seul type d architecture et encore ne permettent pas de partager directement leurs

15 2.4 JuxMem : gestion de données P2P sur JXTA 11 ressources avec les autres. C est dans ce contexte que Sun a créé le projet : JXTA [28]. JXTA est une plateforme dans une approche Open Source. Le modèle de projet JXTA a pour but de faciliter les opérations sur un réseau informatique ou sur le Web : rechercher l information, la trouver, et l utiliser. JXTA permettant de gérer un certain nombre de fonctionnalités communes, comme la gestion des pairs, la découverte de ressources, l invocation de services sur le réseau, la communication inter-pair, la sécurité, etc. La philosophie de JXTA est de fournir l infrastructure et les mécanismes de base des services P2P et de laisser le choix d implémentation d application aux développeurs. Architectures de JXTA Le concept de base de JXTA est le pair qui est l unité structurelle de base de tout réseau P2P. Les pairs sont groupés par paquets selon leurs fonctionnalités. JXTA se décompose en 3 couches [15] : 1. JXTA Core : pour implémenter les services d administartion. Gére la création et la gestion de groupes de pairs, la communication et la sécurité. Les pipes sont les canaux de communication entre les pairs. Un message est envoyé à un pair par un pipe. Sa structure est en XML et peut contenir des données et du code. L intégrité, la confidentialité et la sécurité peuvent aussi être garanties par le pipe. 2. JXTA Services : sert à faciliter le développement des applications. C est une librairie qui étend les fonctionnalités offertes par le core. Cette couche fournit des mécanismes pour rechercher, partager, indexer et mettre en cache du code et du contenu. Le mécanisme de recherche de contenu peut être distribué ou en parallèle et utilise XML comme représentation des requêtes. 3. JXTA Applications : applications pour les pairs. Cette couche repose sur les deux couches prcédentes. D un point de vue général JXTA offre l indépendance de l architecture et l interopérabilité au réseau où elle est utilisée [9]. A haut niveau d abstraction JXTA est un ensemble de six protocoles [28] qui définissent la structure des échanges des informations entre les pairs. Ces protocoles sont tous asynchrones et reposent sur un modèle de requête/réponse JuxMem : Juxtaposed Memory Présentation générale JuxMem est un service de partage de données modifiables sur une infrastructure P2P. Ce service offre une abstraction pour partager les mémoires des pairs du réseau. Ceci indique que JuxMem partage des mémoires et pas des espaces disques. L idée de JuxMem vient du concept de la Mémoire Virtuelle Partagée (MVP). La MVP est une abstraction pour partager des données entre des processus sur des ordinateurs qui ne partagent pas physiquement leurs mémoires. L une des intérêts de JuxMem est d assurer pour un pair d observer d une façon transparente les mises à jour effectuées par les autres pairs. Les systèmes MVP [14] et P2P sont concus avec des objectifs différents. La MVP peut supporter des centaines des noeuds, et le système P2P peut supporter des millions de noeuds, ce qui correspond à l échelle de l internet [14]. L objectif de JuxMem est alors d exploiter les

16 2.4 JuxMem : gestion de données P2P sur JXTA 12 deux systèmes dans un système hybride qui peut aboutir au but et exploite les avantages de MVP (accès transparent aux données, consistence) et P2P (extensibilité, dynamicité, volatilité des ressource). L architecture de JuxMem Puisque JuxMem est basé sur JXTA, la notion de base de JuxMem est le pair. Il existe trois types des pairs [20] : fournisseur, gestionnaire et client. Le pair fournisseur offre un zone mémoire afin de recevoir des blocs de données, le pair gestionnaire gère l espace mémoire offert par plusieurs pairs fournisseur, et le pair client fournit l interface d accès aux services. (Architecture de JuxMem [20]). Les pairs sont groupés de façon à ce que chaque groupe rassemble des pairs qui ont les mêmes ressources à gérer et le même droit d accès à un service. Le groupe Juxmem contient tous les types des pairs, le groupe cluster regroupe les pairs fournisseurs d une grappe gérées par un pair gestionnaire, le groupe de données regroupe les pairs fournisseurs qui hébergent le même bloc de données. JuxMem est un service de partage de données modifiables sur la grille. Ce service doit gérer les ressources mémoires, les blocs des mémoires partagés, et la volatilité des pairs et des ressources. Gestion des ressources mémoires Avec le passage à l échelle la gestion des zones mémoires sera plus difficile, alors il faut proposer un mécanisme de gestion de ces zones. Le mécanisme proposé par JuxMem s appuie sur les annonces pour gérer les ressources mémoires [20]. Chaque pair fournisseur informe le pair gestionnaire auquel il est connecté par son propre espace mémoire disponible. Cette annonce est publiée dans le cluster groupe où le pair fournisseur est inclut. Ce type d annonce est appelé annonce de type fournisseur. Un autre type d annonce est l annonce de type grappe où le pair gestionnaire publie à l extérieur de son groupe son propre espace mémoire disponible qui est la résultante de toutes les zones mémoires annoncées par les pairs fournisseurs au pair gestionnaire qui les gère. Ces annonces seront utilisées par les pairs clients pour demander l allocation d une zone mémoire afin d y stocker un bloc de donnée. Gestion des blocs mémoires Lors de la création d une zone mémoire, un groupe sera créé et une annonce est stockée au niveau du pair client pour qu il puisse communiquer avec le groupe. Au niveau applicatif chaque client qui possède l identifiant de l annonce précédente peut accéder au bloc mémoire déjà créé. Durant la modification des données dans un bloc mémoire, ce bloc sera verrouillé pour une modification simultannée et cela est assuré grâce à un mécanisme de verroulliage utilisé. Gestion de la volatilité La volatilité est le fait qu un pair puisse disparaitre et réapparaitre pendant le fonctionnement du système. Pour la volatilité des pairs gestionnaires, JuxMem utilise le mécanisme suivant : un pair gestionnaire sera considéré comme primaire et un pair fournisseur est considéré comme secondaire, lorsque le pair secondaire est en panne, le pair primaire choisit un autre pair fournisseur pour être comme secondaire. Dans le cas inverse, lorsque le pair primaire est en panne, le pair secondaire choisit un pair fournisseur pour être secondaire et

17 2.5 Gestion de données avec Storage Resource Broker 13 devient lui même primaire. Pour la volatilité des pairs fournisseurs, le principe est simple, quand le pair gestionnaire principal détecte l absence d un pair fournisseur, il fait la mise à jour de ses annonces d espace mémoire et les rediffuse de nouveau. Notons que JuxMem utilise le mécanisme de contrôle dynamique du nombre de copies, tel que si le nombre des copies est inférieur à un nombre donné, le pair gestionnaire demande à un pair fournisseur de stocker une copie des données et à ce moment il faut bien verrouiller la modification de la copie par des autres pairs. 2.5 Gestion de données avec Storage Resource Broker Pour gérer les données distribuées sur plusieurs sites, un système SBR Storage Resource Broker a été developpé au San Diego Supercomputing Centre (SDSC). C est un outil de distribution des données inter-sites qui fournit une interface uniforme pour se connecter à des données hétérogènes distribuées dans des sites multiples, et des ensembles de réplications [22]. Le SBR est supporté sur plusieurs platformes comme LINUX, SOLARIS et supporte des bases de données comme ORACLE, DB2, PostgreSQL. Le point fort de ce système est qu il s appuie sur plusieurs systèmes de stockage de données comme HPSS (High Performance Storage System) et NFS (Network File System) ce qui permet d accéder à des grandes quantités de données et de les gérer dans des ressources hétérogènes avec un taux de transfert élevé. Ce qui est intéréssant, est sa performance [24], avec 20 Téraoctet de données et 600,000 fichiers distribués, le système à besoin de quelques secondes pour lister les fichiers. Ce système a été etudié puisqu il peut répondre à plusieurs de nos besoins : accès transparent aux données, passage à l échelle, haut débit de transfert, gestion des métadonnées, gestion de la cohérence. Il possède également une interface avec des services de grille comme RLS (Replica Location Service) et SRM (Storage Resource Manager) [19]. Ce système sera plus détaillé (chapitre 3) puisqu il convient effectivement à nos besoins. 2.6 Conclusion Nous avons décrit dans cet état de l art plusieurs environnements de systèmes qui permettent de gérer la distribution des données sur plusieurs sites, en nous focalisant sur deux systèmes qui sont SRB et JuxMem. Ce qui nous intéresse le plus dans ces systèmes sont la transparence d accès aux données, la gestion des métadonnées, la gestion de la cohérence et la duplication. JuxMem est un service de partage de données modifiables, ce service qui est en cours de developpement assure une transparence assez importante de l accès aux données tel que les operations d interrogation des pairs fournisseurs seront en transparence par rapport à l utilisateur. Ce service remédie au problème de disponibilté en utilisant la duplication des données sur plusieurs pairs. Les problèmes que j ai rencontré avec JuxMem étaient que le code source de ce service n est pas diffusé jusqu à maintenant. D autre part, JuxMem gére des espaces mémoires et pas des fichiers sur disques, ce qui n est pas pragmatique avec des images comme les images médicales de grande taille. Un autre problème que j ai rencontré avec JuxMem était la gestion de la cohérence dans ce service, en JuxMem la gestion de la cohérence se fait par une opération de multicast pour tout le fichier à modifier (fichier complet) vers tous les pairs fournisseurs qui possèdent des copies de données modifiées. Cette opération est faite par le pair fournisseur lors de la modification d une copie par un pair client. L opération de multicast charge beaucoup le réseau surtout si les copies

18 2.6 Conclusion 14 sont de grande taille comme les images médicales. Tandis qu en SRB la seulement la partie du fichier sera diffusée en multicast. Le système SRB, qui est plus intéressant pour nos besoins, est utilisé dans de nombreux projets [5] à grande échelle, nous l avons choisi pour l étudier en détail, pour analyser sa performance et pour déterminer ces avantages et ses inconvénients pour être utilisé comme système de gestion des données médicales. Ce choix est dû à plusieurs causes : La gestion des données et des métadonnées d une façon efficace ce qui est très importante pour nos besoins. La transparence complète de l accès aux données à plusieurs resources hétérogènes. La disponibilité des données est garantit grâce à la gestion de la duplication des données. L extensibilité en SRB est assurée grâce à l utilisation des zones ou de MCAT fédérée.

19 Chapitre 3 Storage Resource Broker : outil de distribution des données inter-sites 3.1 Définitions Le SRB (Storage Resource Broker) est un middleware qui fournit à ses utilisateurs une interface unique pour accéder à des systèmes de stockage de données (matériels et/ou logiciels) de différents types (figure 3.1) et qui peuvent être distribuées sur plusieurs réseaux distincts. L utilisateur voit alors ces différents supports comme s ils ne constituaient qu un seul système de stockage global (data grid) organisé en arborescence comme un système de fichiers Unix. Les fichiers d un même répertoire peuvent être en fait placés sur des sites variés, ce qui permet d organiser ces données de manière logique alors que leur enregistrement physique se fait selon d autres critères. Par exemple des systèmes rapides peuvent être utilisés pour les données auxquelles on souhaite fréquemment accéder, alors que les contenus importants seront stockés sur des supports plus fiables. Les copies et duplications d éléments d un support vers un autre se font à l aide d une simple commande avec SRB. SRB introduit la notion de metadonnée pour désigner des informations relatives aux données. Ce concept est fondamental dans l utilisation de SRB. En effet il permet d accéder à des données ou à des ressources sans avoir à connaître leur nom ou leur emplacement physique, mais en spécifiant certains de leurs attributs. Chaque système SRB dispose d une base de données relationnelle appelée méta-catalogue (MCAT) qui contient l ensemble des metadonnées pour les utilisateurs et les objets gérés par ce système. 3.2 Les composants de SRB Le système SRB est composé de quatre composants principales [22] : MCAT Database, MCAT SRB Server, SRB Server et SRB Client. Ces quatre composants doivent être utilisés dans une zone. En SRB, une zone est considérée comme un site ou un réseau de plusieurs sites tel que chaque zone posséde son propre méta-catalogue MCAT. Dans les nouvelles versions de SRB (SRB 3.0 Federated MCAT), il existe une possibilité de connecter les zones entre elles. Cette fédération de zones sera trés intéressante à étudier et la relier avec l architecture de P2P (voir conclusion). Les quatre composants de SRB sont : MCAT Database : C est une base de données qui contient les informations nécessaires utilisées par le système SRB. Cette base de données est le coeur du système, chaque zone de SRB doit avoir une MCAT unique. Il existe deux types de métadonnées en SRB : system metadata et application metadata. Le premier type est introduit par le système lui même 15

20 3.2 Les composants de SRB 16 Fig. 3.1 Vue d ensemble de l architecture de SRB comme la localisation physique d un objet de données. Le deuxième type est introduit par l utilisateur, ce sont des métadonnées de description de données. Les application metadata sont intégrées au système par la commande Smeta. MCAT contient les métadonnées, les listes des permissions d accès (ACL ou Access Control Lists), les informations sur les ressources de stockage et les informations des utilisateurs. Les bases de données supportées par SRB sont : DB2, Oracle, Sybase, MySQL, Postgres, LOBJ Databases. L utilisation de MCAT dans une zone signifie la centralisation de la zone, et si cette base de données tombe en panne, toute la zone tombe en panne et les clients ne peuvent ni s authentifier et ni transférer les données. MCAT SRB Server : C est le serveur qui fait l accès à la MCAT, un et un seul serveur MCAT doit exister dans une zone. Ce serveur permet d insérer les métadonnées sur les objets de données, utilisateurs, ressources et méthodes d accès à la MCAT, permet aussi de fournir l abstraction des collections de données qui sont des répertoires logiques qui contiennent plusieurs fichiers de plusieurs sites qui peuvent être hétérogènes et permet d assurer la transparence des ressources du système. SRB Server : Ce serveur reçoit les requêtes des clients et se connecte à la MCAT pour connaitre les informations sur les données demandées par l utilisateur. Ce serveur peut travailler en Federated mode. Lors de la réception d une requête d un client, s il ne peut pas répondre à cette requête, il demande à un autre serveur SRB de répondre à la requête sous son nom. Cette opération se fait en tranparence par rapport au client. Dans une zone de SRB, on peut avoir plusieurs serveurs SRB pour assurer les réponses aux requêtes des clients. SRB Client : C est l interface avec l utilisateur, qui lui permet d envoyer les requêtes au serveur SRB. Chaque client doit être bien indentifié chez le MCAT avec un username et

21 3.3 L architecture de SRB 17 un password. En général, un client peut se connecter à n importe quel serveur SRB dans sa zone (en chageant son fichier de configuration MdasConfig) [1] sauf si ce serveur empêche son accès en bloquant son IP de se connecter au serveur. 3.3 L architecture de SRB Avant de détailler l architecture de SRB il faut noter que dans les zones fédérées l architecture du système SRB devient hiérarchique ou semi-centralisée. Chaque zone posséde son propre MCAT, et les MCAT de toutes les zones partagent les métadonnées entre elles. Si un client dans une zone donnée adresse une requête à son serveur, ni ce dernier, ni les serveurs dans le MCAT ne peuvent répondre à la requête, alors le serveur consulte une autre zone qui posséde la réponse. L architecture de SRB est de type client/serveur dans une zone donnée. Un système SRB est composé d une application serveur à laquelle se connectent des clients SRB. Pour accéder à des données contenues dans le système SRB, un utilisateur lance un client SRB. A l aide de ce client il formule une requête qui est transmise au serveur SRB. Le serveur exécute cette requête et renvoie le résultat au client qui l affiche à l utilisateur. Dans certains cas il peut y avoir plusieurs serveurs SRB dans un même système, mais seulement l un d eux est associé au méta-catalogue et c est à ce serveur que les clients SRB se connectent. Lorsqu un client SRB se connecte à un serveur SRB un processus d authentification a lieu. En effet la base de données relationnelle (MCAT) associée à ce serveur contient une liste d objets de type user. Le serveur n établira la connexion que si le client se présente sous une identité correspondant à un user enregistré dans la base. Lors de l initialisation d un client SRB on lui donne en paramètres les coordonnées du serveur SRB avec lequel il doit dialoguer et les éléments permettant l identification de l utilisateur. La méthode la plus simple est l association identifiant-mot de passe mais il existe d autres protocoles supportés par SRB (section 3.4). 3.4 Interfaces de SRB Comme nous avons dèjà présenté, l interface SRB permet aux clients d envoyer les requêtes au serveur SRB. Dans le système SRB, il y a trois implémentations d interface : command line, Ms windows InQ, et Web based MySRB. Il existe aussi des API pour les programmeurs pour ajouter ou modifier le code source du système. Dans notre implantation (chapitre 4), nous avons utilisé l interface command line pour qu on puisse faire les mesures avec plus de flexibilité parce que en command line nous pouvons ajouter beaucoup d options pour les commandes, ce qui n existe pas complétement dans les autres interfaces. La ligne de commande est un ensemble de commandes appelées dans le monde de SRB, les Scommands. Par exemple on utilise Sget pour télécharger un fichier de l espace SRB, Sput pour diffuser un fichier dans l espace SRB, Smeta pour les métadonnées, Sticket et Schmod pour controler l accès aux objets de données,...etc. 3.5 Gestion des données en SRB Avant de décrire la gestion de données en SRB, il faut définir quelques notions dans le monde SRB. Les systèmes de stockages sont enregistrés dans le système comme des physical resources. Dans SRB il existe aussi la notion de logical resource qui est un ensemble des

22 3.6 Gestion des groupes et des utilisateurs 18 ressources physiques. On va détailler l importance de cette notion dans la partie En SRB un ensemble des objets de données sont stockés sous le nom de collection ou répertoire de fichiers. Les collections sont des regroupements logiques des objets de données qui peuvent être de plusieurs systèmes de fichiers. Par exemple une collection peut contenir les images médicales d un même patient tel que ces images sont sur des resources hétérogènes ou bien la collection peut contenir tous les fichiers d un même projet. Lorsque les données sont stockées dans l espace SRB, ces données sont stockées dans un répertoire Vault tel que chaque client le possède sur la ressource physique pour stocker des données sous son nom. La recherche de ces données ne se fait pas par des attributs physiques mais selon mes métadonnées introduites par l utilisateur lui même Duplications des données Pour assurer la disponibilité des données dans le système, SRB peut faire la duplication des données sur plusieurs sites tel que chaque copie possède un identifiant unique pour être accessible. Les données peuvent être dupliquées sur différents types de système d archivage (disque, bande, etc) et SRB assure la transparence d accès à ces différents systèmes. Avec la duplication, une notion importante s introduit, c est la gestion de la cohérence. En SRB la cohérence entre les copies est bien adaptée, et cette gestion fait deux types de duplication, l une est la duplication active (appelée synchrone dans le monde SRB ) où lors d une modification d une copie dans une ressource logique, SRB fait une duplication automatique de cette copie vers toutes les ressource physiques existantes dans la ressource logique. L autre est la duplication passive (ou asynchrone). Cette duplication se fait manuellement par l utilisateur à l aide de la commande Sreplicate qui permet de dupliquer un objet de données dans une ressource physique donnée. 3.6 Gestion des groupes et des utilisateurs La gestion des groupes et des utilisateurs est l un des points forts de SRB, un utilisateur qui va utiliser SRB doit être enregistré au MCAT comme utilisateur. Les utilisateurs peuvent être groupés. Chaque objet de données posséde une permission d accès donnée aux utilisateurs par le propriètaire de l objet. Cette gestion des groupes et des utilisateurs se convient avec les différents modes d utilisations des images médicales comme nous avons noté dans l introduction Ticketing et Schmod La base de métadonnées MCAT posséde une liste de permission d accès pour chaque objet. Les permissions sont : all (a), read(r), write (w), none(n), annotate(t). La commande qui contrôle l accès est le Schmod. Pour accéder à un objet de données il faut avoir au minimum une permission d accès read à cet objet. Une autre fonctionnalité de la gestion des groupes et des utilisateurs est la notion de ticket qui donne plus des options pour la permission d accès à un objet donnée et plus flexible. Le ticket peut donner à un client la permission d accès à un objet pour une période déterminée et de nombre d accès determiné. La commande utilisée est le Sticket.