Posts Tagged klaster

Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

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

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: , , , , ,

Konfiguracja klastra oparta o moduł mod_cluster – wprowadzenie

Wpisem tym rozpoczynam serię poświęconą modułowi pozwalającemu na budowę łącza pomiędzy serwerem WWW Apache a serwerem aplikacji JBoss w wersji 5. Postaram się opisać sposób instalacji, kompilacji, konfiguracji, przygotowania do działania.

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

Istnieją dwa główne sposoby na które można można udostępnić aplikację webową działającą na JBossie (lub też Tomcacie) w Internecie:

  • udostępnić bezpośredni dostęp do serwera aplikacji na którym jest zainstalowana aplikacja
  • wykorzystanie odpowiedniego pośrednika, który będzie pośredniczył pomiędzy wywołaniami z Internetu a serwerem aplikacji

Pierwszy sposób jest łatwy do realizacji, ale posiada kilka wad, takich jak:

  • brak wsparcia balansowania ruchem (w przypadku konfiguracji z klastrem)
  • brak optymalizacji wydajności (np. serwowanie statycznej treści z innych źródeł, bardziej wydajnych niż serwer aplikacji)
  • mniejsze bezpieczeństwo (trudniej zabezpieczyć serwer aplikacji z powodu dużej ilości działających usług)

Drugim sposobem jest udostępnienie odpowiednich usług poprzez pośrednika, który będzie przekierowywał połączenia przychodzące do aplikacji na serwerze JBoss. Rozwiązanie takie charakteryzuje się:

  • trudniejszą konfiguracją (trzeb skonfigurować zarówno pośrednika jak i serwer aplikacji)
  • wsparciem dla balansowania ruchem i failover
  • zwiększa bezpieczeństwo (udostępniamy tylko te aplikacje, na jakich nam zależy)
  • może zwiększyć wydajność rozwiązania (serwowanie statycznych fragmentów strony z innych źródeł niż serwer aplikacji)

Najczęściej używanym pośrednikiem w przypadku łączenia z JBossem lub Tomcatem jest serwer WWW Apache. W jego przypadku mamy możliwość skorzystania z trzech różnych modułów pozwalających na łączenie się z serwerem aplikacji:

  • mod_proxy – szybki i łatwy sposób konfiguracji, ale gorsze wsparcie klastrowania
  • mod_jk – zaawansowany moduł z dobrą obsługa klastrów, skomplikowany w konfiguracji
  • mod_cluster – nowo rozwijany moduł pozwalający na połączenie z serwerem aplikacji

Każdy z tych modułów konfiguruje się inaczej, mają także inne właściwości. Poniżej postaram się przedstawić sposób konfiguracji połączenie pomiędzy serwera Apacha z modułem mod_cluster a serwerem aplikacji JBoss.

Wymagania minimalne

Moduł mod_cluster posiada określone wymagania zarówno odnośnie serwera Apache jak JBoss:

  • serwer WWW Apache w wersji co najmniej 2.2.8
  • serwer JBoss w wersji co najmniej 5.0

Konfiguracja z której ja będę korzystał jest następująca:

  • system operacyjny: Red Hat Enterprise Linux 5.5 64bit
  • serwer WWW: Apache w wersji 2.2.14 – standardowe jest dostępna wersja 2.2.3, nowszą wersję serwera można pobrać z kanału JBoss EWS for 5Server x86_64
  • Java: wersja 1.6.20
  • serwer aplikacji JBoss EAP 5 – aby przetestować działanie klastra zostanie utworzony klaster składający się z trzech węzłów
  • moduł mod_cluster, wersja 1.1.0.CR2

Czym jest moduł mod_cluster

Moduł mod_cluster odpowiada za przeprowadzenia balansowanie ruchem bazującym o protokół HTTP. Pozwala on na przekierowanie żądań przychodzących do serwera WWW do jednego z węzłów klastra.

