PÁRHUZAMOS ARCHITEKTÚRÁK – 2 ELOSZTOTT RENDSZEREK ALAPJAI Németh Gábor.

Az előadások a következő témára: "PÁRHUZAMOS ARCHITEKTÚRÁK – 2 ELOSZTOTT RENDSZEREK ALAPJAI Németh Gábor."— Előadás másolata:

1 PÁRHUZAMOS ARCHITEKTÚRÁK – 2 ELOSZTOTT RENDSZEREK ALAPJAI Németh Gábor

2 2015Németh Gábor: Párhuzamos architektúrák2 ELOSZTOTT RENDSZEREK ALAPJAI - 1 Egy számítógéprendszerben a felhasználók az erőfor- rásokhoz bizonyos FUNKCIÓK felhasználásával férnek hozzá. Ezeket a funkciókat logikai ENTITÁSOKnak tekintett folyamatokkal valósítjuk meg. függvények halmaza (véges); az függvényt megvalósító entitások halmaza (véges);

3 2015Németh Gábor: Párhuzamos architektúrák3 ELOSZTOTT RENDSZEREK ALAPJAI - 2 Az pillanatnyi állapota globális állapota Egy rendszer -elosztott, ha, hogy ismert az entitás számára. Egy rendszer teljesen elosztott, ha -elosztottesetén. Nagy és/vagy gyors rendszerekben a terjedési késleltetés nem hanyagolható el és változó, így ezek teljesen elosztott rendszerek.

4 2015Németh Gábor: Párhuzamos architektúrák4 ELOSZTOTT RENDSZEREK ALAPJAI - 3 Egy rendszer tervezésének lépései: 1.Meg kell határozni az ELŐFELTEVÉSEKet (a rendszernek csak ezen korlátozások mellett kell helyesen működnie). 2.Meg kell határozni a rendszer SPECIFIKÁCIÓit (a helyes működés kritériumait). 3.Létre kell hozni a rendszer TERVEZÉSI MODELLjét. 4.FORMÁLIS BIZONYÍTÁSsal igazolni kell a logikai megoldás helyességét.

5 2015Németh Gábor: Párhuzamos architektúrák5 ILLUSZTRATÍV PÉLDA - 1 ILLUSZTRATÍV PÉLDA: R erőforrást kell hozzárendelni U felhasználóhoz; a kérések átvitelére egy kommunikációs alrendszert használunk. Most nem foglalkozunk azzal, hogy hogyan lehet egy megoldást kidolgozni, csak egy lehetséges megoldást tekintünk: virtuális gyűrű 1.A rendszerben minden entitáshoz definiálunk egy őt követő szomszédot (virtuális gyűrűt hozunk létre).

6 2015Németh Gábor: Párhuzamos architektúrák6 ILLUSZTRATÍV PÉLDA - 2 vezérlő token 2.Egyetlen vezérlő token kering a gyűrűn. 3.Egy entitás akkor és csak akkor küldhet erőforrás- foglalás kérést, ha jelenleg nála van a vezérlő token. 4.Minden R erőforrásnál egy várakozási sort hozunk létre, melybe beírjuk a kéréseket. (Most eltekintünk a kérések prioritásától, a várakozási sorok hosszától, stb.) 5.Ha egy entitás megkapta a nyugtákat a kéréseire, akkor továbbadja a vezérlő tokent a gyűrűn őt követő szomszédjának. (Most eltekintünk a nyugta elvesztésétől, stb.)

7 2015Németh Gábor: Párhuzamos architektúrák7 ILLUSZTRATÍV PÉLDA - 3 6.Valamikor az U entitás üzenetet kap egy előzőleg kért R erőforrástól, hogy használhatja (a kérés a várakozási sora elejére került). KIVÁLASZTOTT RÉSZPROBLÉMA: Egy olyan algoritmust kell tervezni, mely egy új vezérlő tokent generál, ha valamilyen ok miatt elveszik a vezérlő token. Egy olyan algoritmust kell tervezni, mely egy új vezérlő tokent generál, ha valamilyen ok miatt elveszik a vezérlő token. Megjegyzések: - Megoldja a rendszer automatikus hidegindítását. - Ez egy kölcsönös kizárási probléma elosztott rendszerben.

