10 Podsumowanie

10.1 Realizacja przyjętych założeń projektowych
10.2 Sugerowane kierunki dalszych badań i implementacji

10.1 Realizacja przyjętych założeń projektowych

Poniżej przypominamy listę podstawowych założeń projektowych z p. 2.5 i omawiamy stopień ich realizacji w systemie V3.

• Węzły w systemie są równorzędne i wymienne. Autor zaprojektował mechanizmy synchronizacji w taki sposób, aby nie wymagały wyróżnienia żadnego z węzłów. Zgodne z tym postulatem jest rozproszenie konfiguracji w zbiór lokalnych kopii, jak również mechanizmy zsynchronizowanego dokonywania zmian na tych kopiach oparte na transakcjach i głosowaniu. Niektóre z zastosowanych algorytmów wymagają koordynacji przez wyróżniony element, tzw. prezydenta, ale element ten jest wybierany dynamicznie oraz dynamicznie zmieniany w przypadku awarii. Wszystkie rozwiązania, które autor stosował w warstwie administracyjnej są w pełni symetryczne. 
  Również w warstwie operacyjnej autor trzymał się zasady wymienności. Klient odwołuje się więc do zasobów wskazując serwer, nie węzeł. Węzły potrafią nawzajem przekierowywać żądania klientów, mogą również pośredniczyć w wykonywaniu żądań odebranych od klienta, kontaktując się między sobą w celu wymiany danych. Warstwa administracyjna dostarcza klientowi adresy węzłów wskazanego serwera, zaś klient, aby przekazać żądanie, kontaktuje się z którymkolwiek z nich. Serwer może optymalizować proces składania żądań przez klienta, wysyłając mu wskazówki pozwalające skuteczniej wybierać pomiędzy węzłami zależnie od parametrów żądania i rodzaju obiektu, którego ono dotyczy. Klient nie musi jednak znać tych wskazówek ani z nich korzystać.
• System stanowi (z punktu widzenia klientów systemu) jednolity zasób. Wolumeny są widoczne globalnie, w obrębie całego serwera. Zasoby serwera są wirtualne. Fizyczna lokalizacja ani parametry nie są znane klientowi, żądania dotyczące zasobów mogą być wysyłane do dowolnego z węzłów serwera, tak, jak to opisano w poprzednim punkcie.
• Zapewniamy ciągłość dostarczania usług klientom (tzn. minimalizujemy prawdopodobieństwo wystąpienia przerwy w udostępnianiu usług aplikacjom). Część kliencka systemu jest w stanie odtwarzać połączenia i ponawiać żądania, natomiast serwer próbuje zapewnić ciągłość sesji zapewniając niezmienność uchwytów i nie dopuszczając do usunięcia lub zmiany konfiguracji zasobów używanych przez klientów przed wystąpieniem awarii.
• Zapewniamy skalowalność pojemności i wydajności. W systemie V3 jest to możliwe dzięki umożliwieniu tworzenia wolumenów RAID0 zdefiniowanych na wielu węzłach.
• Wyposażamy system w zdolność do automatycznej (dynamicznej) rekonfiguracji/optymalizacji. System nie posiada w tej chwili żadnych wbudowanych automatycznych metod optymalizacji rozmieszczenia zasobów i wydajności. Aby to zapewnić, konieczna byłaby implementacja międzywęzłowej migracji danych oraz obsługa wolumenów typu RAID1 z równoważeniem obciążenia. System posiada w chwili obecnej jedynie proste mechanizmy reakcji na awarie (takie jak np. zablokowanie wolumenu).
• Administracja systemem jest globalna. Gwarantuje to konstrukcja warstwy administracyjnej.
• Staramy się jak najbardziej odciążać klienta kosztem serwera. Niektóre z proponowanych implementacji RAID0 zostały zaprojektowane właśnie w tym celu, m.in. Klient/R-RAID0 oraz Serwer-RAID0.
• Możliwe są złożone odwzorowania wolumenów na fizyczne nośniki. System nie zapewnia w chwili obecnej zbyt wielkiej elastyczności w tym zakresie, ale przyjęta architektura umożliwia bardzo łatwą implementację złożonych odwzorowań.
• Możliwa jest rekonfiguracja wolumenów na bieżąco. Umożliwieniu rekonfiguracji na bieżąco służą liczne metody opisane w rozdziale 8.
• Zapewniamy wysoką dostępność wolumenów (minimalizujemy łączny czas wyłączeń systemu). W obecnej wersji system nie udostępnia żadnych mechanizmów zapewniających redundancję danych. Wprawdzie redundancja danych nie jest jesynym sposobem zwiększania dostępności, ale bez zapewnienia możliwości odtworzenia informacji po awarii nie można mówić o wysokiej dostępności. 

10.2 Sugerowane kierunki dalszych badań i implementacji

Nie opisane zagadnienia projektowe:

