Praca Magisterska INFORMATYKA4

Prac przedk adam do oceny

Data:

Podpis autora pracy:

Praca jest gotowa do oceny przez recenzenta

Data:

Podpis kieruj cego prac :

Streszczenie

W ramach niniejszej pracy zaprojektowano i zaimplementowano nowy modu do
obs ugi klastra dla serwera WWW Jakarta-Tomcat. W cz ci pisemnej pracy
przedstawiono definicj klastra, podstawowe funkcje, które musi on spe nia w
kontek cie serwerów WWW oraz problemy, które trzeba rozwi za w czasie jego
implementacji. Na cz

praktyczn sk ada si realizacja przedstawionego projektu

oraz wykonanie testów wydajno ci stworzonego modu u, ukazuj cych jego wady i
zalety w praktycznych zastosowaniach.

S owa kluczowe

Klaster, Java, komunikacja sieciowa, aplikacja internetowa, serwer WWW, HTTP,
HTTPS

Klasyfikacja tematyczna

C. Computer Systems Organization
C.2 COMPUTER-COMMUNICATION NETWORKS
C.2.4 Distributed Systems

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

4.4.2

Mo liwe konfiguracje przy wykorzystaniu HTTPS ............................56

Testy wydajno ci .................................................................................................58

5.1

Test poprawno ci .........................................................................................59

5.2

Test wydajno ci ...........................................................................................61

5.3

Test HTTPS .................................................................................................62

Mo liwe rozszerzenia ..........................................................................................64

6.1

Algorytm elekcji ..........................................................................................64

6.2

Podzia klastra na podgrupy.........................................................................64

6.3

Zmniejszanie ilo ci przesy anych informacji...............................................65

6.4

Implementacja interfejsu u ytkownika do zarz dzania klastrem ................65

6.5

Rozbudowa serwera ruchu ...........................................................................66

Podsumowanie .....................................................................................................67

Dodatek A Opis za czników.......................................................................................68
Bibliografia ..................................................................................................................69

1 Wst p

W dzisiejszych czasach us ugi informatyczne zdominowa y zarówno wiat

biznesu, jak i prywatne ycie zwyk ych ludzi. Internet spopularyzowa systemy
komputerowe do tego stopnia, e zaczynaj one wypiera tradycyjne metody
przetwarzania informacji ze wszystkich dziedzin ycia. W wiecie WWW mo na
skorzysta ze s ownika, obejrze mapy, szybko i komfortowo wyszuka dowolne
interesuj ce nas dane.

Jak atwo si domy le wraz z popularno ci systemów informatycznych wzros a

liczba ich potencjalnych u ytkowników, co bezpo rednio wi e si z potrzeb
zwi kszenia mocy obliczeniowej. Firmy prze cigaj si w ofertach du ych,
wieloprocesorowych maszyn, które umo liwi yby obs ug tysi cy czy nawet
milionów u ytkowników na sekund . Niestety koszt takiej maszyny bardzo cz sto
przekracza bud et ma ych czy rednich firm, które maj dobre pomys y, ale brakuje
im odpowiednich funduszy, aby je zrealizowa . W takiej sytuacji idealnym
rozwi zaniem mo e okaza si po czenie wielu zwyk ych, niedrogich komputerów,
które wspólnie umo liwi obs ug du ej liczby klientów. Aby taka architektura mog a
rozwi za problem zwi kszonego zapotrzebowania na moc obliczeniow w sposób
niewidoczny

dla

ko cowego

u ytkownika,

niezb dne

jest

odpowiednie

oprogramowanie.

W swojej pracy przedstawi pomys stworzenia modu u wspieraj cego

rozproszone przetwarzanie danych (klaster) dla bardzo popularnego serwera WWW
Jakarta-Tomcat. W pierwszej cz ci zostanie przedstawiona koncepcja klastra (por.
rozdz. 2) oraz opisany sposób dzia ania Tomcata (por. rozdz. 3). W drugiej cz ci
pracy przedstawi zrealizowany przeze mnie modu klastra (por. rozdz. 4) wraz z
testami jego wydajno ci (por. rozdz. 5). Mo liwe rozszerzenia opisuj w rozdz. 6.

