Politechnika Opolska

Transkrypt

1 Politechnika Opolska Wydział Elektrotechniki, Automatyki i Informatyki Instytut Automatyki i Informatyki PRACA DYPLOMOWA inżynierska Rozproszona biblioteka elektroniczna oparta o platformę LAMP Promotor: dr hab. inż. Jan SADECKI prof. PO Pracę wykonał: Julian HOROSZKIEWICZ Opole, kwiecień 2010

2 ROZPROSZONA BIBLIOTEKA ELEKTRONICZNA OPARTA O PLATFORMĘ LAMP S t r e s z c z e n i e Praca przedstawia teoretyczne i praktyczne aspekty zaprojektowania, implementacji oraz wdrożenia koncepcji rozproszonego systemu zasobów. Na zasoby składają się przechowywane na wszystkich węzłach pliki, opatrzone stosownym zestawem metadanych; standardowych atrybutów oraz informacją na temat stanu synchronizacji plików. Rozważono dwa scenariusze rozproszenia, replikację oraz klaster. Jako przykład zastosowania wybrane zostało repoztorium książek elektronicznych zwane dalej biblioteką. Dokonano analizy oraz projektu systemu z pomocą nowoczesnych narzędzi inżynierii oprogramowania. Ustalono i rozwiązano problemy spójności, koordynacji oraz niezawodności. Uzasadniono wybór platformy, na której zdecydowano się dokonać implementacji. Opisano implementację oraz wdrożenie, a także związane z nią jak i z architekturą oraz platformą aspekty bezpieczeństwa. Wszystko to podsumowane jest dostrzeżonymi wadami oraz zaletami rozwiązania, przedstawiona jest perspektywa dalszego rozwoju oraz utrzymania projektu. DISTRIBUTED LAMP RESOURCES SYSTEM S u m m a r y This project introduces theoretical and practical aspects of design, implementation, deployment and maintainance of distributed resources system. So called resources consist of files distributed through all system nodes, related metadata consisting of standard attributes, fulfilled with information needed for coordination of files synchronization process. There's been considerated two distribution scenarios, replication and clustering. Standard analysis and project were made with the use of modern software engineering instruments. Common distributed systems problems, such as convergence, synchronization and reliability were identified and solved. Also there's been formulated advocacy and argumentation of choosen platform and ideology. Implementation and deployment details were discussed, so as all known implementation, platform and architecture specific security issues. All of this is concluded with revealed vices and virtues of the solution and its policy. Also future development and maintainance perspective has been considered. 2

3 Plan pracy 1. Wstęp, czyli cel i zakres pracy 5 2. Wycinek rzeczywistości 6 3. Scenariusze; architektura sieci 7 4. Platforma GNU/Linux 2. Apache HTTP Server 3. MySQL 4. PHP 1. ViLDeV 5. rsync+ssh 5. Struktura organizacyjna plików Synchronizacja zasobów Zagrożenia wyścigowe Analiza, projekt użytkownicy, grupy 2. diagram przypadków użycia 3. diagram klas 4. diagram komponentów 5. diagramy sekwencji 6. diagramy stanów 7. diagram wdrożenia 9. Implementacja PHP 1. ViLDeV 2. moduły DLRS 3. skrypt kolejkujący synchronizacje plików 4. skrypt do zautomatyzowanego katalogowania zasobów 2. MySQL 10. Bezpieczeństwo Apache HTTP Server 2. PHP 3. MySQL 4. GNU/Linux 5. poufność, uwierzytelnianie, integralność 6. pozostałe 11. Wdrożenie ViLDeV + DLRS 2. MySQL z replikacją 3. SSH+rsync 3

4 12. Rozbudowa, utrzymanie, administracja Licencja Wnioski i uwagi; podsumowanie Bibliografia 100 4

5 1.Wstęp; dlaczego DLRS? DLRS (Distributed LAMP (GNU/Linux Apache MySQL PHP) Resources System) to rozproszony system współdzielenia zasobów. Głównym powodem powstania projektu była potrzeba stworzenia bezpiecznej, rozproszonej bazy danych z książkami elektronicznymi, która automatycznie dba o swoją spójność, a dzięki decentralizacji jest znacznie bardziej niezawodna, odporna na awarie, w tym klęski żywiołowe i ataki DoS (Denial of Service), a także pozwala na rozłożenie pracy związanej z obsługą użytkowników. Dzięki dostępowi poprzez interfejs webowy spełnia również wymogi dostępności i uniwersalności, spełniając jednocześnie pewne cechy sieciowego systemu plików, pozwalając na precyzyjne określanie przywilejów dla wielu różnych zasobów w środowisku wieloużytkownikowym. Dokładna realizacja tego zadania wymagała podjęcia prac na wielu płaszczyznach; programowania rozwiązań web oraz konsolowych, projektowana i programowania baz danych, inżynierii systemów rozproszonych, a również w szerokim stopniu prac administracyjnowdrożeniowych. Poza aspektem praktycznym, wybór tematu był ukierunkowany wyłącznie ideologią oraz osobistym pomysłem na połączenie zagadnień wchodzących w skład zainteresowań i doświadczeń autora. 5

6 2.Wycinek rzeczywistości Na kilku skoordynowanych serwerach nazywanych dalej węzłami funkcjonuje biblioteka elektroniczna, na którą składają się książki w postaci plików w dowolnych formatach i praktycznie dowolnych rozmiarach. Każda z nich może należeć do pewnej kategorii. Baza metadanych opisujących encję książki, zawierających podstawowe informacje na jej temat, bez samych danych jej pliku, utrzymywana i zarządzana jest przez serwer baz danych, zazwyczaj, choć niekoniecznie na tej samej fizycznej czy wirtualnej maszynie. Serwery mogą tworzyć zdecentralizowaną sieć www korzystającą ze zdecentralizowanej sieci serwerów baz danych, zazwyczaj serwer www oraz serwer bazy danych znajdować się bedą na tym samym hoście, przy tymże założeniu utrzymana jest dalsza część pracy. Użytkownik za pomocą przeglądarki łączy się z którymkolwiek z węzłów i dokonuje uwierzytelnienia. Dla estetyki można utworzyć wszystkim po subdomenie we wspólnej domenie, w użytych w projekcie przykładach będą to domeny itathome.pl, n0life.pl. Do dyspozycji użytkownika jest lista aktualnie znajdujących się w systemie książek, wyszukiwarka oraz panel administracyjny do umieszczania, edycji i usuwania plików, jak i interfejs do zarządzania własnym kontem lub także skromną konfiguracją węzłów sieci, jeśli użytkownik ma status administratora węzła. Nowe pliki mogą zostać dodane przez każdego użytkownika należącego do grupy uploaderów oraz administratora. Modularna budowa wybranego systemu webowego pozwala na łatwe rozszerzanie funcjonalności w przyszłości. W wersji bieżącej dostępny jest opcjonalnie między innymi system newsów, który jest integralną częścią wybranego do realizacji zadania systemu web. Spójność pomiędzy węzłami w warstwie bazodanowej jest kontrolowana prze sam system bazodanowy; replikację lub silnik klastrowy. Synchronizacja na poziomie systemu plików na węzłach przebiega asynchronicznie z pomocą osobnego skryptu będącego częścią DLRS, implementującego własny, odporny na awarie algorytm podtrzymywania spójności. 6

