My Ordinary Thoughts

W pierwszej części napisałem czym jest klastrowanie i do czego służy. Pora skupić się na architekturach klastrowania dostępnych w serwerze JBoss AS.

Topografia klastra zdefiniowana w odpowiednim pliku konfiguracyjnym usługi HAPartition za pomocą XMLa dla każdej instancji, ma ogromne znaczenie dla administratorów serwerów JBoss. Programiści natomiast zwracają większą uwagę na konfigurację z punktu widzenia klienta usługi. W JBoss AS wykorzystywane są dwie architektury klastrowania:

1. interceptory po stronie klienta,
2. zewnętrzne loadbalancery.

Interceptory po stronie klienta

Większość zdalnych usług udostępniania przez serwer JBoss AS włączając w to JNDI , EJB, JMS , RMI czy JBoss Remoting wymaga od klienta, aby ten uzyskał (znalazł i pobrał) obiekt stub (proxy). Obiekt stub jest generowany przez serwer. Implementuje on interfejs biznesowy usługi. Po pobraniu obiektu stub przez klienta wywołuje on na nim lokalne zapytanie, następnie stub przekazuje zapytanie przez sieć do odpowiedniej usługi.

Architektura z interceptorem po stronie klienta

Zaślepka wygenerowana przez serwer zawiera w sobie interceptor, który wie jak rutować zapytania do wielu węzłów w klastrze. Następnie stub znajduje odpowiedni węzeł, serializuje parametry zapytania, odserializowuje wyniki zapytania i zwraca je do klienta. Interceptor posiada aktualną wiedzę na temat klastra. Zna on adresy IP każdego dostępnego węzła w klastrze, algorytm dystrybucji obciążenia pomiędzy węzłami oraz informację, w jaki sposób radzić sobie z sytuacją, gdy docelowy węzeł nie będzie dostępny.

W przypadku gdy topologia klastra zmienia się, węzeł uaktualnia dane w interceptorze przy najbliższym zapytaniu. Przykładowo, gdy jeden z węzłów zostanie odłączony od klastra – każdy interceptor zostanie o tym powiadomiony przy podłączeniu się do któregokolwiek aktywnego węzła. Wszystkie aktualizacje obiektu stub są niewidoczne dla klienta.

Polityki rozkładu obciążenia

Dla architektury opartej na interceptorach po stronie klienta serwer JBoss AS 4.2 oferuje następujące polityki:

• Round-Robin (org.jboss.ha.framework.interfaces.RoundRobin) – każde zapytanie jest przekazywane do kolejnego serwera znajdującego się na liście dostępnych węzłów, pierwszy cel jest wybierany przypadkowo.
• Random-Robin (org.jboss.ha.framework.interfaces.RandomRobin) – dla każdego zapytania docelowy węzeł wybierany jest przypadkowo.
• First Available (org.jboss.ha.framework.interfaces.FirstAvailable) – jeden z dostępnych węzłów zostaje zostaje wybrany jako domyślny (bez znaczenia który). Gdy lista dostępnych węzłów zmieni się stub wybierze następny dostępny węzeł, jednak dopiero wtedy gdy wybrany wcześniej węzeł już nie działa. Każdy stub wybiera cel niezależnie. Jeżeli klient pobierze dwa obiekty stub (np. EJB) – każdy z nich wybierze samodzielnie cel. Jest to polityka, która zapewnia tzw. session affinity (sticky sessions).
• First Available Identical All Proxies (org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies) – polega na tym samym co, First Available z tą różnicą, że wszystkie zapytania jednego klienta będą kierowane do tego samego docelowego węzła. Dla przykładu: jeżeli klient pobierze dwa obiekty stub jakiejś usługi, każdy z nich będzie odwoływał się do tego samego węzła w klastrze.

Wszystkie powyższe polityki są implementacją interfejsu org.jboss.ha.framework.interfaces.LoadBalancePolicy. Można stworzyć również własną implementację tego interfejsu.

Loadbalancer

Wiele usług udostępnianych przez serwer JBoss nie wymaga od klienta, aby ten pobierał obiekt proxy. W szczególności dotyczy to usług związanych z protokołem HTTP, gdzie klient (często przeglądarka internetowa) wysyła zapytania i otrzymuje odpowiedzi bezpośrednio za pomocą połączenia odpowiedniego dla wybranego protokołu (np. HTTP). W takim przypadku wymagany jest zewnętrzny loadbalancer, którego zadaniem jest przetworzenie otrzymanych zapytań, a następnie ich wysyłka do węzłów w klastrze. Loadbalancer jest logiczną częścią klastra, mimo to określa się go jako usługę zewnętrzną.

Architektura z loadbalancerem

Loadbalancer może zostać zaimplementowany jako rozwiązanie programowe bądź sprzętowe. Wielu producentów oferuje bardzo zaawansowane rozwiązania sprzętowe. W rozwiązaniach programowych na wyróżnienie zasługują moduły serwera Apache. Do wersji 2.2 serwera Apache rolę loadbalancera dla serwerów aplikacyjnych Javy pełnił moduł mod_jk. Obecnie funkcjonalność ta jest dostarczana przez moduł mod_proxy_balancer.

Loadbalancer posiada zaimplementowany mechanizm, który umożliwia mu poznanie topologii klastra oraz zapewnia logikę rozkładu obciążenia pomiędzy węzłami czy detekcji niedziałających węzłów. Problemem przy takiej architekturze może być to, że loadbalancer sam w sobie może być powodem braku dostępu do aplikacji, ponieważ gdy loadbalancer przestanie odpowiadać – żaden klient nie dostanie się do aplikacji, dlatego też loadbalancer powinien być stale monitorowany aby zapewnić wysoką dostępność całego klastra. Bardzo często stosuje się redundancję loadbalancerów aby wykluczyć pojedynczy punkt awarii.

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.