8 2015Németh Gábor: Párhuzamos architektúrák8 ELŐFELTEVÉSEK - 1 Először meghatározzuk az előfeltevéseket (a gyakorlatban lehet, hogy több iteráció kell). 2 fő csoport: - a környezetből származó megkötések; - tervezői döntések. ELŐFELTEVÉSEK: 1.A rendszerben az új vezérlő token generálásáig nem lép fel újabb meghibásodás. (Önkényes tervezői döntés; a tervező nem elég okos.)

9 2015Németh Gábor: Párhuzamos architektúrák9 ELŐFELTEVÉSEK - 2 2.Az entitásokat i  {0,…,n-1} egészszámokkal azonosítjuk. (Önkényes tervezői döntés az egyszerű azonosításhoz, de azonosítás kell.) 3.Minden entitás hozzáférhet a gyűrűn keringő tokenekhez. (Önkényes tervezői döntés, vagy adottság; így minden entitás részt vehet az új token generálásában.) 4.Minden entitásnak saját időzítője van, melyet alaphelyzetbe állítunk vissza a vezérlő token vételekor.

10 2015Németh Gábor: Párhuzamos architektúrák10 ELŐFELTEVÉSEK - 3 5.Az entitás elveszettnek tekinti a vezérlő tokent, ha időzítője felébred. Azonnal egy azonosítójával ellátott jelölt tokent generál. (A 4. és 5. előfeltevésekkel határozzuk meg, hogy hogyan észleljük a vezérlő token elvesztését, azaz hogyan indul az algoritmus. Ezek szükséges tervezői döntések.) 6.A rendszer aszinkron, minden entitásnak saját időzítője van, az időzítési értékek nem szükség- képpen azonosak. (Teljesen természetesnek látszik, de keverednek az önkényes tervezői döntések [saját időzítők, eltérő értékek] és a környezeti korlátozások [aszinkron futó órák].)

11 2015Németh Gábor: Párhuzamos architektúrák11 ELŐFELTEVÉSEK - 4 7.Az üzenetek sorrendje nem változik a gyűrűn. (Ha az entitások fizikailag is gyűrűbe vannak kötve, akkor ez a környezetből származó előfeltevés. Ha a struktúra fizikailag nem gyűrű [pl. sín] csak logikailag, akkor ez egy önkényes tervezői döntés[nek látszik], mely megfelelő megvalósítást igényel. DE A FORMÁLIS BIZONYÍTÁSBÓL A HELYES MŰKÖDÉSHEZ SZÜKSÉGES KÖVETELMÉNYKÉNT ADÓDIK!) 8.Egy token generálása pillanatnyi atomi esemény. (Egyszerűsítő tervezői döntés.) 9.Egy entitás leveszi a gyűrűről a hozzá érkező üzenetet és ráteszi a gyűrűre kimenő üzenetét. (Takarítás!)

12 2015Németh Gábor: Párhuzamos architektúrák12 SPECIFIKÁCIÓK Meghatározzuk a specifikációkat (a rendszer helyes működésének kritériumait). SPECIFIKÁCIÓK: A.Egyetlen entitás generál új vezérlő tokent. B.Az új vezérlő tokent felülről korlátos időn belül generáljuk. MEGJEGYZÉS:Egy végtelen meghibásodási soro- zat megakadályozhatja a B speci- fikáció teljesülését. Ez az 1. előfel- tevés oka (jobb változata: az új vezérlő token generálásáig csak max. n meghibásodás léphet fel).

13 2015Németh Gábor: Párhuzamos architektúrák13 MEGFIGYELHETŐSÉG - 1 Az adott körülmények között mit látnak az entitások? Jelölje I a választásban résztvevő entitások halmazát (akiknek időzítője felébredt a vezérlő token elveszése miatt), S(i), i  I az i entitás által saját jelöltjének teljes körbefutása alatt észlelt jelölt token azonosítók halmaza. i j k TiTi i j k TiTi TkTk i j k TiTi TkTk TjTj Az eltérő időzítés értékek és/vagy óra futási sebességek miatt előfordulhat, hogy j jelöltjét azután generálja, hogy i jelöltje már áthaladt rajta, de k-é még nem. Így S(i) = {i, k} és S(k) = {i, j, k}. Az entitások nem látnak azonos képet a rendszerről!

