Optimisation of Data Access in Grid Environment* Darin Nikolow 1 Renata Słota 1 Łukasz Dutka 1 Jacek Kitowski 12 Piotr Nyczyk 1 Mariusz Dziewierz 1 1 Institute of Computer Science - AGH 2 Academic Computer Centre CYFRONET - AGH University of Mining and Metallurgy, Cracow, Poland Cracow Grid Workshop, Nov.5-6, 2001 *CrossGrid Project - Task 3.4

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...

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

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 Background Client Site 1 Video Server Storage Server Client Site 2 Video Server Client Site 3 Storage Server Client Site 4 Disk Server Meta-Database WAN r1 a1 d1 r2 a2 d2 r3 a3 d3

Bottom-top approach - Major Components HSMUniTreeCastorHPSS Storage System Replica Management Replica Selection Metadata Repository LDAP..... Resource Management Assumptions –mechanism neutrality –policy neutrality –compatibility with grid infrastructure –uniformity of information infrastructure

Media Management Software –Nikolow, D., Słota, R., Kitowski, J., Nyczyk, P., Otfinowski, J., "Tertiary Storage System for Index-Based Retrieving of Video Sequences", Proc. Int. Conf. HPCN, Amsterdam, June 25-27, 2001, Lect.Notes in Comp. Sci. 2110, pp , Springer, –Nikolow, D., Slota, R., Kitowski, J., ”Benchmarking TertiaryStorage Systems with File Fragmentation”, PPAM Conf., Nałęczów, Lect.Notes in Comp.Sci., accepted.

Media Management Software and its usage in X# Darin Nikolow

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

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

Video Tertiary Storage System (VTSS) Repository Daemon REPD –keeps repository information Tertiary File Manager Daemon TFMD –manages: filedb - tape ident and startup position of the fragment tapedb - 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

MMSRS and VTSS performance 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

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)

Startup latency MMSRS (DLT2000) VTSS (DLT2000) VTSS (DLT7000) UniTree reference startup latency = 718 s UniTree reference startup latency = 718 s

Transfer time (beginning part shown only) MMSRS (DLT2000) VTSS (DLT7000) VTSS (DLT2000) UniTree reference transfer time = 135 s

System performance for the whole video file transfer (DLT2000)

Definitions (for VTSS) –Minimal transfer rate –Time offset for tape changing direction Minimal transfer rate – n - number of packets – B j - number of bytes in j -th packet – t i - time when i -th packet was received – T - tape capacity in MB – N - number of tracks – B r - bitrate of video file in MB/s –no bad blocks

For DLT2000: – T = 10 GB – N = 64 – B r = 0.4 MB/s Minimal transfer rate MMSRS (DLT2000) VTSS (DLT7000) VTSS (DLT2000) Q dt = 400 s For DLT7000: – T = 35 GB – N = 52 – B r = 0.4 MB/s Q dt = 1723 s

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)

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

Access Time Estimation - Open TSS Approach TSS* TSS Symulator Client ETA of req. id? [3] ETA [4] req. [1] data req. id [2] events *TSS source code changes - adding event reporting functions

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

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

Component-expert Systems –Dutka, Ł., and Kitowski, J., „Implementation of expert technologies in information systems based on a component methodology”, MSK 2001 Conf., Nov ,2001 Cracow, accepted (in Polish). –Dutka, Ł., and Kitowski, J., „Component-expert technology in mass-storage grid applications”, ICCS 2002 Conf., April 2002, Amsterdam, in preparation.

Basics of Component-Expert Technology and its usage in X# Łukasz Dutka

Classical component strategy

Component-expert strategy

Component structure

Component header structure

Structure of component code

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

Expert Subsystem Rule-based expert system Typical rule looks like If 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

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

Component-Expert Technology for X# Task 3.4

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

Basic connection diagram

Sequence Diagram

Example of Component-Expert technology usage for data access in X# 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...

Control System for Migration/Replication Strategies (1/2) Assumptions –replica file instances –read only –no update, no coherence Logical file metadata File instance pointer Logical file Replica catalog repository Storage metadata File instance metadata Logical file metadata File instance pointer Logical file Replica catalog repository Storage metadata File instance metadata Storage system File instance Storage system File instance From replica manager

System Management for Migration/Replication Strategies (2/2) 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

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