extreme Transaction Processing

Átírás

1 extreme Transaction Processing Oracle WebLogic Alkalmazás Szerver Oracle Event Szerver Kerekes András június 10.

2 Tartalom Bevezetés WebLogic Server Cluster Work Manager-ekek WebLogic Store-and-Forward (JMS, WSRM) WebLogic Diagnostic Framework Oracle Event Szerver június 10.

3 Elosztott rendszerek Az elosztott rendszerek a feladatok elvégzését szétosztják több, egymástól független modul között A modulok jóval egyszerűbbek, kisebb problémakör megoldására szakosodtak Együtt dolgoznak a feladat végrehajtásában Előnyei: Magas rendelkezésre állás egy modul kiesése nem okoz gondot Skálázhatóság könnyen bővíthető az igényeknek megfelelően alacsonyabb indulási költségek Könnyebb karbantartás (szoftver üzemeltetés) az alkalmazások is különálló, önállóan is menedzselhető komponensekből állnak Hátrányai: A szétszórt komponensek munkáját össze kell hangolni Foglalkozni kell a komponensek közötti kommunikációval június 10.

4 WLS Cluster A WebLogic szerverek egy olyan csoportja, amelyek együttesen biztosítják a kliensek számára a szerveroldali erőforrásokhoz, szolgáltatásokhoz való hozzáférést A cluster a kliensek számára teljesen átlátszó, egy WLS példányként látszik A cluster biztosítja: a magas rendelkezésre állást a megfelelő terhelés elosztás és a hibatűrő architektúra segítségével a könnyű skálázhatóságot június 10.

5 WebLogic cluster tulajdonságai Terhelés elosztás A végrehajtandó feladatok és a kommunikáció ió egyenletes elosztása a cluster-ben futó szerver példányok között Alkalmazás szintű failover Az alkalmazás egy komponensének meghibásodása esetén az adott komponens egy másolata veszi át a feladatok végrehajtását Site failover MAN és WAN esetén, ha egy site-on lévő összes szolgáltatás és alkalmazás elérhetetlenné válik, akkor egy másik site veszi át a végrehajtást Szolgáltatás migráció Egy pinned service meghibásodása esetén lehetőség van az adott szolgáltatás másik WLS példányra való migrációjára Szerver migráció Egy WLS példány meghibásodása esetén lehetséges a teljes szerver környezet automatikus, vagy manuális migrációja egy másik fizikai környezetre június 10.

6 Cluster architektúrák Alkalmazás szintű klaszterezési technológiák A nagyvállalati alkalmazásokat általában több rétegűek, melyek speciális feladatokat végeznek: Web-es réteg (statikus web-es tartalom) Prezentációs réteg (dinamikus megjelenítési réteg) Üzleti logikát tartalmazó réteg A WebLogic alkalmazás szerver támogatja a különböző alkalmazás rétegek klaszteres környezetben való futtatását Infrastruktúra klaszterezése A WebLogic biztosítja az infrastrukturális szolgáltatások klaszteres környezetben való futását is Bizonyos szolgáltatások esetén a terhelés elosztás és a failover speciális szabályok alapján működik (JMS, JDBC) június 10.

7 Cluster architektúrák A megfelelő klaszter architektúra kiválasztása mindig szubjektív szempontok alapján történik Az adott környezeti sajátosságok alapján és az üzleti alkalmazásokkal szemben támasztott követelményeknek megfelelően kell kialakítani A következő általános szempontokat érdemes figyelembe venni: Teljesítmény Hatékony perzisztencia réteg Optimális terhelés elosztás Hatékony failover Megbízható kommunikáció Két fő architektúra modell: Alap (basic) architektúra Több rétegű (multi-tier) architektúra június 10.

8 Cluster architektúrák Basic: Egyszerű konfigurálni és adminisztrálni A web-es és üzleti logikai réteg ugyanazon a szerveren vannak teljesítményben ez a legjobb Az EJB hívások nem lesznek szétosztva a cluster lábak között Nincs rétegek közötti terheléselosztás Több rétegű: Kifinomultabb terhelés elosztási lehetőségek (EJB metódus hívások) Magasabb rendelkezésre állás Magasabb kommunikációs költségek Nagyobb licenc költségek június 10.

9 Terhelés elosztás A végrehajtandó feladatok szétosztása a cluster lábai között Hardveres load balancer-ek: Ez a drágább megoldás, de jobb a teljesítményük, mint szoftveres terhelés elosztó komponenseknek. Cisco, Foundry Networks, Big IP Szoftveres load balancer-ek WebLogic HTTPClusterServlet web alkalmazásként telepíthető egy önálló managed szerverre Third-party proxy szerverek használatát plugin-ekkel támogatja a WebLogic Apache Netscape Enterprise Server Microsoft Internet Information Server Algoritmusok: Round-Robin, Weight-based, Load based, Random június 10.

