Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Polish Infrastructure for Supporting Computational Science in the European Research Space Jakość dostępu do danych w środowiskach obliczeniowych typu Grid.

Podobne prezentacje


Prezentacja na temat: "Polish Infrastructure for Supporting Computational Science in the European Research Space Jakość dostępu do danych w środowiskach obliczeniowych typu Grid."— Zapis prezentacji:

1 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,

2 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

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

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

5 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

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

7 Architektura

8 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

9 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

10 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

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

12 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

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

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

15 Dziękuję za uwagę. Więcej informacji na


Pobierz ppt "Polish Infrastructure for Supporting Computational Science in the European Research Space Jakość dostępu do danych w środowiskach obliczeniowych typu Grid."

Podobne prezentacje


Reklamy Google