Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Transkrypt

1 Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium opartego o protokół WebDAV. Aplikacja składa się z klienta i grupy rozproszonych serwerów. Użytkownik może wysyłać oraz pobierać pliki nie wiedząc na którym z serwerów znajdują się fizyczne dane. W ramach projektu zostaną zrealizowane trzy aplikacje: klienta, bramy repozytorium oraz serwera danych. Klient łączy się z bramą w celu realizacji operacji na repozytorium. Następnie brama odpowiednio przekierowuje klienta do określonego serwera danych. W końcu klient (bez świadomości użytkownika) nawiązuje połączenie z wybranym serwerem danych i realizuje wymaganą operację. Użytkownik nie wie gdzie fizycznie znajdują się jego dane. Projekt dostarcza więc abstrakcji repozytorium - jednolitego miejsca na dane, które w rzeczywistości będzie składać się z wielu połączonych serwerów. Głównymi celami projektu jest opracowanie oraz implementacja algorytmu podziału danych w repozytorium na wiele serwerów oraz zapoznanie się oraz zaadaptowanie odpowiednich funkcji ze standardu WebDAV - kwestie te oraz inne są poruszone w punkcie trzecim Architektura i propozycja implementacji. 2. Funkcjonalność realizowanych aplikacji Klient ma możliwość: wyświetlania zawartości kolekcji - użytkownik może poprosić o wyświetlenie danej kolekcji plików. Kolekcje plików są określane względem katalogu głównego, wyspecyfikowanego przez dany serwer. Będzie istniała możliwość wyświetlenia struktury drzewiastej kolekcji oraz zawartości wybranej kolekcji. dodawania i usuwania plików z repozytorium - użytkownik będzie miał możliwość usunięcia wskazanego pliku z repozytorium oraz dodania pliku znajdującego się na komputerze użytkownika. W przypadku gdy w repozytorium, we wskazanej kolekcji istnieje już plik o takiej nazwie, nowy plik nie zostanie dodany do repozytorium o czym użytkownik zostanie poinformowany. tworzenia i usuwania kolekcji - użytkownik będzie miał możliwość utworzenia lub usunięcia wybranej kolekcji. Tworzona kolekcja znajdzie się w określonej przez użytkownika kolekcji nadrzędnej (w szczególności, gdy taka nie będzie wyspecyfikowania, kolekcja nowa kolekcja zostanie umieszczona w głównym katalogu repozytorium).

2 przenoszenia plików między kolekcjami oraz kopiowanie plików - użytkownik będzie miał możliwość przeniesienia lub skopiowania pliku lub całej kolekcji do innej kolekcji. wyświetlania właściwości określonego pliku lub kolekcji - data modyfikacji, rozmiar itp. Serwer danych będzie: przechowywać określone pliki na żądanie klienta udostępniać określone pliki (w przypadku gdy zasób nie istnieje na serwerze wysłany będzie określony kod błędu) Brama repozytorium będzie: przechowywać informacje o lokalizacji plików na poszczególnych serwerach oraz strukturach kolekcji - na których serwerach poszczególne pliki się znajdują oraz jakie pliki znajdują się w poszczególnych kolekcjach decydować o rozmieszczeniu plików na serwerach danych - wg określonego algorytmu podziału danych. Brama zapamiętuje jedynie, do jakiej kolekcji oraz na jakim serwerze znajduje się określony plik przekierowywać na odpowiedni serwer danych, na podstawie zapytania o dany plik. 3. Architektura i propozycja implementacji brama - serwer pośredniczący, przechowujący informację o plikach znajdujących się w repozytorium i ich fizycznej lokalizacji na serwerach danych (deskryptor systemu plików repozytorium) w postaci pliku XML. Ponadto brama odpowiada za przekierowanie do odpowiedniego serwera danych. serwer danych - serwer, na którym przechowywane są pliki użytkowników.

3 Repozytorium będzie składało się z n niezależnych serwerów danych oraz jednego serwera pośredniczącego - bramy posiadającej informacje o strukturze kolekcji w repozytorium oraz o rozmieszczeniu plików na poszczególnych serwerach danych. Dla poszczególnych funkcjonalności przedstawionych w punkcie drugim zaimplementowane zostaną podstawowe metody WebDAV opisane w dokumencie RFC4918, które będą obsługiwane przez serwery danych: PUT i DELETE - do umieszczania plików na serwerze oraz usuwania plików GET - do pobierania listy plików z serwera danych PROPFIND - przesyła odpowiedź z danymi właściwości określonego pliku, jeżeli taki istnieje. Ponadto brama będzie obsługiwała następujące metody: PUT, DELETE, PROPFIND - obsługa tych żądań będzie polegała na przekierowywaniu klienta na określony serwer danych. Więcej szczegółów realizacji tych metod w punkcie 3.1. MOVE - brama przeniesie plik do innej kolekcji, co powoduje jedynie zmianę w deskryptorze struktury repozytorium przechowywanego przez bramę. Więcej na temat tej metody w punkcie 3.2. COPY - utworzenie nowego pliku jako kopii już istniejącego w repozytorium, oraz umieszczenie go w określonym kolekcji. Więcej w punkcie 3.3.

