P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely

Save this PDF as:
 WORD  PNG  TXT  JPG

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely sipos@sztaki."

Átírás

1 P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához Rendszerterv Sipos Gergely Lovas Róbert MTA SZTAKI, 2003

2 Tartalomjegyzék 1. Bevezetés Jini alapú Grid rendszer A Grid célja és felépítése A Jini-szemlélet Egy dzsinn m ködése A Sun Jini-implementációja A Jini, mint a Grid alap-infrastruktúrája Párhuzamos PVM programok végrehajtása A végrehajtás párhuzamosítása Programok futtatása a helyi PVM-démon felhasználásával PVM programok futtatása Condorral A Condor, mint er forrásmenedzser A PVM és a Condor szerepe a Gridben PVM alkalmazások végrehajtása Jini alapon A Jini használata A rendszer követelményei Jini alapon Egy PVM-program futtatásának forgatókönyve A szolgáltatás használata A szolgáltató program megtervezése A P-GRADE és a Jini-Grid integrálása Párhuzamos PVM programok monitorozása A monitorozás célja Helyi hálózatban futó PVM-program monitorozása PVM-programok monitorozása Jini alapú Gridben...38 Glosszárium...41 Hivatkozások jegyzéke...43

3 1. Bevezetés A közös projekt egyik célja, hogy a szuperszámítógépeken és klasztereken rendkívül hatékonyan futó párhuzamos kódot egységbe zárva létrehozzunk egy új lehet ségeket nyújtó szolgáltatatást; egy interfész modult az MTA SZTAKI által kifejlesztett P-GRADE programozási környezet és a Veszprémi Egyetem által fejlesztett Jini alapú Grid közé. Az újonnan létrejöv interfész modul segítségével a felhasználó egyszer en készíthet egy csomagot a meglév párhuzamos alkalmazásából, megadva a futtatáshoz szükséges rendszerkövetelményeket, illetve a kimeneti/bemeneti adatokhoz és az ellen rz ponthoz tartozó állományokat. Ezek után a felhasználó az interfészen keresztül a Jini alapú Grid segítségével kereshet a Grid-ben a megadott rendszerkövetelményeknek eleget tév és a P-GRADE rendszerben fejlesztett PVM (MPI) programok futtatását felkínáló szolgáltatást. A következ lépcs ben az interfész egy speciális szolgáltatása eljuttatja a kiválasztott szolgáltatóhoz a párhuzamos alkalmazást tartalmazó csomagot a bemeneti adatokkal együtt, majd eredeti állapotába visszaállítja az alkalmazást, és lefuttatja a klaszteren vagy szuperszámítógépen, végül a megadott eredményfájlokat (megszakított futás esetén az ellen rz pont fájlt) visszajuttatja a felhasználóhoz, esetleg elvégzi az esetleges utómunkálatokat. A fenti mechanizmus segítségével kiaknázhatjuk a szuperszámítógépen vagy klaszteren a natív kód és a rendkívül hatékony (gyártók által támogatott) üzenetközvetít könyvtárak el nyeit, de a Jini alapú Grid tenné lehet vé, hogy az alkalmazásunk futtatásához megfelel (kihasználatlan) er forrásokat fedezzünk fel és használhassuk távolról a Grid-ben. Az interfész modul még felel s lenne a fejleszt környezet többi eszközének (pl. monitorozó) távoli moduljainak elindításáért, valamint a távoli modulok és a felhasználó oldalán lokálisan futó fejleszt környezet közötti kapcsolattartásért mind on-line monitorozás során, mind az elosztott hibakeresés fázisában. A rendszerterv els két fejezetében az illesztend infrastruktúrák; a Jini alapú Grid rendszer, valamint a klasztereken használatos PVM és Condor által támasztott követelményeket vizsgáljuk meg, melyek az interfész modul tervezésében a legfontosabb szerepet kapták. A követelmények ismeretében a következ két fejezetben két egymásra épül tervezési fázisban megoldást adunk a PVM alkalmazások végrehajtása a Jini által adott szolgáltatások kihasználása mellett, majd egy szinttel feljebb lépve a P-GRADE és a Jini alapú Grid illesztésére. Végül külön fejezet foglalkozik a Jini alapú Gridben történ P- GRADE/PVM alkalmazások megfigyelésének témakörével.

4 2. Jini alapú Grid rendszer 2.1 A Grid célja és felépítése A számítógépklaszter helyi hálózattal összekötött munkaállomásból áll, és els sorban párhuzamos programok futtatására használják [7]. Ha mások rendelkezésére is bocsátják a számítógépes kapacitásokat, akkor létrejön a Grid, a számítógép-kapacitások világhálózata, melyet önálló PC-k, szuperszámítógépek, és számítógépklaszterek alkotnak [4]. A Gridben tehát a jelenlegi Internettel szemben nem az információ-megosztás, hanem a hardverkapacitás-megosztás az els dleges cél. A Grid tényleges használatához szükség van valamilyen infrastruktúrára, melynek segítségével mindenki értesülhet a többiek által felkínált er forrásokról, és ami lehet vé teszi a felhasználók számára a nekik szükséges kapacitások igénybevételét. Az infrastruktúra f feladata hogy összekösse a Gridet alkotó er forrásokat, és a Gridben programot futtatni kívánó kliensek gépeit. Szerepe az 1. ábrán látható módon képzelhet el. Er forrás Er forrás Kliens gép Er forrás Gridinfrastruktúra... Kliens gép Kliens gép Er forrás 1. ábra: Az infrastruktúra szerepe a Gridben Ez az infrastruktúra a Grid alapszolgáltatásaként fogható fel, melynek minimálisan az alábbi funkciókat kell biztosítania: Csatlakozási lehet séget a Gridhez, keresési lehet séget az er források között. Az els szolgáltatás igénybevételével a hálózat bármely er forrása csatlakozhat a felajánlókhoz. A szolgáltatást úgy kell implementálni, hogy ha egy csatlakozni kívánó er forrás végrehajtja a csatlakozási protokoll szerint rá háruló feladatokat, akkor biztos lehessen benne, hogy része lett a Gridnek, és el bb-utóbb valaki majd igénybe veszi a

5 kapacitását, legyen egy önálló Linux-os PC, egy MS Windows 2000-es munkaállomásokat tartalmazó klaszter, vagy akár egy Cray szuperszámítógép. A másik feladat: megoldani hogy azok, akik igénybe kívánnak venni valamilyen grides er forrást, megtalálják az igényeiket kielégít rendszereket. A keresés eredményeként kapott adathalmaznak tartalmaznia kell az igényeknek megfelel er forrásokkal való kapcsolatfelvételhez szükséges információkat. Az információk alapján az er forrás bérbeadójával a kapcsolat felvehet, a bérbeadás feltételei megtárgyalhatók, majd az er forrás használatba vehet. Mindkét szolgáltatást úgy kell megvalósítani, hogy az igényl eszközök akár emberi közrem ködés nélkül is használatba vehessék azokat. A szolgáltatás igénybevételi folyamata mindkét esetben jól algoritmizálható, pontosan definiált lépésekb l kell hogy álljon. Ha az Interneten ez a két szolgáltatás ilyen formában megvalósul, akkor tényleg létrejön a Grid. De az említett két szolgáltatás nem teljesen független egymástól. A köztük fennálló kapcsolatot az a nyilvántartás adja, amelybe be vannak jegyezve a Gridet alkotó er források. A Gridbe kapcsolódáskor ebbe kerül bejegyzésre az er forrás, és ez képezi az er forrás-keresés alapját. A Grid-infrastruktúra létrehozása során ennek a nyilvántartásnak a kialakítása a legnehezebb feladat. A nyilvántartásban szerepelnie kell annak, hogy milyen er források vesznek részt a Gridben, és hogy azokkal milyen módon vehet fel a kapcsolat. A nyilvántartást elosztott módon kell megvalósítani, hiszen könnyen belátható, hogy egy központosított nyilvántartó-rendszer adná a Grid sz k keresztmetszetét rendkívül lerontva annak használhatóságát egy esetleges leállással pedig ellehetetlenítené a teljes Gridet. Használhatóságát nagyban befolyásolja a naprakészsége, vagyis hogy milyen frissek a bejegyzett információk. A valóságnak teljes egészében megfelel nyilvántartás az információk terjedésének véges sebessége, és az el re nem látható hardver- és szoftverhibák miatt elméletileg sem lehetséges, de törekedni kell a valóságnak leginkább megfelel nyilvántartás létrehozására. Ezt a nyilvántartó szolgáltatást azért érdemes megkülönböztetni az el bb felsorolt kett t l, mert míg azok a hálózatot alkotó minden gép számára látható, általuk közvetlenül igénybe vehet szolgáltatások, addig a nyilvántartás a többség el l rejtve marad, ahhoz csak az említett két szolgáltatást megvalósító komponensek férhetnek hozzá. Összegezve az eddig leírtakat elmondható, hogy a Grid infrastruktúráját olyan szolgáltatók, és a velük való kommunikációt lehet vé tev protokollok alkotják, melyek a hálózat gépei által ismertek, és melyek használatára algoritmus adható. 2.2 A Jini-szemlélet Egy hálózatban a grid-alapszolgáltatásokat megvalósítani képes egyik infrastruktúra a Sun Microsystems által kifejlesztett Jini. A cél, amiért a Jini-t létrehozták: lehet vé tenni egy dinamikusan változó hálózati környezetben mint amilyen a Grid a hálózatot alkotó komponensek egymásnak történ szolgáltatásnyújtását [13]. Az eddigiekhez képest a legfontosabb szemlélet-beli különbség, hogy a Jini a hálózatot alkotó komponenseket nem mint er forrás-felajánlókat és er forrás-igényl! ket, hanem mint szolgáltatókat és szolgáltatás-igényl" ket tekinti. Ez a megközelítési mód azonban sokkal általánosabb az eddiginél. Egyrészt azért, mert amir# l eddig szó volt, hogy egy számítástechnikai eszköz egy PC, egy klaszter, vagy egy szuperszámítógép felkínálja másoknak a számítási kapacitását, azzal tulajdonképpen azt a szolgáltatását teszi bárki számára elérhet$ vé, melyet az adott fizikai eszköz legáltalánosabb értelemben nyújtani képes: programok

6 futtatása. De ha az eszköz tulajdonosa nem szeretné, hogy mások programokat futtassanak nála, a hardver-kapacitást még mindig felkínálhatja a többiek számára. Nyújthat például fájl tárolási lehet séget, SMS-küld szolgáltatást, vagy számológép funkciót. Ezek a szolgáltatások ugyanúgy kihasználják majd az eszköz képességeit, viszont kizárólag a tulajdonos programjai, és nem idegen programok futnak majd a gépen. A lényeg tehát, hogy a bérl knek a számítástechnikai eszköz sokkal speciálisabb szolgáltatást nyújthat, mint a programfuttatás. Az ilyen többletfunkciók eléréséhez azonban a tulajdonosának megfelel szoftvereket kell a rendszerre telepítenie, miel tt azt a Gridbe csatlakoztatná. Eddig a Grid, mint számítástechnikai eszközök, számítógépek hálózata volt. A Jini olyen irányban is kib víti a Gridet, hogy a segítségével létrehozott hálózatba amit dzsinnek hívnak olyan eszközök is bekapcsolódjanak, melyeknek a hagyományos értelemben vett informatikai eszközökt l távol állnak. Egy dzsinnek része lehet például egy kávéf z, egy mobiltelefon vagy akár egy gépkocsi is. Az egyedüli kikötés minden eszközzel szemben, hogy a Jini specifikációban definiált protokollokat képes legyen a gyakorlatban megvalósítani. Ez leegyszer sítve annyit jelent, hogy minden eszköznek rendelkeznie kell egy olyan számítógépegységgel, amely programok futtatására képes, és ezek a programok vezérelni tudják az eszköz fizikai m ködését [14]. A Jini tehát a hálózatot szolgáltatás-nyújtó, és szolgáltatás-felhasználó eszközök halmazának tekinti. A két csoport tagjai ilyen egyszer en azonban nem különíthet k el egymástól: egy szolgáltató maga is lehet egy másik szolgáltatás felhasználója. A Jini-szemlélettel kapcsolatban a legfontosabb kérdés, hogy hogyan biztosítja a hálózat számára a grid-alapszolgáltatásokat? A két alapszolgáltatás az új szemlélet szerint: szolgáltatás-bejegyzés és szolgáltatás-keresés. A m ködésükhöz itt is nélkülözhetetlen egy harmadik, a szolgáltatások nyilvántartása. A Jini-ben ezt a három szolgáltatást együttesen lookup szolgáltatásnak hívják. A lookup szolgáltatás a Jini infrastruktúra metaszolgáltatása: egyrészt ugyanúgy szolgáltatásként kezelhet, másrészt viszont a feladata nem egy valóságos, a dzsinn létezése nélkül is fennálló szükséglet kielégítése, hanem magának a dzsinnek az üzemeltetése. Ha egy hálózatban lookup szolgáltatást nyújtó eszköz nem létezik, akkor az a hálózat nem dzsinn. A lookup szolgáltatást nyújtó eszköz feladatai a következ k: Nyilvántartani a mindenkori dzsinnben résztvev szolgáltatásokat, és a hozzájuk kapcsolódó információkat. Lehet vé tenni további szolgáltatások csatlakozását a dzsinnhez. Keresési lehet séget biztosítani a nyilvántartásban azon eszközök számára, amelyek nem szolgáltatni akarnak, hanem valamilyen szolgáltatást igényelnek. Ezt a lookup szolgáltatást a dzsinnben bármilyen eszköz elláthatja, amelyik teljesíti a specifikált protokolloknak megfelel m ködést. Bárki írhat olyan programot, melynek segítségével a számítógépe lookup szolgáltatóvá válik, vagy készíthet egy olyan hardvereszközt, amely fizikai felépítésével teljesíti a protokolloknak megfelel m ködést. Miután egy ilyen eszközt a hálózatba kapcsol annak tulajdonosa, akkor nincs más feladat, mint várni, hogy a különféle eszközök beregisztrálják nála a szolgáltatásaikat. Bizonyos id elteltével a dzsinn a 2. ábrán látható módon néz majd ki.