W pracy prezentuj pozytywne strony wykorzystania modelu replikowania

ka dy do ka dego. Wykazuj , e dobrze zaimplementowany modu mo e okaza
si bezpieczniejszy i wydajniejszy od modelu serwer macierzysty, serwer kopii.
Oczywi cie implementacja jest znacznie bardziej skomplikowana (pojawia si
problem synchronizowania dost pu do sesji) niemniej jednak zysk jaki mo na
osi gn stosuj c ten model w przypadku protoko u HTTPS rekompensuje trudy
implementacji modu u.

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 .

2.3.2.2 Sybase Enterprise Application Server

Projektanci klastra z firmy Sybase [9] oferuj dwa rozwi zania problemu

przechowywania stanu sesji. Jedno z nich korzysta z bazy danych, a drugie, podobnie
jak w serwerze Bea Weblogic, replikuje stan sesji pomi dzy dwoma wybranymi
w z ami.

W pierwszym rozwi zaniu autorzy stworzyli system scentralizowany, w którym

w rodku klastra znajduje si w ze z baz danych zapisuj cy stan wszystkich sesji. W
przypadku awarii jakiego w z a stan obs ugiwanych przez niego sesji zosta
wcze niej zapisany na fizycznym no niku i mo e by odzyskany przez inne maszyny.

Niestety baza danych jest w skim gard em tego rozwi zania. Zapisanie

informacji na fizycznym no niku jest bardzo kosztowne (trwa d u ej ni przes anie
danych przez sie ). Zapis trzeba wykonywa po obs udze ka dego

dania co mo e

doprowadzi do zatkania serwera kopii zapasowej i w rezultacie braku mechanizmu
odzyskiwania danych po awarii.

Dodatkowo dochodzi tu problem wydajno ci silnika bazy danych je eli

zostanie stworzony klaster sk adaj cy si z wielu maszyn i ka da z nich b dzie
zapisywa a stan swoich sesji w bazie, to mo e si okaza , e wydajno ca o ci zale y
nie od liczby w z ów w sieci, ale od mo liwo ci serwera z baz danych.

Niew tpliw zalet rozwi zania jest mo liwo odzyskania stanu sesji nawet po

awarii ca ego klastra (wszystkich w z ów, w cznie z baz danych). Informacje s
zapisane na fizycznym no niku, wi c zawsze mo na je odzyska .

Drugie rozwi zanie jest bardzo podobne do rozwi zania firmy Bea.

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

wi ksz odporno klastra na awarie oprogramowania. Niestety przedstawione
rozwi zanie wyklucza taki model.

Architektura rozwi zania powoduje generowanie du ego ruchu w sieci ka dy

w ze rozsy a repliki sesji do wszystkich pozosta ych. Przy du ym obci eniu sie
mo e okaza si w skim gard em ca ego klastra. Powoduje to spore ograniczenia na
liczb w z ów jednocze nie dzia aj cych w klastrze. Liczba przesy anych
komunikatów jest kwadratowo zale na od liczby pod czonych w z ów.

Reasumuj c mo na stwierdzi , e Hanik przygotowa bardzo stabilne podstawy

do implementacji modu u klastra dla serwera Jakarta-Tomcat. Wy oni si standard
jaki musz spe nia modu y, aby mog y poprawnie dzia a przy ka dej kolejnej
dystrybucji Tomcata oraz zosta naszkicowany schemat pod czenia modu u do
serwera. Wzorcowa implementacja dostarcza wiele wskazówek, które mog u atwi
prac twórcom kolejnych rozwi za . Niestety nie spe nia ona wymaga stawianych
przez komercyjne zastosowania i mo e s u y jedynie jako przyk ad.

Celem tej pracy jest stworzenie modu u, bazuj cego na koncepcji Hanika,

