plik

Spis tre ci

Spis tre ci .......................................................................................................................5
1

Wst p .....................................................................................................................7

Klastry....................................................................................................................8

2.1

Definicja.........................................................................................................8

2.1.1

Klaster o wysokiej wydajno ci ..............................................................8

2.1.2

Klaster równowa cy obci enie...........................................................8

2.1.3

Klaster odporny na awarie .....................................................................9

2.2

Rozwój systemów klastrowych......................................................................9

2.3

Klastry w serwerach WWW ........................................................................10

2.3.1

Wyst puj ce problemy.........................................................................10

2.3.2

Stosowane rozwi zania........................................................................10

Jakarta-Tomcat 5.0...............................................................................................13

3.1

Rozwój serwera Jakarta-Tomcat..................................................................13

3.2

G ówne za o enia koncepcyjne....................................................................13

3.3

Opis implementacji ......................................................................................14

3.3.1

Hierarchia obiektów.............................................................................14

3.3.2

Strumie przetwarzania da .............................................................16

3.3.3

Wyzwalacze .........................................................................................16

3.4

Implementacja klastra w serwerze Tomcat 5.0............................................17

3.4.1

Klaster dla wersji 4.0 ...........................................................................17

3.4.2

Architektura klastra w wersji 5.0 .........................................................17

3.4.3

Implementacja klastra w wersji 5.0 .....................................................18

3.4.4

Konfiguracja klastra w wersji 5.0 ........................................................21

3.4.5

Zalety rozwi zania ...............................................................................22

3.4.6

Wady rozwi zania................................................................................23

Nowy klaster dla serwera Jakarta-Tomcat ...........................................................25

4.1

Architektura i za o enia koncepcyjne..........................................................25

4.1.1

Koncepcja centralnego sterowania ......................................................25

4.1.2

Podzia na warstwy ..............................................................................26

4.1.3

Wersjonowanie sesji ............................................................................27

4.1.4

Zintegrowany mechanizm równowa enia obci enia .........................27

4.1.5

Bezpiecze stwo....................................................................................28

4.2

Dzia anie systemu ........................................................................................28

4.2.1

Do czanie nowego w z a....................................................................29

4.2.2

Awaria po czenia................................................................................31

4.2.3

Awaria w z a .......................................................................................32

4.2.4

Awaria serwera zarz dcy .....................................................................33

4.3

Implementacja..............................................................................................34

4.3.1

Warstwa transportuj ca........................................................................35

4.3.2

Komunikacja w klastrze.......................................................................39

4.3.3

Mechanizm kolejki zada zale nych ...................................................41

4.3.4

Buforowanie.........................................................................................45

4.3.5

Algorytm przetwarzania dania .........................................................47

4.3.6

Serwer zarz dca ...................................................................................51

4.3.7

Serwer ruchu ........................................................................................53

4.4

Konfiguracja klastra.....................................................................................54

4.4.1

Koncepcja dwóch sieci ........................................................................56

2 Klastry

2.1 Definicja

W literaturze fachowej pojawia si nast puj ca definicja klastra:

Klaster  to  zbiór  niezale nych  komputerów  (w z ów),  po czonych
sieci   komunikacyjn ,  które  z  punktu  widzenia  u ytkownika
sprawiaj  wra enie pojedynczego systemu (komputera) [2].

G ównym  zadaniem  jakie  stawia  si   klastrom  jest  zwi kszenie  szybko ci,
niezawodno ci  i  dost pno ci  systemów  informatycznych.  Rozdzielaj c  obci enie
jednej  maszyny  na  ca   farm   maszyn  otrzymuje  si   zrównoleglenie  oblicze ,
niewidoczne dla ko cowego u ytkownika. W systemach, które obs uguj   tysi ce lub
nawet miliony u ytkowników na sekund  rozdzielenie obci enia na wiele fizycznych
maszyn  mo e  okaza   si   jedynym  mo liwym  rozwi zaniem  problemu  wydajno ci  i
zapewnienia ci g ej pracy systemu.

Bardzo wa n cech , która cz sto powoduje,

e administratorzy du ych

systemów decyduj  si  na instalacj  klastra jest jego odporno  na awarie pojedynczej
maszyny.  Je eli  klaster  zapewnia mechanizm niewidocznej dla  u ytkownika obs ugi
awarii  w z a  (ang.  fail-over),  to  zastosowanie  architektury  korzystaj cej  z  wielu
maszyn  fizycznych  mo e  by   jedynym  sposobem  uzyskania  niezawodno ci  systemu
informatycznego.  W  przypadku  awarii  w z a  klaster  zapewnia  przeniesienie
kontekstu  wykonania  na  inny  serwer,  a  ko cowy  u ytkownik  mo e  si   nie
zorientowa ,  e nast pi a awaria, gdy  zachowa swoje dane. Ponadto nie mniej wa n
zalet   jest  skalowalno   rozwi za   wykorzystuj cych  klaster.  W  momencie,  gdy
administrator zaczyna zauwa a  spadek mocy obliczeniowej systemu mo e pod czy
kolejn   maszyn ,  zwi kszaj c  przepustowo   klastra.  Z  drugiej  strony  je eli  oka e
si ,  e  system  nie  wykorzystuje  w  pe ni  zasobów  sprz towych,  to  cz

maszyn

mo na od czy od klastra, wykorzystuj c je w innych systemach, na dan chwil
bardziej wymagaj cych.

W szczególno ci wyró nia si trzy rodzaje klastrów:

1.  Klaster o wysokiej wydajno ci (ang. high performance cluster),
2.  Klaster równowa cy obci enie (ang. load balancing cluster),
3.  Klaster odporny na awarie (ang. fail over cluster).

W ka dym z trzech rodzajów klastrów k adzie si nacisk na inne aspekty

zwi zane z systemami informatycznymi lub sprz tem. W kolejnych podrozdzia ach
umieszczono krótk charakterystyk ka dego z wymienionych rodzajów.

2.1.1 Klaster o wysokiej wydajno ci

Zadaniem klastra o wysokiej wydajno ci jest maksymalizowanie mocy

obliczeniowej, któr mo na uzyska tworz c farm maszyn. Przy implementacji
g ówny nacisk k adzie si na wydajno systemu (co cz sto wi e si równie z
drugim rodzajem klastra czyli klastrem równowa cym obci enie).

2.1.2 Klaster równowa

cy obci

enie

Klaster równowa cy obci enie jest instalowany w celu zapewnienia równego

podzia u zada na wszystkie maszyny w klastrze. Tego typu klaster instaluje si w
systemach, w których bardzo istotny jest czas reakcji na

danie klienta. Klaster

minimalizuje  wariancj   czasu  oczekiwania  na  odpowied   od  systemu.  Jest
odpowiedzialny  za  wykorzystywanie  wszystkich  swoich  zasobów  sprz towych  w
równym  stopniu,  eliminuj c  sytuacje,  gdzie  jedno

danie od klienta trafia do

ca kowicie niewykorzystywanego w z a i jego obs uga trwa kilka sekund, a inne
trafia do mocno obci onego w z a i obs uga trwa kilkadziesi t sekund. Najbardziej
wyspecjalizowane systemy podczas wyboru w z a do obs ugi

dania bior pod

uwag   statystyki  obci enia  maszyny  (zu ycie  procesora,  dysków,  pami ci)  z
ostatnich kilku sekund i na tej podstawie okre laj  jego potencjaln  moc przerobow .
Niemniej  jednak  mniej  wyrafinowane  algorytmy  w  przypadku  wielu  systemów  s
wystarczaj co  skuteczne.  Przyk adem  jest  najcz ciej  stosowany  algorytm
karuzelowy  (ang. Round Robin),  który ka de  kolejne

danie wysy a do nast pnego

w z a, w pewnym z góry ustalonym cyklu.

2.1.3 Klaster odporny na awarie

Zadaniem klastra odpornego na awarie jest zapewnienie niezawodno ci systemu,

nawet w przypadku fizycznych b d  programowych awarii. Klaster w zale no ci od
stopnia  zaawansowania  mo e  obs ugiwa   odpowiednio  du y  procent  awarii  w z ów
bez utraty danych oczywi cie  dania przetwarzane w momencie awarii mog  cz

danych utraci . Odporno na awarie w z ów uzyskuje si w dwojaki sposób: na
poziomie sprz tu oraz programowo.

Ka d niezb dn z punktu widzenia funkcjonowania systemu maszyn duplikuje

si   i  w  przypadku  awarii  duplikat  przejmuje  rol   podstawowej  maszyny.  Niemniej
jednak  takie  rozwi zanie  nie  gwarantuje  nam,  e  dane  u ytkowników  trzymane  w
pami ci  operacyjnej  maszyny  nie  zostan   utracone  podczas  awarii.  Dlatego  w
systemach  przechowuj cych  dane  zwi zane  z  sesj   u ytkownika  stosuje  si
programowe  wsparcie  dla  mechanizmów  automatycznego  wykrywania  i  obs ugi
awarii. Najcz ciej spotykane rozwi zania to zapis danych na no niku fizycznym (na
przyk ad  w  bazie  danych)  lub  replikacja  danych  w  obr bie  w z ów  klastra.  Oba
rozwi zania  maj   swoje  wady  i  zalety.  Zapis  danych  w  bazie  umo liwia  ich
odzyskanie  nawet po  awarii ca ego klastra, ale powoduje du y narzut przy obs udze

da klientów. Replikacja uniemo liwia odzyskanie danych przy awarii ca ego

klastra,  ale  daje  du e  mo liwo ci  równowa enia  obci enia    kontekst  danego
u ytkownika  nie  musi  by   na  sta e  powi zany  z  w z em,  na  którym  zacz   si
wykonywa  jego program.

2.2 Rozwój systemów klastrowych

Pierwsze udane próby stworzenia klastra si gaj 1968 roku. Grupa naukowców

na  Uniwersytecie  Illinois  w  ramach  projektu  ILLIAC    IV  [2]  stworzy a  klaster
umo liwiaj cy po czenie setek, a nawet tysi cy w z ów w jeden superkomputer. W
czasie  realizacji  projektu  pojawi o  si   wiele  problemów,  jednak  mimo  to  idea
przetrwa a.  W  pó niejszych  latach  programi ci  odeszli  od  koncepcji  równoleg ego
przetwarzania, co wi za o si  z przekonaniem,  e skoro w ci gu dziewi ciu miesi cy
szybko  mikroprocesora podwaja si , to nie ma potrzeby pisania skomplikowanego
oprogramowania  wspieraj cego  klastry,  w  celu  zwi kszenia  mocy  obliczeniowej.
Pr dzej czy pó niej technologia dogoni wymagania programów.

Koncepcja klastrów obroni a si jednak przed p dz cym rozwojem technologii.

W ci gu ostatnich kilkunastu lat firmy zacz y bardzo ywo interesowa si
tworzeniem oprogramowania (szczególnie du ych serwisów i baz danych) w

rodowisku rozproszonym, z o onym z wielu fizycznie niezale nych maszyn.

Okazuje si ,  e w dzisiejszych czasach wa niejsza staje si  gwarancja niezawodno ci
oraz  dost pno ci  (ang.  high  availability)  systemu  od  jego  wydajno ci.  Wydajno
mo na uzyska  kupuj c wieloprocesorow  maszyn , jednak nikt nie zagwarantuje,  e
taka  maszyna  b dzie  dzia a a  non-stop  przez  wiele  lat.  Instaluj c  klaster  firma  ma
pewno ,  e  nawet  w  przypadku  awarii  jednego  z  w z ów  system  wci   b dzie
dost pny.

Innym aspektem powoduj cym wzmo one zainteresowanie klastrami jest ich

skalowalno .  Cz sto  liczba  u ytkowników  ko cowych  systemu  jest  niemo liwa  do
oszacowania  (szczególnie,  je eli  system  jest  dost pny  w  Internecie  jako  serwer
WWW). Bez tej wiedzy projektanci systemu nie s  w stanie z góry okre li  niezb dn
moc  obliczeniow ,  która  pozwoli  u ytkownikom  systemu  na  wygodn   prac .
Skalowalno  i niezawodno  klastrów powoduje,  e staj  si  one bardzo atrakcyjne
dla twórców takich systemów.

2.3 Klastry w serwerach WWW

Wi kszo du ych systemów informatycznych tworzonych w dzisiejszych

czasach w jakim  stopniu korzysta z serwerów WWW. Wynika to z ogromnej rzeszy
potencjalnych  u ytkowników  systemu  znajduj cej  si   w  Internecie,  a  tak e  z  jasno
wyznaczonych  standardów,  które  takie  serwery  spe niaj .  Pisz c  interfejs
u ytkownika jako strony HTML mamy pewno ,  e klient b dzie w stanie korzysta  z
serwisu  na  dowolnej  platformie,  bez  potrzeby  doinstalowywania  lokalnie
dodatkowych komponentów.

Popularno protoko u HTTP spowodowa a masowe wykorzystywanie go nawet

w przypadku aplikacji nie bazuj cych na j zyku HTML. Standardy takie jak serwisy
sieciowe (ang. web-services) czy XML bardzo cz sto id w parze ze stosunkowo
prostym schematem programowania w serwerach WWW.

Wraz ze wzrostem popularno ci serwerów WWW pojawi a si potrzeba

zapewnienia ich niezawodno ci, co wi e si z koncepcj klastrów. W kolejnym
punkcie zostan na wietlone g ówne problemy, które mog pojawi si przy
implementowaniu klastra na potrzeby serwerów WWW.

2.3.1 Wyst puj ce problemy

Ze wzgl du na specyfik serwerów WWW nale y przeanalizowa cele jakie

musi realizowa klaster. W przypadku serwera (lub aplikacji) bezstanowej jedynym
zadaniem klastra b dzie równowa enie obci enia i detekcja wadliwych w z ów, w
celu zapobiegni cia przes aniu zadania do niesprawnej maszyny.

Je eli serwer, b d zainstalowana na nim aplikacja, przechowuj informacj o

swoim stanie (sesja u ytkownika), to klaster musi zapewnia mechanizm
odzyskiwania danych w przypadku awarii.

Spotyka si bardzo ró ne rozwi zania tych problemów w serwerach

komercyjnych. Aby uzyska niezawodno , w niektórych rozwi zaniach stosuje si
zapis danych na no nikach fizycznych, a w innych wykorzystuje si mechanizm
replikacji danych pomi dzy w z ami klastra.

2.3.2 Stosowane rozwi zania

W dzisiejszych czasach w zasadzie ka dy komercyjny serwer WWW mo e

pracowa jako klaster, co zosta o wymuszone przez rynek. Dla osoby zajmuj cej si

projektem  informatycznym  od  strony  biznesowej  s owa  takie  jak  skalowalno   czy
odporno   na  awarie  sta y  si   wyznacznikiem  jako ci  rozwi za   informatycznych.
Ka da  licz ca  si   na  rynku  firma  stara  si   przekona   swoich  klientów,

implementacja  ich  klastra  jest  najlepsza  i  zapewnia  najwi ksz   niezawodno .  W
pracy zostan  omówione dwa przyk adowe rozwi zania zastosowane w komercyjnych
serwerach wspieraj cych standard J2EE (Java 2 Enterprise Edition). Uwaga zostanie
skupiona  na  mechanizmach  zabezpiecze   zapobiegaj cych  utracie  danych  sesji
u ytkownika. Celowo zostanie pomini ta cz

zwi zana z EJB (Entity Java Beans)

oraz JMS (Java Messaging Service), jako nie zwi zana z prac .

2.3.2.1 BEA Weblogic Server 8.0

Serwer Weblogic firmy Bea jest uznawany za najlepiej przystosowany do

dzia ania  w  klastrze  serwer  J2EE  [1].  Autorzy  klastra  zaproponowali  architektur
z o on   z  maszyny  równowa cej  obci enie  (programowo  lub  sprz towo)  oraz
po czonych  sieci   w z ów  klastra  z  zainstalowanym  serwerem  Weblogic  [10].
Architektura  jest  w  pe ni  zdecentralizowana,  to  znaczy  nie  ma  serwera,  który
nadzorowa by  prac   ca ego  klastra.  W ze   do cza  do  klastra  wysy aj c  w  trybie
rozg oszeniowym  komunikat  w  sieci powiadamiaj cy  pozosta e  komputery  o swoim
istnieniu.  Je eli  która   z  maszyn  przestanie  wysy a   regularne  komunikaty  w  trybie
rozg oszeniowym (tzw. heartbeats), to pozosta e uznaj ,  e nast pi a w niej awaria i
przejm  jej zadania.

Ka da sesja u ytkownika posiada swój serwer macierzysty oraz serwer

zast pczy. Identyfikatory obu w z ów klastra s zaszyte w nazwie ciasteczka (ang.
cookie) okre laj cego numer sesji u ytkownika.

Domy lnie ka de

danie od klienta jest przekierowywane do macierzystego

w z a sesji (czyli w z a, na którym sesja zosta a utworzona). Wybór miejsca
przekierowania nast puje w serwerze rozdzielaj cym

dania. W przypadku awarii

w z a macierzystego serwer równowa cy przekierowuje

danie do w z a

zast pczego,  który  zawiera  pe n   kopi   danych  z  sesji.  W ze   zast pczy  przejmuje
rol   macierzystego  i  wybiera  inny  w ze   jako  zast pczy.  Jednocze nie  zmienia
identyfikator sesji, aby kolejne  dania by y kierowane do niego.

Niestety w przypadku awarii dwóch w z ów w sieci dane replikowane mi dzy

nimi zostaj bezpowrotnie utracone.

Drug znacz c wad tego rozwi zania jest s abe równowa enie obci enia w

klastrze. Ka dy u ytkownik jest na sta e przypisany do konkretnego serwera i dopiero
w  momencie  awarii  zostaje  przekierowany  do  innego.  Czyli  w  ogólno ci  nowo
dodany  w ze   w  sieci  nie  przejmie  obci enia  od  pozosta ych  maszyn,  a  jedynie
zacznie  obs ugiwa   nowych  u ytkowników.  W  razie  awarii  w z a  wszystkie  jego
sesje  zostan   przej te  przez  pozosta e  maszyny,  a  po  ponownym  uruchomieniu  nie
b dzie on w stanie z powrotem przej  obci enia. W praktyce mo e to doprowadzi
do  efektu  domina:  kolejny  serwer  przestaje  odpowiada   z  powodu  coraz  wi kszej
liczby obs ugiwanych u ytkowników zwi kszanej wraz z ka d  kolejn  awari .

Przy takim podej ciu administrator systemu ma du o mniej czasu na w czenie

kolejnej  maszyny  do  klastra,  je eli  zobaczy,  e  obci enie  zaczyna  przerasta
mo liwo ci  klastra.  Je eli  si   spó ni,  to  u ytkownicy,  którzy  zalogowali  si   przed
do czeniem nowego w z a nie b d  w stanie komfortowo pracowa .

3 Jakarta-Tomcat 5.0

Serwer Jakarta-Tomcat [8] jest darmowym serwerem WWW z ogólnodost pnym

kodem  ród owym.  Umo liwia  on  tworzenie  dynamicznych  stron  w  oparciu  o
standardy  Java  (serwlety  i  strony  JSP).  Pomimo  bardzo  pr nego  rozwoju  serwera
wci  brakuje w nim w pe ni funkcjonalnego i dzia aj cego klastra. Twórcy Tomcata
dostrzegli  ju   jak  du y  wp yw  na  decyzj   o  wyborze  kontenera  aplikacji  ma  jego
skalowalno   i  odporno   na  awarie.  W  wersji  5.0  wprowadzili  standard  klastra  w
kodach  ród owych  serwera  oraz  pod czyli  bardzo  prosty  modu   replikuj cy  stan
sesji  mi dzy  w z ami  klastra.  Przyk adowa  implementacja  modu u  nie  rozwi zuje
jednak  wielu  problemów,  które  mog   spowodowa   wadliwe  dzia anie  klastra.  St d
zrodzi a si  idea stworzenia nowego klastra dla serwera Jakarta-Tomcat.

W kolejnych punktach zostanie opisany serwer Jakarta-Tomcat oraz

przedstawiona implementacja pierwszego modu u klastra napisana przez Filipa
Hanika (por. p. 3.4).

3.1 Rozwój serwera Jakarta-Tomcat

Pierwszym pomys odawc i twórc Tomcata by James Duncan Davidson

(projektant i programista z firmy Sun). Pod koniec lat dziewi dziesi tych rozpocz
on  prace  nad  wzorcow   implementacj   kontenera  dla  serwletów  i  stron  JSP.  Po
napisaniu  sporej  cz ci  systemu  przekaza   kody  ród owe  organizacji  Apache
Software  Foundation,  aby  dalszy  rozwój  serwera  odbywa   si   pod  jej  patronatem.
Organizacja  ochrzci a  projekt  nazw   Jakarta-Tomcat  i  w  1999  roku  opublikowa a
wersj  3.0, jako wtyczk  do serwera WWW Apache. Kolejna wersja (4.0) by a ju
w  pe ni  niezale nym  serwerem.  Pojawi a  si   obs uga  takich  standardów  jak  JDBC,
SSL czy Realms.

