Optimisation of Data Access in Grid Environment*

2. Optimisation of Data Access in Grid Environment* Darin Nikolow1 Renata Słota1 Łukasz Dutka1 Jacek Kitowski12 Piotr Nyczyk1 Mariusz Dziewierz1 1Institute of Computer Science - AGH 2Academic Computer Centre CYFRONET - AGH University of Mining and Metallurgy, Cracow, Poland *CrossGrid Project - Task 3.4 Cracow Grid Workshop, Nov.5-6, 2001

3. Outline • Background • Bottom-top approach • Media management software • middleware for existing HSM • dedicated VTSS • Local component-expert systems • Global policy for migration/replication FOR MORE INFO... http://www.icsr.agh.edu.pl/

4. Motivation • Big and growing stuff of data • Multimedia database systems (applications - medical, educational, virtual reality, virtual laboratories, digital libraries, advanced simulations, ...) • Solution: Tertiary Storage Systems (TSS) = Media Libraries + Management Software • Examples of existing TSS: • HPSS, DataCutter, APRIL, Condor, OmniStore, UniTree, ...... • Possible directions • Data access time estimation system - efficient usage • Data distribution and grid implementation - large scale experiments • Expert system for data management • Replication policies

5. PARMED Project(Uni. of Klagenfurt - Uni. of Mining & Metall. Cracow) to support physicians with telematic services for: long distance collaboration of medical centers, medical teleeducation case archives Site 2 Client Site 1 Client Video Server Client d1 Client d2 Video Server Client Client Storage Server a2 a1 r2 r1 Meta-Database WAN a3 r3 Site 3 Client Site 4 Client Client Client Client Client Storage Server Disk Server d3 Background

6. Media Management Softwareand its usage in X# Darin Nikolow darin@uci.agh.edu.pl

7. Motivation • Main purpose of the developed TSS: efficient index-based retrieving of video fragments (instead of file fragments) • specific requirements for frequent data reading • startup latency • transfer time • minimal transfer rate > video bitrate • Two prototypes proposed and benchmarked • middleware layer for existing HSM • dedicated TSS • The developed systems are of general use -> possible grid implementations

8. Multimedia Storage and Retrieval System (MMSRS) • Requirements • use existing software (UniTree HSM) • reduce latency (start-up delay), i.e. -reduce file granularity • file fragmentation (subfiles) • Implementation • splitting files into pieces of similar size • Middleware layer on HSM • Consists of: • Automated Media Library • UniTree HSM managing system • MPEG extension for HSM (MEH) • MEH receives the name of video file and the frame range - start/end frames • output stream via HTTP

9. Repository Daemon REPD keeps repository information Tertiary File Manager Daemon TFMD manages:filedb - tape ident and startup position of the fragmenttapedb - information about tape usage Dedicated TSS Client requests to VTSS can be of the following kinds: write a new file to VTSS, read a file fragment from VTSS, delete a file from VTSS. The fragment range is defined in the frame units Two daemons implemented in C using Unix sockets Video Tertiary Storage System (VTSS)

10. Hardware (AML Quantum|ATL) ATL 4/52 (DLT 2000) ATL 7100 (DLT 7000) HP D-class server (with UniTree HSM) Data 790 MB MPEG1 file with B=0.4 MB/s bitrate (33 min.) subfile for MMSRS - 16 MB (8,16, 32 MB tested) as short as possible to keep reproducing smooth (low latency) “optimal” subfile length depends on positioning time drive transfer rate bitrate of the video file MMSRS and VTSS performance

11. Benchmarks • Startup latency - time elapsed from issuing the request to receiving the first byte • Transfer time - time from receiving the first byte till the end of transmission • Minimal rate - minimal transfer rate experienced by a client with endless buffer (should be greater than the bitrate of the video stream to have smooth reproduction)

12. System performance for the whole video file transfer (DLT2000)

13. Minimal transfer rate VTSS (DLT2000) MMSRS (DLT2000) For DLT2000: • T = 10 GB • N = 64 • Br = 0.4 MB/s For DLT7000: • T = 35 GB • N = 52 • Br = 0.4 MB/s Qdt = 400 s Qdt = 1723 s VTSS (DLT7000)

14. Access Time Estimation: Motivation for X# • Retrieving a file from TSS could last few seconds or few hours • User’s satisfaction increases when the access time of data is known (e.g. user waiting to watch selected video; administrator recovering from backup) • Efficient use of storage resources in Grid environment (data replication subsystem)

15. Access Time Estimation: Approaches • Open TSS approach • source code changes • will be used as experimental platform • Black Box TSS approach - for existing HSMs in X# sites • retrieving TSS’s state info via its native tools and available internal files

16. Access Time Estimation - Black Box TSS Approach events collecting TSS Monitor update [4] TSS TSS state [5] databases logs TSS Simulator conf. files fileid [9] ETA [6] Monitoring tools fileid [2] data [10] Disk cache queue state [3] Request Monitor & Proxy feedback [12] ETA [7] • Needed info by Simulator: • nr of drives • tape labels • media types • position of file in media • nr of requests • ... data [11] fileid [8] Client fileid ETA? [1]

17. Conclusions • MMSRS and VTSS more efficient than standard UniTree HSM • MMSRS efficient enough to be used as a middleware for existing HSM of UniTree type (in X# sites) • Proposed measurements could be used for: • building more sophisticated distributed storage systems (faster access to files stored in TSS) • building access time estimation subsystem • Access time estimation subsystem --->>> an information provider for X# replication and migration of data http://www.icsr.agh.edu.pl/

19. Basics of Component-Expert Technology and its usage in X# Łukasz Dutka dutka@agh.edu.pl

20. Classical component strategy

21. Component-expert strategy

22. Component structure

23. Component header structure

24. Structure of component code

25. Call-Environment • Describe state of the call place • Describe call place requirements • Caries information about user or programmer wishes • Expert system processes Call-Environment and finds best component for given Call-Environment

26. Expert Subsystem • Rule-based expert system • Typical rule looks likeIf log-expr Then action1 Else action2 • The rules describe what is meant by: The best component for given Call-Environment • Expert system logs calls and stores deduction results for further analysis

27. Profits from Component-Expert technology • Dynamic expanding system possibility • Ease of solving new problems • Minimising programmer responsibility for component choice • Ease of programming in heterogeneous environment • Maximal reusable of components • Internal simplicity of components code • Increase efficiency of programming process

28. Component-Expert Technology for X# Task 3.4

29. Basic analysis of Data-access problems in X# • Different data set types • Huge data files • Distributed environment • Long distance connections • Mission critical applications • Heterogeneous data storing systems • Heterogeneous computing systems • Open system • Unpredictable file types

30. Basic connection diagram

31. Sequence Diagram

32. Sample Attributes User ID Computing Node ID Preferred replica localisation Required throughput Application purpose Data sharing Critical level Replica expiration ..... Example of local decisions Devices choosing (according to availability and type) Storing format (blocks, multimedia streams,......) Available delivering performance (network, storage devices,....) ... And much more ... Example of Component-Expert technology usage for data access in X#

33. In cooperation with other projects High-level control system (e.g. cooperating with LDAP) Two possible realizations heuristic reinforcement learning based on heuristic strategies for migration/replication and system state classical rule-based expert system System Management for Migration/Replication Strategies (2/2)

34. Conclusions • Some elements have been defined and implemented • Working on higher level structure and cooperation with other X# modules and services