Archive for category JBoss AS

Różnice w konfiguracji pomiędzy profilami all i production w JBoss EAP 5

Paź 24

Posted by Łukasz Stelmach in JBoss AS | Comments off

Serwer aplikacji JBoss EAP 5 zawiera szereg profili, które pozwalają uruchomić rożne jego konfiguracje. Między innymi można znaleźć tam profile all oraz production.

Profil all wspiera klastrowanie i jest przeznaczony do używania podczas tworzenia czy też testowania aplikacji, natomiast profil production jest zoptymalizowany pod typowy serwer produkcyjny. Poniżej znajdzie się opis różnic w konfiguracji obydwóch profili.

Modyfikacje w logowaniu informacji

W wersji production występuje sporo różnic w sposobie logowania informacji przez serwer JBoss:

  • wyłączenie logowania informacji na konsolę
  • włączenie konfiguracji pozwalającej na logowanie asynchronicznie
  • przekierowanie komunikatów z pakietów org.jgroups oraz org.jboss.ha do pliku cluster.log
  • zwiększenie priorytetu logowanych informacji z INFO do WARN

Hot deploy

Zwiększenie czasu skanowania katalogu deploy z 5 na 60 sekund.

Modyfikacje w pliku hdscanner-jboss-beans.xml
all
14
<property name="scanPeriod">5000</property>
production
14
<property name="scanPeriod">60000</property>

Wyłączenie śledzenia połączeń do bazy danych

W profilu production zostaje wyłączone śledzenie otwartych połączeń do bazy danych i ich automatyczne zamykanie:

Modyfikacje w pliku jca-jboss-beans.xml
all
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">true</property>
production
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">false</property>

Generowanie unikalnych identyfikatorów

W usłudze uuid-key-generator.sar zostało zwiększone bezpieczeństwo uzyskiwanych danych w przypadku używania klastrów:

Modyfikacje w pliku uuid-key-generator.sar/META-INF/jboss-service.xml
all
42
43
44
45
46
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended)
<attribute name="SelectHiSql">
   select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE

-->
production
42
43
44
45
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended) -->
<attribute name="SelectHiSql">
    select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE
</attribute>

Wyłączenie możliwości ładowania klas nie będących ziarnami EJB

Klient RMI ma możliwość ładowania klas bezpośrednio z serwera aplikacji. Dzięki temu nie trzeba razem z klientem dostarczać klas znajdujących się po stronie serwera. Jednakże włączenie tej opcji udostępnia wszystkie wszystkie zasoby znajdujące się na w ramach zmiennej classpath każdemu klientowi, bez możliwości kontroli co on pobiera.

W przypadku profilu production zostaje włączona możliwość ładowania jedynie klas EJB.

Modyfikacje w pliku jboss-service.xml
all
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">true</attribute>
production
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">false</attribute>

Tags: , , ,

Zatrzymanie i uruchomienie zainstalowanej aplikacji przy użyciu linii poleceń w serwerze JBoss AS

Cze 19

Posted by Łukasz Stelmach in JBoss AS | Comments off

Aplikacje zainstalowane w serwerze JBoss można zarówno zatrzymywać jak i ponownie uruchamiać, bez konieczności ich instalacji.

Odpowiednie akcje można bez trudności znaleźć w np. w konsoli administracyjnej:

Admin Console - kontrola aplikacji

Admin Console - kontrola aplikacji

Odpowiednie akcje pozwalają na zatrzymanie, uruchomienie lub restart aplikacji.

Co jednak zrobić, aby takie same akcje wykonać przy użyciu linii poleceń?

Za zarządzanie serwerem JBoss z linii poleceń odpowiada polecenie twiddle, można je znaleźć w katalogu bin serwera, tam gdzie pliku run.sh. Przy jego pomocy można wykonywać określone akcje na odpowiednich ziarnach.

Pozostaje więc teraz tylko znaleźć ziarna odpowiedzialne za poszczególne akcje i powinno być po sprawie.

Operacja na aplikacjach typu WAR