Serwer Jakarta-Tomcat sta si bardzo popularnym kontenerem serwletów oraz

stron  JSP,  g ównie  za  spraw   ogólnodost pnego  kodu  ród owego  oraz  jego  dobrej
wydajno ci.  Prosta  implementacja  ograniczonego  podzbioru  standardów  J2EE  [3]
umo liwi a stworzenie bardzo szybkiego i lekkiego serwera, który móg  by  bardzo
dobr   alternatyw   dla  serwerów  ze  stronami  pisanymi  w  j zyku  PHP.  W  wielu
projektach  nie  ma  potrzeby  wykorzystywania  skomplikowanych  mechanizmów  EJB
czy  JMS,  a  do pe nej  realizacji zada  wystarcz  serwlety  z  mo liwo ci  dost pu do
bazy  danych.  Do  tego  typu  projektów  idealnie  nadawa   si   serwer  Jakarta-Tomcat.
Wiele projektów i firm korzysta z Tomcata jako jednego z komponentów, jak cho by
Jonas [7] czy Hyperion Analyzer [5].

3.2 G ówne za o enia koncepcyjne

Serwer Jakarta-Tomcat jest przede wszystkim kontenerem serwletów (wersja

2.4)  i  stron  JSP  (wersja  2.0).  Intencj   twórców  projektu  nie  by o  stworzenie  pe nej
implementacji standardu J2EE [3], ale szybkiego i stabilnego kontenera serwuj cego
strony dynamiczne napisane w j zyku Java. Poniewa  ca y serwer zosta  napisany w
j zyku  Java,  wi c  mo e  dzia a   w  zasadzie  na  dowolnej  platformie,  posiadaj cej
implementacj  maszyny wirtualnej.

W kolejnych wersjach dosz o sporo ró nego rodzaju dodatków, u atwiaj cych

prac programistom i administratorom systemu.

Autoryzacja

Dosz o wsparcie dla obiektów autoryzacji (czyli tzw. realms). Administrator

mo e stworzy  w asne implementacje mechanizmu uwierzytelniania lub skorzysta  z
trzech  gotowych  komponentów  (w  szczególno ci  dost pny  jest  mechanizm
korzystaj cy  z  bazy  danych).  Ponadto  obs ug

da mo na tunelowa w protokole

HTTPS.

Drzewa JNDI, JDBC, JavaMail

Tomcat udost pnia proste mechanizmy rejestrowania obiektów w drzewie nazw

(JNDI).  Programista  mo e  pobiera   w  kodzie  obiekty,  wyszukuj c  je  po  nazwie.
Najcz ciej  stosuje  si   ten  mechanizm  przy  korzystaniu  z  po cze   do  bazy  danych
(obiekty  typu

javax.sql.DataSource

) administrator mo e modyfikowa

parametry po czenia bez potrzeby zagl dania czy modyfikowania kodu aplikacji.

Analogicznie mo na korzysta z obiektów umo liwiaj cych wysy anie listów

poczt elektroniczn [4].

Mened er bezpiecze stwa

Tomcat w wersji 5.0 posiada wsparcie dla mened era bezpiecze stwa (ang.

security  manager).  Administrator  mo e  definiowa   poziom  izolacji  przy
wykonywaniu kodu napisanego przez programistów. W ten sposób mo na obroni  si
przed wykonaniem niebezpiecznego z punktu widzenia serwera kodu w aplikacjach,
np.

System.exit(0);

co powodowa oby koniec pracy ca ego systemu.

3.3 Opis implementacji

Jakarta-Tomcat jest w ca o ci napisany w j zyku Java.

ród a systemu s podzielone na trzy grupy:

1. jakarta-tomcat-catalina cz

, w której znajduje si faktyczna implementacja

kontenera serwletów,

2. jakarta-tomcat-connectors implementacja podstawowych typów po cze

stosowanych w systemie (mi dzy klientem a serwerem),

3. jakarta-tomcat-jasper implementacja kompilatora do stron JSP.

Z punktu widzenia klastrów najciekawsza jest pierwsza cz

, poniewa tu

znajduje si implementacja j dra systemu, a tak e modu do tworzenia klastra.

Tomcat zosta zaimplementowany w postaci hierarchicznego drzewa obiektów,

w którym ka dy w ze mo e zosta przedefiniowany przez odpowiednie wpisy w
plikach konfiguracyjnych. Takie podej cie u atwia modyfikacj systemu, co mia o
du y wp yw na spopularyzowanie serwera.

3.3.1 Hierarchia obiektów

Serwer Jakarta-Tomcat zazwyczaj sk ada si z nast puj cej hierarchii

komponentów:

Korzeniem drzewa jest maszyna (obiekt implementuj cy interfejs

org.apache.catalina.Engine

). Reprezentuje ona niezale ny serwer.

Maszyna

posiada

w z y

(obiekty

implementuj ce

interfejs

org.apache.catalina.Host

), które reprezentuj wirtualne w z y.

W ze

posiada

konteksty

(obiekty

implementuj ce

interfejs

org.apache.catalina.Context

), które reprezentuj aplikacje internetowe

(ang. web applications). Aplikacj mo e by plik z rozszerzeniem .war lub
podkatalog w katalogu webapps.

Kontekst sk ada si z serwletów zadeklarowanych przez programist w pliku
opisuj cym aplikacj (plik web.xml) oraz mened era sesji.

Mened er sesji (obiekt implementuj cy interfejs

org.apache.catalina.

Manager

) zarz dza sesjami u ytkowników.

Taka hierarchia nie jest obligatoryjna dla przyk adu w sytuacji, gdy instalujemy

Tomcat  jako  wtyczk   w  serwerze  Apache,  drzewo  degraduje  si   do  ostatniego
poziomu, czyli samych obiektów aplikacji. Wszystkie pozosta e staj  si  zb dne, gdy
obs ug   dania na wy szym poziomie zajmuje si  macierzysty serwer.

Konfiguracja hierarchii obiektów znajduje si w pliku server.xml. Ka dy poziom

jest  definiowany  przez  odpowiedni  znacznik  w  j zyku  XML.  W  szczególno ci,
standardowa  dystrybucja  Tomcata  dostarcza  trzy  ró ne  rodzaje  mened erów  sesji,
które w zale no ci od zapotrzebowania mo na ustawia  w pliku konfiguracyjnym. Ze
wzgl du na rol  jak  odgrywa mened er sesji w klastrze (przechowuje stan sesji), w
p. 3.3.1.1 zostan  zaprezentowane dost pne implementacje tego obiektu.

3.3.1.1 Implementacje mened era sesji

W standardowej dystrybucji serwera Tomcat dost pne s trzy rodzaje mened era

sesji:

1.  standardowy (ang. StandardManager),
2.  plikowy (ang. PersistentManager),
3.  bazodanowy (ang. JDBCManager).

Pierwszy z nich udost pnia podstawow funkcjonalno mened era sesji czyli

po prostu przechowuje dane w pami ci operacyjnej jednej maszyny.

Drugi pozwala na periodyczne zapisywanie stanu sesji do pliku i odzyskanie tych

danych po restarcie maszyny. Jest równie przydatny w sytuacji, gdy nie wszystkie
sesje mieszcz si w pami ci operacyjnej maszyny. Wtedy mened er zapewnia nam
dodatkowy mechanizm wymiany.

Trzecie rozwi zanie dzia a analogicznie do drugiego z t ró nic , e zapis

odbywa si w bazie danych, w odpowiednio zdefiniowanym schemacie.

3.3.1.2 Klaster w serwerze Tomcat

W wersji 5.0 zosta a dodana obs uga klastra. Administrator mo e zdefiniowa

klas implementuj c klaster (interfejs

org.apache.catalina.Cluster

) w

znaczniku

Cluster

, w pliku konfiguracyjnym serwera. Klaster jest definiowany na

poziomie w z a, dzi ki czemu mo na  atwo rozdzieli  aplikacje, które maj  dzia a  w
trybie  rozproszonym  od  tych  dzia aj cych  na  pojedynczym  serwerze.  Klaster  jest
odpowiedzialny  za  obs ug   wszystkich  aplikacji  (kontekstów)  zainstalowanych  w
obr bie w z a. Implementacja musi zapewni  mechanizmy replikacji i synchronizacji
w obr bie grupy po czonych maszyn oraz mo e udost pnia  metody instalowania i
odinstalowywania  aplikacji  w  ca ym  klastrze  (metody

installContext(String

contextPath, URL war)

start(String contextPath)

oraz

stop(String

contextPath)

Dodatkowo rozszerzono specyfikacj pliku opisuj cego aplikacj (web.xml [3])

o znacznik

, okre laj cy czy aplikacja ma by obs ugiwana przez

klaster. Je eli znacznik zostanie wstawiony, to system pod czy do kontekstu
mened er sesji utworzony przez implementacj klastra. W przeciwnym przypadku do
kontekstu zostanie pod czony standardowy mened er.

Ka dy obiekt tworzony w drzewie hierarchii Tomcata b dzie mia skopiowane

warto ci parametrów z pliku konfiguracyjnego, poprzez wywo anie metod

setXXX(String value)

(gdzie XXX jest nazw parametru oraz jednocze nie nazw

atrybutu w pliku XML). Dodatkowo w specjalny sposób traktowane s obiekty
implementuj ce interfejs klasy

org.apache.catalina.Lifecycle

3.3.1.3 Obiekty klasy Lifecycle

Je eli tworzone na poziomie serwera obiekty implementuj interfejs

org.apache.catalina.Lifecycle

, to w momencie startu systemu wywo ywana jest

dla nich metoda

start()

. Obiekty tego interfejsu zostan powiadomione o

zamkni ciu systemu poprzez wywo anie dla nich metody

stop()

. Dla przyk adu

obiekt implementuj cy interfejs

Cluster

w module klastrowania jednocze nie

implementuje interfejs

Lifecycle

, aby w metodach

start

stop

wykona czynno ci

przygotowuj ce do pracy oraz czynno ci ko cz ce prac klastra.

Ka de

danie obs ugiwane przez serwer Tomcat przechodzi przez odpowiedni

strumie wywo a procedur. Jest to najbardziej newralgiczne miejsce systemu, ze
wzgl du na cz sto wywo ywania jego kodu.

3.3.2 Strumie przetwarzania

Strumie przetwarzania

da w serwerze Tomcat sk ada si z nast puj cych

wywo a :

1. Strumie jest inicjowany przez konektor, dostarczaj cy

danie klienta.

2. Lokalizowany jest odpowiedni w ze , a w nim kontekst, do którego odwo uje

si danie.

3. Wykonywany jest ci g wyzwalaczy (tzw. valve), które obudowuj wywo anie

serwletu (szerzej o wyzwalaczach b dzie mowa w p. 3.3.3).

4.  Uruchamiany jest serwlet.
5.  Wyzwalacze ko cz  dzia anie.
6.  Konektor przekazuje odpowied  do klienta.

3.3.3 Wyzwalacze

Serwer Tomcat umo liwia podpi cie wyzwalaczy obudowuj cych wykonanie

dania przez serwlet. Zasada dzia ania jest podobna do serwletów filtruj cych [3], z

tym e wyzwalacze definiuje si na poziomie w z a. Wyzwalacz musi by obiektem
klasy implementuj cej interfejs

org.apache.catalina.Valve

W metodzie

invoke(Request, Response, Context)

programista mo e

zdefiniowa akcje, które b d wykonywane podczas obs ugi ka dego

dania.

Programista decyduje czy

danie ma by przetwarzane dalej, czy ma zosta

przerwane, wywo uj c lub nie metody

invokeNext(Request,

Response)

Przyk adowo implementacja kontenera autoryzuj cego opiera si na wyzwalaczach.
Przed wywo aniem odpowiedniej strony obs ugi

dania sprawdzane jest czy klient

posiada wystarczaj ce uprawnienia.

Wyzwalacze umo liwiaj tworzenie dzienników serwera lub stosowanie

globalnych dla ca ego serwera filtrów przychodz cych da .

W szczególno ci mechanizm ten jest równie wykorzystywany przy

implementacji klastra (patrz p. 3.4).

3.4 Implementacja klastra w serwerze Tomcat 5.0

W wersji 5.0 klaster dla serwera Tomcat zosta ustandaryzowany. Do czono

odpowiedni  mechanizm  pod czania  i  konfiguracji  odr bnych  implementacji
mechanizmu  rozpraszania  oblicze .  Osob   odpowiedzialn   za  rozwój  standardu,  jak
równie   do czenie  pierwszego  w  pe ni  dzia aj cego  modu u  klastra  w  oficjalnej
dystrybucji serwera, jest Filip Hanik cz onek zespo u programistów Tomcata.

Wybór Filipa Hanika jako osoby odpowiedzialnej za klaster nie by

przypadkowy. Ju wcze niej zaimplementowa on dzia aj c wtyczk do Tomcata
wersji 4.0 umo liwiaj c stworzenie klastra.

3.4.1 Klaster dla wersji 4.0

Hanik zaimplementowa w pe ni funkcjonalny modu dla Tomcata w wersji 4.0,

który po podpi ciu do serwera umo liwia  stworzenie klastra. Jego pomys  polega  na
podmianie  klasy  mened era  sesji,  w  której  doda   mechanizm  replikowania  zmian
zachodz cych w sesjach u ytkowników. Jako warstwy transportuj cej u y  biblioteki
JavaGroups  [6]  dostarczaj cej  mechanizmów  u atwiaj cych  programowanie  w

rodowisku rozproszonym. Konfiguracja JavaGroups dopuszcza komunikacj w

trybie  rozg oszeniowym  (ang.  multicast),  minimalizuj c   liczb   przesy anych
pakietów  (niestety  implementacja  nie  posiada  mechanizmów  zapewniaj cych
niezawodno  transmisji, jaka jest w protokole TPC/IP).

Rozwi zanie Filipa Hanika by o tylko zewn trzn nadbudówk do serwera, który

sam w sobie nie posiada jeszcze wtedy adnego wbudowanego wsparcia dla
klastrów. Wymusza o to tworzenie odr bnych klastrów dla ka dej aplikacji, co
oczywi cie powodowa o zb dny narzut.

W wersji 5.0 modu Filipa Hanika zosta przepisany i do czony do oficjalnej

dystrybucji.

3.4.2 Architektura klastra w wersji 5.0

Klaster jest ca kowicie zdecentralizowany, ka dy kolejny w ze do cza si

rozsy aj c odpowiedni komunikat w trybie rozg oszeniowym, w lokalnej sieci. Sesje
replikowane  s   do  wszystkich  w z ów    w  szczególno ci  zak ada  si ,  e  w z y
posiadaj   identyczny  stan  ka dej  sesji.  Klaster  nie  zak ada istnienia  zintegrowanego
mechanizmu  równowa cego  obci enie    ka de  kolejne

danie mo e trafi do

dowolnego serwera w klastrze i b dzie obs u one tak, jakby ca a interakcja odbywa a
si   na  jednej  fizycznej  maszynie.  Takie  podej cie  pozwala  na  zastosowanie
dynamicznego  równowa enia  obci enia,  z  czym  wi e  si   minimalizacja  wariancji
czasu obs ugi  dania.

Klaster jest zaimplementowany jako modu (plik z rozszerzeniem .jar), który

mo na opcjonalnie do czy do serwera Tomcat.

3.4.3 Implementacja klastra w wersji 5.0

Kody ród owe modu u mo na podzieli na trzy cz ci:

1. warstwa transportuj ca (por. p. 3.4.3.1),
2. warstwa zwi zana z serwerem Tomcat: mened er sesji, obiekt sesji (por. p.

3.4.3.2),

3. klasy pomocnicze (por. p. 3.4.3.3).

3.4.3.1 Warstwa transportuj ca

Hanik zrezygnowa z korzystania z biblioteki JavaGroups jak sam twierdzi z

powodu

braku

gwarancji

poprawno ci

przesy anych

informacji

[11].

Zaimplementowa  warstw  opart  na protokole TCP/IP, s u c  do wymiany danych
mi dzy  w z ami  klastra.  Ka dy  w ze   trzyma  otwarte  po czenia  do  wszystkich
pozosta ych  w z ów.  Lista  pozosta ych  w z ów  uaktualniana  jest  na  podstawie
periodycznie

wysy anych

komunikatów

istnieniu

w z a

trybie

rozg oszeniowym).  Je eli  który   w ze   przestanie  wysy a   komunikat,  to  pozosta e
komputery uznaj ,  e nast pi a w nim awaria i wyrzuc  go z listy cz onków klastra.
Niestety  pojawia  si   tu  problem  rozspójnienia  klastra    mo e  zdarzy   si ,  e  cz

w z ów uzna, e dany komputer przesta dzia a (np. z powodu nadmiernego
obci enia sieci, b d procesora), a cz

pozostawi go na li cie aktywnych w z ów.

Wtedy  podczas  replikacji  uaktualniona  wersja  sesji  nie  dotrze  do  wszystkich
komputerów. Przy za o eniu,  e ca y klaster posiada spójn  wersj  sesji, mo e okaza
si   to  du ym  zagro eniem  utraty  danych.  Wystarczy,  e  kolejne

danie zostanie

przekierowane do w z a nie posiadaj cego najnowszej wersji sesji.

Ka dy w ze przy starcie otwiera jeden port, na którym b dzie oczekiwa na

po czenia  od  pozosta ych  w z ów.  Po czenie  nawi zywane  jest  tylko  raz,  a  przy
wysy aniu  danych  korzysta  si   z  wcze niej  otwartego  po czenia.  Niestety  mi dzy
ka dymi  dwoma  w z ami  otwierane  s   dwa  osobne  po czenia,  co  negatywnie
wp ywa na wydajno  sieci.

Ka dy w ze otwiera jeden port w trybie rozg oszeniowym, w celu

periodycznego wysy ania komunikatu o swoim istnieniu. W komunikacie znajduje si
informacja o w le oraz o porcie, na którym nas uchuje. Je eli odbiorca komunikatu
nie posiada otwartego po czenia do og aszaj cego si w z a, to inicjowane jest nowe
po czenie.

Wad wysy ania komunikatów w trybie rozg oszeniowym jest uniemo liwienie

pracy dwóch serwerów Tomcat na jednej fizycznej maszynie, tak aby oba nale a y do
tego samego klastra. Tylko jeden z serwerów b dzie w stanie otworzy konkretny
port rozg oszeniowy.

Wszelkie informacje wymieniane mi dzy w z ami klastra przesy ane s za

pomoc   wiadomo ci.  Komunikacja  jest  ca kowicie  bezstanowa    to  znaczy  po
wys aniu  komunikatu  nadawca  nie  oczekuje  na  odpowied ,  minimalizuj c  ryzyko
potencjalnych  zakleszcze   (ang.  deadlock).  Format  rozsy anych  wiadomo ci  jest
nast puj cy:

7 bajtów preambu a,

1 bajt d ugo wiadomo ci,

dane wiadomo ci,

7 bajtów zako czenie wiadomo ci.

Na dane sk ada si zserializowana posta klasy

SessionMessage

. Klasa zawiera

typ wiadomo ci, identyfikator sesji, dane sesji, identyfikator kontekstu oraz adres
w z a wysy aj cego wiadomo .

Wyst puj nast puj ce typy wiadomo ci:

EVT_SESSION_CREATED

zosta a utworzona nowa sesja lub istniej ca sesja

zosta a zmieniona;

EVT_SESSION_EXPIRED_WONOTIFY

wygas a sesja, ale nie nale y

powiadamia o tym s uchaczy (ang. listner);

EVT_SESSION_EXPIRED_WNOTIFY

wygas a sesja i nale y powiadomi

s uchaczy;

EVT_SESSION_ACCESSED

u ytkownik odwo a si do sesji, ale jej nie

zmienia ;

EVT_GET_ALL_SESSIONS

nowy w ze pobiera wszystkie do tej pory

stworzone sesje;

EVT_ALL_SESSION_DATA

przesy ane s dane sesji.

W aktualnej wersji rozwi zania zdarzenia

EVT_SESSION_EXPIRED_WONOTIFY

oraz

EVT_SESSION_EXPIRED_WNOTIFY

s obs ugiwane jednakowo, z powiadamianiem

s uchaczy.

Zapisywanie i odtwarzanie danych sesji

Dane sesji s serializowane za pomoc wywo ania standardowej metody

writeObjectData(ObjectOutputStream stream)

z klasy

StandardSession

, a

deserializowane

pomoc

metody

readObjectData(ObjectInputStream

stream)

. Przy odtwarzaniu danych sesji z tablicy bajtów, tworzony jest strumie

wej ciowy

ReplicationStream

, który czyta obiekty korzystaj c z mechanizmu

adowania klas dostarczanego przez kontekst aplikacji, do której nale y sesja. W ten

sposób przesy a si obiekty klas stworzonych w ramach danej aplikacji.