7 Felhasználó Szolgáltató 1 Szolgáltató 2 Szolgáltató 3 Felhasználó A hálózat fizikai megvalósítása LOOKUP SZOLGÁLTATÓ Szolgáltatás 1 Szolgáltatás 2 Szolgáltatás 3 Információ 1 Információ 2 Információ 3 A dzsinn aktuális határa Felhasználó A dzsinn aktuális határa folyamatosan változik az id ben. A határon belül lesznek azok az eszközök, amelyek az adott pillanatban valamilyen szolgáltatást nyújtanak, a határon kívül pedig azok, melyek nem. A dzsinn tagjainak szolgáltatásait viszont mind a határon kívül, mind a határon belül tartózkodók egyaránt igénybe vehetik. Egy globális méret Jini alapú Grid létrehozásakor egyetlen lookup szolgáltató nem lehet megoldás, a nyilvántartást elosztottá kell tenni, ahogy ezt a Veszprémi Egyetem által fejlesztett megoldásban is megtalálható. 2.3 Egy dzsinn működése 2. ábra: Egy dzsinn felépítése Egy hálózatban attól kezdve létezik dzsinn, hogy a hálózat egy eszköze lookup szolgáltatást kezd nyújtani. A lookup szolgáltatást igénybe véve a hálózat eszközei egyrészt regisztrálhatják a szolgáltatásukat ezzel növelve a dzsinn méretét másrészt megszerezhetik a számukra fontos szolgáltatásokat nyújtó eszközök címeit. Ennek birtokában a szolgáltató eszközzel a kapcsolat felvehet, a szolgáltatás igénybevétele megkezdhet. A Jini-ben a lookup szolgáltató megtalálását discovery-nek hívják. Három különböz protokoll szerint történhet [16]: unicast discovery multicast request multicast announcement Az els mód feltételezi, hogy az eszköz, amelyik a lookup szolgáltatást igénybe akarja venni, ismeri a lookup szolgáltatást nyújtó eszköz hálózati címét, és a szolgáltatás portszámát. Ilyenkor el re kell tudni, hogy az információt tartalmazó oldal milyen IP címmel rendelkez számítógépen található, és annak melyik portjára küldhet a kérés. A szolgáltató gépen folyamatosan fut egy program, amelyik a bejöv kérésekre figyel. A multicast request protokoll csak a helyi hálózatban található lookup szolgáltatók megtalálását teszi lehet vé. A lényege, hogy a keresést végz eszköz multicast üzenetet ad ki, melyben a küldés célja lookup szolgáltató megtalálása és a küld vel való kapcsolatfelvételhez szükséges cím szerepel. A lookup szolgáltatók az üzenet kézhezvétele után válaszolnak a velük való kapcsolatfelvételhez szükséges

8 információval, míg a többiek egyszer en eldobják a kapott csomagot. A keresést kezdeményez eszköz ezek után az unicast discovery forgatókönyve szerint felveheti a kapcsolatot a lookup szolgáltatókkal. A harmadik módszer lookup szolgáltatás megtalálására a multicast announcement protokoll. Ez az el z höz hasonlóan szintén csak a helyi hálózaton m köd lookup szolgáltatók elérésére használható. A m ködés, ugyanúgy mint az el bb, most is multicast üzenetek küldésén alapszik, de jelen esetben a szerepek fordítottak: nem a lookup szolgáltatást igényl, hanem a lookup szolgáltatást nyújtó a kezdeményez. Bizonyos meghatározott s r séggel a lookup szolgáltató eszköz multicast üzenetet küldhet, melyben reklámozza saját magát. (A Sun Microsystems ingyenesen elérhet lookup-programja ezt például 120 mp-enként teszi.) Az üzenetben jelzi, hogy milyen hálózati címen és milyen porton keresztül vehet igénybe a szolgáltatása. A szolgáltatást igényl eszköznek csak meg kell várnia hogy eljusson hozzá egy ilyen üzenet, azután unicast discovery segítségével a kapott információkat felhasználva megtalálhatja a szolgáltatót A Jini szemlélete szerint a grid-alapszolgáltatások is ugyanolyan szolgáltatásnak tekinthet k, mint a Gridben elérhet többi szolgáltatás, emiatt a lookup szolgáltatás igénybevétele is ugyanúgy zajlik, mint egy dzsinn bármilyen más szolgáltatásáé. A Jiniben minden szolgáltatás-igénybevétel a szolgáltató eszközön és az igénybevev eszközön futó programok között zajló kérés-akció-válasz formájában megy végbe. Az igényl - eszközön futó program azonban nem közvetlenül a szolgáltató eszközön futó programhoz, hanem egy úgynevezett proxy-hoz intézi a kéréseit (1). A proxy továbbítja a kérést a szolgáltató eszközön futó programnak (2), amely a kérés hatására utasítja a fizikai eszközt valamilyen akció végrehajtására (3). Az akció befejeztével a szolgáltató eszköz programja a proxy közrem ködésével visszaküld egy választ a kliens eszköz programjának (4, 5). A folyamat a 4. ábrán látható: Szolgáltatást igényl eszköz Memória Szolgáltató eszköz Memória Igényl program 1 5 Szolgáltatás proxy 2 4 Szolgáltató program 3 3. ábra: Egy szolgáltatás igénybevételének folyamata A proxy a szolgáltató által készített olyan program, amely tudja, hogy hol található a szolgáltatást végz eszköz, és hogy a szolgáltató programnak milyen kéréseket kell küldenie ahhoz, hogy a kért akció végrehajtódjon. Egy szolgáltatás proxy-ja a szolgáltatás dzsinnbe való bekapcsolódásakor a lookup szolgáltatónál kerül letárolásra, mint az egyik, a szolgáltatást jellemz információ. Amikor tehát egy eszköz a dzsinnben valamilyen szolgáltatást keres, akkor számára a szolgáltatáshoz tartozó proxy-nak a megszerzése a cél. Egy szolgáltatás igénybevételének teljes folyamata az alábbi módon zajlik: az igényl eszköz memóriájában futó program valamelyik discovery módszert követve megszerzi a lookup szolgáltató proxy-ját. A proxy-t eltárolja a memóriájában, majd a segítségével a lookup szolgáltató által nyújtott szolgáltatáskeres szolgáltatás

9 igénybevételét kéri. A proxy-hoz intézett kérés tartalmazza mindazokat a feltételeket, melyeknek az igényelt szolgáltatás meg kell hogy feleljen. A proxy továbbítja a kérést a lookup szolgáltatónak, ami ennek hatására megnézi, hogy van-e a nála bejegyzett szolgáltatások között a feltételeknek megfelel. Ha van, akkor eredményként visszaküldi az összes ilyen szolgáltatáshoz tartozó proxy-t, ha nincs, akkor értesíti az igényl t a keresés sikertelenségér l. Sikeres keresés esetén a szolgáltatást igényl eszköz a kapott proxy-k közül bármelyikhez intézheti a kéréseit, mivel a megkapott proxy-k ugyanolyan funkcionalitással rendelkez szolgáltatásokhoz tartoznak. A következ fontos kérdés, ami a Jini nyilvántartó-rendszerével kapcsolatban felmerülhet, a bejegyzések törlése. Ha a dzsinn egy tagja a továbbiakban már nem kíván a többieknek szolgáltatást nyújtani, akkor az általa eddig nyújtott funkcióhoz tartozó információkat a lookup szolgáltató nyilvántartásából törölni kell. Egyszer eset, ha az eszköz önként hagyja el a dzsinnt, mert ilyenkor a törlést maga kezdeményezheti. Ha azonban a szolgáltatásnyújtás megsz nése el re nem látható hardver-, vagy szoftverhiba miatt lép fel, az eszközre vonatkozó bejegyzés törlésére akkor is szükség van. Az ilyen, el re nem látható események nagyban megnehezítik egy valóságh nyilvántartás létrehozását. A Jini ezt a problémát a lízing fogalmának a bevezetésével oldja meg: általában minden szolgáltatást annak igénybevev je a szolgáltatás megkezdését l számítva csak egy adott ideig használhat. Az engedélyezett használati id a lízing hossza a használat megkezdésekor kerül megállapításra. A lízing lejártakor a lízingel kérheti a használati id meghosszabbítását, de ha ezt nem teszi, akkor a szolgáltató beszünteti a számára nyújtott tényleges szolgáltató tevékenységét. A lookup szolgáltatás igénybevétele is ilyen minta szerint m ködik. Amikor egy lookup szolgáltató egy szolgáltatás nyilvántartásba vételét vállalja, azt csak egy meghatározott id re teszi. Ha az id lejárta el tt a szolgáltatást nyújtó eszköz nem kéri a lízing meghosszabbítását, a lookup szolgáltató törli a nyilvántartásából. Mivel a meghibásodott eszközök nem képesek a lízing meghosszabbítására, bejegyzésük törl dni fog a dzsinnb l. Minél rövidebb id re lízingelhet tehát egy lookup szolgáltató nyilvántartásba-vételt megvalósító szolgáltatása, annál valóságh bb lesz a nyilvántartás. 2.4 A Sun Jini-implementációja A Sun Microsystems kínál egy Jini implementációt, amely az eddig leírtaknak megfelel en m ködik, és kizárólag Java technológiákat használ. Az implementáció használatával egy IP protokollra épül hálózaton Jini alapú grid-rendszer hozható létre. A követelmény a hálózatba kapcsolt eszközökkel szemben, hogy mindegyik rendelkezzen Java Virtuális Géppel (a továbbiakban JVM), egyedi IP címmel, továbbá képes legyen unicast TCP és multicast UDP üzenetek küldésére. Ezeken kívül mivel az implementáció er sen épít a Java RMI technológiára az eszközökkel szemben támasztott további követelmény, hogy képesek legyenek Java objektumok idegen JVM-be történ exportálására. Ennek a feltételnek legegyszer bben megfelel! en konfigurált HTTP szerverprogram használatával felelhet meg egy eszköz. Az implementációval létrehozott dzsinnben Java programok kommunikálnak közvetlenül egymással, és közvetve az " ket futtató eszközzel. A dzsinn egy részlete az 4. ábrán látható módon képzelhet# el.

10 Unicast TCP és multicast UDP csomagok Java program JVM Java program Java program JVM Fizikai eszköz JVM Fizikai eszköz Fizikai eszköz 4. ábra: A Sun implementációja szerint m köd Dzsinn Az implementáció részei: Az összes szükséges, továbbá néhány hasznos Jini szolgáltatást megvalósító Java program. (például Lookup szolgáltató program) Egy Jini API (Java osztály- és interfész-gy jtemény), melynek segítségével Jini szolgáltatásokat használni képes kliensprogramok illetve tetsz leges szolgáltatásokat megvalósító szerverprogramok készíthet k. Olyan programok, melyek használata nem kötelez, de az infrastruktúra igénybevételekor rájuk, vagy hasonló funkcionalitású programokra gyakran szükség lehet. (például HTTP szerverprogram) Mint már említettem, az implementáció er sen épít a Java RMI-re. Ez azt jelenti, hogy az RMI technológiát használja minden olyan esetben, amikor JVM-ek között Java objektumok mozgatására van szükség. Ilyen el fordulhat például két eszköz kommunikációja során, de a leggyakoribb ilyen eset, amikor szolgáltatásokhoz tartozó információkat kell átvinni egyik eszközr l a másikra. Minden szolgáltatást egy rá egyedileg jellemz objektum azonosít. Az ilyen objektumok mind a szolgáltató eszközök és a lookup szolgáltatók, mind a lookup szolgáltatók és a szolgáltatást igényl k között RMI segítségével kerülnek átvitelre. Ez az objektum tartalmazza egyrészt a szolgáltatáshoz tartozó proxy-t, másrészt az úgynevezett attribútumokat, harmadrészt pedig egy egyedi szolgáltatás-azonosítót. A proxy-t és az attribútumokat a szolgáltatást nyújtó eszköz készíti el. Az el bbi feladata a szolgáltatás igénybevételének lehet vé tétele, míg utóbbi a szolgáltatáshoz logikailag vagy fizikailag rendelhet paraméterek halmaza, melyek célja a szolgáltatás funkcionális jellemzése. Ilyen paraméter lehet egy nyomtató szolgáltatásnál például a nyomtató helye, vagy a nyomtatáshoz használható lap mérete. A Jini-szolgatatásokhoz tartozó harmadik paramétert az azonosítót ellenben nem a szolgáltató eszköz, hanem az a lookup

