2. Elosztott rendszerek

1. 2. Elosztott rendszerek Dr. Bilicki Vilmos Szegedi Tudományegyetem Informatikai Tanszékcsoport Szoftverfejlesztés Tanszék

2. Programrendszerek fejlesztése Tartalom • Bevezető • Felmerülő problémák • Alkalmazás architektúrák • Elosztott rendszer architektúrák • SOA koncepció • Virtualizációs szintek • Összefoglaló

3. Programrendszerek fejlesztése Valós nagy rendszerrel kapcsolatos tapasztalatok (Inktomi)

4. Programrendszerek fejlesztése Motiváció – nem funkcionális követelmények • Rendelkezésre állás: azon idő amely alatt a komponens képes kielégíteni a funkcionális követelményekben meghatározott funkciókat azon időhöz viszonyítva amikor ezt nem tudja megtenni. • Kapacitás/Skálázhatóság: A komponens a terhelés növekedésével is képes ellátni a funkcionális követelményekben megfogalmazott feladatokat. • Párhuzamosság: A komponens a több egymással párhuzamos terhelés hatására is képes ellátni a funkcionális követelményekben megfogalmazott feladatokat. • Fejleszthetőség: A komponens új funkcionális követelményeket is el tud látni viszonylag szerény fejlesztési ráfordítással. • Együttműködési képesség: A komponens képes környezetével és a szükséges komponensekkel aránytalan plusz terhelés okozása nélkül is együttműködni. • Késleltetés: A komponens az adott funkcionális követelményben szereplő szolgáltatását adott terhelés mellett adott időtartamon belül kiszolgálja. • Karbantarthatóság: A komponensnek támogatnia kell az adott szervezetben definiált karbantartási feladatokat (pl.: backup) • Menedzselhetőség: A komponensnek támogatnia kell a megfelelő konfigurálhatósági szintet. • Monitorozhatóság: A komponensnek monitorozhatónak kell lennie. • Visszaállíthatóság: Hibás adat esetén a komponensnek támogatnia kell a megfelelő állapot visszaállítását. • Biztonság: A komponensnek a helyi biztonsági előírásoknak megfelelően kell működnie. • Konzisztencia: A komponens az adatot konzisztens állapotban tartja.

5. Programrendszerek fejlesztése Rendelkezésre állás • Az alábbi paraméterektől függ • Megbízhatóság: • Annak az esélye, hogy egy rendszer adott ideig hibamenetesen működik (lmeghibásodási ráta) • Karbantarthatóság: • Annek az esélye, hogy egy meghibásodás után egy adott időtartam alatt visszaáll a működőképes állapot (mmegjavítási ráta) • A rendelkezésre állás a rendszer működőképes ideje és a teljes idő hányadosa R(t) = e-lt M(t) = 1 - e-mt Up-Time Up-Time + Down-Time A =

6. Programrendszerek fejlesztése Fogalmak • MTTF Mean Time To Fail: • MTBF Mean Time Between Failure: • MTTR Mean Time To Repair: B1 + B2 + B3 3 MTTF = (A1 + B1) + (A2 + B2) + (A3 + B3) 3 MTBF = A1 + A2 + A3 3 MTTR = B1 B2 B3 Up t Down A1 A2 A3

7. Programrendszerek fejlesztése Fürdőkád görbe l Failure Rate Time Burn-In Useful Life Note: Failure Rate is constant Wear-Out

8. Programrendszerek fejlesztése Megoldás: redundancia • Aktív redundancia • Elem/komponens duplikálás • Rendszer duplikálás • Passzív redundancia • Hot Standby • WarmStandby • ColdStandby • Soros rendszer: • Párhuzamos rendszer: Rs = p1 . p2 ……. pn q1 = 1 - p1 q2 = 1 - p2 Rs = 1 - q1 q2 ……qm

9. Programrendszerek fejlesztése Példa • Amazon EC2: • 99.95% átlagos rendelkezésre állás egy év alatt • Évi 4,38 óra leállás • GoogleApps: • 99.9% havi alapon • Évi 8,76 óra leállás, havi 0,73 óra leállás • Serveloft: • Hálózat: 99,9%, 4 órás helyreállítási idő • Gép: 4 órás helyreállítási idő • Rackspace: • Hálózat: 100% (karbantartáson kívül) • Infrastruktúra: 100% havonta (karban tartáson kívül) • Gép: 1 órán belül csere

