1 / 43

The AMGA metadata catalog with use cases

The AMGA metadata catalog with use cases. Danfeng, Zhu Beihang University 3rd EUChinaGrid Tutorial Beijing , 25 -2 6 th November 2006. Background and Motivation for AMGA Interface, Architecture and Implementation Metadata Replication on AMGA Deployment Examples GILDA Use cases.

miette
Télécharger la présentation

The AMGA metadata catalog with use cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The AMGA metadata catalog with use cases Danfeng, Zhu Beihang University 3rdEUChinaGrid Tutorial Beijing, 25-26th November 2006

  2. Background and Motivation for AMGA • Interface, Architecture and Implementation • Metadata Replication on AMGA • Deployment Examples • GILDA Use cases Contents

  3. Metadata is data about data • On the Grid: information about files • Describe files • Locate files based on their contents • But also simplified DB access on the Grid • Many Grid applications need structured data • Many applications require only simple schemas • Can be modelled as metadata • Main advantage: better integration with the Grid environment • Metadata Service is a Grid component • Grid security • Hide DB heterogeneity Metadata on the GRID

  4. 2004 - ARDA evaluated existing Metadata Services from HEP experiments • AMI (ATLAS), RefDB (CMS), Alien Metadata Catalogue (ALICE) • Similar goals, similar concepts • Each designed for a particular application domain • Reuse outside intended domain difficult • Several technical limitations: large answers, scalability, speed, lack of flexibility • ARDA proposed an interface for Metadata access on the GRID • Based on requirements of LHC experiments • But generic - not bound to a particular application domain • Designed jointly with the gLite/EGEE team • Incorporates feedback from GridPP • Adopted as the official EGEE Metadata Interface • Endorsed by PTF (Project Technical Forum of EGEE) ARDA/gLite Metadata Interface

  5. ARDA developed an implementation of PTF interface • AMGA – ARDA Metadata Grid Application • Began as prototype to evaluate the Metadata Interface • Evaluated by community since the beginning: • LHCb and Ganga were early testers (more on this later) • Matured quickly thanks to users feedback • Now part of gLite middleware • Official Metadata Service for EGEE • First release with gLite 1.5 • Planned for inclusion on gLite 3.1 (not present on gLite 3.0) • Also available as standalone component • Expanding user community • HEP, Biomed, UNOSAT… AMGA Implementation

  6. Some Concepts • Metadata - List of attributes associated with entries • Attribute – key/value pair with type information • Type – The type (int, float, string,…) • Name/Key – The name of the attribute • Value - Value of an entry's attribute • Schema – A set of attributes • Collection– A set of entries associated with a schema • Think of schemas as tables, attributes as columns, entries as rows Metadata Concepts

  7. Dynamic Schemas • Schemas can be modified at runtime by client • Create, delete schemas • Add, remove attributes • Metadata organised as anhierarchy • Collections can contain sub-collections • Analogy to file system: • Collection  Directory; Entry  File • Flexible Queries • SQL-like query language • Joins between schemas • Example AMGA Features selectattr /gLibrary:FileName /gLAudio:Author /gLAudio:Album '/gLibrary:FILE=/gLAudio:FILE and like(/gLibrary:FileName, “%.mp3")‘

  8. Unix style permissions • ACLs – Per-collection or per-entry. • Secure connections – SSL • Client Authentication based on • Username/password • General X509 certificates • Grid-proxy certificates • Access control via a Virtual Organization Management System (VOMS): Security

  9. C++ multiprocess server • Runs on any Linux flavour • Backends • Oracle, MySQL, PostgreSQL, SQLite • Two frontends • TCP Streaming • High performance • Client API for C++, Java, Python, Perl, Ruby • SOAP • Interoperability • Also implemented as standalone Python library • Data stored on filesystem AMGA Implementation

  10. TCP Streaming Front-end • mdcli & mdclient and C++ API (md_cli.h, MD_Client.h) • Java Client API and command line mdjavaclient.sh & mdjavacli.sh (also under Windows !!) • Python Client API • AMGA Web Interface ---NEW • Developed totally by the GILDA team – INFN CT • Based on JAVA AMGA Standard APIs • Web Application using standard as JSP Custom Tags, Servlet • SOAP Frontend (WSDL) • C++ gSOAP • AXIS (Java) • ZSI (Python) Accessing AMGA

  11. AMGA Web Interface

  12. AMGA Web Interface

  13. Metadata Schema Management

  14. Entry Management

  15. ACL Management

  16. QBE like Query Engine

  17. Query Result

  18. AMGA WI Deployment Scenario AMGA WI could be deployed on a dedicated server. This can be located inside the GRID network or outside. Currently the GILDA AMGA Server machine also hosts the web interface. Users access to the catalog towards the functionalities provided by the web interface. User uses a common Web Browser.

  19. Motivation • Scalability – Support hundreds/thousands of concurrent users • Geographical distribution – Hide network latency • Reliability – No single point of failure • DB Independent replication – Heterogeneous DB systems • Disconnected computing – Off-line access (laptops) • Architecture • Asynchronous replication • Master-slave – Writes only allowed on the master • Replication at the application level • Replicate Metadata commands, not SQL → DB independence • Partial replication – supports replication of only sub-trees of the metadata hierarchy Metadata Replication

  20. Metadata Replication Some use cases Partial replication Full replication Proxy Federation

  21. LHCb-bookkeeping • Migrated bookkeeping metadata to ARDA prototype • 20M entries, 15 GB • Large amount of static metadata • Feedback valuable in improving interface and fixing bugs • AMGA showing good scalability • Ganga • Job management system • Developed jointly by Atlas and LHCb • Uses AMGA for storing information about job status • Small amount of highly dynamic metadata Early adopters of AMGA

  22. AMGA – Metadata Service of gLite • Part of gLite (but still not certificed in gLite 3.0. it will be done with 3.1 release) • Useful for simplified DB access • Integrated on the Grid environment (Security) • Replication/Federation features • Tests show good performance/scalability • Already deployed by several Grid Applications • LHCb, ATLAS, Biomed, … • AMGA WI, gMOD, gLibrary (it follows) • AMGA Web Site http://cern.ch/amga / Conclusion

  23. Biomed • gLibrary • gMOD GILDA Use cases

  24. Medical Data Manager – MDM • Store and access medical images and associated metadata on the Grid • Built on top of gLite 1.5 data management system • Demonstrated at last EGEE conference (October 05, Pisa) • Strong security requirements • Patient data is sensitive • Data must be encrypted • Metadata access must be restricted to authorized users • AMGA used as metadata server • Demonstrates authentication and encrypted access • Used as a simplified DB • More details at • https://uimon.cern.ch/twiki/bin/view/EGEE/ DMEncryptedStorage Biomed

  25. Huge amounts of data can be saved on SEs (did we forget about the existence of Data Grids?) • But how can we easily find later a file that we need? • (if you have good memory, its GUID could be a solution  ) • File Catalogues just let us to arrange files in folders and subfolders, no way to query on their contents • Metadata Catalogues are a possible solution, but not always “affordable” especially for non expert users (powerful but complex to use) • Our solution: a higher level application built on top of many gLite grid services: a Metadata Catalogue + File Catalogues + Storage Elements gLibrary • Requirements: easy to use, fast, secure, extensible gLibrary Motivations

  26. Attempt to create a Multimedia Management System on the Grid • Examples of Multimedia Contents handled by gLibrary: • Images • Movies • Audio Files • Office Documents (Powerpoint, Word, Excel, OpenOffice) • E-Mails, PDFs, HTMLs • Customized versions of well-know document type (ex. EGEE PPTs) • …. • Keep track and organize in a uniform way all the additional details (metadata) of files saved in Storage Elements and registered in File Catalogues • Provide users an easy way to locate and retrieve files based on their contents gLibrary goals

  27. Example 1: • Locate all theoretical (PPTType) PowerPoint (Type) presentations about FireMan (Keywords) given in 2005 (Date) by Uncle Sam (Speaker); • Find all the movies (Type) in which Julia Roberts (Cast) performed together with Hugh Grant (Cast) produced in USA (Country) in 2004 (ReleaseDate); • Find all the acoustic (Genre) mp3 (Format) audio files (Type) of Alanis Morissette (Singer) that last more than 3 minutes (Runtime). • Example 2: • A doctor is looking for brain (keyword) DICOM (Type) images of male (Gender) patients older than 65 (Age). Usage scenarios

  28. Files are saved on SEs and registered into file catalogues (LFC and/or FiReMan) • The AMGA Metadata Catalogue is used to archive and organize metadata and to answer users’ queries. • gLibrary is built using the following AMGA collections: • /gLibrary contains generic metadata for each entry • /gLAudio, /gLImage, /gLVideo, /gLPPT, /EGEEPPT, /gLDoc, … are examples of collections of “additional features” (shown later) • /gLTypes • keeps the associations between document types and the names of the collection that contains the “additional features” • is used by gLibrary to find out where it has to look when new document types are added into the system (extensibility) • /gLKeys is used to store Decryption Keys gLibrary prototype implementation

  29. Example of entries

  30. “additional features” Example of gLibrary collections

  31. User Requirements: • a valid proxy with VOMS extensions • VOMS Role and Group needed to be recognized by gLibrary as a contents manager. • 3 kinds of users: • gLibraryManager: (s)he can create new content type and allows a generic VO user to become gLibrarySubmitter • gLibrarySubmitters: they can add new entries and define access rights on the entries they create. • Fine-grained permission (reading, writing, listing, decrypting) settings on each entry: whole VO members, VO groups, list of DNs • generic VO users: browse and make queries (on entries they have access to) • Basic level of cryptography: • New files saved on SEs can be encrypted beforehand with a symmetric passphrase that will be saved in /gLKeys. Only selected users (that have a specific DN in the subject of their VOMS proxy) can access the passphrase and decrypt the file. gLibrary Security

  32. gLibrary Authorization Query> whoami >> gLibrarySubmitter Query> acl_show /gLKeys/gildateam >> gLibrarySubmitter rwx >> gLibrarySubmitter:gildateam rx Query> grp_show gildateam >> tony >> valeria >> giuseppe >> emidio Query> user_listcred tony >> >> 'C = IT, O = GILDA, OU = Personal Certificate, L = INFN Catania, CN = Tony Calanducci, emailAddress = tony.calanducci@ct.infn.it' Query> acl_show /gLibrary/ >> gLibraryManager rwx >> gLibraryManager:glibsubmitters rwx >> gilda:users rx Query> acl_show /gLAudio >> gLibraryManager rwx >> gLibraryManager:glibsubmitters rwx >> gilda:users rx Query> acl_show /gLTypes >> gLibraryManager rwx >> gLibraryManager:glibsubmitters rx >> gilda:users rx

  33. Heavy exploitation of AMGA features • support for VOMS proxy authentication • fine-grained authorization capabilities to set ACLs per entry basis to restrict access to the decryption keys. • Allow gLibrarySubmitters to control which users (based on DNs, VOMS Roles and Groups) can list and get the attributes’ value for the submitted entries • GUI Front-ends (to achieve the “easy of use” promise): • Java SWING GUI to be run on a Grid UserInterface (JVM required) -- prototype is under way • Portlet based front-end will be deployed in GENIUSPHERE and made available for any other JSR168 compliant portlets cointainer • Both use AMGA Java APIs Implementation

  34. LFC (or Fireman) Catalog gLibrary Deployment scenario VOMS VOMS Proxy w/Role & Group VOMS Proxy with Group & Role Information Authenticate with X509 Certificate PostGreSQL (gLibraryManager, gLibrarySubmitter, VO user) AMGA Server UI VOMS Proxy VOMS Proxy SE SE SE

  35. gLibrary JAVA GUI screenshot Alpha Prototype

  36. gLibrary JAVA GUI Screenshot (II) Alpha Prototype

  37. Splitting of big files among several SEs (different chunks stored in different SEs): • Increase the security of data: even if a chunk is intercepted it has no meaning alone. • Increase upload/download bandwidth • Possible implementation: • one more NumberOfChunks attribute in /gLibrary collection. • /gLChunks collection keeps track of FirstChunkGUID-Chunk#-ChunkGUID • Automatic extraction and population of metadata for well known document types • use of GNU libextractor to extract metadata from HTML, PDF, PS, OLE2 (DOC, XLS, PPT), OpenOffice (sxw), StarOffice (sdw), DVI, MAN, MP3 (ID3v1 and ID3v2), OGG, WAV, EXIV2, JPEG, GIF, PNG, TIFF, DEB, RPM, TAR(.GZ), ZIP, ELF, REAL, RIFF (AVI), MPEG, QT and ASF • use of Lucenne algorithm for indexing document types containing text • Evaluation of gLite Hydra Key Store to save decryptions keys Future planned improvements

  38. Splitting Implementation SE UI SE EGEE_Movie.mpg_gpg_1 EGEE_Movie.mpg_gpg_2 EGEE_Movie_mpg_gpg_3 EGEE_Movie.mpg_gpg_4 SE SE EGEE_Movie.mpg

  39. gMOD provides a Video-On-Demand service • User chooses among a list of video and the chosen one is streamed in real time to the video client of the user’s workstation • For each movie a lot of details (Title, Runtime, Country, Release Date, Genre, Director, Case, Plot Outline) are stored and users can search a particular movie querying on one or more attributes • Two kind of users can interact with gMOD: TrailersManagers that can administer the db of movies (uploading new ones and attaching metadata to them); GILDA VO users (guest) can browse, search and choose a movie to be streamed. gMOD: grid Movie On Demand

  40. Built on top of gLite services: • Storage Elements, sited in different place, physically contain the movie files • FireMan, the File Catalogue, keeps track in which Storage Element a particular movie is located • AMGA is the repository of the detailed information for each movie, and makes possible queries on them • The Virtual Organization Membership Service (VOMS) is used to assign the right role to the different users • The Workload Management System(WMS) is responsible to retrieve the chosen movie from the right Storage Element and stream it over the network down to the user’s desktop or laptop gMOD under the hood

  41. CE WN WN WN FireMan Catalogue Metadata Catalogue gMOD interactions VOMS Storage Elements Genius Portal AMGA get Role User Workload Management System

  42. gMOD screenshot gMOD is accesible through the Genius Portal (https://glite-tutor.ct.infn.it)

  43. Any questions? Thanks for the attention

More Related