11 szolgáltató generálja, amelyiknél a szolgáltatás el ször kérte regisztrációját. Ennek az azonosítónak a célja, hogy a szolgáltatását globálisan -nem csak az adott dzsinnen belülegyedivé tegye. Minden eszköz számára ajánlatos ezt az els regisztráció során kapott azonosítót eltárolnia, és minden kés bbi regisztráláshoz ugyanezt használnia. Egy szolgáltató dzsinnbe való bekapcsolódásakor tehát ezt a három információt magába záró objektum kerül a dzsinn lookup szolgáltatójánál letárolásra. Azok az eszközök, melyek egy szolgáltatást igénybe szeretnének venni, el ször el kell hogy küldjék a lookup szolgáltatóhoz mindazokat a feltételeket, melyeknek a keresett szolgáltatás meg kell hogy feleljen. Ezután a lookup szolgáltató elvégzi a kritériumok és a nála tárolt objektumok összevetését, és amelyik megfelel a kikötéseknek, azt visszaküldi az igényl nek. Az igényl a kapott objektumban található proxy segítségével ezután kéréseket intézhet a szolgáltatóhoz a korábban említett módon. A szolgáltatás-regisztrálás és szolgáltatás-keresés folyamatát a 5. ábra mutatja. Lookup szolgáltató 2 Igényl Proxy 3 1 Szolgáltató Proxy Attribútumok Attribútumok Azonosító A szolgáltatást jellemz objektum Azonosító 5. ábra: Egy szolgáltatás-objektum megszerzésének folyamata A folyamat lépései: 1. A szolgáltatás regisztrálása. A szolgáltatást jellemz objektum RMI hívás paramétereként kerül át a lookup szolgáltatóhoz. 2. Szolgáltatás-keresés. A keresett szolgáltatással kapcsolatos kritériumok RMI hívás paramétereként kerülnek átadásra. 3. A megfelel szolgáltatás(ok)hoz tartozó objektum(ok) átküldése az el z RMI hívás visszatérési értékeként. Egy szolgáltatás megkeresésekor a lookup szolgáltatónak átadásra kerül kritériumok vonatkozhatnak az attribútumokra, a proxy-ra és az azonosítóra egyaránt. A kliens kereshet név-attribútuma szerint, vagy kérhet egy olyat, melynek a szolgáltatója a Veszprémi Egyetemen m ködik, mely esetben a hely-attribútum kell hogy megegyezzen az elküldött szöveggel. A proxy-ra vonatkozó kritériumok megadása olyan Java interfész vagy interfészek átadását jelenti, melyeket a proxy objektumnak implementálnia kell. Ilyen kikötésre minden szolgáltatáskeresés alkalmával szükség van, mert ez biztosítja a kliens számára, hogy a kapott proxy-t meg fogja érteni a kéréseit. A szolgáltatás azonosítója szerint történ keresés akkor lehetséges, ha az igényl eszköz korábban már használta a

12 keresend szolgáltatást. A korábbi használatkor meg volt elégedve vele, ezért eltárolta az azonosítóját, melyet most keresési kritériumként ad át a lookup szolgáltatónak. Éppen az ilyen keresések miatt ajánlatos a szolgáltató eszközöknek a regisztrációjuk során mindig ugyanazt az azonosítót használni. Bármilyen kritérium, vagy kritérium-rendszer alapján is keres egy kliens, eredményül a számára szükséges proxy-t kapja. A proxy-hoz az általa ismert módon kéréseket intéz, melyek hatására az vagy helyi szolgáltatás-nyújtást végez, vagy ahogy az a 4. ábrán is látható volt a kérést továbbítása után a távoli gépen történik meg a kiszolgálás. A proxy olyan protokollt kell, hogy használjon a szolgáltató-eszközzel való kommunikációhoz, melyet mind, mind a szolgáltató eszközön futó Java program megért. A teljesen különböz Jini szolgáltatások azonos módon történ igénybevételének ez az alapja. A kliensek szemszögéb l a dzsinn minden szolgáltatása azonos módon, ismert Java interfészen keresztül használható. A klienseknek nem kell tudni a szolgáltató-eszköz által ténylegesen ismert nyelvet, de még a szolgáltató eszköz helyét sem, a tolmács szerepét számukra a proxy tölti be. Ez a megoldás teszi lehet vé azt is, hogy egy dzsinnek bármilyen eszköz, és nem csak számítógép lehet az alkotó eleme. 2.5 A Jini, mint a Grid alap-infrastruktúrája A Jini-t az univerzális szolgáltatásszemlélete, és az egyértelm en definiált szolgáltatás-bejegyzési és szolgáltatás-keresési protokolljai alkalmassá teszik arra, hogy az alapinfrastruktúra szerepét töltse be bármilyen grid-rendszerben. Hogy egy dzsinnt tényleg Gridnek lehessen nevezni, a futtatást végz er forrásokon szükség van egy-egy a Jini protokollokat alkalmazni képes szolgáltató-programra, a kliens gépeken pedig a protokollokat szintén ismer kliens alkalmazásokra. Egy er forrásokon futó szolgáltató programnak képesnek kell lennie az adott gép által kínált futtató-szolgáltatás igénybevételéhez szükséges proxy regisztrálására, míg a kliens-programoknak egy megfelel er forráshoz tartozó proxy megtalálására, majd annak a saját JVM-jükbe történ importálására. A proxy letöltése után a grid-szolgáltatás igénybevételével a végrehajtásra szánt programjuk a távoli er forráson futtatható, annak eredménye pedig visszatölthet. A szolgáltatás igénybevételének folyamatát a 6. ábra mutatja. Futtatandó program Futási eredmény Grid kliens program Grid er forrás Grid-szolgáltatás proxy-ja Grid szolgáltató program JVM JVM Tetsz leges protokoll 6. ábra: Egy Jini alapú Grid-szolgáltatás sémája

13 Mivel a Jini a Java nyelven alapszik, ezért mind a Grid szolgáltató programnak, mind a Grid kliens programnak Java program kell lennie, a köztük lév kommunikációs protokoll pedig csak olyan lehet, amelyet JVM-b l végre lehet hajtani. A kommunikáció során meg kell oldani a kliens programjának és a futtatáshoz szükséges minden egyéb információnak a szolgáltatóhoz való átvitelét, a futtatás befejezése után pedig az eredmények visszahozatalát. A kommunikáció alapulhat egyszer socket-eken, használhat Java RMI-t, CORBA alapú kommunikációt, vagy akár teljesen egyedi megoldást is. A Jini proxy-szemlélete miatt a kliensnek az alkalmazott módszerrel nem kell tör dnie, mert az csak a proxy-ra és a távoli er forráson futó szolgáltató programra tartozik. Amit viszont a kliens programnak mindenképpen tudnia kell, az a proxy használati módja, melynek ismerete nélkül nem képes a szolgáltatás igénybevételére. Az er forráson futó Java szolgáltató-programnak a proxy regisztrálása után késznek kell lennie a távoli proxy-któl jöv kérések fogadására, és a kéréseknek megfelel en programfuttatás irányítására.

14 3. Párhuzamos PVM programok végrehajtása 3.1 A végrehajtás párhuzamosítása Egy lehetséges módszer a párhuzamosításra a program dekomponálása, processzekre bontásra, melyek közül egyszerre több is futhat, de a processzek között valamilyen szinkronizálásra, kommunikációra van szükség. Az elkészült program futhat akár klaszteren, akár szuperszámítógépen. Egy párhuzamos program megírásakor a processzek között zajló kommunikációnak a kivitelezése jelenti az egyik legnagyobb nehézséget. Vagy el re tudnia kell a programozónak, hogy mikor melyik processz melyik gépen fut ami nyilvánvalóan lehetetlen vagy kell valamilyen megoldást találni arra, hogy az ilyen és ehhez hasonló részletekkel a programfejleszt knek ne kelljen foglalkozniuk. Erre a problémára ad megoldást a PVM (Parallel Virtual Machine) [5]. A PVM egy olyan szoftvercsomag, melynek használatával egy hálózat számítógépei a felhasználó számára egyetlen, párhuzamos m ködés virtuális gépnek látszanak. A gépeken futó processzek egymáshoz egységes interfésszel kapcsolódnak, melyen keresztül egymásnak PVM-függvényhívások segítségével üzeneteket küldhetnek. A virtuális gép része lehet bármilyen els sorban Unix operációs rendszert használó számítógép, számítógéprendszer. Egy PVM rendszer felépítése az alábbi ábrán látható: PVM-program Parallel Virtual Machine MPP PC klaszter Vektor szuper szg. PVM-üzenetek 7. ábra: PVM-rendszer A PVM egy absztrakciós szint a párhuzamos program és a hálózat számítógépei között. A virtuális gép létrehozásában bármilyen típusú számítógép részt vehet, melyhez létezik PVM csomag. Egy PVM-program speciális függvényhívásokat használva kommunikálhat a virtuális géppel, mely kommunikáció a számítógépeken futó PVMdémonokkal való kommunikációt jelenti. A rendszer a kommunikáció során elrejti a processzek el l az olyan architektúra-függ információkat, mint például a gépek közötti számábrázolási különbség. Ezt a problémát úgy oldja meg, hogy az üzenetküldés el tt a paramétereket architektúra-független formátumra konvertálja, célba érkezéskor pedig vissza, de már az aktuális számábrázolásnak megfelel en.

15 3.2 Programok futtatása a helyi PVM-démon felhasználásával A PVM tehát egy olyan infrastruktúra, amely biztosítja a különböz gépeken futó processzek számára a kommunikációs csatornát, továbbá definiál egy hozzá való protokollt. Ahhoz, hogy ez az infrastruktúra egy program számára rendelkezésre álljon, a program tulajdonosának a futtatás el tt létre kell hoznia a virtuális gépet, melynek azon rendszerek lehetnek tagjai, amelyeken a felhasználónak joga van használni a helyi PVMdémont. Ezek után elindítható a program, amely a virtuális gépen belül létrehozza a kit zött feladatot megoldó PVM-processzeket. Fontos megjegyezni, közvetlenül a futtatás el tt az alábbi két dolgot kell tenni: 1. A programot minden olyan architektúrán lefordítani, amely a virtuális gépet alkotó számítógépek között megtalálható. 2. A lefordított állományokat abba a könyvtárba másolni, ahol a PVM a futás során a létrehozandó PVM-processzek forrását keresni fogja. Ennek a jegyzéknek a neve a PVM dokumentációjában megtalálható. (Általában $HOME/pvm3/$ARCH/bin.) A rendszeren belül a PVM-processzek tényleges futási helyét csak a PVM ismeri, a programozó nem. A processzek megszületésükkor a PVM-rendszert l egyedi azonosítót kapnak, melyek ismeretében egymásnak üzeneteket küldhetnek. A PVM gondoskodik arról, hogy egy üzenet eljusson a megadott azonosítóval rendelkez processzhez, vagyis egy üzenetet küld processznek csak a címzett processz azonosítóját kell ismernie, a futási helyét nem. A PVM ezen a szolgáltatásokon kívül semmi többletet nem ad a futtatás megkönnyitésére, és ez különösen a hosszú ideig (napokig vagy akár hetekig) futó programok esetén jelent nehézséget. Nem ritka az ilyen hosszú futású program, mivel a PVM-et gyakran használják olyan mérnöki, fizikai, biológiai számításokat igényl feladatokhoz, melyek során aránylag nem túl bonyolult m veleteket kell végrehajtani nagy mennyiség adaton. Az ilyen, és ehhez hasonló feladatok során elvégzend lebeg pontos számítások pedig rendkívül megnövelik a futási id t. A futtatás során a probléma jelentkezhet akkor, ha egyszerre több programot indítunk ugyanazon a virtuális gépen. Ilyenkor az ugyanabban a virtuális gépben futó, különböz alkalmazásokhoz tartozó PVM-processzek képesek egymásnak üzenetet küldeni, nincs semmi védelem, ami elkülönítené ket. Ez kiszámíthatatlan viselkedést okozhat a programokban, és ellehetetleníti az utólagos hibakeresést. További nehézséget okozhat de még a futtatás el tt a virtuális gép létrehozása, vagyis az er forrás-allokálás. Ez a folyamat azt jelenti, hogy a rendelkezésre álló er források közül ki kell választani azokat, amelyeket egy adott program futtatásához használni szeretnénk, vagyis amelyekb l a virtuális gépet létre kívánjuk hozni. PVMdémonon keresztül végzett futtatás esetén ez teljes mértékben a program tulajdonosára hárul, és közel sem egyszer feladat. Tudnia kell hogy pontosan milyen gépek érhet k el a hálózatban, és nem árt ismerni azok aktuális leterheltségét sem. A leterheltséget figyelembe véve elkerülhet, hogy egy túlterhelt gépen futó processz a kommunikációban fellép késleltetésekkel visszafogja a többi, kevésbé terhelt gépen futót. Ilyen nem egyenletes leterheltség különösen olyan ipari környezetben fordulhat el, ahol a helyi klaszter munkaállomásait els sorban a napi ügyek intézésére használják, párhuzamos programok futtatása csak másodlagos. Ilyen helyen csak olyan gépet ajánlatos a virtuális gép létrehozásakor felhasználni, amelyik éppen szabad, vagyis annak tulajdonosa nem