10. Programrendszerek fejlesztése Skálázhatóság • Adat tárolás/Feldolgozás • Vertikális (Scaleup) • Fizikai korlátai vannak (processzorok száma, JVM szemétgyűjtő, …) • Közös memória mint kommunikációs médium • Horizontális (Scale out) • Elosztott rendszer (LeslieLamport: „Elosztott rendszer az ahol egy addig teljesen ismeretlen számítógép hibája teszi használhatatlanná a gépünket”) • Elvileg korlátlan (elosztottságból fakadóan nem lehet ACID) • Távoli hozzáférés problematikája (érték szerint vs. referencia szerint)

11. Programrendszerek fejlesztése Virtualizációs rétegek

12. Programrendszerek fejlesztése IaaS - Infrastruktúra mint Szolgáltatás • Valós vagy virtualizált HW • Processzor • Memória • I/O • Hálózat • Függ a fizikai eszközöktől • Példák:

13. Programrendszerek fejlesztése Virtualizáció • Absztrakt fizikiai komponensek logikai objektumok segítségével • A fizikai és logikai objektumok dinamikus kötése • Példa: • Hálózat: VLAN, VPN, P2P • Tárhely: SAN • Számítógép: Virtuális Gép

14. Programrendszerek fejlesztése Fizikai vs. Virtuális gép • Fizikai HW: • Processzor, memória, chipset, I/O busz • A fizikai erőforrások gyakran üresjáratban vannak • Szoftver: • Szorosan kapcsolódik a HW-hez • Egy aktív OS kép • Az OS vezérli a HW-t • Hardver szintű absztrakció: • Virtuális HW: processzor, memória, chipset, I/O eszközök, … • Magában foglalja az OS és alkalmazás állapotot • Virtualizációs SW: • Elválasztja a HW-t és az OS-t • A vendég OS-ek felé multiplexálja a HW-t • Erős szeparáció • Kezeli a fizikai erőforrásokat

15. Programrendszerek fejlesztése Típusai • Type 2: Hosztolt architektúra: • Befogadó Oprendszer felett van futtatva • Kicsi kontextus váltó meghajtó • Type 1: Csupasz fém architektúra • A Hypervisort közvetlenül a HW-re telepítik • Paravirtualizáció • Az operációs rendszer tud a Hyervisorról

16. Programrendszerek fejlesztése Magas rendelkezésre állás

17. Programrendszerek fejlesztése Konszolidált mentés

18. Programrendszerek fejlesztése Probléma:

19. Programrendszerek fejlesztése PaaS - Gartner

20. Programrendszerek fejlesztése PaaS Felmerülő problémák • Leslie Lamportegyigenfrappánsdefiníciótadottazeloszotottrendszerekre: • “A distributedsystem is oneinwhichthefailure of a computer youdidn't evenknowexistedcanrenderyourown computer unusable” azaz „Elosztott rendszer az, ahol egy olyan számítógép hibája teszi használhatatlanná a saját gépünket, amiről azt sem tudtuk, hogy létezik.” • Egy szabatosabb definíció Wolfgang Emmerichtől: „Elosztott rendszernek nevezzük az autonóm, egymással hálózaton együttműködő számítógépeket, amelyek közös együttműködésén alapuló szolgáltatását a felhasználó úgy érzékeli, mintha azt egy integrált eszköz szolgáltatta volna.”

21. Programrendszerek fejlesztése Határok – CAP tétel (Brewer tétele) • Internet méretű elosztott rendszerek • C – Konzisztencia (Minden csomópont ugyanazt az adatot látja adott időben) • A – Atomi • C - Konzisztens • I - Elkülönítés • D - Tartósság • A - Rendelkezésre állás (csomópontok kiesése nem akadályozza meg a maradókat a működéstől) • X % időben elérhető • P - Partíció tűrés (tetszőleges üzenetvesztést tolerál) • Gilber és Lynch definíciója szerint „A teljes rendszer (hálózat) hibáján kívül semmilyen hiba kombináció sem okozhatja azt, hogy a rendszer hibásan válaszol”. • Ezek közül csak kettő teljesülhet

22. Programrendszerek fejlesztése Nem partíció tűrő • Minden a tranzakció által érintett adat egy gépen van • Következmények: • Vertikális skálázás

23. Programrendszerek fejlesztése Nincs rendelkezésreállás • Partíció esetén megvárjuk míg megszűnik: megáll az élet • Adatbázis klaszterek, elosztott zárolási protkollok • Van ahol ez elkerülhetetlen: • Pl: Google bigtable zárolások -> Paxos szavazásos algoritumos

24. Programrendszerek fejlesztése Gyenge konzisztencia • Sok helyen az ACID nem kritikus • Erős konzisztencia – ACID • Inkonzisztencia-ablak • Nem a legfrissebb adat kerül visszaadásra • Végső fokon konzisztens • A rendszer mérete határozza meg az inkonzisztencia ablakot (replikák száma, a rendszer terhelése, hálózati késleltetés, stb.) • Ezt valósítja meg a BASE (BasicallyAvailableSoft-stateEventuallyconsistent) megközelítés (pl.: DNS)

