Polish InfrastructurePolish Infrastructurefor Supporting Computational Sciencefor Supporting Computational Science
in the European Research Spacein the European Research Space
FiVO/QStorMan: toolkit for supporting FiVO/QStorMan: toolkit for supporting data-oriented applications in PL-Griddata-oriented applications in PL-Grid
R. Slota (1,2), D. Król (1), R. Slota (1,2), D. Król (1), K. Skalkowski (1), B. Kryza (1), K. Skalkowski (1), B. Kryza (1),
D. Nikolow (1,2), and J. Kitowski (1,2)D. Nikolow (1,2), and J. Kitowski (1,2)
(1) ACC Cyfronet AGH, Kraków, Poland(1) ACC Cyfronet AGH, Kraków, Poland(2) Institute of Computer Science AGH-(2) Institute of Computer Science AGH-
UST, Krakow, PolandUST, Krakow, Poland
KU KDM 2011
Zakopane, 9-11.03.2011
AgendaAgenda
1. Data intensive applications2. Research and implementation goals3. Non-functional requirements in data management4. FiVO/QStorMan toolkit components and architecture5. FiVO/QStorMan usage6. Testing scenarios7. Results8. Conclusions
Data intensive applicationsData intensive applications
Main features:Generate gigabytes (or more) of data per day.Different types of data which require different types of storage.Heavily uses read/write operations.The run time of an application heavily depends on storage access time and transfer speed rather than the computation time.
Scientific examples (from wikipedia):The LHC experiment produces 15 PB/year = ~42 TB/day = ~1 GB/sThe German Climate Computing Center (DKRZ) has a storage capacity of 60 petabytes of climate data.
Research and implementation goalsResearch and implementation goals
The main objective of the presented research is to manage the data coming from Grid applications using the following concepts:
allowing users to define non-functional requirements for storage devices explicitly,
exploiting a knowledge base of the VO extended with descriptions of storage elements
exploiting information from storage monitoring systems and VO knowledge base to find the most suitable storage device complient with the defined requirements
Non-functional requirements in data Non-functional requirements in data managementmanagement
Data intensive applications may have different requirements, e.g. important data should be replicated
Abstraction of storage elements prevents users from influencing the actual location of data
Distribution of data among available storage elements according to the defined requirements
Sample non-functional requirements:• freeCapacity• currentReadTransferRate• averageWriteTransferRate
FiVO/QStorMan toolkitFiVO/QStorMan toolkit
FiVO/QStorMan usageFiVO/QStorMan usage
1. Using QStorMan portal: Declare your non-functional requirements in the QStorMan portlet. Copy and paste the returned text from the portlet to your JDL file.
2. Using C++ programming library (libses):#include <LustreManager.h> #include <StoragePolicyFactory.h>
using namespace lustre_api_library;
LustreManager manager;StoragePolicy policy;
policy.setAverageReadTransferRate(50);policy.setCapacity(100);
int descriptor = manager.createFile(„nazwa_pliku.dat”, &policy);
3. Using system C library: declare your non-functional requirements in the GOM knowledge base export LD_PRELOAD=<path_to_libses_wrapper_librart>
FiVO/QStorMan testing environmentFiVO/QStorMan testing environment
ACC Cyfronet AGH (Cracow) Scientific Linux SL release 5.5 (Boron) 2x Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (4 cores, 1 thread per core) 16056 MB RAM ~ 12 TB storage capacity, ~150 MB/s read transfer rate, ~70 MB/s write
transfer rate
PCSS (Poznan): Scientific Linux CERN SLC release 5.5 (Boron) Intel(R) Xeon(R) CPU 5160 @ 3.00GHz (2 cores, 1 thread per core) 1000 MB RAM ~ 14 TB storage capacity, ~55 MB/s read trasfer rate, ~46 MB/s write
trasfer rate
ICM (Warsaw): CentOS release 5.5 (Final) Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (4 cores, 1 thread per core) 7975 MB RAM ~ 5 TB storage capacity, ~50 MB/s read trasfer rate, ~27 MB/s write
trasfer rate
Testing scenario Testing scenario
Scenario: Aims to simulate a Grid job which is scheduled to
run in the most suitable data center. The job performs computation and then writes data.
Scenario parameters:• Number of users – 3 (2 users used QStorMan)
and 4 • File size – 512 MB• Number of files to write – 20 , 30 , 40
Scenario: Aims to simulate a Grid job which is scheduled to
run in the most suitable data center. The job performs computation and then writes data.
Scenario parameters:• Number of users – 3 (2 users used QStorMan) • File size – 512 MB• Number of files to write – 20 , 30 , 40
ResultsResults
Conclusions and Future workConclusions and Future work
The presented research goal is to develop new approaches to issues of storage management in the Grid environment
Explicit definitions of non-functional requirements are necessary in data intensive applications
Allowing to accelerate data-oriented Grid applications by ~45% without any modifications in source code
Future work: Integration with Grid Queuing Systems Integration with Virtual Organizations