Konfiguracja

Konfiguracja nie jest szczególnie skomplikowana, do uruchomienia potrzebny będzie sam JavaRebel oraz serwer aplikacji. Osobiście przetestowałem serwery aplikacjyjne JBoss 4.2.3.GA oraz Tomcat 5.5.26 deployując na nich aplikację Spring’ową.

W obu przypadkach dodajemy linię:
set JAVA_OPTS=-noverify -javaagent:javarebel.jar -Drebel.dirs= -%JAVA_OPTS%
uzupełniając “-Drebel.dirs=” o katalogi do których nasze IDE kompiluje klasy, oddzielając je przecinkami. W przypadku JBoss’a plikiem do którego dodajemy linię jest run.bat, natomiast dla Tomcat’s będzie to catalina.cmd.

Plik javarebel.jar umieszczamy w tym samym miejscu, w którym znajdował się edytowany przez nas wcześniej, czyli katalogu bin serwera.

Działanie

Teraz możemy już uruchomić serwer. Naszą aplikację deployujemy na serwerze normalnie, wrzucając w odpowiednie miejsce plik war. Aplikacja zostanie uruchomiona, a JavaRebel rozpocznie monitorowanie folderu podanego wcześniej, sprawdzając czy któraś z naszych klas nie została zmieniona. Monitorowanie zmian odbywa się na podstawie znaczników czasu w klasach. Przeładowanie klasy zachowuje wszystkie istniejące instancje.

JavaRebel pozwala nam na wykonanie szeregu operacji na naszych klasach. Możemy zarówno dodawać jak i usuwać metody, konstruktory, pola, klasy czy adnotacje. Oczywiście pozwala nam zmieniać ciała samych metod. Niestety, ograniczeniem jest brak możliwości zamiany klasy bazowej oraz dodawanie/usuwanie interfejsów. Wydaje mi się jednak, że nie są to tak częste operacje, aby mogły stanowić problem.

Spring

W ostatnim czasie pojawił się plugin do JavaRebel wspierający jego działanie ze Springiem. Wspiera on rejestrowanie nowych bean’ów, kontrolerów, zarządzanie zależnościami. Wszystkie powyższe operacje mogą być wykonywane zarówno przy użyciu konfiguracji w XML’u jak i adnotacji. Co prawda narzędzie jest udostępnione jako open source, jednak wciąż należy je traktować jako wersję beta.

Licencja

Jest chyba największą wadą tego narzędzia, nie jest ono tanie. Licencja ciągła przy zakupie poniżej dziesięciu kosztuje 249$, a licencja roczna to koszt 99$. Cena licencji spada wraz z ich ilością.

Autorzy podają, że narzędzie to jest aktualnie używane przez wszystkich developerów serwisu LinkedIn. Ponadto posiadacze brązowego pasa na www.javablackbelt.com mogą otrzymać licencję za darmo.

Wrażenia

Osobiście ten sposób wprowadzania zmian w aplikacji bardzo przypadł mi do gustu. Nie zauważyłem opóźnień związanych z przeładowywaniem klas. Zależności były zawsze na miejscu dzięki możliwości zachowania istniejących instancji bean’ów. Uważam, że jest to narzędzie warte rozważenia, szczególnie w przypadku aplikacji, których deployment zajmuje pokaźną ilość czasu. Jednak z tego co zdążyłem wyczytać na forum projektu, pojawiają się problemy z obsługą EJB i generalnie nie istnieje wsparcie dla jakichkolwiek frameworków (poza Springiem). Jednak istnieje możliwość darmowego przetestowania, czy narzędzie spełnia nasze oczekiwania.

Moim zdaniem jest to bardzo przydatne oprogramowanie przy przygotowaniu aplikacji springowych, jednak jego cena jest nieco wygórowana, biorąc pod uwagę kłopoty z EJB i brak wsparcia dla innych frameworków.

Tomcat

W trakcie normalnego działania klastra sesje są replikowane między wszystkimi komputerami przy użyciu jednej z następujących metod:

1. Replikacja poprzez współdzielony sieciowy system plików (PersistanceManager + FileStore)
2. Replikacja do bazy danych (PersistanceManager + JDBCStore)
3. Replikacja w pamięci (SimpleTcpCluster)

