extreme Transaction Processing

eXtreme Transaction Processing Oracle WebLogic Alkalmazás Szerver Oracle Event Szerver Kerekes András

2009. június 10.

Tartalom „ Bevezetés „ WebLogic Server Cluster „ Work Manager Manager-ek ek „ WebLogic Store-and-Forward (JMS, WSRM) „ WebLogic Diagnostic Framework „ Oracle Event Szerver

2

2009. június 10.

Elosztott rendszerek

„ Az elosztott rendszerek a feladatok elvégzését szétosztják több 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: „ M Magas rendelkezésre d lk é állá állás – egy modul d l ki kiesése é nem okoz k gondot d t „ 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ó 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

3

2009. június 10.

WLS Cluster „ A WebLogic szerverek egy olyan csoportja 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ó átlátszó, egy WLS példányként látszik

„ A cluster biztosítja: j „ 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

4

2009. június 10.

WebLogic cluster tulajdonságai „ Terhelés elosztás A végrehajtandó é h jt dó ffeladatok l d t ké és a kkommunikáció iká ió egyenletes l t elosztása l tá a cluster-ben l t b 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 E éldá meghibásodása hibá dá esetén té llehetséges h t é a tteljes lj szerver kö környezett automatikus, vagy manuális migrációja egy másik fizikai környezetre 5

2009. június 10.

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)

6

2009. június 10.

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 y sajátosságok j g alapján pj é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

7

2009. június 10.

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

8

2009. június 10.

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

9

2009. június 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 (in memory replication) „ Adatbázisban (JDBC replication) „ Fájl rendszerben (File system replication)

10

2009. június 10.

Memóriában történő session replikáció

„ A Session objektum csak két WebLogic szerver „

„ „

11

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 g g gondos beállításával Az elsődleges szerver hibája esetén a backup szerver válik elsődlegessé g és egy gy újj backup p szerver kerül kiválasztásra A backup meghibásodása esetén automatikusan p kerül kiválasztásra újj backup

2009. június 10.

Adatbázisban történő session replikáció

„ A cluster összes session „ „ „ „

12

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

2009. június 10.

File rendszerben történő session replikáció

„ A cluster összes session „ „ „ „

13

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

2009. június 10.

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. „

„

„

14

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 replica- és cluster cluster-aware, 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 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 ead o y e entitások t táso eseté esetén a WebLogic eb og c tá támogatja ogatja a te terhelés e és e elosztó os tó a algoritmusok go t uso 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.

2009. június 10.

Infrastrukturális szolgáltatások cluster 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 (JMS, JTA)

„ Lehetséges egy teljes WebLogic szerver példány automatikus, vagy manuális migrációja is

15

2009. június 10.

Cluster tuning

„ Alkalmazás hangolás: g „ 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 DTO kat az adatok alkalmazás rétegek közötti továbbításához (fejlesztői feladat)

„ Peer Peer-to-peer to peer kommunikáció hangolása: „ Lehetőség szerint mindig a native socket implementációt használjuk a pureJava 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) 16

2009. június 10.

Work Manager-ek (self-tuning)

„ A WebLogic g 10-es verziójában j jjelent meg g ez a hatékony y eszköz a végrehajtási g j „ „ „

„ „

17

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 ( lf t i ) (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 „ Üzemeltető/fejlesztő által megadott paraméterek (Work manager beállítások) „ Futási idejű rendszer adatok „ Egy-egy E ké é ki kérés kiszolgálásnak l álá k id ideje j „ 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 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

2009. június 10.

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 p érkező kérésekre vonatkozó elvárt válaszidőt lehet definiálni a segítségével

„ Context-request-class A request q 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 18

2009. június 10.

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 j a megadott g számú végrehajtási g j 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

19

2009. június 10.

Work Manager

„ Egy gy Work Manager g egy gy request q osztályból y és/vagy gy egy gy korlátozásból állhat

20

2009. június 10.

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ő elérhető, akkor az üzenetet a SAF szolgáltatás eltárolja a memóriában 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

21

2009. június 10.

Store-and-Forward komponensek

22

2009. június 10.

Store-and-Forward komponensek

Local Weblogic Server

23

2009. június 10.

Remote Weblogic Server

Web Service Reliable Messaging (WSRM)

„ Lehetővé teszi,, hogy gy 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– 2007. jún. 17.)

„ A WebLogic WSRM teljes mértékben megfelel WS-ReliableMessaging WS ReliableMessaging specifikációnak

„ Üzenet kézbesítési garancia szintek: „ At Most Once „ At Least Once „ Exactly Once „ In Order

24

2009. június 10.

SAF tuning

„ SAF Agent g attribútumainak hangolásával g nagyfokú gy teljesítménynövekedés j y érhető el „ „ „ „ „ „ „ „ „ „ „ „ „ „ „

25

2009. június 10.

Conversation Idle Time Maximum Retry Delay Base R t D Retry Delay l M Maximum i 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 B t maximum Bytes i Message maximum Maximum message size

WebLogic Diagnostic Framework

„ A WebLogic g 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 j meg a WLDF, ami jelentősen növelte a monitorozási lehetőségek minőségét és összetettségét

26

2009. június 10.

WLDF komponensek 1.

„ Data Creator-ok „ Bármelyik WebLogic alrendszer, komponens vagy alkalmazás

„ Instrumentation: „ Segítségével S ít é é l külö különálló álló di diagnosztikai tik i kód kódrészleteket é l t k t adhatunk dh t k a W WebLogic bL i szerver „ „ „

27

2009. június 10.

példányok, vagy cluster-ek, illetve a rajtuk futó alkalmazások meghatározott pontjaihoz Speciális data publisher Szerver,, vagy gy 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ű) i tű) „ 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 y é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 TraceElapsedAction ThreadDumpAction,TraceAction, „ Diagnostic Context: a request kontextus információi (például hívó fél IP címe)

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 publisher-ek ek által küldött adatok naplózása

„ Data Accessor-ok: „ Diagnosztikai g adatokhoz való hozzáférésre szolgáló g komonensek Admin console és WLST

„ „ Watches and Notifications: „ Dinamikusan konfigurálható körülményekre figyelnek „

„

28

2009. június 10.

és értesítést küldenek Segítségükkel vizsgálhatóak: „ Szerver log log-ok ok „ Instrumentation alrendszer eseményei „ További diagnosztikai adatok Notification listener-ek: SMTP, SNMP, JMX, JMS, Diagnostic Image

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): C ) „ Egy pillanatfelvételt készít egy „ „

29

2009. június 10.

WebLogic szerver példányról Előre konfigurált helyen 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) indulás, esetén), vagy manuálisan

Oracle Complex Event Processing

„ Napjaink j g gazdasági g alkalmazásai folyamatosan y továbbítják j 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, együttese amely felhasználók által definiált szabályok segítségével dolgozza fel az üzeneteket

30

2009. június 10.

Oracle CEP infrastruktúra

„ Komponensek: „ Adapterek: adat konverzió, események normalizálása „ Stream-ek: események sorba rendezése a feldolgozáshoz „ Event E t processor: szabályok bál k alapján l já ffeldolgozza ld l az ü üzeneteket, t k t majd jd 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

31

2009. június 10.

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 E é é ü 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 20% kal megnő a páciens vérnyomása, akkor értesítse a legközelebbi nővért

32

2009. június 10.

Köszönöm a figyelmet!

Ké dé k? Kérdések?

33

2009. június 10.