Osztott rendszerek (Distributed

Osztott rendszerek (Distributed systems) Bevezetés Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 09. 18. Ficsor Lajos

osztottrendszerek / 1

Tartalom Miért kellenek osztott rendszerek Egy kis történelem Software architektúrák Osztott alkalmazások fejlesztése A midleware koncepció Nem objektum orientált midlewere-ek Objektum orientált midleware-ek

Ficsor Lajos

Osztott rendszerek (Bevezetés)


Miért kellenek osztott rendszerek? Feladatok elosztása A számítási teljesítmény növelése

Adatok (kódok) elosztása Desktop gépek használata duplikált (és inkonzisztens) adatok nélkül

A rendszer funkcionalitásának elosztása Komponensek Internet alapú alkalmazások

Ficsor Lajos



Történelem - a kezdetek Mainframe-ek és terminálok Minden a központi gépen fut A terminál csak egy periféria Minden a központi gépen múlik Csak osztott használat! Ficsor Lajos



Történelem - a következő lépés Klasszikus kliens/szerver architektúra Az adatok kezelése a szerver feladata Az alkalmazás logikájából adódó feladatok megoszlanak a kliens és a szerver között A felhasználói felület kezelése a kliens dolga Ficsor Lajos



(Majdnem) történelem: többrészes kliens/ szerver architektúra Multi-tier architecture Egy alkalmazás több részből állhat Tipikus: három rész Felhasználói interface Üzleti logika Adatbázis kezelés Ficsor Lajos



A jelen: valódi osztott rendszer Többrészes (multi-tier) architectúra Objektum orientált, komponens alapú megközelítés (object-oriented, component based approach) További szolgáltatások directory services tranzakció monitor

rugalmasság újrahasznosítható komponensek Egy komponens egyszerre lehet kliens és szerver internet - alapú alkalmazások Ficsor Lajos



A middleware koncepció Általános, alkalmazás független szolgáltatások Lehetővé teszi a felhasználó és az alkalmazás kommunikációját a hálózaton keresztül A hálózati és az alkalmazói program között helyezkedik el Ficsor Lajos

Applications MIDDLEWARE Network services

Local services

Operating system and hardware



Alkalmazás modellek

Computing models Terminal-host models

Distributed Computing Model

File transfer model

Ficsor Lajos

Client/Server model


Peer-to-Peer model


Alapvető kliens/szerver middleware-ek

Sockets

Ficsor Lajos


Socket s


A middleware-ek osztályozása 1. Egy szabvány nem elég, mert a különböző jellegű alkalmazások kommunikációs igénye eltérő A middleware-eket osztályozhatjuk abból a szempontból, hogy milyen más, ismert mechanizmus kiterjesztéseként tekintik a modulok közötti kommunikációt. (Milyen metaforát használnak.) A legalacsonyabb szintű middleware a socket mechanizmus. Ficsor Lajos



A middleware-ek osztályozása 2. A kommunikáció metafórája File-kezelés

Middleware-ek

Távoli eljáráshívás

RPC, DCE RPC, XML RPC, SOAP RDA

Adatbázis lekérdezés Üzenet küldés Távoli metódushívás Ficsor Lajos

Socket

MOM CORBA, Java RMI, Microsoft DCOM Osztott rendszerek (Bevezetés)


Socket mechanizmus A metafora a file kezelés Valójában egy API a TCP/IP protokoll verem szolgáltatásaihoz (TCP és UDP) Alkalmas nagyon speciális alkalmazásokhoz (Mindent megtehetek) (I can do everything) Nem alkalmas nagy, bonyolult rendszerek fejlesztésére (Mindent nekem kell megcsinálnom) (I must do everything) Ficsor Lajos



Socket mechanizmus (folyt.) Valójában egy csatornára byte-sorozat tehető ki ("write") és onnan byte sorozat olvasható be ("read"). Nem biztosított, hogy a csatornára kitett információt valaki el is olvassa => valamilyen protokollal össze kell hangolni a kommunikáló feleket. Gyakorlatilag minden plattformra és programozási nyelvhez van implementációja. Ficsor Lajos



Socket mechanizmus (folyt.) A kommunikáló felek futhatnak különböző plattformokon és készülhetnek különböző programozási nyelveken. Számos magasabb szintű middleware implementációs eszköze.

Ficsor Lajos



Távoli eljáráshívás (RPC) RPC: Remote Procedude Call Teljesen homogén rendszereken futó alkalmazások közötti komunikációra lett tervezve: azonos processzor UNIX operációs rendszer C-ben írt programok

Ma már közvetlenül ritkán használt middleware, de egy alapötlet, ami a korszerűbb middleware-ek is alkalmaznak, már itt megjelenik. Ficsor Lajos



Távoli eljáráshívás (folyt.)

Ficsor Lajos



Távoli eljáráshívás (folyt.) 1. A kliens meghívja a csonkeljárást (stub), ami lokális függvénynek látszik. A stub a paramétereket a hálózaton átvihető csomagokba pakolja és meghatározza a szerver címét 2. Az üzenet átvitelre kerül a hálózati átviteli szolgáltatáson (network transport service) keresztül 3. Az üzenet átvitelre kerül a hálózaton és a szerver gép hálózati rétege fogadja Ficsor Lajos



Távoli eljáráshívás (folyt.) 4. A hálózati szolgáltatás értesíti a szerver csonkot hogy egy kérés érkezett 5. A szerver csonk fogadja az üzenetet, lefordítja a lokális eljáráshívás formátumára és meghívja az eljárást 6. A szerver végrehajtja az eljárást és visszaadja az eredményt a csonknak 7. A csonk a választ átalakítja hálózati üzenetté és elküldi a hálózati rétegnek Ficsor Lajos



Távoli eljáráshívás (folyt.) 8. A szerver hálózati rétege visszaküldi a választ a kliens hálózati rétegének 9. A kliens hálózati rétege elküldi a választ a kliens csonknak 10. A kliens csonk fogadja a választ, átalakítja eljárás visszatérési értékének és átadja a kliensnek

Ficsor Lajos



Távoli eljáráshívás (folyt.) Megjegyzések: A csonkeljárások automatikusan generálhatók A paraméterek érték szerint adódnak át (különböző címterek!) Kötés (binding) problémája: hogyan található meg a szervert futtató gép, és a szerver program a gépen belül Az adatábrázolási módok különbözőek lehetnek A kliens és a szerver gép egymástól függetlenül összeomolhat A kliens általában lockolódik és vár a válaszra Ficsor Lajos



Távoli eljáráshívás (folyt.) Hasznos ötletek: kliens oldali csonk (stub) egy funkcionális interface-t mutat a kliens programnak, de valójában a funkciókat egy middleware szolgáltatásait igénybe véve mással (egy remote szolgáltatóval) végezteti el. Kommunikál a szerver oldali csonkkal.

Ficsor Lajos



Távoli eljáráshívás (folyt.) Szerver oldali csonk kéréseket fogad, aktivizálja a remote szolgáltatót, és átveszi tőle az eredményeket. A kliens oldali stub-al kommunikál. Szokásos elnevezése még: skeleton, proxy

Remote szolgáltató Funkcionális interface-e egyezik a kliens stub-éval, és ténylegesen implementálja is azt. Önmagában nem futásképes elem, a szerver oldali stub aktivizálja. Ficsor Lajos



Distributed Computing Environment (DCE) Open Software Foundation (OSF): célja a UNIX rendszerek közötti együttműködés biztosítása DCE: nyílt szabvány az osztott alkalmazásokhoz DCE: implementáció, nem specifikáció. A legfontosabb korlátozás: az adatbázis műveletek gyenge támogatása Sohasem nyert széleskörű támogatást, de bizonyos elemei beépültek a CORBA-ba és a DCOM-ba (IDL, marshalling) Ficsor Lajos



A DCE architektúrája Applications S e c u r i t y

Diskless Support Future Disk. Serv.

Distributed File Services Distributed Time Services

Directory Services

Future Basic Services

RPC

M a n a g e m e n t

Threads Operating Systems and Transport Services Ficsor Lajos



DCE RPC A megjelenítési szolgáltatás (Presentation service) elrejti a belső adatábrázolás különbözőségét Hálózat és protokoll független Biztonságos RPC kommunikáció Autentikáció Integritás Megszemélyesítés (privacy)

Szerver azonosítás név szerint Tetszőleges argumentum méret Ficsor Lajos



XML RPC A klaszikus RPC "újraélesztése" Távoli eljáráshívást valósít meg, de az "eljárás" tetszőleges szolgáltató egység lehet, ami implementálja az adott interface-t. A hagyományos RPC-vel ellentétben HTTP protokoll felett zajlik a kommunikáció. Az adatokat a hagyományos RPC-vel ellentétben XML formátumban küldi át a hálózaton. Miután szabványos, platform és implementációs eszköz független. Ficsor Osztott rendszerek (Bevezetés) osztottrendszerek / 27 Lajos

XML RPC (folyt.) Az XML RPC HTTP POST metódus segítségével XML-be kódolt kérést küld a szervernek. A szerver elemzi a kérést, meghívja a megfelelő metódust, a választ pedig XML-be kódolva visszaküldi. A kliens kikódolja a választ. Az XML RPC támogatja az "ésszerű" adatformátumokat (int, double, string, bináris adathalmaz, struktúra, tömb, egyebek) Ficsor Lajos



SOAP Simple Object Access Protocol UserLand, Developmentor és Microsoft együttműködés terméke Jelenleg a W3C felügyeli ezt a szabványt Jóval összetettebb, mint az XML RPC Komplex adatstruktúrák támogatása Az XML namespacek használata globálisan egyértelművé teszi az átvitt adatot Ficsor Lajos



Előnyök és hátrányok Az XML RPC és a SOAP nagy előnye, hogy könnyen átmegy a tűzfalakon Az XML RPC és a SOAP nagy hátránya, hogy könnyen átmegy a tűzfalakon Jóval nagyobb erőforrás igényűek, mint a hagyományos RPC

Ficsor Lajos



Távoli adatelérés (RDA) A kliens kiad egy SQL hívást a kliens middlewarenek Az üzenet átmegy a hálózaton keresztül a szerverig A szerver middleware-e meghívja az adatbázis szervert Az adatbázis szerver végrehajtja a lekérdezést és visszaküldi az eredményt a szerver middlewareének A szerver middleware átalakítja az eredményt hálózati üzenetté és elküldi a kliensnek a hálózaton keresztül A kliens middleware fogadja az üzenetet, átalakítja és átadja az eredményt a kliensnek Ficsor Lajos



Üzenet-orientált middleware (MOM)

Ficsor Lajos



A MOM tulajdonságai Lehetővé teszi az aszinkron kommunikációt Alkalmas mobil (vezeték nélküli) kommunikációra A szerver hibája nem állítja meg a klienst Alkalmas nagyon nagy várakozó sorok kezelésére is Korlát: a várokozó sorok írásának/olvasásának többletterhelése Ficsor Lajos



Osztott rendszerek (Distributed

Recommend Documents