2006.03.06, WEiTI PW, RSO.B, tjk Treść zadania laboratoryjnego ============================= Każda grupa projektowa otrzyma za zadanie zaprojektowanie, zaimplementowanie, uruchomienie i przetestowanie klastrowego rozwiązania systemu zarządzania bazą danych w oparciu o rozwiązanie o otwartych źródłach MySQL (www.mysql.com). Zrealizowane rozwiązanie powinno cechować się zwiększoną wydajnością i odpornością na uszkodzenia w stosunku do rozwiązań standardowych. Wyłączenie dowolnego z węzłów klastra z danymi nie powinno przerywać działania serwisu. Zapytania do bazy powinny być przezroczyście rozpraszane do różnych replik w celu zwiększenia wydajności. Cele te powinny być osiągnięte poprzez wykorzystanie środowiska i specyficznych własności rozwiązania klastrowego OpenSSI oraz realizację fizycznej replikacji zasobów w środowisku klastra. Osiągnięte lepsze własności powinny być zademonstrowane przez przygotowane i zrealizowane testy porównawcze. Efektem końcowym projektu powinny być: - 1. paczka ze standardową instalacją silnika bazy danych instalującą się na koncie użytkownika, bez konieczności angażowania katalogów systemowych i konta root, - 2. analogiczna paczka ze zoptymalizowaną pod klaster, ale ciągle bez własnych rozszerzeń w ramach projektu RSO, klastrową instalacją silnika bazy danych, - 3. najważniejsze: paczka z silnikiem bazy danych skonfigurowanym i rozszerzonym o nowy kod (wykorzystujący optymalnie środowisko OpenSSI) autorskim rozwiązaniem zrealizowanym w ramach projektu RSO, Wszystkie trzy rozwiązania powinny być uruchamiane i kończone skryptami o strukturze analogicznej do struktury skryptów startujących usługi umieszczonych w katalogu /etc/init.d/. Powinny zatem właściwie startować i delikatnie kłaść rozproszoną na wiele procesów usługę 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. W celu zaliczenia projektu wymagana będzie prezentacja jego działania z wykorzystaniem tej procedury na ostatnich zajęciach, - zautomatyzowana procedura przeprowadzania testów porównawczych pod względem wydajności i niezawodności powyższych trzech (1.-3.) systemów zarządzania bazą danych, - pełna dokumentacja projektu zawierająca co najmniej następujące pozycje: - uporządkowane wstępne opracowania, - koncepcję zrealizowanego rozwiązania, - sprawozdanie z prac nad projektem, czyli listę spotkań roboczych wraz z datami i ustaleniami, - dokumentację techniczną dotyczącą trzech zrealizowanych paczek, w szczególności metody ich instalacji i konfiguracji, - dokumentację techniczną opisującą poszczególne zrealizowane moduły oprogramowania, - opis uruchamiania i konfiguracji systemu, - opis testów oraz wyniki testów. Z dokumentacji jasno musi wynikać, kto i w jakim stopniu uczestniczył w realizacji poszczególnych elementów projektu. Rozszerzenia i modyfikacje serwera powinny być przezroczyste dla klientów usługi MySQL. Oznacza to, że z punktu widzenia klienta serwer bazodanowy we wszystkich trzech przypadkach (1.-3.) powinien być widziany w identyczny sposób, jako usługa MySQL nasłuchująca na zadanych w pliku konfiguracyjnym porcie. Wszystkie trzy rozwiązania z punktu widzenia przetwarzania danych powinny być dla klienta identyczne i wyglądać jak standardowa instalacja serwera bazy MySQL. Dopuszcza się rozszerzenie listy interpretowanych poleceń w rozwiązaniu 3. o polecenia specyficzne dla zaprojektowanego i zrealizowanego rozwiązania. Narzędzia programistyczne ========================= Realizacja rozwiązania wymagać będzie najprawdopodobniej napisania własnego serwisu (demona bądź grupy demonów), który będzie nasłuchiwał w imieniu serwera/serwerów i pośredniczył w kontakcie klientów MySQL z serwerami MySQL oraz zmian/rozszerzeń w samym kodzie serwera MySQL. Rozszerzenia istniejących modułów należy zaprogramować w tych samych językach, w których oprogramowano rozszerzane rozwiązanie (C/C++/sh/perl). Elementy nowe należy realizować wyłącznie w C/C++/perl/sh. Rozwiązanie należy obowiązkowo uruchomić i zademonstrować w środowisku klastra OpenSSI w laboratorium 25. Do realizacja pracy grupowej (implementacja/dokumentacja) służy system kontroli wersji subversion, dostępny na klastrze w laboratorium 25. Użycie systemu subversion jest obowiązkowe. Cała dokumentacja ma być przygotowana z wykorzystaniem systemu Latex według wskazówek przedstawionych przez prowadzących przedmiot. Dokumenty należy przekazywać prowadzącym 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://developer.imendio.com/wiki/Planner). Użycie narzędzia planner nie jest obowiązkowe. 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 dwa 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 prawno na przykład przyznać 0 punktów osobie, która nie zaangażowała się w ogóle w projekt, a jej punkty rozdzielić między pozostałych członków zespołu. 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 będą realizowane w grupach projektowych pięcio- bądź sześcio-osobowych. Prowadzący dany termin laboratoryjny ustala ile grup jest tworzonych. Będą to w zależności od frekwencji 3 lub 4 grupy na dany termin (12-14, 14-16). Grupa będzie miała przyznane co drugi tydzień po dwie godziny, co gwarantuje iż w danej chwili w laboratorium będą się znajdować maksymalnie dwie grupy projektowe. Ścisły harmonogram jest przedstawiony w dalszej części. 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. Pierwsza faza jest fazą zapoznawania się z zagadnieniem do realizacji, narzędziami oraz środowiskiem uruchomieniowym. Faza ta wymaga następujących kroków wstępnych do realizacji na zajęciach wstępnych. Na zajęciach wstępnych _muszą_ być wykonane następujące kroki: - organizacja 5-6 osobowych grup projektowych, żaden student nie może zostać poza grupą projektową, - uzgodnienie z prowadzącym laboratorium, czy grupa ma przydzielone tygodnie parzyste czy nieparzyste, - wybór kierownika projektu, - ustalenie przez kierownika projektu ról poszczególnych członków w projekcie. W grupie projektowej powinny zostać przyznane następujące role: a. kierownik projektu, b. osoba zarządzająca repozytorium projektu i odpowiedzialna za przechowywanie aktualnego backupu 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 może ustalić i przydzielić 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. - przydzielenie przez kierownika projektu członkom zespołu przedstawionych poniżej tematów pierwszej fazy do opracowania. FAZA 1 ------ W trakcie pierwszej fazy każdy z zespołów ma za zadanie zrealizować opracowania bądź wprowadzenia praktyczne dotyczące następujących zagadnień: 1. (P) Przygotowanie paczki z instalacją serwera MySQL na koncie użytkownika (bez angażowania praw roota czy plików z katalogów ogólnosystemowych). Efektem powinna być paczka nr 1 opisana w celach projektu, 2. (OP) Opis i analiza już istniejących rozwiązań w ramach MySQL umożliwiających realizację klastrowości, zwiększenia niezawodności i wydajności serwera bazy danych, 3. (P) Praktyczne wprowadzenie i instrukcja użytkownika systemu kontroli wersji subversion na potrzeby realizowanego projektu, 4. (OP) Co powinno się wiedzieć o rozwiązaniu OpenSSI w kontekście realizowanego projektu, w szczególności: specyfika rozwiązania klastrowego, metody komunikacji międzyprocesowej i zarządzania procesami, pakiety i narzędzia, które mogą okazać się pomocne do realizacji projektu (http://www.ia.pw.edu.pl/~tkruk/openssi/), 5. (OP) Wprowadzenie do zagadnienia realizacji niezawodności i wydajności poprzez replikację zasobów. Wstęp do algorytmów realizacji wysokiej dostępności i niezawodności rozproszonych zasobów. Symbol OP oznacza opracowanie i ustala, że efektem końcowym ma być tylko dokument. Symbol P oznacza zagadnienie praktyczne i ustala, iż poza opracowanym dokumentem efektem końcowym powinna być odpowiednia realizacja praktyczna, np. gotowa do użycia paczka oprogramowania, założone repozytorium projektu z plikiem README i właściwymi prawami dostępu, itp. 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 koncepcji docelowego rozwiązania. W grupach sześcioosobowych to kierownik projektu decyduje, które z powyższych zagadnień ma być zrealizowane przez dwie osoby. Pierwszy krok milowy to zakończenie realizacji powyższych opracowań i przekazanie ich osobie prowadzącej laboratorium. FAZA 2 ------ Faza druga ma następujące zadania: - opracowanie dokumentacji koncepcji docelowego rozwiązania, - paczka numer 2 z celów projektu, - realizacja prototypu oferującego ograniczoną funkcjonalność. Zaliczenie tego etapu projektu, to przedstawienie dokumentacji z koncepcją rozwiązania docelowego, przedstawienie paczki numer 2 o cechach wydajnościowych i niezawodnościowych lepszych niż rozwiązania standardowe MySQL bez rozszerzeń klastrowych, oraz demonstracja w laboratorium 25 zainstalowanego prototypu, który oferuje ograniczoną funkcjonalność. Na tym etapie nie jest wymagana kompletna dokumentacja, a demostracja prototypu nie musi być automatyczna. 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 komentarz nr zajęć nr zajęć 07.03 0 0 organizacja grup projektowych 14.03 1 21.03 1 28.03 2* 04.04 2* 11.04 3 18.04 - - przerwa świąteczną 25.04 3 02.05 - - dzień wolny 09.05 4* 16.05 4* 23.05 5 30.05 5 06.06 6* 13.06 6* ostatni dzień semestru * - krok milowy, w tym terminie można uzyskać punktu za projekt. Obecność _wszystkich_ członków grupy w terminie kroku milowego jest _obowiązkowa_.