Aplikacje typu war to aplikacje webowem uruchamiane w ramach kontenera JBoss Web Container (czyli we wbudowanym Tomcacie). Aby taką aplikację zatrzymać czy też wystartować, należy znaleźć tylko odpowiednie ziarno, które za nią stroi. W tym przypadku wystarczy się przyjrzeć zawartości ziaren znajdujących się w grupie jboss.web.deployment.

Można to zrobić albu używając konsoli JMX lub też bezpośrednio przy użyciu polecenie twiddle:

$ twiddle.sh query 'jboss.web.deployment:*'
jboss.web.deployment:war=/ROOT
jboss.web.deployment:war=/admin-console
jboss.web.deployment:war=/jmx-console
jboss.web.deployment:war=/invoker
jboss.web.deployment:war=/juddi

Tym sposobem otrzymamy listę ziaren, które odpowiadają za zarządzaniem poszczególnymi aplikacji. Teraz pozostaje się dowiedzieć, jakich metod można na nich używać:

$ twiddle.sh info 'jboss.web.deployment:war=/ROOT'
Description: Management Bean.
+++ Attributes:
 Name: SecurityManagement
 Type: org.jboss.security.ISecurityManagement
 Access: -w
 Name: PolicyRegistration
 Type: org.jboss.security.authorization.PolicyRegistration
 Access: -w
 Name: Kernel
 Type: org.jboss.kernel.Kernel
 Access: -w
+++ Operations:
 void destroy()
 void start()    
 void stop()
 void create()

Interesujące są dwie metody: start oraz stop. Polecenie, które zatrzyma aplikację:

$ twiddle.sh invoke 'jboss.web.deployment:war=/ROOT' stop

W logach JBossa powinien pojawić się taki komunikat:

15:35:35,665 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/

Uruchomienie aplikacji jest możliwe poprzez taką komendę:

$ twiddle.sh invoke 'jboss.web.deployment:war=/ROOT' start

I w logach można znaleźć informację o uruchomieniu aplikacji:

15:37:20,268 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/

Inne typy aplikacji

Niestety, nie udało mi się znaleźć odpowiednich ziaren dla typów EAR czy RAR. Widać, że takie istnieją, ale nie zachowują się do końca tak jak bym chciał.

Polecenie to wyświetli listę ziaren z grupy jboss.j2ee:

$ twiddle.sh query 'jboss.j2ee:*'

W moim przypadku wyświetlone zostały dwa ziarna które pasowały do aplikacji. Jedno z nich zawierało akcje start oraz stop. I tak wywołanie akcji stop niczego nie zmieniło (aplikacja dalej działała). Wywołanie natomiast akcji start powodowało wyświetlenie komunikatów o zainstalowaniu aplikacji, ale także niczego nie zmieniło w jej działaniu (jak obsługiwała połączenia tak obsługiwała je cały czas).

Metodą, która natomiast zadziałała bez zastrzeżeń, jest wymuszenie odinstalowania aplikacji. Więcej można przeczytać w tym artykule: Zarządzanie instalacją aplikacji w JBoss AS. W skrócie wygląda to tak:

  • usunięcie aplikacji:
    $ twiddle.sh invoke "jboss.system:service=MainDeployer" undeploy "file:/ścieżka/do/pliku/do/instalacji"
  • instalacja aplikacji:
    $ twiddle.sh invoke "jboss.system:service=MainDeployer" deploy "file:/ścieżka/do/pliku/do/instalacji"

Przy takim instalowaniu aplikacji należy jednak pamiętać o dwóch sprawach:

  • jeżeli JBoss ma uruchomioną usługę HDScanner, to jeżeli zostanie odinstalowana aplikacje znajdująca się w katalogu deploy, może ona zostać zaraz zainstalowana ponownie przez tą usługę
  • aplikacje, które nie znajdują się w katalogu deploy nie są automatycznie instalowane podczas startu serwera JBoss, więc trzeba je zainstalować później[/cci]

Źródła

Tags: , , , , ,

Konfiguracja serwera aplikacji JBoss 5 do pracy z Jopr