7 3. Scenariusze; architektura sieci Z punktu widzenia użytkownika scenariusz jest jeden; może on połączyć się z dowolnym węzłem w systemie, dokonać uwierzytelnienia a następnie wykonywać przewidziane dla niego przypadki użycia, tj. korzystać z zasobów jak też tworzyć własne. Nie ma dla niego znaczenia, jak sytuacja faktycznie rozgrywa się w bazie danych, można więc założyć, że z punktu widzenia użytkownika sieć jest zupełnie zdecentralizowana. Wyjątkiem jest sytuacja, w której przy korzystaniu z wersji replikacyjnej (o czym dalej) nie działa host pełniący rolę węzła głównego (tzw. master, wtedy system dostępny jest tylko do odczytu, niemniej nadal funkcjonuje). Z punktu widzenia administratorów oraz węzłów, pomijając instancje systemu składające się z jednej maszyny (tzw. instalacja standalone, niewymagająca żadnej synchronizacji na poziomie zarówno baz jak i plików), architektura systemu oparta jest o założenie, że każdy z węzłów ma pełną informację na temat węzłów pozostałych. Tyczy się to również informacji o stanie danego zasobu na danym węźle, tj. czy określony plik fizycznie znajduje się na wskazanym węźle, gdyż jeśli nie, oznacza to, że nie zakończył się jeszcze proces jego synchronizacji. Rozproszona baza danych jest traktowana z punktu widzenia użytkowego atomowo, tj. utrzymujemy założenie, że na każdym z węzłów baza danych posiada identyczną zawartość. Do tego potrzebne jest utrzymanie spójności, synchronizacja w zapisie tych samych zasobów i sprostanie zagrożeniom wyścigowym. Z punktu widzenia implementacji, czyli samej bazy danych, jest to zadanie trudne. MySQL wychodzi naprzeciw tym oczekiwaniom oferując takie rozwiązania, jak replikacja oraz klastry, przy czym w różnym stopniu spełniają one wyżej wspomniane wymogi. 3.1 MySQL Cluster Tę funckjonalność oferuje silnik NDB (Network Database), umożliwiający tworzenie zdecentralizowanych klastrów o wysokiej dostępności, nadmiarowości i skalowalności. Technologia ta pozwala na odczyt i zapis do wielu węzłów, transparentnie wykonując synchronizację, transparentnie tolerując awarie oraz przetwarzając zapytania w sposób rozproszony, co znacznie poprawia wydajność przeszukiwania metadanych o zasobach. Bazy oparte o silnik NDB w trakcie pracy mogą być przechowywane wyłącznie w pamięci operacyjnej, aby skrócić czas dostępu do danych. W takiej sytuacji należy jedynie poprawnie wdrożyć instalację klastra, niemniej nie ma potrzeby przejmowania się problemami związanymi bezpośrednio z systemem rozproszonym, można traktować wszystkie dane globalnie, kwestię spójności i zagrożeń wyścigowych pozostawiając do rozwikłania NDB. Nic za darmo. Programista nie musi tworzyć i implementować skomplikowanych algorytmów rozwiązujących te problemy, ale wszystkie węzły muszą spełnić wymóg wzajemnej łączności na szerokości min. 100 Mbps, niemniej gdzie tylko się da, zalecana jest łączność rzędu gigabita na sekundę [mysql-cluster]. To niestety kłóci się z jednym z założeń pozafunkcjonalnych, tj. system ma być zdolny do wdrożenia i zadowalającego działania na węzłach o niskich przepustowościach, zazwyczaj niesymetrycznych łączach dla klientów indywidualnych, rzędu np Mbps. Rysunek nr 1 przedstawia klaster z funkcjonalnego punktu widzenia związanego z przepływem danych. Jak widać jest on wielokierunkowy, sam zaś użytkownik i aplikacja korzystać mogą z dowolnego jego węzła, gwoli wydajności wybierając najmniej obciążony/namniej oddalony 7

8 geograficznie, co można również zautomatyzować, wykonując kolejny krok w stonę tzw. Cloud Computingu. Niebieska linia przerywana prezentuje przepływ danych od użytkownika do systemu (zarówno zapis jak i odczyt na dowolnym węźle). Rys. 3.1 schemat systemu rozproszonego zrealizowanego z pomocą MySQL Cluster z punktu widzenia przepływu danych, aplikacji oraz użytkownika 3.2 Replikacja Drugą wartą rozważenia opcją jest replikacja. Dzięki częściowej rezygnacji z decentralizacji wprowadza znacznie mniejsze wymagania dotyczące dostępności, w tym przepustowości węzłów, gdyż jest asynchroniczna. Replikacja pozwala na tworzenie bazy danych rozproszonej po wielu niezależnych, zazwyczaj fizycznych maszynach, przeważnie ma to na celu poprawić wydajność poprzez zmniejszenie opóźnień wynikających z geograficznego rozlokowania węzłów oraz bezpieczeństwo pod względem nadmiarowości (tj. replikacja, podobnie jak klaster, jednocześnie spełnia rolę sieciowego backupu baz). Jest to scenariusz bardzo podobny do klastra, z pewną zasadniczą różnicą. Główny serwer, nazywany dalej master, jest jedynym węzłem, na którym zachodzą zapisy danych (dodawanie, modyfikacja, usuwanie, czyli operacje DML), które są na bieżąco propagowane do wszystkich podłączonych aktualnie węzłów skonfigurowanych do replikacji, nazywanych dalej slave, przy czym to węzły slave odpowiadają za pobieranie aktualizacji od mastera, nie odwrotnie. Można ustalić nie tylko bazę, którą należy poddać replikacji, ale również pojedyncze tabele. Pierwszą opcją, która pozwala kontrolować to, czy operacje na danej bazie trafiają do bin-loga (a w związku z tym czy podlegają replikacji), jest dyrektywa binlog-do-db oraz binlog-ingnore-db [replication-rules]. Użycie tychże opcji powoduje jednak wyłączenie baz z włączenia w bin-loga, zatem utrudnia ewentualne odzyskanie danych po awarii, co jest drugą kluczową funkcjonalnością oferowaną przez ten mechanizm. Zalecane jest zatem kontrolowanie tej opcji po stronie węzłów slave, z użyciem dyrektyw --replicate-*. W pierwszej kolejności sprawdzane są opcje związane z bazami danych, następnie z tabelami. System powinien być zorganizowany w taki sposób, że wszystkie operacje poza 8

9 wybierającymi dane (SELECT, SHOW), czyli DDL (Data Definition Language) i DML (Data Modification Language) wykonywane na obszarze replikowanych danych jedynie na masterze, węzły slave pobierają je z binarnego loga i automatycznie wykonują u siebie, zaś użytkownicy i aplikacje na węzłach slave korzystają z danych jedynie w trybie odczytu. W przeciwnym wypadku dojdzie do zaburzenia spójności, co jest sprzeczne z ideą replikacji. Niemniej MySQL pozwala na takie zachowania (operacje DDL i DML na replikowanych bazach), pozwala również na ich ograniczenie opcją --read-only, więcej szczegółów w dokumentacji [replication-options-slave]. Zasada działania replikacji oparta jest o wspomniany wyżej log binarny, w którym zapisywane są kolejno wszystkie wydarzenia w bazie, w tym przypadku w bazie mastera. Istnieją różne formaty loga binarnego i odpowiadające im formaty replikacji, zatem wybrany dla danej bazy format musi być spójny pomiędzy wszystkimi węzłami. Do wersji jedynym obsługiwanym formatem loga binarnego, a co za tym idzie, replikacji, jest SBR (Statement Based Replication), polegający na propagowaniu bezpośrednio zapytań SQL z mastera do serwerów slave. RBR (Row Based Replication) opiera się z kolei na zapisie wydarzeń dla każdego z wierszy tabel. Jest on domyślny w wersjach MySQL , zaś od wersji dalszych domyślnie znów jest to SBR. Bazy z silnikiem NDB (czyli logicznie rzecz biorąc MySQL Cluster, rozwiązanie w pełni klastrowe, nie replikacyjne) pracują wyłącznie z formatem RBR. Istnieje również format mieszany (Mixed Based Replication, Mixed Format Replication), w którym format SBR jest domyślny, zaś w przypadku określonych zdarzeń tego wymagających, format jest dynamicznie przestawiany na RBR. Widać tu zatem wyraźną różnicę i idącą za nią we wdrożeniu decyzję, jaką należy podjąć dla danego projektu bazodanowego. Format loga binarnego jest ustalany globalnie, dla całego serwera, jednak może być także oddzielnie określony dla każdej sesji (ustawienie więc istnieje dla każdej sesji aż do jej zakończenia, zatem należy konsekwentnie każdą sesję projektu podlegającego repliakcji rozpoczynać ustawieniem tego samego formatu, jeśli ma się on różnić od tego globalnego (ponadto niejako uniezależnia to od globalnego ustawienia na serwerze)). Za replikacją opartą o wiersze mocno przemawia również fakt, iż w pewnych sytuacjach rozwiązanie SBR (w przypadku widoków, przechowywanych procedur, funkcji) może prowadzić do rozbieżności pomiędzy danymi, różnymi ścieżkami wykonania kodu w procedurach a także naruszenia bezpieczeństwa, gdyż zapytania odczytywane z mastera i wykonywane na węźle slave poprzez proces/wątek przeznaczony do replikacji działają w trybie uprzywilejowanym. W przypadku propagowania faktycznych zmian na wierszach, zamiast przekazywania samych zapytań, sytuacja taka z wyżej wymienionych powodów jest niemożliwa. Po obszerne dane na ten temat replikacji z SBR przy wykorzystaniu procedur i funkcji, szczególnie w aspekcie ich tworzenia w związku z ich determinizmem, odsyłam do dokumentacji [stored-programs-logging]. 3.3 Kompatybilność pomiędzy wersjami Replikacja działa zawsze pomiędzy kolejnymi głównymi seriami MySQL, tj. np. pomiędzy 4.1 i 5.0, jak i 5.0 a 5.1, również kaskadowo, tj. szeregowo (łącząc podłączając 4.1 jako mastera dla 5.0, który z kolei jest masterem dla 5.1, unikając w ten sposób problemów z kompatybilnością, niemniej zazwyczaj obchodzi się i bez pośrednika). Układ ten generalnie nie funkcjonuje dla kierunku odwrotnego, tj. dla masterów o numerach wersji wyższych, niż węzły typu slave (starsze węzły slave nie rozumieją np. nowego formatu loga o zmianach w bazie, na podstawie których dokonywana jest replikacja). 9

