• konsola webowa,
• nowa implementacja Web Beans,
• usługa farmy.

JBoss AS otrzymał konsolę graficzną do zarządzania serwerem — Embedded JOPR. Nie posiada ona ogromnych możliwości, jednak do podstawowego zarządzania jest przydatna. Należy wspomnieć, że jest to okrojona wersja narzędzia JOPR służącego do zarządzania i monitorowania m.in. serwerów JBoss AS (ale nie tylko!).

Wróciła również usługa farmy która pozwala na bezproblemowe uruchamianie swoich serwerze w klastrze serwerów JBoss (skopiuj aplikację do jednego węzła, aplikacja zostanie rozpropagowana po klastrze automatycznie).

Więcej na temat tego wydania można poczytać w informacjach o wydaniu (obszerne!). Cóż, pozostaje mi tylko zachęcić do testów!

Dowiedz się również więcej na temat JBoss Rails (tak tak, aplikacje napisane w Rails działają na JBoss AS) i JBoss Cloud z wywiadu na DZone!

Cóż więcej mogę dodać — trzymajcie kciuki za nas!

While surfing the web and searching for informations about JBoss’ mod_cluster I have found a post at Bob McWhirter’s blog (check out his theses :)). I have figured out, that Bob has recently started a project called JBoss Cloud. Word cloud (same as green and social…) is very vogue last moths, so I’ve started digging this topic, especially therefore I’m a fan of JBoss.

What is it? In a few words it’s a set of scripts for creating JBoss AS appliances. You can run them, for example on Amazon’s EC2 or any other virtualized (or not) environment (eg. VMware). Many useful informations about JBoss Cloud (and JBoss Rails — another project from Bob) are enclosed in a great (no, that’s not irony) presentation. I highly recommend it!

JBoss Cloud is primarily designed to be a deployment tool / platform for JBoss Rails, but why not use it as a completely standalone project for clustered Java EE deployment? I’m not familiar with Rails (and Ruby too) — I would see JBoss Cloud as a big help for poeople that are deploying corporate apps written in JBoss Seam (my personal favourite).

I think, that a cool feature could be a user-friendly monitoring (management?) interface (web-app written in seam?). Maybe I could help with it? Will see.

Interested in JBoss Cloud? Want to learn more? Simply track Bob’s blog and join #jboss-cloud at freenode to ask him about this project! You can also grab the sources from GitHub and build yourself appliances or RPM’s. So, don’t be lazy — get involved! ;) I will keep my eyes on this project!

P.S. Primarly language of this blog is polish and most of posts will be still in polish. Just sometimes I will drop one or two notes in English to practice my poor language skills. So, be tolerant, please :)

Jak to było do tej pory?

Podstawowym modułem serwera Apache obsługującym połączenia na linii Apache — serwer aplikacji był (a w zasadzie nadal jest) moduł mod_proxy (wraz z modułami zależnymi przeznaczonymi dla konkretnego protokołu np. AJP, HTTP). Jego konfiguracja jest naprawdę bardzo prosta. Mając raz utworzony plik konfiguracyjny można go wykorzystać w innych instalacjach zmieniając tylko potrzebne opcje. Dodatkowo, jeżeli skonfiguruje się moduł mod_proxy_balancer (domyślny sposób równoważenia obciążenia w serwerze Apache — pisałem o tym  wcześniej), otrzymujemy możliwość zdefiniowania wielu serwerów aplikacji, jak i zasad równoważenia obciążenia między nimi. Po szczegóły odsyłam do (krótkiej, ale konkretnej) dokumentacji. Dodatkowo w Internecie można znaleźć tony instrukcji w jaki sposób uruchomić load balancer na podstawie serwera Apache na wybranej dystrybucji Linuksa (uruchamia to ktoś na Windowsie?!). Rozwiązanie oparte na mod_proxy i mod_proxy_balancer jest naprawdę dobre, ale głupie. Moduły nie wiedzą nic o stanie serwerów aplikacji poza tym, czy działają :) Na ogół takie postawienie sytuacji powinno wystarczyć. Jednak w przypadku gdybyśmy chcieli obciążać tylko jeden serwer, a drugi traktować jako dodatkową moc obliczeniową wykorzystywaną tylko i wyłącznie w przypadku, gdy pierwszy serwer nie jest w stanie obsłużyć wszystkich zapytań, rozwiązanie oparte na mod_proxy_balancer nie będzie pomocne.