16 használ rajta semmilyen programot. Hogy egy egyszer felhasználó ezt hogyan tudja kideríteni, arra sok esetben egyáltalán nincs megoldás, de ha mégis valamilyen módon képes felmérni a helyi hálózat gépeit, abból akkor sem tud következteti a következ pár perc vagy óra történéseire. 3.3 PVM programok futtatása Condorral Az említett problémák megoldására szükség van egy olyan programra, amelyik egyrészt minden PVM-program számára új virtuális gépet hoz létre, másrészt az aktuális terheltségt l függ en változtatja a PVM-ek létrehozásában részt vev gépek halmazát. Ez a szoftver a felhasználóknak magasabb szint szolgáltatást nyújt, mint egy sima PVMdémon, elrejtve el lük a futtatás valódi menetét. Ezek a szoftverkomponensnek a jobmenedzserek. Használata esetén a felhasználók nem a virtuális géppel, hanem vele tartják a kapcsolatot, lényegében nem is kell tudniuk arról, hogy a PVM-programok futtatásához virtuális gépre is szükség van. Egy ilyen jobkezel program a Wisconsin-Madison Egyetem által kifejlesztett Condor. A cél, amiért a Condort létrehozták: lehet vé tenni az úgynevezett high throughput computing nagy számú, különböz tulajdonosokhoz tartozó számítógépek egyegységbe foglalásával [18]. Egy Condor-rendszer sémája az alábbi ábrán látható: PVM-program Java-program MPI-program Globus-program... Condor Tényleges futtató környezetek, virtuális gépek Fizikai er forrás 1 Fizikai er forrás 2... Fizikai er forrás N A hálózat fizikai megvalósítása 8. ábra: Condor futtató rendszer Mint látható, a Condor nem csak PVM-programokat, hanem más típusú, mind szekvenciális, mind párhuzamos programokat fogad. Elrejti a tényleges futtató környezeteket a felhasználók el l, akiknek egy program futtatásakor csupán annyit a feladatuk, hogy elkészítenek egy megfelel job-leíró fájlt, melyet azután átadnak a jobkezel nek. Ebben a job-leíró fájlban szerepl alapvet adatok: A futtatandó program típusa A futtatható állomány neve Futási paraméterek Standard input-ot helyettesít fájl neve A program számára beállítandó környezeti változók Futás közbeni eseményekr l készítend naplófájl neve

17 A Condor a fájl tartalma alapján létrehoz egy új futási környezetet, elindítja a futtatható állományt a megadott környezeti változókkal, majd végig a futása során a fontosabb eseményekr l bejegyzéseket készít a megadott naplófájlba. A program tulajdonosa a napló fájlból értesülhet például arról is, hogy job-jának a futása akár sikeresen, akár sikertelenül befejez dött. Amit mindenképpen meg kell jegyezni, hogy a Condor ugyan sok tekintetben magasabb szint szolgáltatást nyújt, mint a PVM, viszont cserébe fel kell áldozni a programok interaktivitását. Condor-on keresztül ugyanis nem lehet interaktív alkalmazásokat futtatni. Mint az el bbi felsorolásból látszik, a felhasználónak már a program elindítása el tt tudnia kell, hogy mi lesz annak bemenete, ugyanis az adatokat a futtatás el tt egy állományba kell írnia, majd az állományt a leíró fájlban meghivatkoznia. A Condor garantálja, hogy a futó program a hivatkozott fájlt fogja standard bemenetének tekinteni, és nem a billenty zetet. Ez, a PVM-démonhoz képest jelent snek t n megszorítás PVM-programok esetén szerencsére nem jelent gondot, ugyanis a PVMalkalmazások által végzett számítások bemen adatai általában el re ismertek, vagy futás közben generálódnak. 3.4 A Condor, mint erőforrásmenedzser A Condor az el bb leírtak értelmében tehát képes a felhasználó helyett a PVM létrehozására, és a futó programok folyamatos felügyeletére. Az ok azonban, amiért általában a felhasználók a Condor mellett döntenek, az az er forrásmenedzseri képessége. A Condor nem csak a futtatásra átadott programokat, hanem a hálózatban er forrásként üzemel gépeket is képes nyilvántartani. Az általa menedzselt hálózat minden gépén rendelkezik egy helyi démonnal, melyen keresztül folyamatosan figyelemmel kísérheti annak terheltségét. A terheltség függvényében bármelyik er forrást képes hozzácsatolni, illetve kivenni a programfuttatásra használható gépek halmazából. A leggyakoribb allokálási politika, amit Condor esetében alkalmaznak a következ : minden olyan gép, melyet x perce nem használt annak tulajdonosa, az kerüljön a központi Condor menedzser fennhatósága alá. Ha azonban megérkezik a tulajdonos, akkor t illeti az els bbség. Ha az x id intervallumnak a hosszát a rendszergazda alkalmasan választja meg, akkor egy ilyen Condor esetén egyszer en konfigurálható megoldással kisz rheti a korábban már említett kávészünetek miatt pihen er forrásokat a ténylegesen szabad gépek közül. A Condor egy program futtatásakor a politikája által szabadnak ítélt gépek halmazából választ a virtuális gép felépítéséhez. Az allokálási procedúra során azonban nem csak az er forrás-felajánlókra, de a job-ot futtatók igényeire is figyel. A Condorfelhasználók a job-leíró fájlokban megadhatnak a futtatáshoz használandó architektúrákra vonatkozó kikötéseket, prioritásokat. A Condor ezeket az információkat figyelembe véve próbálja a szabad gépek közül kiválasztani a legalkalmasabbakat a futtató környezet felépítéséhez. Ha éppen nincs olyan architektuájú gép, mint amit a kliens igényelt, akkor a Condor egyáltalán nem allokál er forrást, ennek okát pedig a naplófájlba írja. A Condor megoldja mindazokat a problémákat, melyek az egyszer PVM-démonon keresztüli program-futtatás során felmerültek. A korábban említett interaktivitás hiányá -n kívül azonban még egy problémája van: a Condor segítségével futtatott PVMprogramoknak más módon kell létrehozniuk a PVM-processzeket, mint PVM-démonnal való futtatás esetén. Emiatt a felhasználóknak már a programjuk fejlesztése során tudniuk kell, hogy az kés bb Condorral, vagy PVM-démonnal lesz-e futtatva.

18 3.5 A PVM és a Condor szerepe a Gridben Mint a fejezet els részb l kiderült, a PVM összefogja a lokális hálózat gépeit, és bel lük nagyobb egységeket képez. Egy ilyen nagyobb egység egy párhuzamos virtuális gép a processzek számára biztosított kommunikációs infrastruktúra miatt sokkal nagyobb számítási kapacitást képvisel, mint az t alkotó fizikai er források kapacitásának az összege. Mivel a Gridben a cél a nagy kapacitást igényl programok futtatása, ezért kézenfekv nek t nik egy olyan grid-rendszer létrehozása, melynek alapegységeit nem önálló gépek, hanem PVM-ek adják. Az ilyen számítási rendszer neve PVM-Grid, és jellemz tulajdonsága, hogy a benne található er források mind párhuzamos virtuális gépek. A PVM-Grid infrastruktúrát biztosít egyrészt a klienseknek a legmegfelel bb PVM kiválasztásához, másrészt a PVMprocesszeknek a kiválasztott virtuális gépen belüli hatékony kommunikációhoz. Mint az a második részben látható volt, a helyi hálózatban él PVM-démon nem biztosít elég magas szint szolgáltatást, vagyis a Condor-hoz kellett fordulni. A PVM-Grid esetén még ez a szint sem elegend, ugyanis a Condor-t általában csak a helyi hálózat er forrásmenedzsereként használják. Ilyen esetben csak a helyi hálózat gépeit használhatja programfuttatáshoz, de ami a legfontosabb, hogy ilyenkor csak a helyi hálózat felhasználói érhetik el. Ez utóbbi tulajdonság miatt egyetlen Condor-klaszter nem tekinthet gridrendszernek. A Condor lehet séget biztosít azonban arra, hogy több klaszter összekötésével úgynevezett barátságos pool-t hozzunk létre, melynek egyetlen Condor-példány az er forrás- és jobmenedzsere. Ilyen esetben el fordulhat, hogy a barátságos pool egyik felhasználója által submitált job olyan gépeken is futni fog, melyhez az illet nek nincs felhasználói fiókja. Ennek oka, hogy a Condor megengedi a barátságos pool-on belül a jobok tetsz leges gépen való futását. A felépítésnek azonban van két nagy hátránya, melyek miatt a gyakorlatban csak ritkán alkalmazzák: 1. A klaszterek között meg kell nyitni minden egyes portot. Ez akkora biztonsági rést jelenthet, hogy tényleg csak a legjobb barátok engedhetik meg maguknak a közös Condor használatát. 2. Ha valamelyik barátságos klaszter ki akar lépni a szövetségb l, vagy egy új klaszter akar belépni a barátságos klaszterek közé, akkor a pool minden egyes résztvev jének módosítani kell néhány konfigurációs fájlt. Ez néhány tag esetén még elviselhet, de nagy méret Grid esetén nyilván kivitelezhetetlen. Ha több száz, vagy ezer klaszterb l álló Gridet akarunk létrehozni, akkor a Condor önmagában nem nyújthat megoldást. Ennyi felhasználó nem bízik meg egymásban annyira, hogy barátságos pool-t hozzanak létre, és egyébként is túl bonyolult a rendszer menedzselése. A Condor tehát PVM-gridekben a klaszterek közötti infrastruktúraként nem használható, viszont klaszteren belül jól funkcionál. Emiatt érdemes a távoli kliensek számára futtató szolgáltatást nyújtó program, és a klasztert alkotó fizikai er források közötti rétegként alkalmazni. Ez a struktúra látható a 9. ábrán.

19 Grid-infrastruktúra Grid szolgáltató program Condor Grid szolgáltató program Condor Gép 1 Gép 2... Gép M... Gép 1 Gép 2... Gép N Lokális hálózat 1 Lokális hálózat P 9. ábra: A Condor szerepe a Gridben Ilyen esetben a Grid infrastruktúrája a klaszterek közötti, míg a Condor a klasztereken belüli er forrás-allokációt végzi. Mivel a Condor a PVM-programok számára nem transzparens a programoknak máshogyan kell Condor esetén a PVM-processzeket létrehozniuk ezért a Grid klienseinek tudnia kell a Condor létezésér l. Ha viszont tudnak a Condor-ról, akkor akár a klaszteren belüli gépallokációhoz is kritériumokat adhatnak. Ha ezeket a kritériumokat a klaszter szolgáltató programja továbbítja a Condor-nak, akkor annak a gépallokáció során mind a rendszergazda által beállított politikára, mind a kapott igényekre tekintettel kell lennie. Ha viszont a kikötéseket a szolgáltató program nem továbbítja, akkor a Grid kliensei csak klasztert, és nem konkrét er forrásokat választhatnak programjaiknak.

