Na ostatnim, trzecim spotkaniu Silesia JUG, po prezentacji Łukasza Lipki na temat Mule ESB kilka osób zainteresowanych było możliwością uruchomienia Mule ESB w klastrze. Okazało się, że polityka klastrowania musi zostać zaimplementowana ręcznie przez programistów. Ciekawe, bo bez tego ESB chcące być postrzegane jako technologia dla biznesu musi posiadać możliwość klastrowania. Nie zgłębiając dalej tematu Mule ESB, zaintrygowany tematem, postanowiłem napisać jak to jest w przypadku serwera aplikacji, na którym pracuję na co dzień, czyli JBoss Application Server.

Klastrowanie? A co to tak właściwie jest?

Klastrowanie pozwala na uruchomienie aplikacji na wielu, pracujących równolegle serwerach przy serwowaniu pojedynczego widoku dla klienta. Obciążenie rozłożone jest na wszystkie serwery w klastrze. W przypadku, gdy jeden lub więcej węzłów zostanie wyłączonych (ulegnie awarii) – aplikacja nadal jest dostępna za sprawą pozostałych, działających serwerów. Dzięki łączeniu serwerów w klastry można zwiększać wydajność aplikacji poprzez zwykłe dodawanie kolejnych węzłów do klastra. Oprócz zwiększonej mocy obliczeniowej klastrowanie oferuje redundancję, która jest bardzo często wymaganiem dla bezawaryjnego działania dużych aplikacji.

JBoss Application Server posiada wbudowane mechanizmy klastrowania. Najprostszą metodą uruchomienia klastra z serwerów JBoss jest uruchomienie każdego z nich w tej samej sieci lokalnej w konfiguracji all (za pomocą polecenia run -c all). Każdy z serwerów samoczynnie wykryje pozostałe węzły, które razem sformułują klaster.

Reasumując: klastrowanie ma dwa podstawowe zadania:

1. utrzymanie niezawodności systemu,
2. zwiększenie wydajności aplikacji.

Definicja klastra

Klaster to zbiór węzłów komunikujących się ze sobą, pracujących razem w celu osiągnięcia wspólnego celu.

W klastrze serwerów aplikacji JBoss AS, zwanym również partycją, pojedynczy węzeł to jedna instancja serwera JBoss AS. Komunikacja między węzłami odbywa się za pomocą grupy bibliotek JGroups. JGroups Channels pozwala na śledzenie, kto znajduje się w klastrze oraz na niezawodną komunikację pomiędzy członkami klastra. Instancje JGroups Channels posiadające te same konfiguracje i jednakowe nazwy mają zdolność do dynamicznego wykrywania siebie nawzajem i formowania w grupy. To dlatego uruchomienie dwóch serwerów w tej samej sieci lokalnej poprzez wywołanie polecenia run -c all wystarcza aby sformułować klaster. Każdy z serwerów uruchomi kanał (channel) z tą samą, domyślną konfiguracją. W ten sposób węzły mogą się rozpoznać w sieci tworząc razem klaster. Węzły mogą być dynamicznie dodawane i usuwane z klastra w każdym momencie. Wystarczy uruchomić lub zatrzymać kanał, który skonfigurowany jest w ten sam sposób jak inne węzły w klastrze.

Reasumując: klaster JBoss jest zbiorem instancji serwerów JBoss AS, przy czym każda instancja posiada uruchomiony JGroups Channel skonfigurowany dokładnie w taki sam sposób jak inne instancje.

Na jednej instancji serwera JBoss AS uruchomione usługi mogą uruchomić swoje własne kanały. Przy standardowej konfiguracji serwera JBoss AS 4.2 cztery usługi uruchamiają swoje kanały. Są to:

• usługa replikacji stanu sesji HTTP,
• usługa replikacji stanu SFSB,
• usługa cacheowania encji EJB 3.0,
• oraz standardowa usługa klastrowania zwana HAPartition.

Poszczególne kanały rozróżnia się za pomocą nazw – różne kanały muszą posiadać różne nazwy, przy czym konfiguracja węzłów w poszczególnych kanałach musi być taka sama dla wszystkich instancji

Przykładowe formowanie się węzłów w partycje

danej usługi w klastrze, jednak różna dla usług uruchomionych na pojedynczej instancji. W przypadku uruchomienia przykładowo dwóch instancji serwerów JBoss AS za pomocą polecenia run -c all może wydawać się, że mamy jeden klaster złożony z dwóch węzłów. Ściśle mówiąc jest to nieprawda, ponieważ każda usługa tworzy swój własny klaster, w związku z czym otrzymujemy cztery klastry każdy po dwa węzły. Dla jednej sieci, nawet dla tej samej usługi możemy mieć wiele klastrów. Diagram przedstawia przykładową sieć serwerów JBoss podzieloną na trzy partycje. Taką konfigurację można szybko uzyskać edytując poszczególne pliki konfiguracyjne w odpowiednich instancjach serwerów.

W następnej części zostaną omówione architektury klastrów możliwe do utworzenia przez serwer JBoss AS.