14 2015Németh Gábor: Párhuzamos architektúrák14 MEGFIGYELHETŐSÉG - 2 Az entitások nem látnak azonos képet a rendszerről és nincs olyan entitás, mely biztosan helyes képet látna.  Elosztott rendszer.  Nincs olyan entitás, mely a priori felelős lehetne az új vezérlő token generálásáért.  Minden jelölt entitásnak saját magának kell döntenie az általa látott helyzet alapján, hogy ő lesz-e a győztes vagy sem.  Minden jelölt entitásnak saját magának kell döntenie az általa látott helyzet (vett jelölt tokenek) alapján, hogy ő lesz-e a győztes vagy sem.  Olyan algoritmust kell tervezni, mely az entitások előre nem definiált részhalmazán fut, mindig megengedett állapotokban tartja a rendszert és teljesíti a specifikációkat.

15 2015Németh Gábor: Párhuzamos architektúrák15 TERVEZÉSI MODELL - 1 Most nem foglalkozunk a tervezési módszerrel, így egy lehetséges megoldást adunk meg véges automata TERVEZÉSI MODELLel:  VÁLASZTÁS: Ha i = min [S(i)], akkor az i entitás azonnal generálja az új vezérlő tokent.  TAKARÍTÁS: A ”vesztes” jelölt tokenek eltávolítása a gyűrűről. (Nem tárgyaljuk, pl. a vesztes leveszi, ha visszaér hozzá.)

16 2015Németh Gábor: Párhuzamos architektúrák16 TERVEZÉSI MODELL - 2 A rendszerben választáskor fellépő eseményeket és állapotokat a választott algoritmusból, előfeltevésekből és specifikációkból származtatjuk. Ezzel itt most nem foglalkozunk. i entitás eseményei: 1:felébred az időzítő; 2:vezérlő token (CT – Control Token) vétele; 3:jelölt token vétele, melynek azonosítója < i; 4:jelölt token vétele, melynek azonosítója > i; 5:saját jelölt (i) token vétele egy teljes gyűrűn körbefutás után.

17 2015Németh Gábor: Párhuzamos architektúrák17 TERVEZÉSI MODELL - 3 i entitás állapotai: A:normális működés, a vezérlő token időzítő be van állítva. B:i entitás kész egy új CT generálására, jelölt token időzítője be van állítva. (Jelölt tokent generált, eddig nem adta fel jelöltségét. A jelölt token időzítő a választás közben fellépő meghibásodás esetén új választási eljárást indíthat.) C:i entitás feladta jelöltségét, jelölt token időzítője be van állítva. A*:generálja az új CT-t és azonnal átmegy A állapotba.

18 2015Németh Gábor: Párhuzamos architektúrák18 TERVEZÉSI MODELL - 4 i entitás állapot-átmeneti táblája: (A szabadon választva)

19 2015Németh Gábor: Párhuzamos architektúrák19 FORMÁLIS BIZONYÍTÁS - 1 FORMÁLIS BIZONYÍTÁSsal igazoljuk a logikai megoldás helyességét: 1.Nagy rendszerek esetén az ellenőrző vizsgálat túlságosan hosszú ideig tart (ha egyáltalán lehetséges). 2. Az esetleges javítások/módosítások helyének meghatározásához a logikai megoldás hibáit meg kell különböztetni a megvalósítás hibáitól (a logikai megoldás helyességét formálisan bizonyítjuk, majd a logikailag helyes megoldás jó megvalósítását ellenőrző vizsgálattal igazoljuk).