20 4. PVM alkalmazások végrehajtása Jini alapon A rendszernek lehet vé kell tennie, hogy egy Jini alapú hálózatban a hálózat egyik gépén megírt PVM-program a hálózat egy másik részén m köd PVM virtuális gépen fusson le akár PVM-démon, akár Condor támogatásával. Az elindított PVM-programok futás közben képesek a távoli monitoroknak állapotinformációkat küldeni, futásuk befejeztével pedig az eredmények automatikusan kerülnek vissza a kliensekhez. Egy alkalmasan megírt programmal egy dzsinnben, (dzsinnekben) bejegyezhet a PVM-program futtató és monitorozó szolgáltatás, melynek igénybevételével a kliensgépek távoli er forrásokat választhatnak a végrehajtandó programjaikhoz. A szolgáltatást nyújtó eszköz lehet bármilyen számítógép vagy számítógép-rendszer, az egyetlen kikötés vele szemben hogy rendelkezzen JVM-mel és PVM-mel, illetve opcionálisan Condor-ral. Ha a szolgáltató oldalon nincs Condor, akkor a kliensek job-jai egyszer PVM-démonon kereszül lesznek futtatva, ellenkez esetben viszont Condor-ral. A legcélszer bb és legegyszer bb, ha egy klaszter végzi ezt a szolgáltató tevékenységet, ezért a kés bbiekben a szolgáltató-eszközöket végig klasztereknek tekinthet. 4.1 A Jini használata A rendszerben a Jini-t, mint a PVM-Grid infrastruktúráját használom. A következ felsorolásban áttekintem mindazokat a Jini funkcionalitásokat, melyeket ki fog használni a rendszer: Szolgáltatás-központú szemlélet: A Jini a hálózatot szolgáltatók, és szolgáltatás-igényl k hálózatának tekinti. Ez a szemlélet megfelel az aktuális helyzetnek. Szolgáltatónak tekinthet k mindazon PVMklaszterek, melyeket tulajdonosuk, mint futtató er forrást kínál mások számára. Szolgáltatás-igényl nek tekinthet k mindazon gépek, melyeken futtatásra és monitorozásra váró PVM-program található. Ezen igényl k és szolgáltatók egymásra találására a dzsinnek lookup szolgáltatásai adnak lehet séget. Dinamikusan változó hálózatban m ködik: A lookup szolgáltatás segítségével a hálózatban elérhet klaszterek dinamikusan változó halmaza könnyen nyilvántartható. A lízingelés miatt a nyilvántartás a valóságnak (majdnem tökéletesen) megfelel adatokat fog tartalmazni. Az igényl k emiatt biztosak lehetnek benne, hogy a kiválasztott klaszter jelen pillanatban szabad, vagyis az átküldött PVM-program a távoli virtuális gépen azonnal elindul. Nem okoz a klaszter tulajdonosának plusz kiadást: A program az ingyenesen elérhet Java, Jini, PVM és Condor programokat használja, ezért a szolgáltatót semmilyen kiadás nem terheli. A PVM-klaszterek tulajdonosai ezért mások számára a szolgáltatást akár ingyen is nyújthatják. TCP/IP alapú hálózatban alkalmazható: dzsinnek létrehozhatók az Internetre alapozva, vagyis a program a már meglév globális számítógép hálózatnak adna egy újabb funkcionalitást. Nem a szolgáltató-rendszert, hanem csak egy funkciót tesz a kliensek számára láthatóvá:

21 A teljes klaszter helyett a kliensek csak a lookup szolgáltatóknál közzétett proxy-t kapják meg. Kizárólag a proxy-n keresztül intézhet kérés a szolgáltatóhoz, tehát mind a szolgáltató program, mind az azt futtató eszköz a kliensek el l rejtve marad, a szolgáltatásnyújtás biztonsága javul. Ellen rzött módon végezhet idegen PVM-programok futtatása: A kliensekt l kapott PVM-programok futtatását a szolgáltató oldalon futó Java-program kezdeményezi. Ez a program egy el re megadott feltételrendszer alapján dönthet a kliensek megbízhatóságáról, a futtatás engedélyezésér l. Mind a kliens-, mind a szolgáltatói oldalon pontosan megadhatók azok a m veletek, melyeket az idegen forrásból származó kódoknak joguk van elvégezni, más dolgokat viszont nem. Automatikus szolgáltatás-igénylés és használat: A Jini koncepcióban a szolgáltatók és a szolgáltatás-igényl k nem emberek, hanem szoftverek, vagyis a szolgáltatás igénybevétele automatizálható. A PVM-programok futtatását a kliensek által írt Java-programok kezdeményezhetik, mely kéréseket a szolgáltató klaszteren futó Java-program emberi beavatkozás nélkül kiszolgál. A teljes folyamat emiatt jóval rövidebb id alatt lezajlik, mint bármely más módszerrel, vagyis a hálózat gépeinek állásideje csökken, kihasználtságuk hatásfoka növekszik. 4.2 A rendszer követelményei Jini alapon Írni kell egy olyan szolgáltató program - proxy párt, amely képes megvalósítani az alábbi szolgáltatást: A szolgáltatást igényl számítógépr l áttölti magához a kliens által megadott PVMprogramot. A helyi Condort vagy PVM-démont használva lefuttatja azt. Képes a PVM-programok monitorozásához támogatást adni. A futási eredményeket visszatölti a kliens gépére. A feladat megoldása el tt az alábbi pontosításokat teszem: 1. Lefordított PVM-program kerül áttöltésre: A kikötés a PVM-fejleszt k szempontjából teszi biztonságosabbá a szolgáltatás igénybevételét: nem kerülhet illetéktelen kezekbe a forráskód. A hátránya, hogy a futtatandó PVM-programhoz olyan szolgáltatót kell keresni, akinek a klasztere ugyanolyan architektúrájú gépekb l áll, mint amilyenen a PVM-program le lett fordítva. Ennek oka a korábban említett PVM tulajdonság, vagyis hogy egy PVM programot a futtatás el tt minden olyan architektúrán le kell fordítani, amely a virtuális gépben szerepel. A szolgáltató oldalon emiatt célszer szolgáltatóeszközként olyan klasztert használni, amely sok azonos felépítés, és széles körben használt architektúrájú gépb l áll. Az architektúrát jellemz tulajdonságokat azután a kliensek számára elérhet vé kell tenni, máskülönben csak a programjuk elindításakor derül ki, hogy nem megfelel architektúrájú klasztert választottak. 2. A futtatandó PVM-program nem interaktív: Erre a kikötésre két ok miatt van szükség: 1. Condort használva nem lehet interaktív PVM-programokat futtatni. 2. PVM-et használva ugyan lehet, de ha a szolgáltatóhoz feltöltött programok id nként leállnának felhasználói inputra várakozva, azzal más programok el l foglalnák a számítási kapacitást, a klaszterek kihasználtsága jelent sen romlana.

A hierarchikus adatbázis struktúra jellemzői

A hierarchikus adatbázis struktúra jellemzői A hierarchikus adatbázis struktúra jellemzői Az első adatbázis-kezelő rendszerek a hierarchikus modellen alapultak. Ennek az volt a magyarázata, hogy az élet sok területén első közelítésben elég jól lehet

Részletesebben

Vezeték nélküli, elosztott rendszerű jelzőlámpás forgalomirányítás

Vezeték nélküli, elosztott rendszerű jelzőlámpás forgalomirányítás Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedés- és Járműirányítási Tanszék Vezeték nélküli, elosztott rendszerű jelzőlámpás forgalomirányítás Tamaskovics

Részletesebben

Hálózatkezelés: Távoli elérés szolgáltatások - PPP kapcsolatok

Hálózatkezelés: Távoli elérés szolgáltatások - PPP kapcsolatok System i Hálózatkezelés: Távoli elérés szolgáltatások - PPP kapcsolatok 6. változat 1. kiadás System i Hálózatkezelés: Távoli elérés szolgáltatások - PPP kapcsolatok 6. változat 1. kiadás Megjegyzés Mielőtt

Részletesebben

ERserver. iseries. Szolgáltatási minőség

ERserver. iseries. Szolgáltatási minőség ERserver iseries Szolgáltatási minőség ERserver iseries Szolgáltatási minőség Szerzői jog IBM Corporation 2002. Minden jog fenntartva Tartalom Szolgáltatási minőség (QoS)............................ 1

Részletesebben

IV. Szakmai szolgáltatások funkcionális tervezése

IV. Szakmai szolgáltatások funkcionális tervezése Magyarország-Szlovénia Phare CBC Program 2003 A határrégió emberi erőforrás potenciáljának maximalizálása támogatási konstrukció A régióban működő foglalkoztatási paktumok közötti koordináció projekt A

Részletesebben

Általános statisztika II. Kriszt, Éva Varga, Edit Kenyeres, Erika Korpás, Attiláné Csernyák, László

Általános statisztika II. Kriszt, Éva Varga, Edit Kenyeres, Erika Korpás, Attiláné Csernyák, László Általános statisztika II Kriszt, Éva Varga, Edit Kenyeres, Erika Korpás, Attiláné Csernyák, László Általános statisztika II Kriszt, Éva Varga, Edit Kenyeres, Erika Korpás, Attiláné Csernyák, László Publication

Részletesebben

Pénztárgép Projektfeladat specifikáció

Pénztárgép Projektfeladat specifikáció Pénztárgép Projektfeladat specifikáció 1 Tartalomjegyzék 1 Tartalomjegyzék... 2 2 Bevezetés... 3 2.1 A feladat címe... 3 2.2 A feladat rövid ismertetése... 3 3 Elvárások a feladattal kapcsolatban... 4

Részletesebben

INFORMATIKA Helyi tantárgyi tanterv

INFORMATIKA Helyi tantárgyi tanterv 1. Tantárgyi címoldal Intézmény neve, székhely-település vagy fejléc INFORMATIKA Helyi tantárgyi tanterv Általános tantervű tanulócsoportok A tantárgy nevelési és fejlesztési célrendszere megvalósításának

Részletesebben

(Nem jogalkotási aktusok) RENDELETEK

(Nem jogalkotási aktusok) RENDELETEK 2016.2.9. L 32/1 II (Nem jogalkotási aktusok) RENDELETEK A BIZOTTSÁG (EU) 2016/161 FELHATALMAZÁSON ALAPULÓ RENDELETE (2015. október 2.) a 2001/83/EK európai parlamenti és tanácsi irányelvnek az emberi

Részletesebben

2009.03.16. Ezeket a kiemelkedı sebességő számítógépeket nevezzük szuperszámítógépeknek.

2009.03.16. Ezeket a kiemelkedı sebességő számítógépeket nevezzük szuperszámítógépeknek. A számítási kapacitás hiánya a világ egyik fontos problémája. Számos olyan tudományos és mőszaki probléma létezik, melyek megoldásához a szokásos számítógépek, PC-k, munkaállomások, de még a szerverek

Részletesebben

Szuperszámítógépes teljesítmény szuperszámítógép nélkül A BinSYS Projekt

Szuperszámítógépes teljesítmény szuperszámítógép nélkül A BinSYS Projekt Szuperszámítógépes teljesítmény szuperszámítógép nélkül A BinSYS Projekt Kovács Attila attila@compalg.inf.elte.hu Kornafeld Ádám kadam@sztaki.hu Burcsi Péter bupe@compalg.inf.elte.hu 1. Szuperszámítógép

Részletesebben

Novell Nterprise Branch Office: a távoli iroda felügyeletének leegyszerűsítése

Novell Nterprise Branch Office: a távoli iroda felügyeletének leegyszerűsítése Novell Nterprise Branch Office: a távoli iroda felügyeletének leegyszerűsítése termékleírás www.novell.hu Bevezetés A mai vállalatok gyakran tartanak fenn irodákat az ország és a világ különböző pontjain.

Részletesebben

Történeti áttekintés

Történeti áttekintés Történeti áttekintés Előzmények A számítástechnika kezdetén elterjedt (egyeduralkodó) volt a mérnökpult használata, a gép és az ember kommunikációja bináris nyelven zajlott. A gépi kódú programozás nem

Részletesebben

Bonobo: A GNOME CORBA alapú komponens-megoldása Unixokra

Bonobo: A GNOME CORBA alapú komponens-megoldása Unixokra Bonobo: A GNOME CORBA alapú komponens-megoldása Unixokra Érdi Gergő 2000.09.25. Kivonat A Unix rendszerek alapvető segédprogramjait jellemző tegyél egy dolgot, de azt helyesen, és

Részletesebben

Gépbiztonság. Biztonságtechnikai és szabványok áttekintése.

Gépbiztonság. Biztonságtechnikai és szabványok áttekintése. Gépbiztonság. Biztonságtechnikai és szabványok áttekintése. 1. Bevezetés. A gépek biztonsága tekintetében az EU.ban több szintű szabványrendszer van kialakítva, amely a gépek lehető legszélesebb körét

Részletesebben

Számítógép kártevők. Számítógép vírusok (szűkebb értelemben) Nem rezidens vírusok. Informatika alapjai-13 Számítógép kártevők 1/6

Számítógép kártevők. Számítógép vírusok (szűkebb értelemben) Nem rezidens vírusok. Informatika alapjai-13 Számítógép kártevők 1/6 Informatika alapjai-13 Számítógép kártevők 1/6 Számítógép kártevők Számítógép vírusok (szűkebb értelemben) A vírus önreprodukáló program, amely saját másolatait egy másik végrehajtható file-ba vagy dokumentumba

Részletesebben

OEP Betegéletút lekérdezés háziorvosok és vénytörténet lekérdezés patikák számára. API dokumentáció. verzió: 2.01

OEP Betegéletút lekérdezés háziorvosok és vénytörténet lekérdezés patikák számára. API dokumentáció. verzió: 2.01 OEP Betegéletút lekérdezés háziorvosok és vénytörténet lekérdezés patikák számára API dokumentáció verzió: 2.01 2013.03.26 Tartalomjegyzék 1 BEVEZETÉS...3 1.1 A fejlesztés célja...3 2 API ELÉRÉS ÉS MŐKÖDÉS...3