wykorzystuj cego zalety rozwi zania, ale przede wszystkim eliminuj cego jego wady
i zagro enia. G ówn zalet , która zosta a zidentyfikowana w bazowym rozwi zaniu,
jest mo liwo dynamicznego sterowania obci eniem poszczególnych jednostek
klastra. G ówn wad jest brak synchronizacji podczas odwo ywania si do sesji oraz
brak kontroli nad spójno ci klastra. Drugim bardzo wa nym celem jest
optymalizacja rozwi zania, aby jego wydajno nie sta a si powodem rezygnacji ze
stosowania klastra w serwerze Jakarta-Tomcat. W rozdziale 4 przedstawi now ,
autorsk implementacj klastra, a w rozdziale 5 opisz wyniki testów
wydajno ciowych zaproponowanego rozwi zania.

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.

4.2.1 Do czanie nowego w z a

Jest to standardowa sytuacja, która ma miejsce przy ka dym restarcie

któregokolwiek z w z ów klastra lub te podczas rozbudowy superkomputera.

Zg aszaj cy si w ze

Serwer zarz dca

ADDMEMBER

NEWMEMBER
[sesja, wersja]

ADDMEMBER

Rys. 4.1. Schemat zg aszania si nowego w z a w klastrze

Zg aszaj cy si w ze nawi zuje po czenie z serwerem zarz dc (por. rys. 4.1);

zak adamy, e w ze zna adres IP oraz port serwera zarz dcy (ustawione na sztywno
w pliku konfiguracyjnym lub pobrane z sieci poprzez protokó rozg oszeniowy).
Wysy a komunikat

NEWMEMBER

, wraz z identyfikatorami wszystkich posiadanych sesji

oraz numerami wersji. Serwer zarz dca, po odebraniu komunikatu wysy a komend

ADDMEMBER

do wszystkich pozosta ych w z ów, informuj c o konieczno ci

przy czenia nowego w z a (komunikat zawiera adres nowego w z a). Do
zg aszaj cego si w z a wysy a komunikat

ADDMEMBER

z adresami przy czonych do

tej pory w z ów. Czyli w pierwszej fazie serwer zarz dca uspójnia klaster,
wymuszaj c tworzenie nowych par po cze . Bez komunikatu

ADDMEMBER

od serwera

zarz dcy aden z w z ów nie mo e przyj nowych po cze .

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.

4.2.2 Awaria po czenia

Awaria po czenia mo e nast pi z winy karty sieciowej (przepalenie uk adu

scalonego), z powodu przerwania kabla lub b du w konfiguracji sieciowej systemu
operacyjnego.

Wstrzymanie sesji

Serwer zarz dca

Wstrzymanie sesji

Rys. 4.3. Schemat dzia ania klastra w przypadku awarii po czenia

Je eli mamy do czynienia z awari po czenia mi dzy dwoma zwyk ymi

w z mi klastra (tzn. nie dotyczy ona serwera zarz dcy), to nie spowoduje ona

adnych zmian w architekturze klastra (por. rys. 4.3). W z y b d trzyma y logiczne

po czenie w swoich strukturach danych, nie zaprzestaj c prób wysy ania
komunikatów replikacyjnych mi dzy sob . Jedyn ró nic b dzie to, e komunikatu
w rzeczywisto ci nie b dzie udawa o si wys a i w z y b d wstrzymywa y zaj te
przez siebie sesje (sesja jest zwalniana tylko w momencie poprawnego rozes ania
replik do wszystkich cz onków klastra). Przy wykorzystaniu zintegrowanego serwera
ruchu ko cowy u ytkownik nawet si nie zorientuje, e nast pi a jakakolwiek awaria
po cze . Je eli nie wykorzystamy zintegrowanego serwera ruchu, to

danie

odwo uj ce si do zaj tej sesji mo e trafi do innego w z a i jego wykonanie zostanie
opó nione o czas naprawy zerwanego po czenia.

Przy tej okazji atwo zauwa y konieczno trzymania blokady sesji do momentu

