Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Distributed systems / Fault tolerance 1 Systemy Rozproszone Tolerancja Błędów 1.Podstawowe pojęcia - terminologia 2.Proces odporności Grupy i brak maskowania.

Podobne prezentacje


Prezentacja na temat: "Distributed systems / Fault tolerance 1 Systemy Rozproszone Tolerancja Błędów 1.Podstawowe pojęcia - terminologia 2.Proces odporności Grupy i brak maskowania."— Zapis prezentacji:

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

2 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 4 Modele Awarii Inne typy awarii Obserwacje: crash failures są najłagodniejsze, niepożądane błędy są najgorsze. Rodzaj awariiOpis Crash failureZatrzymuje 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łędySerwer może powodować niepożądane błędy w dowolnym czasie

5 Distributed systems / Fault tolerance 5 Failure Masking by Redundancy Potrójne modułowe zwolnienia (TMR)

6 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 9 Grupy i maskowanie awarii (3) Bizantyjski problem generałów dla 3 lojalnych generałów i 1 zdrajcy. a)Generałowie ogłaszają siły swojego oddziału (w jednostkach 1 kilożołnierz). b)Wektory ogólne montuje na podstawie (a) c)Wektory każdy otrzymuje w kroku 3.

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

11 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 12 Niezawodność (Realiable) RPC (1) Co może pójść źle ? 1.Klient nie może odnaleźć serwera 2.Utracona odpowiedź klienta 3.Awaria serwera 4.Utracona odpowiedź serwera 5.Awaria klienta [1:] Stosunkowo proste – po prostu zgłoś się do klienta [2:] Wystarczy wysłać wiadomość.

13 Distributed systems / Fault tolerance 13 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 21 Wirtualna Synchronizacja (1) Logiczna organizacja systemu systrybucji rozróżnienie pomiędzy otrzymaniem wiadomości,a dostarczeniem wiadomości

22 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 26 Dwu-fazowy Commit (2) a.Stan ostateczny maszyny dla koordynatora w 2PC b.Stan ostateczny maszyny dla uczestnika

27 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 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 QAkcja P COMMITTworzy przejście do COMMIT ABORTTworzy przejście do ABORT INITTworzy przejście do ABORT READYKontaktuje się z innym uczestnikiem Rezultat: jeśli wszyscy uczestnicy są w stanie gotowości, protokół blokuje. Widocznie, koordynator jest wadliwy.

29 Distributed systems / Fault tolerance 29 Dwu-fazowy Commit (5) Zarys działań podjętych przez koordynatora w dwufazowym protokole zatwierdzania 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; }

30 Distributed systems / Fault tolerance 30 Dwu-fazowy Commit (6) Kroki podejmowane przez uczestników w procesie 2PC. 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; }

31 Distributed systems / Fault tolerance 31 Dwu-fazowy Commit (7) Działania podjęte do obsługi przychodzących żądań decyzji 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 */

32 Distributed systems / Fault tolerance 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. 2. 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 Distributed systems / Fault tolerance 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 Distributed systems / Fault tolerance 34 Trój-fazowy Commit (3) a.Skończony stan maszyny dla koordynatora 3PC b. Skończony stan maszyny dla uczestnika


Pobierz ppt "Distributed systems / Fault tolerance 1 Systemy Rozproszone Tolerancja Błędów 1.Podstawowe pojęcia - terminologia 2.Proces odporności Grupy i brak maskowania."

Podobne prezentacje


Reklamy Google