Optimisation of Data Access in
Grid Environment*
Darin Nikolow1
Łukasz Dutka1
Piotr Nyczyk1
Renata Słota1
Jacek Kitowski12
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
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/
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
Background

PARMED Project
Client
Client
Client
(Uni. of Klagenfurt - Uni. of Mining
& Metall. Cracow)
Site 1
Video Server
Video Server
d2
Site 2
Client
Client
Client
Storage Server
– to support physicians
with telematic services
for:
• long distance collaboration
of medical centers,
• medical teleeducation
• case archives
d1
a2
a1
r2
r1
Meta-Database
WAN
a3
Client
Client
Client
r3
Site 3
Storage Server
Client
Client
Client
d3
Site 4
Disk Server
Media Management Software
and its usage in X#
Darin Nikolow
darin@uci.agh.edu.pl
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



Dedicated TSS
Client requests to VTSS can be of the following kinds:
Tertiary File Manager
Daemon TFMD
– manages:
filedb - tape ident
and startup position
of the fragment
tapedb - information
about tape usage
– 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
DLT2000 DLT7000

Hardware (AML Quantum|ATL)
load time [s]
maximal position time[s]
transfer rate [MB/s]
– 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
60
120
1.25
37
120
5
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)

System performance for the whole
video file transfer (DLT2000)
UniTree MMSRS VTSS
startup latency [s]
718
90
70
transfer time [s]
135
710
617
avarege rate [MB/s]
5.85
1.11
1.17
total transfer time [s]
853
800
747
total throughput [MB/s] 0.93
0.99
1.06
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)
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 Black Box TSS Approach
events collecting
TSS
databases
Monitoring
tools
TSS
Monitor
logs
fileid [9]
conf. files
Disk cache
Needed info by Simulator:
nr of drives
tape labels
media types
position of file in media
nr of requests
...
data [10]
data [11]
update [4]
TSS state
[5]
TSS
Simulator
ETA [6]
fileid [2]
queue state [3]
Request
Monitor & Proxy feedback [12]
fileid [8] ETA [7]
Client
fileid ETA? [1]
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/
Basics of Component-Expert
Technology and its usage in X#
Łukasz Dutka
dutka@agh.edu.pl
Classical component strategy
Component
UID1
Program
using component
technology
UID1
UID2
Get
(UID
1)
D3)
Get (UI
)
D3
I
t (U
e
G
Component
Managment
Subsystem
Search UIDx
component
Component
UID2
UID3
Component
UID3
Components container
Component-expert strategy
Get additional
informations
Rule-based
expert system
Ge
t
com inform
po
ne ation
nts
a
typ bout
e T all
IDx
Find
System
knowledge
database
Component
(TID3, SPECa)
Component type TID3
(TID2, Env3)
the b
est c
TIDx omponen
for E
t type
NVx
EN
V3
)
Ge
t(
TI
D2
,
(TID3, Env1)
Component
(TID2, SPECb)
Komponent type TID2
(TID2, Env2)
Get (TID1, ENV1)
2)
NV
E
2,
D
I
T
t(
1)
V
Ge
N
,E
3
D
TI
(
et
G
Component
(TID1, SPECa)
Components container
Components different types may have
the same specializations
(TID1, Env1)
Expert
Component
Management
Subsystem
Component type TID1
Program using
component-expert
technology
Component structure
A header which describe a
type and a specialization
A code of the component
Data stream
An input parameters
stream
An output parameters
stream
Component header structure
Type: Type_of_Component
Attribute_n = Value_n
Component
specialization
SPECx
Attribute_1 = Value_1
Attribute_2 = Value_2
.........................
(TIDx)
Code of the component
Structure of component code
service run( call-environment,
control-parameters)
{
service code
}
Data stream
An input parameters
stream
An output parameters
stream
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

Env1={Attribute_1=Value_1,
Attribute_2=Value_2,…., Attribute_k=Value_k}
Program using
component-expert
technology
Get (TID1, ENV1)
(TID1, Env1)
ID
Get (T
(TID2, Env2)
t
Ge
(TID3, Env1)
(TID2, Env3)
D
( TI
ID
(T
t
Ge
2, EN
3, E
2,
NV
V2 )
1)
)
V3
N
E
Expert
Component
Management
Subsystem
Rule-based
expert system
Env3={Attribute_2=Value_2,
Attribute_4=Value_4,…., Attribute_z=Value_z}
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 ...
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