zako czenia procesu replikacji. Gdyby w ze wcze niej zwolni blokad , to kolejne

danie odwo uj ce si do sesji mog oby trafi do w z a, z którym zosta o zerwane

po czenie, a ten rozpocz by przetwarzanie na nieaktualnych danych.

Je eli mamy do czynienia z awari po czenia mi dzy serwerem zarz dc i

zwyk ym w z em, to zostanie ona potraktowana jako awaria w z a. Dok adniejszy
opis podejmowanych dzia a znajduje si w p. 4.2.3.

4.2.3 Awaria w z a

Opisywana sytuacja mo e zdarzy si w momencie awarii fizycznej maszyny, na

której pracuje serwer w z a lub w przypadku braku odpowiedzi ze strony programu
serwera (por. rys. 4.4).

Wstrzymanie sesji

REMOVEMEMBER

Serwer zarz dca

AWARIA

Rys. 4.4. Schemat dzia ania klastra w przypadku awarii w z a

W przypadku ca kowitej awarii jednego ze zwyk ych w z ów klastra zak ada si ,

e zostan zerwane wszystkie po czenia fizyczne (w szczególno ci po czenie z

serwerem zarz dc ). Na tej podstawie serwer zarz dca stwierdza fakt awarii.

Po zerwaniu po czenia zarz dca rozsy a komunikat

REMOVEMEMBER

, wraz z

adresem uszkodzonej maszyny, do wszystkich pozosta ych cz onków klastra. Ka dy
w ze po otrzymaniu tego komunikatu ma prawo wyrzuci komputer z puli
aktywnych cz onków i anulowa wszystkie zadania wys ania komunikatów do tego
komputera. Czyli de facto mo e zako czy wstrzymane procesy replikacji i tym
samym przesta zajmowa do tej pory pobrane sesje.

Zwolnienie
wstrzymanych
sesji

Wyszukanie
najwy szych wersji
sesji

CHECK_SESSION_VERSION

Serwer zarz dca

Rys. 4.5. Schemat dzia ania klastra po odrzucenia w z a

Dodatkowo serwer zarz dca próbuje odzyska najnowsze wersje wszystkich,

zajmowanych przez uszkodzon maszyn sesji (por. rys. 4.5). Dla ka dego
identyfikatora z zaj tych sesji rozsy a komunikat

CHECK_SESSION_VERSION

wszystkich cz onków z pro b o przes anie trzymanego przez w ze numeru wersji.

Po zebraniu tych informacji, je eli oka e si , e który z w z ów posiada wy szy
numer ni ten przechowywany u zarz dcy, serwer synchronizacyjny wysy a
komunikat

FORCESYNC

do posiadacza najwy szego numeru, tym samym odzyskuj c

zmienione dane.

Wykorzystuj c ten mechanizm zwi kszamy szanse odzyskania danych

utraconych przy awarii w z a. Mo e zdarzy si , e maszyna zd y a wys a
komunikat replikacyjny do chocia jednego z w z ów, umo liwiaj c odzyskanie
zmienionego stanu sesji. Taka sytuacja mo e pojawi si przy wykorzystaniu
zintegrowanego serwera ruchu oraz zwi kszeniu czasu buforowania wysy anych
replik. Wtedy ka dy w ze zaraz po zako czeniu przetwarzania

dania wysy a

replik sesji do jednej, losowo wybranej maszyny, a do pozosta ych wysy a z pewnym
opó nieniem. Je eli opó nienie b dzie odpowiednio d ugie mo e okaza si , e do
wszystkich w z ów roze le replik dopiero po przetworzeniu kilku da , tym samym
ograniczaj c liczb przesy anych pakietów w sieci. St d bierze si potrzeba
odzyskiwania stanu nie zwolnionych sesji. Szerzej ten temat jest opisany w p. 4.3.4.

4.2.4 Awaria serwera zarz dcy

Opisywana sytuacja mo e zdarzy si w momencie awarii fizycznej maszyny, na