10 Rys. 3.2 schemat systemu rozproszonego zrealizowanego z pomocą MySQL Replication z punktu widzenia aplikacji oraz użytkownika Właśnie z tego powodu, że wszelkie metadane uaktualniane mają być bezpośrednio jedynie na węźle master, zmiany dokonywane przez użytkowników na węzłach pozostałych będą w systemie DLRS przezroczyście propagowane do niego z pomocą PHP działającego jako klient MySQL, co prezentuje ciągła niebieska linia na rysunku nr 2 (linia przerywana reprezentuje dane pochodze od użytkownika). Jest to zwykłe zapytanie wykonywane poprzez PHP prawie tak samo, jak w przypadku korzystania z klastra i silnika NDB, z tą różnicą, że specjalnie dla niego otwierane jest oddzielne połączenie MySQL z węzłem master. Sam zaś slave, z którego ta zmiana wyszła, tak jak pozostałe węzły, dokonuje aktualizacji swojej bazy na podstawie dokonanej przez samego siebie zmiany w bazie węzła master, tak jakby została ona wykonana bezpośrednio na węźle master. Jest to główna różnica implementacyjna, jaka występuje pomiędzy wersją DLRS opartą o replikację, a przewidywaną w na przyszłość wersją klastrową. Szczegóły związane z różnicami implementacyjnymi zostały poruszone w rozdziale Zagrożenia wyścigowe. Pozostałe różnice pomiędzy klastrem a replikacją pozostają na poziomie wdrożenia. 3.4 Decyzja, czyli dlaczego replikacja Ze względu na wymagania pozafunckjonalne, mniejszy stopień komplikacji przy wdrożeniu, a także fakt, iż klaster jest rozwiązaniem, które w praktyce jest rozszerzeniem replikacji, jako podstawowy scenariusz wybrano ten, który spełnia bardzo istotne w tej instancji wymagania niefunkcjonalne (niska przepustowość węzłów oraz ograniczony obszar pamięci). Jak wspomniano na końcu poprzedniego akapitu, z punktu widzenia samego systemu DLRS różnica w implementacji jest niewielka, przy czym rozwiązanie klastrowe rozwiązuje również problemy zagrożeń wyścigowych, którym w przypadku scenariusza replikacyjnego należy stawić czoła. Ponadto nic nie stoi na 10

11 przeszkodzie, aby w razie awarii mastera skonfigurować jeden z węzłów slave do jego zastąpienia, a nawet możnaby się pokusić o zautomatyzowanie takiego procesu. Wnikając w szczegóły implementacyjne MySQL Cluster można się przekonać, iż silnik NDB w rzeczywistości stosuje właśnie takie rozwiązanie. Przewidywana jest wersja dla silnika NDB. 11

12 4. Platforma 4.1 GNU/Linux System operacyjny GNU/Linux został wybrany jako naturalne środowisko dla platformy AMP (Apache, MySQL, PHP), stabilne i otwarte, a co za tym idzie wyjątkowo elastyczne, szeroko wspierane oraz relatywnie bezpieczne. Ze względu na jego wieloletnią popularność w zastosowaniach serwerowych, co wynika z uniksowej specyfikacji oraz faktu, że jest wolnodstępny, jego dojrzałość i szerokie wsparcie w Sieci sprawiają, że w coraz większej mierze staje się znakomitym narzędziem do profesjonalnych zastosowań. Niemniej nie można decyzji o platformie odmówić pewnego czynnika personalnego. Każdy element projektu, a także jego idea jest w swej genezie i specyfice najbardziej związana ze środowiskiem GNU/Linux. Ze względu na bliskie pokrewieństwo i elastyczność użytego oprogramowania, nic nie stoi na przeszkodzie, aby do tego zadania zatrudnić inny system uniksopodobny, taki jak OS X czy inne systemy z rodziny BSD. 4.2 Apache HTTP Server Jako serwer www, odgrywający kluczową rolę dla użytkownika, użyty został, ze względu na swoją dojrzałość i szerokie możliwości, Apache HTTP Server w wersji 2.2, niemniej nic nie stoi na przeszkodzie w uruchomieniu tego systemu na np. lighttpd czy nginksie. Tutaj przedstawione są jedynie zalecenia konfiguracyjne dla wygodnie i bezpiecznie działającej instalacji DLRS. Do działania DLRS powinien wystarczyć każdy serwer HTTP ze wsparciem dla PHP. Ze względu na konieczność umożliwienia użytkownikowi, którego prawa będzie posiadać proces serwera, zapisu przynajmniej do katalogu z plikami, zaleca się takie konfiguracje httpd, w których potencjalny złośliwy użytkownik mający konto na tym samym hoście mając do dyspozycji PHP mógłby np. zmodyfikować czy zniszczyć pliki, bądź też uzyskać do nich dostęp omijając ich atrybuty dostępu działające jedynie poprzez DLRS. Wobec tego, poza uruchamianiem w środowisku chroot (rozdział Bezpieczeństwo ), zalecane jest stosowanie rozsądnej konfiguracji PHP (rozdział Bezpieczeństwo ) oraz dedykowanego użytkownika, który nie posiada żadnych innych plików w systemie. Do relizacji projektu konieczna jest tutaj obsługa PHP, do celów głównie kosmetycznych zaś vhosty oraz przepisywanie adresów URL za pomocą modułu mod_rewrite. Jest to najluźniej związany z całym projektem element platformy, należy spodziewać się jego stopniowego wypierania przez wydajniejsze rozwiązania, takie jak lighttpd czy nginx. 4.3 MySQL DLRS jest ściśle związany z używanym oprogramowaniem bazodanowym. Z powodu swojej dojrzałości, bardzo szerokiego wsparcia i obszernej, precyzyjnej dokumentacji, popularności a także nabytego przez autora doświadczenia, do realizacji wybrany został właśnie MySQL. Kolejnym ważnym argumentem przemawiającym za tym oprogramowaniem są oferowane możliwości utworzenia środowiska rozproszonego. Co prawda rozwiązanie takie znane jest już od ośmiu lat w wydaniu Oracle RAC (Real Application Clusters), niemniej trzeba za nie dodatkowo płacić. Również z 12