Részletesebben

TANÚSÍTVÁNY. tanúsítja, hogy a Polysys Kft. által kifejlesztett és forgalmazott

TANÚSÍTVÁNY. tanúsítja, hogy a Polysys Kft. által kifejlesztett és forgalmazott TANÚSÍTVÁNY A HUNGUARD Számítástechnikai-, informatikai kutató-fejlesztő és általános szolgáltató Kft. a 15/2001.(VIII. 27.) MeHVM rendelet alapján, mint a Magyar Köztársaság Informatikai és Hírközlési

Részletesebben

Ingrid Signo Felhasználói kézikönyv. Pénztári használatra

Ingrid Signo Felhasználói kézikönyv. Pénztári használatra Ingrid Signo Felhasználói kézikönyv Pénztári használatra 3.0 verzió Microsoft Windows 98SE, NT 4.0, XP, 2000 operációs rendszerekre 2006. január 20. Tájékoztató a Ingrid Signo felhasználási jogáról A felhasználás

Részletesebben

feladatok meghatározása során elsősorban az eszközök ismeretére, az eszközökkel megvalósítható lehetőségek feltérképezésére és az alkotó

feladatok meghatározása során elsősorban az eszközök ismeretére, az eszközökkel megvalósítható lehetőségek feltérképezésére és az alkotó INFORMATIKA 5-8. Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök használata olyan

Részletesebben

Az informatika tantárgy fejlesztési feladatait a Nemzeti alaptanterv hat részterületen írja elő, melyek szervesen kapcsolódnak egymáshoz.

Az informatika tantárgy fejlesztési feladatait a Nemzeti alaptanterv hat részterületen írja elő, melyek szervesen kapcsolódnak egymáshoz. Informatika Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök használata olyan eszköztudást

Részletesebben

átvitt bitek számával jellemezhetjük. Ezt bit/s-ban mérjük (bps) vagy ennek többszöröseiben (kbps, Mbps).

átvitt bitek számával jellemezhetjük. Ezt bit/s-ban mérjük (bps) vagy ennek többszöröseiben (kbps, Mbps). Adatátviteli sebesség: Digitális hálózatokat az átviteli sebességükkel az idıegység alatt átvitt bitek számával jellemezhetjük. Ezt bit/s-ban mérjük (bps) vagy ennek többszöröseiben (kbps, Mbps). Sávszélesség:

Részletesebben

Welcome3 Bele pteto rendszer

Welcome3 Bele pteto rendszer Welcome3 Bele pteto rendszer Programozói kézikönyv beks Kommunikációs Technika Kft 4024, Debrecen, Rákóczi utca 21 www.beks.hu 2013. március 7. Tartalomjegyzék Rendszer telepítési folyamatábra... 6 Welcome3

Részletesebben

ALAPISMERETEK...6 A MICROSOFT ACCESS INDÍTÁSA...14 AZ ABLAK...14 MEGNYITÁS...16 TÁBLÁK...17 LEKÉRDEZÉSEK...18

ALAPISMERETEK...6 A MICROSOFT ACCESS INDÍTÁSA...14 AZ ABLAK...14 MEGNYITÁS...16 TÁBLÁK...17 LEKÉRDEZÉSEK...18 Adatbázis-kezelés TARTALOMJEGYZÉK BEVEZETİ...6 ALAPISMERETEK...6 ADATBÁZIS...6 AZ ADATBÁZISHOZ KAPCSOLÓDÓ FOGALMAK...6 ADATMODELL...8 ADATBÁZISOK TERVEZÉSE...9 1. LÉPÉS: KÖVETELMÉNYELEMZÉS...9 2. LÉPÉS:

Részletesebben

IBM Business Monitor 7. változat 5. alváltozat. IBM Business Monitor telepítési kézikönyv

IBM Business Monitor 7. változat 5. alváltozat. IBM Business Monitor telepítési kézikönyv IBM Business Monitor 7. változat 5. alváltozat IBM Business Monitor telepítési kézikönyv ii Telepítés Tartalom 1. fejezet IBM Business Monitor telepítése.............. 1 2. fejezet IBM Business Monitor

Részletesebben

I. A légfékrendszer időszakos vizsgálatához alkalmazható mérő-adatgyűjtő berendezés műszaki

I. A légfékrendszer időszakos vizsgálatához alkalmazható mérő-adatgyűjtő berendezés műszaki A Közlekedési Főfelügyelet közleménye a nemzetközi forgalomban használt autóbuszok (M2 és M3 jármű-kategóriába tartozó gépkocsik) vizsgálatát (is) végző vizsgálóállomásokon alkalmazandó mérő-adatgyűjtő

Részletesebben

Komponens modellek. 3. Előadás (első fele)

Komponens modellek. 3. Előadás (első fele) Komponens modellek 3. Előadás (első fele) A komponens modellek feladata Támogassa a szoftverrendszerek felépítését különböző funkcionális, logikai komponensekből, amelyek a számítógépes hálózatban különböző

Részletesebben

Adatbázisok és adattárházak az információs rendszerek adatkezelői

Adatbázisok és adattárházak az információs rendszerek adatkezelői Adatbázisok és adattárházak az információs rendszerek adatkezelői (Klárné Barta Éva) Részlet az Adatbáziskezelés és vállalati információs rendszerek című jegyzetből. Az első adatfeldolgozó rendszerek néhány

Részletesebben

1. K ORLÁTLAN SÁVSZÉLESSÉG ÉS

1. K ORLÁTLAN SÁVSZÉLESSÉG ÉS 1. K ORLÁTLAN SÁVSZÉLESSÉG ÉS TÁROLÓKAPACITÁS Bartolits István Az adatátviteli és tárolási kapacitások korlátainak jelentős csökkenése új szolgáltatások és új üzleti modellek megjelenését eredményezi.

Részletesebben

BorsodWeb Kft. Általános Szerződési Feltételek. Előző módosítás kelte: 2009.01.11. Utolsó módosítás kelte: 2009.10.01. Érvényes: 2009.11.

BorsodWeb Kft. Általános Szerződési Feltételek. Előző módosítás kelte: 2009.01.11. Utolsó módosítás kelte: 2009.10.01. Érvényes: 2009.11. BorsodWeb Kft. Általános Szerződési Feltételek Előző módosítás kelte: 2009.01.11. Utolsó módosítás kelte: 2009.10.01. Érvényes: 2009.11.01-től 2 TARTALOMJEGYZÉK TARTALOMJEGYZÉK.....2 1. A szolgáltató neve,

Részletesebben

Adathálózati (Internet) szolgáltatás Általános Szerzıdési Feltételek (v1.2) Érvényes : 2009.06.18-tól. Tartalomjegyzék

Adathálózati (Internet) szolgáltatás Általános Szerzıdési Feltételek (v1.2) Érvényes : 2009.06.18-tól. Tartalomjegyzék Fejezet- és bekezdés címek Adathálózati (Internet) szolgáltatás Általános Szerzıdési Feltételek (v1.2) Érvényes : 2009.06.18-tól Tartalomjegyzék 1. A szolgáltató adatai 1.1. A szolgáltató megnevezése,

Részletesebben

A.26. Hagyományos és korszerű tervezési eljárások

A.26. Hagyományos és korszerű tervezési eljárások A.26. Hagyományos és korszerű tervezési eljárások A.26.1. Hagyományos tervezési eljárások A.26.1.1. Csuklós és merev kapcsolatú keretek tervezése Napjainkig a magasépítési tartószerkezetek tervezése a

Részletesebben

Általános Szerződési Feltételek

Általános Szerződési Feltételek Általános Szerződési Feltételek ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK (ÁSZF) A Mana Fashion ruha webáruház böngészésével és használatával Ön kijelenti, hogy elolvasta és elfogadta a Mana Fashion webáruház használatára

Részletesebben

NETLOCK SIGN szolgáltatás Rendelkezésre állási Szabályzata

NETLOCK SIGN szolgáltatás Rendelkezésre állási Szabályzata NETLOCK SIGN szolgáltatás Rendelkezésre állási Szabályzata NETLOCK Informatikai és Hálózatbiztonsági Szolgáltató Korlátolt Felelősségű Társaság Azonosító szám (OID): 1.3.6.1.4.1.3555.1.58.20160530 Jóváhagyás

Részletesebben

1 Rendszer alapok. 1.1 Alapfogalmak

1 Rendszer alapok. 1.1 Alapfogalmak ÉRTÉKTEREMTŐ FOLYAM ATOK MENEDZSMENTJE II. RENDSZEREK ÉS FOLYAMATOK TARTALOMJEGYZÉK 1 Rendszer alapok 1.1 Alapfogalmak 1.2 A rendszerek csoportosítása 1.3 Rendszerek működése 1.4 Rendszerek leírása, modellezése,

Részletesebben

INFORMATIKA Emelt szint 11-12.

INFORMATIKA Emelt szint 11-12. INFORMATIKA Emelt szint 11-12. Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök

Részletesebben

AKVÁRIUM KLUB ÜZEMELTETŐ KORLÁTOLT FELELŐSSÉGŰ TÁRSASÁG ADATVÉDELMI SZABÁLYZAT

AKVÁRIUM KLUB ÜZEMELTETŐ KORLÁTOLT FELELŐSSÉGŰ TÁRSASÁG ADATVÉDELMI SZABÁLYZAT AKVÁRIUM KLUB ÜZEMELTETŐ KORLÁTOLT FELELŐSSÉGŰ TÁRSASÁG ADATVÉDELMI SZABÁLYZAT Az Akvárium Klub Üzemeltető Korlátolt Felelősségű Társaság (az Adatkezelő ) az általa nyújtott online jegyvásárlási szolgáltatáshoz

Részletesebben

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK INTERNET PROTOKOLL ALAPÚ HELYHEZ KÖTÖTT ÉS INTERNET PROTOKOLL ALAPÚ HELYHEZ NEM KÖTÖTT TÁVBESZÉLŐ SZOLGÁLTATÁSHOZ Oldal: 1 / 67 Tartalom 1. SZOLGÁLTATÓ ADATAI, ÜGYFÉLSZOLGÁLAT

Részletesebben

Karibi kincsek Dokumentáció

Karibi kincsek Dokumentáció Dokumentáció 2010.03.24. Gyimesi Róbert Alapvetés Milyen célok elérését remélhetjük a programcsomagtól? Ezen oktatócsomag segítségével egy olyan (matematika)feladatot dolgozhatunk fel, oldhatunk közösen

Részletesebben

Közigazgatási szerződés

Közigazgatási szerződés Közigazgatási szerződés a Nemzeti Média- és Hírközlési Hatóság által működtetett Szélessáv Programban történő részvétel feltételeiről amely létrejött a XY (anyja neve, szig. száma, lakcíme) továbbiakban

Részletesebben

OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK. 2.1 A feladat

OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK. 2.1 A feladat 2. Digitális óra 28 OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK 2.1 A feladat Ebben a fejezetben egy viszonylag egyszerő problémára alkalmazva tekintjük át az OO tervezés modellezési technikáit. A feladat

Részletesebben

SyscoNet Kereskedelmi és Szolgáltató Kft.

SyscoNet Kereskedelmi és Szolgáltató Kft. SyscoNet Kereskedelmi és Szolgáltató Kft. ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEI INTERNET HOZZÁFÉRÉS SZOLGÁLTATÁS IGÉNYBEVÉTELÉRE Létrehozás dátuma: Budapest, 2008.12.09. Módosítás dátuma: 2010.08.25 Hatálybalépés

Részletesebben

Bánsághi Anna anna.bansaghi@mamikon.net. Bánsághi Anna 1 of 54

Bánsághi Anna anna.bansaghi@mamikon.net. Bánsághi Anna 1 of 54 SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT Bánsághi Anna 1 of 54 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK

Részletesebben

Felhasználói leírás v1.0

Felhasználói leírás v1.0 1 Felhasználói leírás v1.0 A Lakás Expressz Szolgáltatás Elemző rendszer felhasználói funkcióiról Verzió: v1.0 Készült: 2013.március 27. 2 TARTALOMJEGYZÉK 1 Bevezető... 3 2 Tarifálás... 4 2.1 Navigáció

Részletesebben

Integrált ügyviteli rendszer: Kettős könyvelés modul

Integrált ügyviteli rendszer: Kettős könyvelés modul Integrált ügyviteli rendszer: Kettős könyvelés modul Használati útmutató 1988-2015. 3100.Salgótarján Fő tér 1. tel.: 36-32-423-912, e-mail minorg@minorg.hu Internet: http://www.minorg.hu/ 1.oldal Tartalomjegyzék.

Részletesebben

Gyakori kérdések és. válaszok. az internetes vásárlás. témaköréből

Gyakori kérdések és. válaszok. az internetes vásárlás. témaköréből Gyakori kérdések és válaszok az internetes vásárlás témaköréből Budapest, 2016. május 13. BEVEZETÉS Ma már számtalan különböző webáruház kínál termékeket eladásra a fogyasztóknak, ezzel kényelmes lehetőséget

