Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon
Mi az IMDG? Nem… memóriában futó relációs adatbázis NoSQL hagyományos relációs adatbázis
Más fajta adat tárolás Az összes adat RAM-ban van, osztott módban Szerverek hozzáadhatók / elvehetők menet közben Adat modell objektum alapú Hibatűrés és magas rendelkezésre állás Alacsony válaszidő – információt a memóriában tárol
Miért IMDG? Nagy mennyiségű tranzakció esetén, gyorsabb adatelérésre van szükség az üzleti elvárások miatt A klasszikus adatbázis-kezelők I/O műveletei lassúak, amelyek nincsenek az in-memory esetén
Alkalmazások is a memóriában helyezkednek el, ezáltal az IMDG komplett megoldást nyújt
Gigaspaces megoldása
Technológiai koncepció iBolt 3.x Middleware: Magic request broker
Technológiai koncepció Magic xpi 4.0 In-Memory Data Grid Klaszterezés Hibatűrés Végtelenül skálázható! Magasabb teljesítmény
Magic xpi 4.0 új szoftver komponensek Architektúra:
In-Memory Data Grid (Grid) Space Magic Processing Unit (PU) Magic xpi server Workers External triggers
Architektúra: In Memory Data Grid Middleware software Egyszerre többféle géptípuson fut (fizikai, virtuális)
Ezek együtt nagyméretű adatokat tartanak mindig memóriában!
Ezáltal lesz rugalmas, nagyteljesítményű, hibatűrő
Architektúra: Space Entitás, mely az adatokat és azok
logikáját foglalja magába, hasonló mint egy adatbázis-példány A Grid több Space-t tartalmazhat
A Magic xpi 4.0 egyetlen Space-t használ az összes projekthez Az adatok és a logikák az összes
Griden belüli gépre partícionálódnak (skálázás, hibatűrés megvalósítása)
Architektúra: Magic Processing Unit (PU) Szoftver modul, mely a Grid-ben fut Közvetlenül hozzáfér minden adathoz a Space-ben A Magic xpi 4.0 –ben egy PU komponens végzi az adminisztratív és karbantartási feladatokat: Engine indítás, leállítás Monitorozás Recovery Egyéb…
Architektúra: Magic xpi szerver Alkalmazás szerver szoftver Futtatja az integrációs logikát Minden Magic xpi process (engine) több szálból állhat (worker) Az összes worker együtt bármilyen integrációs logikát képes végrehajtani
Architektúra: Workers Flow worker – régi nevén flow: Rendszer elindulása után folyamatosan vár az őt indító kérésre (üzenetre). Ha ez bekövetkezik, a worker lefuttatja a kívánt flow-t ahogy az a projektben definiálva van.
Trigger worker – régi nevén trigger komponens: Figyeli a külső rendszer felöl érkező eseményeket Amint az esemény teljesül, üzenetet generál az esemény részleteivel, és a megfelelő szabad workert elindítja.
Szinkron Trigger: amennyiben visszatérési elem, érték szükséges, a trigger megvárja a flow eredményét, és azt visszaadja az őt meghívónak.
Architektúra: External triggers Olyan triggerek, melyek nem az engine alatt futnak worker triggerként, hanem a saját környezetükben futva indikálnak flow indítási kérelmet, jellemzően más alkalmazásokból. A HTTP trigger pl. egy modul a web szerver - IIS vagy Apache alatt. SOAP Web service trigger pl. egy külső trigger a Systinet alatt.
Architektúra: Ábra PU
PU
PU
PU
Space
Flow Worker
GS proxy
GS proxy
Magic xpi szerver motor_1
Magic xpi szerver motor_n
Flow Worker
Flow Worker
Flow Worker
Trigger Worker
GS proxy
External Trigger Trigger Worker
Magic Processing Unit Space-ben fut Gondoskodik a szerver hibamentes működéséről Központi management funkciókat lát el: Azonosítja az időtúllépéseket és helyreállítja azokat Azonsítja a megakadt/hibás worker-eket, szerverket és helyreállítja azokat Szétosztja a management üzeneteket a futó szerverek közt Teljesített flow kéréseket kipucolja Statisztikát készít a projekt elemeiről Management, Monitoring, Auditing, Alerting
Magic PU
Rendszer indítás
1. IMDG szolgáltatás, majd Magic space és Magic PU a gridben IMDG Indítás: A magic xpi szolgáltatásként telepíti a Windows alatt, vagy init daemonként Unix esetében. Az IMDG indítási beállításokat egy konfig file tartalmazza. 2. Magic xpi projekt indítása/leállítása: kézi vagy automatikus Az új konfig állománnyal:
Több különböző projekt indítható Egy projekthez több motor is indítható Kontrollálható, hogy a gridben melyik motor fut
Magic xpi projekt indításának folyamata A Magic xpi projekt több motort futtathat több szerveren Az első Magic xpi szerver csatlakozik a space-hez és az alábbi
sorrendben Frissíti a space-ben a projekt meta-adatot Frissíti a space-ben a szerver objektumokat (PU) Elindítja a flow worker szálakat Elindítja a trigger worker szálakat (ha vannak) Elindítja a scheduler-t (ha van) A többi szerver kapcsolódik a Space-hez és felkészül a projekt metaadat futtatására. A szerver azonosítja a projektet, és ha már fut, akkor kapcsolódik az elindult erőforrásokhoz.
Magic xpi projekt leállítás folyamata Egy megadható kifutási idővel teljesen leállítható a projekt
Ha egyszer a „leállás” parancsot kiadtuk, és letelt a leállási (türelmi) idő, akkor a projekt
Már nem szolgál ki új kérést (triggerek leállnak) A projekt folytatja a megkezdett procedúrát, amíg az véget nem ér.
