Sisteme distribuite teorie 5. Semantica esecurilor în RPC. Comunicatie în grup

Sisteme distribuite teorie 5. Semantica esecurilor în RPC. Comunicatie în grup

Esecuri în comunicare pierderea de mesaje căderea unui proces 1. Pierderea mesajului cerere 2. Pirederea mejajului răspuns 3. Căderea serverului 4. Căderea clientului

Tipuri de esecuri (1/2) 1. Pierderea unui mesaj cerere: Clientul trebuie să retransmită mesajul după un timeout Problemă: clientul nu poate diferenția diferitele tipuri de eșecuri Ex: dacă mesajul rezultat este cel care a fost pierdut, o retransmitere a mesajului cerere poate rezulta în executarea de două ori a procedurii la distanță Ex: proceduri care necesită mult timp vs. selecția unui timeout scurt 2. Pierderea unui mesaj răspuns: Clientul retransmite cererea după un timeout. Problemă: daca serverul nu recunoaște ce s-a întâmplat, execută procedura din nou

Tipuri de esecuri (2/2) 3. Căderea serverului: Dacă serverul cade datorită unei erori, trebuie determinat dacă execuția parțială a procedurii a produs deja efecte în stare. Ex. Dacă baza de date a fost modificată în timpul procedurii, problema recuperării și a continuării din momentul eșecului nu este trivială 4. Căderea clientului: Un proces client care cade în timpul execuției unui RPC este referit ca o invocare orfană Problemă: ce face serverul cu rezultatele și unde trebuie să le trimită

Semantica esecurilor Aplicații diferite pot avea cerințe diferite în ceea ce privește calitatea serviciului (QoS) în termeni de detecție a eșecurilor și recuperare Semantica eșecului Operație fără eșec Pierdere mesaj Cădere server Maybe (Poate) Execuție: 1 Rezultat: 1 Execuție: 0/1 Rezultat: 0 Execuție: 0/1 Rezultat: 0 At-least-once (Cel puțin odată) Execuție: 1 Rezultat: 1 Execuție: >=1 Rezultat: >=1 Execuție: >=0 Rezultat: >=0 At-most-once (Cel mult odată) Execuție: 1 Rezultat: 1 Execuție: 1 Rezultat: 1 Execuție: 0/1 Rezultat: 0 Exactly once (Exact odată) Execuție: 1 Rezultat: 1 Execuție: 1 Rezultat: 1 Execuție: 1 Rezultat: 1

Semantica Maybe Referită ca și efortul cel mai bun. Nu oferă mecanisme pentru tratarea eșecurilor Ex. RPC poate fi executat o dată sau niciodată la partea server Clientul recepționează cel mult un rezultat Nu oferă garanții Atîta timp cît nu apar eșecuri, RPC este adresat adecvat

Semantica At-least-once RPC va fi executat la partea server cel puțin o data în cazul pierderii de mesaje După un timeout, clientul repetă RPC pînă cînd recepționează un răspuns de la server O procedură poate fi efectuată de mai multe ori la server E posibil ca un client să recepționeze răspunsuri multiple datorate execuției repetate Nu oferă o confirmare dacă serverul cade Adecvată pentru proceduri idempotente care nu cauzează schimbarea stării la server și pot fi executate mai mult decît o dată fără a produce pagube

Semantica At-most-once Procedura va fi executată cel mult o dată - atît în cazul pierderii de mesaje cît și a căderii serverului Dacă serverul nu cade, sunt garantate exact o execuție și exact un rezultat Necesită un protocol complex de gestiune a mesajelor și numerotare

Semantica Exactly once Cazul ideal, nu este ușor de atins Invocarea de către un client va rezulta într-o singură execuție la partea server și va fi furnizat un singur rezultat Dezirabilă pentru tranzacții bancare Cazul cel mai simplu: operații idempotente Cazul unei simple informări care doar citește data de la serverul de la distanță fără a schimba starea serverului Execuția repetată și numeroase mesaje rezultate nu sunt o problemă

Comunicarea în grup RPC: doua părți, clientul și serverul Contra-exemplu: un grup de servere de fișiere care cooperează pentru a oferi un singur sistem de fișiere tolerant la eșecuri Clientul expediază un mesaj la toate serverele pentru a se asigura că cererea este onorată chiar dacă unul dintre acestea cedează RPC nu poate trata comunicarea de la un expeditor la mai mulți receptori (în afara cazului în care efectuează RPC-uri separate cu fiecare dintre ele)