10 HTTP session replikáció A web-es réteg a hibatűrő kialakításának eszköze A WebLogic szerver HTTP session replikációs lehetőségei működés mód szerint: Szinkron: minden tranzakció commit esetén, vagy minden változás esetén, ha nincs tranzakció Aszinkron: meghatározott időközönként Session tárolása szerint: Memóriában (in-memory replication) Adatbázisban (JDBC replication) Fájl rendszerben (File system replication) június 10.

11 Memóriában történő session replikáció A Session objektum csak két WebLogic szerver példányban létezik egyidejűleg (elsődleges és backup) A backup szerver kiválasztása automatikusan történik, de befolyásolható az algoritmus a fizikai gépek és a replikációs csoportok gondos beállításával Az elsődleges szerver hibája esetén a backup szerver válik elsődlegessé és egy új backup szerver kerül kiválasztásra A backup meghibásodása esetén automatikusan új backup kerül kiválasztásra június 10.

12 Adatbázisban történő session replikáció A cluster összes session objektumát egy közös adatbázisban tároljuk Minden szerver példány hozzáférhet az összes session objektumhoz Azonos klienstől érkező kéréseket több különböző szerver is kiszolgálhat A gyakori adatbázis műveletek performancia visszaesést okozhatnak Hibatűrőbb architektúra június 10.

13 File rendszerben történő session replikáció A cluster összes session objektumát közös file rendszerben tároljuk Minden szerver példány hozzáférhet az összes session objektumhoz Azonos klienstől érkező kéréseket több különböző szerver is kiszolgálhat Hibatűrőbb architektúra A teljesítmény csökkenés elhanyagolható a hatékony file rendszer kezelésnek köszönhetően június 10.

14 EJB réteg működése cluster-es környezetben A failover és terheléselosztás ún. replica- és cluster-aware stub-ok segítségével történik. Ezeket a fordító készíti el, a fejlesztőknek nem kerül plusz munkába Statless Session Bean-ek: A metódushívások között nincs kapcsolat, ezért a hívásokat bármelyik láb kiszolgálhatja A Home és Remote Stub is replica- és cluster-aware, bármelyik szerverre továbbíthatja a hívásokat A metódusok futása közben bekövetkező hibák kezelésére csak speciális, idempotens műveletek esetén van lehetőség Stateful Session Bean-ek: Hívások közötti belső állapottal rendelkeznek A Home stub load-balance-ol, bármelyik szerveren létrehozhatja az EJB-t A Remote stub már hozzá van kötve az adott szerver példányhoz, minden metódust ugyanazon a szerveren hív meg Létrejön egy replika egy backup szerveren, a HTTP Session replikációhoz hasnoló módon Hálózati kommunikációs hiba esetén a replica-aware stub a backup szerveren lévő EJBhez fordul. Entity Bean-ek: Read-only entitások táso esetén a WebLogic támogatja a terhelés e elosztó algoritmusok alkalmazását és a failover-t (idempotens metódusokra) minden metódushívás esetén. A read-write entitások esetén csak a Home stub képes erre június 10.

15 Infrastrukturális szolgáltatások cluster-es es környezetben Klaszterezhető szolgáltatások automatikusan biztosítják a terhelés elosztás és failover lehetőségét (JNDI, JDBC (csak korlátozottan)) A pinned szolgáltatásokat, amelyek hozzá vannak kötve egy-egy cluster lábhoz, automaikusan vagy manuálisan lehet migrálni egy másik szerver példányra (JMS, JTA) Lehetséges egy teljes WebLogic szerver példány automatikus, vagy manuális migrációja is június 10.

16 Cluster tuning Alkalmazás hangolás: Minimalizáljuk a távoli metódushívásokat Kerüljük az Entity-k Web-es rétegbeli használatát Alkalmazzuk a Session facade tervezési mintát és használjunk DTO-kat az adatok alkalmazás rétegek közötti továbbításához (fejlesztői feladat) Peer-to-peer kommunikáció hangolása: Lehetőség szerint mindig a native socket implementációt használjuk a pure- Java implementáció helyett (üzemeltetői feladat, admin console-on lehet beállítani) Multicast kommunikáció hangolása: Ha a cluster valamelyik lába nem képes időben feldolgozni a multicast üzeneteket, akkor azokat a küldő újraküldheti, ami ún. multicast-storm-hoz vezethet. Ezt vagy a multicast buffer méretének növelésével lehet kiköszöbölni, vagy az adott szerver példány hangolásával (nagyobb heap size, GC beállítások) június 10.