Maj 21

Posted by Łukasz Stelmach in JBoss AS, RHQ/JON | Comments off

Nowa wersja aplikacji Jopr (2.3.1) teoretycznie wspiera obsługę zarządzania serwerem aplikacji JBoss EAP 5. W praktyce niestety agent nie wyrywa w ogóle tego serwera aplikacji. Spowodowane jest to brakiem odpowiedniej wtyczki, która obsługiwałaby tę wersję JBoss (z wersją 4.x nie tutaj żadnych problemów, jest w pełni obsługiwana).

Okazuje się na szczęście, że odpowiedni plugin istnieje, i nawet działa, ale należy skompilować go samodzielnie. Odpowiednią procedurę przedstawiłem w tym wpisie: Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr. Po kompilacji kodu powinniśmy dysponować odpowiednią wersję wtyczki, która już powinna wykryć wersję 5 serwera JBoss.

Jednakże nie wystarczy tylko do włączenia zarządzania instancją serwera przy użyciu Jopra. Od wersji 5 wyłączono anonimowy dostęp do konsoli JMX (dzięki której można ta naprawdę zarządzać serwerem). W związku z tym, dopóki po stronie serwera aplikacji nie zdefiniujemy użytkownika mogącego się łączyć z konsolą, nie będziemy w stanie korzystać z konsoli JMX.

Przy domyślnej konfiguracji dane użytkowników są przechowywane w dwóch plikach, zapisanych w wybranej konfiguracji serwera:

  • conf/props/jmx-console-users.properties – informacje o loginach i hasłach użytkowników
  • conf/props/jmx-console-roles.properties – informacje o grupach użytkowników

W najprostszym przypadku wystarczy odkomentować jedną linię z pliku jmx-console-users.properties i już można cieszyć się kontem administracyjnym. Ze względu bezpieczeństwa jednak proponowałbym zmienić chociaż hasło dostępu dla tego użytkownika na jakieś mniej standardowe.

Drugim niezbędnym elementem jest odpowiednia konfiguracja Jopra. Robi się to poprzez:

  • import serwera JBoss do monitorowanych zasobów
  • konfigurację użytkownika i hasła pozwalającego na dostęp do konsoli JMX

Konfigurację loginu i hasła należy zrobić poprzez:

  • wybranie z listy serwerów interesujący nas serwer JBossa
  • wybranie zakładki Inventory
  • wybranie opcji Connection
  • edycję pozycji[cci] Principal/cci] i [cci]Credential/cci] (najpierw należy wybrać przycisk [cci]Edit/cci] znajdujący się na dole strony)
    Połączenie Jopr - JBoss 5

    Połączenie Jopr - JBoss 5

  • po zatwierdzeniu zmian powinniśmy już dysponować dostępem do serwera aplikacji JBoss i możliwością jego zarządzania

Źródła

Tags: , , , ,

Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Maj 18

Posted by Łukasz Stelmach in JBoss AS | Comments off

Po wstępie wyjaśniającym czym jest mod_cluster oraz jak skompilować odpowiednie moduły potrzebne do jego uruchomienia czas na konfigurację.

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Pobranie modułu mod_cluster

Odpowiednie pliku do ściągnięcie można znaleźć na stronie projektu. Ja użyłem wersji stabilnej oznaczonej jako 1.0.3 GA dla platformy 64 bitowej:

Instalacja modułów w serwerze Apache

Należy pamiętać, że mod_cluster wymaga wersji Apacha przynajmniej 2.2.8. Może to być problem w przypadku RHEL 5.5, ponieważ tutaj dostępna jest wersja 2.2.3. Należy w związku z tym zainstalować nowszą wersję aplikacji.

Należy rozpakować plik z bibliotekami dynamicznymi (mod_cluster-1.0.3.GA-linux2-x64-so.tar.gz) i skopiować zawarte w nim biblioteki do katalogu /etc/httpd/modules):

cp mod_advertise.so mod_manager.so mod_proxy_cluster.so mod_slotmem.so /etc/httpd/modules