Grup = colectie de procese care acționează împreună într-o modalitate specifică sistemului sau utilizatorului. Scop: permite proceselor să trateze colecții de procese ca o singură abstractizare => un proces poate trimite un mesaj la un grup de servere fără a cunoaște cîte sunt și unde sunt (caracteristici ce se pot schimba de la un apel la altul) Proprietate cheie: cînd un mesaj este expediat la un grup specific, toți membrii grupului îl recepționează forma de comunicare unul-la mai mulți în contrast cu comunicarea punct-la-punct Dinamicitate (analogie cu organizarea socială!) Grupuri noi pot fi create, grupuri vechi pot fi distruse Un proces se poate alătura unui grup sau îl poate părăsi Un proces poate fi membru la mai multe grupuri în același timp => Sunt necesare mecanisme pentru a administra grupurile și apartenența la grupuri

Implementări ale comunicării în grup 1. Tehnica multi-casting (difuzare multiplă) Crearea unui adrese speciale de rețea (de exemplu, indicare prin setarea biților celor mai semnificativi pe 1), la care ascultă mașini multiple Cînd este expediat un pachet la una dintre aceste adrese, este automat livrat la toate mașinile care ascultă la respectiva adresă Implementarea grupurilor utilizând multi-casting este imediată: asignarea fiecărui grup la adrese multi-cast diferite 2. Tehnica broad-casting (difuzare largă) Pachelete care contin o anumită adresă sunt livrate la toate mașinile Poate fi utilizată pentru a implementa grupurile, dar este mai puțin eficientă: Fiecare mașină primește fiecare difuzare si software-ul său trebuie să verifice dacă pachetul îi este adresat Dacă nu, pachetul este ignorat, dar un anumit timp este pierdut pentru tratarea întreruperii Necesită doar un pachet care ajunge la toți membrii grupului

Implementări ale comunicării în grup 1. Multi-casting 2. Broad-casting, dacă multicasting nu este permis 3. Uni-casting (transmitere punct-la-punct), daca mc sau bc nu sunt permise Expedierea unui mesaj de la un singur expeditor la un singur destinatar Expeditorul transmite pachete separate pentru fiecare membru din grup Pentru un grup cu n membri, sunt necesare n pachete, spre deosebire de un pachet cand este utilizat mc sau bc Deși mai putin eficientă, aceasta implementare este funcțională dacă grupurile sunt mici

Designul comunicărilor în grup Drept cazuri de transmitere de mesaje: Cu buffer vs. fără buffer Cu blocare vs. fără blocare Etc. Opțiuni adiționale Grupuri închise vs. Grupuri deschise Grupuri de semeni vs. Grupuri ierarhice Alte probleme Apartenența la grup Adresarea grupului Primitivele Send și Receive Atomicitate Ordonarea mesajelor Grupuri cu suprapunere Scalabilitate

Grupuri închise vs Grupuri deschise Grupuri închise: În care numai membrii grupului pot trimite mesaje la grup Cei din exterior nu pot trimite mesaje la grup ca tot, deși pot trimite mesaje la membrii individuali Exemplu: O colecție de procese care lucrează împreună pentru un joc de șah pot forma un grup închis; au propriul scop și nu interacționeză cu lumea înconjurătoare Grupuri deschise: fiecare proces din sistem poate trimite la oricare grup Exemplu: grup de servere replicate; este important ca procesele care nu sunt membre (clienții) să poată expedia mesaje la grup