Z pomocą nadchodzi mod_cluster

Od początku listopada tego roku na stronach społeczności JBossa udostępniony został projekt pod kierownictwem Jean-Frederic Clerea o dumnej nazwie mod_cluster. Oprócz niego w projekcie uczestniczą Brian Stansberry oraz Paul Ferraro.  Zadaniem mod_cluster, zupełnie tak jak w przypadku mod_proxy, jest przekierowywanie zapytań z serwera Apache do serwerów aplikacji. W takim razie, czym różnią się te rozwiązania? W odróżnieniu od mod_proxy, w przypadku mod_cluster komunikacja jest dwukierunkowa. Serwer aplikacji dodatkowo nawiązuje połączenie z serwerem Apache. Właśnie to połączenie odpowiada za inteligencję tego rozwiązania. Za jego pomocą przekazywane są informacje z cyklem życia aplikacji, jak również inne informacje potrzebne do zarządzania load balancerem (np. aktualne obciążenie serwera aplikacji). Informacje przesyłane są za pomocą protokołu Mod-Cluster Management Protocol (MCMP), który w rzeczywistości jest zbiorem metod protokołu HTTP. Co ciekawe — nie jest wymagane utworzenie nowego gniazda dla tych połączeń — serwer aplikacji komunikuje się z serwerem Apache na porcie, na którym jest on skonfigurowany! W rzeczywistości mod_cluster nie jest pojedynczym modułem. Jest to raczej zbiór następujących modułów: mod_slotmem, mod_manager, mod_proxy_cluster oraz mod_advertise. Duża część kodu źródłowego jest oparta na aktualnych implementacjach mod_proxy. Co ciekawe, to konfiguracja po stronie serwera aplikacji odpowiedzialna jest za mapowanie odpowiednich adresów do aplikacji. Szczególny wpływ ma na to konfiguracja domeny i ścieżki danej aplikacji na serwerze aplikacji. Dane te są przesyłane za pomocą wiadomości CONFIG do wszystkich load balancerów.  Jeżeli przychodzące do serwera Apache zapytanie dla wybranej domeny i ścieżki zostanie odnalezione wśród wpisów posiadanych przez moduł mod_cluster, zapytanie to zostanie automatycznie przekierowane do wybranego węzła.

Wymagania

Aby móc uruchomić mod_cluster potrzebny jest serwer Apache w wersji powyżej 2.2.8. Niestety aktualna wersja httpd dostępna dla systemu Red Hat / CentOS 5.2 oznaczona jest numerem 2.2.3. Pozostaje skompilować samemu odpowiednie moduły z dostępnego kodu źródłowego, gdy chcemy wykorzystać standardową instalację demona httpd. Należy zwrócić uwagę, że deweloperzy przygotowali odpowiednie paczki dla wielu systemów operacyjnych zawierające całą potrzebną instalację (łącznie z serwerem Apache!). Wszystko jest kompletne, skonfigurowane i gotowe do użytku! Można to lepiej zrobić?

Do uruchomienia mod_cluster potrzebny jest również odpowiedni kontener. W grę wchodzi JBoss Application Server 5.0.0+, Apache Tomcat, oraz JBoss Web 2.1.1+. Niestety nie doszukałem się informacji z jakimi wersjami Apache działa mod_cluster.

Najważniejsze cechy mod_cluster

Rozwiązanie JBossa wprowadza wiele usprawnień wpływających na konfigurację i zarządzanie klastrem. Oto niektóre z nich.

Dynamiczna konfiguracja workerów (a po polsku?)

Do tej pory to load balancer musiał wiedzieć jakie serwery aplikacji wchodzą w skład klastra. Powodowało to potrzebę rekonfiguracji load balancerów przy dodawaniu nowego węzła w klastrze. Od tej pory, przy użyci mod_cluster, to serwery aplikacji będą posiadały informację o dostępnych load balancerach. Informacja ta może być umieszczona na stałe w konfiguracji serwerów aplikacji jako lista lub mogą one zostać wykryte automatycznie przez serwer aplikacji przy użyciu muticastu za pośrednictwem mechanizmu advertise. W środowiskach, w których nie można użyć multicastu (np. VMware) należy skonfigurować ręcznie listę dostępnych load balancerów.

Współczynnik obciążenia obliczany po stronie serwerów aplikacyjnych