której dzia a serwer zarz dca lub w przypadku braku odpowiedzi ze strony programu
serwera rys. 4.6.

przypadku awarii serwera zarz dcy ka dy z w z ów likwiduje wszelkie

Serwer zarz dca

AWARIA

Rys. 4.6. Awaria serwera zarz dcy

czenia z pozosta ymi w z ami, uznaj c e klaster przesta funkcjonowa . Dalsze

zachowanie ka dego z w z ów jest identyczne z sytuacj przy czania nowego
cz onka do klastra. Ka dy z serwerów próbuje po czy si z zarz dc . Udaje im si
to dopiero po restarcie maszyny zarz dcy (lub ewentualnie wpi ciu identycznie
skonfigurowanej maszyny zapasowej).

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

zajmowania sesji. Oczywi cie nie mo na przesadzi z d ugo ci opó nienia, aby nie
doprowadzi do sytuacji opisanej w poprzednim punkcie, gdy klaster zaczyna si
zachowywa tak, jakby istnia y sta e przypisania sesja w ze macierzysty.

Warto zwróci uwag na fakt, e blokada jest przyznawana ca emu w z owi i

wszystkie w tki wewn trz serwera mog korzysta z danych sesji bez potrzeby
ponownego wysy ania pro by o jej przyznanie. W danym momencie tylko jeden
w tek wysy a komunikat z pro b o zablokowanie sesji. Wszystkie kolejne w tki,
odwo uj ce si do sesji b d czeka y na zako czenie wcze niej rozpocz tej
procedury. Podobnie wygl da proces zwalniania dopiero ostatni zwalniaj cy w tek
wy le faktycznie komunikat do serwera zarz dcy. Wszystkie wcze niejsze po prostu
zmniejsz licznik odwo a .

Znaj c podstawowe mechanizmy dzia aj ce w module mo na przeanalizowa

algorytm przetwarzania

dania. cie ka wykonania algorytmu rozpoczyna si w

momencie zg oszenia przez u ytkownika dania, a ko czy w momencie wys ania do
serwera zarz dcy wiadomo ci zwalniaj cej sesj .

4.3.5 Algorytm przetwarzania

dania

Opisywana cie ka przetwarzania

dania rozpoczyna si ju w konkretnym

w le, czyli serwerze Tomcat. Sposób dzia ania systemu na poziomie zarz dcy ruchu
zostanie opisany w p. 4.3.7. Koniec opisywanego procesu wyznaczany jest przez
wys anie danych z serwera Tomcat oraz przez zwolnienie blokady sesji u ytkownika.

Na rys. 4.11 znajduje si diagram przep ywów ukazuj cy najbardziej

charakterystyczny przypadek obs ugi

dania. Diagram przedstawia zg oszenie

klienta z numerem sesji, któr nale y zablokowa w serwerze zarz dzaj cym.

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

siebie w z a (oczywi cie wtedy wszystkie w z y b d musia y posiada identyczny
certyfikat).

Oba rozwi zania maj swoje wady i zalety. W pierwszym moc obliczeniowa

zwi zana z szyfrowaniem i deszyfrowaniem jest skupiona na pojedynczej maszynie,
co mo e si okaza w skim gard em systemu. Natomiast umo liwia ono
wykorzystanie zintegrowanego serwera ruchu, który b dzie mia dost p do nag ówka

dania. Z kolei w drugim moc obliczeniowa zwi zana z szyfrowaniem jest

rozk adana na wszystkie w z y w klastrze, ale serwer ruchu nie mo e podejrze
nag ówków zaszyfrowanych

da i tym samym nie mo e stwierdzi , który w ze

aktualnie zajmuje dan sesj .

Ogólnie je eli klaster w wi kszej cz ci ma obs ugiwa po czenia szyfrowane to

lepiej jest zastosowa drug koncepcj , co umo liwi rozdzielenie pracy zwi zanej z
szyfrowaniem na ca y klaster. Poniewa i tak sesja jest replikowana na wszystkie
maszyny, wi c nie ma problemu z wyborem serwera bez znajomo ci nag ówków.