Jeżeli jeden z Tomcatów ulegnie awarii jest usuwany z klastra a powiązane z nim zapytania są automatycznie przekierowywane przez loadbalancera. Sesje powiązane z uszkodzonym serwerem mogą zostac w zależności od konfiguracji wygaszone lub nie.

Przynależność do klastra jest określana przy pomocy pakietów UDP wysyłanych przez wszystkie Tomcaty, ze skonfigurowanym tym samym adresem multicastowym oraz portem. Replikacja sesji odbywa się przy użyciu pakietów TCP.

Zawór replikacji (ReplicationValve) służy do określenia kiedy zapytanie zostało zakończone i klaster może rozpocząć replikację.

Element w pliku server.xml konfiguruje domyślnie klaster z następującymi parametrami:

• Membership z adresem multicastowym 228.0.0.4 i portem udp 8012
• Potwierdzenie wysyłane co sekundę, usunięcie z listy po 30 sekundach bez odpowiedzi od danego Tomcata
• Odbiorca wiadomości SocketReplicationListener na domyślnym adresie IP oraz pierwszym wolnym portem z zakresu 8015 – 8019
• Replikacja oparta o ReplicationTransmitter w trybie fastasyncqueue
• Dodane ClusterSessionListener oraz ReplicationValve.

Wystarczy to do podstawowego skonfigurowania klastra, np. na maszynie developerskiej, jednakże w środowisku produkcyjnym zaleca się modyfikację ilości wątków obsługujących replikację i tryb replikacji.

Tipsy:

• Dokumentacja dotycząca klastrowania znajduje się tutaj: Tomcat 5.5, Tomcat 6.0
• Obiekty które są zapisywane w sesji muszą implementować java.io.Serializable (np. dto w kreatorach springowych)
• Na serwerach należy włączyć obsługę multicastu (np. pod Linuxem: ifconfig eth0 multicast)
• W web.xml powinien znajdować się element <distributable />, który powoduje, że dana aplikacja jest zdolna do działania w środowisku rozproszonym, czyli np. w klastrze.
• Najważniejszym elementem jeżeli chodzi o wydajność replikacji jest parametr replicationMode, konfigurowalny w elemencie <Sender …/>

Apache i mod_jk

Mod_jk to moduł do apache’a obsługujący komunikację z Tomcatem. Worker to instancja Tomcata na której uruchomione są servlety i do której przekierowywane są zapytania. Mod_jk jest konfigurowany, tak jak inne moduły, w pliku apache.conf lub httpd.conf. W niektórych dystrybucjach (np. debian) pliki konfiguracyjne modułów znajdują się w podkatalogu mods-enabled i są includowane w głownym pliku konfiguracyjnym.

Konfiguracja mod_jk

Moduł ładowany jest przy pomocy dyrektywy:

LoadModule jk_module ${sciezkaDoKataloguZModulami}/mod_jk.so

Następnie musimy dodać plik z workerami:

JkWorkersFile /etc/apache/workers.properties

Oczywiście plik workers.properties znajdować się może w dowolnym miejscu widocznym przez Apache’a.

Dodatkowo, należy też skonfigurować punkt montowania, czyli scieżkę od której przetwarzaniem zapytań zajmować będzie się Tomcat.