3.4.3.2 Warstwa zwi zana z serwerem Tomcat

Modu Hanika pod czany jest za pomoc klasy

SimpleTcpCluster

, któr

definiuje si w znaczniku

, w pliku konfiguracyjnym serwera. Klasa

implementuje standardowy interfejs

org.apache.catalina.Cluster

, dostarczaj c

niezb dnych metod do pracy systemu. W aktualnej wersji implementacja nie wspiera
metod instalacji oraz deinstalacji aplikacji w ca ym klastrze.

Klasa

SimpleTcpCluster

implementuje interfejs

org.apache.catalina.

Lifecycle

, wykorzystuj c metody

start()

oraz

stop()

do inicjowania swoich

struktur danych.

Przy starcie systemu w metodzie

start()

obiekt tworzy warstw transportuj c ,

przekazuj c do niej parametry pobrane z pliku konfiguracyjnego server.xml
(dok adniej o parametrach klastra b dzie mowa w p. 3.4.4).

W metodzie

createManager(String name)

, odpowiadaj cej za tworzenie

mened era

sesji,

przekazywany

jest

obiekt

instancji

klasy

SimpleTcpReplicationManager

, b d cej nadklas klasy

StandardManager

. Klasa

przeimplementowuje metod

createSession()

, w której tworzy i przekazuje obiekt

typu

ReplicatedSession

zamiast

StandardSession

. Obiekty replikowanych sesji

przechwytuj wywo ania metod

setAttribute(String name, Object value)

removeAttribute(String name)

expire(boolean notify)

z poziomu aplikacji w celu ustawienia bitu informuj cego o przeprowadzonych
zmianach w sesji. Po zako czeniu przetwarzania dania system podejmuje decyzj o
replikacji na podstawie warto ci tego bitu.

Inicjowanie procesu replikacji zachodzi w odpowiednim wyzwalaczu (obiekt

klasy

ReplicationValve

), podpi tym pod wywo ania

da . Po wykonaniu

dania

przez aplikacj obs uguj c dany kontekst, wyzwalacz wywo uje metod

requestCompleted(String sessionId)

w obiekcie zarz dcy sesji. Metoda

przekazuje wiadomo , zawieraj c zserializowane dane sesji, która zostaje rozes ana
do wszystkich w z ów w klastrze.

Rozsy anie wiadomo ci do w z ów mo e by wykonywane w dwóch trybach:

synchronicznym oraz asynchronicznym. Przy pierwszym trybie w tek obs uguj cy

danie jest równocze nie odpowiedzialny za rozes anie pakietów w obr bie klastra.

Powoduje to oczywi cie wyd u enie czasu obs ugi

dania, co mo e negatywnie

wp ywa na wydajno systemu.

W trybie asynchronicznym tworzone jest zadanie replikacji sesji, które zostanie

wykonane przez jeden ze specjalnych w tków zazwyczaj ju po zako czeniu
obs ugi

dania. Przy takim podej ciu klient nie musi niepotrzebnie czeka na

zako czenie  zadania  replikacji  sesji;  proces  ten  wykonywany  jest  w  tle,  w  czasie
przesy ania odpowiedzi do klienta. Niestety implementacja tego mechanizmu ma du
wad   nie jest w  aden sposób sprawdzane czy w ze  zd y  rozes a  now  wersj
sesji przy kolejnym odwo aniu. Czyli mo e zdarzy  si  nast puj ca sytuacja:

1.  Klient wysy a  danie do klastra i zostaje przekierowany do maszyny A.
2.  Podczas obs ugi  dania sesja zostaje zmodyfikowana (na maszynie A).
3.  Klient otrzymuje odpowied  i natychmiastowo wysy a kolejne  danie.
4.  Serwer równowa cy obci enie przekierowuje  danie do maszyny B.
5.  Kod obs uguj cy

danie odwo uje si do sesji, której maszyna A nie zd y a

jeszcze wys a do maszyny B.

Taka sytuacja mo e z atwo ci zaj przy nadmiernym obci eniu danego

w z a.  Z  powodu  braku  mocy  obliczeniowej  (lub  przeci enia  sieci)  wysy anie
wiadomo ci ze zmienionym stanem sesji zaczyna si  opó nia , co mo e doprowadzi
do  rozspójnienia  klastra  i  w  konsekwencji  utraty  danych.  W  praktycznych
zastosowaniach tryb asynchroniczny jest rozwi zaniem niedopuszczalnym, w a nie z
powodu ryzyka utraty danych.

Kolejnym powa nym problemem implementacji jest brak synchronizacji dost pu

do sesji w obr bie klastra. Klaster nie posiada adnego mechanizmu kontroluj cego
równoczesny dost p do tej samej sesji. Je eli klient wy le równolegle dwa

dania,

modyfikuj ce te same zasoby, to doprowadzi to do utraty danych. Co gorsze, mo e
okaza si , e cz

w z ów b dzie posiada a sesj zmienion przez jedno

danie, a

przez drugie je eli wiadomo ci z replikami b d dociera y w ró nej

kolejno ci.

Taka sytuacja mo e mie miejsce w przypadku stron HTML posiadaj cych

ramki. Po od wie eniu strony przegl darka wysy a równolegle wiele

da do tych

samych zasobów, automatycznie generuj c równoleg e odwo ania do tej samej sesji.

3.4.3.3 Klasy pomocnicze

Buforowanie

Zosta zaimplementowany prosty mechanizm buforowania przesy anych w sieci

informacji. W przypadku pracy w trybie asynchronicznym po przetworzeniu

dania

kolejkowane  jest  zadanie  replikacji  sesji.  Je eli  zadanie  dotycz ce  tej  samej  sesji
znajdowa o si  ju  w kolejce, to zostanie ono nadpisane przez nowsz  wersj . W ten
sposób  eliminuje  si   niepotrzebny  ruch  w  sieci.  Niemniej  jednak  taka  sytuacja  ma
miejsce  tylko  przy  du ym  obci eniu  sieci,  kiedy  w ze   nie  jest  w  stanie
wystarczaj co  szybko  wys a   wiadomo ci  do  pozosta ych  w z ów.  Niestety  zysk  z
wykorzystania

tego

mechanizmu

jest

iluzoryczny,

poniewa

jest

ma o

prawdopodobne,  e kolejne  danie trafi do tego samego w z a. Skoro zak ada si ,  e
mog  wyst powa  tak du e opó nienia w rozsy aniu replik zmienionej sesji, to klaster
bardzo szybko stanie si  niespójny i zacznie traci  dane.

Pula w tków

W celu minimalizowania narzutu zwi zanego z tworzeniem w tków zosta a

zaimplementowana  pula  w tków,  obs uguj ca  przychodz ce  wiadomo ci.  Je eli
w tek nas uchuj cy na otwartych po czeniach z pozosta ymi w z ami odbierze dane,
to  budzi  jeden  z  w tków  z  puli  i  przydziela  mu  gniazdo  (ang.  socket),  z  którego
nale y  wczyta   dane.  W tek  wczytuje  kolejne  wiadomo ci  przetwarzaj c  je
synchronicznie. Po zako czeniu zwraca gniazdo i przechodzi w stan oczekiwania.

3.4.4 Konfiguracja klastra w wersji 5.0

Klaster w cza si poprzez odkomentowanie sekcji klastra w pliku server.xml:

<Cluster

className=org.apache.catalina.cluster.tcp.SimpleTcpCluster

name=FilipsCluster

debug=10

serviceclass=org.apache.catalina.cluster.mcast.McastService

mcastAddr=228.0.0.4

mcastPort=45564

mcastFrequency=500

mcastDropTime=3000

tcpThreadCount=2

tcpListenAddress=auto

tcpListenPort=4001

tcpSelectorTimeout=100

printToScreen=false

expireSessionsOnShutdown=false

useDirtyFlag=true

replicationMode=synchronous

oraz sekcji wyzwalacza wykorzystywanego przez klaster:

<Valve

className=org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;

Znaczenie odpowiednich atrybutów w sekcji klastra:

name

nazwa klastra (warto w zasadzie nie wykorzystywana),

debug

poziom szczegó owo ci generowanych przez implementacj zapisów

systemowych,

serviceclass

klasa s u ca do dostarczania informacji o dost pnych

w z ach

klastrze