Natomiast je eli klaster w wi kszym stopniu ma serwowa tre ci nie

wymagaj ce szyfrowania, to lepiej jest zastosowa koncepcj z pojedyncz maszyn
deszyfruj c . Umo liwi to wykorzystanie metod buforowania, które usprawni
dzia anie systemu.

Doskona ym dowodem na s uszno postawionej tezy s wyniki testów

przedstawione w punkcie 5. W rozwi zaniach opartych na po czeniach
szyfrowanych zastosowanie klastra mo e w sposób niebagatelny zwi kszy
wydajno systemu, zast puj c tym samym bardzo drogi serwer, dysponuj cy
równowa n moc obliczeniow .

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

tego z 4. Przy ma ym obci eniu systemu w skim gard em staje si strata zwi zana z
przesy aniem replik w sieci. Natomiast wraz ze wzrostem liczby równoleg ych

zysk z doinstalowania kolejnego w z a staje si coraz bardziej widoczny. Jest to
bardzo wa na obserwacja z punktu widzenia administratora systemu. Zwi kszenie
liczby w z ów w klastrze musi i w parze ze zwi kszeniem liczby u ytkowników
systemu; w przeciwnym przypadku dodanie w z a spowoduje spadek wydajno ci
systemu.

Test zosta przeprowadzony dla aplikacji sesyjnej, aby uwidoczni zysk jaki

mo na osi gn przy instalacji klastra do obs ugi po cze szyfrowanych. Je eli test
zostanie przeprowadzony dla bardziej wymagaj cej aplikacji, to mo na oczekiwa , e
wyniki b d jeszcze korzystniejsze.

6 Mo liwe rozszerzenia

W trakcie pisania klastra pojawi o si sporo ró nego rodzaju mo liwych

rozszerze , które nie zosta y zaimplementowane z powodu braku czasu. W tym
rozdziale zamieszczono krótki opis ciekawszych pomys ów na dalszy rozwój
projektu.

6.1 Algorytm elekcji

W aktualnej wersji serwer zarz dca jest ustalany na poziomie pliku

konfiguracyjnego i jest na sta e zaszyty w dzia aj cym serwerze Tomcat. Ciekawym
rozszerzeniem by oby zaimplementowanie dynamicznego algorytmu elekcji, który
wybiera by serwer zarz dc spo ród dost pnych w klastrze w z ów. W przypadku
awarii aktualnego serwera zarz dcy dzia aj ce komputery automatycznie ustala yby
kolejny komputer czuwaj cy nad synchronizacj w klastrze. Taki mechanizm
wyeliminowa by potencjalny s aby punkt klastra czyli awari centralnego serwera.
W aktualnej wersji jedynym sposobem zabezpieczenia si przed awari serwera
zarz dcy jest sprz towa podmiana maszyny fizycznej na identycznie skonfigurowan
w przypadku wyst pienia awarii. Takie rozwi zanie niestety mo e by dosy
kosztowne.

6.2 Podzia klastra na podgrupy

Spor wad aktualnego rozwi zania jest liniowa zale no ilo ci przesy anych w

sieci danych od liczby w z ów w klastrze (repliki sesji wysy ane s do ka dego
w z a). Klaster o bardzo du ej liczbie w z ów mo e okaza si nieu yteczny w
praktycznych zastosowaniach. Szczególnie je eli sesje b d zawiera y bardzo wiele
danych.

Serwer zarz dca

Podgrupa 3

Podgrupa 2

Podgrupa 1

Rys. 6.1. Architektura klastra z podgrupami

Istnieje mo liwo zapobiegni cia sytuacji prze adowania sieci poprzez logiczne

rozbicie klastra na kilka roz cznych podgrup. Ka da podgrupa mog aby posiada
obs ugiwany przez ni podzbiór sesji repliki by yby rozsy ane tylko w obr bie
podgrupy. Je eli podgrupy by yby niedu ej wielko ci (np. 3, 4 w z y) ograniczy oby

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.

