Systemy Rozproszone Tolerancja Błędów

Prezentacja na temat: "Systemy Rozproszone Tolerancja Błędów"— Zapis prezentacji:

1 Systemy Rozproszone Tolerancja Błędów
Podstawowe pojęcia - terminologia Proces odporności Grupy i brak maskowania Niezawodna komunikacja Niezawodna komunikacja klient-serwer Niezawodna grupowa komunikacja Distributed commit dwufazowe (2PC) trójfazowe (3PC)

2 Rzetelność Podstawowe: Komponent świadczy usługi dla klientów. Aby świadczyć usługi, komponent może potrzebowć usług innych komponentów => komponent może zależeć od innych komponentów. Dokładniej: Komponent C zależy od C* jeżeli poprawność zachowania C zależy od poprawności zachowania C*. Niektóre właściwości niezawodności: Dostępność Gotowość do użycia Niezawodność Ciągłość świadczenia usług Bezpieczeństwo Bardzo niskie prawdopodobieństwo katastrof Maintainability Jak łatwo można naprawić uszkodzony system Uwagi: Dla systemów rozproszonych, komponentami mogą być zarówno procesy i kanały.

3 Terminologia Niepowodzenie: Kiedy komponent nie jest living up do jego specyfikacji, następuje awaria Błąd: Część stanu komponentu, które mogą doprowadzić do awarii Awaria: Przyczyna błędu Zapobieganie awarii: zapobieganie wystąpienia awarii Odporność na awarie: budowanie komponentów w taki sposób aby mogły one sprostać specyfikacji w obecności awarii (tzn., maskować obecność awarii) Usuwanie awarii: zmniejszenie występowania, liczby, wagi usterek Prognozowanie awarii: oszacowanie obecnej liczby, występowania w przyszłości i konsekwencji awarii.

4 Modele Awarii Inne typy awarii
Rodzaj awarii Opis Crash failure Zatrzymuje serwer, ale działa poprawnie, dopóki nie zatrzyma Awarie pominięcia Pominięcie odebrania Pomienięcie wysłania Serwer nie odpowiada na żadania przychodzące Serwer nie otrzymuje wiadomości przychodzących Serwer nie wysyła wiadomości Brak synchronizacji Odpowiedzi serwera znajduje się poza określonym przedziałem czasu Awaria odpowiedzi Brak wartości Awaria stanu przejścia Odpowiedź serwera jest nieprawidłowa Wartość odpowiedzi jest niepoprawna Serwer odbiega od prawidłowego przepływ kontroli Niepożądane błędy Serwer może powodować niepożądane błędy w dowolnym czasie Inne typy awarii Obserwacje: crash failures są najłagodniejsze, niepożądane błędy są najgorsze.

5 Failure Masking by Redundancy
Potrójne modułowe zwolnienia (TMR)

6 Proces Odporności Podstawowy problem: Zabezpiecz się przed błędnymi procesami przez replikowanie i dystrybucję obliczeń w grupy. Płaskie grupy: Dobra odporność na awarie kiedy wymiana informacji występuje natychmiast dla wszystkich członków grupy; jednakże, mogą wprowadzać bardziej ogólne, jak kontrola jest całkowicie rozproszona (trudne do implementacji). Hierarchiczne grupy: Cała komunikacja za pośrednictwem jednego koordynatora => niezbyt odporna na awarie i skalowalna, ale stosunkowo prosta do implementacji.

7 Grupy i maskowanie awarii (1)
Terminologia: kiedy grupa może maskować każde k jednoczesnych błędów członków,to mówi się, że jest to k-błędowa tolerancja (k nazywana jest stopniem lub tolerancją błędu). Problem: jak duża powinna być k-błędowa tolerancja grupy? Assume crash/performance failure semantics => a total of k+1 members are needed to survive k member failures. Assume arbitrary failure semantics, and group output defined by voting => a total of 2k+1 members are needed to survive k member failures. Założenie: wszyscy użytkownicy są idenstyczni, i procesy przetwarzają wejścia w tej samej kolejności=> Tylko wtedy jesteśmy pewni, że robią dokładnie to samo.