(musi

implementowa

interfejs

org.apache.catalina.cluster.MembershipService

mcastAddr

adres rozg oszeniowy, na którym w z y b d powiadamia y si

nawzajem o swoim istnieniu,

mcastPort

port u ywany przy rozg aszaniu,

mcastFrequency

cz stotliwo rozsy ania informacji o istnieniu w z a (w

milisekundach),

mcastDropTime

czas po jakim w ze zostaje uznany za niesprawny od

momentu otrzymania ostatniego pakietu o jego istnieniu,

tcpThreadCount

liczba w tków obs uguj cych przychodz ce wiadomo ci

w klastrze,

tcpListenAddress

adres, na którym w ze spodziewa si po cze od

pozosta ych  w z ów  (je eli  ustawiona  jest  warto   auto,  to  zostanie  u yty
domy lny  adres  komputera).  Wykorzystuje  si   go,  je eli  komputer  posiada
wi cej ni  jedn  kart  sieciow ,

10.

tcpListenPort

port, na którym nas uchuje w ze ,

11.

tcpSelectorTimeout

czas w milisekundach po jakim w tek nas uchuj cy

na otwartych po czeniach ma sprawdzi czy serwer nie jest zamykany,

12.

printToScreen

czy strumie diagnostyczny ma by przekierowany do

standardowego wyj cia,

13.

expireSessionsOnShutdown

czy podczas zamykania serwera sesje maj

zosta zdezaktualizowane,

14.

useDirtyFlag

czy sesja ma by replikowana tylko po wywo aniu metod

setAttribute(..)

removeAttribute(..)

expire()

invalidate()

setPrincipal(..)

setMaxInactiveInterval(..)

15.

replicationMode

przyjmuje warto

synchronous

lub

asynchronous

oznacza tryb w jakim sesje b d replikowane.

Wyzwalacz przyjmuje atrybuty:

filter

zawiera wyra enia regularne oddzielone znakiem

rednika,

definiuj ce adresy, podczas przetwarzania których na pewno sesja nie b dzie
zmieniana. Przy obs udze tych

da mechanizm replikacji nie b dzie

wywo ywany, nawet gdy flaga

useDirty

b dzie ustawiona na fa sz.

3.4.5 Zalety rozwi zania

Zalet przedstawionego rozwi zania jest jego ca kowite zdecentralizowanie.

Klaster nie posiada wyró nionego w z a, co zwi ksza stabilno i odporno na

awarie konkretnej maszyny. Do czanie kolejnego w z a wi e si jedynie z
w czeniem go do sieci.

Kolejn cech wyró niaj c klaster w serwerze Tomcat jest ca kowita

niezale no od algorytmu równowa enia obci enia. Rozwi zanie nie wymaga
specjalnego

oprogramowania

interpretuj cego

identyfikatory

sesji

czy

zapami tuj cego przypisania w ze -sesja. Administrator mo e wykorzysta dowolny
mechanizm przekierowywania (programowy czy sprz towy).

Pe na replikacja (tzn. ka dy w ze replikuje swoje sesje do wszystkich

pozosta ych  w z ów)  zapewnia  du   odporno   klastra  na  awarie.  Wystarczy,  e
chocia   jeden  z  serwerów  pozostanie  sprawny,  aby  nie  utraci   adnych  informacji.
Poza  tym  umo liwia  zastosowanie  wyrafinowanych  algorytmów  równowa enia
obci enia,  które  nie  b d   ograniczane  sta ymi  przypisaniami  sesji  do  w z ów.  W
szczególno ci  po  dodaniu  kolejnego  w z a  do  klastra  bardzo  szybko  mo emy
przerzuci   na  niego  obci enie  z  pozosta ych  komputerów,  a  nie  tylko
przekierowywa  nowo przyby ych u ytkowników.

Niestety rozwi zanie oprócz zalet ma równie wady. Niektóre z nich s na tyle

powa ne, e uniemo liwiaj wykorzystanie serwera w komercyjnych zastosowaniach.
Rozwi zanie nie gwarantuje poprawnego dzia ania systemu.

3.4.6 Wady rozwi zania

G ówn wad rozwi zania jest brak synchronizacji przy dost pie do sesji oraz

brak  kontroli  nad  spójno ci   klastra.  Za o enie  o  pe nej  replikacji  poci ga  za  sob
konieczno  zapewnienia mechanizmu synchronizacji przy wprowadzaniu zmian czy
chocia by  odczycie  sesji.  Je eli  ka dy  komputer  mo e  uchodzi   za  serwer
macierzysty dowolnej sesji (czyli mo e obs ugiwa  wszelkie

dania, jakie docieraj

do klastra), to nale y uniemo liwi  wprowadzanie równoczesnych zmian na ró nych
maszynach.  Niestety  rozwi zanie  Filipa  Hanika  ignoruje  zagro enie  równoleg ych
zmian, tak samo jak ignoruje mo liwo  opó nie  w replikacji sesji. Je eli komputer
z  powodu  nadmiernego  obci enia  opó ni  rozes anie  nowej  wersji  sesji,  to  przy
kolejnym

daniu klienta, przekierowanym do innego w z a, aplikacja b dzie

korzysta a  z  nieaktualnej  wersji  danych,  nadpisuj c  tym  samym  poprzednie  zmiany.
Co gorsze w takiej sytuacji nie ma pewno ci, która wersja sesji trafi do pozosta ych
w z ów, poniewa  b dzie to zale a o tylko od kolejno ci w jakiej odbior  one repliki
z dwóch ró nych  róde .

Nie mniej wa ne jest niebezpiecze stwo rozspójnienia klastra. Zak ada si , e

wszystkie  w z y  w  klastrze  posiadaj   identyczn   wersj   dowolnej  sesji,  ale  co  si
stanie  je eli  w ze   chwilowo  uzna  inny  komputer  za  niesprawny  i  nie  prze le  mu
repliki  zmienionej  sesji?  Taka  sytuacja  mo e  zaistnie   przy  du ym  obci eniu  sieci
lub  maszyny    wystarczy,  e  na  czas  nie  dotrze  do  którego   w z a  pakiet
rozg oszeniowy  informuj cy  o  istnieniu  innego  w z a.  Ten  odrzuci  go,  s dz c,  e
w ze  przesta  dzia a  i nie b dzie wysy a  do niego wiadomo ci. Za chwile pakiet o
istnieniu  znowu  dotrze  i  w ze   ponownie  zostanie  w czony  do  listy  aktywnych
cz onków, ale sesja nie zostanie ju  zaktualizowana.

Korzystanie z trybu rozg oszeniowego w sieci uniemo liwia zainstalowanie

dwóch w z ów klastra na jednej fizycznej maszynie tylko jeden serwer otworzy port
rozg oszeniowy  i  b dzie  móg   z  niego  korzysta .  To  mo e  okaza   si   spor
niedogodno ci   w  niektórych  topologiach  klastrów.  Czasami  administrator  mo e
chcie   zainstalowa   wi cej  ni   jeden  serwer  na  fizycznej  maszynie  zapewniaj c

4 Nowy klaster dla serwera Jakarta-Tomcat

W tym rozdziale przedstawiam w pe ni funkcjonalny i sprawnie dzia aj cy

klaster dla serwera Jakarta-Tomcat. Nowy projekt bazuje na koncepcji replikacji
ka dy

do ka dego,

ale

dodatkowo

rozwi zuje

wi kszo problemów

zidentyfikowanych  w  implementacji  Hanika.  W  szczególno ci  rozwi zuje  problem
synchronizacji  przy  dost pie  do  sesji  oraz  uniemo liwia  przypadkowe  rozspójnienie
klastra.  Nowa  implementacja  dostarcza  pewniejszy  mechanizm  automatycznej
detekcji i obs ugi awarii.

W rozdziale zostanie przedstawiony projekt i za o enia koncepcyjne nowego

klastra. Zostanie równie na wietlona implementacja wa niejszych cz ci systemu,
wraz z zastosowanymi algorytmami.

4.1 Architektura i za o enia koncepcyjne

Architektura zbli ona jest do tej wyst puj cej w klastrze z Tomcat wersji 5.0

ka dy  w ze   posiada  po czenia  do  wszystkich  pozosta ych  i  zak ada  si ,  e  stan
ka dej  sesji  na  ka dym  serwerze  jest  identyczny.  Brak  tutaj  przypisania  sesji  do
konkretnego serwera.

Aby zapewni efektywne synchronizowanie dost pu do sesji konieczne sta o si

scentralizowanie klastra.

4.1.1 Koncepcja centralnego sterowania

Wybrany w ze w sieci pe ni rol semafora przy dost pie do zasobów.

Przechowuje  on  informacje  o  wszystkich  dost pnych  obiektach  oraz  w z ach,  które
oczekuj  na zwolnienie obiektów. Granulacja dost pu jest na poziomie w ze -sesja, to
znaczy  ca y  obiekt  sesji  jest  udost pniany  w  danej  chwili  tylko  jednemu  w z owi.
Je eli  serwer  obs uguje  wiele

da równocze nie odwo uj cych si do tej samej

sesji, to aplikacja internetowa musi zapewni synchronizacj w obr bie pojedynczej
maszyny wirtualnej serwera (np. poprzez wykorzystanie s owa kluczowego

synchronized

w j zyku Java). Je eli

dania zostan rozrzucone po ró nych

maszynach, to zostan wykonane synchronicznie w nieokre lonej kolejno ci, ale
ka de

danie b dzie wykonywane z aktualn wersj sesji. Przy takim rozwi zaniu

aplikacje, w których wymagana jest równoczesna obs uga wielu

da dotycz cych

tej samej sesji (np. z powodu synchronizowania w tków

da ), b d musia y

wykonywa   si   w  rodowisku  ze  zintegrowanym  mechanizmem  równowa cym
obci enie  (patrz  p.  4.1.4).  Mechanizm  ten  zapewni  przekierowywanie  zg osze
odwo uj cych si  do tego samego zasobu na maszyn , która w danym momencie go
zajmuje.

Stworzenie w z a wyró nionego (serwer zarz dca) umo liwi o implementacj

centralnego  nadzorowania  spójno ci  klastra.  Maszyna  zajmuj ca  si   synchronizacj
dost pu  do sesji  równocze nie  jest  odpowiedzialna za przechowywanie  informacji  o
w z ach  klastra  i  rozpropagowywanie  tych  informacji  do  ka dego  w z a.  W  ten
sposób  w ze   zostanie  uznany  za  niesprawny  dopiero  wtedy,  gdy  serwer  zarz dca
uzna go za niesprawny i tak e dopiero wtedy zostanie on odrzucony przez wszystkie
pozosta e  w z y.  Takie  podej cie  eliminuje  niebezpiecze stwo  zaistnienia  sytuacji,
gdzie  jeden  z  w z ów  z  powodu  utraty  czno ci  odrzuca  chwilowo inny  w ze , nie
przesy aj c mu uaktualnionej wersji sesji. Dopóki w ze  nie dostanie komunikatu od
centralnego serwera o odrzuceniu danej maszyny, dopóty b dzie próbowa  nawi za

po czenie w celu uko czenia procesu replikacji, nie zwalniaj c replikowanych sesji.
Taki mechanizm gwarantuje, e ka de

danie, które trafi do klastra b dzie

obs ugiwane  z  najnowsz   wersj   sesji.  W  najgorszym  przypadku  mog   nast powa
opó nienia  spowodowane  nie  zwalnianiem  sesji  przez  w z y,  ale  to  mo na
wyeliminowa , je eli rol  zarz dcy przejmie serwer równowa cy obci enie. Wtedy
ka de  kolejne

danie b dzie przekierowywane do serwera aktualnie zajmuj cego

sesj , do której nast pi o odwo anie.

Implementacja przewiduje sta konfiguracj , gdzie serwerem centralnym b dzie

z  góry  ustalony  komputer.  Niemniej  jednak  istnieje  mo liwo   rozszerzenia  klastra
tak, aby serwer zarz dca by  wybierany drog  elekcji, w ród aktualnie pod czonych
w z ów (patrz p. 6). Wtedy w momencie awarii g ównej maszyny inny w ze  móg by
przej   jego  rol   i  zachowa   ci g o   pracy  systemu.  W  aktualnej  wersji
zaimplementowanego  klastra,  aby  zapewni   ci g o   pracy  w  przypadku  awarii
serwera  zarz dcy  niezb dne  by oby  zastosowanie  mechanizmu  dublowania  serwera
(ang.  mirroring).  W  sytuacji,  gdy  serwer  synchronizacyjny  przesta by  odpowiada
nast pi oby automatyczne od czenie komputera od sieci i wstawienie na jego miejsce
identycznie  skonfigurowanej  maszyny  (z  tym  samym  adresem  IP  oraz  serwerem
synchronizacyjnym  s uchaj cym  na  tym  samym  porcie).  Wtedy  pozosta e  w z y
ponownie nawi za yby po czenia z serwerem zarz dc  i rozpocz aby si  procedura
przy czania  kolejnych  w z ów  klastra  (dok adniej  jest  to  opisane  w  p.  4.2.4).  W
wyniku tych dzia a  system zosta by samoistnie odbudowany.

4.1.2 Podzia na warstwy

Implementacja modu u klastra sk ada si z dwóch podstawowych warstw:

1. warstwa transportuj ca,
2. warstwa synchronizacyjna.

Pierwsza z warstw jest odpowiedzialna za komunikacj w obr bie klastra tzn.

nawi zuje  po czenia  z  ustalonymi  komputerami  i  umo liwia  przesy anie  danych  w
sieci.  Dodatkowo  implementacja  tej  warstwy  musi  by   odporna  na  tymczasowe
awarie  w  sieci.  Je eli  zostanie  zlecone  wys anie  pakietu  do  danego  komputera  to,
warstwa ma dot d próbowa  wys a  dane, a  w ca o ci dotr  one do odbiorcy lub do
momentu,  gdy  komputer  ten  nie  zostanie  explicite  wyrzucony  z  listy  aktywnych
adresów.

Warstwa synchronizacyjna jest ci le zwi zana z serwerem Tomcat, zapewniaj c

mechanizmy  wy cznego  dost pu  do  sesji.  W  sytuacji,  gdy  serwer  pokrywa  si   z
serwerem  zarz dc ,  warstwa  dzia a  lokalnie.  Je eli  serwer  synchronizuj cy  jest  na
innej  maszynie,  to  warstwa  w  sposób  przezroczysty  komunikuje  si   z  zarz dc
poprzez  warstw   transportuj c .  System  wykorzystuje  warstw   w  celu  za o enia
blokady  na  zasoby  zwi zane  z  przetwarzanym

daniem. Po zako czeniu

przetwarzania blokada jest zwalniana. Warstwa przechowuje informacje o wszystkich
dost pnych w z ach w klastrze i jest odpowiedzialna za replikacj sesji.

W przypadku serwera zarz dcy implementacja warstwy synchronizacyjnej jest

dodatkowo rozbudowana. Przechowuje szczegó owe informacje o wszystkich
dost pnych zasobach i kolejkuje

dania dost pu do tych zasobów. W momencie

zwolnienia zasobu warstwa przydziela obiekt kolejnemu czekaj cemu w z owi,
wysy aj c do niego odpowiedni komunikat.

4.1.3 Wersjonowanie sesji

W systemie ka da sesja posiada swój numer wersji. Numer pocz tkowo jest

ustawiany na zero i jest zwi kszany po przetworzeniu ka dego kolejnego

dania

odwo uj cego si do danej sesji. Numer wersji jest u ywany podczas odzyskiwania
danych po awarii w z a. Je eli dany w ze przetworzy

danie zmieniaj ce sesj i

przed  zwolnieniem  blokady  tej  sesji  nast pi a  awaria,  to  system  wykorzysta  numer
wersji  w  celu  wyszukania  najnowszych  danych  w ród  pozosta ych  w z ów.  Istnieje
szansa,  e  w ze   zd y   przes a   uaktualnion   replik   sesji  do  chocia   jednego  z
pozosta ych serwerów i na tej podstawie uda si  odzyska  wprowadzone zmiany. Po
awarii w z a serwer zarz dca dla ka dej sesji, której w ze  nie zd y  zwolni , wysy a
zapytanie o numer wersji do pozosta ych komputerów. Ten który przeka e najwy szy
numer  wersji  rozpropaguje  swoje  dane  do  pozosta ych.  Oczywi cie  mechanizm  nie
zadzia a  w  przypadku  sesji,  których  obs uga  nie  zosta a  w  pe ni  uko czona,  jednak
ka da  awaria  poci ga  za  sob   pewne  niebezpiecze stwo  utraty  danych,  a  zadaniem
oprogramowania  jest  minimalizowanie  tego  ryzyka.  Mechanizm  odzyskiwania
danych po awarii w z a zosta  dok adniej opisany w p. 4.2.

4.1.4 Zintegrowany mechanizm równowa enia obci

enia

Ka dy klaster musi posiada serwer przekierowuj cy

dania do ko cowych

w z ów czyli tzw. punkt dost powy (serwer ruchu). Aplikacje klienckie zg aszaj ce
si  do systemu negocjuj  po czenie z punktem dost powym, nie widz c architektury
samego klastra. Serwer ten zazwyczaj pe ni jednocze nie rol  jednostki równowa cej
obci enie,  równomiernie  dziel c

dania na wszystkie maszyny. Posiada on swój

sta y adres IP, na który s t umaczone adresy WWW w serwerach nazw

. Poniewa

serwer  ruchu  musi  posiada   informacje  o  dost pnych  w z ach  w  klastrze,  aby  móc
przesy a  do nich  dania od klientów, naturalne wydaje si  po czenie serwera ruchu
z  serwerem  zarz dc .  Przy  takim  rozwi zaniu  administrator  nie  musi  dodatkowo
konfigurowa   serwera  ruchu,  ustawiaj c  mu  list   dost pnych  w z ów.  Dodatkowym
atutem  wykorzystania  zintegrowanego  mechanizmu  równowa enia  obci enia  jest
mo liwo   zwi kszenia  wydajno ci  systemu,  poprzez  skrócenie  czasu  reakcji  na

danie klienta. Serwer steruj cy ruchem ma dost p do informacji, który w ze

aktualnie zajmuje dan sesj . Posiadaj c takie dane jest w stanie kierowa ruch tak,
aby

minimalizowa

liczb

stosunkowo

drogich

wywo a

blokowania

odblokowywania sesji. Przy obs udze zg oszenia klient nie b dzie musia  oczekiwa
na  zako czenie  procesu  replikacji  sesji  i  zwolnienie  blokady  przez  poprzednio
obs uguj cy  go  w ze ,  tylko  od  razu  zostanie  przekierowany  do  w z a  aktualnie
posiadaj cego najnowsze dane.

Zastosowanie takiego rozwi zania daje ogromne mo liwo ci usprawnienia

samego  procesu  replikacji.  Maj c  pewno ,  e  nikt  nie  b dzie  oczekiwa   na
zwolnienie  blokady,  ka dy  z  serwerów  mo e  opó nia   moment  oddania  sesji,  a  co
wi cej  mo e  opó nia   moment  replikacji.  Dla  zapewnienia  niezawodno ci  w
przypadku awarii, ka dy z serwerów replikuje zmienion  sesj , zaraz po zako czeniu
obs ugi

dania, do jednego, losowo wybranego w z a klastra. Zadania rozes ania

danych do pozosta ych w z ów zostaj opó nione. Je eli w mi dzyczasie, przed
rozes aniem zmian w sesji, nadejdzie kolejne

danie zmieniaj ce t sam sesj , to

Istnieje mo liwo równowa enia obci enia na poziomie serwerów nazw, poprzez przekazywanie

ró nych adresów IP dla tego samego adresu WWW, ale takie rozwi zanie nie zapewnia mechanizmu
automatycznej naprawy awarii i jest du o bardziej statyczne w kontek cie równomiernej dystrybucji
ruchu.

system  w  momencie  wykonywania  zada   replikacji  roze le  wersj   uwzgl dniaj c
najnowsze  zmiany.  Zmniejsza  to  ruch  w  sieci,  eliminuj c  konieczno   rozes ania
wcze niejszych  zmian.  Bardzo  wa ne  jest  tutaj  dobranie  odpowiednich  czasów
buforowania,  aby  nie  doprowadzi   do  sytuacji,  gdzie  adna  sesja  nie  zmienia
kontekstu  wykonania  (analogicznie  do  architektury  serwer  macierzysty-zast pczy)  i
zanika  g ówna  zaleta  architektury  ka dy  do  ka dego,  czyli  równomierne
równowa enia obci enia.

4.1.5 Bezpiecze stwo

System nie zapewnia

adnych mechanizmów bezpiecze stwa podczas

replikowania  sesji  czy  autoryzacji  do czanego  w z a.  Zak ada  si ,  e  klaster
komunikuje  si   w  prywatnej  sieci,  za  cian   ogniow   (ang.  firewall)  i  wszystkie
odebrane  komunikaty  pochodz   od  w a ciwych  adresatów.  Wszelkie  przypadkowe
lub z o liwe komunikaty w sieci mog  doprowadzi  do wadliwego dzia ania klastra, a
nawet  do  jego  ca kowitego  zablokowania.  W  gestii  administratora  systemu  jest
odpowiednie zabezpieczenie sieci, w której komunikuj  si  w z y.

4.2 Dzia anie systemu

W tym podrozdziale zostanie opisany sposób reakcji systemu na podstawowe

rodzaje  zdarze ,  które  mog   si   pojawi   podczas  dzia ania.  Zostanie  omówiony
mechanizm do czania nowego w z a czy reakcja na zerwanie po czenia i ca kowit
awari  jednego z komputerów. Przy ka dym zdarzeniu g ówny nacisk k adziony  jest
na  zapewnienie  niezawodno ci  i  minimalizowanie  prawdopodobie stwa  utraty
danych przechowywanych w sesji.

Legenda diagramów:

Pojedynczy w ze klastra. Fizyczna maszyna mo e posiada
wiele odr bnych w z ów. Ka dy w ze to serwer Tomcat z
nowym modu em wspieraj cym klastry.

Serwer zarz dca mo e to by albo jeden z w z ów klastra,
albo serwer ruchu.

W ze , w którym nast pi a awaria.

Po czenie  TCP/IP  mi dzy  dwoma  w z ami.  Poniewa
mi dzy  ka dymi  dwoma  w z ami  jest  nawi zywane  tylko
jedno  fizyczne  po czenie,  wi c  kierunek  strza ki  oznacza
stron  aktywn  nawi zywanego po czenia.

Nowo

nawi zane

po czenie

TCP/IP.

przypadku

diagramów ukazuj cych awari w z a przerywana linia b dzie
oznacza a logiczne po czenie.

Zerwane fizyczne po czenie (np. z powodu zerwania kabla
lub awarii karty sieciowej).

KOMUNIKAT

Du ymi literami oznaczane s przesy ane komunikaty.
Strza ka nad komunikatem informuje o kierunku przesy ania.

Serwer zarz dca

FORCESYNC

Zg aszaj cy si w ze

Rys. 4.2. Schemat wykonywanych operacji po przy czeniu w z a

W drugiej fazie nast puje synchronizacja zasobów (por. rys. 4.2). Dla ka dego

identyfikatora sesji, wys anego przez nowy w ze , serwer zarz dca sprawdza numer
wersji z numerem zapisanym u siebie w strukturach danych. S mo liwe trzy
sytuacje:

1. Numery wersji s identyczne nie s podejmowane adne dzia ania.
2. Numer wersji trzymany przez zarz dc jest mniejszy od numeru

dostarczonego przez nowy w ze serwer wysy a do nowego w z a
komunikat

FORCESYNC

z identyfikatorem tej sesji.

3. Numer wersji trzymany przez zarz dc jest wi kszy od numeru dostarczonego

przez nowy w ze serwer wysy a komunikat

FORCESYNC

do jednego z

wcze niejszych cz onków klastra. Komunikat zawiera identyfikator sesji oraz
adres nowego w z a.

Komunikat

FORCESYNC

powoduje wymuszenie replikacji sesji dla danego

identyfikatora.  Opcjonalnie  mo na  wys a   adres  w z a,  do  którego  nale y  wys a
replik .  Je eli  adres  nie  zostanie  podany,  to  replika  b dzie  rozes ana  do  wszystkich
cz onków klastra. Dodatkowo serwer zarz dca przed wys aniem komunikatu ustawia
adresata  jako  aktualnie  zajmuj cego  sesj .  Jest  to  konieczne,  poniewa   serwer
zarz dca  zak ada,

e wszystkie pod czone w z y posiadaj identyczny stan

wszystkich sesji. Je eli nie zosta aby za o ona blokada, to

danie odwo uj ce si do

niezsynchronizowanej  sesji  mog oby  zosta   przekierowane  do  w z a  A,  który
jeszcze  nie  otrzyma   nowej  repliki.  Wtedy  w ze   za o y by  blokad   w  serwerze
synchronizacyjnym i  zacz  przetwarzanie

dania. Niestety

danie mia oby dost p

do  nieaktualnej  wersji  sesji.  Mechanizm  obroni  si   przed  tak   sytuacj ,
uniemo liwiaj c w z owi A za o enie blokady dopóty, dopóki nie zwolni jej w ze
replikuj cy. Ten z kolei zwolni sesj  dopiero po zako czeniu procesu replikacji, czyli
przes aniu najnowszej wersji danych do w z a A.

W sytuacji, gdy pod czany w ze jest ca kowicie nowym serwerem Tomcat,

przesy ana  tablica  identyfikatorów  sesji  b dzie  pusta.  Niemniej  jednak  przy
ponownym  pod czaniu  tego  samego  w z a  (na  przyk ad  z  powodu  chwilowego
zerwania po czenia) tablica mo e zawiera  dane.

Serwer zarz dca

NEWMEMBER
[sesja, wersja]

Rys. 4.7. Schemat odzyskiwania struktury klastra po awarii serwera zarz dcy

Wys any zostaje komunikat

NEWMEMBER

, zawieraj cy tablic par: sesja wraz z

numerem wersji (por. rys. 4.7). Dalsze kroki podejmowane przez system zosta y
opisane w p. 4.2.1.

Niestety serwer zarz dca podczas przyj cia komunikatu

NEWMEMBER

wraz z

wersjami  sesji  posiadanych  przez  w ze ,  nie  jest  w  stanie  rozstrzygn   czy  podane
wersje  s   aktualnie  najwy szymi  w  klastrze.  Tak   wiedz   mo e  zweryfikowa
dopiero po pod czeniu wszystkich w z ów, które wcze niej tworzy y klaster. Z tego
powodu,  przy  implementacji  serwera  zarz dcy,  konieczne  staje  si   chwilowe
zablokowanie  przetwarzania  jakichkolwiek

da po starcie serwera, aby pozwoli

mu na zebranie informacji, niezb dnych do prawid owej pracy systemu.

Przy takim rozwi zaniu awaria serwera zarz dcy nie powoduje utraty danych.

Oczywi cie mo e spowodowa ,  e system b dzie przez pewien czas niedost pny, ale
zak ada  si ,  e  taka  sytuacja  b dzie  mia a  miejsce  stosunkowo  rzadko,  wi c  nie
powinna negatywnie wp ywa  na wygod  pracy u ytkowników aplikacji.

4.3 Implementacja

Mimo bardzo podobnej architektury i koncepcji rozwi zania przy implementacji

w zasadzie nie uda o si wykorzysta kodu napisanego przez Hanika. W sk ad
nowego modu u wesz o jedynie kilka plików

ród owych z poprzedniej

implementacji, zawieraj cych mechanizm pod czenia modu u do serwera. W
szczególno ci s to klasy:

org.apache.catalina.cluster.session.SimpleTcpReplicationManager,

org.apache.catalina.cluster.session.ReplicatedSession,

org.apache.catalina.cluster.tcp.ReplicationValve.

Nak ad pracy jak nale a oby w o y w celu dostosowania kodów ród owych

starego modu u do celów nowego projektu by by porównywalny ze stworzeniem
ca o ci od nowa. Dlatego bardziej sensowne okaza o si zaimplementowanie ca ego
modu u od pocz tku.

Modu zosta napisany w j zyku Java (wersja 1.4), przy u yciu standardowych

bibliotek,  dostarczanych  wraz  z  instalacj   rodowiska  wykonywalnego  Javy  lub  z
dystrybucj   serwera  Jakarta-Tomcat.  Wybór  j zyka  programowania  zosta
zdeterminowany  przez  technologi   serwera  Tomcat.  Poniewa   ca y  system  zosta
zaimplementowany w j zyku Java, nie by o powodu, aby wprowadza  inny j zyk.

Kod modu u by pisany pod k tem maksymalizowania wydajno ci. Poniewa

zazwyczaj w tego typu systemach w skim gard em staje si przepustowo sieci,
g ówna cz

uwagi podczas tworzenia projektu by a po wi cona kwestii

minimalizowania  ilo ci  przesy anych  informacji.  Wi e  si   to  z  wyeliminowaniem
zb dnych  pakietów  (por. p.  4.3.1,  4.3.2) oraz  z mechanizmami buforowania  (por. p.
4.3.4).  Dodatkowym  utrudnieniem  podczas  pisania  by o  silnie  zrównoleglone

rodowisko pracy modu u. Serwer WWW pracuje wielow tkowo, obs uguj c nawet

kilkaset

da jednocze nie. Dobrze napisany modu klastra musi by zabezpieczony

przed  równoleg ym  dost pem,  jednocze nie  pozwalaj c  na  wykonywanie  mo liwie
jak  najwi kszej  liczby  operacji  w  tym  samym  czasie.  Zbyt  ma a  liczba  roz cznych
sekcji  krytycznych  spowolni  dzia anie  modu u,  tworz c  w skie  gard a.  Z  kolei  zbyt
cz ste wywo ania wej cia i wyj cia z sekcji krytycznej mo e negatywnie wp ywa  na
wydajno  i utrudnia  wykrywanie b dów.

Dodatkow wa n kwesti , decyduj c o sposobie budowania modu u by a

potrzeba dzia ania w dwóch ró nych trybach:

1. Jako klient, zg aszaj cy si do serwera zarz dcy.
2. Jako serwer zarz dca.

Zak ada si , e w drugim trybie modu mo e pracowa zarówno wewn trz

serwera Tomcat, z wykorzystaniem cz ci klienckiej mechanizmu synchronizacji, jak
i w niezale nej aplikacji (por. p. 4.3.7), wykorzystuj cej tylko cz

serwerow

mechanizmu. Dok adniejszy opis zastosowanego rozwi zania znajduje si w p. 4.3.6.

W dalszej cz ci pracy opisuj sposób implementowania poszczególnych cz ci

systemu, zaczynaj c od mechanizmu transportowania danych w sieci, a ko cz c na
algorytmie synchronizacji oraz równowa enia obci enia. W celu uproszczenia
notacji

zosta

zastosowany

skrót

org..

oznaczaj cy

pakiet

org.apache.catalina.cluster

4.3.1 Warstwa transportuj ca

Poniewa nowy klaster ma by rozwi zaniem tanim i atwym w instalacji, jako

mechanizm transportuj cy zosta  wykorzystany protokó  TCP/IP, przy u yciu którego
komputery mog  si  komunikowa  niemal e w ka dej dost pnej sieci. Drugim bardzo
wa nym  czynnikiem,  który  spowodowa   wybór  tej  technologii  jest  powszechno
gotowych,  sprawdzonych  implementacji  (obs uga  TCP/IP  jest  zaimplementowana  w
standardowych klasach Javy). Charakterystyka architektury klastra (po czenia ka dy
z  ka dym)  sugerowa aby  wykorzystanie  protoko u  rozg oszeniowego,  niemniej
jednak brak mechanizmów gwarantuj cych dostarczenie danych oraz sprawdzenia ich
poprawno ci, spowodowa  wykluczenie tego rozwi zania z projektu. Do poprawno ci
dzia ania  klastra  niezb dna  jest  gwarancja  dostarczenia  danych  w  niezmienionej
postaci. Tak  gwarancj  daje protokó  TCP/IP.

Na implementacj warstwy transportuj cej sk adaj si nast puj ce klasy:

org..transport.DestinationManager

org..transport.DestinationAddress

org..transport.socket.ServerSocketListener

org..transport.socket.ClientSocketListener

org..transport.socket.LoopbackSocketListener

Kluczow

rol

mechanizmie

transportuj cym

odgrywa

klasa

DestinationManager

. Zawiera ona metody umo liwiaj ce dodawanie/odejmowanie

adresów dost pnych komputerów oraz umo liwia odbieranie i wysy anie danych.

Ka dy serwer w klastrze identyfikowany jest poprzez unikatowy klucz. Na klucz

sk ada si adres IP oraz numer portu. Klasa

DestinationAddress

reprezentuje

adresy serwerów w module, jednocze nie implementuj c interfejs

org..Member

. W

klasie zosta a nadpisana metoda

equals()

, która sprawdza zgodno adresu IP oraz

portu porównywanych obiektów. Poza tym zosta a zaimplementowana metoda

compareTo(DestinationAddress)

, w której porównywane s adresy IP lub w

przypadku ich równo ci numery portów. Metoda ta jest wykorzystywana podczas
wybierania strony aktywnej/biernej przy nawi zywaniu po czenia (zostanie to
dok adniej opisane w dalszej cz ci punktu).

Obowi zkiem obiektu

DestinationManager

jest obs uga wszelkich problemów

zwi zanych z po czeniem i przesy aniem danych. Spor wad protoko u TCP/IP jest

atwo zerwania po czenia ka de po czenie jest uznawane za aktywne dopóki s

otrzymywane  pakiety.  Niestety  wystarczy,  e  z  powodu  przeci enia  sieci  lub
systemu operacyjnego pakiety zaczn  si  znacz co opó nia  i po czenie mo e zosta
zerwane. Poniewa  w  zastosowanej architekturze  spójno  klastra jest kontrolowana
za pomoc  aktywno ci po cze , aby ograniczy  liczb  omy kowych decyzji o awarii
w z ów,

implementacja

warstwy

transportuj cej

umo liwia

przezroczyste

odtwarzanie  chwilowo  zerwanych  po cze .  Po  utracie  po czenia  system  przez
pewien czas próbuje odtworzy  kana  komunikacyjny; je eli si  to nie powiedzie, to
informuje  wszystkich  zarejestrowanych  s uchaczy  o  utracie  adresata.  Mechanizm
powiadamiania  o  utracie  po czenia  jest  wykorzystywany  przez  klaster  do
podejmowania decyzji o awarii w z ów. W przypadku zwyk ego w z a znaczenie ma
tylko  informacja  o  zerwaniu  po czenia  z  serwerem  zarz dc     w ze   musi  zerwa
wszystkie pozosta e po czenia i próbowa  odnowi  komunikacj  z zarz dc . Z kolei
w przypadku serwera zarz dcy informacja o zerwaniu po czenia powoduje podj cie
decyzji o jego odrzuceniu z klastra. Wa n  cech  obiektu klasy

DestinationManager

jest fakt, e dany adresat b dzie uznawany przez obiekt jako aktywny dopóki nie
zostanie explicite wywo ane

RemoveDestination(DestinationAddress)

. Ten fakt

u atwia implementacj mechanizmu replikacji w ze wysy a dane do wszystkich
pozosta ych w z ów, niezale nie od tego czy s one dla niego dost pne czy nie.
Obiekt

DestinationManager

po prostu b dzie bez ko ca ponawia prób wys ania

lub stwierdzi fakt poprawnego zako czenia, je eli w mi dzyczasie adresat zostanie
usuni ty z listy aktywnych.

Aby unikn aktywnego oczekiwania na grupie po cze , ka dy kana

komunikacyjny ma swój w asny w tek, który go obs uguje. Istniej trzy typy
po cze :

ServerSocketListener

ClientSocketListener

oraz

LoopbackSocketListener

. Diagram na rys. 4.8 przedstawia hierarchi klas.

Data Model

DestinationManager

CreateDestination() : void

RemoveDestination() : void

AddErrorListener() : void

RemoveErrorListener() : void

Send() : void

start() : void

stop() : void

«interface»

LifeCycle

«thread»

ServerSocketListener

+  AddErrorListener() : void
+  RemoveErrorListener() : void
+  write() : void

«thread»

ClientSocketListener

«thread»

LoopbackSocketListener

«interface»

ErrorListener

«realize»

0..*

Rys. 4.8. Hierarchia klas warstwy transportuj cej

W celu zminimalizowania liczby przesy anych pakietów w sieci, pomi dzy

ka dymi dwoma w z ami otwierane jest tylko jedno po czenie. Wyró nia si stron
biern i aktywn . Strona bierna, czyli obiekt klasy

ServerSocketListener

nas uchuje na porcie identyfikuj cym w ze , oczekuj c na zainicjowanie po czenia
przez stron aktywn . Strona aktywna, czyli obiekt klasy

ClientSocketListener

nawi zuje komunikacj

cz c si na odpowiedni port adresata. Poniewa strona

bierna  nie  mo e  zidentyfikowa   strony  aktywnej  (nie  jest  w  stanie  pozna   numeru
portu, na którym nas uchuje strona aktywna, a jedynie adres IP, z którego si   czy),
wi c  w ze   inicjuj cy  po czenie  wysy a  w  pierwszej  kolejno ci  numer  swojego
portu. Rola w po czeniu jest ustalana na podstawie warto ci, któr  przeka e metoda

compareTo(DestinationAddress)

. Poni szy kod jest wykonywany podczas

tworzenia po czenia w obiekcie

DestinationManager

(oAddr.compareTo(oLocalAddr) < 0)

oCL =

new

ServerSocketListener(oAddr,

this

);

else if

(oAddr.compareTo(oLocalAddr) > 0)

oCL =

new

ClientSocketListener(

this

.oLocalAddr, oAddr,

this

);

else
throw new

RuntimeException(

Will not add localhost

);

Do prawid owego dzia ania systemu bardzo istotne jest, aby obie strony w tym

samym  momencie  zaprzesta y  prób  odtworzenia  zerwanego  po czenia.  Sytuacja,  w
której  strona  aktywna  dochodzi  do  wniosku,  e  po czenie  jest  zerwane,  natomiast
strona  bierna  wci   oczekuje  na  odtworzenie  kana u  komunikacyjnego,  mo e
doprowadzi  do b dnego dzia ania systemu. Strona aktywna mog aby przedsi wzi
pewne  kroki  zwi zane  z  zerwaniem  po czenia,  a  nast pnie  ponowi   prób

nawi zania komunikacji. Wtedy strona bierna odtworzy po czenie, niestety bez
powiadamiania s uchaczy o zerwaniu.

Schemat procesu nawi zywania po czenia jest przedstawiony na rys. 4.9.

Interactions

Strona bierna

DestinationManager

ServerSocketListener

Strona aktywna

DestinationManager

ClientSocketListener

CreateDestination(Strona bierna)

CreateDestination(Strona aktywna)

connect

SetChannel(channel)

connected

Rys. 4.9. Diagram nawi zywania po czenia

Obiekt

DestinationManager

podczas tworzenia otwiera port do nas uchu. W

momencie próby nawi zania po czenia (powrót z metody

accept()

), mened er

sprawdza czy istnieje obiekt konektora obs uguj cy adres zg aszaj cego si
komputera. Je eli istnieje, to wywo uje na nim metod

SetChannel(socket)

, tym

samym ko cz c procedur nawi zywania po czenia. Je eli nie istnieje, to wywo uje
na obiekcie klasy

MainSyncServer

(dok adniej o tej klasie b dzie mowa w p. 4.3.6),

metod

CanAccept(DestinationAddress)

. Je eli metoda przeka e warto

pozytywn , to mened er wywo uje sam dla siebie metod

CreateDestination

nowym adresatem jako argumentem. W tym momencie ca a procedura nawi zywania
po czenia zaczyna si na nowo. Taki mechanizm umo liwia serwerowi zarz dcy
akceptowanie po cze z nowymi, nieznanymi wcze niej w z ami.

Jedyna ró nica w konektorach biernym i aktywnym wyst puje w metodzie

Connect()

. Konektor bierny w tej metodzie przechodzi w stan oczekiwania na

wywo anie metody

SetChannel(SocketChannel)

, natomiast konektor aktywny

nawi zuje po czenie i wysy a jako pierwsze 4 bajty swój numer portu. Oba
konektory w przypadku przechwycenia jakiegokolwiek wyj tku wywo uj metod

ReConnect()

, która próbuje odnowi zerwane po czenie.

Poza dwoma podstawowymi typami po cze zosta o jeszcze stworzone

po czenie zwrotne, obiekt klasy

LoopbackSocketListener.

Wszystkie wysy ane

przez  niego  dane  od  razu  przekierowywane  s   do  funkcji  obs ugi  wiadomo ci
sieciowych,  nie  wywo uj c  niepotrzebnie  funkcji  systemowych.  Jest  on
wykorzystywany podczas przesy ania danych od serwera zarz dcy do serwera Tomcat
w przypadku, gdy serwer Tomcat jest jednocze nie serwerem zarz dc . Architektura
rozwi zania  wymusi a  taki  mechanizm    serwer  zarz dca  nie  wie  nic  o  istnieniu

serwera Tomcat. Jego zadanie sprowadza si jedynie do odbierania i wysy ania
odpowiednich komunikatów. Takie podej cie umo liwia odseparowanie serwera
zarz dcy od Tomcata (por. p. 4.3.7).

4.3.1.1 Odbieranie danych z sieci

Ka dy konektor posiada swoj pul buforów, do których mo e wpisywa

pobrane z sieci informacje (maksymalna liczba dost pnych buforów jest
konfigurowalna). Po odebraniu danych z sieci konektor pobiera kolejny wolny bufor,
przepisuje do niego wiadomo i wykonuje na obiekcie

DestinationManager

metod :

AddReadyBuffer(DestinationAddress oFromAddr, ExtendableByteBuffer

oData)

Po zako czeniu obs ugi wiadomo ci na obiekcie

ExtendableByteBuffer

musi

zosta wywo ana metoda

ReturnToQueue()

, aby konektor móg ponownie

wykorzysta bufor do odebrania danych. Je eli liczba wolnych buforów spadnie do
zera, to modu wstrzyma odbiór danych, tym samym chroni c system przed
nadmiernym zu yciem pami ci.

Implementacja warstwy transportuj cej jest bardzo silnie zale na od protoko u

TCP/IP.  Przeno no   i  uogólnianie  cz ci  transportuj cej  nie  by y  g ównymi
czynnikami  decyduj cymi  o  kszta cie  ko cowego  kodu.  Najwa niejsza  by a
wydajno  tej cz ci modu u, poniewa  to od niej zale a a wydajno  ca ego projektu.
Takie zabiegi jak tworzenie pojedynczych po cze , osobne w tki dla ka dego kana u
komunikacyjnego  czy  kolejki  buforów  mia y  na  celu  optymalizacj   modu u  klastra.
Mechanizm  odtwarzania  po cze   mia   na  celu  zabezpieczenie  klastra  przed
przypadkowym  rozbiciem  oraz  u atwienie  implementacji  samego  mechanizmu
replikowania sesji.

4.3.2 Komunikacja w klastrze

Komunikacja w klastrze odbywa si za pomoc warstwy transportuj cej. Aby

mo liwe by o przes anie danych konieczne jest wcze niejsze utworzenie adresata. W
celu  optymalizacji  zosta   stworzony  model  komunikacji  bezstanowej    to  znaczy
wys any  komunikat  zawiera  pe en  zbiór  informacji  potrzebnych  do  jego
przetworzenia  (analogicznie  do  modelu  komunikacji  w  serwerach  HTTP).  Nie  by o
potrzeby  tworzenia  skomplikowanych  w  implementacji  dialogów  mi dzy  stronami.
Przesy ane wiadomo ci maj  nast puj cy format:

32 bity d ugo przesy anej wiadomo ci.
8 bitów typ wiadomo ci.
Kolejne bity zawieraj dane zale ne od typu wiadomo ci.

Typy wiadomo ci mo na podzieli na dwa zbiory:

1. Wiadomo ci przesy ane mi dzy dwoma zwyk ymi w z ami.
2. Wiadomo ci przesy ane mi dzy zwyk ym w z em i serwerem zarz dc .

Wiadomo ci przesy ane mi dzy dwoma zwyk ymi w z ami

SESSIONS_ADD

dodanie nowej lub modyfikacja istniej cej sesji. W sekcji

danych znajduje si identyfikator sesji, kontekst oraz zserializowane dane
sesji.

Wiadomo ci przesy ane mi dzy zwyk ym w z em i serwerem zarz dc

Wiadomo ci przesy ane od serwera zarz dcy do zwyk ego w z a:

DESTINATIONS_ADD

dodanie nowego w z a do klastra. W sekcji danych

przesy any jest adres nowego w z a.

DESTINATION_REMOVE

usuni cie w z a z klastra. W sekcji danych

przesy any jest adres w z a.

OBTAINED_SESSION

sesja zosta a przyznana w z owi. W sekcji danych

znajduje  si   identyfikator  sesji,  kontekst  oraz  aktualny  numer  wersji  (je eli
w ze  posiada mniejszy numer oznacza to,  e  z jaki  powodów nie  otrzyma
repliki  ostatnich  zmian  i  musi  wstrzyma   modyfikacj   sesji  do  czasu
otrzymania naj wie szych danych).

SESSION_EXISTANCE

informacja czy podana sesja istnieje. W sekcji danych

znajduje si identyfikator sesji, kontekst oraz 1 bajt z informacj czy sesja
istnieje w klastrze czy nie. Komunikat jest wysy any w odpowiedzi na

CHECK_SESSION_EXISTANCE

CHECK_SESSION_VERSION

pro ba o odes anie numeru wersji sesji o

podanym identyfikatorze. W sekcji danych przesy any jest identyfikator sesji
oraz kontekst. Komunikat jest wysy any w momencie próby odzyskania sesji
zajmowanych przez w ze , który dozna awarii. Ka dy w ze w klastrze
odsy a numer wersji, a serwer zarz dca na tej podstawie wybiera w ze , który
zreplikuje swoj kopi danych do pozosta ych cz onków.

SESSIONS_REMOVE

usuni cie sesji. W sekcji danych znajduje si tablica

identyfikatorów sesji oraz kontekstów. Komunikat jest wysy any w momencie
wyga ni cia sesji. Serwer zarz dca podejmuje decyzj o zako czeniu ycia
sesji analogicznie do pojedynczego serwera Tomcat. Je eli przez odpowiednio
d ugi okres aden serwer nie poprosi o dost p do sesji, to zostaje ona uznana
za nieaktywn .

SESSIONS_REPLICATE_WITH_SYNC

wymuszenie procesu replikacji. W

sekcji  danych  znajduje  si   adres  w z a,  do  którego  nale y  wys a   replik
(je eli jest pusty, to nale y rozes a  repliki do wszystkich w z ów) oraz tablica
identyfikatorów  sesji,  które  nale y  replikowa .  W ze ,  który  odbierze
komunikat po zako czeniu replikacji musi zwolni  wszystkie sesje, poniewa
serwer  zarz dca  przed  wys aniem  wiadomo ci  ustawia  blokady  na  adresata.
Mechanizm ten zabezpiecza przed niebezpiecze stwem wprowadzania zmian
w sesjach przez inny w ze  w czasie replikowania. Wys ane repliki mog yby
nadpisa  nowo wprowadzone zmiany.

Wiadomo ci przesy ane od zwyk ego w z a do serwera zarz dcy:

OBTAIN_SESSION

zaj cie sesji. W sekcji danych znajduje si identyfikator

zajmowanej sesji oraz kontekst.

RELEASE_SESSION

zwolnienie sesji. W sekcji danych znajduje si

identyfikator zwalnianej sesji, kontekst, numer wersji sesji oraz liczba
zwolnie (zazwyczaj 1). Mo e si zdarzy , e w ze posiadaj c blokad na
sesji

otrzyma

serwera

zarz dcy

komunikat

SESSIONS_REPLICATE_WITH_SYNC

(na przyk ad z powodu zg oszenia si

nowego w z a do klastra). Wtedy w ze musi zwolni sesj wi cej ni raz,
wysy aj c w tym celu liczb zwolnie .

NEW_SESSION_MEMBER

zg oszenie si nowego w z a w klastrze. W sekcji

danych  znajduje  si   s ownik  par:  identyfikator  sesji  (wraz  z  kontekstem),
numer  wersji.  Komunikat  jest  wysy any  za  ka dym  razem,  gdy  nast pi
zerwanie  po czenia  mi dzy  zwyk ym  w z em  a  serwerem  zarz dc .  W
przypadku zupe nie nowego w z a s ownik b dzie pusty.

SESSION_CREATED

utworzenie sesji. W sekcji danych znajduje si

identyfikator  sesji  oraz  kontekst.  Komunikat  jest  wysy any  zaraz  po
utworzeniu  sesji.  Wys anie  komunikatu  jest  konieczne,  aby  pozosta e  w z y
mog y  si   dowiedzie   poprzez  komunikat

CHECK_SESSION_EXISTANCE

istnieniu tej sesji zanim twórca zako czy proces replikacji.

CHECK_SESSION_EXISTANCE

sprawdzenie istnienia sesji. W sekcji danych

znajduje si identyfikator sesji oraz kontekst. Komunikat jest wysy any, je eli
w ze otrzyma

danie odwo uj ce si do nieistniej cej sesji. Poniewa sesja

mog a by stworzona na innym w le, ale jeszcze nie dosz a replika, serwer
wpierw sprawdza u zarz dcy czy identyfikator jest aktywny.

Po odebraniu komunikatu z sieci tworzone jest zadanie (wi cej o zadaniach

b dzie mowa w p. 4.3.3):

org..task.SessionReceivedTask

w przypadku, gdy modu dzia a

wewn trz

serwera

Tomcat

(zadanie

tworzone

jest

obiekcie

org..transport.TransportCluster

org..task.MessageReceivedTask

w przypadku, gdy modu dzia a jako

niezale ny

serwer

zarz dca

(zadanie

tworzone

jest

obiekcie

org..transport.DestinationManager

Zadanie

SessionReceivedTask

dziedziczy

MessageReceivedTask

dok adaj c  kilka  mo liwych  typów  wiadomo ci,  które  mo e  obs ugiwa .  W
szczególno ci  s   to wiadomo ci  odbierane  przez  zwyk e  w z y  od serwera zarz dcy
lub  wiadomo ci  wymieniane  mi dzy  zwyk ymi  w z ami.  Zak ada  si ,  e  serwer
zarz dca nie musi nic wiedzie  o mened erze sesji. Natomiast

SessionReceivedTask

posiada atrybut wskazuj cy na mened era sesji niezb dne podczas przetwarzania
takich komunikatów jak chocia by

SESSIONS_ADD

Zadania tworzone na potrzeby przetwarzania komunikatów posiadaj specjaln

kolejk zada , gwarantuj c , e komunikaty b d przetwarzane w kolejno ci, w
której nadesz y (lub ewentualnie równolegle).

4.3.3 Mechanizm kolejki zada zale nych

Na potrzeby projektu zosta a stworzona wyspecjalizowana kolejka do

przetwarzania  zada .  Kolejka  posiada  swoj   w asn   pul   w tków  przetwarzaj cych
instrukcje. W ten sposób istnieje mo liwo  zlecania zada , które maj  si  wykona
asynchronicznie  (jak  np.  replikacja  sesji).  W tki  tworzone  s   raz,  w  momencie
tworzenia  kolejki,  a ich praca sprowadza si  do oczekiwania na nadej cie kolejnego
zadania,  które  mog yby  wykona .  Je eli  zada   nie  ma,  to  w tki  przechodz   w  stan
u pienia. Zmieniaj c  liczb  w tków w  kolejce mo na kontrolowa  zu ycie  zasobów
systemowych przez modu  klastra (szerzej o konfigurowaniu klastra b dzie mowa w
p. 4.4).

Kolejka zada posiada dodatkowe, bardzo przydatne mo liwo ci:

1. definiowania zada , które zostan wykonane z opó nieniem (np. zwolnienie

sesji przy wykorzystaniu buforowania);

2. definiowania zale no ci mi dzy zadaniami czyli zadanie zostanie

wystartowane dopiero po wykonaniu innych zada (np. zwolnienie sesji po
zako czeniu wykonywania zada replikacji);

3. restartowania zadania, czyli ponownego wrzucenia zadania do kolejki, w

przypadku b du (np. ponawianie prób replikowania sesji do danego w z a).

Ka de zadanie musi dziedziczy po abstrakcyjnej klasie

org..task.Task

. Klasa

zawiera w szczególno ci abstrakcyjn metod

InternalRun()

, w której podklasy

umieszczaj kod zadania. Klasa zawiera metod

AddListener(Listener)

, poprzez

któr mo na do czy s uchaczy do zadania. S uchacze implementuj interfejs

org..task.Listener

public interface

Listener {

public void

WakeUp(

boolean

bError);

}

W momencie zako czenia wykonywania zadania dla ka dego do czonego

s uchacza wywo ywana jest metoda

WakeUp(boolean bError)

, z argumentem

informuj cym  czy  zadanie  zako czy o  si   z  b dem  czy  nie  (b d  jest  wynikiem
zg oszenia  przez  zadanie  wyj tku).  Ten  mechanizm  jest  wykorzystywany  przy
implementacji  zale no ci  mi dzy  zadaniami.  Po  prostu  klasa

Task

implementuje

interfejs s uchacza, a w metodzie

WakeUp(boolean)

zmniejsza licznik zada , na które

oczekuje. W momencie, gdy licznik spadnie do zera, zadanie samo si inicjuje,
dodaj c si do kolejki:

public void

WakeUp(

boolean

bError) {

this.DecTasks();

}

public synchronized void

DecTasks() {

nTasks--;

Start();

}

public void

Start() {

(nTasks <= 0) {

(this.nTimeoutFromStart > 0)

this.SetTime(System.currentTimeMillis() +

nTimeoutFromStart);

oTaskQueue.AddTask(

this

);

}

Je eli zadanie ma si wykona tylko w przypadku poprawnego zako czenia

wszystkich zada zale nych, to nale y przeimplementowa w podklasie metod

WakeUp(boolean)

, zmniejszaj c licznik zale no ci tylko w przypadku braku b du.

Ten mechanizm zosta wykorzystany przy implementacji zadania zwalniania sesji
(klasa

org..task.ReleaseSessionTask

public void

WakeUp(

boolean

bError) {

rror)

(! bE

super

.WakeUp(bError);

}

Zadanie zwolnienia sesji zale y od zada replikacji sesji do poszczególnych

w z ów.  Mo e  si   ono  wykona   tylko  w  przypadku  poprawnego  zako czenia
wszystkich  zada   replikacyjnych  (co  jest  równoznaczne  z  poprawnym  rozes aniem
replik do wszystkich w z ów w klastrze). Je eli wyst pi nieoczekiwany b d podczas
wykonywania  zada   replikuj cych  (np.  brak  pami ci  w  systemie),  to  sesja  nie
zostanie zwolniona, co zabezpieczy system przed gro b  utraty danych.

Na rys. 4.10 znajduje si hierarchia klas najwa niejszych zada zdefiniowanych

w systemie.

Tasks

Task

nTasks: int

oTaskQueue: WorkerQueue

# nTime: long

+  Start() : void
+  SetTime() : void
+  AddListener(Listener) : void
+  InternalRun() : void
+  Restart(int) : void
+  Run() : void
+  WakeUp() : void

«interface»

Listener

WorkerQueue

+ AddTask(Task) : void

+ RemoveTask(Task) : void

+ GetTask() : void

SendingTask

bRestartOnError: boolean

oDestManager: DestinationManager

Send(DestinationAddress, ByteBuffer) : void

BufferSendingTask

InternalRun() : void

ReleaseSessionTask

oSyncManager: SyncManager

oSessionID: SessionContext

+ InternalRun() : void

SessionPropagateTask

oSessionID: SessionContext

oSessionManager: SessionManager

oMember: ClusterMember

InternalRun() : void

MessageReceivedTask

# oBuffer: ExtendableByteBuffer

# oAddr: DestinationAddress

# oCluster: DestinationManager

# oSyncServer: MainSyncServer

+ InternalRun() : void

SessionReceivedTask

+ InternalRun() : void

«realize»

0..*

nale y do

0..*

zale y od

0..*

Rys. 4.10. Diagram hierarchii zada

Opis zada :

SendingTask

abstrakcyjna

klasa,

zawieraj ca

metod

Send(DestinationAddress,

ByteBuffer)

, która umo liwia wys anie

bufora z danymi do konkretnego adresata. Mo na skonfigurowa zadanie w
dwóch ró nych trybach:

a. Operacja wysy ania ma by blokuj ca tzn. powrót z metody

Send()

nast pi dopiero po faktycznym wys aniu danych.

b. B d podczas wysy ania ma powodowa restart zadania.

BufferSendingTask

klasa w metodzie

InternalRun()

wywo uje metod

Send()

z nadklasy. Klasa jest wykorzystywana do generowania zada

wysy aj cych proste komunikaty (np. komunikat o typie

OBTAINED_SESSION

SessionPropagateTask

klasa jest odpowiedzialna za wys anie repliki

konkretnej sesji do konkretnego adresata. W metodzie

InternalRun()

serializuje obiekt sesji i próbuje wys a dane do w z a (wywo uj c metod

Send()

z nadklasy). Klasa wykorzystuje tryb restartowania w przypadku

b du.  W  ten  sposób,  je eli  z  jakiego   powodu  wys anie  danych  zaczyna  si
opó nia , to nie blokuje niepotrzebnie pami ci zserializowanymi danymi sesji
i  co  wa niejsze  przy  kolejnym  uruchomieniu  zadania  ponawia  prób
replikacji, ale ju  by  mo e z nowsz  wersj  sesji, zmniejszaj c w ten sposób
liczb   przesy anych  informacji  (tworzenie  zada   replikacyjnych  zostanie
opisane w p. 4.3.5). Ponadto, je eli system wykorzystuje buforowanie, to przy
definicji zadania ustala si  opó nienie w wykonaniu (por. p. 4.3.4).

ReleaseSessionTask

zadania tej klasy s odpowiedzialne za zwalnianie

sesji w serwerze zarz dcy. System podczas tworzenia ustawia zale no  tego
zadania  od  wszystkich  zada   replikacyjnych  sesji.  Proces  zwolnienia  jest
uruchamiany dopiero po poprawnym przes aniu replik do wszystkich w z ów
w  klastrze.  W  przypadku  wykorzystywania  buforowania  system  dodatkowo
opó nia  start zadania  ju  po  wykonaniu wszystkich replikacji  (szerzej  na ten
temat b dzie mowa w p. 4.3.4).

MessageReceivedTask

zadanie tej klasy tworzone jest po odebraniu

wiadomo ci z sieci. Zadanie zawiera dane komunikatu oraz adres w z a, który
je  przys a . Przetwarzanie  wiadomo ci wykonywane jest w odr bnym w tku,
co powoduje,  e nie nast puje blokowanie w tku odbieraj cego dane z sieci.
W  ten  sposób  zapewniane  jest  maksymalne  zrównoleglenie  oblicze
wykonywanych  przez  modu   klastra,  co  mo e  nie  by   bez  znaczenia  w
przypadku serwerów wieloprocesorowych.

SessionReceivedTask

klasa dziedziczy po

MessageReceivedTask

dodaj c

w metodzie

internalRun()

obs ug komunikatów charakterystycznych w

sytuacji, gdy modu jest zanurzony wewn trz serwera Tomcat, jak np.
komunikat

SESSIONS_ADD

W systemie zosta y stworzone dwie odr bne kolejki zada :

dla zada  przetwarzaj cych odebrane z sieci komunikaty oraz
dla  pozosta ych  zada   wyst puj cych  w  systemie  (czyli  w  przewa aj cej
liczbie zada  wysy aj cych komunikaty).

Potrzeba odizolowania tych zada wynik a z faktu, e zadania przetwarzania

wiadomo ci odebranych nie mog by blokowane przez zadania wysy aj ce dane.

Mo na sobie wyobrazi  sytuacj , gdy wszystkie w tki w kolejce zosta y wstrzymane
przy  próbie  wys ania  danych  i  nie  ma  wolnego  w tka,  który  opró ni by  bufory  z
odebranymi  wiadomo ciami.  Bardzo  cz sto  to  w a nie  szybkie  przetworzenie
odebranych  informacji  b dzie  mia o  krytyczny  wp yw  na  wydajno   systemu.  W
pakietach  odbieranych  b d   informacje  o  przydzieleniu  sesji  (komunikat

OBTAINED_SESSION

) zinterpretowanie tego komunikatu powoduje bezpo rednie

wznowienie wykonywania zg oszenia wygenerowanego przez u ytkownika systemu.

Modu klastra umo liwia konfigurowanie liczby w tków do czonych do ka dej

z kolejek (opis konfiguracji znajduje si w p. 4.4).

4.3.3.1 Implementacja kolejki zada

Do implementacji kolejki zosta o wykorzystane drzewo (standardowa klasa Javy

java.util.TreeSet

) z warto ciami posortowanymi zgodnie z czasem wykonania.

Zadania, które maj  by  wykonane bez opó nienia wstawiane s  do drzewa z ma ymi
warto ciami,  natomiast  te,  które  maj   si   wykona   po  up ywie  pewnego  czasu  s
wstawiane z liczb  milisekund okre laj c  czas wykonania.

Ka dy w tek pod czony do drzewa w niesko czonej p tli pobiera zadanie z

kolejki (

WorkerQueue.GetTask()

wywo anie metody jest blokuj ce i w przypadku

braku zada powoduje wstrzymanie wykonywania). Nast pnie dla pobranego zadania
wywo uje metod

Run()

, która obudowuje wywo anie

InternalRun()

G ównym powodem stworzenia kolejki zada zale nych by a potrzeba realizacji

procesu  zwalniania  sesji  dopiero  po  udanym  zako czeniu  rozsy ania  kopii  do
wszystkich w z ów klastra. Drugim, nie mniej wa nym powodem by o umo liwienie
realizacji pewnych zada  z opó nieniem, jak np. wys anie repliki po pewnym czasie,
aby ewentualnie umo liwi  u ytkownikowi wprowadzenie kolejnych zmian i omin
wys anie wcze niejszej wersji.

Skuteczno i wydajno systemów rozproszonych w bardzo du ym stopniu

zale y  od  zastosowanych  metod  buforowania.  Wszelkiego  rodzaju  opó nianie
wys ania  danych  w  celu  ich  zagregowania  czy  eliminowanie  przesy ania
niepotrzebnych  wiadomo ci  powoduj ,

e system mo e w znacznym stopniu

przyspieszy swoje dzia anie. Stworzony modu klastra równie zawiera mechanizmy
usprawniaj ce jego dzia anie.

4.3.4 Buforowanie

W systemie zosta o zastosowane buforowanie w dwóch ró nych etapach:

1. Opó nianie momentu replikacji sesji.
2. Opó nianie momentu zwalniania sesji.

Oba typy buforowania s mo liwe do zastosowania tylko w przypadku

wykorzystania zintegrowanego serwera ruchu. Je eli serwer rozdzielaj cy zadania na
poszczególne  w z y  nie  b dzie  posiada   informacji  o  w le  aktualnie  zajmuj cym
sesj ,  to  buforowanie  na  poziomie  sesji  mo e  jedynie  niepotrzebnie  opó nia
dzia anie klastra. Je eli natomiast posiada takie informacje, to b dzie przekierowywa

dania do w z a, który aktualnie okupuje sesj , co umo liwia w z om opó nianie

momentu przekazania sesji.

Opó nianie momentu replikacji sesji

Ka de zadanie replikuj ce posiada numer sesji oraz adres w z a, do którego ma

wys a  replik . Modu  dla ka dego w z a przechowuje informacj  o stworzonych, ale
nie  rozpocz tych  zadaniach  replikuj cych,  z  mo liwo ci   wyszukiwania  po
identyfikatorze  sesji  (s ownik,  w  którym  kluczami  s   identyfikatory).  W  momencie
zako czenia przetwarzania  dania, system tworz c zadania replikuj ce sprawdza czy
nie  istnieje  ju   identyczne  zadanie,  które  jeszcze  nie  zd y o  si   wykona .  Je eli
istnieje, to nie ma potrzeby tworzenia kolejnego zadania, bo istniej ce tak czy owak w
momencie  wykonania  pobierze  naj wie sze  dane  sesji.  Nale y  tylko  do  zbioru
s uchaczy  istniej cego  zadania  doda   obiekt  klasy

ReleaseSessionTask

, aby w

odpowiednim momencie zwolni sesj .

Takie podej cie gwarantuje, e nawet je eli wiele w tków jednocze nie b dzie

przetwarza o

dania odwo uj ce si do tej samej sesji, to tak czy owak zostanie

stworzone  tylko  jedno  zadanie  replikuj ce,  zmniejszaj c  w  ten  sposób  liczb
przesy anych  informacji.  Dodatkowo  mechanizm  pozwala  na  atw   realizacj
koncepcji  opó niania  procesu  replikacji.  Wystarczy,  e  podczas  tworzenia  zadania
replikuj cego  modu   wstawi  opó nienie  w  jego  wykonanie.  Je eli  w  czasie
oczekiwania  zostanie  przetworzone  kolejne

danie (zmieniaj ce dane sesji), to

modu   ominie  wys anie  wcze niejszej  wersji.  W  ten  sposób  doprowadza  si   do
sytuacji,  gdzie  wydajno   klastra  przestaje  zale e   od  cz stotliwo ci  zg aszania  si
u ytkowników. W rezultacie sesja b dzie replikowane co pewien czas, niezale nie od
tego czy u ytkownik zg osi si  do systemu raz czy bardzo wiele razy. Dobór d ugo ci
opó nienia nie jest rzecz  zupe nie trywialn   je eli b dzie za ma e, to buforowanie
mo e  nie  przynosi   oczekiwanych  rezultatów.  Z  kolei  je eli  opó nienie  b dzie  za
du e,  to  system  straci  swoj   g ówn   zalet     czyli  dynamiczne  równowa enie
obci enia. Doprowadzi to do sytuacji, gdzie ka da sesja jest na sta e przypisana do
konkretnego  w z a    czyli  analogicznie  do  koncepcji  zastosowanej  w  serwerze  Bea
Weblogic  8.0  (por.  p.  2.3.2.1),  a  ca y  nak ad  zwi zany  z  synchronizowaniem  sesji
oka e si  zb dny.

Opó nianie wys ania zmienionych danych zwi ksza niebezpiecze stwo utraty

zmian.  Je eli  nast pi  awaria  w z a,  to  mo e  to  doprowadzi   do  utraty  nie  tylko
w a nie  przetwarzanych  sesji,  ale  równie   tych,  które  by y  przetworzone  wcze niej,
ale oczekiwa y na moment replikacji. Problem ten zosta  rozwi zany przez tworzenie
jednego  zadania  replikacyjnego  bez  opó nienia.  To  znaczy  modu   po  przetworzeniu

dania wybiera losowo jeden w ze , dla którego tworzy zadanie wys ania repliki z

natychmiastowym  czasem  wykonania.  W  ten  sposób  w  ka dej  chwili  naj wie sze
dane sesji znajduj  si  przynajmniej na dwóch maszynach. W razie awarii dane sesji
zostan

odzyskane

drugiej

maszyny

(patrz

opis

komunikatów

CHECK_SESSION_VERSION

oraz

SESSION_VERSION

w p. 4.3.2).

Opó nianie momentu zwalniania sesji

Poza opó nianiem wys ania pakietów z kopi najnowszej wersji sesji mo na

równie   opó nia   moment  zwolnienia  sesji.  Wydajno   klastra  jest  mierzona
szybko ci  reakcji systemu na zg oszenie u ytkownika. Im reakcja jest szybsza, tym
lepiej.  Niestety  architektura  zaimplementowanego  klastra  wymaga,  aby  przed
modyfikacj   danych  u ytkownika  system  zablokowa   sesj   w  serwerze
zarz dzaj cym.  Operacja  ta  jest  dosy   kosztowna    wymaga  przes ania  dwóch
pakietów w sieci (pro ba o zablokowanie i odpowied ). Je eli w ze  opó ni moment
oddania  sesji,  to  mo e  przetworzy   kilka  kolejnych

da bez potrzeby ponownego

U
y

lic

tio

r r

lik

r z

rz
d

o
e

y
w

r z

rz
d

ie
m

o
e

le
e

w
z

, k

tó

, c

ll(

, t

)

Rys. 4.11. Diagram przep ywu podczas obs ugi dania

Klient generuje zg oszenie, które zostaje wys ane do serwera Tomcat. Serwer

inicjuje wykonanie strumienia przetwarzania

da (por. p. 3.3.2). W ród

za czonych wyzwalaczy wyst puje równie wyzwalacz klasy

ReplicationValve

(analogicznie do implementacji Filipa Hanika). W metodzie

invoke(Request,

Response, Context)

wyzwalacz wznawia przetwarzanie strumienia w celu

wykonania zg oszenia. Po powrocie z metody

invokeNext(Request, Response,

Context)

program sprawdza czy

danie posiada sesj oraz czy sesja jest dzielona

przez ca y klaster. Je eli tak, to zwi ksza wersj sesji, tworzy dla ka dego w z a w
klastrze zadanie replikacyjne oraz tworzy zadanie odblokowania sesji, które wykona
si po rozes aniu wszystkich kopii. Nast pnie ko czy dzia anie, tym samym ko cz c

proces przetwarzania

dania. Wszystkie stworzone zadania wykonane zostan

asynchronicznie przez w tki obs uguj ce kolejk zada .

Oczywi cie zadania replikacyjne zostan stworzone tylko pod warunkiem, e w

systemie  nie  wyst powa y  ju   wcze niej  zdefiniowane  identyczne  zadania.  Po
wykonaniu  replikatorów  (zada   replikacyjnych)  do  kolejki  trafia  zadanie
odblokowania  sesji.  W  czasie  uruchomienia  sprawdza  czy  inne  w tki  aktualnie  nie
u ywaj   sesji.  Je eli  nie,  to  ustawia  w  strukturach  danych,  e  sesja  nie  jest
zablokowana  i  wysy a  komunikat  do  serwera  zarz dcy  w  celu  faktycznego
odblokowania.  Od  tego  momentu  ka dy  w tek,  który  spróbuje  si   odwo a   do  sesji
b dzie  musia   najpierw  zablokowa   j   u  zarz dcy.  Tutaj  warto  zwróci   uwag   na
implementacj   procesu  przydzielania  i  zwalniania  zasobu.  Nawet  je eli  zostan
wys ane  równolegle  dwa  pakiety:  jeden  z  pro b   o  zwolnienie,  a  drugi  o
zablokowanie  sesji,  to  poniewa   serwer  zlicza  ile  razy  semafor  zosta   podniesiony i
opuszcza  go  dok adnie  tyle  razy  ile  wys any  pakiet  to  specyfikuje,  nie  b dzie
niebezpiecze stwa wej cia do sekcji krytycznej bez podniesienia semafora. Po prostu
jeden pakiet zmniejszy licznik, a drugi go zwi kszy kolejno  nie b dzie odgrywa a
roli.

4.3.5.1 Proces tworzenia sesji

Je eli wygenerowane

danie nie posiada o wcze niej utworzonej sesji, a

aplikacja odwo a si do niej, to serwer Tomcat standardowo wywo a dla mened era
sesji metod

createSession()

. Poniewa dla aplikacji zadeklarowanych jako

rozproszone (tag

w pliku web.xml) mened erem jest obiekt klasy

org..server.SessionManager

, wywo anie to zostanie przechwycone przez modu

klastra. Mened er utworzy sesj (analogicznie jak w zwyk ych mened erach), ale
sesja b dzie instancj klasy

org..session.ReplicatedSession

(podklasa

org.apache.catalina.session.StandardSession

Dodatkowo

mened er

wygeneruje zadanie wys ania wiadomo ci

SESSION_CREATED

do serwera zarz dcy

informuj ce o stworzeniu nowego identyfikatora (zadanie b dzie wykonywane w tle).
Serwer zarz dca przetwarzaj c t  wiadomo  przy okazji podniesie semafor dla nowej
sesji a konto w z a, który j  stworzy  (aby nie trzeba by o wysy a  kolejnego pakietu
z pro b  o przyznanie sesji).

Oprócz wys ania wiadomo ci mened er ustawi w globalnych strukturach danych,

e sesja zosta a przydzielona temu w z owi. Na tym wywo anie metody

createSession()

si ko czy. Dalej nast puje przetwarzanie analogiczne do sytuacji,

gdy sesja by a utworzona wcze niej.

4.3.5.2 Proces sprawdzania istnienia sesji

Kolejnym przypadkiem jaki mo e si wydarzy jest odwo anie do sesji, która nie

jest zarejestrowana w mened erze. S dwie mo liwo ci zaistnienia takiej sytuacji (nie
licz c z o liwych da generowanych przez w amywaczy):

1. Sesja ju wygas a w klastrze.
2. W ze nie otrzyma jeszcze pakietu

SESSIONS_ADD

od twórcy sesji.

O ile w pierwszym przypadku mened er przez pewien czas mo e zachowywa

informacje o wygas ych sesjach i bez potrzeby komunikowania si z zarz dc po
prostu tworzy now sesj , o tyle w drugim przypadku konieczne jest wys anie
zapytania.

Obiekt klasy

SessionManager

w metodzie

findSession(String sessionID)

wykonuje nast puj cy kod:

public

Session findSession(String sSessionID)

throws

java.io.IOException {

return

findSession(sSessionID,

true

);

}

public

ion findSession(String sSessionID,

boolean

bCreate)

Sess

throws

java.io.IOException {

(sSessionID ==

null

)

return

null

;

Session oSession =

super

.findSession(sSessionID);

(oSession == null && sSessionID != null) {

// sprawdzamy czy sesja istnieje w klastrze

(oSyncServer.CheckExistance(new SessionContext(sSessionID,

this

.getName()))) {

synchronized

ssions) {

(se

oSession =

super

.findSession(sSessionID);

(oSession ==

null

) {

// sesja istnieje, ale my wci

jej nie mamy

// dlatego tworzymy pust , aby w tek móg

// przy odwo aniu rozpocz

procedur

// blokowania sesji.

oSession =

this

.createSession(sSessionID,

false

);

}

return

oSession;

}

Obiekt

oSyncServer

jest instancj klasy

org..server.SyncManager

(klasa

zosta a szerzej opisana w p. 4.3.6). Ka dy w ze klastra zawiera dok adnie jeden
obiekt tej klasy, wspó dzielony przez wszystkie mened ery sesji. Metoda

CheckExistance(SessionContext)

dzia a analogicznie do procedury zajmowania

sesji. To znaczy pierwszy w tek inicjuje faktyczn procedur sprawdzania u serwera
zarz dcy (wysy a komunikat

CHECK_SESSION_EXISTANCE

), a wszystkie kolejne

jedynie czekaj  na odpowied . Je eli oka e si ,  e w klastrze istnieje sesja o podanym
identyfikatorze, to mened er stworzy pusty obiekt i pozwoli na dalsze wykonywanie
w tku.  Nie  istnieje  tu  niebezpiecze stwo  rozspójnienia,  poniewa   mimo  stworzenia
pustej  sesji  nie  zosta a  ustawiona  na  niej  blokada.  Czyli  w tek,  który  b dzie  si
odwo ywa   do  danych  sesji,  tak  czy  owak  b dzie  musia   j   najpierw  zablokowa .  Z
kolei, aby  blokada si  uda a  musi  zako czy  si  proces replikacji, który spowoduje,

e pusty do tej pory obiekt sesji zostanie w ko cu zasilony danymi.

Nale y tu zwróci uwag na fakt, e w przypadku wykorzystania zintegrowanego

serwera ruchu w z y nie b d mia y potrzeby generowania dodatkowych zapyta do
serwera zarz dcy. Je eli jaka sesja b dzie w danym momencie zaj ta, to

danie

b dzie przekierowane do zajmuj cego j  w z a. Je eli nie b dzie przez nikogo zaj ta,
to b dzie to oznacza o,  e tak czy owak wszystkie w z y posiadaj  kopi  tej sesji i nie
b d  musia y si  pyta  serwera czy istnieje.

4.3.5.3 Proces blokowania sesji poprzez odwo anie

celu

zminimalizowania

niepotrzebnych operacji

blokowania

oraz

replikowania sesji moment wej cia do sekcji krytycznej zosta przeniesiony w miejsce
faktycznego odwo ania do danych sesji. Czyli je eli u ytkownik wygeneruje

danie,

które nie b dzie zagl da o do danych sesji (nie zostan wywo ane na sesji metody

getAttribute(String)

setAttribute(String, Object)

itp.), to nie spowoduje

to adnego ruchu po stronie klastra.

W dalszej cz ci tego punktu opisano sposób zaimplementowania tego

mechanizmu.

Obiekt klasy

ReplicatedSession

nadpisuje wywo ania wszystkich metod

zwi zanych z pobieraniem lub ustawianiem danych w sesji (czyli m.in.

getAttribute(String)

setAttribute(String, Object)

). W ka dej z tych metod

zanim zostanie wykonana metoda z nadklasy sprawdzane jest czy odwo uj cy si
w tek zablokowa ju t sesj . Je eli nie, to wywo ywana jest metoda

ObtainSession(String sessionID)

na mened erze sesji. To wywo anie z kolei

blokuje sesj u serwera zarz dcy (synchronicznie) lub zwi ksza licznik odwo a do
ju zaj tej sesji. Po przetworzeniu

dania (w wyzwalaczu

ReplicationValve

)

sprawdzane jest czy w tek zajmowa sesj . Je eli tak, to inicjowana jest replikacja
oraz zwolnienie sesji.

Niestety istnieje tu hipotetyczne niebezpiecze stwo,

e je eli aplikacja

przetwarzaj c

danie stworzy nowy w tek, który odwo a si do sesji, to pó niej sesja

ta nie zostanie zwolniona. W tek za o y blokad , której pó niej nie b dzie w stanie
zdj .  Jednak  sytuacja  taka  jest  na  tyle  specyficzna,  e  raczej  istnieje  ma e
prawdopodobie stwo,  e programi ci zdecyduj  si  na jej realizacj  w rzeczywistych
aplikacjach.  Nawet  gdyby  kto   chcia   zaimplementowa   tak   architektur
rozwi zania, to wystarczy,  e do nowego w tku przeka e ju  pobrane z sesji atrybuty,
a po zako czeniu jego wykonywania wpisze je z powrotem.

Tak czy owak w najgorszym wypadku w ze po prostu nie zwolni sesji, co przy

wykorzystaniu zintegrowanego serwera ruchu nie spowoduje zaprzestania dzia ania
aplikacji. Wszystkie

dania b d kierowane na jedn maszyn bez mo liwo ci

zmiany kontekstu wykonania. Atutem zastosowania klastra b dzie natomiast wci
trwaj cy proces replikowania sesji, co mo e okaza si nie bez znaczenia w
przypadku awarii tego w z a.

Ca a logika zwi zana z blokowaniem, zwalnianiem czy replikowaniem sesji

znajduje si w klasie mened era sesji (

org..server.SessionManager

) oraz klasie

samej sesji (

org..session.ReplicatedSession

). Niemniej jednak wi kszo kodu

niezb dnego do komunikacji z serwerem zarz dc jak i kod samego serwera zarz dcy
znajduje

dwóch

klasach:

org..server.MainSyncServer

oraz

org..server.SyncManager

4.3.6 Serwer zarz dca

G ównym celem implementacji serwera zarz dcy by a mo liwo wykorzystania

tego samego kodu w dwóch przypadkach:

1. Serwer zarz dca jest jednym z w z ów klastra (zamieszczony wewn trz

Tomcata).

2. Serwer zarz dca jest osobnym programem, który nie ma nic wspólnego z

klasami Tomcata.

Aby uzyska tak dwoisto modu u, zastosowano mechanizm dziedziczenia w

podej ciu obiektowym. Implementacja bazowa serwera zarz dcy opiera si na klasie

org..server.MainSyncServer

oraz klasie implementuj cej warstw transportuj c

org..server.DestinationManager

. Zastosowanie modu u wewn trz serwera

Tomcat staje si mo liwe poprzez dodanie klas dziedzicz cych po klasach bazowych
(por. rys. 4.12).

Dziedziczenie

Serwer zarz dca

Tomcat

SyncManager

oSyncedSessions: Hashtable = new Hashtable()

oMainAddr: DestinationAddress = null

# bIsMainServer: boolean

aSessionManagers: Hashtable = new Hashtable()

GetSessionManagers() : SessionManager[]

CheckSessionExistanceMessage(DestinationAddress, SessionContext) : void

SessionCreated(SessionContext) : void

AddClusterAddressMessage(DestinationAddress) : void

AddClusterAddress(DestinationAddress, Hashtable) : void

RemoveClusterAddressMessage(DestinationAddress) : void

ObtainSyncMessage(DestinationAddress, SessionContext) : void

ReleaseSyncMessage(DestinationAddress, SessionContext, long, int) : void

Obtain(SessionContext) : void

CheckExistance(SessionContext) : boolean

SessionObtainedMessage(SessionContext) : void

SessionExistanceMessage(SessionContext, boolean) : void

Release(SessionContext) : void

ConnectionError(DestinationAddress) : void

SimpleTcpReplicationManager

SessionManager

oSyncServer: SyncManager

oCluster: TransportCluster

+ SessionManager(String)

+ createSession(String) : Session

+ findSession(String) : Session

+ PropagateToAll(String, boolean) : void

+ ObtainSession(String) : void

MainSyncServer

oDestManager: DestinationManager

# oClusterAddresses: ArrayList = new ArrayList()

oSessions: Hashtable = new Hashtable()

MainSyncServer(DestinationManager)

ConnectionError(DestinationAddress) : void

AddClusterAddressMessage(DestinationAddress) : void

RemoveClusterAddressMessage(DestinationAddress) : void

SessionObtainedMessage(SessionContext) : void

AddClusterAddress(DestinationAddress, Hashtable) : void

SessionCreatedMessage(DestinationAddress, SessionContext) : void

ReleaseSyncMessage(DestinationAddress, SessionContext, long, int) : void

ObtainSyncMessage(DestinationAddress, SessionContext) : void

SessionExistanceMessage(SessionContext, boolean) : void

CheckSessionExistanceMessage(DestinationAddress, SessionContext) : void

Cluster

TransportCluster

# oSyncAddr: DestinationAddress = null

# aSessionManagers: Hashtable = new Hashtable()

+ TransportCluster()
+ GetSessionManager(String) : SessionManager

+  AddReadyBuffer(DestinationAddress, ExtendableByteBuffer) : void
+  start() : void
+  stop(String) : void
+  startContext(String) : void
+  installContext(String, URL) : void

+ createManager(String) : Manager

Lifecycle

DestinationManager

# oLocalAddr: DestinationAddress

# oSyncManager: MainSyncServer = null

# oWorkerQueue: WorkerQueue
# oReceiveWorkerQueue: WorkerQueue

+  DestinationManager()
+  CreateDestination(DestinationAddress, ErrorListener) : void
+  RemoveDestination(DestinationAddress) : void

+ Send(DestinationAddress, ByteBuffer, boolean) : void

+  AddReadyBuffer(DestinationAddress, ExtendableByteBuffer) : void
+  start() : void
+  stop() : void

0..*

+oCluster

0..*

1 -oSyncServer

Rys. 4.12. Hierarchia klas podzielona na dwa mo liwe zastosowania

W wywo aniach nadpisanych metod zosta dodany kod specyficzny dla serwera

Tomcat.  W  szczególno ci  zosta   zaimplementowany  mechanizm  zdalnego  lub
lokalnego (w zale no ci od konfiguracji) odwo ywania si  do serwera zarz dcy. Je eli
modu  ma dzia a  jako klient zdalnego serwera zarz dcy, to wszystkie odwo ania do

metod z klasy

SyncManager

powoduj wygenerowanie odpowiednich komunikatów

w sieci. Natomiast w przypadku, gdy modu wewn trz Tomcata pe ni jednocze nie
rol serwera zarz dcy, wtedy klasa

SyncManager

wywo uje kod z nadklasy, czyli

MainSyncServer

. Czyli tak naprawd zainstalowanie pojedynczego serwera w

klastrze (w trybie serwera zarz dcy) nie spowoduje znacz cego spadku wydajno ci w
stosunku do sytuacji, gdy serwer ten b dzie dzia a w ogóle bez modu u klastra. Taka
informacja mo e mie du y wp yw na podj cie decyzji o instalacji rodowiska
rozproszonego.

Administrator

instaluj c

klaster

nie

jest

zmuszony

natychmiastowego pod czenia wielu komputerów, w celu zrekompensowania spadku
mocy obliczeniowej. Pojedyncza maszyna b dzie dzia a a równie wydajnie jak przed
pod czeniem modu u.

Wydajno klastra w du ej mierze zale y od oprogramowania rozdzielaj cego

zadania na poszczególne jego w z y. Szczególnie istotne jest to w przypadku
przedstawionego w pracy rozwi zania. Algorytm, który nie wykorzystuje informacji o
aktualnych przydzia ach sesji, spowoduje os abienie mocy przerobowej systemu i
uniemo liwi wykorzystanie buforowania.

4.3.7 Serwer ruchu

Zasadniczym celem pracy by o napisanie i przedstawienie dzia aj cego modu u

klastra w serwerze Tomcat. Niemniej jednak, aby móc w ca o ci ukaza dzia anie
rozwi zania konieczne sta o si napisanie zintegrowanego serwera przekierowuj cego

dania do poszczególnych maszyn klastra. Niestety nie uda o si znale gotowego

programu, który odznacza by si nast puj cymi cechami:

Napisany w j zyku Java z dost pnym kodem ród owym.
Bardzo wydajny (przekierowania na poziomie TCP/IP).
Buforuj cy pul po cze .

Dlatego w ramach pracy zosta napisany serwer ruchu jednocze nie dzia aj cy

jako serwer zarz dca. Implementacj nale y traktowa jako wzorcowy przyk ad
rozwi zania, a nie jako docelowy i w pe ni dzia aj cy serwer do przekierowywania

da .

Serwer zosta w ca o ci napisany w j zyku Java z wykorzystaniem klas

bazowych z modu u klastra. Schemat dzia ania programu jest stosunkowo prosty:

1.  Przy starcie otwiera port, na którym b dzie przyjmowa   dania od klientów.
2.  Tworzy i inicjuje obiekty serwera zarz dcy.
3.  W  momencie,  gdy  jaki   w ze   klastra  zg osi  si   do  serwera  zarz dcy

jednocze nie dodawany jest do listy aktywnych serwerów Tomcat.

4. Przy zg oszeniu klienta program wybiera serwer Tomcat z listy aktywnych i

zaczyna si zachowywa jak serwer po rednicz cy, przekazuj c dane mi dzy
klientem a serwerem.

5. Je eli która ze stron zako czy po czenie, to program automatycznie ko czy

po czenie z drugiej strony.

6. W momencie zg oszenia awarii w z a przez oprogramowanie serwera

zarz dcy jest on automatycznie usuwany z listy aktywnych serwerów Tomcat.

4.3.7.1 Szczegó y implementacyjne

Dla ka dego aktywnego serwera Tomcat trzymana jest pula po cze (jej

wielko jest konfigurowalna). Ka de po czenie jest zadaniem, które w momencie

uruchomienia powoduje rozpocz cie czytania z kana u komunikacyjnego.
Jednocze nie obiekt zadania posiada metod

Write(ByteBuffer)

, która umo liwia

pisanie danych do po czenia. Przed ponownym uruchomieniem zadania
(wywo aniem metody

Restart()

) ustawiane s referencje mi dzy zadaniem

obs uguj cym  po czenie  z  serwerem,  a  zadaniem  obs uguj cym  po czenie  z
klientem.  W  ten  sposób  pó niej  wszystkie  odebrane  informacje  przez  jeden  obiekt
zostaj   przes ane  do  drugiego  (tworz c  pomost  dla  danych).  Ró nice  mi dzy
zadaniami klienta a serwera wyst puj  w zachowaniu na pocz tku i ko cu.

Zadanie po czenia klienta na pocz tku, zanim zostanie sparowane z zadaniem

serwerowym, czyta nag ówek

dania w celu sprawdzenia czy nie odwo uje si ono

do  konkretnej  sesji.  Je eli  tak,  to  program  sprawdza  czy  podana  sesja  nie  jest
aktualnie  zajmowana  przez  jeden  z  w z ów.  Je eli  jest  zajmowana,  to  zadanie  jako
odbiorc   wybiera  po czenie  z  puli  tego  w z a.  W  przeciwnym  przypadku  zadanie
wybiera serwer  posiadaj cy najwi cej nieu ywanych po cze .

Z kolei zadanie serwerowe po sko czeniu obs ugiwania klienta odnawia

po czenie z serwerem, aby przy obs udze kolejnego

dania nie trzeba by o traci

czasu  na  nawi zywanie  po czenia.  Istotne  jest,  aby  odpowiednio  skonfigurowa
po czenia  w  serwerach    tzn.  dopuszczalny  czas  bezruchu  na  po czeniu  musi  by
odpowiednio d ugi, aby po czenia nie by y zbyt szybko zrywane przez serwer. Je eli
po czenie zostanie zerwane zanim jaki  klient zacznie je wykorzystywa , to obs uga

dania zostanie wyd u ona o czas odnowienia po czenia.

Wykorzystanie zada umo liwi o dynamiczny przydzia w tków do obs ugi

wszystkich  po cze   ze  wszystkich  serwerów  jednocze nie.  W  ten  sposób  mo na
zwi kszy   liczb   oczekuj cych  po cze   bez  zwi kszania  liczby  w tków.
Dynamiczny  przydzia   w tków  ze  wspólnej  puli  powoduje,  e  rozwi zanie  du o
lepiej adaptuje si  do aktualnego zapotrzebowania na po czenia.

Warto zwróci uwag , e zastosowane rozwi zanie umo liwia wykorzystanie

opcji protoko u HTTP 1.1,

Connection: Keep-Alive

. Opcja pozwala przegl darce

na wykorzystanie raz otwartego po czenia dla obs ugi kilku osobnych

da . Po

prostu adna ze stron nie zerwie po czenia, tym samym zachowuj c aktywny pomost
w serwerze ruchu.

Wad zaproponowanego rozwi zania jest brak interpretera nag ówka protoko u

HTTP.  Gdyby  program  by   w  stanie  poprawnie  interpretowa   nag ówek  móg by
zachowywa   otwarte  po czenia  z  ka dym  z  w z ów,  bez  potrzeby  ich  odnawiania
(do tego niezb dna by aby kontrola d ugo ci przesy anych danych). Wtedy równie  w
przypadku  trzymania  po cze   typu

Keep-Alive

mo na by by o dynamicznie

zmienia serwer, który obs u y kolejne

danie. Niestety stopie skomplikowania

takiego interpretera wykracza poza ramy tej pracy.

Zarówno serwer ruchu jak i sam modu klastra zawieraj szereg parametrów,

które umo liwiaj dostrojenie systemu w zale no ci od zastosowania. W kolejnym
punkcie opisano parametry oraz przedstawiono ró ne dodatkowe wskazówki, którymi
mog si kierowa administratorzy klastra.

4.4 Konfiguracja klastra

Parametry klastra ustawia si w pliku konfiguracyjnym

server.xml

(analogicznie do rozwi zania z wersji 5.0). Nale y wstawi znacznik

Cluster

pliku opisuj cym ustawienia serwera Tomcat:

<Cluster

className=org..transport.TransportCluster

name=ReliableTransportCluster

debug=3

tcpListenAddr=192.168.0.2:4001

syncServer=192.168.0.2:4010

sendThreadCount=5

receiveThreadCount=3

receiveBufferCount=10

syncSessionHoldingTimeout=20000

sessionObtainTimeout=40000

serverSideConnTimeout=10000

clientSideReconnectCount=5

replicationBufferingTime=0

releaseSessionTimeout=0

Opis poszczególnych parametrów:

className

nazwa klasy implementuj cej interfejs

org..Cluster

name

nazwa klastra (tylko informacyjnie).

debug

poziom szczegó owo ci przy wypisywaniu komunikatów przez modu

klastra (od 0 do 10, przy czym dla 10 wypisywane jest wszystko).

tcpListenAddr

adres, na którym b dzie nas uchiwa modu klastra. Je eli

adres przed dwukropkiem nie zostanie podany, to modu pobierze domy lny
adres lokalny z maszyny (czyli np.

:4001

syncServer

adres serwera zarz dcy. Je eli adres b dzie pusty, to przyjmuje

si , e ten serwer ma dzia a w trybie serwera zarz dcy.

sendThreadCount

liczba w tków przetwarzaj cych zadania wysy aj ce

dane.

receiveThreadCount

liczba w tków przetwarzaj cych odebrane z sieci

komunikaty.

receiveBufferCount

liczba buforów, do których b d wpisywane

komunikaty  pobrane  z  sieci.  Powinno  ich  by   wi cej  ni   w tków,
przetwarzaj cych odebrane komunikaty. Z drugiej strony nie mo e ich by  za
du o, aby nadmiernie nie obci a  pami ci maszyny.

syncSessionHoldingTimeout

parametr odnosi si do serwera zarz dcy.

Okre la czas w milisekundach po jakim serwer ko czy zbieranie informacji o
tym, który w ze posiada najwy szy numer wersji danej sesji (np. po awarii
którego w z a).

sessionObtainTimeout

parametr okre la maksymalny czas oczekiwania na

zaj cie sesji w serwerze zarz dcy. Je eli czas zostanie przekroczony, to modu
zg osi wyj tek.

serverSideConnTimeout

parametr okre la czas w milisekundach, po

którym modu uznaje po czenie za zerwane, je eli nie uda si go ponownie
nawi za (powinien by taki sam dla wszystkich w z ów w klastrze).

clientSideReconnectCount

parametr okre la liczb prób, które ma podj

strona aktywna po czenia w celu odbudowania kana u komunikacyjnego.
Próby zostan roz o one równomiernie w czasie okre lonym parametrem

serverSideConnTimeout

replicationBufferingTime

parametr okre la opó nienie z jakim zostan

wykonane zadania replikowania sesji. Zero oznacza brak buforowania.

releaseSessionTimeout

parametr okre la opó nienie z jakim zostanie

zwolniona sesja (opó nienie b dzie liczone od momentu zako czenia
ostatniego zadania replikuj cego). Zero oznacza brak opó nienia.

Poza strojeniem parametrów klastra istnieje jeszcze mo liwo usprawnienia

dzia ania systemu poprzez odpowiednie skonfigurowanie sprz tu. Skuteczno  klastra
najbardziej  zale y  od  przepustowo ci  sieci.  Je eli  brakuje  funduszy  na  zakup  super
szybkiej sieci (jak np. sieci Myrinet), to mo na zainstalowa  dwie równoleg e sieci.

4.4.1 Koncepcja dwóch sieci

Architektura klastra pozwala na logiczny i fizyczny podzia przesy anych

informacji na dwie odr bne cz ci:

1. Dane przesy ane w ramach modu u klastra.
2. Dane przesy ane mi dzy klientem a serwerem Tomcat.

Je eli po czy si w z y dwoma niezale nymi sieciami, to mo na skonfigurowa

klaster tak, aby te dwie grupy danych by y przesy ane niezale nymi kana ami. W ten
sposób  mo na  doprowadzi   do  sytuacji,  gdzie  wydajno   systemu  ca kowicie
przestaje  zale e   od  wydajno ci  modu u  klastra.  Nawet  je eli  sie  obs uguj ca  dane
modu u klastra zacznie si  zapycha , to je eli wykorzysta si  zintegrowany serwer
ruchu, który b dzie  minimalizowa  liczb  operacji zajmowania i zwalniania sesji, to
reakcja  pojedynczego  w z a  b dzie  równie  szybka  jak  w  przypadku  systemu
z o onego z jednego serwera.

Koncepcja jest o tyle interesuj ca, e koszt zainstalowania drugiej sieci jest

stosunkowo  niewielki  w  porównaniu  z  zyskiem  jaki  mo na  w  ten  sposób  osi gn .
Dodatkowo  zainstalowanie  dwóch  sieci  upraszcza  ich  monitorowanie  oraz  u atwia
lepsze  zabezpieczenie  sieci  przesy aj cej  repliki  sesji  przed  potencjalnymi
w amywaczami.

Ka dy system WWW udost pniaj cy swoje zasoby do Internetu powinien

posiada   mechanizmy  zabezpieczaj ce  dane  przed  pods uchem  osób  trzecich.
Pojedynczy serwer Tomcat posiada obs ug  po cze  szyfrowanych HTTPS. Nale y
si  zastanowi  nad mo liwym wykorzystaniem  czy szyfrowanych w klastrze.

4.4.2 Mo liwe konfiguracje przy wykorzystaniu HTTPS

Zasadniczo istniej dwa mo liwe rozwi zania z wykorzystaniem HTTPS:

1. Zastosowanie serwera po rednicz cego, który deszyfruje dane zanim dotr

one do klastra.

2. Deszyfrowanie danych na poziomie ka dego w z a osobno.

Pierwsze rozwi zanie polega na umieszczeniu serwera z odpowiednim

oprogramowaniem (np. serwer HTTP Apache) lub sprz tu deszyfruj cego przed
serwerem ruchu. Wtedy klaster zachowuje si tak, jakby szyfrowanie nie
wyst powa o.

W drugim rozwi zaniu zak adamy, e serwer ruchu nie b dzie w stanie

odszyfrowa przesy anych informacji, a tylko b dzie je przesy a do wybranego przez

5 Testy wydajno ci

W tym rozdziale zostan przedstawione wyniki przeprowadzonych testów

wydajno ci  nowego  klastra.  Przy  projektowaniu  testów  by y  brane  pod  uwag   dwa
zasadnicze aspekty: poprawno  oraz szybko  dzia ania. Testy zosta y wykonane w
laboratorium  komputerowym  na  Wydziale  Matematyki,  Informatyki  i  Mechaniki
Uniwersytetu  Warszawskiego.  Dost pne  by y  dwa  typy  maszyn  o  nast puj cej
charakterystyce:

Parametr

Maszyna typu A

Maszyna typu B

Procesor

350 MHz

700 MHz

RAM

64 MB

128 MB

Sie

100 Mb/s

Linux

Do testowania zosta wykorzystany specjalnie w tym celu napisany program,

którego zadaniem by o generowanie odpowiedniej liczby równoleg ych

da do

systemu,  uwzgl dniaj cych  przes any  przez  system  identyfikator  sesji.  Aby  wyniki
by y  bardziej  miarodajne,  program  testuj cy  by   uruchamiany  równolegle  na  kilku
maszynach  (w  ten  sposób  wyniki  zosta y  uniezale nione  od  wydajno ci  konkretnej
maszyny  testuj cej,  co  mia o  szczególne  znaczenie  przy  testowaniu  po cze
szyfrowanych).

Po stronie serwera do testów zosta y wykorzystane dwa typy aplikacji. Pierwsza

aplikacja (dalej nazywana aplikacj sesyjn ) dzia a a w nast puj cy sposób:

1.  Pobiera a z  dania nazw  parametru oraz jego warto .
2.  Wstawia a t  par  do sesji.
3.  Zwraca a wszystkie pary klucz-warto  znajduj ce si  w sesji.

Aplikacja sesyjna zosta a napisana g ównie w celu praktycznego udowodnienia

poprawno ci dzia ania klastra. Program testuj cy generuj c kolejne

dania,

odwo uj ce si do tej samej sesji, sprawdza czy wynik

dania zgadza si z

oczekiwaniami.  Je eli  w  wyniku  nie  znajdowa   si   jeden  z  dodanych  przez  niego
parametrów,  to  podnoszony  by   wyj tek  i  test  ko czy   si   niepowodzeniem.  Nale y
zwróci  uwag  na fakt, i  z wydajno ciowego punktu widzenia aplikacja jest skrajnie
pesymistycznym  przypadkiem  wykorzystania  klastra.  Przetworzenie

dania

powoduje znikome obci enie serwera, jednocze nie zmuszaj c klaster do
replikowania wci rosn cych sesji.

Druga aplikacja (dalej nazywana aplikacj XSL) dzia a a w nast puj cy sposób:

1. Przy pierwszym daniu ustawia a w sesji dwa parametry:

cie k do pliku zawieraj cego dane zapisane w formacie XML,

cie k do pliku zawieraj cego przekszta cenie XSL prezentuj ce dane

z pliku XML.

2. Przy drugim

daniu aplikacja pobiera a oba parametry z sesji i wykonywa a

przekszta cenie XSL na danych z pliku XML.

Aplikacja nieco lepiej odwzorowuje praktyczne zastosowanie serwera Tomcat.

Co  prawda  nie  komunikuje  si   z  baz   danych,  co  ma  miejsce  w  wi kszo ci
prawdziwych  zastosowa   serwerów  aplikacyjnych,  niemniej  jednak  wykonuje
obliczenia  maj ce  na  celu  uatrakcyjnienie  wy wietlanych  informacji.  Wykorzystuje
bardzo  modne  ostatnio  technologie  XML  oraz  przekszta cenia  XSL  oddzielaj ce
warstw  danych od warstwy prezentacji.

Ka dy z przeprowadzonych scenariuszy testowych by wykonywany kilkakrotnie

w  celu  zwi kszenia  wiarygodno ci  wyników.  Tabele  wynikowe  prezentuj
u redniony  czas.  Podczas  bada   system  zachowywa   si   stabilnie    standardowe
odchylenie  oscylowa o  pomi dzy  5%,  a  15%.  Poniewa   ró nice  w  wynikach  by y
nieznaczne, nie zajmowa em si  badaniem odchylenia samego w sobie.

5.1 Test poprawno ci

Test poprawno ci zosta przeprowadzony na maszynach typu A. Program

testuj cy generowa kolejne

dania do aplikacji sesyjnej sprawdzaj c zgodno

danych. Przy ka dym

daniu wielko sesji by a zwi kszana o oko o 130 bajtów.

Charakterystyka testu:

Serwer zarz dca znajdowa si wewn trz jednego z serwerów Tomcat.
Przy ka dym kolejnym

daniu program testuj cy wybiera losowo jeden z

w z ów, do którego przesy a danie.

0 s.

20 s.

40 s.

60 s.

80 s.

100 s.

120 s.

bez klastra

2 w z y

3 w z y

4 w z y

5 w z ów

bez klastra

2 w z y

3 w z y

4 w z y

5 w z ów

100

30 w. 50 .

60 w. 50 .

90 w. 50 .

30 w. 100 .

Rys. 5.1. Wykres wyniku testów przy losowym wyborze serwera

Wykres na rys. 5.1 prezentuje czasy trwania kolejnych testów mierzone w

sekundach. Zapis 30 w. 50 . oznacza, e zosta o wygenerowanych 30 w tków, z

których ka dy wysy a kolejno bez opó nie 50

da , sukcesywnie zwi kszaj cych

sesj (ka dy w tek mia osobny identyfikator sesji).

Podstawowym zadaniem testu by o pokazanie poprawno ci dzia ania modu u co

zosta o osi gni te. Mimo skrajnie trudnych warunków pracy w jakich
przeprowadzono test (tzn. ci g a zmiana kontekstu wykonania

da bez

jakiegokolwiek  opó nienia)  modu   dzia a   poprawnie.  Testy  ko czy y  si   z  99,9
procentow   poprawno ci .  Przy  bardzo  du ym  obci eniu  czasami  zdarza o  si ,  e
klaster przekazywa  b d (status odpowiedzi na  danie 500), który by  spowodowany
przekroczeniem maksymalnego czasu  oczekiwania  na zaj cie  sesji.  Niemniej  jednak
nie  wyst pi a  sytuacja,  w  której  program  testuj cy  zaobserwowa by  niezgodno
danych czyli modu  nie dopu ci  do odczytu (modyfikacji) nieaktualnej sesji.

Jak mo na si by o spodziewa zwi kszanie liczby w z ów w klastrze

powodowa o  zwi kszanie  czasu  trwania  testu.  Nie  jest  to  wielkim  zaskoczeniem
zwa ywszy  na  charakterystyk   przeprowadzonego  testu.  Nie  powinno  równie   by
wielkim zaskoczeniem,  e czas trwania testu na pojedynczym serwerze by  najni szy.
Pojedynczy serwer odwo uje si  do danych bezpo rednio w pami ci operacyjnej i nie
musi ich przesy a  przez sie . Je eli dodatkowo

danie nie generuje prawie adnego

obci enia na serwerze, to obs uga nawet kilku tysi cy

da b dzie trwa a bardzo

krótko.

Drugi test zosta przeprowadzony w bardzo podobnych warunkach, z tym e

system wykorzystywa zintegrowany serwer ruchu. Ka dy z w tków testuj cych

czy si z serwerem ruchu, który na podstawie przesy anego identyfikatora sesji

wybiera w ze aktualnie zajmuj cy sesj . Ka dy z w z ów mia ustawiony czas
opó nienia wysy ania replik oraz opó nienia zwolnienia sesji na 2 sekundy.

0 s.

20 s.

40 s.

60 s.

80 s.

100 s.

120 s.

2 w z y

3 w z y

4 w z y

5 w z ów

6 w z ów

2 w z y

3 w z y

4 w z y

5 w z ów

6 w z ów

30 w. 50 .

60 w. 50 .

90 w. 50 .

30 w. 100 .

Rys. 5.2. Wykres wyniku testów przy zastosowaniu zintegrowanego serwera ruchu

Wykres na rys. 5.2 prezentuje wyniki testów mierzone w sekundach. Jak mo na

zauwa y   zastosowanie  zintegrowanego  serwera  ruchu  bardzo  mocno  polepszy o
wydajno   klastra.  Prawdopodobnie  zysk  by by  nawet  jeszcze  wi kszy  przy
odpowiednio  dobrym  zaimplementowaniu  serwera ruchu.  Z  testów  wynika o,  e  tak
naprawd  w skim gard em tego testu móg  okaza  si  w a nie serwer ruchu. Niemniej
jednak  mo na  zauwa y ,  e  przy  tej  architekturze  zwi kszanie  liczby  w z ów  w
klastrze  przesta o  negatywnie  wp ywa   na  wydajno   systemu.  W  zasadzie  ró nice
czasu po dodaniu kolejnych w z ów staj  si  nieznacz ce.

5.2 Test wydajno ci

Test wydajno ci zosta przeprowadzony na maszynach typu B. Ka dy w tek

testowy wykonywa pierwsze

danie do aplikacji XSL w celu ustawienia w sesji

cie ek do plików. W kolejnym

daniu odbiera rezultat wykonania przekszta cenia

na pliku XML. Nale y zwróci uwag na fakt, e w przeprowadzanym te cie równie
by y odwo ania do replikowanych sesji, a nie tylko generowanie oblicze .
Charakterystyka testu:

Serwer zarz dca znajdowa si w jednym z serwerów Tomcat.

Testy by y przeprowadzane bez u ycia zintegrowanego serwera ruchu.

Aplikacja testuj ca wybiera a kolejne w z y w sposób losowy.

0 s.

2 s.

4 s.

6 s.

8 s.

10 s.

12 s.

14 s.

16 s.

bez klastra

2 w z y

3 w z y

4 w z y

bez klastra

1,7

3,4

2 w z y

1,2

1,4

2,3

3 w z y

1,2

1,4

2,7

6,5

9,5

4 w z y

0,9

1,3

1,5

8,5

10 w.

20 w.

30 w.

90 w.

150 w.

210 w.

Rys. 5.3. Wyniki testów aplikacji XSL

Wykres na rys. 5.3 prezentuje wyniki testów. Jak mo na zaobserwowa zysk z

zastosowania  klastra  jest  niebagatelny  w  stosunku  do  pracy  pojedynczego  serwera.
Dodanie  kolejnych  w z ów  obni a  czas  trwania  testu,  co  jest  szczególnie  widoczne
przy obs udze bardzo wielu  da  jednocze nie. Zysk z zastosowania klastra najlepiej
wida  dla 150 oraz 210 w tków. Pojedynczy serwer Tomcat bez klastra w ogóle nie
przeszed   testu    serwer  przesta   odpowiada   i  trzeba  by o  go  zrestartowa .  Czyli
zainstalowanie  klastra  pozwoli o  na  obs ug   znacznie  wi kszej  liczby  klientów

jednocze nie, co tak naprawd jest najwa niejszym wyznacznikiem wydajno ci
systemu.

Prawdopodobnie zastosowanie dobrze zaimplementowanego serwera ruchu

pozwoli oby na uzyskanie jeszcze lepszych wyników, szczególnie przy wi kszej
liczbie w z ów.

5.3 Test HTTPS

Ostatni z testów mia na celu pokazanie skuteczno ci dzia ania klastra w

przypadku

stosowania

po cze

szyfrowanych.

Obliczenia

zwi zane

deszyfrowaniem po cze zosta y rozrzucone na wszystkie w z y w klastrze
(dok adniejszy opis konfiguracji znajduje si w p. 4.4.2). Do testów wykorzystano
maszyny typu B. Charakterystyka testu:

Serwer zarz dca znajdowa si wewn trz jednego z serwerów Tomcat.

Do testów wykorzystano aplikacj sesyjn .

0 s.

20 s.

40 s.

60 s.

80 s.

100 s.

120 s.

140 s.

bez klastra

3 w z y

4 w z y

bez klastra

117

3 w z y

100

4 w z y

15 w. 100 .

30 w. 100 .

50 w. 100 .

75 w. 100 .

90 w. 100 .

Rys. 5.4. Wyniki testów przy wykorzystaniu po cze szyfrowanych

Wykres na rys. 5.4 prezentuje wyniki przeprowadzonych testów. Co ciekawe

przy  wykorzystaniu  po cze   szyfrowanych  okazuje  si ,  e  zysk  z  zastosowania
klastra osi ga si  nawet dla skrajnie pesymistycznych przypadków z punktu widzenia
klastra (aplikacja sesyjna). Obliczenia zwi zane z szyfrowaniem i deszyfrowaniem s
tak kosztowne,  e z czenie wielu fizycznych maszyn rekompensuje straty zwi zane z
przesy aniem replik sesji w sieci. Jak wida  na wykresie pojedynczy serwer jest du o
wolniejszy  od  klastra,  a  szczególnie  wyra nie  wida   to  przy  du ym  obci eniu.
Podczas testu z 90 w tkami serwer przesta  odpowiada  i trzeba by o go zrestartowa .

Warto zwróci uwag na kszta towanie si ró nic czasów pomi dzy klastrem

z o onym z 3 w z ów a klastrem z o onym z 4 w z ów. Dla ma ej liczby
równoleg ych

da (15 w. 100 .) klaster z trzema w z ami okazuje si szybszy od

si w znacznym stopniu obci enie sieci i przede wszystkim wyeliminowa oby si
zale no liczby przesy anych replik od liczby w z ów w klastrze. Architektur
takiego rozwi zania przedstawia rys. 6.1.

Wbrew pozorom implementacja takiego uogólnienia by aby ca kiem prosta.

Ka dy  w ze   widzi  tylko  te  w z y,  które  wska e  mu  serwer  zarz dca.  Czyli
wystarczy,  e serwer zarz dca wska e mu tylko w z y nale ce do jego podgrupy, nie
informuj c  go  o  istnieniu  pozosta ych.  Dla  pojedynczego  w z a  klaster  b dzie  si
sk ada  tylko z w z ów z jego podgrupy. Implementacja rozszerzenia sprowadza aby
si  zatem do przeprogramowania serwera zarz dcy tak, aby logicznie rozbi  klaster na
mniejsze  podgrupy.  Dodatkowo  konieczne  by oby  zainstalowanie  klastra  ze
zintegrowanym  serwerem  ruchu,  aby

dania odwo uj ce si do sesji nie trafi y do

podgrupy,  która  nie  posiada  danych  sesji.  Oczywi cie  uniemo liwi oby  to
zastosowanie  konfiguracji  HTTPS,  gdzie  ka dy  w ze   niezale nie  szyfruje  i
deszyfruje dane serwer ruchu musi zna  odszyfrowane nag ówki zanim przekieruje

danie dalej (por. p. 4.4.2).

6.3 Zmniejszanie ilo ci przesy anych informacji

Istnieje jeszcze drugie, równoleg e podej cie maj ce na celu zmniejszenie liczby

przesy anych w sieci bajtów. Mo na by by o w przypadku bardzo du ych sesji
wysy a przyrosty danych. W momencie rozpocz cia przetwarzania

dania system

zapami tywa by zserializowane dane sesji. Nast pnie po przetworzeniu

dania

serializowa by sesj ponownie i sprawdza co tak naprawd si zmieni o od
poprzedniej wersji. Faktyczne zmiany na poziomie konkretnych bajtów rozsy ane by
by y do pozosta ych w z ów w sieci. Takie rozwi zanie ma dwie zasadnicze zalety:

1. Je eli sesja by a pobrana tylko do odczytu, to system nie wygeneruje adnych

pakietów replikacyjnych.

2. Je eli zasz y niewielkie zmiany w sesji, to pakiety replikacyjne mog okaza

si znacznie mniejsze ni w przypadku pe nej replikacji.

Niestety wad takiego podej cia jest atwo utraty danych. Wystarczy, e

informacje  o  jednej  ze  zmian  zanikn   w  którym   w le,  by  przy  odbiorze  kolejnej
zmiany  nie  by   on  w  stanie  odtworzy   aktualnej  wersji  sesji.  Poza  tym  rozwi zanie
wymaga  du ego,  dodatkowego  nak adu  pami ci    trzeba  przechowa   kopi   sesji  na
czas przetwarzania  dania.

6.4 Implementacja interfejsu u ytkownika do zarz dzania

klastrem

Poza rozwojem maj cym na celu usprawnienie klastra warto równie rozwa y

rozwój

zwi zany

wygod

jego

administracji.

Niestety

aktualnie

zaimplementowanej wersji w celu zainstalowania lub podmiany aplikacji dzia aj cej
w klastrze administrator musi wykona instalacj na ka dym w le osobno

. Przy

klastrach  sk adaj cych si   z  wielu  w z ów mo e  to by  bardzo uci liwe. Warto by
by o  zaimplementowa   mechanizm  automatycznej  instalacji  aplikacji  w  ca ym
klastrze. Mo na by by o to zrealizowa  na poziomie serwera zarz dcy. W momencie

Ewentualnie w aktualnej wersji mo na zainstalowa ka dy z serwerów na rozproszonym systemie

plików (np. NFS). W momencie zmiany aplikacji wszystkie w z y od razu widzia yby now wersj .
Niemniej jednak administrator musia by r cznie powiadomi ka dy z w z ów o konieczno ci
przeinstalowania aplikacji.

Dodatek A
Opis za czników

pracy

do czona

zosta a

p yta

kodami

ród owymi

zaimplementowanego modu u klastra. Poni ej znajduje si hierarchia katalogów wraz
z opisem zawarto ci.

Dokumentacja praca magisterska wraz z za cznikiem.
Kody zrodlowe kody zród owe modu u klastra.

Cluster kody modu u do czanego do serwera Tomcat. Tutaj znajduje
si równie plik Build.xml umo liwiaj cy zbudowanie modu u przy
pomocy narz dzia ANT.

conf plik konfiguracyjny Tomcata: server.xml.
dist zbudowany modu klastra.

LoadBalancer:

cluster kody ród owe serwera ruchu.
test kody ród owe aplikacji testuj cych.

Session kod ród owy serwletu u ywanego podczas testów.

WebXsl kod aplikacji XSL u ywanej podczas testów.

Modu klastra pisany by przy u yciu narz dzia Eclipse. Wraz z kodami

ród owymi na p ycie znajduj si pliki tworzone przez to narz dzie, co umo liwia

otwarcie projektów bezpo rednio w

rodowisku Eclipse bez potrzeby ich

importowania.

Instalacja modu u klastra

Aby zainstalowa modu klastra nale y:

1. zainstalowa serwer Tomcat w wersji 5.0,

2. przegra plik

/kod zrodlowy/Cluster/dist/catalina-cluster.jar

katalogu

[Tomcat]/server/lib

, gdzie

[Tomcat]

jest katalogiem domowym

zainstalowanego serwera,

3. przegra plik konfiguracyjny

/kod zrodlowy/Cluster/conf/server.xml

do katalogu

[Tomcat]/conf

Aby klaster móg dzia a nale y jeden z w z ów skonfigurowa w trybie serwera

zarz dcy, a w pozosta ych ustawi adres serwera zarz dcy (dok adniejszy opis
konfiguracji znajduje si w rozdz. 4.4).