13 takich względów nie zdecydowano się na, możnaby do niedawna rzecz, konkurencyjną platformę. Godnym uwagi rozwiązaniem mógłby się okazać również PostgreSQL wraz z middleware pgpool [pgpool-projects]. 4.4 PHP W wersji 5 PHP oferuje zaawansowany poziom obiektowości, szerokie wsparcie bazodanowe jak i zestaw wygodnych do manipulacji danymi funkcji, dzięki czemu świetnie nadaje się do budowania automatów generujących zawartość webową, która jest najpowszechniejszym, uniwersalnym oraz wspieranym na większości platform interfejsem dostępu do usług. Ponadto PHP posiada szerokie wsparcie dla HTTP, takie jak dostęp do nagłówków, co pozwala między innymi na obsługę cookies, rozpoznawanie wersji przeglądarki oraz uwierzytelnianie. Obecność biblioteki GD pozwala na dynamiczne generowanie wykresów oraz manipulację plikami graficznymi. W przypadku systemu DLRS wymagana jest możliwość dostępu do powłoki w PHP działającym jako CLI (Command Line Interface). Wymaganie jest to w obecnej architekturze systemu, gdyż konieczne do synchronizacji plików, co oznacza, że systemów składających się z jednej maszyny (tzw. tryb standalone) ten wymóg nie dotyczy. 4.5 ViLDeV System webowy to autorski skrypt ViLDeV, który jest aplikacją typu CMS (Content Management System) posiadającą pewne cechy frameworka. Zawiera między innymi system użytkowników oraz ich uwierzytelniania, parser szablonów, zaawansowany system formularzy z szeregiem udogodnień, zaawansowaną warstwę bazodanową, wsparcie dla treści w wielu językach. Dodatkowo posiada moduł systemu menu, newsów, artykułów, galerii, katalogu linków, komentarzy, wyszukiwarki. Bardzo wielu starań dołożono w kwestii bezpieczeństwa tej aplikacji. Poza automatycznym filtrowaniem wejścia pod kątem ataków SQL injection czy XSS (Cross Site Scripting), system formularzy posiada zabezpieczenia przed atakami CSRF (Cross Site Request Forgery) oraz tzw. floodem, a także automatyczny walidator uploadowanych plików jak i automatyczną weryfikację poprawnośći wprowadzonych danych (więcej o zagrożeniach aplikacji webowych w rozdziale Bezpieczeństwo ). Pełne możliwości tego systemu wykraczają poza wymagania systemu DLRS. Niestety nie jest stworzony z wykorzystaniem powszechnie znanych wzorców projektowych oraz nie spełnia w pełni wzorca MVC (Model View Controller) ze względu na zagnieżdżony gdzieniegdzie w modułach kod html, co wynika z faktu, iż zbudowany został bardzo amatorsko około czterech lt temu, a od tego czasu doczekał się jedynie drobnych modernizacji i nowych modułów. Przy bliższej sposobności planowana jest modernizacja architektury (ViLDeV 2.0) z zastosowaniem wszelkich pasujących wzorców projektowych a także silnika szablonów Smarty. Więcej informacji na temat systemu webowego w rozdziale Implementacja oraz w źródle [vildev]. 4.6 rsync+ssh rsync jest niewielkim, powszechnym narzędziem o sporych możliwościach. Służy do utrzymywania spójności pomiędzy zdalnymi systemami plików. Jego główną zaletą jest obsługa wielu 13

14 metod dostępu do plików, takich jak np. SSH czy FTP. W bieżącej wersji systemu wykonywanie zdalnych operacji na plikach polega na wywołaniu skonfigurowanego wcześniej rsynca poprzez jedną z wbudowanych funkcji PHP oferujących dostęp do powłoki. To wiąże ze sobą konieczność konfiguracji, w której funkcje te nie będą wyłączone. W większości przypadków nie powinno być potrzeby dostarczania funkcji wywołujących polecenia powłoki do PHP działającego dla nieustannie atakowanych aplikacji webowych. Problem można rozwiązać poprzez zmianę sposobu przesyłania plików na niewymagający rsync, np. poprzez wykorzystanie rozszerzenia PHP obsługującego samo SSH. W bieżącej wersji zachowano użycie rsync. Cechą charakterystyczną narzędzia jest umiejętność oszczędnego przesyłania jedynie różnic występujących w synchronizowanych systemach plików. Obsługuje także takie udogodnienia, jak kompresja oraz zdalne wykonywanie poleceń powłoki, co pozwala między innymi na automatyczne tworzenie nowych katalogów do przechowywania plików. Bezpieczeństwo transmisji (uwierzytelnianie, integralność, poufność) zapewniane są poprzez SSH. rsync uruchamiany jest bezpośrednio poprzez skrypt kolejki plików przeznaczonych do synchronizacji. PHP sprawdza wyjście narzędzia uruchamianego kolejno dla każdego z synchronizowanych plików i na tej podstawie zmienia w bazie informacje na temat stanu synchronizacji zasobu. Uwierzytelnianie pomiędzy węzłami przy przesyłaniu plików odbywa się poprzez infrastrukturę kluczy publicznych. 14

15 5. Struktura organizacyjna plików Na cały system składają się dwa główne katalogi. Pierwszy to public_html lub jego odpowiednik, w którym znajdować się będą wszystkie pliki systemu webowego, tj. ViLDeV z modułami DLRS. Z punktu widzenia serwera www jest to lokalizacja DocumentRoot dla dedykowanego pod aplikację vhosta. Drugi natomiast, library/, zawiera po prostu pliki, zwane ogólnie zasobami. Wszystkie metadane, tj. atrybuty książek elektronicznych, takie jak autor, tytuł, wydawnictwo czy kategoria, a przede wszystkim pełna nazwa pliku znajdują się w bazie danych. Sama nazwa pliku nie musi zawierać żadnych atrybutów. Rozdzielenie metadanych od systemu plików znacznie ułatwia zarządzanie, gdyż nie ma dzięki temu potrzeby nakładania jakichkolwiek restrykcji na nazwy plików, gdyż ich przeglądanie oraz wyszukiwanie i tak odbywa się za pośrednictwem systemu webowego. Początkowy pomysł na umieszczanie plików w katalogach odpowiadających kategoriom został porzucony ze względu na komplikacje, które by spowodował przy edycji atrybutów, przy jednoczesnym braku wynikających z tego korzyści, przy właśnie założeniu, że korzystanie z zasobów nie będzie polegać na bezpośrednim przeglądaniu systemu plików. Niemniej, aby zmniejszyć ryzyko wystąpienia problemu związanego z ograniczeniem danego systemu plików, tj. maksymalnej ilości plików w katalogu a także zauważalnego spadku wydajności przy przeszukiwaniu folderu z bardzo dużą ich ilością, celem uniknięcia potencjalnie kłopotliwego rozwiązywania tego problemu na działającej już instalacji, przyjęto następujące założenia dotyczące organizacji katalogów: nazwa pliku nie podlega edycji, co oznacza, że pozostaje w systemie w pierwotnej wersji, takiej, w jakiej został wprowadzony przez uploadera, sam plik zaś ulokowany jest w katalogu o nazwie składającej się z trzech pierwszych znaków jego nazwy, bez rozróżnienia na duże i małe litery. Dzięki temu ryzyko przekroczenia i tak wysokich limitów poszczególnych systemów plików na ilość plików w jednym katalogu zostaje praktycznie zniwelowane. Przykładowo dla popularnego na serwerach systemu plików reiserfs limit ten wynosi cztery miliardy, co przy założeniu, że nazwy plików mogą zaczynać się wyłącznie od liter, bez rozróżniania ich wielkośći, daje wielokrotność 8192 tego limitu. Przy proponowanej strukturze organizacyjnej i założeniu, że alfabet składający się na trzyznakowe nazwy posiada 40 znaków, maksymalna ilość wszystkich utworzonych automatycznie katalogów daje okrągłą liczbę, W związku z powyższym, struktura katalogów dla systemu DLRS przedstawia się, jak następuje: /home/dlrs - katalog domowy projektu /home/dlrs/public_html - system webowy /home/dlrs/library/ - zasoby biblioteki Dla przykładowej listy plików: Applied cryptography 2nd edition.odt Cryptography_Theory_and_Practice.doc handbook of security management.rtf Handbook of applied Cryptography.pdf faktyczne lokalizacje w katalogach mapowane są następująco: /home/dlrs/library/app/applied cryptography 2nd edition.odt 15