W przeciwieństwie do dwóch pozostałych modułów (mod_jk oraz mod_proxy) tworzy on dodatkowe połączenie pomiędzy poszczególnymi węzłami klastra a serwerem WWW. Poprzez do połączenie odpowiednia aplikacja po stronie serwera aplikacji informuje moduł mod_cluster o swojej sytuacji. Wykorzystuje w tym celu zestaw metod, zwanych Mod-Cluster Management Protocol (MCMP). Te dodatkowe informacje pozwalają na duże lepszą integrację serwera WWW z klastrem oraz lepsze zarządzanie przekazywanymi połączeniami.

Zalety mod_cluster

Najważniejsze zalety w stosunku do innych aplikacji odpowiedzialnych za balansowanie ruchem HTTP:

  • dynamiczna konfiguracja połączeń z węzłami klastra
  • obliczanie współczynników balansowania ruchem po stronie serwera
  • kontrola na cyklem życia aplikacji zainstalowanej na klastrze
  • opcjonalne użycie protokołu AJP

W następnych częściach przedstawię, w jaki sposób skonfigurować moduł mod_cluster do pracy z klastrem serwerów JBoss.

Źródła

Tags: , , , ,

JBoss Cluster – zabezpieczenie komunikacji między serwerami

Przy użyciu serwera aplikacji JBoss AS bardzo łatwo jest utworzyć klaster. Serwer ten wspiera automatyczne wykrywanie poszczególnych maszyn, które uczestniczą w danym klastrze. Konfiguracja polega na uruchomieniu serwera przy użyciu profilu opartego o profil all i podaniu kilku parametrów:

$ ./run.sh -c node1 -b jboss1 -Djboss.messaging.ServerPeerID=1 -g CLUSTER -u 239.255.100.100  -m 1234