8 Grupy i maskowanie awarii (2)
Założenie: Członkowie grupy nie są identyczni, tzn., mamy rozproszone obliczenia. Problem: Członkowie grupy niewadliwych powinni osiągnąć porozumienie dla tej samej wartości. Obserwacje: Przyjmując semantykę awarii, potrzebujemy 3k + 1 członków grupy do przetrwania ataku k członków awarii. Uwagi: Jest to także znane jako Bizantyjska awaria. Istota: Staramy się dotrzeć większością głosów w gronie zwolenników, w obecności k zdrajców =>potrzebujemy 2k+1 lojalnych.

9 Grupy i maskowanie awarii (3)
Bizantyjski problem generałów dla 3 lojalnych generałów i 1 zdrajcy. Generałowie ogłaszają siły swojego oddziału (w jednostkach 1 kilożołnierz). Wektory ogólne montuje na podstawie (a) Wektory każdy otrzymuje w kroku 3.

10 Grupy i maskowanie awarii (3)
Tak samo jak poprzednio, tylko teraz 2 lojalnych generałów i 1 zdrajca

11 Niezawodna komunikacja
Jak dotąd: Skoncentrowany na odporności procesu (za pomocą grup procesów). Co o wiarygodnych kanałach komunikacji? Wykrywanie błędów: Framing pakietów w celu umożliwienia wykrywania błędów bitowych. Użycie numerowania ramek do wykrywania utraconych pakietów Korekta błędów: Dodaj tyle zwolnień żeby uszkodzone pakiety mogły być automatycznie korygowane. Poproś o retransmisję utraconych, lub ostatnich N pakietów. Obserwacje: Większość z tej pracy bierze na siebie komunikacja punkt-punkt

12 Niezawodność (Realiable) RPC (1)
Co może pójść źle ? Klient nie może odnaleźć serwera Utracona odpowiedź klienta Awaria serwera Utracona odpowiedź serwera Awaria klienta [1:] Stosunkowo proste – po prostu zgłoś się do klienta [2:] Wystarczy wysłać wiadomość.

13 Serwer w komunikacji klient-serwer
Niezawodność RPC (2) [3:] Serwer zawiesza się kiedy nie wiesz co miał do zrobienia: Problem: Musimy zdecydować czego oczekujemy od serwera Co-najmniej-raz-semantics: Serwer gwarantuje, że przeprowadzi operację co najmniej raz, nie ważne co się stanie. Co-najwyżej-raz-semantics: Serwer gwarantuje, że przeprowadzi operację co najwyżej raz. Serwer w komunikacji klient-serwer (a) normalny przypadek (b) awaria po wykonaniu (c) awaria przez wykonaniem

14 Niezawodność RPC (3) [4:] Detektowanie zagubionych odpowiedzi może być trudne, ponieważ może również wystąpić awaria serwera i nie wiadomo, czy serwer przeprowadził operację. Rozwiązanie: Żadne, chyba, że można próbować zrobić swoje opracje idempotent: powtarzane bez żadnej szkody jeśli zdarzyło się przeprowadzić wcześniej. [5:] Problem: Serwer wykonuje pracę i dzierżawi zasoby dla niczego (for nothing) (nazywa pracę sierocymi obliczeniami). Sierota jest zabijana (lub wycofywana) przez klienta, kiedy się restartuje Nadawanie numeru* nowej epoce podczas odzyskiwania => serwer zabija sierotę Wymaga obliczeń do skompletowania w jednostce czasu T. Te stare są prosto osuwane Pytanie: Co z wycofywaniem? *An epoch number is the total number of operations that originated at a particular replica.

