Session-replikációs alternatívák WebLogic környezetben Farkas István Alerant Informatikai Zrt. 2010. szeptember 27.
Bevezető Nagyvállalati környezet: növekvő adatmennyiség Összetett infrastruktúrák szintén hozzájárulnak az adatmennyiséghez, pl. SOA Az infrastruktúra teljesítményének utol kell érnie az adatmennyiséget Egyre bonyolultabb követelmények Alkalmazások adatainak biztonságos tárolása egy módszer a HTTP session replikációja hatással van a rendszer teljesítményére körültekintő tervezést igényel 2 2010. szeptember 27.
WebLogic környezet - cluster Load balancer dedikált WebLogic példány, telepített speciális Servlet-tel webszerver, telepített WebLogic proxy plugin-nel hardveres megoldások Terhelés elosztása Hibás szerverek kihagyása Statikus és dinamikus tartalom szétválasztása Sticky session kezelése Cookie-mechanizmus SSL konfigurálható 3 2010. szeptember 27.
A WebLogic HTTP Session-kezelése Állapotkezelési és nyomkövetési sémák (track and store) In-memory (single server not replicated) JDBC based File based In-memory replication (clustered) Cookie based Beállítás: deklaratív módszer WEB-INF/weblogic.xml, session-descriptor J2EE szempontból vendor-specifikus HTTP session cookie első kéréskor a szerver állítja össze; válaszban küldi a kliensnek a kliens a következő kérésekben elküldi a tartalmát egyedi azonosító (session-id) elsődleges és másodlagos szerverek azonosítása 4 2010. szeptember 27.
In-memory (single server) A HTTPSession adatait a kiszolgáló memóriájában tárolja Maximális session-szám korlátozható Természetes korlát a JVM heap mérete korlátok túllépését Java kivétellel jelzi a szerver A munkamenethez élettartam tartozik konfigurációs paraméter a szerver periodikusan felszabadítja a lejárt session-ök erőforrásait a figyelés periódusideje is konfigurálható Hátrány a szerver újraindításakor ill. leállásakor a session adatai elvesznek 5 2010. szeptember 27.
In-memory replication A munkamenet állapotáról másolat készül egy másodlagos szerveren dinamikus kiválasztás alapján memóriában tartva A session állapota tehát 2 helyen található meg az állapotok szinkronizációját a WLS biztosítja Ha az elsődleges szerver leáll a proxy szerver a session cookie alapján a másodlagos szerverhez irányít a másodlagos szerver választ egy új backup szervert a kliens csak a megnövekedett válaszidőt veheti észre Ha minden szervert újraindítunk a session adatai elvesznek (ha ez szempont: külső cache, pl. Coherence) Konfigurációs paraméterek deployment descriptor: replicated, replicated-if-clustered 6 2010. szeptember 27.
Replikációs csoportok WLS lehetőség szerverek csoportosítására használatuk opcionális Minden szerverhez konfigurálható a replikációs csoport, amelyhez tartozik a preferált másodlagos replikációs csoport Kérés érkezésekor a szerver figyelembe veszi a preferenciát magasabb rangú, mint a fizikai szerverhez tartozás igyekszik a preferált csoportban létrehozni a replika-objektumot igyekszik elkerülni az azonos csoportba tartozó szervereket 7 2010. szeptember 27.
JDBC persistence A perzisztenciát adatbázis-tábla biztosítja Előfeltétel: JDBC non-xa datasource létrehozása Adattárolás session adatai bináris formában (BLOB) utolsó hozzáférés ideje Az adatok szinkronizációja költséges művelet Replikációs csoportokat is támogatja Minden szervernek hozzáférése van minden session adataihoz Cache mechanizmus utoljára használt munkamenetek adatai hangolható Újraindítást / leállást túléli 8 2010. szeptember 27.
File-based persistence A session adatai fájlban perzisztálódnak szerver oldalon Követelményei minden clustertagnak írnia és olvasnia kell tudni magas rendelkezésre állás és gyors válaszidő szükséges Gyakorlatban: SAN-ra kötött diszkalrendszer Cache mechanizmus JDBC-hez hasonlóan 9 2010. szeptember 27.
Cookie-based replication A munkamenet adatainak perzisztálása cookie formájában a kliens oldalán történik Kis méretű session esetén Valamennyi kliensnek támogatnia kell a cookie-kat Csak szöveges adatok adhatók a session-höz Biztonsági kérdéseket vet fel A cookie neve konfigurálható 10 2010. szeptember 27.
Terheléselosztás és failover Szoftveres megoldás: proxy plugin A szerverek közti választás round robin módszerrel a plugin a szerverek állapotát folyamatosan figyeli szükség esetén átirányítást végez a backup szerverre 11 2010. szeptember 27.
Külső megoldás használata Coherence*Web Elosztott cache megoldás Lehetőséget biztosít session-megosztásra különböző webalkalmazások között heterogén környezetben konkurens hozzáférés biztosítása (Locking) Önállóan vagy alkalmazás-szerverrel kombinálva támogatja a WebLogic Portal konténert is Számos cache topológiát támogat Lehetőség a munkamenet kezelésére a J2EE szerveren kívül heap terhelése csökkenthető Hozzáférés-szabályozás policy-k segítségével 12 2010. szeptember 27.
Coherence telepítése WebLogic Server 10.3 beépített service provider coherence-web-spi.war library telepítése alkalmazás-oldal: coherence-web.spi felvétele a deployment descriptor-ban WLS v. < 10.3 weblogic.jar és web-alkalmazások instrumentálása A web-modul környezettől függően konfigurálható 13 2010. szeptember 27.
Cluster-tagok izolációja A Coherence*Web modul hatókörét biztosítja az appserver-en belül Application server-scoped cluster nodes az alkalmazás-szerveren egy Coherence cluster csomópont jön létre minden webalkalmazás session-kezelését átveszi a Coherence a coherence.jar-t a system classpath-ra kell felvenni EAR-scoped cluster nodes Az alkalmazás-szerveren alkalmazásonként egy Coherence cluster csomópont jön létre EAR-on belül minden webalkalmazás session-kezelését a Coherence végzi A coherence.jar az EAR classpath-ra települ WAR-scoped cluster nodes minden webalkalmazás számára dedikált Coherence cluster node 14 2010. szeptember 27.
Coherence session-modellek Cél a munkamenet fizikai reprezentációjának tárolása Hagyományos modell a munkamenet állapotát egyetlen entitásban tárolja a (de)szerializáció attribútumonként történik kis méretű session-nél célszerű (<10 KB) ha nincs olyan objektum a session-ben, melyre több különböző attribútum is hivatkozik (többszörös szerializáció elkerülése) 15 2010. szeptember 27.
Coherence session-modellek #2 Monolitikus modell a munkamenet állapota egy entitásban tárolódik (de)szerializációjuk egyszerre, egy lépésben történik 16 2010. szeptember 27.
Coherence session-modellek #3 Split model a tradicionális modell kiterjesztése kisméretű attribútumok tárolása fizikailag önálló entitásban hálózati forgalmat csökkenti nagy méretű objektumok módosítása nem igényli a teljes session frissítését használata javasolt nagy méretű munkamenetek esetén 17 2010. szeptember 27.
Cache topológiák Replicated cache service a cache-ben tárolt adatokat minden cluster-tagra másolja az adatokat szinkronban tartja olvasásra a leggyorsabb hátrány: írás esetén minden tagot szinkronizálni kell! skálázhatósági korlát: a JVM heap-et növelni kell előny: olvasás-intenzív felhasználás esetén 18 2010. szeptember 27. olvasás írás
Cache-topológiák #2 Partitioned cache service nem a teljes adatmennyiség kerül másolásra a cluster-tagokra hasonlít a HTTP state replication-re az adatokat szétteríti a cluster-ben load balancing a szétterítés természetes velejárója egyetlen adat (session) kezeléséért a clusteren belül mindig egyetlen tag felel location transparency nincs kitüntetett szerver, ugyanazt az API-t használja a kliens a kliens számára átlátszó mechanizmus failover a session-adatról replika készül (konfigurálható számú) hiba esetén adatvesztés nélküli átirányítás adatkezelés során a kommunikáció point to point jó (lineáris) skálázhatóság! új tagok bevonása esetén nincs kommunikációs overhead 19 2010. szeptember 27.
Cache-topológiák #3 Partitioned cache service (folyt.) clusteren belül egy adott tag nem feltétlenül kezel adatot ilyenkor csak API-t biztosít pl. appserver JVM terhelés csökkentése kimondottan load balancing komponens nincs egyedi clustering-protokoll van a háttérben olvasás írás 20 2010. szeptember 27.
Cache-topológiák #3 Near cache a partitoned cache megoldást bővíti ki alkalmazás-oldali lokális cache hozzáadása legutoljára / leggyakrabban használt adatok az alkalmazás JVM-jéből áldozunk fel a cache-ben lévő adatok elérésére közel 0 késleltetés worst case partitioned cache elérése olvasás írás 21 2010. szeptember 27.
Szerializálhatósági szabályok Szerializálás: objektum bájtfolyamba írása pl. fájl, socket-kapcsolat Deszerializálás: szerializált bájtfolyamból Java objektum java.io.serializable interfész jelző szerepe van, implementálandó metódusok nincsenek Szerializált bájtfolyam minden adatot tartalmaz a visszaállított objektum konstruktorának hívására nincs szükség Öröklési hierarchia az első nem szerializálható ősosztálynak legyen üres konstruktora egyébként NotSerizalizableException kivétel a deszerializáció az ősosztályokhoz tartozó állapotot is visszaállítja 22 2010. szeptember 27.
Példák Nincs szükség üres konstruktorra (az Object az első ősosztály, neki van) Nincs szükség üres konstruktorra (az ősosztálynak csak default konstruktora van) A MyAncestor osztály rendelkezik paraméterezett konstruktorral üres konstruktort is definiálni kell 23 2010. szeptember 27.
Szerializálhatósági szabályok #2 SerialVersionUID mező a szerializálandó osztály egységes verzió-azonosítója különféle változatok kompatibilitásának megőrzésére Statikus adattagok csak az objektumhoz tartozó állapotok szerializálódnak automatikusan statikus adatok esetén mi gondoskodunk a szerializálásról statikus inicializáló blokk egyedi értékadás (writeobject() felüldefiniálása) Transient adattagok a nem replikálandó adatok kezelésére célszerű használni! Session objektumok minden session-be helyezett objektumnak teljesítenie kell a szerializálhatóság feltételeit 24 2010. szeptember 27.
Szerializálhatóság ellenőrzése Nem elegendő a Serializable interfészt kiterjeszteni A szerializálhatósági feltételek az adattagokra is vonatkoznak! pl. HashMap-be pakolt objektumok Célszerű unit teszteket készíteni fejlesztési időben történő ellenőrzés pl. ByteArrayInputStream-be írás és visszaolvasás ha nincs Java kivétel, rendben vagyunk SessionMonitor interfész az implementálója értesítést kap a session műveleteiről (set, replace, remove) célszerű logot készíteni Teljesítménytesztek 25 2010. szeptember 27.
Session-kezelési jógyakorlatok Használjunk replikációs csoportokat (WLS)! Replikációs hibák keresése: ServerDebugConfig MBean A HTTP session-t csak átmeneti tárolásra használjuk! egyéb esetekben adatbázis vagy külső cache megoldás A session-be csak szerializálható objektumot helyezzünk! Amikor lehet, használjuk a memória-alapú replikációt! Az együtt használt attribútumok egy entitásban legyenek! pl. tétel és mennyiség tulajdonság kerüljön egy MegrendelesVO-ba Nagy méretű VO esetén válasszuk ketté RO és RW attribútumokat tegyük külön VO-ba! pl. megrendelés állapotát jelző attribútumok vs. megrendelés címe Szemléletváltás! 26 2010. szeptember 27.