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 GS proxy Magic xpi szerver motor_1 GS proxy Magic xpi szerver motor_n GS proxy External Trigger Flow Worker Flow Worker Flow Worker Flow Worker Trigger Worker 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 Magic PU Management, Monitoring, Auditing, Alerting
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.