15 Niezawodność Multicasting (1)
Model podstawowy: Mamy kanał multicast c z dwoma (ewentualnie nakładającymi się) grupami: grupa wysyłających SND(c) z procesów wysyłających wiadomości do kanału c Grupa odbierających RCV(c) z procesów, które mogą odbierać wiadomości z kanału c Prosta niezawodność: jeżeli proces P  RCV(c) w czasie wiadomości m był dostarczony do c i P nie opuszcza RCV(c), m powinna być dostarczona P Atomowy multicast: Jak możemy zapewnić, że wiadomość m wysłana do kanału c jest dostarczona do procesu P  RCV(c) tylko jeżeli m jest dostarczona do wszystkich użytkowników z RCV(c)

16 Niezawdny Multicasting (2)
Obserwacje: Jeśli uda nam się wbić do sieci lokalnej, niezawodny multicasting jest "prosty". Zasady: Niech nadawcy log messages wysyłają do kanału c: jeśli P wysłał wiadomość m, m jest przechowywana w buforze historii Każdy odbiorca potwierdza odbiór m, albo prosi o retransmisję na P kiedy zauważył zagubioną wiadomość Wysyłający P osuwa m z buforu historii kiedy wszyscy potwierdzą odbiór Pytania: Dlaczego nie na taką skalę ? Podstawowy algorytm nie skaluje: jeśli RCV(c) jest duże, P powinien być zapchany ze sprzężeniem zwrotnym (ACKs and NACKs) Wysyłający P musi znać wszystkich członków RCV(c)

17 Podstawowy schemat Wiarygodnego-Multicastingu
Proste rozwiązanie do rzetelnego multicastingu kiedy wszyscy użytkownicy są znani i zakładamy niezawodność a) Transmisji wiadomości b) Sprawozdań zwrotnych

18 Skalowalność RM: Tłumienie feedback
Podstawowa idea: Niech proces P tłumi swoje własne feedback kiedy zauwazy, że inny proces Q właśnie prosi o retransmisję Założenia: Wszyscy odbiorcy nasłuchują wspólny kanał feedback, do którego feedbak sa wysyłane. Proces P układa swoje własne feedback w sposób przypadkowy i chamuje to podczas obserwacji kolejnej feedback message Pytania: Dlaczego przypadkowy harmonogram jest taki ważny? Harmonogram przypadkowy jest konieczny do zapewnienia, że tylko jedna feedback message jest ewentualnie.

19 Skoalowalność RM: Rozwiązanie Hierarchiczne
Proste rozwiązanie: Zbuduj hierarchiczny feedback channel, w którym wszystkie wysłane wiadomości są wysyłane tylko do roota. Pośredni węzeł agreguje feedback messages zanim zostaną przekazane dalej Pytanie: Co jest głównym problemem w tym rozwiązaniu? (Dynamiczne) konstrułowanie hierarchicznego kanału feedback jest podstawowym problemem. Obserwacja: Pośrednie węzły moga być łatwo użyte dla celów retransmisji.

20 Atomiczny Multicast Idea: Formułować wiarygodne multicasting w obecności awarii w odniesieniu do grup procesów i zmian przynależności do grupy: Gwarancja: Wiadomość jest dostarczona tylko do nie wadliwego członka aktualnej grupy. Wszyscy użytkownicy powinni uzgodnić aktualna grupę członków. Słowo kluczowe: Praktycznie synchroniczny multicast

21 Wirtualna Synchronizacja (1)
Logiczna organizacja systemu systrybucji rozróżnienie pomiędzy otrzymaniem wiadomości ,a dostarczeniem wiadomości

22 Wirtualna Synchronizacja (2)
Istota: Rozważamy widoki V  RCV(c)  SND(c) 1. Procesy są dodawane lub usuwane z widoku V poprzez zmianę widoku w V*; zmiana widoku jest wykonywana lokalnie przez każdy P  V  V* 2. Dla każdego spójnego stanu, znajduje się niepowtarzalny widok na który zgadzaja się wszyscy jego uczestnicy. Uwaga: Oznacza to, że nie wszystkie procesy błędne zobaczą wszystkie zmiany widoku w tej samej kolejności 3. Jeżeli wiadomość m została wysłana do V przed zmianą widoku vc do V*, wtedy każdy P  V otrzymuje m, lub nieprocesy P  V otrzymują m.Uwaga: wszyscy błędni urzytkownicy w tym samym widoku zobaczą ten sam zestaw multicast messages. Wiadomość wysłana do widoku V może być dostarczona tylko do procesu z V, i jest odrzucana przez kolejne odsłony. Niezawodny multicast algorytm spełniający 1. – 3. nazywany jest virtually synchronous.

