Polish InfrastructurePolish Infrastructurefor Supporting Computational Sciencefor Supporting Computational Science

in the European Research Spacein the European Research Space

Jakość dostępu do danych w Jakość dostępu do danych w środowiskach obliczeniowych typu Grid środowiskach obliczeniowych typu Grid

na przykładzie PL-Gridna przykładzie PL-Grid

R. Slota, R. Slota, D. KrólD. Król, B. Kryza, D. , B. Kryza, D. Nikolow, K. Skalkowski, Nikolow, K. Skalkowski,

and J. Kitowskiand J. Kitowski

ACC Cyfronet ACC Cyfronet AGH, AGH, Kraków, PolandKraków, Poland

Institute of Computer Science AGH-Institute of Computer Science AGH-UST, Krakow, PolandUST, Krakow, Poland

Konferencja „i3” 2010

Wrocław, 1-3.12.2010

Plan prezentacjiPlan prezentacji

1. Cele badawcze i implementacyjne

2. Aplikacje zorientowane na przetwarzanie danych

3. Wymagania niefunkcjonalne w zarządzaniu danymi

4. FiVO/QStorMan toolkit

5. Architektura

6. Główny przypadek użycia

7. Status implementacji

8. Podsumowanie

Cele badawcze i implementacyjneCele badawcze i implementacyjne

Głównym celem prezentowanych zadań jest zapewnienie użytkownikowi systemu gridowego jakości dostępu (ang. Quality of Service) do danych przechowywanych z wykorzystaniem heterogenicznych systemów przechowywania i udostępniania danych (ang. storage systems).

W tym celu wykorzystywane są następujące pojęcia: definiowane wymagań niefunkcjonalnych względem

systemów składowania danych przez użytkownika, opisy semantyczne systemów składujących danych,

przechowywane w bazie wiedzy Wirtualnej Organizacji (WO),

informacje pochodzące z systemu monitorującego aktualnych stan wykorzystywanego środowiska rozproszonego.

Aplikacje zorientowane na daneAplikacje zorientowane na dane

Główne cechy: Generowanie gigabajtów danych dziennie. Wykorzystywanie różnych typów danych, wymagających różnego

„traktowania”. Zorientowane na operacje odczytu/zapisu. Czas wykonania aplikacji silnie uzależniony od czasu dostępu

oraz transferu systemów składujących dane a nie od ilości wykonywanych obliczeń.

Przykłady (na podstawie Wikipedii): Eksperyment LHC generuje 15 PB/rok = ~42 TB/dzień = ~1

GB/sek Niemieckie Klimatyczne Centrum Obliczeniowe (DKRZ)

przechowuje dane dot. klimatu o wielkości 60 PB.

Wymagania niefunkcjonalne w zarządzaniu Wymagania niefunkcjonalne w zarządzaniu danymidanymi

Aplikacje zorientowane na dane mają różne wymagania, np. replikacja szczególnie ważnych danych,

Abstrakcje w systemach składowania danych uniemożliwiają kontrolowanie lokalizacji fizycznych danych.

Rozpraszanie danych pomiędzy dostępnymi węzłami na podstawie zdefiniowanych wymagań.

Możliwość określenia stopnia spełniania danego wymagania przez każdy z dostępnych elementów składujących dane

FiVO/QStorMan toolkitFiVO/QStorMan toolkit

Po stronie użytkownika – biblioteki programistyczne (libSES) które udostępniające funkcjonalność zarządzania lokalizacją danych w środowisku rozproszonym zgodnie ze zdefiniowanymi wymaganiami.

Po stronie serwera: Serwis (Storage Element Selection service) znajdujący najbardziej

odpowiedni element składujący dane dla przekazanych wymagań oraz aktualnego obciążenia w środowisku.

Baza wiedzy (GOM) który przechowuje konfiguracje środowiska razem ze zdefiniowanymi wymagania niefunkcjonalnymi w postaci ontologicznej.

System monitorujący (SMED) który dostarcza informacj nt. obserwowanych parametrów QoS.

Portal w którym użytkownik może zdefiniować swoje wymagania.

ArchitekturaArchitektura

Główny przypadek użyciaGłówny przypadek użycia

User

Portal