Részletesebben

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK Jelen Általános Szerződési Feltételek (továbbiakban ÁSZF) tartalmazza a www.axelentshop.hu weboldalon (a továbbiakban: Honlap) elérhető szolgáltatás igénybevételének nagykereskedők,

Részletesebben

Access 2010 Űrlapok és adatelérés

Access 2010 Űrlapok és adatelérés 2 Minden jog fenntartva, beleértve bárminemű sokszorosítás, másolás és közlés jogát is. Kiadja a Mercator Stúdió Felelős kiadó a Mercator Stúdió vezetője Lektor: Gál Veronika Szerkesztő: Pétery István

Részletesebben

A DIÁKHITEL Rt. szoftver és hozzá kapcsolódó oktatás beszerzése Az ajánlatkérő neve, címe, távirati címe, telefon és telefax számai:

A DIÁKHITEL Rt. szoftver és hozzá kapcsolódó oktatás beszerzése Az ajánlatkérő neve, címe, távirati címe, telefon és telefax számai: A Diákhitel Központ Rt. a 2003. évi CXXIX. törvény (a továbbiakban: Kbt.) negyedik része alapján egyszerű közbeszerzési eljárást indít A DIÁKHITEL Rt. szoftver és hozzá kapcsolódó oktatás beszerzése tárgyában

Részletesebben

AZ EURÓPAI KÖZÖSSÉGEK BIZOTTSÁGA

AZ EURÓPAI KÖZÖSSÉGEK BIZOTTSÁGA AZ EURÓPAI KÖZÖSSÉGEK BIZOTTSÁGA Brüsszel, 24.5.2005 COM(2005) 203 végleges A BIZOTTSÁG KÖZLEMÉNYE A TANÁCSNAK, AZ EURÓPAI PARLAMENTNEK, AZ EURÓPAI GAZDASÁGI ÉS SZOCIÁLIS BIZOTTSÁGNAK ÉS A RÉGIÓK BIZOTTSÁGÁNAK

Részletesebben

IBM i. Szerviz és támogatás 7.1

IBM i. Szerviz és támogatás 7.1 IBM i Szerviz és támogatás 7.1 IBM i Szerviz és támogatás 7.1 Megjegyzés A kiadvány és a tárgyalt termék használatba vétele előtt olvassa el a Nyilatkozatok, oldalszám: 111 szakasz tájékoztatását. Ez

Részletesebben

URL-LEL ADOTT OBJEKTUM LETÖLTÉSE (1) URL-LEL ADOTT OBJEKTUM LETÖLTÉSE

URL-LEL ADOTT OBJEKTUM LETÖLTÉSE (1) URL-LEL ADOTT OBJEKTUM LETÖLTÉSE Programozás III HÁLÓZATKEZELÉS A hálózatkezeléshez használatos java csomag: java. net Hol találkoztunk már vele? Pl.: URL cim = this.getclass().getresource("/zene/valami_zene.wav"); De pl. adott URL-ről

Részletesebben

A Vidékért Egyesület képzési ajánlata 2012-re

A Vidékért Egyesület képzési ajánlata 2012-re w w w.v i d e ke r t. h u A Vidékért Egyesület képzési ajánlata 2012-re A képzésekre 100%-os támogatás igényelhető az MVH által utólagosan. - 1 - w w w.v i d e ke r t. h u Bemutatkozás Egyesületünk a Vidékért

Részletesebben

Általános Szerződési Feltételek

Általános Szerződési Feltételek Általános Szerződési Feltételek A jelen Általános Szerződési Feltételek (ÁSZF) tartalmazza a WebShop-Experts Kft. (4028 Debrecen, Kassai út 129. III. em. 301-308.; Cg. 09-09-012282) által üzemeltetett

Részletesebben

Bevezetés. Párhuzamos vetítés és tulajdonságai

Bevezetés. Párhuzamos vetítés és tulajdonságai Bevezetés Az ábrázoló geometria célja a háromdimenziós térben elhelyezkedő alakzatok helyzeti és metrikus viszonyainak egyértelműen és egyértelműen visszaállítható (rekonstruálható) módon történő való

Részletesebben

AllBestBid. Felhasználói kézikönyv az AllBestBid online aukciós szolgáltatás használatához. 2016. március DFL Systems Kft.

AllBestBid. Felhasználói kézikönyv az AllBestBid online aukciós szolgáltatás használatához. 2016. március DFL Systems Kft. AllBestBid Felhasználói kézikönyv az AllBestBid online aukciós szolgáltatás használatához 2016. március DFL Systems Kft. Tartalomjegyzék Általános leírás... 2. oldal Regisztráció... 2. oldal Saját árlejtések...

Részletesebben

ALKALMAZÁS MONITOROZÁS A MERCURY MONITORRAL A CLUSTERGRID INFRASTRUKTÚRÁN. Gombás Gábor, gombasg@sztaki.hu MTA SZTAKI

ALKALMAZÁS MONITOROZÁS A MERCURY MONITORRAL A CLUSTERGRID INFRASTRUKTÚRÁN. Gombás Gábor, gombasg@sztaki.hu MTA SZTAKI ALKAAZÁS MONITOROZÁS A MERCURY MONITORRAL A CLUSTERGRID INFRASTRUKTÚRÁN Gombás Gábor, gombasg@sztaki.hu MTA SZTAKI 1. Bevezető Napjainkban a grid technológiák használata egyre több területen válik elfogadottá

Részletesebben

Everlink Parkoló rendszer Felhasználói és Üzemeltetési útmutató

Everlink Parkoló rendszer Felhasználói és Üzemeltetési útmutató Everlink Parkoló rendszer Felhasználói és Üzemeltetési útmutató Kiemelt magyarországi disztribútor: LDSZ Vagyonvédelmi Kft. I. fejezet Általános ismertető Az EverLink a mai követelményeket maximálisan

Részletesebben

Szakdolgozat egy fejezetének tartalomjegyzéke

Szakdolgozat egy fejezetének tartalomjegyzéke Szakdolgozat egy fejezetének tartalomjegyzéke 2. A tanulásszervezés módszerei és eszközei a Moodle keretrendszerben... 2 2. 1. Tartalomkezelés... 2 2. 1. 1. Szöveges oldal hozzáadása... 2 2. 1. 2. Weboldal

Részletesebben

Adatkezelési tájékoztató