16 /home/dlrs/library/cry/cryptography_theory_and_practice.doc /home/dlrs/library/han/handbook of security management.rtf /home/dlrs/library/han/handbook of applied Cryptography.pdf Zważywszy na fakt, że wśród metadanych w bazie przechowywane będą pełne, oryginalne nazwy plików, dla systemu webowego nie będzie stanowić żadnego problemu odwołanie się do nich. Niektóre znaki specjalne powodują utrudnienia w przetwarzaniu nazw przez powłokę oraz rsync, który jest z niej wywoływany. Problemy te zostały jednak w większości rozwiązane (więcej szczegółów w rozdziale Synchronizacja ). 16

17 6. Synchronizacja Szczegóły synchronizacji MySQL zostały przedstawione w rozdziale Scenariusze, architektura sieci. Przebiega praktycznie w sposób automatyczny, tj. węzły typu slave same dbają o to, aby na bieżąco pobierać z mastera informacje o zmianach i stosować je do własnej bazy danych. Głównym problemem, jaki pozostaje rozwikłać jest synchronizacja plików pomiędzy węzłami. Z powodów natury organizacyjnej, wydajnościowej oraz większej uniwersalnośći rozwiązania, pliki trzymane będą w lokalnym systemie plików, nie w bazie (w wersji dla MySQL Cluster byłoby to wręcz niemożliwe, gdyż przewidziana jest duża pojemność systemu, zaś cała zawartość bazy w przypadku korzystania z silnika NDB musi znajdować się w pamięci RAM). Z punktu widzenia użytkownika, metadane o zasobach jak i same zasoby mogą być dodawane na dowolnym z węzłów (pod warunkiem, że działa węzeł master, aby można było dokonać aktualizacji na nim, zachowując spójność). Po pojawieniu się w masterze metadane rzeczywiście poprzez replikację podróżują do węzłów slave. Pliki natomiast są zapisywane lokalnie, fizycznie na maszynie, z której serwerem www użytkownik dokonuje połączenia. Ze względu na fakt, iż rozmiar plików jest praktycznie zawsze znacznie większy od opisujących je metadanych, a co za tym idzie prędkość przesyłania przez ich przez sieć będzie znacznie większa, synchronizacja plików będzie następować ze sporym opóźnieniem w stosunku do metadanych. Aby równomiernie rozłożyć obciążenie z tym związane, a także zachować spójność systemu, na potrzebę systemu opracowany został schemat wzajemnej synchronizacji zasobów oparty o kolejkę plików i wzajemne priorytety synchronizacji pomiędzy hostami, koordynowany z pomocą bazy danych. Nad kolejką plików, których synchronizacja nie została jeszcze spełniona, czuwa działający w tle skrypt PHP, który nieustannie pobiera z bazy informacje o nowododanych plikach a także o tym, które z hostów zakończyły już ich synchronizację. Za sam proces transferu plików przez sieć odpowiada popularne uniksowe narzędzie rsync, którego wywoływanie kontrolowane jest właśnie przez działający w tle skrypt kolejki synchronizacyjnej. Użytkownik, zwany dalej uploaderem, umieszcza nowy zasób na dowolnym z serwerów, za pośrednictwem interfejsu webowego, więc za pośrednictwem PHP. Plik zostaje zaindeksowany w bazie danych (wprowadzane są podstawowe informacje, takie jak tytuł, kategoria, autor, rok wydania, wydawnictwo, rozmiar, nazwa (która może zostać poddana modyfikacji, aby spełnić założenia nazewnictwa), a także opcjonalne atrybuty dostępu). W tym momencie wszystkie aktywne hosty dzięki replikacji wiedzą o nowym zasobie a także o tym, który z nich dokonał już związanej z tym synchronizacji. Rozpoczyna się proces synchronizacji plików za pomocą rsync. Składa się z dwóch etapów. Host, który oryginalnie otrzymał zasób, wywołuje rsync z innym hostem w sieci (tym, dla którego wpis w jego własnej tabeli priorytetów jest najniższy, tj. im niższy priorytet, tym pilniejszy). Efekt pracy rsync jest sprawdzany przez PHP, w zależności od tego podejmowana jest decyzja o dalszej synchronizacji (jeśli wszystko poszło zgodnie z planem, synchronizacja z punktu widzenia danego węzła jest zakończona, gdyż zgodnie z tym założeniem każdy węzeł, z wyjątkiem ostatniego, wykona szeregowo upload plików na kolejny węzeł, co łącznie działać ma jak efekt domino). Dla każdego z serwerów w bazie danych znajduje się wspomniana lista priorytetów synchronizacji z pozostałymi członkami sieci. Gwarantujące objęcie wszystkich węzłów oraz najoptymalniejsze zarazem ustawienie tych parametrów w sposób przedstawiony na rysunku nr

18 Rys. 6.1 schemat rozłożenia wzajemnych priorytetów synchronizacji plików pomiędzy węzłami DLRS Takie rozłożenie jest niezależne od ilości węzłów tego grafu, niemniej instalacja jednej instancji systemu DLRS zalecana jest na od jednej do pięciu maszyn, zgodnie z rekomendacją dla instalacji MySQL Cluster, podobne, acz mniej restrykcyjne zalecenia stosowane są dla MySQL z replikacją. Na rysunku 4 przedstawiono schemat blokowy algorytmu skryptu obsługującego kolejkę plików przeznaczonych do synchronizacji. Do celu generowania grafu wzjemnych priorytetów służy niewielki kawałek kodu SQL, który osadzony jest w wyzwalaczu uruchamianym po każdym dodaniu oraz usunięciu węzła z bazy, co zapewnia zawsze spójny, aktualny graf. Kolejnym ważnym elementem systemu jest działający w tle skrypt PHP odpowiadający za synchronizację plików za pośrednictwem rsync i SSH. Przy każdym dodaniu pliku do systemu, zostaje on zapisany lokalnie na dysku serwera HTTP węzła, z którym użytkownik akurat był połączony. Wraz z plikiem pojawiają się metadane a także dane synchronizacyjne, określające, na jakich fizycznie hostach już znajduje się plik. 18

19 Rys. 6.2 schemat blokowy algorytmu skryptu kolejki synchronizowanych plików Ta informacja jest zapisywana na serwerze master, a jej propagacja ma miejsce do innych węzłów poprzez replikację. Każdy węzeł, jeśli otrzymał nowy zasób, zobowiązany jest przekazać go jednemu innemu węzłowi, chyba, że wszystkie już posiadają dany zasób. To samo tyczy się poleceń usunięcia zasobu z systemu. Na każdym węźle lokalnie odpowiada za to właśnie wspomniany skrypt PHP, 19

20 którego schemat blokowy algorytmu przedstawia rysunek nr 6.2. Informacje o tym, czy dany węzeł posiada zasób oraz czy powinien wykonać jego synchronizację z innym węzłem przetrzymywane są w przeznaczonej do tego tabeli dlrs_sync. Szczegóły związane z implementacją skryptu w rozdziale Implementacja. 6.1 Awarie Oczywiście może dojść do sytuacji, w której jeden z węzłów staje się niedostępny, na przykład w wyniku awarii czy prac konserwacyjnych. Jeśli nie zakończył on swego udziału w procesie synchronizacji, tzn. istnieją zasoby, które nie zostały do niego przesłane, po osiągnięciu zbieżności przez pozostałe węzły, ostatni z zsynchronizowanych serwerów, za pośrednictwem działającego w tle skryptu kolejki synchronizacji będzie usiłował przesłać do niego pliki. Aby próby takie zostały poniechane, administrator posiadający uprawnienia do edycji nieczynnego węzła, tj. administrator w ViLDeV bądź członek grupy dlrs_admins, który jest właścicielem danego hosta bądź ma nadane przez właściciela specjalne uprawnienia, musi ręcznie poprzez panel administracyjny zmienić status serwera na offline. Od tego momentu serwer nie jest widziany przez żadną z instancji skryptu synchronizującego jako jeden z partnerów do synchronizacji, toteż próby przesłania plików z pomocą rsync nie są podejmowane. Proces synchronizacji jest osobny dla każdego z zasobów oraz niezależny od pozostałych. Po usunięciu awarii i ponownym uzyskaniu zbieżności z bazą mastera w procesie replikacji, administrator węzła powinien zmienić z powrotem status maszyny na online, co spowoduje, że ostatni z pozostałych węzłów, któremu nie udało się dokonać synchronizacji, ponownie podejmie tę próbę. Spójność jest zatem automatycznie utrzymywana z niewielkim stopniem ingerencji ze strony administratora, rozważane jest większe zautomatyzowanie tego procesu, poprzez automatyczną zmianę statusu hosta na offline w momencie, gdy jest on niedostępny, pozostawiając kwestię ustalenia statusu online w trybie ręcznym, wychodząc z założenia, że w wypadku awarii administrator i tak musi interweniować, a po włączeniu z powrotem MySQL oraz DLRS niekoniecznie chce, aby węzeł od razu przystąpił do synchronizacji plików. 20

