adl approach to performance modelling of fault-tolerant

Wstep Motywacja Stochatyczna algebra procesów Modelowanie awarii Jezyk PODSAL Podsumowanie

ADL approach to performance modelling of fault-tolerantdistributed systems

Dariusz Dwornikowski

Instytut InformatykiPolitechnika Poznanska

Poznan, 7/6/2011 r.

Dariusz Dwornikowski Instytut InformatykiPolitechnika Poznanska

ADL approach to performance modelling of fault-tolerant distributed systems


Plan prezentacji

1 Motywacja

2 Stochatyczna algebra procesów

3 Modelowanie awarii

4 Jezyk PODSAL

5 Podsumowanie




Szacowanie wydajnosci systemów rozproszonych

Spełnianie wymagan uzytkowników(SLA, QoS)

W systemach usługowych przełozeniena zysk (SOA, Cloud)

Wpływ na poprawnosc działania

Mniej ustepstw na innych waznychpolach (bezpieczenstwo,niezawodnosc)

Oszczednosc energii (mniej maszyn =mniej pradu)




Jak szacowac wydajnosc

Pomiaryinwazyjnewymagaja prototypu lub działajacego systemutrudnosc uogólnienianie zawsze mozliwe

Symulacjeczasochłonne (przygotowanie symulatora)słabo rozszerzalnewymagajace zasobów infrastrukturalnych

Modelowanie za pomoca metod formalnych




Metody formalne w szacowaniu wydajnosci

Gdy pomiary nie sa mozliwe.

Gdy pomiar ma istotny wpływ na poprawnosc i wydajnosc.

Gdy interesuje nas cos wiecej niz sama wydajnosc (poprawnosc, zachowanie).




Metody formalne w szacowaniu wydajnosci

Modele Markova

Czasowe i stochastyczne sieci PetriegoTime Petri Nets, Deterministic Time Petri Nets, Stochastic Timed Petri Nets, Generalized Stochastic Petri Nets, . . .

Automaty czasowe

Sieci automatów stochastycznychStochastic Automata Networks

Teoria kolejekKolejki, Sieci kolejkujace, . . .

Stochastyczne algebry procesów (SPA)(M)TIPP, EMPA, Stochastic π − calculus, GSMPA, IMC, Modest, IGSMP




Stochastyczna algebra procesów

Zalety:

Prostota (ang. parsimonous)

Kompozycyjnosc

Wsparcie dla modelowania współbieznosci

Silna podstawa formalna

Behawioralizm i wydajnosc

Duze modele przedstawione w kompaktowy sposób

Wady:

Eksplozja przestrzeni stanów

Dziedzina probabilistyczna




PEPA (Performance Evaluation Process Algebra)

PEPA jest stochastyczna algebra procesów, stworzona przez Jane Hillston, dla którejmatematyczna podstawa jest łancuch Markova z czasem ciagłym – CTMC(ang. Continuous Time Markov Chain).

PEPA ukierunkowana jest na szacowanie wydajnosci, jednoczesnie nie tracac cechtradycyjnych algebr procesów (relacje równowaznosci, behawioralizm, analizaosiagalnosci, weryfikacja modelowa).




Rozwiazywanie modeli




PEPA

W PEPA podstawowa jednostka abstrakcji sa komponenty, które za pomocaoperatorów łaczone sa w modele.

Komponenty angazuja sie w aktywnosci, scharakteryzowane przez typ oraz tempo(ang. activity rate), z jakim przebiegaja.

Formalnie aktywnosc mozna opisac jako dwójke (α, r), gdzie α jest typem aktywnosci(ang. action type), a r jest tempem (ang. activity rate).




PEPA

Z kazda aktywnoscia skojarzona jest zmienna losowa o ujemnym rozkładziewykładniczym 1− e−λ∗t .

Tempo wykonywania aktywnosci r jest równe parametrowi λ w rozkładziewykładniczym.

Oznacza to, ze dana aktywnosc wykonuje sie srednio λ−1 jednostek czasu.




Ograniczenia

Aby łancuch Markova posiadał rozwiazanie stanu ustalonego, modele PEPA muszabyc powracajace.

Oznacza to, ze w modelu nie moga istniec komponenty z aktywnosciamiprowadzacymi do stanów bez “wyjscia“.

Nieformalnie, gdy model osiagnie stan, w którym ma do wyboru dwie sciezkizachowan, to którejkolwiek nie wybierze, musi w koncu powrócic do tego samegomiejsca.




PEPA

S def= (α, r).P

Proces S wykonuje aktywnosc typu α w tempie r , po czym zachowuje sie jak proces P.




PEPA operatory

PEPA definiuje zbiór operatorów, za pomoca których mozliwe jest wyrazanie całychsystemów.

Stała (ang. constant) S def= P, pozwala na nazywanie komponentów. Komponentowi S

przypisujemy zachowanie komponentu P.

Prefiks (ang. prefix) (α, r).P, komponent (α, r).P wykonuje czynnosc (α, r), po czymzachowuje sie jak komponent P