25. Programrendszerek fejlesztése ACID vs BASE

26. Programrendszerek fejlesztése Architektúra típusok • Monolit • Tipikusan eljárás szintű struktúrálás • Objektum orientált • Objektum szintű struktúrálás • Skandináv vs. Amerikai iskola (domainmodel vs. újrahaszonosíthatóság) • Alap granularitás / rétegek építőelemei • Komponens orientált • Üzleti funkciók mentén több objektumot magába foglaló egységek. Nagyobb lépték. • Fontos, hogy hozott anyagból is jól tudjon dolgozni (ritka a zöldmezős beruházás) • Kritikus fontosságú a laza csatolás figyelembevétele (az OO-nál ez nem szempont) • Gyakran saját perzisztencia megoldással bírnak az egyes komponensek. • Szolgáltatás orientált • Futó kód az építőkő

27. Programrendszerek fejlesztése A határ • Interfész két modul között • P2P, … • Az alapvető határ: • Metódus/Függvény hívás • A szál átlépi a határt • A két oldal azonos címtérben van

28. Programrendszerek fejlesztése Más címtér • Mi van akkor ha ez nem igaz? • IPC/RPC, …. • Nem használhat referencia szerinti átadást • Mi van akkor, ha a memória egy része osztott? • Nem minden pointerre igaz ez • Szinkronizálni kell a kliens és a szerver között

29. Programrendszerek fejlesztése Megbízunk a másik oldalban? • Nincs bizalom? • Meg kell vizsgálni az argumentumokat • Nincs pointer átadás • A kernelekben ez meg van valósítva • A legtöbb rendszerben nincs • TCP • Web • ….

30. Programrendszerek fejlesztése Részleges hiba • Meghibásodhat a két rész függetlenül? • Új kivételek • Helyi erőforrások felszabadítása • Bérletek használata

31. Programrendszerek fejlesztése Kliens Muliplexelés • Nagyszámú konkurens hozzáférés • SLA – belépés vezérlés • Kliensek kiegyensúlyozott kezelése • Audit, számlázás • Kliens elkülönítés • Határ definíció

32. Programrendszerek fejlesztése Határ evolúció • Frissíthetjük-e a rendszereket egymástól függetlenül? • Verziók? • Protokoll frissítés? • Visszafelé kompatibilis?

33. Programrendszerek fejlesztése Protokoll vs. API • A protokoll szemlélet sikeresebb mint az API • Érték szerinti átadás • Hibákra is részben fel vannak készítve • Nem akarnak helyi hívásnak tűnni • Explicit állapotgép a hívás válasz helyett

34. Programrendszerek fejlesztése XML • Semmit sem old meg • Kiterjeszthető típusú RPC • Közös séma ami figyelmen kívül hagyható • Valós problémákat elfedheti

35. Programrendszerek fejlesztése Elosztott rendszer architektúrák • CS – Kliens szerver • P2P • N rétegű architektúra • Szorosan csatolt rendszer • Lazán csatolt rendszer (EDA) • Esemény • ESP • CEP • SBA (SpaceBaseArchitecture) (PU alapú) • Klaszter • Felhő • Rács • Elosztott Objektum

36. Programrendszerek fejlesztése Kliens - Szerver • Szerepkörök alapján határozza meg a rendszerben résztvevő entitások helyzetét. • A szerver oldal birtokolja az erőforrásokat, • Kliens oldal használja azokat. • Ezen elvek mentén működnek napjaink legnépeszerűbb protokolljai (HTTP, SMTP, DNS, stb.). • A megközelítés előnyei • könnyebb karbantarthatóság, és a központosítás miatt elvileg könyebb biztonságos rendszert készíteni. • Hátránya • a skálázhatóság és a robosztusság kérdése, mivel ez csak a szerver oldalon múlik.

37. Programrendszerek fejlesztése P2P • A kliens szerver architektúra ellentétje a P2P architektúra, ahol egyenrangú vagy nem egyenrangú, de az erőforrások megosztásában egyaránt részt vevő entitások alkotják a rendszert. • Skypevagy a legtöbb fájlcserélő protokoll ezen az elven működik. • A kliens-szerver megoldással szemben a hátránya a komplexitásában és elosztottságában rejlik, viszont cserébe extrém skálázhatóságot nyújt. • Típusai: • Elosztott kivonat tábla (pl.: Kademina) • Kicsi világ (pl.: Gnutella) • Szolgáltatás primitívek: • Store • Load • Search