23 Wirtualna Synchronizacja (3)
Wysyłający do widoku V potrzebuje być członkiem V, Jeśli wysyłający S  V ulega awarii, jego multicast message m jest kasowana , S jest usuwana z V; m nigdy nie będzie dostarczona po punkcie, że S  V Uwaga: Wiadomości z S mogą nadal być dostarczane do wszystkich, lub brak (nonfaulty) procesów w V przed zgoda wszystkich na nowy widok do którego S nie należy Jeśli odbiorca P zawodzi, wiadomość m może być utracona ale może być odzyskana jeśli wiemy dokładnie kto był odbiorcą w V. Alternatywnie, możemy zdecydować na dostarczenie m do członków w V-{P} Obserwacja: Zachowanie wirtualnej synchchronizacji może być widoczne niezależnie od kolejności dostarczenia wiadomości. Jedynym problemem jest to, że wiadomości są dostarczane do uzgodnionej grupy odbiorców.

24 Rozproszony Commit Dwu-fazowy commit (2PC) Trój-fazowy commit (3PC)
Zasadnicze znaczenie: Biorąc pod uwagę obliczenia rozproszone grupy procesów, w jaki sposób możemy zapewnić, że wszystkie procesy dotrwają do finałowego rezultatu, lub żaden z nich nie dotrwa (niepodzielność)?

25 Dwu-fazowy Commit (1) Model: Klient, który zainicjował obliczeń działa jako koordynator; procesy konieczne do commit to uczestnicy Faza 1a: Koordynator wysyła VOTE_REQUEST do uczestników (nazywane również pre-write) Faza 1b: Kiedy uczestnik odbierze VOTE_REQUEST zwraca YES lub NO do koordynatora. Jeśli wysłał NO,anuluje lokalne obliczenia Faza 2a: Koordynator zbiera wszystkie głosy; jeśli wszystkie są YES, wysyła COMMIT do wszystkich uczestników, w innym przypadku wysyła ABORT Faza 2b: Wszyscy uczestnicy czekają na COMMIT lub ABORT i zachowują się odpowiednio.

26 Dwu-fazowy Commit (2) Stan ostateczny maszyny dla koordynatora w 2PC
Stan ostateczny maszyny dla uczestnika

27 2PC – Słaby uczestnik (1) Obserwacje: Uczestnik rozważa błąd w jednym z tych stanów, a następnie odzyskanie tego stanu: Stan początlkowy: Nie ma problemów, jako uczestnik nieświadomym protokołu. Stan gotowości: Uczestnik czeka na either commit lub anulowanie .Po odzyskaniu, uczestnik potrzebuje znać, które stany przejść powinny to robić  log koordynatora decyzji Stan anulowania: Samo wejście na stan na anulowania,t.j., usówanie wyników pracy Stan zobowiązania: kopiowanie do pamięci roboczej. Obserwacje: When distributed commit is required, having participants use temporary workspaces to keep their results allows for simple recovery in the presence of failures.

28 2PC – Słaby uczestnik (2) Alternatywa: Kiedy odzyskanie jest potrzebne do stanu gotowości, sprawdź co robi drugi uczestnik. To rozwiązanie pozwala uniknąć konieczności logowania decyzji koordynatora. Załóżmy odzyskanie kontaktów uczestnika P innego uczestnika Q: Stan Q Akcja P COMMIT Tworzy przejście do COMMIT ABORT Tworzy przejście do ABORT INIT READY Kontaktuje się z innym uczestnikiem Rezultat: jeśli wszyscy uczestnicy są w stanie gotowości, protokół blokuje. Widocznie, koordynator jest wadliwy.