Wybór (ang. choice) P1 + P2, operator probabilistycznego wyboru opisujewspółzawodnictwo pomiedzy komponentami.

Kooperacja (ang. cooperation) P1 BCL P2 pozwala na synchronizacje pomiedzykomponentami na aktywnosciach ze zbioru L.

Kompozycja równoległa (ang. parallel composition) P1||P2, procesy działaja zupełnieniezaleznie, nie ma pomiedzy nimi kooperacji, ani współzawodnictwa

Ukrywanie, abstrakcja (ang. hiding) P1/{χ}, aktywnosc α jest dostepna jedynie dlaprocesu P1,staje sie jego wewnetrzna aktywnoscia lokalna τ ,niewidoczna dla obserwatora zewnetrznego.




Przykład modelu

Komponent Consumer cyklicznie ubiega sie o zasób Resource w celu jego uzycia.Reprezentowane jest to przez typ współdzielonej akcji use.

Consumer def= (use, r1).(task , r2).Consumer

Resource def= (use, r3).(update, r4).Resource

System def= Consumer BC

useResource




Algebry stochastyczne dla systemów odpornych na awarie

Dotychczasowe badania i literatura abstrahowały od modelowania awarii.

Tworzone modele i metody nie były zatem przystajace do rzeczywistosci, poniewazawarii nie mozna wykluczyc (maja one wpływ na wydajnosc).

Ze wzgledu na charakter algebr stochastycznych, reprezentacja w nich awarii nie jesttrywialne.




Modelowanie awarii w algebrach stochastycznych

Problemy:

Inny poziom abstrakcji (proces kontra stan)

Wieksza dokładnosc (stany, tranzycje, zachowania)

Brak semantyki

Wymóg istnienia rozwiazania stanu ustalonego

Eksplozja stanów




Typy awarii w systemach rozproszonych

Załamania (ang. crash-stop)proces ulega awarii w chwili t i nigdy niewiecej nie wykonuje zadnej akcji

Zaniechania (ang. omission)pewne komunikaty sa pomijane przezproces

Awarie odtwarzalne (ang. crash-recovery)proces ulega awarii, ale po jakims czasiesie podnosi

Awarie dowolne (ang. arbitrary)dowolne inne, np. przekłamania, ataki,losowe zachowanie




Modelowanie awarii w algebrach stochastycznych

Awaria ma nature probabilistyczna — moze sie zdarzyc lub nie.

Naturalnym jest wiec modelowanie awarii za pomoca operatora choice.

Model procesu ulegajacego awarii przedstawia sie zatem nastepujaco:

C def= P + F

gdzie P jest komponentem awaryjnym, a F komponentem awarii




Awarie odtwarzalne

Awarie odtwarzalne sa najbardziej interesujace, jako ze posiadaja powracajaca nature.Ich model w SPA jest zatem intuicyjny.

Przykład awarii odtwarzalnej

Process def= (dowork , d1).Process1 + (fail, f1).ProcessFail

Process1def= (sleep, s1).Process + (fail, f1).ProcessFail1

ProcessFaildef= (recover , r1).Process

ProcessFail1def= (recover , r1).Process1




Załamania

Awarie typu załamania nie sa mozliwe do bezposredniego zamodelowania w PEPA.

Oznaczałoby to, ze musi istniec operator terminacji (ang. deadlock, oznaczany 0,STOP).

Skutkuje to w braku rozwiazania stanu ustalonego (stany absorbujace).

Przykład załamania z terminacja

Process def= (work , r1).Process + (fail, f1).STOP




Załamania

Ratunkiem jest traktowanie załamania jako szczególnego przypadku awariiodtwarzalnej.

Przykład załamania typu restart

Process def= (dowork , d1).Process1 + (fail, f1).ProcessFail

Process1def= (sleep, s1).Process + (fail, f1).ProcessFail

ProcessFaildef= (restart , r1).Process




Załamania

Sytuacja gdzie załamanie moze zostac zamodelowane nie wprost sa modelesystemów z replikacja.

Tam jestesmy zainteresowani jaki wpływ na wydajnosc moze miec znikniecie jednego zN identycznych komponentów z systemu.

Metoda modelowania moze byc rozwiazanie kilku wersji modelu, za kazdym razem zinna liczba komponentów obecnych w systemie.

Przykład równania systemu

Client def= . . .

Server def= . . .

Client[M] BCconnect

Server [N]

Client[M] BCconnect

Server [N − 2]




Zaniechania

Poprzednie typy awarii mogły byc wyrazone czysto behawioralnie (stany, tranzycje).

Zaniechanie plasuje sie poziom wyzej — nadaje znaczenie czesci procesu (wysyłanie,odbieranie, kanał).

Z punktu widzenia behawioralnego jest równa awariom odtwarzalnym.

Jednakze jej automatyczne modelowanie nie jest mozliwe bez narzucenia semantykitranzycjom i stanom.




Zaniechania

Przykład zaniechania w procesie

Process def= (send , d1).Process1 + (omit1, o1).Process

Process1def= (receive, s1).Process + (omit2, o2).Process1