38. Programrendszerek fejlesztése N-rétegű architektúra • Megjelenítés: a társ rendszer felé nyújt interfészt (gyakran ez a felhasználói interfész), és az ehhez kapcsolódó eseményeket kezeli le. Ennek a leggyakoribb megvalósítása a weboldal és az előállító logika. • Üzleti logika: ezen réteg feladata az üzleti folyamatok futtatása, hosszú életű tranzakciók kezelése. Itt kerül sor az adatok szélesebb hatókört, több adattípust átölelő szabályainak kikényszerítése is. • Perzisztencia: az adatok tartós tárolásával foglalkozik. Itt történik meg a szűkebb hatókörrel rendelkező adatszabályok kikényszerítése és gyakran az objektum és relációs adatmodellek közötti leképezés is.

39. Programrendszerek fejlesztése Szorosan csatolt rendszerek • A szorosan csatolt rendszerekben a komponensek (vagy ha ilyenek nincsenek, akkor az osztályok, objektumok) szinkron módon kommunikálnak egymással, szorosan követve a klasszikus függvényhívás szemantikáját. • Ebbe a kategóriába tartoznak a távoli eljárásokon alapuló rendszerek is. • A megközelítés előnye az, hogy a rendszer a klasszikus, egy processzen belül is megtalálható interkaciós paradigmákra épít, egyszerűvé téve ezzel a megvalósítást. • Ezzel a megoldással viszont nehéz robosztus, skálázható rendszereket létrehozni.

40. Programrendszerek fejlesztése Lazán csatolt rendszerek • Egyszerű események feldolgozása: ez esetben egy atomi esemény beérkezése indít el egy feldolgozási folyamatot. Egy példa erre a különböző felhasználói interakciókat támogató keretrendszerek eseménykezelése (pl. SWING JSF, stb.) • Eseményfolyamok feldolgozása(EventStreamProcessing – ESP): ezesetben eseményfolyamokat szűrnek egyszerű feltételek alapján, és az érdekes eseményekre feliratkozott vevőknek küldik ki a szűrt eseményeket. Példa lehet erre, amikor a naplózásnál csak adott szintet elérő eseményeket továbbítunk. • Komplex esemény feldolgozás (ComplexEventProcessing - CEP): ez esetben a valós idejű eseményfolyamon értékelünk ki olyan szabályokat, melyek figyelembe vehetik az események sorrendiségét, bekövetkeztét, számosságát és számos egyéb tulajdonságát. Erre a későbbiekben majd látunk példát a Drools-szal kapcsolatban.

41. Programrendszerek fejlesztése SBA rendszerek • Klaszter alapú (Cluster): a feldolgozásra koncentrál, az adattárolásra különböző tervezési minták vannak, a tipikusan olvasás jellegű alkalmazásoknál igen jó skálázódást tud elérni a CAP kompromisszumai nélkül. Le tudja kezelni az írási ütközést is. Példák erre a különböző alkalmazásszerverek által nyújtott klaszterezési lehetőségek (pl. JBossCluster) • Felhő alapú (Cloud): a CAP paradigma mentén a skálázható adattárolást is biztosítja, tipikusan a konzisztencia rovására. Példa erre a GoogleAppEngine. • Rács alapú (Grid): főleg a feldologzásra koncentrál, nincs igazán írási ütközés, így a feldolgozás tetszőlegesen párhuzamosítható. Ezt leginkább munkafolyamatok (Job) formájában szokták megtenni. • Elosztott objektum alapú (DistributedObjects): az eloszott objektumok gyakran a fenti architektúrák alapjait képezik. Ekkor egy-egy objektum vagy replikánsa (replikált objektum – replicatedobject) megjelenik azokon a helyeken, ahol használják, és a háttérben egy keretrendszer (köztes réteg) gondoskodik arról, hogy konzisztens maradjon, vagy pedig egy helyen van tárolva (élő objektum – liveobject), és azokon a helyszíneken, ahol szükséges megfelelő proxy objektumok képviselik az objektumot. A megosztott objektumok gyakran objektumterekbe (objectspaces) vannak szervezve, melyet valamilyen köztes réteg tart karban, virtualizál (pl. Java Spaces).

42. Programrendszerek fejlesztése SOA koncepció

43. Programrendszerek fejlesztése SOA háromszög

44. Programrendszerek fejlesztése WS világ

45. Programrendszerek fejlesztése Összefoglaló • Bevezető • Felmerülő problémák • Alkalmazás architektúrák • Elosztott rendszer architektúrák • SOA koncepció • Virtualizációs szintek • Összefoglaló

46. Programrendszerek fejlesztése A következő előadás tartalma • Kontextus • Biztonsági kontextus • Tranzakciós kontextus • Perzisztencia kontextus