do czania w z a do klastra serwer zarz dca móg by wysy a list aplikacji (wraz z
ich cie kami) do nowej maszyny w celu ich zainstalowania. W ze b d c w klastrze
nie instalowa by aplikacji z lokalnego systemu plików (jak to si dzieje w
standardowym serwerze), tylko pobiera by list aplikacji podczas pierwszego
zg oszenia do zarz dcy. W przypadku instalacji nowej aplikacji administrator
wysy a by

odpowiednie

polecenia

serwera

zarz dcy,

który

dalej

rozpropagowywa by t informacj do wszystkich w z ów.

Poza tym wskazane by oby zaimplementowanie wygodnego interfejsu

u ytkownika (na wzór interfejsu do administracji pojedynczym serwerem Tomcat), w
którym administrator móg by instalowa , wstrzymywa czy deinstalowa aplikacje.
Dodatkowo mia by mo liwo zmiany parametrów wszystkich w z ów w klastrze za
jednym razem.

6.5 Rozbudowa serwera ruchu

Poza rozbudow modu u klastra mo liwa jest równie rozbudowa serwera ruchu,

który na t chwil nale y raczej traktowa jako implementacj wzorcow . W pe ni
funkcjonalna implementacja serwera ruchu zosta a wcze niej opisana w p. 4.3.7.
Nale a oby doda do serwera interpreter nag ówków HTTP, który pozwoli by na
bardzo d ugie przetrzymywanie otwartych po cze z serwerami Tomcat, a przede
wszystkim pozwoli by na dynamiczne prze czanie kontekstu wykonania nawet w
przypadku po cze typu

Keep-Alive

. Mog oby to spowodowa znaczne polepszenie

wydajno ci szczególnie przy nawi zywaniu po cze .

Innym

bardzo

praktycznym

rozszerzeniem

mog oby

okaza

zaimplementowanie obs ugi protoko u HTTPS na poziomie serwera ruchu. Serwer
samodzielnie zajmowa by si szyfrowaniem i deszyfrowaniem po cze co
wyeliminowa oby

potrzeb

instalacji

dodatkowych komponentów

(serwera

po rednicz cego) w przypadku korzystania z protoko u szyfrowanego.

7 Podsumowanie

Cel, który postawiono w ramach pracy zosta osi gni ty. Stworzone

oprogramowanie dzia a bardzo dobrze nawet w skrajnie trudnych warunkach. Klaster
zachowuje si stabilnie, potrafi c odpowiednio reagowa na awarie w z ów. Z testów
wydajno ci wynika, e w praktycznych zastosowaniach narzut zwi zany z replikacj
zostaje ca kowicie zrekompensowany zyskiem mocy obliczeniowej z czonych
maszyn. W tym momencie najs abszym ogniwem zaproponowanego rozwi zania jest
zintegrowany serwer ruchu. Aby w pe ni wykorzysta mo liwo ci modu u, powinno
si usprawni dzia anie tego serwera.

Z obserwacji wyników testów nasuwa si wniosek, e najmocniejsz stron

nowego klastra jest mo liwo rozproszonego przetwarzania po cze szyfrowanych.
Replikacja ka dy do ka dego umo liwia przekierowywanie

da do w z ów klastra

bez znajomo ci nag ówków (dok adniej identyfikatora sesji). Takiego rozwi zania nie
ma w swojej ofercie aden komercyjny serwer na rynku. Je eli administrator
zdecyduje si na zastosowanie po cze szyfrowanych, to przy du ej liczbie
u ytkowników musi albo kupi bardzo wydajny, wieloprocesorowy serwer, albo
specjalny sprz t deszyfruj cy. Oba rozwi zania s niestety bardzo kosztowne. Nowy
klaster Tomcata pozwala na wykorzystanie mocy obliczeniowej wielu zwyk ych
komputerów do kosztownych operacji szyfrowania, jednocze nie gwarantuj c
niezawodno replikacji i poprawne dzia anie w przypadku równoleg ych odwo a do
tej samej sesji. Stworzenie klastra z o onego z kilku czy kilkunastu niedrogich
komputerów stacjonarnych b dzie rozwi zaniem wielokrotnie ta szym, a przy okazji
du o bardziej skalowalnym. Przy ma ym obci eniu systemu mo na od czy cz