21 7. Zagrożenia wyścigowe Zagrożenia wyścigowe, tzw. race conditions [race-conditions] to rodzaj problemów, jakie występują w środowiskach, w których jednocześnie funkcjonujące procesy są częśćiowo zależne od tych samych obiektów. Może być to sytuacja, w której jakiś obszar danych podlega zmianie, a następnie odczytowi przez ten sam proces. Pomiędzy zapisem a odczytem znajduje się okno czasowe, w którym może dojść do zmiany wskazanego obszaru danych przez inny proces, o czym nie dowie się proces pierwszy, który ułamek sekundy potem dokona odczytu danych, których spójność została właśnie naruszona. Przykładem jest np. doliczenie punktu w grze najpierw przez jeden, a następnie drugi rdzeń procesora, ze względu na błąd w ich synchronizacji, tj. braku zastosowania odpowiedniej blokady. Na jednym procesorze analogiczna sytuacja może dotyczyć chociażby działających jednocześnie różnych procesów i braku dokonania działającego ze skutkiem natychmiastowym zablokownia tej operacji dla innych procesów, tak jak czynią to semafory. Problem zagrożeń wyścigowych jest zatem nieodłącznym zagadnieniem systemów rozproszonych. Główną zaletą rozwiązania MySQL Cluster z punktu widzenia implementacji projektu DLRS jest fakt, iż każdy z serwerów MySQL może być traktowany tak, jakby był jedynym węzłem w sieci, tj. tak, jakby system rozproszony wcale nie istniał. Problem ten rozwiązywany jest więc w sposób transparentny. W przypadku replikacji nie można sobie na to pozwolić, gdyż nie zachodzi obustronna koordynacja działań na rekordach, zaś zmiany propagowane są tylko w jednym kierunku. To zmusza do uniknięcia problemów ze spójnością, takich jak dwie różne wersje tego samego rekordu, poprzez założenie, iż zapisy dokonywane są wyłącznie na węźle master. Ciągnie to za sobą konsekwencje implementacyjne, mianowicie każde zapytanie SQL, które nie rozpoczyna się od słowa SELECT, musi być wykonane na węźle master. W ViLDeV, specjalnie na potrzeby DLRS, opcja ta została zrealizowana poprzez rozpoznanie lokalnego ustawienia, informującego system o tym, czy pełni rolę węzła slave, czy master, następnie, jeśli ustawienie tego wymaga, a zapytanie nie rozpoczyna się od frazy SELECT, klasa odpowiedzialna za wykonywnie zapytań w locie dokonuje połączenia z MySQL węzła master i bezpośrednio tam wykonuje zapytania modyfikujące dane, których efekt następnie powraca zarówno do węzła slave, z którego wyszedł, jak i trafia do pozostałych węzłów slave za sprawą samego mechanizmu replikacji. W przypadku złożonych zestawów zapytań, takich jaki np. występuje przy operacji dodawania nowego węzła do sieci, nadal pozostawia furtkę do zaistnienia chwilowego braku spójności pomiędzy bazą master a slave, w wyniku której powstaną w bazie nieprawidłowe metadane. Sytuacja wygląda następująco: w systemie webowym dowolnego z węzłów dokonywane jest dodanie nowego hosta do tabeli dlrs_hosts, zwykłe polecenie INSERT. Jak wspomniano wyżej, jeśli nie nastąpi to bezpośrednio na węźle master, w locie zostanie wykonane połączenie z tymże właśnie serwerem. Zaraz po dodaniu hosta następuje ponowne zbudowanie grafu wzajemnych priorytetów synchronizacji. W tym celu wykonywane jest zapytanie SELECT na, jak założono, świeżo uaktualnionej o nowy rekord tabeli dlrs_hosts. Zgodnie z powyższym założeniem, SELECT będzie wykonany bezpośrednio na węźle, z którym łączył się administrator dodający hosta, zatem istnieje nikła szansa, że lokalna wersja tabeli zdąży się uaktualnić w wyniku replikacji, co 21

22 doprowadziłoby do zbudowania dokładnie takiego samego grafu priorytetów, jaki istniał przed dodaniem nowego hosta. Problem ten rozwiązano poprzez przeniesienie procedury generowania nowego grafu priorytetów do wyzwalacza nałożonego na tabelę dlrs_hosts, dzięki czemu cała operacja zostanie wykonana na serwerze master. Kolejnym, analogicznym przypadkiem jest sytuacja, w której do zasobów dodano jeden plik. Zostaje on przesłany do kolejnego, wskazanego grafem priorytetów węzła. Informacja o tym zapisana zostaje na węźle master. Istnieje realna szansa, iż zanim węzeł slave, który dokonał wysłania pliku, uaktualni swoją tabelę z metadanymi na temat synchronizacji poprzez replikację, zdąży po raz kolejny pobrać z lokalnej wersji bazy informację o tym, iż danego pliku nadal nie wysłał do żadnego serwera. Nie stwarza to żadnego zagrożenia poza ewentualną, nadmiarową próbą ponownego wysłania pliku do kolejnego węzła. Ze względu na fakt, iż synchronizacja przebiega szeregowo, a nie równolegle, nie istnieje poważniejsze zagrożenie wyścigowe w wypadku replikacji, które mogłoby przejawiać się sytuacją, w której kilka węzłów jednocześnie usiłuje wysłać któryś plik do tego samego serwera, następnie zmieniając informację w bazie, że niejako dokonały synchronizaji z jednym z pozostałych węzłów, co w przypadku powtórzenia się jednego z nich spowodowałoby, iż inny pozostałby bez danego zasobu w ogóle, a jego synchronizacja nigdy by nie nastąpiła. Można powiedzieć, że synchronizacja tego zasobu zostałaby osierocona. Również sprawdzenie, czy dodawany zasób już nie istnieje w systemie, odbywać się musi na węźle master. W przeciwnym wypadku istnieje nikłe, niemniej prawdopodobieństwo, iż w krótkim odstępie czasu do bazy wprowadzony zostanie ten sam zasób z dwóch różnych źródeł, gdyż sprawdzenie pod kątem np. sumy kontrolnej na lokalnym węźle zawiedzie z powodu zbyt dużego czasu osiągania zbieżności. Przy projektowaniu oraz implementacji należało zatem zwrócić uwagę na wymienione wyżej oraz analogiczne problemy, które śmiało można pominąć w wypadku, gdy zamiast replikacji można pozwolić sobie na MySQL Cluster. W tym celu wystarczy wyłączyć odpowiadającą za obsługę systemu replikowanego opcję silnika ViLDeV. 22

23 8. Analiza; projekt Niniejszy rozdział obejmuje analizę strukturalną i behawioralną systemu, ma na celu stworzenie modelu aplikacji pod kątem perspektywy logicznej, wdrożeniowej, implementacyjnej, przypadków użycia a także strukturalnej. Do tego celu zastosowany zostaje język UML (Unified Modeling Language), który powyższe podejście nazywa perspektywą 4+1 [uml-perspektywy]. 8.1 Użytkownicy i grupy Podstawowy podział rozróżnia zwykłych użytkowników oraz administratorów. Podejście jest bardzo proste, administratorzy mają pełną kontrolę nad zasobami, uprawnienia zwykłych użytkowników regulowane są zaś specjalnymi rekordami w stworzonej na ten cel tabeli, cały proces uwierzytelniania i autoryzacji zasobów oferuje wykorzystany do projektu system webowy, ViLDeV. Poza grupą administratorów na potrzeby projektu stworzono dodatkową grupę, mającą możliwość zarządzania informacjami o węzłach sieci oraz częściowej administracji nimi, a także dwie grupy do odseparowania uprawnień związanych z zarządzaniem zasobów od uprawnień pozwalających jedynie na korzystanie z nich. 23

