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
3
2010. szeptember 27.
szétválasztása Sticky session kezelése Cookie-mechanizmus SSL konfigurálható
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
20
2010. szeptember 27.
olvasás
írás
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
21
2010. szeptember 27.
olvasás
írás
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.