20 2015Németh Gábor: Párhuzamos architektúrák20 FORMÁLIS BIZONYÍTÁS - 2 Mivel a döntést a nyertes entitás saját jelöltjének körbe- futása után hozza meg (korlátos időtartam), B specifikáció nyilvánvalóan teljesül, ha az A specifikáció teljesül. A specifikáció teljesülését indirekt módon igazoljuk: -Tételezzük fel, hogy két entitás (x és y) generál új vezérlő tokent (megsértve az A specifikációt). -Kimutatjuk, hogy ez lehetetlen (ha x generálta, akkor y nem generálhat és fordítva).

21 2015Németh Gábor: Párhuzamos architektúrák21 FORMÁLIS BIZONYÍTÁS - 3 Az általánosság korlátozása nélkül feltételezzük, hogy azonosító(x) < azonosító(y). I(x, 0)= x entitás ebben a pillanatban generál egy jelölt tokent. I(x, y)=x által generált jelölt tokent ebben a pillanatban veszi az y entitás. I(x, x)=x által generált jelölt tokent egy teljes körülfutás után ebben a pillanatban veszi az x entitás. I(CT, x)=x entitás ebben a pillanatban veszi a vezérlő tokent.

22 2015Németh Gábor: Párhuzamos architektúrák22 FORMÁLIS BIZONYÍTÁS - 4 y entitás akkor és csak akkor generál új vezérlő tokent, ha az I(y, y) időpillanatban állapota B. (5. esemény: saját jelölt (i) token vétele egy teljes gyűrűn körbefutás után; B állapot: i entitás kész egy új CT gene- rálására.) Az állapot-átmeneti tábla 2. sorából következik, hogy az I(y, 0) időpillanat (amikor az 1. esemény miatt jelöltté vált) és az I(y, y) időpillanat között sem a 2., sem a 3. esemény nem léphet fel.

23 2015Németh Gábor: Párhuzamos architektúrák23 FORMÁLIS BIZONYÍTÁS - 5 Hasonló megfontolással x entitás akkor és csak akkor generál új vezérlő tokent, ha a 2. esemény nem lép fel az I(x, 0) és az I(x, x) időpillanatok között. (A 3. eseményt nem kell tekinteni, mert azonosító(x) < azonosító(y).) Kimutatjuk, hogy ezek a feltételek ellentmondásra vezetnek, azaz nem generálhat mindkét entitás egy-egy új vezérlő tokent.

24 2015Németh Gábor: Párhuzamos architektúrák24 FORMÁLIS BIZONYÍTÁS - 6  3 I(y, 0) és I(y, y) között (y nyer): (3. esemény: y entitás veszi az x entitás jelöltjét.) I(x, y) > I(y, y) (1), vagy I(x, y) < I(y, 0) (1a)  2 I(x, 0) és I(x, x) között (x nyer): (2. esemény: x entitás vezérlő tokent vesz.) I(CT, x) > I(x, x) (2) (I(CT, x) < I(x, 0) esetén x nem is lépne fel jelöltként!)

25 2015Németh Gábor: Párhuzamos architektúrák25 FORMÁLIS BIZONYÍTÁS - 7 y entitás indítja jelöltjét: I(y, 0) x-hez ér: x entitás indítja jelöltjét: I(y, x) I(x, 0) y-hoz ér: I(y, y) I(x, y) x-hez ér: I(CT, x) > I(x, x) lásd (2) (x nyer) > (2)-ből következik, HA az üze- netek sorrendje nem változik a gyűrűn  7. előfeltevés. Ez ellentmond (1)-nek! (y nyerésének) x y TxTx TyTy Nem nyerhet egyszerre x (2) és y (1).

26 2015Németh Gábor: Párhuzamos architektúrák26 FORMÁLIS BIZONYÍTÁS - 8 Hasonlóan, (1a) feltétel és a 7. előfeltevés szerint: x entitás indítja jelöltjét: I(x, 0) y-hoz ér: y entitás indítja jelöltjét: I(x, y) I(y, 0)<[lásd (1a); y nyer] x-hez ér: I(x, x) I(y, x)<[a 7. előfeltevés miatt] y-hoz ér: I(CT, y) I(y, y) <[a 7. előfeltevés miatt] Azaz fellép a 2. esemény, ellentmondva annak, hogy y nyerésé- hez sem a 2., sem a 3. esemény nem léphet fel I(y, 0) és I(y, y) között.