Powyższe poleceniu uruchomić instancję serwera JBoss przy następujących parametrach:

  • -c node1 – nazwa profilu jaki ma zostać uruchomiony (profili musi obsługiwać tworzenia klastrów, czyli najprościej powinien być kopią profilu all lub production
  • -b jboss1 – adres IP z którym ma zostać związana dana instancja serwera aplikacji
  • -Djboss.messaging.ServerPeerID=1 – numer dla JMS (unikalny w ramach klastra)
  • -g CLUSTER – nazwa klastra
  • -u 239.255.100.100 – adres multicastowy, który będzie używany do komunikacji między serwerami
  • -m 1234 – port adresu multicastowego

Aby dane instancje JBossa zaczęły współpracować ze sobą w ramach klastra, parametry -g, -u oraz -m muszą mieć taką samą wartość. Jak widać, nie ma tutaj miejsca na żadne uwierzytelnienie poszczególnych węzłów klastra. Jeżeli ktokolwiek będzie w stanie wpiąć maszynę do danej sieci fizycznej oraz poznać te parametry, będzie mógł się bez problemu wpiąć w klaster na równoprawnych warunkach.

Przy domyślnej konfiguracji JBossa musimy zapewnić fizyczne bezpieczeństwo naszej sieci wewnętrznej oraz przy pomocy innych narzędzi dbać o to, aby nie pojawiły się w niej żadne nie pożądane komputery. Sprawa może zacząć się komplikować, gdy zaczniemy używać klastra w sieci rozległej lub tez nie takiej, której nie ufamy w 100% czy też nie mamy nad nią pełnej kontroli.

Pozostaje wtedy zainteresować się różnymi metodami uwierzytelniania poszczególnych serwerów. Niestety, nie udało mi się znaleźć dokładnej dokumentacji na ten temat. Duża część informacji opiera się na testach oraz obejrzeniu kodu źródłowego pozwalającego na tego typu operacje.

Co trzeba wiedzieć na wstępie

Za obsługę komunikacji między poszczególnymi węzłami serwera aplikacji JBoss odpowiada biblioteka JGroups.Posiada ona szereg właściwości takich jak: automatyczne tworzeni klastra, przesyłanie wiadomości pomiędzy nimi, obsługuje zarówno protokołu UDP jak i TCP. Więcej informacji można znaleźć na stronie domowej JGroups.

Protokół transportujący wiadomości składa się z kilku różnych warstw. Każda z nich odpowiada za realizację określonych funkcji (takiej jak wykrywanie serwerów, dzielenie komunikatu na mniejsze części, łączenie go z powrotem w całości i inne). Warstwy te współpracują ze sobą. Dlatego też dodanie uwierzytelniania serwerów sprowadza się do dodania kolejnej warstwy w protokole transportującym, która będzie pilnowała czy dany komunikat może zostać przyjęty od danego serwera czy też do niego wysłany.

W przypadku serwera JBoss AS konfiguracja znajduje się w pliku: $JBOSS_HOME/server/node1/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml i to ten plik będzie trzeba edytować w celu dodania uwierzytelnienia dla grupy klastrów.

Bazową klasą używana do autentykacji jest org.jgroups.auth.AuthToken. Wszystkie moduły dziedziną po niej i rozszerzają ja o własne metody i parametry potrzebne do przeprowadzenie uwierzytelnienia. Aby włączyć dany moduł, należy w pliku jgroups-channelfactory-stacks.xml umieścić taki wpis:

83
84
85
<VIEW_SYNC avg_send_interval="10000"/>
<AUTH auth_class="klasa odpowiedzialna za uwierzytelnienie"
      parametr="wartość" />

Jedynym wymaganym tutaj argumentem jest auth_class, który wskazuje na klasę, jaka ma zostać użyta do uwierzytelnienia. Wszystkie pozostałe argumenty zostaną przekazane do tej klasy. Dlatego też ich postać jest już zależna od konkretnego modułu uwierzytelnia, należy się skonsultować z dokumentacją do każdej klasy i sprawdzić w niej jakie wartości muszą one przyjmować.

Uwierzytelnienie na podstawie adresu IP

Za uwierzytelnienie na podstawie adresu IP odpowiada klasa o nazwie FixedMembershipToken. Pozwala ona na zdefiniowanie listy adresów IP oraz numerów, które są używane przez poszczególne komputery w klastrze. Definicja wygląda następująco:

84
85
86
<AUTH auth_class="org.jgroups.auth.FixedMembershipToken"
       fixed_members_value="192.168.3.21*192.168.3.22"
       fixed_members_seperator="*"/>

Jak widać klasa ta przyjmuje dwa parametry:

  • fixed_members_value – pozwala na określenie adresów IP serwerów wchodzących w składa klastra, poszczególne adresy są rozdzielna znakiem separatora podanym w drugim parametrze, można także podać numer portu w formacie: 192.168.3.21/1234;
  • fixed_members_seperator – znak separatora, który rozdziela poszczególne adresy IP, w przykładzie znak *

Podany opis konfiguracji musi znaleźć się na wszystkich węzłach klastra. Każda instancja serwera JBoss będzie się porozumiewała tylko z tymi maszynami, które znajdują się w jej spisie.

Uwierzytelnienie na podstawie hasła

Chyba najprostsza metoda uwierzytelniania poszczególnych serwerów w klastrze: użycie hasła. Wszystkie serwery uczestniczące w klastrze muszą mieć skonfigurowane to samo hasło dostępu, na tej podstawie następuje uwierzytelnienie. Za przeprowadzenie tego testu odpowiada klasa SimpleToken i jej definicja wygląda następująco:

84
85
<AUTH auth_class="org.jgroups.auth.SimpleToken"
       auth_value="haslo_klastra"/>

Jedynym obowiązkowym parametrem w tej metodzie jest auth_value gdzie definiujemy hasło.

Uwierzytelnianie przy użyciu preshared token

Kolejny sposób uwierzytelniania przy użyciu preshared token jest udostępniony przez klasę MD5Token. Pozwala on na zdefiniowanie tokenu oraz hasła dostępu:

84
85
86
<AUTH auth_class="org.jgroups.auth.MD5Token"
       token_hash="0425823a38b591b104ca0c3fcf1f3d9d"
       auth_value="haslo_klastra"/>

Parametry token_hash i auth_value i definiują odpowiednio token (zakodowany przy użyciu MD5 lub SHA) oraz hasło. Na wszystkich węzłach klastra muszą być podane takie same wartości tych parametrów.

Uwierzytelnienie przy użyciu certyfikatu X509

Ostatnią dostępną metodą nieuwierzytelnienia poszczególnych węzłów klastra jest użycie certyfikatu X509. Za przeprowadzenie tego sposobu uwierzytelnienia odpowiada klasa X509Token. Pozwala ona na zdefiniowania miejsca z którego można pobrać certyfikat.

Przykład komendy definiującej nowy certyfikat przy użycia polecenia keytool:

keytool -genkeypair -dname "cn=JBoss Key 1, ou=JBoss, c=PL" -alias jboss -keyalg RSA -keypass haslo_klucza -keystore keystore -storepass haslo_magazynu

Poszczególne polecenia oznaczają:

  • -genkeypair – generowanie pary kluczy, prywatnego i publicznego
  • -dname "cn=JBoss Key 1, ou=JBoss, c=PL" – nazwa certyfikatu w standardzie X509
  • -alias jboss – nazwa certyfikatu na podstawie której będzie on identyfikowany w magazynie kluczy
  • -keyalg RSA – algorytm użyty do generowania kluczy
  • -keypass haslo_klucza – hasło na klucz prywatny
  • -keystore keystore – plik z magazynem kluczy
  • -storepass haslo_magazynu – hasło dostępu do pliku z magazynem kluczy

A oto definicja XML pozwalająca na użycie wygenerowanego certyfikatu:

84
85
86
87
88
89
90
<AUTH auth_class="org.jgroups.auth.X509Token"
       auth_value="haslo_klastra"
       keystore_path="keystore"
       keystore_password="haslo_magazynu"
       cert_password="haslo_klucza"
       cert_alias="jboss"
       cipher_type="RSA"/>

Znaczenie poszczególnych parametrów:

  • auth_value – hasło używane przez klastry
  • keystore_path – ścieżka do magazyny kluczy
  • keystore_password – hasło do magazyny kluczy
  • cert_password – hasło do certyfikatu
  • cert_alias – nazwa certyfikatu
  • cipher_type – typ certyfikatu

Należy pamiętać, że wszystkie węzły klastra muszą korzystać z tego samego certyfikatu.

Źródła

Tags: , , , , , , , , , , , ,

Jak uruchomić więcej niż jedną instancję serwera JBoss na jednej maszynie fizycznej?

Czasami zachodzi potrzeba uruchomienia więcej niż jednej instancji serwera JBoss na jednym komputerze, czy to do celów testowych, deweloperskich czy nawet produkcyjnych. Aby było to możliwe, należy spełnić następujące warunki:

  • każda instancja serwera musi posiadać własny profil
  • należy skonfigurować odpowiednio serwer aplikacji oraz maszynę na której go uruchamiamy

W sumie największym problem jaki się pojawia w momencie uruchamiania kolejnych instancji serwera, jest konflikt wykorzystania tych samych portów na wybranej maszynie. Sposobów rozwiązania jest kilka, niektóre wymagają modyfikacji konfiguracji maszyny fizycznej, inne jedynie modyfikacji serwera JBoss AS.

Pierwszym krokiem będzie utworzenie dwóch profili w katalogu $JBOSS_HOME/server, które będą potem wykorzystywane do uruchomienia serwera. W dalszych części przyjmę, że profile te noszą nazwy profile1 oraz profile2 i są kopią profilu default.

Dodanie kolejnych aliasów IP do interfejsów sieciowych

Najprostszą metodą poradzenia sobie z konfliktem portów jest dodanie kolejnego (kolejnych) interfejsu sieciowego, będącego aliasem to już istniejącego. Czyli po prostu przyznanie sobie kolejnego numeru IP i przypięcie do niego konkretnej instancji serwera. Może to być spokojnie kolejny interfejs lokalny (loopback), jeżeli nie chcemy mieć dostępu do serwera z poza lokalnego komputera.

Jak utworzyć kolejne interfejsy? To zależy od używanego systemu operacyjnego:

I teraz nie pozostaje zrobić nic innego, jak uruchomić JBossa. Standardowo JBoss przypina się tylko interfejsu oznaczonego jako localhost (czyli adresu 127.0.0.1) oraz uruchamiania profil default. Aby to zmienić, należy użyć odpowiednich przełączników:

  • -c – nazwa konfiguracji do uruchomienia, a naszym przypadku profile1 lub profile2;
  • -b – nr IP, który ma wykorzystać JBoss do nasłuchiwania na połączenia;

Uruchomienie serwera z konfiguracją profile1 oraz nasłuchiwaniem na adresie 127.0.0.1:

$JBOSS_HOME/bin/run.sh -c profile1 -b 127.0.0.1

Uruchomienie serwera z konfiguracją profile2 oraz nasłuchiwaniem na adresie 127.0.0.2:

$JBOSS_HOME/bin/run.sh -c profile2 -b 127.0.0.2

Po tych operacjach powinniśmy otrzymać dwa uruchomione serwery JBoss, każdy nasłuchujący na innym adresie IP, w związku z czym nie wchodzących sobie w paradę. Sprawdzić można to przy użyciu polecenia netstat:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:8083          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 0.0.0.0:51415           0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4444          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:58460         0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4445          0.0.0.0:*               LISTEN      12789/java      
...

Zmiana portów (Service Binding Manger)

Drugim rozwiązaniem problemów konfliktu portów jest ich zmiana. Można to zrobić na albo przy użyciu specjalnej usługi zwanej Service Binding Manger lub też ręcznie

Od wersji 5.0 serwera aplikacji usługa ta jest domyślnie włączona i udostępnia 4 konfiguracje portów:

  • ports-default – domyślna konfiguracja portów
  • ports-01 – dodanie do każdego portu z domyślnej konfiguracji wartości 100
  • ports-02 – dodanie do każdego portu z domyślnej konfiguracji wartości 200
  • ports-03 – dodanie do każdego portu z domyślnej konfiguracji wartości 300

Jak widać konstrukcja jest całkiem prosta, definicja tych mapowań można znaleźć w pliku $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml. Tam znajduje się zarówno definicja wszystkich domyślnych portów, jak i definicje pozostałych konfiguracji (łącznie z offsetami).

Aby uruchomić JBossa z zadanym zestawem portów, należy ustawić w JVM zmienną jboss.service.binding.set na wartość odpowiadającej jednemu ze sposobów mapowań:

$JBOSS_HOME/bin/run.sh -c profile2 -Djboss.service.binding.set=ports-01

Można także zapisać zmiany w odpowiednim pliku konfiguracyjnym, nie będzie wtedy potrzeby konfigurowania zmiennej dla JVM. Plik, który należy edytować: $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml:

17
18
19
20
21
22
23
24
25
26
<!-- Provides management tools with a ProfileService ManagementView
interface to the SBM and its components -->
<bean name="ServiceBindingManagementObject"
class="org.jboss.services.binding.managed.ServiceBindingManagementObject">
 
<constructor>
 <!-- The name of the set of bindings to use for this server -->
 <parameter>${jboss.service.binding.set:ports-default}</parameter>
 
 <!--  The binding sets -->

W linii 24 znajduje się wpis wskazujący na domyślnie użyty zestaw portów. Wystarczy zmienić wpis ports-default na jedną z wartości: ports-01, ports-02 czy ports-03 i zrestartować serwer JBossa.

A oto jak wygląda mapowanie portów po uruchomieniu dwóch serwerów:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:8180          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:25460         0.0.0.0:*               LISTEN      15787/java
tcp        0      0 0.0.0.0:32885           0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:8183          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4446          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4544          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:4545          0.0.0.0:*               LISTEN      15787/java
...

Jak widać, są uruchomione dwa procesy JVM i można zaobserwować podobne mapowania portów z różnicą 100 pomiędzy nimi.

Zmiana portów (admin-console)

W wersji 5.0 JBoss AS istnieje możliwość zmiany portów przy użyciu aplikacji admin-console. Umożliwia ona zarówno zmianę profilu, który będzie użyty podczas tworzenia konkretnych mapować, jak i modyfikację zarówno profili jak i poszczególnych portów dla różnych usług.

Binding Manager in the Admin Console

Binding Manager in the Admin Console

Czyli najprościej otworzyć Service Binding Manager, a następnie zmienić właściwość

Active Binding Set Name

. Pozostaje jeszcze tylko zrobić restart serwera i powinno działać.

Zmiana portów (ręczna)

Jeżeli z jakiś powodów nie można użyć usługi Service Binding Manager do zmiany domyślnych portów, pozostaje jeszcze możliwość ich recznej konfiguracji. W przypadku JBossa 5.1 należy otworzyć plik $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml oraz przyjrzeć się dokładnie w jaki sposób jest zdefiniowany domyślne mapowanie. W przypadku mojego pliku początek tej definicji wygląda następująco:

99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
!-- Base binding metadata that ServiceBindingStore uses to create bindings for each set -->
<bean name="StandardBindings" class="java.util.HashSet">
<constructor>
 <parameter class="java.util.Collection">
    <set elementClass="org.jboss.services.binding.ServiceBindingMetadata">
    <!-- ********************* conf/jboss-service.xml ****************** -->

    <!-- Naming Service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">Port</property>
       <property name="port">1099</property>
       <property name="description">The listening socket for the Naming service</property>
    </bean>

    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">RmiPort</property>
       <property name="port">1098</property>
       <property name="description">Socket Naming service uses to receive RMI requests from client proxies</property>
    </bean>

    <!-- Remote classloading service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=WebService</property>
       <property name="port">8083</property>
       <property name="description">Socket for dynamic class and resource loading</property>
    </bean>

...

Jak widać, każda usługa posiada zdefiniowany jakiś port. Jeżeli mamy potrzebę, to możemy ten port zmienić, zrestartować serwer i powinno działać.

Podsumowanie

Wydaje mi się, że najlepszym sposobem uruchomienia kilku instancji serwera JBoss na jednej maszynie fizycznej jest użycie oddzielnych aliasów IP dla każdej z nich. Tylko jeżeli nie jest możliwe zastosowanie takiego sposobu, można zastanowić się nad zastosowaniem usługi Service Binding Manager. Jedynie ostatecznością powinna być ręczna modyfikacja portów, na jakich nasłuchują różne usługi uruchamiane przez serwera aplikacji:

Dlaczego warto używać oddzielnych adresów IP w zależności od instancji serwera:

  • łatwiej jest skojarzyć konkretną instancje JBossa z konkretnym numerem IP, niż pamiętać na jakie usługi na pracują na których niestandardowych portach
  • łatwiej jest skonfigurować zaporę ogniową
  • jeżeli istnieje na maszynie wiele usług, rośnie prawdopodobieństwo wystąpienia konfliktu portów nawet jeżeli używamy usługi SBM
  • łatwiejsza aktualizacja serwera aplikacji (brak problemów wynikających z nadpisaniem plików konfiguracyjnych, w szczególności w przypadku ręcznej edycji numerów portów)

Powyższe opisy działa w przypadku JBossa 5.1 i 5.0, w przypadku wcześniejszych wymagana jest trochę inna konfiguracja. Zmiana domyślnego adresu IP na którym nasłuchuje serwer jest taka sama, ale w przypadku JBossa 4.2 usługa SBM nie jest domyślnie włączona. Trzeba ją włączyć samodzielnie, co wymaga edycji odpowiednich plików. Podobnie inaczej się przypisuje ręcznie porty, na których nasłuchują poszczególne usługi (należy zmodyfikować pliki konfiguracyjne poszczególnych usług). Dokładniejszy opis można znaleźć w materiałach źródłowych.

Źródła

Tags: , , , , , , , , ,