Współczynniki rozkładu obciążenia w przypadku mod_proxy_balancer (jak i w starym mod_jk) były umieszczane na stałe w konfiguracji tych modułów. Statyczna konfiguracja mogła doprowadzić do przeciążenia jednego serwera, gdy inne w klastrze nie były obciążone. Oczywiście zależało to od poprawnego zdefiniowania współczynników. W przypadku mod_cluster problem ten został wyeliminowany. Współczynniki są obliczane po stronie serwerów aplikacji a następnie przekazywane do load balancera, który znając współczynniki wszystkich węzłów w klastrze może efektywnie zarządzać zapytaniami w zależności od obciążenia serwerów.

Należy dodać, że rozwiązanie to sugeruje się informacjami otrzymanymi od serwerów — po stronie serwera http nie ma obliczania współczynników!

Pełna kontrola cyklu życia aplikacji

Rozwiązania dostępne obecnie na rynku w postaci modułów serwera Apache nie potrafią poprawnie obsłużyć takich zdarzeń jak wdrożenie, czy usunięcie aplikacji z serwera. Odwołanie się do usuniętej z serwera aplikacji powoduje po prostu wyświetlenie błędu 404. W przypadku mod_cluster błędy te zostały wyeliminowane, ponieważ informacje o cyklu życia aplikacji są przesyłane do load balancera.

Architektura mod_cluster

Architekturę mod_cluster można podzielić na dwie części. Z jednej strony znajdują się usługi uruchomione na serwerze http, z drugiej strony usługi uruchomione na serwerze aplikacji. Po stronie serwera http uruchomiony jest zestaw modułów wspomnianych wcześniej, natomiast po stronie serwera aplikacji uruchomiona jest usługa ModClusterService. Usługa ta odpowiedzialna jest za komunikację z dostępnymi load balancerami. W szczególności dotyczy to informowania ich o stanie serwera i aplikacji na nim uruchomionych. Szczegółowe informacje można znaleźć na stronach wiki projektu.

Wyróżnić można dwa tryby pracy klastra: z klastrowaniem lub bez.

Konfiguracja bez klastrowania

W tym trybie serwery aplikacji nie wymieniają danych między sobą.

Konfiguracja bez klastrowania

Oznacza to, że dwie, te same, aplikacje uruchomione na dwóch serwerach nie będą wiedziały o swoim istnieniu, oraz żadne dane nie będą replikowane do innych serwerów. Klient, po awarii jednego z serwerów i przełączeniu do innego, straci wszystkie dane znajdujące się aktualnie sesji, będzie się musiał również ponownie zalogować. Oczywiście przesyłane są informacje do serwera http odpowiedzialne za rejestrację serwera apliakcji w load balancerze, czy związane z cyklem życia aplikacji. Natomiast współczynnik obciążenia przesyłany przez serwer aplikacji będzie miał wartość obliczaną (lub ustalaną odgórnie) tylko dla tego konkretnego serwera. Współczynnik ten będzie wpływał na działanie całego systemu tak samo jak wartość lbfactor w pliku konfiguracyjnym workers.properties modułu mod_jk.

Konfiguracja z klastrowaniem

W tym trybie serwery aplikacji formułują klaster, a dane są wymieniane między węzłami w klastrze.

Konfiguracja z klastrowaniem

Wymieniane są również informacje o aktualnym stanie serwerów pomiędzy instancjami. Jedna z usług ModClusterService będzie zawierała komponent HASingleton odpowiedzialny za zbieranie informacji o stanie wszystkich węzłów. Następnie dane te są poddawane analizie, a wyniki w postaci czynnika obciążenia dostarczane są wszystkim węzłom w klastrze oraz dostępnym load balancerom.

Instalacja

Należy skonfigurować odpowiednio serwer Apache i aplikacji. Bardzo dobra dokumentacja instalacji znajduje się na stronach mod_cluster, zarówno jeżeli chodzi o konfigurację serwera Apache jak i serwera aplikacji.

Podsumowanie

Pewnie parę osób zarzuci mi, że jestem przesadnie podekscytowany tym rozwiązaniem. Być może, ale nie ulega żadnej wątpliwości, że mod_cluster zmieni całkowicie podejście do programowych load balancerów. Polecam przyjrzenie się temu projektowi! Według mapy wydań możemy się spodziewać w najbliższym czasie pierwszego, stabilnego wydania mod_cluster, a więc nie ma na co czekać, tylko uruchamiać. W końcu każdy chce mieć stabilny i szybki system. Co? Może nie?