4 MKCOL - utworzenie nowej kolekcji w repozytorium. Operacja polega jedynie na modyfikacji deskryptora struktury repozytorium przechowywanego przez bramę Przesyłanie i kasowanie plików (PUT, DELETE, PROPFIND) Przesyłanie plików do repozytorium odbywa się z wykorzystaniem bramy. Klient komunikuje się z bramą w przypadku, gdy chce wykonać jedną z metod PUT, DELETE lub PROPFIND. Brama nie zajmuje się jednak przechowywaniem danych, w związku z czym przekierowuje klienta na zalecany przez nią serwer danych. Wybór określonego serwera danych dokonywany jest - w przypadku metody PUT - wg algorytmu podziału przygotowanego dla rozproszonego repozytorium plików. Algorytm podziału Algorytm podziału będzie optymalizował rozmieszczenie plików na serwerach danych tak, aby były one równomiernie obciążone pojemnościowo. Algorytm zakłada, że nowy plik będzie umieszczany na serwerze, na którym sumaryczny rozmiar przechowywanych danych jest najmniejszy. Algorytm podziału stanowi część oprogramowania bramy, w związku z czym przechowuje ona informacje o obecnym obciążeniu poszczególnych serwerów danych w postaci struktury kolejki priorytetowej typu min. Przy każdym kolejnym zgłoszeniu przez klienta metody PUT brama wybiera serwer, który jest najmniej obciążony pojemnościowo (z kolejki priorytetowej typu min) i wysyła do klienta zgłoszenie przekierowania właśnie na ten serwer. Następnie klient wysyła po raz kolejny zgłoszenie PUT, tym razem do serwera danych wskazanego przez bramę, który będzie przechowywał dany plik. Problem spójności informacji przechowywanych przez bramę oraz serwery danych Istotnym problemem w realizacji rozproszonego repozytorium jest warunek zachowania spójności informacji przechowywanych przez bramę oraz serwery danych. Po przesłaniu lub usunięciu danych na określonym serwerze, deskryptor struktury repozytorium nie będzie odpowiadał plikom przechowywanym przez ten serwer. Istnieje więc konieczność zakomunikowania bramie o zmianach dokonanych w wyniku żądań klienta. Proponowane przez nas rozwiązanie opiera się na założeniu, że to serwer danych po otrzymaniu pliku lub wykonaniu usunięcia pliku informuje bramę o zmianach które zostały dokonane w repozytorium. Decyzja ta wynika z zauważenia, że aktualizacja deskryptora struktury repozytorium nie może być dokonana przez bramę w momencie żądania PUT lub DELETE bezpośrednio przez klienta. Co prawda brama przekazuje klientowi informację o serwerze, na którym należy dokonać zmian, jednak nie ma żadnej gwarancji, że klient wykona po raz kolejny żądanie PUT lub DELETE na wskazanym serwerze danych. Takie przedwczesne uznanie przez bramę, że jakiś plik pojawił się lub zniknął w repozytorium jest źródłem potencjalnej niespójności informacji. Brama o zmianach w strukturze repozytorium musi być informowana przez serwer, na którym dokonane zostały zmiany. Nasza propozycja rozwiązania tego problemu polega na użyciu mechanizmu

5 Java RMI w komunikacji między serwerami danych a bramą repozytorium. W momencie uruchamiania aplikacji bramy utworzony będzie nowy obiekt bramy, do którego referencja zostanie umieszczona w rejestrze RMI (który - dla uproszczenia - będzie uruchamiany na tym samym hoście co brama). Oprogramowanie serwerów danych będzie uruchamiane z obowiązkowym parametrem w postaci adresu oraz nazwy obiektu bramy. Następnie serwer danych rejestruje się wysyłając - poprzez uzyskaną referencję do obiektu Bramy - zdalną referencję swojego poprzez argument metody o postaci np. gate.registerdataserver(). Dzięki temu serwer będzie mógł komunikować bramie zmiany zachodzące w jego strukturze danych poprzez wywoływanie określonych metod uzyskanego obiektu bramy. Dostęp bramy do obiektów utworzonych przez serwery danych pozwala na monitorowanie stanu poszczególnych serwerów danych (np. określenie czy serwer jest dostępy poprzez sieć) lub realizacji metody COPY (pkt. 3.3). Komunikacja pomiędzy bramą a serwerami danych odbywa się za pomocą mechanizmu RMI. Serwer danych, po otrzymaniu żądania od klienta i pomyślnym zakończeniu operacji wywołuje odpowiednią metodę bramy, aktualizującą listę plików Przenoszenie plików (MOVE) Przenoszenie plików między kolekcjami w strukturze repozytorium polega jedynie na zmianie deskryptora przechowywanego w bramie. Nie jest wymagane wykonywanie jakichkolwiek działań na serwerach danych Kopiowanie plików (COPY) Kopiowanie plików do oddzielnych kolekcji może być również zrealizowane przy użyciu RMI. W przypadku żądania klienta skopiowania pliku w inne miejsce, brama wyszukuje informację o serwerze, w którym przechowywany jest określony plik, określa serwer docelowy, na którym będzie przechowywana kopia i w przypadku gdy serwer docelowy jest inny niż serwer źródłowy - wywołuje określoną metodę dla jednego ze zdalnych obiektów serwerów danych. 4. Użyte narzędzia Wszystkie trzy aplikacje: bramy, serwera danych oraz klienta - planujemy wykonać dla JVM. W przypadku realizacji obsługi zapytań oraz odpowiedzi dla WebDAV wykorzystane będzie prosty mechanizm Socketów z pakietu java.net. Do obsługi deskryptora jako równoprawnego obiektu zostanie wykorzystana biblioteka XStream.