GOM

SMED Monitoring

system

Application

SES library

SE SE SE.....

Distributed storage system

Defining non-functional

requirements

Storing requirements

definitionClassical

„write” operation to concrete SE

Getting requirements for the application along

with configuration of a Lustre installation

Getting actual storage system parameter

values

Monitoring information

Getting configuration information of

a Lustre installation

Operation interception

„Write” operation to

the most suitable SE

Status implementacji – Status implementacji – po stronie użytkownika (libSES)po stronie użytkownika (libSES)

Biblioteki są implementowane jako klasyczne biblioteki dzielone (ang. shared libraries) z wykorzystaniem C/C++.

Komunikacja z serwerem wykorzystuje podejście REST z użyciem biblioteki libcurl.

Do fizycznego składowania danych używany jest rozproszony system plików Lustre wraz z mechanizmem pul.

Najważniejsza część API biblioteki to :

o createFile(fileName : char*, policy : StoragePolicy*) : into openFile(fileName : char*) : into closeFile(fileName : char*) : voido changeStoragePolicy(fileName : char*, policy : StoragePolicy*)

: void

Status implementacji – Storage Element Status implementacji – Storage Element Selection serviceSelection service

Serwis wyszukujący element składujących dane został zaimplementowany w Python`ie.

Funkcja obliczająca odległość pomiędzy wymaganiami a elementem składującym dane:

Komunikacja z systemem monitorujących odbywa się z wykorzystaniem modelu REST.

Integracja z bazą wiedzy WO odbywa się z wykorzystaniem usług sieciowych opartych o protokół SOAP.

i i

ii

x

yx=f(x)

- if < the current value of an attribute => - else the current value of an attribute

xi – required value of an attribute i

yi xi xi

Status implementacji – GOMStatus implementacji – GOM

Pozwala na wykorzystanie różnych metod składowania ontologii jak również wykorzastanie różnych metod wnioskowania.

Udostępnia różnego rodzaje interfejsu do zmieniania zarządzania oraz odpytywania zarządzanych.

GOM aktualnie wspiera komunikacje oparte o Java RMI oraz protokół SOAP.

Status implementacji – SMEDStatus implementacji – SMED

Architektura systemu monitorującego SMED jest oparta o Enterprise Service Bus (ESB).

Obecna wersja wspiera monitorowanie następujących elementów: Dyski lokalne, Macierze dyskowe, Hierarchiczne systemy składowania danych (ang.

Hierarchical Storage Management) Rozproszone system plików, np. Lustre

Status implementacji – wymagania Status implementacji – wymagania niefunkcjonalneniefunkcjonalne

Obecna implementacja StoragePolicy wspiera następujące parametry:

preferredDeviceType – typ urządzenie preferowany przez użytkownika, np. urządzenie szybko zapisujące lub posiadające wysoki poziom dostępności

capacity – wymagana wolna przestrzeń dyskowastorage space required averageReadTransferRate – średni czas odczytu danych z ostatniej monitorowanej

serii averageWriteTransferRate – średni czas zapisu danych z ostatniej monitorowanej

serii throughput – numeryczna wartość wymaganej przepustowości throughputLevel – wymagana przepustość w postaci abstrakcyjnego poziomu, np.

LOW, MEDIUM lub HIGH

Użytkownik może wybrać tylko te parametry niefunkcjonalne które są istotne z jego punktu widzenia.

PodsumowaniePodsumowanie

Celem prezentowanych prac jest opracowanie oraz implementacja mechanizmu zarządzania danymi w środowiskach rozproszonych.

Bezpośrednie definiowanie wymagań niefunkcjonalnych jest konieczne w aplikacjach zoriontowanych na dane.

Proponowane rozwiązanie może również służyć do wyboru odpowiedniego węzła w środowisku rozproszonym typu Grid gdzie zadanie ma zostać uruchomione przez system kolejkowy.

Przedstawione podejście można łatwo użyć (standardowe biblioteki dzielone C/C++), rozszerzyć (poprzez opisy semantyczne nowych elementów składujących dane) oraz zrozumieć (nieskomplikowany algorytm wyszukiwania elementów).

Dziękuję za uwagę.

Więcej informacji na www.plgrid.pl