24 Rys. 8.1 diagram przypadków użycia z wyszczególnieniem podstawowych grup użytkowników 8.2 Przypadki użycia Przypadek użycia reprezentuje kompletną funkcję oferowaną tzw. aktorowi przez system. Aktorem jest obiekt nienależący do samego systemu, zazwyczaj jest to użytkownik, niemniej może być to obiekt innego typu, który korzysta z jakiejś funkcji analizowanego systemu. Na rys. 8.1 przedstawione zostały przypadki użycia oferowane przez sam system DLRS, z pominięciem tych standardowo oferowanych przez ViLDeV, takich jak zarządzanie użytkownikami, zmiana języka, używanego szablonu HTML itp. Dostęp do poszczególnych grup przypadków użycia rozłożony jest hierarchicznie, ze stopniowym rozszerzaniem uprawnień. Każdy użytkownik ma prawo dostępu do używania systemu, jeśli należy do stworzonej do tego celu grupy dlrs_readers czy też grupy o wyższych prawach. Reprezentacją najpowszechniejszego użytkownika, o minimalnych uprawnieniach, jest obecny na diagramie aktor Reader. Użytkownik może posiadać status uploadera, co wiąże się również z przynależnością do analogicznej grupy dlrs_uploaders. Daje mu to dodatkowo dostęp do operacji modyfikujących zawartość bazy, tj. przypadków użycia związanych z dodawaniem i edycją zasobów, a także ustalania dla nich praw dostępu. Najwyższe uprawnienia mają administratorzy, oznacza to dostęp do wszystkich przypadków użycia i pełną kontrolę nad każdym 24

25 zasobem. Każdy z zasobów może mieć, podobnie jak pliki w systemach uniksowych, nadaną grupę, jedną z tych, do której należy osoba tworząca zasób. Pozwala to na bardzo precyzyjne określenie, kto ma prawo pełnej kontroli czy też wyłącznie odczytu pliku (toteż można bez problemu nie udzielić dostępu nikomu poza administratorami i właścicielem pliku). W takiej sytuacji użytkownicy administracyjni nadal mają pełną kontrolę, osoby należące do grupy uploaderów mają prawo do przypadków użycia związanych z przeglądaniem zasobów. Użytkownicy należący do grupy czytelników uzyskują dostęp wyłącznie do przypadków użycia związanych z odczytem danych, zaś użytkownicy nienależący do żadnej z grup nie mają prawa korzystać z modułów DLRS w ogóle Scenariusze przypadków użycia nazwa pakietu ReadResource numer 1 poziom ważności tryb przypadku użycia aktorzy krótki opis najwyższy szczegółowy Użytkownik Ten przypadek użycia odpowiada za kluczową funkcjonalność, jaką jest udzielenie użytkownikowi dostępu do pliku. warunki wstępne istnieje wywołanie od użytkownika, które identifykuje jednoznacznie zasób, do którego dostęp chce on uzyskać warunki końcowe użytkownik otrzymuje plik, w przypadku braku dostępu lub braku pliku otrzymuje stosowny komunikat o błędzie główne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system dokonuje autoryzacji system zwraca plik użytkownikowi alternatywne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu SearchResources numer 2 poziom ważności wysoki 25

26 tryb przypadku użycia aktorzy krótki opis szczegółowy Użytkownik Ten przypadek użycia odpowiada za kluczową funkcjonalność, jaką jest przeszukiwanie bazy pod kątem zasobów spełniających kryteria. warunki wstępne istnieje wywołanie od użytkownika, które identifykuje kryteria, jakie spełnić mają wynikowe zasoby warunki końcowe użytkownik otrzymuje listę odpowiadających kryteriom zasobów główne przepływy zdarzeń użytkownik wydaje żądanie przeszukania zasobów system zwraca żądaną część wyników alternatywne przepływy zdarzeń Użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu ListHosts numer 3 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Użytkownik Ten przypadek użycia dostarcza podstawowych informacji o tworzących sieć węzłach. warunki wstępne następuje wywołanie przypadku warunki końcowe użytkownik otrzymuje listę istniejących hostów, a jeśli jest ku termu uprawniony, również dodatkowe związane z nimi informacje, takie jak priorytety synchronizacji plików względem innych hostów oraz informację o stanie kolejki główne przepływy zdarzeń użytkownik wydaje żądanie listy hostów system zwraca informacje o stanie hostów alternatywne przepływy zdarzeń użytkownik wydaje żądanie listy hostów 26

27 system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu AddResource numer 4 poziom ważności tryb przypadku użycia aktorzy krótki opis wysoki szczegółowy Uploader Ten przypadek użycia pozwala na dodanie zasobu do bazy. warunki wstępne następuje wysłanie pliku oraz metadanych węzeł master jest dostępny warunki końcowe plik pozostaje zapisany na dysku, metadane wprowadzone do bazy, zaś skrypt kolejki jest gotów rozpocząć proces synchronizacji pliku między węzłami główne przepływy zdarzeń użytkownik wydaje żądanie dodania pliku system zwraca informację o powodzeniu alternatywne przepływy zdarzeń użytkownik wydaje żądanie dodania zasobu system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do dodawania zasobów system zwraca komunikat o błędzie do użytkownika nazwa pakietu EditResource numer 5 poziom ważności tryb przypadku użycia aktorzy krótki opis średni szczegółowy Uploader Przypadek odpowiada za modyfikację informacji dotyczącej istniejącego już w bazie zasobu, z 27

28 podmianą reprezentującego go pliku włącznie. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe użytkownik otrzymuje informację o powodzeniu operacji główne przepływy zdarzeń użytkownik wydaje żądanie edycji zasobu, przesyłając nowe metadane oraz opcjonalnie nowy plik zasobu system zwraca informację o powodzeniu edycji alternatywne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do modyfikacji wskazanego zasobu system zwraca komunikat o błędzie nazwa pakietu DeleteResource numer 6 poziom ważności tryb przypadku użycia aktorzy krótki opis średni szczegółowy Uploader Przypadek realizuje możliwość usunięcia zasobu z bazy. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe użytkownik otrzymuje informację o powodzeniu usunięcia główne przepływy zdarzeń użytkownik wydaje żądanie usunięcia zasobu system zwraca informację o powodzeniu usunięcia, usunięty zostaje plik oraz rozpoczęty proces uzyskiwania spójności z pozostałymi serwerami alternatywne przepływy zdarzeń użytkownik wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do usunięcia wskazanego zasobu system zwraca komunikat o błędzie 28

29 nazwa pakietu AddHost numer 7 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość formalnego dołączenia kolejnego węzła do systemu, co spowoduje między innymi zainicjowanie procesu synchronizacji. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o powodzeniu dodania hosta oraz rozpoczęciu procesu uzyskiwania spójności przez system główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego dodania system zwraca informację o powodzeniu w dodawaniu hosta, graf wzajemnych priorytetów synchronizacji zostaje przebudowany oraz rozpoczyna się synchronizacja plików nowego węzła alternatywne przepływy zdarzeń użytkownik wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie nazwa pakietu EditHost numer 8 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość edycji informacji o węźle, takich jak nazwa czy adres IP. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o powodzeniu edycji danych o węźle 29

30 główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego edycji system modyfikuje informację o hoście system zwraca informację o powodzeniu w edycji danych hosta alternatywne przepływy zdarzeń Administrator wydaje żądanie edycji system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie nazwa pakietu DeleteHost numer 9 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość formalnego odłączenia węzła od sieci. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o usunięciu węzła z sieci główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego usunięcia system usuwa z bazy metadane o hoście i zasobach na nim rozlokowanych system zwraca informację o powodzeniu usunięcia hosta alternatywne przepływy zdarzeń Administrator wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie 30