W przypadku gdy nie znajdziemy odpowiedniej wersji modułów, należy skompilować je samodzielnie.

Konfiguracja serwera WWW Apache

Jeżeli wszystko poszło OK, to powinniśmy już dysponować zainstalowanymi modułami potrzebnymi do działania klastra. Aby je włączyć, należy kazać je serwerowi Apache załadować i odpowiednio je skonfigurować.

Należy utworzyć plik /etc/httpd/conf.d/jboss.conf. Pliki znajdujące się w tym katalogu i z rozszerzeniem conf zostaną automatycznie wczytane podczas startu serwera i zinterpretowane. W pliku tym załadujemy potrzebne moduły oraz zdefiniujemy serwer wirtualny, w ramach którego będzie działa balansowanie ruchem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

<VirtualHost 192.168.3.11:80>

        <Directory />
                Order deny,allow
                Allow from all
        </Directory>

        KeepAliveTimeout 60
        MaxKeepAliveRequests 0

       AdvertiseFrequency 5

       <Location /mod_cluster-manager>
           SetHandler mod_cluster-manager

           Order deny,allow
           Deny from all
           Allow from 127.0.0.1
       </Location>


</VirtualHost>

Powyższy plik jest minimalnym plikiem, który pozwala nam uruchomić klaster. Jeżeli serwer Apache uruchomił się bez problemów, można uznać do za sukces i przystąpić do dalszych kroków.

Definicja serwera wirtualnego jest standardowa, poza następującymi elementami:

  • AdvertiseFrequency – czas jaki musi upłynąć pomiędzy próbą wykrycia adresów IP oraz portu, domyślna wartość to 10 sekund
  • SetHandler – pozwala na wyświetlanie informacji o tym, jakie węzły klastra są widoczne przez moduł mod_cluster

Problemy ze startem serwera Apache

W przypadku problemów trzeba jest najpierw rozwiązać. Ja spotkałem się z nastepującymi problemami:

  • Cannot load /etc/httpd/modules/mod_slotmem.so into server: /etc/httpd/modules/mod_slotmem.so: cannot open shared object file: No such file or directory – brak możliwości otworzenia podanego pliku. Może to oznaczać:
    • brak pliku w podanej lokalizacji, czyli błędnie skopiowany plik
    • błędne uprawnienia na plik (biblioteka powinna mieć ustawiony bity do odczytu i wykonywalności)
    • próba wczytania biblioteki o złej architekturze (to przytrafiło się mi 🙂 ), można to sprawdzić w prosty sposób, wynik tego polecenia powinien zwrócić takie same informacje (poniżej są inne):
      file /etc/httpd/modules/mod_slotmem.so /etc/httpd/modules/mod_alias.so
      /etc/httpd/modules/mod_slotmem.so: ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped
      /etc/httpd/modules/mod_alias.so:   ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
  • Module mod_proxy_balancer is loaded it must be removed  in order for mod_proxy_cluster to function properly – komunikat pojawi się w w pliku error.log. Aby rozwiązać problem, należy usunąć ładowanie modułu mod_proxy_balancer. Można to zrobić edytując plik /etc/httpd/conf/httpd.conf i zakomentować linię:
    189
    #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

Instalacja modułu w serwerze aplikacji

Pierwszym krokiem jest skopiowanie aplikacji mod_cluster.sar do katalogu deploy danego serwera:

cp -a mod_cluster.sar $JBOSS_HOME/server/node1/deploy

Teraz należy odpowiednio skonfigurować serwer aplikacji. Konfiguracja będzie dotyczyła aplikacji jbossweb.sar znajdującej się w katalogu deploy danej konfiguracji serwera. W pliku tym należy dodać następujący element (pod istniejącymi elementami Listener):

9
10
11
<Listener
 className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener"
 delegateBeanName="ModClusterService"/>

Drugą modyfikacją jest dodanie zmiennej jvmRoute do sekcji Engine:

36
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">

Na podstawie tej wartości dany węzeł będzie identyfikowany przez serwer Apache, wartość ta powinna być unikalna w ramach klastra.