w z ów; je eli obci enie wzro nie mo na dokupi kolejn maszyn i odpowiednio
skonfigurowan wpi do sieci, aby odci y a pozosta e w z y. Je eli oka e si , e
w skim gard em systemu staje si serwer zarz dca, to mo na go odseparowa od
serwera Tomcat i uruchomi na oddzielnej maszynie jako samodzielny program.
Pewnym mankamentem klastra mo e by brak wygodnego narz dzia pozwalaj cego
na administrowanie nim. Niemniej jednak, je eli skorzysta si z sieciowego systemu
plików (NFS), to dodatkowy nak ad pracy zwi zany z utrzymaniem klastra nie musi
by a tak dotkliwy.

S dz ,

e nowy klaster mo e by znakomit alternatyw dla du ych

komercyjnych serwerów. Idealnie pasuje do koncepcji darmowego oprogramowania
promuj cego tanie, ale funkcjonalne rozwi zania, które dowodz , e w informatyce
nie trzeba posiada du ych funduszy, aby zrealizowa wielkie zamiary.

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

Bibliografia

[1]

Abraham Kang. J2EE Clustering, Part 1.

http://www.javaworld.com

[2]

G. F. Pfister. In Search of Clusters. Prentice Hall, Upper Saddle River, 1998.

[3]

Specyfikacja i opis standardu J2EE,

http://java.sun.com/j2ee

[4]

Specyfikacja Java Mail API,

http://java.sun.com/products/javamail

[5]

Strona domowa aplikacji Hyperion Analyzer,

http://www.hyperion.com

[6]

Strona domowa biblioteki do komunikacji wspó bie nej Java Groups,

http://www.jgroups.org

[7]

Strona domowa darmowego serwera J2EE, Jonas,

http://jonas.objectweb.org

[8]

Strona domowa serwera Apache Tomcat,

http://jakarta.apache.org/tomcat

[9]

Strona domowa serwera J2EE firmy Sybase,

http://www.sybase.com

[10]

Strona domowa serwera J2EE firmy Weblogic,

http://www.weblogic.com

[11]

Strona opisuj ca klaster zaimplementowany w Tomcat, wersji 5.0,

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html

Wyszukiwarka

Podobne podstrony:
Grafika Rastrowa - Corel Photopaint - Praca Magisterska, Informatyka
praca magisterska informatyka 4 KHJLNZKHRFDDG6PHDIY4PQXD5CIEA5RFTGWV5GI
praca magisterska Zarządzanie informacją i komunikacją w przedsiębiorstwie turystycznym
Praca Magisterska - program, info 2[1], Informacja nr 2
praca magisterska Skuteczne zarządzanie ryzykiem w projektach informatycznych, prace - moje
Praca Magisterska(1)1 Portale Internetowe, Informatyka
[eBooks PL]Praca Magisterska Projekt serwisu informacyjnego WWW
Praca Dyplomowa Informatyka Internet-Rola I Znaczenie Internetu, PRACA MAGISTERSKA INŻYNIERSKA DYPLO
Samorząd powiatowy na przykładzie powiatu ostrowieckiego. Praca dyplomowa, Informacja naukowa i bibl
praca magisterska technologia informacyjna zadania w excel u
praca magisterska Akty kończące ogólne postępowanie administracyjne
praca-magisterska-a11406, Dokumenty(2)
praca-magisterska-a11222, Dokumenty(2)
praca-magisterska-6811, Dokumenty(8)
praca-magisterska-a11186, Dokumenty(2)
praca-magisterska-7383, Dokumenty(2)

więcej podobnych podstron