17 Work Manager-ek (self-tuning) A WebLogic 10-es verziójában jelent meg ez a hatékony eszköz a végrehajtási szálak egyszerűsített kezelésére Az új koncepció szerint csak egy thread-pool létezik, ennek méretét változtatja automatikusan a WebLogic Szerver az teljesítmény maximalizálására törekedve (self-tuning) A thread pool folyamatosan monitorozza a teljesítményt és az összegyűjtott adatoknak megfelelően csökkenti, vagy növeli a méretét. A WebLogic négy szempont alapján priorizálja a végrehajtandó feladatokat június 10. Üzemeltető/fejlesztő által megadott paraméterek (Work manager beállítások) Futási idejű rendszer adatok Egy-egy kérés é kiszolgálásnak k ideje Beérkező és kiszolgált kérések aránya adott időszakban Alaphelyzetben létezik egy default Work Manager és a WLS minden alkalmazáshoz ennek segítségével rendeli hozzá a végrehajtási szálakat, egyenlő elosztásban minden alkalmazás egyforma prioritású. Szükség esetén változtathatunk ezeken a beállításokon: Globálisan Alkalmazás, web alkalmazás szinten Komponens (EJB) szinten

18 Work Manager komponensek 1. Request Class-ok: Fair-share-request-class segítségükkel arányosan lehet elosztani a rendelkezésre álló végrehajtási szálakat az adott komponens(ek)hez érkező kérések között Response-time-request-class Az adott komponenshez érkező kérésekre vonatkozó elvárt válaszidőt lehet definiálni a segítségével Context-request-class A request kontextusban lévő információk alapján lehet összerenelni az előbbi request osztályokat a request-ekkel A Work Manager-eket és az általuk menedzselt alkalmazásokat/komponenseket a weblogic specifikus deployment descriptor-okban lehet összerendelni június 10.

19 Work Manager komponensek 2. Korlátozások (Constraints): Szabályozni lehet az adott work manager-hez tartozó minimális és maximális végrehajtási szálak számát, valamint a sorban álló és éppen futó szálak száma is maximalizálható a dead-lock elkerülése végett Maximálisan felhasználható szálak korlátozása: Maximum az itt megadott számú végrehajtási szálat allokálja a feladatok végrehajtásához Minimális szálszám korlátozás: Garantálja a megadott számú végrehajtási szál allokálását Kapacitás korlátozás: A WLS eldobja a kéréseket, ha az itt megadottnál több kérés várakozik kiszolgálásra, vagy éppen folyamatban van a kiszolgálása június 10.

20 Work Manager Egy Work Manager egy request osztályból és/vagy egy korlátozásból állhat június 10.

21 WebLogic Store-and-Forward A hatékony, WebLogic szerver példányokon átívelő, aszinkron kommunikáció eszköze Megbízható üzenet alapú kommunikációt tesz lehetővé A küldő fél által továbbított üzenet akkor is eljut a címzetthez, ha az a küldés pillanatában nem érhető el Ha fogadó fél nem elérhető, akkor az üzenetet a SAF szolgáltatás eltárolja a memóriában, vagy valamilyen perzisztens tárolóban (file rendszer, adatbázis) és csak akkor továbbítja, ha a címzett újra elérhető lesz Két üzenet alapú kommunikáció esetén használható: WebLogic JMS-ek közötti kommunikáció Web Service-ek közötti kommunikáció (WSRM) Előnyei: Gyors, megbízható üzenet továbbítás távoli szerver példányok között. Használata teljesen transzparens az alkalmazások és így a fejlesztők számára Hátrányai: Nem használható a WebLogic korábbi verzióival Csak a WebLogic JMS implementációjával működik együtt június 10.

22 június 10. Store-and-Forward komponensek

23 Store-and-Forward komponensek Local Weblogic Server Remote Weblogic Server június 10.

24 Web Service Reliable Messaging (WSRM) Lehetővé teszi, hogy az alkalmazás szerveren futó alkalmazások megbízható módon tudjanak kommunikálni egy másik, távoli alkalmazás szerveren futó Web Service-szel, ha mindkét alkalmazás szerver támogatja a WS-ReliableMessaging specifikációt (OASIS standard jún. 17.) A WebLogic WSRM teljes mértékben megfelel WS-ReliableMessaging specifikációnak Üzenet kézbesítési garancia szintek: At Most Once At Least Once Exactly Once In Order június 10.

25 SAF tuning SAF Agent attribútumainak hangolásával nagyfokú teljesítménynövekedés érhető el Conversation Idle Time Maximum Retry Delay Base Retry Delay Maximum Retry Delay Multiplier Time-To-Live Logging Enabled Window Size Window Interval Paging Directory Message Buffer Size Bytes threshold high/low Message threshold high/low Bytes maximum Message maximum Maximum message size június 10.