Kolejnym plikiem który trzeb otworzyć jest deploy/jbossweb.sar/META-INF/jboss-beans.xml. Do pliku tego należy dodać następujący w ramach definicji ziarna WebServer następującą zależność:

17
<depends>ModClusterService</depends>

I to wszystko, teraz należy wystartować serwery Apache oraz JBoss i jeżeli nie wystąpią jakieś błędy to powinniśmy mieć już skonfigurowany load balancer. Można otworzyć lokalizację mod_cluster-manager na serwerze WWW i sprawdzić, czy mod_cluster poprawnie wykrył klaster.

Pozostaje jeszcze skonfigurować pozostałe węzły klastra i również je uruchomić.

Źródła

Tags: , , , ,

Konfiguracja klastra oparta o moduł mod_cluster – kompilacja modułów

Maj 17

Posted by Łukasz Stelmach in JBoss AS | Comments off

Moduł mod_cluster jest dostępny dla kliku architektur, ale na pewno nie dal wszystkich. W moim przypadku wersja pobrana ze stron JBossa nie chciała działać z serwerem Apache. Nie pozostało więc nic innego, jak skompilować odpowiednie moduły ze źródeł. Na szczęście nie jest to trudne :).

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Krok 1: instalacja potrzebnych pakietów

Pierwszym krokiem jest rozstrzygnięcie, czy chcemy korzystać z wersji udostępnionej na stronie w postaci źródeł czy też pobrać najnowszą wersję modułów z systemu kontroli wersji. W pierwszym przypadku trzeba udać się na stronę pozwalająca ściągnąć źródła w odpowiedniej wersji.

W przypadku drugim należy zainstalować (jeżeli nie mamy) narzędzie Subversion. W moim przypadku komenda instalująca pakiet była następująca (musiałem wybrać wersję architektury, aby zainstalowała się odpowiednia wersja pakietu, prawdopodobnie nie jest to potrzebne w większości przypadków):

yum install subversion.x86_64

Kolejnym elementem jest instalacja dwóch pakietów:

  • autoconf – narzędzia potrzebne do konfiguracji kompilacji
  • httpd-devel – narzędzia i biblioteki potrzebne do budowania modułów dla serwera Apache
yum install autoconf
yum install httpd-devel-2.2.14-1.2.6.jdk6.ep5.el5.x86_64

I tutaj również musiałem bardzo szczegółowo podać wersję pakietu httpd-devel. Być może będziesz potrzebować innych pakietów więc w razie problemów w dalszych krokach będzie trzeba te braki uzupełnić.

Krok 2: pobranie źródeł

W celu pobrania źródeł pakietu z systemu kontroli wersji należy wydać następujące poleceni:

svn co http://anonsvn.jboss.org/repos/mod_cluster/trunk/ mod_cluster

Utworzy ono katalog mod_cluster i w nim zapisze pobrane źródła.

Można także pobrać źródła modułu ze strony Downloads.

Ja pobrałem aktualne źródła z repozytorium, w wersji o numerze 271.

Krok 3: kompilacja i instalacja modułów

Odpowiednie moduły skompilują poniższy zestaw instrukcji (powinny one zostać wykonane w katalogu mod_cluster/native:

1
2
3
4
5
6
7
8
9
for DIR in advertise mod_manager mod_proxy_cluster mod_slotmem
do
    cd $DIR
    sh buildconf
    ./configure --with-apxs=/usr/sbin/apxs
    make
    cp *.so /etc/httpd/modules/
    cd ..
done

Przed uruchomieniem powyższego skryptu proszę zwrócić uwagę na ścieżki dostępu, zarówno do narzędzia apxs jak i miejscu gdzie znajdują się moduły Apacha. Powyższy także kopiuje moduły do katalogu z modułami.

Jeżeli kompilacja przebiegła bez problemów, to odpowiednie moduły powinny już znaleźć się w katalogu z modułami Apache i można je używać.

Źródła

  • Building mod_cluster from sources

Tags: , , , , ,