2010.03.02, WEiTI PW, RSO.B, tjk Treść zadania laboratoryjnego ============================= Każda grupa projektowa ma za zadanie a. zaprojektowanie, b. zaimplementowanie, c. przetestowanie i c. zademonstrowanie rozproszonej usługi pełniącej funkcję monitora transakcyjnego wykorzystującego zewnętrzne systemy zarządzania bazami danych co najmniej dwóch rodzajów. Monitor transakcyjny powinien przyjmować ustalony podzbiór poleceń SQL i inteligentnie pośredniczyć w przekazywaniu ich systemom bazodanowym wybranych typów. Różnice w typach systemów bazodanowych powinny być przezroczyste dla użytkownika. System powinien mieć możliwość zarządzania wieloma równocześnie uruchomionymi instancjami każdego z typów systemów bazodanowych. Zrealizowane rozwiązanie powinno cechować się dobrą wydajnością i zwiększoną odpornością na uszkodzenia. System powinien mieć zorganizowany mechanizm równoważenia obciążenia. Wyłączenie _dowolnego_ z węzłów sieci z działającą usługą nie może przerywać działania całego serwisu. System powinien również prawidłowo obsługiwać ponowne przyłączenie węzła aplikacji po chwilowej przerwie w komunikacji sieciowej. Cele te powinny być osiągnięte poprzez wykorzystanie środowiska systemu Linux Postępy prac i wersja finalna mają być uruchomione, przetestowane i zademonstrowane w środowisku systemu Linux (Ubuntu) w laboratorium 518. W zależności od konfiguracji system powinien wykazywać zwiększenie wydajności lub/i zwiększenie niezawodności wraz ze wzrostem liczby zaangażowanych węzłów w zakresie ustalonej skalowalności projektu. System powinien oferować opcjonalnie uruchamiany tryb pracy "przetrwać za wszelką cenę", który obrazuje przykład: Niech w konfiguracji będzie zadane, że system ma startować na pięciu węzłach, a każdy zasób ma być w minimum trzech replikach. W sytuacji, gdy w aktualnej konfiguracji wymuszono pełną replikację na wszystkich węzłach i gdy z pięciu węzłów klastra, na których uruchomiono usługę, dwa przestały działać już uprzednio i właśnie przestaje działać trzeci, system powinien automatycznie uruchomić demon usługi na jeszcze innym węźle tak, by móc spełnić wymóg posiadania minimum trzech replik każdego zasobu. Szczegółowe wymagane cechy rozwiązania: - system ma mieć dokładnie jeden tekstowy plik konfiguracyjny definiujący m.in. konfigurację startową systemu, - komunikacja klientów usługi z serwisem poprzez gniazdo o zadanym w pliku konfiguracyjnym adresie (bądź kilka gniazd na różnych węzłach), - operacje na danych powinny obejmować co najmniej: - zakładanie nowej tabeli o zadanej strukturze, - wstawianie rekordów do tabeli, - wyszukiwanie rekordów pasujących do pewnego wzorca, - modyfikacja rekordów pasujących do pewnego wzorca, - usuwanie rekordów pasujących do pewnego wzorca, - elastyczne blokowanie rekordów pasujących do pewnego wzorca (blokada zapisu, blokada zapisu i odczytu), - usuwanie tabeli, - poza operacjami na danych baza powinna obsługiwać różne zlecenia administracyjne, w szczególności: - uzyskiwanie danych statystycznych o poszczególnych tabelach, - uzyskiwanie danych statystycznych o aktualnym stanie bazy danych, - dynamiczne sterowanie własnościami bazy i tabel, np. liczbą replik poszczególnych tabel, minimalną liczbą węzłów systemu, na których uruchomiona jest usługa, itp. - zrzut zawartości bazy danych do pliku o zadanej nazwie, - załadowanie zawartości bazy danych z pliku o zadanej nazwie, - demonstracja powinna m.in. pokazywać po jednym scenariuszu, w którym: - jest większa wydajność niż ta sama grupa zleceń zadana bezpośrednio jednej z baz bez pośrednictwa monitora transakcyjnego, - występuje etryb 'przetrwać za wszelką cenę', - pozazane są niezawodnościowe cechy rozwiązania, w szczególności odporność na awarie poszczególnych węzłów i ponowne automatyczne dołączanie się węzłów po awarii. Efektem końcowym projektu powinien być: - pakiet z instalacją demona usługi na koncie użytkownika. Usługa powinna być uruchamiana skryptem o strukturze analogicznej do struktury skryptów startujących usługi umieszczanych w katalogu /etc/init.d/. Powinna zatem właściwie startować i delikatnie kłaść rozproszoną na wiele węzłów grupę procesów oraz zwracać status przy następujących jednokrotnych wywołaniach: ./usługa start ./usługa stop ./usługa status - zautomatyzowana procedura prezentacji możliwości zrealizowanego rozwiązania. Zautomatyzowanie polega na dostarczeniu skryptu interpretera sh oraz być może wstępnie przygotowanych dla celów prezentacji danych wejściowych. W celu zaliczenia projektu wymagana będzie prezentacja zrealizowanego rozwiązana polegająca na sprawnej instalacji pakietu i uruchomieniu skryptu demostracyjnego w środowisku laboratorium 518, - zestaw testowych skryptów interpretera sh demonstrujących możliwości rozwiązania z uwzględnieniem następujących zmiennych parametrów pracy systemu: - liczba uruchomionych demonów usługi, - poziom replikacji poszczególnych tabel, - rozmiar danych przechowywanych w poszczególnych tabelach, - obciążenie systemu równoczesnymi zleceniami od aplikacji klienckich, - pełna dokumentacja projektu zawierająca co najmniej następujące pozycje: - uporządkowane wstępne opracowania, - szczegółową koncepcję zaproponowanego rozwiązania, - sprawozdanie z prac nad projektem, czyli listę spotkań roboczych wraz z datami i ustaleniami, - dokumentację techniczną proponowanego rozwiązania, - szczegółową analizę - popartą statystykami otrzymanymi w wyniku uruchamiania przygotowanych skryptów testowych - następujących aspektów rozwiązania: - niezawodność zrealizowanego rozwiązania, - wydajność zrealizowanego rozwiązania, - analiza skalowalności rozwiązania pod względem rozproszenia, replikacji i rozmiaru przechowywanych danych. - dokumentację uruchamiania i konfiguracji systemu, - opis przygotowanych skryptów testowych i prezentacyjnych. Ważne: z dokumentacji musi jasno wynikać, kto i w jakim stopniu uczestniczył w realizacji poszczególnych elementów projektu. Narzędzia programistyczne ========================= Do realizacji projektu dopuszcza się wykorzystanie następujących języków: Java, C/C++, sh, Perl, Python. Należy wykazać się samodzielnym zaimplementowaniem algorytmów rozproszonych - czym bardziej zaawansowane mechanizmy będą wykorzystywane z gotowych bibliotek programistycznych, tym bardziej zaawansowane kompleksowo rozwiązanie będzie oczekiwane i wymagane od zespołu projektowego. Rozwiązanie należy obowiązkowo uruchomić i zademonstrować pod kontrolą Linuksa w laboratorium 518. To na zespole spoczywa obowiązek upewnienia się, że zastosowano narzędzia i postawiono wobec środowiska wymagania, które mogą być zrealizowane w laboratorium 518. Do realizacja pracy grupowej (implementacja/dokumentacja) wymagane będzie użycie systemu kontroli wersji, na przykład subversion, dostępnego w laboratorium 518. Użycie systemu subversion bądź innego systemu kontroli wersji o porównywalnej funkcjonalności jest obowiązkowe. Cała dokumentacja ma być przygotowana z wykorzystaniem systemu Latex. Dokumenty należy przekazywać prowadzącemu w formacie pdf. Użycie systemu Latex jest obowiązkowe. Do harmonogramowania zadań kierownicy projektów mogą użyć dostępnego pod Linuksem narzędzia planner (http://live.gnome.org/Planner). Użycie narzędzia planner jest wskazane, ale nie jest obowiązkowe, natomiast samo harmonogramowanie projektu jest obowiązkowe i powinno mieć swój ślad w dokumentacji. Ocenianie ========= Z przedmiotu RSO można zdobyć maksymalnie 100 punktów, 40 punktów z kolokwium oraz 60 punktów z laboratorium. W celu zaliczenia przedmiotu wymagane jest uzyskanie minimum 50 punktów sumarycznie z kolokwium i laboratorium. Z laboratorium można uzyskać 60 punktów. Punkty uzyskiwane są z dwóch źródeł: 1. ocena projektu jako całości z końcowym rozdysponowaniem uzyskanych punktów przez kierownika projektu (0-30 punktów), 2. ocena indywidualna pracy każdego z członków zespołu przeprowadzona przez prowadzącego laboratoria po zakończeniu projektu. Ad 1. W trakcie semestru występują dwa terminy oceniania postępów w realizacji projektów (tzw. kroki milowe) oraz końcowa ocena realizacji projektu. Na każdym z tych etapów prowadzący laboratorium ma możliwość przyznania do 10 punktów całemu zespołowi projektowemu, zatem na koniec laboratorium projekt sumarycznie oceniony jest w skali 0-30 punktów. Nabyta liczba punktów staje się automatycznie liczbą punktów uzyskaną przez kierownika danego projektu. Jednocześnie kierownik, na podstawie własnej oceny wkładu poszczególnych członków zespołu, decyduje o tym, ile punktów przyznać każdemu z członków zespołu projektowego. Muszą być jedynie spełnione poniższe warunki: - średnia punktów przyznana członkom zespołu jest równa dokładnie liczbie punktów jaką uzyskał projekt, - każdy z członków zespołu projektowego musi uzyskać liczbę punktów z zakresu 0-30 punktów włącznie. Najprostszym rozwiązaniem spełniającym powyższe warunki jest przyznanie wszystkim członkom zespołu po tyle samo punktów, co uzyskał projekt i zarazem kierownik, jednak kierownik ma prawo do innego rozdziału punktów. Ważne: przy podziale punktów nie mogą być uwzględniane punkty osób, które w trakcie semestru wycofały się z danej grupy projektowej. Ad 2. Ocena indywidualna przez prowadzącego laboratoria daje możliwość uzyskania od 0 do 30 punktów włącznie. Przy ocenie uwzględniana jest m.in. dokumentacja pracy członka zespołu, uzyskana liczba punktów z oceny projektu jako całości, systematyczność pracy, obecność na wymaganych terminach oraz ocena rzeczywistego wkładu danego członka zespołu. Z tego względu bardzo ważnym jest, by w dokumentacji projektowej na każdym etapie było ściśle określone, który członek i w jakim stopniu jest odpowiedzialny za poszczególne części projektu. Bonus: ------ Uwaga, prowadzący laboratoria ma prawo podnieść liczbę uzyskanych punktów przez dwa zespoły projektowe, o ile zespoły te poddadzą swoje autorskie rozwiązania serwerowe krzyżowo przygotowanym przez drugi z zespołów testom wydajności i niezawodności i porównają w dokumentacji z cechami własnego rozwiązania. Grupy projektowe ================ Zadania realizowane są w grupach projektowych. Każda grupa ma przypisany tydzień (nieparzysty - grupy A i B oraz parzysty - grupy D i E), w którym ma do dyspozycji laboratorium 518. Taki podział gwarantuje, iż w danej chwili w laboratorium znajdują się co najwyżej trzy grupy projektowe. Ścisły harmonogram przedstawiony jest na końcu niniejszego opracowania. Wymagania odnośnie realizacji zadania projektowego ================================================== Realizacja zadania podzielona jest na trzy oceniane osobno fazy. Faza pierwsza kończy się pierwszym krokiem milowym, druga drugim krokiem, a trzecia demonstracją końcową projektu i przekazaniem pełnej dokumentacji projektu. Na zajęciach, na które wypada oddanie kolejnej fazy projektu obecność _wszystkich_ członków zespołu jest obowiązkowa. W pozostałych terminach zajęć obecność na zajęciach nie jest obowiązkowa. Uwaga, w pozostałych terminach laboratorium istnieje możliwość udostępnienia sali 518, ale pod warunkiem wysłania co najmniej dzień wcześniej na e-mail prowadzącego informacji o zamiarze skorzystania z laboratorium. Wstępna faza jest fazą zapoznawania się z zagadnieniem do realizacji, dostępnymi narzędziami, środowiskiem uruchomieniowym, dostępnymi opracowaniami z poprzednich lat. Faza ta wymaga następujących kroków do realizacji na zajęciach wstępnych: - organizacja pięcio- bądź sześcioosobowych grup projektowych, żaden student nie może zostać poza grupą projektową, - przypisanie terminu do grupy, - wybór kierownika projektu, Rolą kierownika będzie następnie ustalenie ról poszczególnych członków projektu. W grupie projektowej powinny zostać wyróżnione co najmniej następujące role: a. kierownik projektu, b. osoba zarządzająca repozytorium projektu i odpowiedzialna za przechowywanie aktualnej kopii zapasowej projektu, c. osoba odpowiedzialna za przygotowanie demonstracji prototypu oraz przygotowanie i opisanie prezentacji końcowej, d. osoba odpowiedzialna za zarządzanie dokumentacją projektu, zbieranie i ujednolicanie dokumentacji technicznej pisanej przez innych członków zespołu oraz m.in. protokołowanie ustaleń z poszczególnych spotkań roboczych zespołu projektowego, e. osoba odpowiedzialna za testowanie rozwiązania. Kierownik wyznacza i przydziela powyższe oraz dodatkowe role. Wszystkie osoby z przydzielonymi rolami za wyjątkiem kierownika projektu mogą wchodzić w skład zespołu programistycznego realizującego projekt. Kierownik projektu ma zakaz uczestniczenia w pracach implementacyjnych. Rolą kierownika będzie przydzielenie członkom zespołu poniższych zadań do opracowania (w podzespołach bądź pojedynczo): FAZA 1 ------ W trakcie pierwszej fazy każdy z zespołów ma za zadanie zrealizować poniższe opracowania. Przed przystąpieniem do ich pisania, proszę zapoznać się z dostępnymi na stronie WWW przedmiotu opracowaniami studenckimi z poprzednich lat. Wymagane opracowania: 1. Przygotowanie środowiska dla pracy grupowej w ramach projektu. Przygotowanie środowiska do zarządznaia wersjami. 2. Wprowadzenie do zagadnienia realizacji niezawodności i wydajności poprzez replikację zasobów i zarządzanie spójnością danych. Wstęp do algorytmów realizacji wysokiej dostępności i niezawodności rozproszonych zasobów. 3. Koncepcja proponowanego do realizacji rozwiązania. Powyższe tematy powinny być realizowane przez poszczególnych członków zespołu, a po pierwszym kroku milowym być źródłem wiedzy dla wszystkich członków zespołu, w celu wspólnego opracowania szczegółowej koncepcji docelowego rozwiązania. Pierwszy krok milowy to zakończenie realizacji powyższych opracowań i przekazanie ich w postaci papierowej osobie prowadzącej laboratorium. FAZA 2 ------ Faza druga ma następujące zadania: - opracowanie szczegółowej koncepcji rozwiązania, - realizacja prototypu oferującego ograniczoną funkcjonalność. Zaliczenie tego etapu projektu, to przedstawienie dokumentacji ze szczegółową koncepcją rozwiązania docelowego oraz demonstracja w laboratorium 518 zainstalowanego prototypu, który oferuje ograniczoną funkcjonalność. Na tym etapie nie jest wymagana kompletna dokumentacja, a demostracja prototypu nie musi być automatyczna, jednak system ma już dla wybranych scenariuszy oferować pełną funkcjonalność. FAZA 3 ------ Faza trzecia to dokończenie realizacji projektu, skompletowanie dokumentacji, przeprowadzenie testów i demonstracji rozwiązania, czyli dostarczenie wszystkich wymaganych efektów końcowych projektu. Terminy laboratorium i harmonogram oceniania ============================================ data tydzień I tydzień II nr zajęć nr zajęć grupy A,B grupy C,D 09.03 16.03 1* 23.03 1* 30.03 07.04 13.04 20.04 27.04 2* 04.05 2* 18.05 25.05 01.06 3* 08.06 3* 15.06 * - krok milowy, w tym terminie można uzyskać punkty za projekt. Obecność _wszystkich_ członków grupy w terminie kroku milowego jest _obowiązkowa_. W pozostałych terminach laboratorium istnieje możliwość udostępnienia sali 518, ale pod warunkiem wysłania co najmniej dzień wcześniej na e-mail prowadzącego informacji o zamiarze skorzystania z laboratorium. Ważne: proszę zwrócić uwagę, że na przełomie kwietnia i maja mają mieć Państwo już gotowy uruchamialny prototyp Waszego rozwiązania.