Adatkezelési tájékoztató Tiszántúli Első Hitelszövetkezet KM5. számú melléklet Adatkezelési tájékoztató Hatályos: 2016. május 01. Adatkezelési tájékoztató Bevezetés A Tiszántúli Első Hitelszövetkezet (a továbbiakban: [Hitelszövetkezet)

Részletesebben

Az 5-2. ábra két folyamatos jel (A és B) azonos gyakoriságú mintavételezését mutatja. 5-2. ábra

Az 5-2. ábra két folyamatos jel (A és B) azonos gyakoriságú mintavételezését mutatja. 5-2. ábra Az analóg folyamatjeleken - mielőtt azok további feldolgozás (hasznosítás) céljából bekerülnének a rendszer adatbázisába - az alábbi műveleteket kell elvégezni: mintavételezés, átkódolás, méréskorrekció,

Részletesebben

Bevezetés a Symbian operációs rendszerbe

Bevezetés a Symbian operációs rendszerbe 1. FEJEZET Bevezetés a Symbian operációs rendszerbe Napjainkban a mobilkommunikáció szerepe és piaca átalakulóban van. A pusztán távközlésre kialakított eszközből a technológiai fejlődés, a felhasználói

Részletesebben

Informatika szintmérő-érettségi tételek 2015. február

Informatika szintmérő-érettségi tételek 2015. február 1.oldal (18) Rendszer karbantartása Rendszerkarbantartás fogalma: Minden operációs rendszer tartalmaz eszközöket a hardver- és a szoftverkomponensek karbantartására. Idesoroljuk a hardveralkotók szoftveres

Részletesebben

TÁMOP 4.1.1 VIR alprojekt VIR felhasználói kézikönyv

TÁMOP 4.1.1 VIR alprojekt VIR felhasználói kézikönyv 1. sz. melléklet TÁMOP 4.1.1 VIR alprojekt Készítette: Aloha Informatika Kft. Tartalomjegyzék 1. A Vezetői Információs Rendszer, mint a stratégiai gondolkodás eszköze...4 1.1 Elméleti háttér...4 1.2 VIR

Részletesebben

Általános Szerződési Feltételek

Általános Szerződési Feltételek Általános Szerződési Feltételek A jelen Általános Szerződési Feltételek ( ÁSZF ) a kereskedelemről szóló 2005. évi CLXIV törvény, az elektronikus kereskedelmi szolgáltatások, valamint az információs társadalommal

Részletesebben

(Kötelezően közzéteendő jogi aktusok)

(Kötelezően közzéteendő jogi aktusok) 2004.11.20. L 345/1 I (Kötelezően közzéteendő jogi aktusok) A BIZOTTSÁG 1973/2004/EK RENDELETE (2004. október 29.) az 1782/2003/EK tanácsi rendelet IV. és IVa. címeiben meghatározott támogatási rendszereket,

Részletesebben

TARTALOMMUTATÓ. 1. A Társulás 2009. évi költségvetési határozatának módosítása.

TARTALOMMUTATÓ. 1. A Társulás 2009. évi költségvetési határozatának módosítása. TARTALOMMUTATÓ 1. A Társulás 2009. évi költségvetési határozatának módosítása. 2. A SZOI pótelőirányzat kérelme. 3. Pályázati lehetőség A térségi közigazgatási és közszolgáltatási informatikai rendszerek

Részletesebben

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK INTERNETSZOLGÁLTATÁSRA. Szolgáltató: Station Net Kereskedelmi És Szolgáltató Kft.

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK INTERNETSZOLGÁLTATÁSRA. Szolgáltató: Station Net Kereskedelmi És Szolgáltató Kft. ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK INTERNETSZOLGÁLTATÁSRA Szolgáltató: Station Net Kereskedelmi És Szolgáltató Kft. Szolgáltatás megnevezése: internet-hozzáférési (elérési) szolgáltatás, helyhez kötött Készítés

Részletesebben

Általános szerzôdési feltételek

Általános szerzôdési feltételek Általános szerzôdési feltételek Hatálybalépés napja: 2013.05.01. www.fizessenmobillal.hu I. fejezet ALAPFOGALMAK, AZ ÁLTALÁNOS SZERZÕDÉSI FELTÉTELEK HATÁLYA, TÁRGYA ALAPFOGALMAK, AZ ÁLTALÁNOS SZERZŐDÉSI

Részletesebben

Gyarmati Dezső Sport Általános Iskola. Informatika HELYI TANTERV 6-8. ÉVFOLYAM. KÉSZÍTETTE: Oroszné Farkas Judit Dudásné Simon Edit

Gyarmati Dezső Sport Általános Iskola. Informatika HELYI TANTERV 6-8. ÉVFOLYAM. KÉSZÍTETTE: Oroszné Farkas Judit Dudásné Simon Edit Gyarmati Dezső Sport Általános Iskola Informatika HELYI TANTERV 6-8. ÉVFOLYAM KÉSZÍTETTE: Oroszné Farkas Judit Dudásné Simon Edit MISKOLC 2015 Összesített óraterv A, Évfolyam 6. 7. 8. Heti 1 1 1 óraszám

Részletesebben

Az információs társadalom lehetőségeivel csak azok a személyek tudnak megfelelő módon élni, akik tudatosan alkalmazzák az informatikai eszközöket,

Az információs társadalom lehetőségeivel csak azok a személyek tudnak megfelelő módon élni, akik tudatosan alkalmazzák az informatikai eszközöket, INFORMATIKA Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök használata olyan eszköztudást

Részletesebben

Szuperszerviz Általános vállalási feltételek

Szuperszerviz Általános vállalási feltételek Szuperszerviz Általános vállalási feltételek Szuperszerviz Általános vállalási feltételek A szolgáltató adatai Magyar Telekom Távközlési Részvénytársaság Székhely: 1013 Budapest, Krisztina krt. 55. Cégjegyzékszám:

Részletesebben

Ingatlanvagyon értékelés

Ingatlanvagyon értékelés Nyugat-Magyarországi Egyetem Geoinformatikai Kar Ingatlanfejlesztı 8000 Székesfehérvár, Pirosalma u. 1-3. Szakirányú Továbbképzési Szak Ingatlanvagyon értékelés 2. Számviteli alapok Szerzı: Harnos László

Részletesebben

Aronic Főkönyv kettős könyvviteli programrendszer

Aronic Főkönyv kettős könyvviteli programrendszer 6085 Fülöpszállás, Kiskunság tér 4. Internet: www.cin.hu E-mail: software@cin.hu Tel: 78/435-081, 30/9-573-673, 30/9-593-167 kettős könyvviteli programrendszer v2.0 Szoftverdokumentáció Önnek is jár egy

Részletesebben

Szervezeti és Működési Szabályzat

Szervezeti és Működési Szabályzat - 1 - Szervezeti és Működési Szabályzat A Veszprémi Tiszti Kaszinó Hagyományőrző Egyesület működésének és ügyrendjének szabályozására Jelen Szervezeti és Működési Szabályzatot a Veszprémi Tiszti Kaszinó

Részletesebben

Budapest Józsefváros Önkormányzatának. 37/2003. (VII.07.) ök. sz. rendelete

Budapest Józsefváros Önkormányzatának. 37/2003. (VII.07.) ök. sz. rendelete Budapest Józsefváros Önkormányzatának 37/2003. (VII.07.) ök. sz. rendelete a Budapest Józsefvárosi Önkormányzat vagyonáról, valamint a versenyeztetés és a helyi költségvetési szervek beszerzési eljárásának

Részletesebben

A nemzetközi vándorlás hatása a magyarországi népesség számának alakulására 1994 2010 között 1

A nemzetközi vándorlás hatása a magyarországi népesség számának alakulására 1994 2010 között 1 Hablicsek László Tóth Pál Péter A nemzetközi vándorlás hatása a magyarországi népesség számának alakulására 1994 2010 között 1 A magyarországi népesség-előreszámítások eddig a zárt népesség elvén készültek,

Részletesebben

Mérés és értékelés a tanodában egy lehetséges megközelítés

Mérés és értékelés a tanodában egy lehetséges megközelítés Mérés és értékelés a tanodában egy lehetséges megközelítés Baráth Szabolcs Fejes József Balázs Kasik László Lencse Máté 2016 Javaslat tanodák számára a mérési és értékelési kultúrájuk megújításához Tartalom

Részletesebben

Workflow és Petri hálók. Workflow fogalma

Workflow és Petri hálók. Workflow fogalma Workflow és Petri hálók Workflow fogalma Mai világunkban egyre nagyobb szerepet kapnak a workflow által irányított rendszerek és a workflow alapú szemléletek. A workflow, vagy munkafolyamat definícióját

Részletesebben

KIEMELT PROJEKT PÁLYÁZATI FELHÍVÁS a Társadalmi Megújulás Operatív Program

KIEMELT PROJEKT PÁLYÁZATI FELHÍVÁS a Társadalmi Megújulás Operatív Program KIEMELT PROJEKT PÁLYÁZATI FELHÍVÁS a Társadalmi Megújulás Operatív Program XXI. századi közoktatás (fejlesztés, koordináció) II. szakasz c. pályázathoz Kódszám: TÁMOP- 3.1.1-11/1 Tartalom A. A TÁMOGATÁS

Részletesebben

INFORMATIKA HELYI TANTERV

INFORMATIKA HELYI TANTERV INFORMATIKA HELYI TANTERV Az alsó tagozatos informatikai fejlesztés során törekedni kell a témához kapcsolódó korosztálynak megfelelő használatára, az informatikai eszközök működésének bemutatására, megértésére

Részletesebben

FELHASZNÁLÓI ÚTMUTATÓ

FELHASZNÁLÓI ÚTMUTATÓ Számítástechnikai Fejlesztı Kft. FELHASZNÁLÓI ÚTMUTATÓ E-SZIGNÓ KÁRTYAKEZELİ ALKALMAZÁS ver. 1.0 2010. november 9. MICROSEC SZÁMÍTÁSTECHNIKAI FEJLESZTİ KFT. 1022 BUDAPEST, MARCZIBÁNYI TÉR 9. Felhasználói

Részletesebben

Az Összetett hálózatok vizsgálata elektronikus tantárgy részletes követeleményrendszere

Az Összetett hálózatok vizsgálata elektronikus tantárgy részletes követeleményrendszere Az Összetett hálózatok vizsgálata elektronikus tantárgy részletes követeleményrendszere Horváth Árpád 2014. február 7. A tárgy célja: Az összetett hálózatok fogalomrendszerének használata a tudomány több

Részletesebben

KIBOCSÁTÓI TÁJÉKOZTATÓ V 1.0. Tájékoztató anyag az elektronikus számlakibocsátói oldal számára

KIBOCSÁTÓI TÁJÉKOZTATÓ V 1.0. Tájékoztató anyag az elektronikus számlakibocsátói oldal számára Tájékoztató anyag az elektronikus számlakibocsátói oldal számára 2/17 Tartalomjegyzék Tájékoztató anyag az elektronikus számlakibocsátói oldal számára... 1 Tartalomjegyzék... 2 1. Dokumentum célja... 3

Részletesebben

2016 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED

2016 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED Tavasz 2016 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED Department of Software Engineering Számítógép-hálózatok 10. gyakorlat IP-címzés Somogyi Viktor, Jánki Zoltán Richárd S z e g e d i

Részletesebben

29 darab defibrillátor beszerzése

29 darab defibrillátor beszerzése 29 darab defibrillátor beszerzése tárgyú közbeszerzési eljárás AJÁNLATI DOKUMENTÁCIÓ (Eljárás száma: 15/TB-294/12) 2012. A. ÁLTALÁNOS TUDNIVALÓK 1. Az eljárás 1.1. A Budapesti Közlekedési Zártkörűen Működő

Részletesebben

komplex védelem Letöltő szoftver ismertető V1.61 Azonosító: EP-13-13243-01 Budapest, 2004. február

komplex védelem Letöltő szoftver ismertető V1.61 Azonosító: EP-13-13243-01 Budapest, 2004. február EuroProt komplex védelem Letöltő szoftver ismertető V1.61 Azonosító: EP-13-13243-01 Budapest, 2004. február Tartalomjegyzék 1 Bevezetés...3 1.1 Az EuroProt rendszer központi egysége...3 1.2 A CPU rendszer

Részletesebben

Bosch Recording Station. Telepítési kézikönyv

Bosch Recording Station. Telepítési kézikönyv Bosch Recording Station hu Telepítési kézikönyv Bosch Recording Station Tartalomjegyzék hu 3 Tartalomjegyzék 1 Biztonsági tudnivalók 6 1.1 Alkalmazott biztonsági jelölések 6 1.2 Telepítés/konfigurálás

Részletesebben

AZ 50 ÉV FELETTI ÁLLÁSKERESŐK ELHELYEZKEDÉSÉT SEGÍTŐ TÁMOGATÁSI RENDSZER MAGYARORSZÁGON, BARANYA MEGYÉBEN

AZ 50 ÉV FELETTI ÁLLÁSKERESŐK ELHELYEZKEDÉSÉT SEGÍTŐ TÁMOGATÁSI RENDSZER MAGYARORSZÁGON, BARANYA MEGYÉBEN AZ 50 ÉV FELETTI ÁLLÁSKERESŐK ELHELYEZKEDÉSÉT SEGÍTŐ TÁMOGATÁSI RENDSZER MAGYARORSZÁGON, BARANYA MEGYÉBEN Pécs-Baranyai Kereskedelmi és Iparkamara Pécs, 2013. Tartalomjegyzék: 1. Az 50 év felettiek munkaerő-piaci

Részletesebben

MultiMédia az oktatásban Zsigmond Király Fıiskola Budapest, 2008. szeptember 25 26.

MultiMédia az oktatásban Zsigmond Király Fıiskola Budapest, 2008. szeptember 25 26. BODNÁR KÁROLY 1 DR. KÖDMÖN JÓZSEF 2 KRISTÓF ZSOLT 3 Felhasználó-azonosítás alternatívái elearning rendszerekben DE Egészségügyi Kar, Egészségügyi Informatika Tanszék 1 bcharles@de-efk.hu, 2 kodmonj@de-efk.hu,

Részletesebben

általános szerződési feltételek

általános szerződési feltételek általános szerződési feltételek Vállalkozói e-bank szolgáltatás Hatályos: 2004. január. 19 napjától I. FOGALMAK Az itt felsorolt kifejezések a jelen Általános Szerződési Feltételekben (a továbbiakban:

Részletesebben

A SZOFTVER TELEPÍTÉSE ELŐTT TELEPÍTÉS WINDOWS KÖRNYEZETBEN TELEPÍTÉS MACINTOSH KÖRNYEZETBEN HIBAKERESÉS

A SZOFTVER TELEPÍTÉSE ELŐTT TELEPÍTÉS WINDOWS KÖRNYEZETBEN TELEPÍTÉS MACINTOSH KÖRNYEZETBEN HIBAKERESÉS Szoftvertelepítési útmutató A SZOFTVER TELEPÍTÉSE ELŐTT TELEPÍTÉS WINDOWS KÖRNYEZETBEN TELEPÍTÉS MACINTOSH KÖRNYEZETBEN HIBAKERESÉS Köszönjük, hogy megvásárolta termékünket. Ez a kézikönyv leírja, hogyan

Részletesebben

Párhuzamos és Elosztott Rendszerek

Párhuzamos és Elosztott Rendszerek MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR Párhuzamos és Elosztott Rendszerek KÉSZÍTETTE: DR. MILEFF PÉTER Miskolci Egyetem Általános Informatikai Tanszék 2009 1 Szuperszámítógépektıl napjainkig

Részletesebben

HEFOP 3.5.1 Korszer feln ttképzési módszerek kidolgozása és alkalmazása. A szakképzés rendszere

HEFOP 3.5.1 Korszer feln ttképzési módszerek kidolgozása és alkalmazása. A szakképzés rendszere HEFOP 3.5.1 Korszer feln ttképzési módszerek kidolgozása és alkalmazása A szakképzés rendszere Budapest, 2008 II. A szakképzés rendszere Tanácsadó Testület elnöke: Dr. Hunyadi György Alkotószerkeszt k:

Részletesebben

SEGÉDLET a jegyzők felkészüléséhez a helyi önkormányzati képviselők és polgármesterek 2010. évi választásán

SEGÉDLET a jegyzők felkészüléséhez a helyi önkormányzati képviselők és polgármesterek 2010. évi választásán VÁLASZTÁSI FÜZETEK 172. SEGÉDLET a jegyzők felkészüléséhez a helyi önkormányzati képviselők és polgármesterek 2010. évi választásán KÖZIGAZGATÁSI ÉS IGAZSÁGÜGYI MINISZTÉRIUM ORSZÁGOS VÁLASZTÁSI IRODA VÁLASZTÁSI

Részletesebben

az Életünk fordulópontjai című társadalmi, demográfiai panelfelvétel IV. hullámához (az adatfelvétel engedélyezési száma: 1961/2012)

az Életünk fordulópontjai című társadalmi, demográfiai panelfelvétel IV. hullámához (az adatfelvétel engedélyezési száma: 1961/2012) NKI KÖZPONTI STATISZTIKAI HIVATAL NÉPESSÉGTUDOMÁNYI KUTATÓINTÉZET 1024 BUDAPEST, BUDAY LÁSZLÓ UTCA 1-3. TELEFON: (36-1) 345-6320, (36-1) FAX: (36-1) 345-1115 WEB: WWW.DEMOGRAFIA.HU E-MAIL: NKI@DEMOGRAFIA.HU

Részletesebben

Irinyi József Általános Iskola 4274 Hosszúpályi Szabadság tér 30. 031154. HELYI TANTERV Informatika 4. osztály 2013

Irinyi József Általános Iskola 4274 Hosszúpályi Szabadság tér 30. 031154. HELYI TANTERV Informatika 4. osztály 2013 Irinyi József Általános Iskola 4274 Hosszúpályi Szabadság tér 30. 031154 HELYI TANTERV Informatika 4. osztály 2013 Informatika az általános iskola 4. évfolyama számára (heti 1 órás változat) Az alsó tagozatos

Részletesebben

BorderManager Enterprise Edition

BorderManager Enterprise Edition BorderManager Enterprise Edition A Novell BorderManager Enterprise Edition egy átfogó, a Novell-címtárszolgáltatásra (NDS-re) épülő biztonsági felügyeleti termékcsomag. Az NDS funkcióit kihasználva lehetővé

Részletesebben

GroupWise 5.2 használói jegyzet

GroupWise 5.2 használói jegyzet GroupWise 5.2 használói jegyzet 32 bites verzió Készítette: Borsodi Gábor, ABS Consulting Kft. (http://www.abs.hu) 1998-2001 Ez a dokumentáció szabadon felhasználható (nyomtatható, másolható) és terjeszthet,

Részletesebben

Penta Unió Zrt. Az Áfa tükrében a zárt illetve nyílt végű lízing. Név:Palkó Ildikó Szak: forgalmi adó szakirámy Konzulens: Bartha Katalin

Penta Unió Zrt. Az Áfa tükrében a zárt illetve nyílt végű lízing. Név:Palkó Ildikó Szak: forgalmi adó szakirámy Konzulens: Bartha Katalin Penta Unió Zrt. Az Áfa tükrében a zárt illetve nyílt végű lízing Név:Palkó Ildikó Szak: forgalmi adó szakirámy Konzulens: Bartha Katalin Tartalom 1.Bevezetés... 3 2. A lízing... 4 2.1. A lízing múltja,

Részletesebben