Grupuri de semeni vs. Grupuri ierarhice Grupuri de semeni (Peer Groups) Toate procesele sunt egale. Nici un proces nu este șef și toate deciziile sunt luate în colectiv Grupul este simetric și nu are un punct singular de eșec Daca procesele eșuează, grupul devine mai mic, dar continuă Dezavantaj: procesul de decizie este complicat pentru a decide orice, este necesar un vot ceea ce duce la întârzieri și surplus în timp Grupuri ierarhice Un proces este corodonator și celelalte sunt lucrători Cînd este generată o cerere de lucru fie de către un client extern sau de unul dintre lucrători, ea este trimisă la coordonator care decide care lucrător este cel mai adecvat să efectueze lucrul și i-l expediază Pierderea coordonatorului duce întregul grup la o oprire, dar atîta timp cît funcționează, deciziile se iau fără a deranja pe alții Ex: un grup ierarhic este indicat pentru un program de șah: Coordonatorul consideră situația curentă, generează toate mișcările posibile din aceasta și le trimite lucrătorilor pentru evaluare Ca urmare a evaluării noile situații sunt expediate la coordonator pentru a le evalua Cînd un lucrător nu este ocupat, cere coordonatorului de lucru Coordonatorul controlează strategia de căutare

Apartenenta la grup Anumite metode sunt necesare pentru a crea și șterge grupuri pentru a permite proceselor să se alăture sau să părăsească grupuri Abordări: 1. Există un server de grup la care sunt transmise toate cererile 2. Administrează apartenența la grup într-o modalitate distribuită Într-un grup deschis, un outsider poate trimite un mesaj la toți membrii grupului pentru a-și anunța prezența Într-un grup închis, este necesar ceva similar Pentru a părăsi grupul, un membru trimite mesaj către fiecare membru

Adresarea grupului abordări 1. Fiecare grup are o adresă unică, precum o adresă de proces Permis multicast-ul: adresa de grup poate fi asociată cu o adresă multi-cast Permis broadcast-ul: mesajul poate fi difuzat Numai unicast-ul est permis: necesar o listă de mașini care au procese ce aparțin grupului. 2. Cere expeditorului să ofere o listă explicită a tuturor destinațiilor 3. Fiecare mesaj este expediat la membrii grupului prin una din metodele descrise anterior, dar în plus: Fiecare mesaj conține un predicat (expresie Booleană) de evaluat Predicatul poate include numărul mașinii destinatare, variabilele sale locale și alți factori Daca predicatul este evaluat prin TRUE, mesajul este acceptat Daca este evaluat prin FALSE, mesajul este ignorat Exemplu: expediază un mesaj numai la acele masini care au cel puțin 4M de memorie liberă și sunt dispuse să preia noul proces

Primitivele Send si Receive 1. Unește cele două forme de comunicare: group & point 2 point Send: Parametru - destinație Receive: O adresă de proces, un singur mesaj este trimis la un proces. O adresă de grup (sau o referință la o lista de destinații), un mesaj este trimis la toți membrii grupului Complet cand sosește un mesaj punct-la-punct sau de grup 2. Proceduri noi de bibliotecă: group-send group-receive

Atomicitate Dezirabilă deoarece face programarea sistemelor distribuite mai ușoară Un proces care expediază un mesaj la un grup nu trebuie să-și facă griji ce să facă dacă unul dintre membri nu l-a primit Exemplu - într-un sistem de baze de date distribuite și cu replicare: Un proces expediază un mesaj la toate mașinile care dețin baza de date pentru o nouă înregistrare în baza de date Are certitudinea că data a fost scrisă în toate replicile

Ordonarea mesajelor Ordonarea în timp global: Se așteaptă ca toate mesajele să fie livrate instantaneu și în ordinea în care au fost exepdiate Toate destinațiile obțin toate mesajele în exact acceași ordine Ignoră din motive de conveniență faptul că nu există un timp global absolut! Ordonarea în timp absolut nu este întotdeauna ușor de implementat! Anumite sisteme oferă variațiuni pe această temă. De exemplu: Ordonare în timp consistentă: Daca două mesaje, fie A și B, sunt expediate apropriat în timp, sistemul preia unul dintre acestea ca fiind primul și îl livrează la toți membrii grupului urmat de celălalt Se întâmplă ca cel ales să nu fie cel real, dar comportarea sistemului nu depinde de acesta Mesajele ajung la toți membrii grupului în aceeași ordine, dar ordinea nu este neapărat ordinea reală în care au fost expediate

Grupuri cu suprapunere Deși există o ordonoare în timp în fiecare grup, nu este în mod necesar și o coordonare între grupuri multiple Anumite sisteme suportă ordonarea în timp între grupuri suprapuse, altele nu Implementarea ordonării în timp între grupuri diferite este dificilă