Warto odwiedzić

• Strona domowa projektu
• Bug tracker (JIRA)
• Forum użytkowników
• Krótki post Boba McWhirtera opisujący konfigurację mod_cluster w środowisku pozbawionym multicastu (VMware)

• EJB 3.0, JavaBeans, JPA, JSF
• JBoss Seam 2.1.0.SP1
• RichFaces 3.2.2.GA
• Hibernate 3.2.4.sp1 (dialekt PostgreSQL)

Używane przeze mnie IDE to Eclipse Ganymede, wraz z zestawem wtyczek JBoss Tools.  Połączenie to stanowi bardzo dobre środowisko do tworzenia aplikacji we frameworku JBoss Seam. Aplikacje uruchamiam na gorąco na serwerze JBoss AS za pomocą skryptu Anta — nowe pliki są kompilowane i kopiowane do katalogu deploy serwera JBoss. Na tym etapie nie przewiduję żadnych zmian w konfiguracji.

Po podmianie ścieżki do nowego serwera spróbowałem uruchomić aplikację  (a nóż widelec…). Jak można było łatwo przewidzieć — nie uruchomiła się.

Moja aplikacja używa cacheowania encji. Okazało się, że w tym temacie zaszły duże zmiany w nowej wersji serwera. Na szczęście dostępna jest bardzo dobra dokumentacja, która pozwoliła mi się wstępnie rozeznać w temacie. Od wersji 5.0 pamięcią podręczną w serwerze JBoss AS zarządza nowa usługa — CacheManager. Na stronie z dokumentacją nowej usługi znajduje się szczegółowa informacja w jaki sposób skonfigurować aplikację — okazało się to bardzo pomocne :)

Dokonałem zmian zgodnych z sekcją Usage with JPA and Hibernate Entity Clustering dokumentu i uruchomiłem ponownie aplikację. Posunąłem się tylko o mały krok naprzód, ponieważ JBoss przywitał mnie wyjątkiem:

20:03:35,416 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=system.ear/system.jar#system state=Create
javax.persistence.PersistenceException: [PersistenceUnit: system] Unable to build EntityManagerFactory
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:677)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:311)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
	at org.jboss.Main.boot(Main.java:209)
	at org.jboss.Main$1.run(Main.java:547)
	at java.lang.Thread.run(Thread.java:619)
Caused by: org.hibernate.cache.CacheException: unsupported access type [nonstrict-read-write]
	at org.hibernate.cache.jbc2.entity.EntityRegionImpl.buildAccessStrategy(EntityRegionImpl.java:66)
	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:256)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327)
	at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
	... 51 more

Moje encje wyglądają mniej więcej tak:

@Name("rolePermission")
@Entity
@Table(name = "role_permissions")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
@SequenceGenerator(name = "role_permission_seq", sequenceName = "role_permission_seq")
public class RolePermission implements Serializable, SystemEntity {

	...

}

Zgłupiałem. Czyżby ta strategia dostępu do encji nie była wspierana? Przecież w JBoss AS 4.2.x była! Kod źródłowy klasy org.hibernate.cache.jbc2.entity.EntityRegionImpl okazał się pomocny.

    public EntityRegionAccessStrategy buildAccessStrategy(AccessType accessType) throws CacheException {
        if (AccessType.READ_ONLY.equals(accessType)) {
            return optimistic ? new OptimisticReadOnlyAccess(this) : new ReadOnlyAccess(this);
        }
        if (AccessType.TRANSACTIONAL.equals(accessType)) {
            return optimistic ? new OptimisticTransactionalAccess(this) : new TransactionalAccess(this);
        }

        // todo : add support for READ_WRITE ( + NONSTRICT_READ_WRITE ??? )

        throw new CacheException("unsupported access type [" + accessType.getName() + "]");
    }

Ten TODO wyjaśnia wszystko…

Atrybut usage adnotacji @org.hibernate.annotations.Cache ustala jeden z pięciu typów strategii użycia pamięci podręcznej:

1. NONE — pamięć nie jest używana,
2. READ_ONLY — aplikacja czyta obiekty, ale nigdy ich nie modyfikuje,
3. READ_WRITE — dane mogą być odczytywane jak i modyfikowane,
4. NONSTRICT_READ_WRITE — dane są głównie odczytywane, modyfikacje mogą wystąpić, ale są rzadkie,
5. TRANSACTIONAL — używany przy providerach w pełni wspierających transakcje.

