Polish Infrastructure for Supporting Computational Science in the European Research Space Jakość dostępu do danych w środowiskach obliczeniowych typu Grid na przykładzie PL-Grid R. Slota, D. Król, B. Kryza, D. Nikolow, K. Skalkowski, and J. Kitowski ACC Cyfronet AGH, Kraków, Poland Institute of Computer Science AGH- UST, Krakow, Poland Konferencja i Wrocław,

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

Architektura

Główny przypadek użycia User Portal GOM SMED Monitoring system Application SES library SE..... Distributed storage system Defining non- functional requirements Storing requirements definition Classical 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 – 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 : ocreateFile(fileName : char*, policy : StoragePolicy*) : int oopenFile(fileName : char*) : int ocloseFile(fileName : char*) : void ochangeStoragePolicy(fileName : char*, policy : StoragePolicy*) : void

Status implementacji – Storage Element Selection 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. - if - else the current value of an attribute – required value of an attribute i

Status 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 – 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 niefunkcjonalne Status implementacji – wymagania niefunkcjonalne 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.

Podsumowanie 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