1 / 42

gLite Lecture 2

gLite Lecture 2. Peter Kunszt EGEE Middleware Activity (JRA1) Data Management Cluster Leader. Outline. Data Management Security in Data Management

sook
Download Presentation

gLite Lecture 2

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. gLite Lecture 2 Peter Kunszt EGEE Middleware Activity (JRA1)Data Management Cluster Leader

  2. Outline • Data Management • Security in Data Management • This is a “Differential” presentation – trying not to repeat what has been said earlier. Focus is on the differences to LCG, as presented in the lectures on Monday and Tuesday. EGEE School July 2005, Budapest, Hungary 2

  3. Chapter: Data Management DATA MANAGEMENT • Requirements, challenges • Difference to LCG • Naming • Services • SE, SRM • glite-I/O • Catalogs • FTS/FPS Data Management Documentation: http://cern.ch/egee-jra1-dm/doc.htm EGEE School July 2005, Budapest, Hungary 3

  4. The Grid DM Challenge • Need common interface to storage resources • Storage Resource Manager (SRM) • Need to keep track where data is stored • File and Replica Catalogs • Need scheduled, reliable file transfer • File transfer and placement services • Need a common security model • ACLs enforcement based on Grid identities – DNs • Heterogeneity • Data is stored on different storage systems using different access technologies • Distribution • Data is stored in different locations – in most cases there is no shared file system or common namespace • Data needs to be moved between different locations • Different Administrative Domains • Data is stored at places you would normally have no access to • Security and auditing implications EGEE School July 2005, Budapest, Hungary 4

  5. Differences to LCG • Naming • The LFN – GUID relationship is not N:1 but 1:1. There are symbolic links i.e. LFNs pointing to LFNs in a Symlink – LFN N:1 relation. • Catalog • We provide a File and Replica Management catalog named Fireman • A lot of similarities in functionality to the LFC. Differences: LFC: • not a web service, has no WSDL. • Direct connection to Oracle • Transactions are kept open between operations • No bulk operations • POSIX-like ACL syntax • Catalog distribution based on catalog replication (not done) Fireman: • Secure Web Service, WSDL • Bulk operations instead of transactions – web services are stateless • ACL permissions using non-posix but NTFS syntax (reason: distribution) • Catalog distribution based on reliable messaging (not done) EGEE School July 2005, Budapest, Hungary 5

  6. Differences to LCG (II) • Storage Element • gLite defines the SE to have 3 interfaces: • Storage Resource Management (SRM) interface • Gridftp interface • Native I/O interface (rfio, dcap, nfs, ..) • LCG only requires the gridftp interface (“classic SE”) • gLite: SRM is mandatory for each SE • POSIX-like I/O: GFAL: • client-side interaction with the SRM, storage and catalogs • user certificate is used • no atomicity guarantee gLite – I/O: • provides a server to process SRM, native I/O and catalog interactions • client delegates user credential to glite I/O server • glite I/O owns files on SE EGEE School July 2005, Budapest, Hungary 6

  7. Differences to LCG (III) • Managed File Transfer • LCG provides command-line utilities through lcg-util to move data. All the operations are performed on the client. • Blocking operation – client has to wait until the copy/replication is done • Scaling and Network resource management issue – if every job issues wide-area file movement operations from the worker nodes in a cluster, this will easily clog up the network • gLite provides services for asynchronous and bulk data movement • File Transfer • File Placement (transfer including catalog registration) EGEE School July 2005, Budapest, Hungary 7

  8. Data Management Services • Storage Element – common interface to storage • Storage Resource Manager Castor, dCache, DPM, … • POSIX-I/O gLite-I/O, rfio, dcap, xrootd • Accessprotocolsgsiftp, https, rfio, … • Catalogs – keep track where data is stored • File Catalog • Replica Catalog • File Authorization Service • Metadata Catalog • File Transfer – scheduled reliable file transfer • Data Scheduler (only designs exist so far) • File Transfer Service gLite FTS and glite-url-copy; (manages physical transfer) Globus RFT, Stork • File Placement Service gLite FPS(FTS and catalog interaction in a transactional way) gLite File and Replica Catalog Globus RLS Application specific catalogs EGEE School July 2005, Budapest, Hungary 8

  9. Fireman File andReplica Catalog Database File Transfer andPlacement Service StorageIndex Transfer Agent FPS Database FTS DM Interaction Overview Storage Element WSDL VOMS Storage API Getcredential File I/O gLite I/O SRM gridFTP File namespace and Metadata mgmt Storecredential File replication Proxy renewal ReplicaLocation MyProxy WMS EGEE School July 2005, Budapest, Hungary 9

  10. Grid Storage Devices EGEE School July 2005, Budapest, Hungary 10

  11. gLite: Grid Storage Requirements • Manage local storage and interface to Mass Storage Systems like • HPSS, CASTOR, DiskeXtender (UNITREE), … • Provide an SRM interface • Support basic file transfer protocol • GridFTP mandatory • Others if available (https, ftp, etc) • Support a native I/O access protocol • POSIX (like) I/O client library for direct access of data EGEE School July 2005, Budapest, Hungary 11

  12. Storage Resource Management • Data are stored on disk pool servers or Mass Storage Systems • storage resource management needs to take into account • Transparent access to files (migration to/from disk pool) • File pinning • Space reservation • File status notification • Life time management • SRM (Storage Resource Manager) takes care of all these details • SRM is a Grid Service that takes care of local storage interaction and provides a Grid interaface to outside world • Interactions with the SRM is hidden by higher level services EGEE School July 2005, Budapest, Hungary 12

  13. SRM Interactions Client 4 SRM 1 2 3 5 Storage • The client asks the SRM for the file providing an SURL (Site URL) • The SRM asks the storage system to provide the file • The storage system notifies the availability of the file and its location • The SRM returns a TURL (Transfer URL), i.e. the location from where the file can be accessed • The client interacts with the storage using the protocol specified in the TURL EGEE School July 2005, Budapest, Hungary 13

  14. Physical File SURL 1 TURL 1 Logical File Name 1 . . . . . . GUID Physical File SURL n Logical File Name n TURL n Files & replicas: Name Conventions • Logical File Name (LFN) • An alias created by a user to refer to some item of data, e.g. “lfn:cms/20030203/run2/track1” • Globally Unique Identifier (GUID) • A non-human-readable unique identifier for an item of data, e.g. “guid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6” • Site URL (SURL) (or Physical File Name (PFN) or Site FN) • The location of an actual piece of data on a storage system, e.g. “srm://pcrd24.cern.ch/flatfiles/cms/output10_1” (SRM) “sfn://lxshare0209.cern.ch/data/alice/ntuples.dat” (Classic SE) • Transport URL (TURL) • Temporary locator of a replica + access protocol: understood by a SE, e.g. “rfio://lxshare0209.cern.ch//data/alice/ntuples.dat” LCG2(slide fromtuesday’s lecture) EGEE School July 2005, Budapest, Hungary 14

  15. Files & replicas: Name Conventions • Symbolic Link in logical filename space • Logical File Name (LFN) • An alias created by a user to refer to some item of data, e.g. “lfn:cms/20030203/run2/track1” • Globally Unique Identifier (GUID) • A non-human-readable unique identifier for an item of data, e.g. “guid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6” • Site URL (SURL) (or Physical File Name (PFN) or Site FN) • The location of an actual piece of data on a storage system, e.g. “srm://pcrd24.cern.ch/flatfiles/cms/output10_1” (SRM) “sfn://lxshare0209.cern.ch/data/alice/ntuples.dat” (Classic SE) • Transport URL (TURL) • Temporary locator of a replica + access protocol: understood by a SE, e.g. “rfio://lxshare0209.cern.ch//data/alice/ntuples.dat” SRM File and Replica Catalog Symbolic Link 1 Physical File SURL 1 TURL 1 . . . . . . LFN GUID Symbolic Link n Physical File SURL n TURL n EGEE School July 2005, Budapest, Hungary 15

  16. gLite Fireman and StorageIndex • Fireman: Currently only single central catalog implemented • StorageIndex stores information on which SE stores a replica of the files • Next step: Distribution Now Next Fireman Fireman StorageIndex StorageIndex StorageIndex Fireman ReliableMessagePassing (MOM) Single Central Fireman Fireman Fireman Fireman Fireman EGEE School July 2005, Budapest, Hungary 16

  17. Implemented on top of Oracle and MySQL gLite FiReMan Catalog details • Web Service interface (WSDL) • Mostly Bulk operations • Stateless interaction • No transactions outside Bulk • StorageIndex: file location for broker • FAS: File Access Service (ACLs) • File Catalog: directory structure in LFN namespace • Replica Catalog: location of replicas • Meta: additional (user defined metadata) Interface Structure FiReMan FileCatalog ReplicaCatalog MetaBase FASBase StorageIndex ServiceBase EGEE School July 2005, Budapest, Hungary 17

  18. Fireman commands 1 Summary of the Fireman Catalog commands EGEE School July 2005, Budapest, Hungary 18

  19. Fireman commands 2 Summary of the Fireman Catalog commands EGEE School July 2005, Budapest, Hungary 19

  20. Fireman Simple C API glite_fireman_getinterfaceversionglite_fireman_getschemaversionglite_fireman_getservicemetadataglite_fireman_getversionglite_fireman_checkpermissionglite_fireman_getpermissionglite_fireman_setpermissionglite_fireman_createfileglite_fireman_getfilecatalogentryglite_fireman_getguidforlfnglite_fireman_getlfnforguidglite_fireman_locateglite_fireman_mkdirglite_fireman_mvglite_fireman_readdirglite_fireman_rmdirglite_fireman_symlinkglite_fireman_unlinkglite_fireman_updatemodifytimeglite_fireman_updatevaliditytimeglite_fireman_addguidreplicaglite_fireman_clearattributesglite_fireman_createguidglite_fireman_getatributesglite_fireman_getdefaultglobalpermissionglite_fireman_getdefaultprincipalpermissionglite_fireman_getguidforsurlglite_fireman_getguidstatglite_fireman_getmasterreplicaglite_fireman_getsurlstatglite_fireman_hasguidglite_fireman_listattributesglite_fireman_listreplicasbyguidglite_fireman_listsurlsbyguidglite_fireman_queryglite_fireman_removeguidglite_fireman_removeguidreplica glite_fireman_setattributesglite_fireman_setdefaultglobalpermissionglite_fireman_setdefaultprincipalpermissionglite_fireman_setmasterreplicaglite_fireman_updateguidstatglite_fireman_updatestatusglite_fireman_updatesurlstatglite_fireman_addreplicaglite_fireman_associatedirwithschemaglite_fireman_createglite_fireman_getstatglite_fireman_listlfnglite_fireman_listreplicasglite_fireman_removeglite_fireman_removereplicaglite_seindex_getinterfaceversionglite_seindex_getschemaversionglite_seindex_getversionglite_seindex_listsebyguidglite_seindex_listsebylfnglite_conf_valueglite_config_fileglite_discover_endpoint API level methods: glite_catalog_free glite_catalog_get_endpointglite_catalog_get_errclassglite_catalog_get_errorglite_catalog_newglite_catalog_set_default_permglite_catalog_set_errorglite_catalog_get_verrorglite_catalog_aclentry_cloneglite_catalog_aclentry_freeglite_catalog_aclentry_freearrayglite_catalog_aclentry_newglite_catalog_attribute_cloneglite_catalog_attribute_freeglite_catalog_attribute_freearrayglite_catalog_attribute_newglite_catalog_fcentry_cloneglite_catalog_fcentry_freeglite_catalog_fcentry_freearrayglite_catalog_fcentry_newglite_catalog_fcentry_setguidglite_catalog_fcentry_updateglite_catalog_fcentry_addsurlglite_catalog_frcentry_cloneglite_catalog_frcentry_freeglite_catalog_frcentry_frearrayglite_catalog_frcentry_newglite_catalog_frcentry_setchecksumglite_catalog_frcentry_setguidglite_catalog_guidstat_cloneglite_catalog_guidstat_copyglite_catalog_guidstat_freeglite_catalog_guidstat_freearray glite_catalog_guidstat_newglite_catalog_guidstat_setchecksumglite_catalog_lfnstat_cloneglite_catalog_lfnstat_copyglite_catalog_lfnstat_freeglite_catalog_lfnstat_freearrayglite_catalog_lfnstat_newglite_catalog_permission_addaclentryglite_catalog_permission_cloneglite_catalog_permission_delaclentryglite_catalog_permission_freeglite_catalog_permission_freearrayglite_catalog_permission_newglite_catalog_permission_setgroupnameglite_catalog_permission_setusernameglite_catalog_rcentry_addsurlglite_catalog_rcentry_cloneglite_catalog_rcentry_freeglite_catalog_rcentry_freearrayglite_catalog_rcentry_newglite_catalog_rcentry_setchecksumglite_catalog_stat_cloneglite_catalog_stat_freeglite_catalog_stat_freearrayglite_catalog_stat_newglite_catalog_surlentry_cloneglite_catalog_surlentry_freeglite_catalog_surlentry_freearrayglite_catalog_surlentry_newglite_fireman_expand_pathglite_fireman_get_locate_limitglite_fireman_get_query_limitglite_fireman_get_readdir_limit glite_freestringarrayglite_locationglite_location_logglite_location_varglite_pkg_varglite_tmpglite_uri_freeglite_uri_new RED methods alsohave bulk versions EGEE School July 2005, Budapest, Hungary 20

  21. StorageIndex UI Inform. System Match Maker Job Submission Task Queue Information Supermarket Network Server Logging & Bookkeeping Computing Element Grid Interface LRMS Using Data Location for Job Scheduling Resource Broker Data Requirements Job status Storage Element EGEE School July 2005, Budapest, Hungary 21

  22. Using Data Location for Job Scheduling Endpoint of the Catalog (StorageIndex interface) [ Executable = "helloCSC.sh"; StdOutput = "Message.txt"; StdError = "stderr.log"; StorageIndex = "http://lxb2028.cern.ch:8080/EGEE/glite-data-catalog-service-fr/services/SEIndex"; InputData = "lfn:///tmp/testCSC"; DataAccessProtocol = "gridftp,gliteio"; InputSandbox = {"helloGet.sh"}; OutputSandbox = {"Message.txt","stderr.log", "testfile.txt"}; ] LFN of the file needed Access protocol used EGEE School July 2005, Budapest, Hungary 22

  23. Remote File Access • How can we access files stored on an SRM? • 1: copy the file to local storage (tool: glite-get – based on glite I/O) • 2: access the data directly through remote file I/O (tool: glite-I/O) • gLite I/O abstraction • The Catalogs allow to find the SURL of a file • The SRM will translate the SURL into a TURL • Not all SRMs support the same protocols for direct file access • E.g.: Castor – rfio, dCache – dcap EGEE School July 2005, Budapest, Hungary 23

  24. gLite-I/O • Client only sees a simple API library and a Command Line Interface • GUID or LFN can be used, i.e. open(“/grid/myFile”) • GSI Delegation to gLite I/O Server • Server performs all operations on User’s behalf • Resolve LFN/GUID into SURL and TURL • Operations are pluggable • Catalog interactions • SRM interactions • Native I/O FiReMan RLS, RMC LFN – GUID – SURLmappings AliEn FC Server CatalogModules aio SRM API SURL - TURLmappings SRM Clientopen(LFN) gsiftp MSS ProtocolModules dcap rfio EGEE School July 2005, Budapest, Hungary 24

  25. gLite I/O commands and API Summary of the gLite I/O command line tools Summary of the gLite I/O API calls (C only) glite_openglite_readglite_writeglite_creatglite_fstatglite_lseekglite_closeglite_unlinkglite_errorglite_strerror glite_posix_openglite_posix_readglite_posix_writeglite_posix_creatglite_posix_fstatglite_posix_lseekglite_posix_closeglite_posix_unlinkglite_filehandle EGEE School July 2005, Budapest, Hungary 25

  26. File Open rfio EGEE School July 2005, Budapest, Hungary 26

  27. File Movement • Many Grid applications will distribute a LOT of data across the Grid sites • Need efficient and easy to manage File movement service • gLite File Transfer Service FTS • Manage the network and the storage at both ends • Define the concept of a CHANNEL: a link between two SEs • Channels can be managed by the channel administrators, i.e. the people responsible for the network link and storage systems • These are potentially different people for different channels • Optimize channel bandwidth usage – lots of parameters that can be tuned by the administrator • VOs using the channel can apply their own internal policies for queue ordering (i.e. professor’s transfer jobs are more important than student’s) • gLite File Placement Service • It IS an FTS with the additional catalog lookup and registration steps, i.e. LFNs and GUIDs can be used to perform replication. Could’ve been called File Replication Service. (replica = managed/catalogued copy) EGEE School July 2005, Budapest, Hungary 27

  28. Baseline: GridFTP • Data transfer and access protocol for secure and efficient data movement • Standardized in the Global Grid Forum • extends the standard FTP protocol • Public-key-based Grid Security Infrastructure (GSI) or Kerberos support (both accessible via GSS-API • Third-party control of data transfer • Parallel data transfer • Striped data transfer Partial file transfer • Automatic negotiation of TCP buffer/window sizes • Support for reliable and restartable data transfer • Integrated instrumentation, for monitoring ongoing transfer performance EGEE School July 2005, Budapest, Hungary 28

  29. Reliable File Transfer • GridFTP is the basis of most transfer systems • Retry functionality is limited • Only retries in case of network problems; no possibility to recover from GridFTP a server crash • GridFTP handles one transfer at a time • No possibility to do bulk optimization • No possibility to schedule parallel transfers • Need a layer on top of GridFTP that provides reliable scheduled file transfer • FTS/FPS • Globus RFT (layer on top of single gridftp server) • Condor Stork EGEE School July 2005, Budapest, Hungary 29

  30. Transfer Agent Actions gLite FTS/FPS details • File Transfer/Placement Service (FTS,FPS) • Transfer Job Database • Exposes the Transfer Web Service Interface to which user clients talk (submit, cancel, status capability) • Has a Web Interface • Manages Catalog updates if necessary • Transfer Agent • Basic Actions • Get transfer jobs from Transfer Job Database • Manages transfer over many channels • Monitors transfer status and updates Transfer Job Database • Extensible with user-defined custom actions • Retry Policy • Transfer Service (glite-url-copy) • Actually performs transfer: SRM – SRM, gsiftp – SRM, gsiftp – gsiftp • Monitor capability, including gsiftp performance markers Web Monitor FTS/FPSWebService Job DB Channel Channel glite-url-copy glite-url-copy glite-url-copy glite-url-copy glite-url-copy glite-url-copy EGEE School July 2005, Budapest, Hungary 30

  31. FTS vs. FPS • File Transfer Service (FTS) • Acts only on SRM SURLs or gsiftp URLs • submit(source-SURL, destination-SURL) • File Placement Service (FPS) • A plug-in into the File Transfer that allows to act on logical file names (LFNs) • Interacts with replica catalogs (similar to gLite-I/O) • Registers replicas in the catalog • submit(transferJobs) (transferJob = sourceLFN, destinationSE) FTSWebService Job DB FPSplugin Catalog EGEE School July 2005, Budapest, Hungary 31

  32. Transfer Job States EGEE School July 2005, Budapest, Hungary 32

  33. File Transfer commands Summary of the FTS/FPS commands API is also available in C and Java (WSDL-autogenerated)Simple C API is in the works, will be available in gLite 1.2.x EGEE School July 2005, Budapest, Hungary 33

  34. How to Copy and Replicate? • Using the File Transfer Service (FTS) • Lookup source SURL in replica catalog • Initiate and monitor transfer • After successful transfer register new replica in the catalog • Using the File Placement Service (FPS) • Initiate and monitor transfer • Plugin takes care of catalog interactions • FTS and FPS offer the same interface • Difference only in input parameters to the submit command • SURLs vs. LFNs • Different configuration • FPS requires catalog endpoint EGEE School July 2005, Budapest, Hungary 34

  35. Summary: End-User Interactions • File Access • glite-get, glite-put, glite-rm - on LFN and GUID • glite-IO API - C • Logical Namespace Management • glite-catalog-* commands (like ls, create, rename, ..) • Fireman API - C, C++, Java, Perl • POOL File Catalog API (GliteCatalog implementation) – not exercised • Transfer and Replication • glite-transfer-* commands (submit, status, cancel, ..) • FPS API - C, C++, Java, Perl EGEE School July 2005, Budapest, Hungary 35

  36. Fireman File andReplica Catalog Database File Transfer andPlacement Service StorageIndex Transfer Agent FPS Database FTS DM Summary Storage Element WSDL VOMS Storage API Getcredential File I/O gLite I/O SRM gridFTP File namespace and Metadata mgmt Storecredential File replication Proxy renewal ReplicaLocation MyProxy WMS EGEE School July 2005, Budapest, Hungary 36

  37. Chapter: Data Security DATA SECURITY • Requirements and Model motivation • Usage EGEE School July 2005, Budapest, Hungary 37

  38. DM Security • Requirements from the Grid context • Data access authorization should be uniform from the user’s point of view at any site • It should not happen that a user is authorized to access a replica of the same file on one site but not on another • User management should be done on the VO level • Requirements from the local context • User may want to access data locally outside of the Grid context as before (‘backdoor access’) • Requirements from the Sites • Being able to allow/deny access to specific users at the site • Being able to audit usage including the name of the user • To fulfill 1. we decided that • Data is owned by the Grid • File Authorization Service holds authorization information Contradictory to 3,4? No, but it complicates things EGEE School July 2005, Budapest, Hungary 38

  39. User Credential Usage Address Req. 1: Uniform Access control Owned by VO Owned by Site Address Req. 4, 5: Site Auth and Authz and Audit Address Req. 2: VO User Mgmt Address Req. 3: direct Access – details below EGEE School July 2005, Budapest, Hungary 39

  40. Two paths to access files Grid path Proxy authorized by Grid Server through FAS Contacting local Resource (SE) using a dual certificate (user and service info given) Local resource maps user through LCAS/LCMAPS using dual cert into the grid user owning all files Local path User contacting service directly (no Grid services used) Mapped through LCMAPS/LCAS into user’s local account. Req 1 and 3 reconciliation SE has to support more than just standard UNIX permissions – 2 owners EGEE School July 2005, Budapest, Hungary 40

  41. Security Summary • Glite enforces the ACLs as present in the File Catalog homogeneously on all SEs even those that do not have native ACL support • Made possible through additional extension to PKI certs • Non-Grid back-door access to data only safe on SEs which provide native ACL support. EGEE School July 2005, Budapest, Hungary 42

  42. More Information • gLite homepage • http://www.glite.org • DM subsystem documentation • http://egee-jra1-dm.web.cern.ch/egee-jra1-dm/doc.htm • FiReMan catalog user guide • https://edms.cern.ch/file/570780/1/EGEE-TECH-570780-v1.0.pdf • gLite-I/O user guide • https://edms.cern.ch/file/570771/1.1/EGEE-TECH-570771-v1.1.pdf • FTS/FPS user guide • https://edms.cern.ch/file/591792/1/EGEE-TECH-591792-Transfer-CLI-v1.0.pdf EGEE School July 2005, Budapest, Hungary 43

More Related