Do tej pory używałem CacheConcurrencyStrategy.NONSTRICT_READ_WRITE z uwagi na wydajność. Wygląda na to, że trzeba się pożegnać z tym trybem na rzecz CacheConcurrencyStrategy.TRANSACTIONAL.

Kolejna próba uruchomienia aplikacji zakończyła się sukcesem, jeżeli można tak powiedzieć. Po drodze musiałem poprawić jeden komponent. Przy okzji hot deploy’u nowej wersji odkryłem błąd — aplikacja uruchamia się, po czym chwilę później zamyka się — bez jakichkolwiek błędów, czy ostrzeżeń!

20:43:38,856 INFO  [SeamFilter] Initializing filter: org.jboss.seam.web.identityFilter
20:43:38,864 INFO  [[/system]] org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: conf reload check performed each request
20:43:38,923 INFO  [[/system]] org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: loaded (conf ok)
20:43:44,104 INFO  [TomcatDeployment] undeploy, ctxPath=/system, vfsUrl=system.ear/system.war
20:43:44,108 INFO  [[/system]] org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called

Bardzo irytujące — nie da się przez to pracować, ponieważ deploy trwa w takim przypadku ok. 10 minut (sic!). Muszę poczytać o hot deploy’u w nowej wersji, bo to powinno działać! Kupiłem sobie książkę JBoss in Action — będzie dobry pretekst aby ją przeczytać :)  Tymczasem wracam do starego, dobrego JBoss AS 4.2.3.

źródło: http://www.jboss.org/

Jak dumnie informuje strona główna community JBossa wersja 5 została oznaczona jako gotowa do produkcyjnych zastosowań i jest już dostępna do pobrania!

Nic tylko ściągać i instalować. Lista zmian dostępna jest na stronie z informacjami o wydaniu – na pierwszy rzut oka wygląda pokaźnie. Oprócz poprawek wielu błędów mamy aktualizacje do najnowszych wersji różnych projektów zależnych, poprawki upiększające, czy takie kwiatki jak wstępne przygotowanie do Java EE 6 (web config – konfiguracja zgodna z założeniami Java EE 6 dla profilu web). Przez weekend muszę się bliżej przyjrzeć zmianom.

Ciekawe jak będzie wyglądała integracja z ich flagowym frameworkiem – JBoss Seam? Dorzucić do TODO: przez weekend zmigrować mój poligon doświadczalny z wersji 4.2.3 na 5.

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.

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.

import javax.persistence.Entity;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity
@Table(name = "role_permissions")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class RolePermission extends BaseEntity {

	private static final long serialVersionUID = 6778357970340362708L;

	private String role;
	private String target;

...

}

oraz dodać odpowiednie właściwości do pliku persistence.xml:

<property name="hibernate.cache.provider_class" value="org.jboss.ejb3.entity.TreeCacheProviderHook" />
<property name="treecache.mbean.object_name" value="jboss.cache:service=EJB3EntityTreeCache" />

Dodatkowo należy posiadać odpowiednio skonfigurowany serwer. Są na to dwa sposoby:

1. Uruchomienie serwera w konfiguracji all,
2. Uruchomienie serwera w konfiguracji default po jej uprzednim przygotowaniu.

Drugi sposób jest o tyle lepszy, że jest start serwera jest zdecydowanie szybszy, co na maszynie deweloperskiej jest dużym atutem. Konfiguracja all pozwala na klastrowanie, ale komu to potrzebne przy tworzeniu i testowaniu aplikacji?

Aby uruchomić cacheowanie encji przy konfiguracji default (domyślnej) należy skopiować z katalogu $JBOSS_HOME/server/all/lib/ biblioteki jboss-cache-jdk50.jar oraz jgroups.jar do katalogu $JBOSS_HOME/default/lib/.

Dodatkowo należy skopiować plik $JBOSS_HOME/server/all/deploy/ejb3-entity-cache-service.xml do katalogu $JBOSS_HOME/default/deploy/.

I to wszystko – możemy już cieszyć się encjami z pamięci podręcznej.

Poprawność uruchomienia cacheowania można sprawdzić w konsoli JMX serwera JBoss pod adresem http://localhost:8080/jmx-console/ wyszukując usługę *:service=EJB3EntityTreeCache,*, a następnie uruchamiająć akcję printDetails(). Na wynikowym ekranie powinna się znaleźć encja oznaczona adnotacją @Cache.