31 8.3 Diagram klas Rys. 8.2 diagram klas systemu Powyższy diagram przedstawia tylko te najważniejsze z punktu widzenia projektu DLRS klasy. Pominięte zostały pewne mniej istotne, będące szczegółem implementacyjnym samego systemu ViLDeV, takie jak klasa obsługująca zmianę języka, klasa odpowiadająca za warstwę bazodanową, klasa parsera szablonów oraz inne składające się na ten CMS. Wyjątkiem na diagramie są ViLDeV, 31

32 usr_ctrl oraz user, gdyż stanowią one rdzeń systemu z użytkowego punktu widzenia, zawierają operacje związane z obsługą użytkowników, uwierzytelniania oraz autoryzacji. Jedyne dedykowane dla tego projektu moduły reprezentowane są przez klasy obsługi akcji związanych z zasobami, które są bezpośrednio przedmiotem projektu, tj. zasobami biblioteki oraz informacjami o węzłach tworzących system rozproszony. 8.4 Diagram komponentów Rys diagram komponentów przedstawiający strukturę aplikacji od podstawowego interfejsu użytkownika CRUD, poprzez pakiet realizujący właściwe zadanie, DLRS, który z kolei zależny jest kolejno od CMS-a ViLDeV, PHP oraz MySQL Przedstawiony na rysunku nr 8.3 diagram realizuje spojrzenie na powiązania między komponentami z perspektywy systemu DLRS. Każdy z modułów implementuje podstawowy interfejs, nazwany CRUD od podstawowego sposobu podziału metod ze względu na operację, jaką wykonują na 32

33 danych (Create Read Update Delete). Zarówno moduł ResourceManager jak i HostManager implementują te same, podstawowe metody odpowiadające elementarnym operacjom, tj: create add_host, add_resource read show_host, list_hosts, show_resource, list_resources update edit_host, edit_resource delete del_host, del_resource Implementują go również wszystkie pozostałe moduły tego CMS-a. 8.5 Diagramy interakcji Diagramy interakcji przedstawiają przebieg komunikacji pomiędzy obiektami, zazwyczaj tworzy się je dla określonych przypadków użycia [diagramy-interakcji]. Język UML definiuje cztery rodzaje tych diagramów. Są to: diagram sekwencji, komunikacji (w UML 1.0 nazywany jeszcze diagramem interakcji), przeglądu interakcji oraz diagram zależności czasowych Diagramy sekwencji dla podstawowych przypadków użycia Rys. 8.4 diagram sekwencji dla przypadku użycia odczytania zasobu Zamieszczony na rys. 8.4 diagram sekwencji przedstawia przepływ sterowania pomiędzy aktorem reprezentującym zwykłego użytkownika, a modułem obsługującym operacje na zasobach. Elementarne operacje, jakie zachodzą w module, to sprawdzenie poprawności żądania, a następnie sprawdzenie uprawnień do niego w kontekście bieżącego użytkownika. Kolejny diagram jest analogiczny. 33

34 Rys diagram sekwencji dla przypadku użycia przeszukiwania zasobów Rys. 8.6 diagram sekwencji dla przypadku użycia edycji informacji o węźle, tj. hoście Na rys. 8.6 przedstawiono diagram sekwencji dla administracyjnego przypadku użycia służącego do zarządzania hostami. Podobnie, jak w przypadku poprzednich i wszystkich innych przypadków użycia, sprawdzenie poprawności odwołania, autoryzacja a następnie zmiana dokonywana jest na bazie. 34

35 Rys. 8.7 diagram sekwencji dla przypadku użycia dodawania zasobu (AddResource) Na diagramie przedstawionym na rys. 8.7, prezentującym przepływ sterowania pomiędzy obiektami dla przypadku wprowadzania zasobu do bazy, widać większy stopień złożoności w stosunku do diagramów poprzednich. W pierwszej kolejności, rutynowo sprawdzana jest poprawność danych wejściowych oraz przeprowadzana jest autoryzacja. Ze względu na fakt, że wszystkie operacje zapisu odbywają się na masterze za pośrednictwem połączenia klienckiego wykonanego z aktualnie biorącego udział w operacji węzła, do powodzenia tej operacji konieczna jest dostępność tego pierwszego. Wynika to z wspomnianego w rozdziale Scenariusze; architektura sieci; założenia architektonicznego. Zapis następuje zawsze na węźle master, więc warunkiem koniecznym jest jego dostępność. 8.6 Diagramy stanu Diagramy stanu reprezentują kolejne stany, w jakich znajduje się system bądź jego obiekt w trakcie wykonywania danych przypadków użycia, a także przejścia pomiędzy tymi stanami. Kolejne rysunki przedstawiają diagramy stanów dla tych samych przypadków użycia, dla których 35

36 przedstawiono diagramy sekwencji. Bardzo pokrewnym rodzajem diagramów są diagramy czynności, które na pierwszym planie skupiają się na czynnościach, a w planie drugorzędnym na stanach, w jakich system znajduje się pomiędzy przejściami. Ze względu na wyjątkową prostotę systemu diagramy te w tym przypadku są praktycznie tożsame, zatem pominięto tworzenie diagramów czynności. Rys. 8.8 diagram maszyny stanów dla przypadku odczytywania zasobu (ReadResource) Podstawowe stany reprezentują własności w dziedzinie zastosowań. Diagram maszyny stanów na rys. 8.8 prezentuje podstawowe stany systemu i warunki przejść między nimi. Przejście ze stanu początkowego do stanu sprawdzenia, czy wskazany zasób istnieje, następuje gdy dostarczony identyfikator jest liczbą naturalną większą od 0. W zależności od powodzenia tej weryfikacji, następuje 36

37 przejście do stanu końcowego w wyniku błędnego odwołania, lub przejście do stanu analizy uprawnień do poprawnie wskazaznego zasobu. W zależności od ustanowionych praw dostępu dla danego zasobu a także statusu użytkownika określony zostaje stopień uprawnienia, tzw. chmod. Wartość rw oznacza pełną kontrolę (odczyt i zapis), r jedynie odczyt, w przeciwnym wypadku dostęp jest zablokowany. Proces na kolejnym diagramie (rys. 9) przebiega analogicznie, przy czym zawiera on pętlę iterującą po kolejnych rekordach wynikowych, aby dla każdego z osobna podjąć decyzję autoryzacji. Rys. 8.9 diagram maszyny stanów dla przypadku przeszukiwania zasobów (SearchResources) 37

38 8.7 Diagram wdrożenia Diagramy wdrożenia mają za zadanie oddać fizyczne rozlokowanie elementów systemu i powiązania między nimi, toteż znajdują zastosowanie głównie w dużych systemach, w szczególności w systemach rozproszonych. Dla systemu składającego się z jednego komponentu lub kilku ulokowanych na tej samej maszynie nie ma większego sensu tworzenia tychże diagramów. Rys. 8.7 przedstawia przykładowy diagram wdrożenia systemu składającego się z trzech węzłów. Elementy umieszczone wewnątrz nich, tj. oprogramowanie, skompilowane, gotowe do użycia komponenty nazywane są w tych diagramach artefaktami. Linie łączące węzły oznaczają ścieżki komunikacyjne. Rys diagram wdrożenia dla sieci składającej się z trzech węzłów 38

39 9. Implementacja 9.1 MySQL W tej części przedstawiona jest struktura całej składającej się na projekt bazy danych oraz jej obiektów, takich jak widoki, procedury składowane oraz indeksy. Pozostałe tabele (użytkownicy, grupy, kategorie itd.) i związane z nimi obiekty (widoki, procedury, funkcje etc.) nie są bezpośrednio częścią projektu, a standardową architekturą bazodanową dla użytego do tego celu systemu webowego [vildev-mysql]. Rys. 9.1 diagram związków encji ERD (Entity Relationship Diagram) Poniżej przedstawiono część kodu SQL tworzącego obiekty bazy, pomijając nieistotne z punktu widzenia samego DLRS standardowe obiekty CMS-a ViLDeV, związane z obsługą natywnych encji, 39