• Algorytm łączenia dwóch wielowęzłowych serwerów, algorytm dzielenia serwera. Ograniczyliśmy się tu do zarządzania składem serwera przez dodawanie i usuwanie węzłów. Rozszerzenie algorytmu dodawania węzłów o możliwość łączenia serwerów prowadzi do interesujących problemów wynikających z faktu, że w nowym, powiększonym serwerze zmienia się pojęcie większości. Źle zaprojektowany algorytm może doprowadzić np. do utworzenia jednocześnie dwóch globalnych sekcji krytycznych (obejmujących grupy węzłów należące do obu łączonych serwerów) blokujących się wzajemnie.
• Dynamiczne (dokonywane na bieżąco) zmiany konfiguracji wolumenów typu Klient/Serwer-RAID0.
• Szczegóły scenariusza realizacji żądań odczytu i zapisu związane z awariami (zarówno w opisie protokołu, jak i scenariusza obiegu żądań między wątkami serwera pominięto kwestię obsługi awarii).
• Scenariusze awaryjne w implementacji wolumenów RAID1. Autor jedynie symbolicznie wspomniał o równoważeniu obciążenia w wolumenach typu RAID1, pominął w ogóle kwestię implementacji scenariuszy awaryjnych (np. zapisywania zmian do dziennika w trakcie, gdy istnieje tylko jedna kopia, później uzupełniania drugiej kopii zmianami dokonanymi w międzyczasie, gdy druga kopia zostanie ponownie dołączona do systemu). Nie opisano również innych ważnych organizacji RAID, w tym organizacji RAID5. 

Nie przeprowadzone testy:

• Test obciążenia klienta systemu dla różnych rodzajów implementacji RAID. Szczególnie ważnym testem byłoby zbadanie obciążenia klienta w trakcie operacji odczytu dla Serwer-RAID0 i Klient-RAID0, pozwalające na ostateczne porównanie obu tych implementacji. Autor zaproponował dwie metody, wykorzystujące liczniki wydajności i aplikację testową, z których pierwszej nie udało się zrealizować z powodów technicznych (szczegółowe powody podano w przypisach w p. 7.5.1.1), natomiast druga dawała wyniki tak niestabilne i zależne od tak wielu czynników zewnętrznych, że w praktyce bezużyteczne.
• Autor, w czasie przeprowadzania testów, dysponował bardzo ograniczonymi zasobami sprzętowymi i nie mógł przeprowadzić testów RAID0 dla wolumenów zbudowanych na więcej niż dwóch węzłach. Można spodziewać się, że rozszerzenie testów na większą liczbę węzłów pozwoli zaobserwować dodatkowe różnice pomiędzy testowanymi implementacjami RAID0.
• W teście czasu losowego odczytu ze 100% skutecznością schowka, wykonanym dla różnych implementacji RAID0, okazało się, że dla dużych żądań implementacja Serwer-RAID0 jest o około połowę wolniejsza niż implementacja Klient-RAID0. Autor nie znalazł dotychczas przekonującego wyjaśnienia tego zjawiska. Zbadanie tego faktu i zidentyfikowanie przyczyny tych różnic mogłoby polegać na rozbiciu całego procesu wykonania żądań na fazy i pomiarze czasów wykonania poszczególnych faz: odebrania żądania, operacji dyskowych, przesyłu danych itd.
• W teście losowego odczytu wolumenu typu Klient-RAID0 ze 100% skutecznością schowka na wykresie daje się zauważyć wyraźne garby, tzn. pogorszenie się wydajności dla rozmiarów żądań bliskich pewnej ustalonej wartości, zbliżonej do rozmiaru pasemka. Autorowi nie udało się ustalić, co jest przyczyną tego zjawiska.
• Bardzo interesującym testem mógłby być pomiar wariancji czasu wykonania żądań dla różnych rodzajów wolumenów RAID0. Wariancja wyznacza wielkość roztrzęsienia, bardzo istotną we wszelkiego rodzaju zastosowaniach multimedialnych.
• Różnic między poszczególnymi implementacjami RAID0 można również doszukiwać się, nieco ogólniej, w rozkładach prawdopodobieństwa czasu odczytu.
• Autor nie wykonał testów operacji zapisu, choć operacja taka w obu wersjach (zarówno dla wolumenów typu Klient-RAID0, jak i Serwer-RAID0) została zaimplementowana. Przyczyną tego była ograniczona ilość czasu przeznaczonego na zakończenie pracy magisterskiej. Wszystkie testy wymagały dosyć długich symulacji (koniecznych, aby uzyskać stabilność i dokładność wyników, szczególnie istotną z uwagi na bardzo niewielkie różnice wydajności pomiędzy oboma implementacjami RAID0 i wynikającą stąd trudność wnioskowania o nich). Jednocześnie przestrzeń parametrów testowych była dosyć duża (rozmiar żądania przyjmował 12 różnych wartości, od 512B do 1MB, liczba jednoczesnych żądań przyjmowała 9 różnych wartości, od 1 do 512, rozmiar pasemka przyjmował do 5 różnych wartości, od 8KB do 128KB). W rezultacie sporządzenie każdego wykresu wymagało kilkudziesięciu osobnych, często długotrwałych symulacji (i, co gorsza, często ponawianych z uwagi na niedeterministycznie pojawiające się przy dużych obciążeniach błędy komunikacyjne, wynikające prawdopodobnie z błędów w implementacji sterowników Giganet lub biblioteki komunikacyjnej ACL – patrz przypisy w p. 7.5.3.1).