Przykład zaniechania w kanale

Sender def= (send , s0).(prepare, p1).Process

Receiver def= (receive, r0).(compute, c1).Receiver

Channel def= (send , s1).Channel1 + (omit1, o1).Channel

Channel1def= (propagate, p1).(receive, r1).Channel + (omit2, o2).Channel

Sender BCsend

Channel BCreceive

Receiver




Problem badawczy

Automatyczne modelowanie awarii ukierunkowane na szacowanie wydajnosci.




Potencjalne rozwiazania problemu

Istnieja trzy podejscia do rozwiazania problemu:

Rozszerzyc algebre procesów (nowe operatory) NIE

Rozszerzyc narzedzi modelowania NIE

Wzniesc sie na wyzszy poziom abstrakcji — jezyk ADL TAK




Jezyk definicji architektury zorientowany na systemy odporne na awarie

Jezyki ADL (ang. Architectural Description Language) to jezyki ukierunkowane namodelowanie architektur.

Charakteryzuja sie:

Hierarchicznoscia

Wystepowaniem łaczników (ang. connectors) i komponentów (ang. components)

Wbudowane paradygmaty komunikacji (porty, potoki, bufory, gniazda)

Wsparcie dla paradygmatów architektonicznych




Jezyk definicji architektury zorientowany na systemy odporne na awarie

Istniejace jezyki:

ACME

Rapide

Aesop

Wright

AEmilia

Meta-H

C2

Unicon

xADL

Wady istniejacych rozwiazan:

Brak wsparcia dla szacowaniawydajnosci

Nieczytelne i skomplikowane

Zbyt ukierunkowane dziedzinowo

Zbyt ogólne

Brak lub słabe wsparcie dla opisówbehawioralnych

Brak lub słabe wsparcie narzedzi




Jezyk PODSAL

PODSAL (Performance Oriented Distributed Systems Architectural Language)

Załozenia:

Czytelny i prosty

Wsparcie dla rozproszonych systemów odpornych na awarie

Mozliwosc wsparcia dla róznych metod formalnych (PEPA, CTMC)

Rozszerzalnosc

Rozproszony model narzedzi

Wsparcie dla przetwarzania maszynowego

Wsparcie dla metod weryfikacji modelowej (ang. model checking)




Koncepcja narzedzi jezyka




Gramatyka PODSAL

import <MODULE NAME>;

component <COMPONENT NAME> *extends <COMPONENT NAME> {

*behaviour {<BEHAVIORAL DESC.>

}

*failure {type: crash-recovery | crash-stop | omission;attach: all | <LIST>;

*behaviuor {<BEHAVIORAL DESC.>

}}

*meta {parameter <PARAM NAME> = <VALUE>*;

}}

connection <CONNECTION NAME> (component <COMPONENT NAME>*,..., actionset <ACTIONSET NAME>) {glue {

<GLUE DEFINITION>;}

}

model instance <INSTANCE NAME> {meta {

<MODULE NAME> {<NAME>=<VALUE>*;

}}<COMPONENT NAME>=<NUMBER>*;

<CONNECTION NAME>(<COMPONENT NAME>*, {<ACTION>*});}




Przykład modelu w PODSALModel bez awarii

Model1.adl

import pepa;

component Process {bahaviour {

use->task;}

}

component Resource {behaviour {body {

use->update;}

}}

connection Usage (component A, component B, actionset c) {glue {A <c> B;

}}

model instance ProcessResource {meta {pepa {Process.use.rate=exp(10);Process.task.rate=exp(10);Resource.use.rate=exp(20);Resource.update.rate=exp(30);

}}connect Usage(Process, Resource, {use});Process.count=10;Resource.count=20;

}




Przykład modelu w PODSALModel z awariami i dziedziczeniem

Model2.adl

import pepa;import model1.adl;

component Process {bahaviour {

use->task;}

}

component ResourceFailingextends Resource {

failure {type: crash-recovery;attach: all;bahaviour {

fail->recover}

}

connection Usage (component A, component B, actionset c) {glue {A <c> B;

}}

model instance ProcessResourceFailures {meta {pepa {Process.use.rate = exp(10);Process.task.rate = exp(10);Resource.use.rate = exp(20);Resource.update.rate = exp(30);Resource.failure.fail.rate = exp(345);Resource.failure.recover.rate = exp(77);

}}connect Usage(Process, Resource, {use});Process.count = 10;Resource.count = 20;

}




Podsumowanie

Przedstawiono:

Wprowadzenie do algebr stochastycznych na przykładzie PEPA

Propozycje modelowania awarii w algebrach stochastycznych

Wstepna koncepcje jezyka PODSAL

Dalszy kierunek badan:

Sfinalizowanie pierwszej wersji jezyka

Implementacja translatora do algebry PEPA

Standardowa biblioteka jezyka (detektory awarii, kanały, standardoweparadygmaty komunikacji)

Metody weryfikacji translacji modeli




Dziekuje za uwage.



adl approach to performance modelling of fault-tolerant

Documents