26 WebLogic Diagnostic Framework A WebLogic korábbi verzióiban cizellált naplózási lehetőségek és az Admin console, illetve a WLST eszközei álltak rendelkezésre a környezet monitorozására A 10-es verzióban jelent meg a WLDF, ami jelentősen növelte a monitorozási lehetőségek minőségét és összetettségét június 10.

27 WLDF komponensek 1. Data Creator-ok Bármelyik WebLogic alrendszer, komponens vagy alkalmazás Instrumentation: Segítségével é különálló diagnosztikai i kódrészleteket k t adhatunk a WebLogic szerver példányok, vagy cluster-ek, illetve a rajtuk futó alkalmazások meghatározott pontjaihoz Speciális data publisher Szerver, vagy alkalmazás szintű lehet Három részből áll: Diagnostic Monitors: dinamikusan menedzselhető diagnosztikai kódrészlet Standard: beégetett helyen és módon hajtja végre az beégetett action-t (szerver szintű) Delegating: a monitorozás helye be van égetve, de választható az action (szerver és alkalmazás szintű) Custom: választható a monitorozás helye és az action is (alkalmazás szintű) Diagnostic Action: ezt a tevékenységet hajtja végre a monitor WLDF action library: DisplaysArgumentsAction, StackDumpAction, ThreadDumpAction,TraceAction, TraceAction TraceElapsedAction Diagnostic Context: a request kontextus információi (például hívó fél IP címe) június 10.

28 WLDF komponensek 2. Data Collector-ok Diagnosztikai adatok összegyűjtésére szolgáló komponensek Harvester: adatok lekérdezésekkel történő gyűjtése Logger: a data publisher-ek ek által küldött adatok naplózása Data Accessor-ok: Diagnosztikai adatokhoz való hozzáférésre szolgáló komonensek Admin console és WLST Watches and Notifications: Dinamikusan konfigurálható körülményekre figyelnek és értesítést küldenek Segítségükkel vizsgálhatóak: Szerver log-okok Instrumentation alrendszer eseményei További diagnosztikai adatok Notification listener-ek: SMTP, SNMP, JMX, JMS, Diagnostic Image június 10.

29 WLDF komponensek 3. Archiváló komponens (Data Archiver): A WLDF összes diagnosztikai adatát archiválja egy előre megadott helyre (file vagy adatbázis) Szerverenként kell konfigurálni Diagnosztikai Image készítése (Diagnostic Image Capture): ) Egy pillanatfelvételt készít egy WebLogic szerver példányról Előre konfigurált helyen, tömörített formában tárolja a rendszer az image file-okat Történhet automatikusan (például szerver indulás, leállás esetén), vagy manuálisan június 10.

30 Oracle Complex Event Processing Napjaink gazdasági g alkalmazásai folyamatosan továbbítják az üzleti adatokat az arra feliratkozó fogadó feleknek Az Oracle CEP egy deklaratív környezetet nyújt esemény vezérelt alkalmazások fejlesztéséhez Előnyei: Valós idejű mintakeresés több különböző esemény forrásból érkező adatokban Másodpercenként több százezer esemény feldolgozására képes Könnyen integrálható más Oracle eszközökkel Piacvezető megoldás Gyakorlatilag egy lecsupaszított WebLogic Server és egy összetett esemény feldolgozó motor együttese, amely felhasználók által definiált szabályok segítségével dolgozza fel az üzeneteket június 10.

31 Oracle CEP infrastruktúra Komponensek: Adapterek: adat konverzió, események normalizálása Stream-ek: események sorba rendezése a feldolgozáshoz Event processor: szabályok alapján feldolgozza l az üzeneteket, t majd az új özeneteket továbbítja az output stream-re User code: POJO, az output stream-re érkező üzenetek hatására indul el a működésük és továbbítják az üzeneteket a megfelelő helyre június 10.

32 Oracle CEP use case-ek Pénzügyi példa: kereskedés automatizálása példa query: ha 20 másodpercen belül az A termék ára több, mint 2%-kal csökken és a B termék ára változatlan marad, automatikusan vásárolj A-t Energia és/vagy tlekommunikáció csökkentsük a hamis risztások számát példa query: Ha 5 mp-en belül 15 jelzés érkezik, de 30 mp-en belül kevesebb, mint 5 azonos jelzés van, akkor ne történjen risztás Egészségügy é Páciens életjeleinek monitorozása Példa query: Ha a gyógyszeradag változtatása után 10 percen belül több, mint 20%-kal megnő a páciens vérnyomása, akkor értesítse a legközelebbi nővért június 10.

33 Köszönöm a figyelmet! Kérdések? június 10.