JkMount /* tomcat1

Ta dyrektywa sprawia, że wszystkie zapytania które odbierze Apache będą przekserowane do Wolkera o nazwie tomcat1. JkMount może się powtarzać i umieścić ją można zarówno w globalnej konfiguracji, VirtualHost jak i w Location (tylko nazwa workera, ścieżka będzie z Location) .
Zamiast montowania każdego punktu z osobna można użyć pliku uriworkermap.properties przy pomocy dyrektywy JkMountFile wskazującej na plik z mapowaniem.

Konfiguracja workera

Workery znajdują się przeważnie w pliku workers.properties. W pliku powinna znaleźć się dyrektywa worker.list oraz definicja co najmniej jednego workera. Worker.list to lista oddzielonych przecinkami workerów, które będą udostępnione mod_jk. Workera definiuję się w następujący sposób:

worker.nazwaWorkera.type=
worker.nazwaWorkera.host=
worker.nazwaWorkera.port=

Typ to najczęściej ajp13, który zastąpił starszy ajp12 i udostępnił między innymi kompresje danych i obsługę SSL’a.

Konfiguracja loadbalancera

Loadbalancer to specyficzny typ workera który nie komunikuje się z Tomcatem, tylko zajmuję się zarządzaniem pozostałymi „prawdziwymi” workerami, czyli min. rozdziela zadania na poszczególne instancje Tomcata używając algorytmu Round Robin z wagami. Sprawdza też które Tomcaty z listy nie odpowiadają i nie wysyła do nich zapytań.

Konfiguracja definiuję się w nastepujący sposób:

worker.nazwaWorkeraLB.balance_workers=

Dodatkowo można skonfigurować sticky session, czyli czy loadbalancer powinien przekierowywać zapytania z istniejącym sessionId do obsługującego je wcześniej Tomcata. Domyślnie ta funkcjonalność jest włączona.

Workerom można przyporządkować rózne wagi (worker.nazwaWorkera.lbfactor) a w loadbalancerze zmienić metodę wyboru workera do którego przekazane zostaną zapytania (worker.nazwaWorkeraLB.method). Do wyboru są następujące metody:
•R[equest] – kryterium jest obłożenie zapytaniami. Domyślne ustawienie.
•S[ession] – kryterium jest obłożenie sesjami. Zalecane w przypadku ograniczonych zasobów do obsługi sesji.
•B[usyness] – kryterium jest aktualne obciążenie serwera. Zalecane w przypadku długich sesji, np. w aplikacjach udostępniających pliki.
•T[raffic] – kryterium jest ilość ruchu na łączu między Apachem a Tomcatem. Zalecane w przypadku ograniczonej łączności między klasterm a Apachem.

Linki:

• Pozostałe dyrektywy
• Konfiguracja pliku mapowań
• Dokumentacja workerów

Przykłady

Apache -> mod_jk -> 1 tomcat

Najprostszy przykład. Zapytania są przekierowywane do jednego tomcata.

Konfiguracja Apache 1:

workers.properties:

worker.list=tomcat1

worker.tomcat1.type=ajp13
worker.tomcat1.host=10.1.1.2
worker.tomcat1.port=8009

Konfiguracja Tomcat1:

server.xml, sekcja Service:

<Connector port="8009"  protocol="AJP/1.3" />

Apache -> mod_jk -> 2 tomcaty w klastrze

Najbardziej użyteczna według mnie konfiguracja, bez użycia balansowania DNS’owego lub sprzętowego. Balansowaniem zajmuje się mod_jk.

Konfiguracja Apache 1:

workers.properties:

worker.list=cluster

worker.tomcat1.type=ajp13
worker.tomcat1.host=10.1.1.2
worker.tomcat1.port=8009

worker.tomcat2.type=ajp13
worker.tomcat2.host=10.1.1.3
worker.tomcat2.port=8009

worker.cluster.type=lb
worker.cluster.balance_workers=tomcat1, tomcat2

Konfiguracja Tomcat’ów:

server.xml, sekcja Service:

<Connector port="8009"  protocol="AJP/1.3" />

server.xml, sekcja Host:

<Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"/>

Dodatkowo, do należy dopisać jvmRoute=”${nazwaHosta}”, gdzie ${nazwaHosta} to odpowiednio tomcat1 i tomcat2

Apache -> mod_jk -> 1 tomcat jako loadbalancer -> 2 tomcaty w klastrze

Metoda ta używa aplikacji “balancer” uruchomionej na Tomcat’ie, który nie jest w klastrze. Zaletą tego rozwiązania jest możliwość dowolnego skonfigurowania balancingu. Wadą jest konieczność napisania klasy zajmującej się wyborem najlepszego Tomcata. Rozwiązanie to używa pliku workers.properties z przykładu pierwszego, konfiguracji klastra z przykładu drugiego oraz dodatkowego Tomcata, na którym działa aplikacja balancer. workers.properties przekierowuje zapytania na Tomcata pełniącego rolę LoadBalancera.