29 Dwu-fazowy Commit (5) Akcje koordynatora: while START _2PC to local log; multicast VOTE_REQUEST to all participants; while not all votes have been collected { wait for any incoming vote; if timeout { while GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants; exit; } record vote; } if all participants sent VOTE_COMMIT and coordinator votes COMMIT{ write GLOBAL_COMMIT to local log; multicast GLOBAL_COMMIT to all participants; } else { write GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants; } Zarys działań podjętych przez koordynatora w dwufazowym protokole zatwierdzania

30 Kroki podejmowane przez uczestników w procesie 2PC.
Dwu-fazowy Commit (6) Działania podejmowane przez użytkowników: write INIT to local log; wait for VOTE_REQUEST from coordinator; if timeout { write VOTE_ABORT to local log; exit; } if participant votes COMMIT { write VOTE_COMMIT to local log; send VOTE_COMMIT to coordinator; wait for DECISION from coordinator; if timeout { multicast DECISION_REQUEST to other participants; wait until DECISION is received; /* remain blocked */ write DECISION to local log; } if DECISION == GLOBAL_COMMIT write GLOBAL_COMMIT to local log; else if DECISION == GLOBAL_ABORT write GLOBAL_ABORT to local log; } else { write VOTE_ABORT to local log; send VOTE ABORT to coordinator; } Kroki podejmowane przez uczestników w procesie 2PC.

31 Działania podjęte do obsługi przychodzących żądań decyzji
Dwu-fazowy Commit (7) działania dotyczące rozpatrywania wniosków decyzji: /* executed by separate thread */ while true { wait until any incoming DECISION_REQUEST is received; /* remain blocked */ read most recently recorded STATE from the local log; if STATE == GLOBAL_COMMIT send GLOBAL_COMMIT to requesting participant; else if STATE == INIT or STATE == GLOBAL_ABORT send GLOBAL_ABORT to requesting participant; else skip; /* participant remains blocked */ Działania podjęte do obsługi przychodzących żądań decyzji

32 Trój-fazowy Commit (1) Problem: z 2PC kiedy koordynator ulega awarii, uczestnicy mogą nie być w stanie do podjęcia ostatecznej decyzji i mogą potrzebować pozostania w stanie zablokowanym, dopóki koordynator nie naprawi się. Rozwiązanie: trzy-fazy protokołu commit (3PC). Stany koordynatora i każdego uczestnika spełniają następujące warunki: 1. Nie ma żadnego stanu, z którego można dokonać bezpośredniego przejścia do stanu COMMIT lub ABORT. Nie ma żadnego stanu, w którym nie jest możliwe podjęcie ostatecznej decyzji, i od którego przejście do stanu COMMIT może być wykonane. Uwagi: często nie są stosowane w praktyce jak warunki, na jakich 2PC są rzadko spotykane.

33 Trój-fazowy Commit (2) Faza 1a: Koordynator wysyła VOTE_REQUEST dla uczestników Faza 1b: Kiedy uczestnicy otrzymują VOTE_REQUEST zwracają albo YES albo NO do koordynatora. Jeśli wysłali NO, przerywa to lokalne obliczenia Faza 2a: Koordynator zbiera wszystkie głosy; jeśli wszystkie są YES,wysyła PREPARE do wszystkich uczestników, w innym przypatku wysyła ABORT, i zatrzymuje się. Faza 2b: Każdy uczestnik czeka na PREPARE, lub czeka na ABORT po czym się zatrzymuje Faza 3a: (Przygotowanie do commit) Koordynator czeka dopóki wszyscy uczestnicy mają ACKed otrzymania wiadomości PREPARE i wtedy wysyła COMMIT do wszystkich Faza 3b: (Przygotowanie di to commit) Uczestnicy czekają na COMMIT

34 Trój-fazowy Commit (3) Skończony stan maszyny dla koordynatora 3PC
b. Skończony stan maszyny dla uczestnika