Posts Tagged apache

Monitorowanie serwera Apache przy użyciu RHQ Server – konfiguracja RHQ

Serwer RHQ umożliwia monitorowania funkcjonowania serwera WWW Apache. Konfiguracja połączenia między agentem monitorującym a Apachem nie jest jednak zbyt prosta. Trzeba nie tylko odpowiednie informacje podać w RHQ, ale również dodać dodatkowe moduły do Apache oraz je skonfigurować.

Jeżeli chcesz, aby poprawnie zadziałało Ci monitorowanie, oraz udało się wszystko skonfigurować tak jak jest to podane poniżej, napierw zapoznaj się z artykułami, w których znajdują się informacje w jaki sposób należy skonfigurować Apacha:

Konfigurację można podzielić na dwa kroki: najpierw należy dodać serwer do zasobów Apache a następnie zdefiniować (poprawić) wpisy do poszczególnych serwerów wirtualnych.

Dodanie serwera Apache do zasobów RHQ

Pierwszym krokiem będzie dodanie serwera Apache do zasobów monitorowanych. Jeżeli serwer jest już widoczny na liście, można ten punkt opuścić i od razu przejść do konfiguracji połączenia w ustawieniach serwera.

Pierwszym krokiem będzie wybór serwera (platformy) na której jest zainstalowany serwer, a następnie wybranie zakładki INVENTORY->OVERVIEW. Na dole strony znajdziemy przycisk pozwalający na dodanie nowego zasobu:

RHQ: dodanie serwera Apache

RHQ: dodanie serwera Apache

Teraz należy zdefiniować potrzebne ścieżki dostępu do poszczególnych elementów serwera (poniższe ścieżki są podane na przykładzie Debiana):

  • Server Root = /etc/apache2
    absolutna ścieżka dostępu do katalogu głównego Apacha
  • Executable Path = /usr/sbin/apache2
    ścieżka dostępu do pliku wykonywalnego serwera Apache
  • Control Script Path = /etc/init.d/apache2
    ścieżka dostępu do skryptu kontrolującego Apacha
  • Config File = /etc/apache2/apache2.conf
    ścieżka dostępu do pliku konfiguracyjnego
  • URL = http://blog.stelmisoft.pl:80/
    adres URL do jakiegoś zasobu udostępnianego przez serwer, będzie on badany w celu sprawdzenia czy serwer działa
  • SNMP Agent Host = 127.0.0.1
    konfiguracja agenta SNMP, który będzie monitorował serwer Apache (będziemy go konfigurować w dalszej części wpisu)
  • SNMP Agent Port = 1610
    port, na którym nasłuchuje agent
  • SNMP Agent Community = public
  • Error Log File Path = /var/log/apache2/error.log
    Lokalizacja pliku w którym będą znajdowały się komunikaty o błędach
  • Error Log Events Enabled = Yes
    Tworzenie nowych zdarzeń w momencie wystąpienia błędów w logu.
  • Error Log Minimum Severity = error
    Minimalny poziom ważności informacji w logu, który będzie użyty
  • Error Log Includes Pattern =  
  • Zatwierdzenie powyższych informacji umożliwi serwerowi RHQ podstawowe monitorowanie dostępności serwera Apache. Będziemy także mieli możliwość zarządzania nim (start, restart, zatrzymanie).

    Konfiguracja serwerów wirtualnych

    Jeżeli serwer Apache został wykryty popranie, to w jego zakładce INVENTORY->OVERVIEW powinny się pokazać wszystkie wykryte serwery wirtualne. Informacje te są pobrane z SNMP.

    Należy teraz zdefiniować dla każdego z tych serwerów odpowiednie pliki, w których będą się znajdowały czasy odpowiedzi serwera (tworzone przez moduł Response Time). Kolejne kroki, które trzeba wykonać:

    1. Wybieramy serwer wirtualny, w moim przypadku to będzie blog.stelmisoft.pl
    2. Otworzyć zakładkę INVENTORY->CONNECTION
    3. Nacisnąć przycisk EDIT
    4. Zmodyfikować linię Response Time Log File. Powinna ona wskazywać na miejsce przechowywania zapisów przez moduł Response Time.

    I to wszystko, po powtórzeniu tych kroków dla wszystkich serwerów powinno działać monitorowanie serwera Apache.

    Źródła

Tags: , , , , ,

Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu SNMP

Serwer RHQ może monitorować Apache, ale do uzyskania informacji o wirtualnych serwerach wy,aga instalacji modułu SNMP. Umożliwi to agentowi monitorującemu pobieranie tych informacji bezpośrednio z serwera Apache, bez potrzeby analizy plików konfiguracyjnych.

Pozostałe wpisy z tej serii to:

Aby mieć możliwość instalacji tego modułu trzeba spełnić kilka warunków:

  • Apache musi być skompilowany z obsługą modułów
  • należy skompilować moduł lub użyć plików binarnych oraz zainstalować w ramach serwera Apache
  • należy odpowiednio skonfigurować serwer tak, aby z niego korzystał

Informacje skąd można pobrać pliki źródłowe można znaleźć we wpisie: Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu Response Time.

Po dekompresji pliku connector-apache.zip pliki modułu można znaleźć w katalogu apache-snmp. Tutaj również można naleźć dwa katalogi: ze wersjami binarnymi pakietów oraz ze źródłami. Tym razem jednak mamy w źródłach skompilowane moduły dla różnych wersji serwera Apache oraz dla architektur intelowskich 32 i 64 bitowych.

Kompilacje ze źródeł jest opisana w pliku apache-snmp/sources/README.txt, w praktyce powinno wystarczyć wywołanie polecenia build_apache_snmp.sh.

$ cd apache-snmp/sources
$ ./build_apache_snmp.sh 2.0 /usr/bin/apxs2

Jednak z moim przypadku kompilacja się nie powiadała. Na szczęście w tym przypadku są dostępne już skompilowane wersje modułów z których można skorzystać.

Czyli trzeba moduły rozkompresować:

$ cd apache-snmp/binaries
$ unzip snmp_module-x64-linux-apache2.2.zip

Zostanie utworzony katalogu snmp_module_2.2 a w nim niezbędne pliki konfiguracyjne oraz z modułami. Moduły dla serwera Apache znajdują się w katalogu module, czyli kopiujemy je teraz do odpowiedniej lokalizacji:

# cd snmp_module_2.2
# mkdir -p /usr/local/lib/apache2/modules
# cp module/*.so /usr/local/lib/apache2/modules/

Kopiujemy plik konfiguracyjny modułu:

# mkdir -p /etc/apache2/snmpd/conf
# cp conf/snmpd.conf /etc/apache2/snmpd/conf

W domyślnej konfiguracji moduł SNMP nasłuchuje na przychodzące połączenia od klientów na porcie 1610 na wszystkich interfejsach sieciowych. Ponieważ w naszym przypadku klientem będzie agent monitorujący działający na maszynie lokalnej, można otworzyć jedynie ten port na interfejsie localhost. Czyli należy w pliku /etc/apache2/snmpd/conf/snmpd.conf zmienić wpis agentaddress na taki:

34
agentaddress 1610@127.0.0.1

Należy jeszcze utworzyć specjalny katalog na pliki tworzone przez moduł:

# mkdir -p /var/lib/apache2/snmpd/var

Tworzymy plik /etc/apache2/mods-available/snmpd.load ładujący moduł SNMP do serwera Apache:

1
2
LoadModule snmpcommon_module /usr/local/lib/apache2/modules/libsnmpcommon.so
LoadModule snmpagt_module /usr/local/lib/apache2/modules/libsnmpmonagt.so

Teraz tworzymy plik konfigurujący moduł /etc/apache2/mods-available/snmpd.conf:

1
2
SNMPConf /etc/apache2/snmpd/conf
SNMPVar /var/lib/apache2/snmpd/var

Ostatnim krokiem będzie włączenie modułu:

# a2enmod snmpd

Aby moduł SNMP działał poprawnie, muszą zostać precypitynie zdefiniowane nazwy serwerów wirtualnych. W nazwie musi znaleźć się nie tylko nazwa tego serwera, ale także port na którym serwer Apache będzie nasłuchiwał. Czyli odpowiedni wpis w definicji serwera wirtualnego musi mieć następującą postać:

1
2
3
4
<VirtualHost *:80>
        ServerName blog.stelmisoft.pl:80
        ....
</VirtualHost>

Teraz pozostaje restart serwera Apache i sprawdzenie czy wszystko zadziała:

# /etc/init.d/apache2 restart

Źródła

Tags: , , , , , ,

Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu Response Time

Serwer RHQ może monitorować Apache, ale uzyskał maksymalną ilość informacji o czasach jego odpowiedzi konieczna jest instalacja dodatkowego modułu Apache Response Time. Moduł ten będzie zapisywał w specjalnym pliku logu dodatkowe informacje pomocne w monitorowaniu.

Pozostałe wpisy z tej serii to:

Aby mieć możliwość instalacji tego modułu trzeba spełnić kilka warunków:

  • Apache musi być skompilowany z obsługą modułów
  • należy skompilować moduł oraz zainstalować w ramach serwera Apache
  • należy odpowiednio skonfigurować serwer tak, aby z niego korzystał

Pozostaje jeszcze jedna kwestia, skąd można pobrać te moduły Znam następujące miejsca:

  • Nie udało mi się znaleźć odpowiedniego poliku w wersjach społecznościowych serwera RHQ czy też Jopr.
  • Są one dostarczane przez Red Hata razem z dystrybucją serwera JON 2.3.1, ale żeby je uzyskać trzeba mieć zawartą odpowiednią umową z Red Hatem. Będą one wtedy znajdować się w pliku connector-apache.zip razem z zainstalowanym agentem. Można także je znaleźć w w tym miejscu: jon-server-2.3.1.GA/jbossas/server/default/deploy/rhq.ear.rej/rhq-downloads/connectors/connector-apache.zip.
  • Bardzo możliwe, ze moduły te są zawarte w produkcie SpringSource ERS, ale nie sprawdzałem tego

Ja pobrałem wersje dystrybuowaną wraz z serwerem JON 2.3.1. W dostarczanych źródłach nie ma niestety informacji na jakiej licencji są one rozprowadzane.

Kompilacja modułu mod_rt.so

Po rozpakowaniu pliku connector-apache.zip pliki tego modułu będą się znajdowały się w katalogu apache-rt. Wewnątrz tego katalogu możemy znaleźć katalog z plikami binarnymi modułu przeznaczonymi dla Apache 2 i chyba dla w wersji dla Windowsa (chyba to dlatego, że sam moduł ma rozszerzeniowy so). W związku z tym, trzeba będzie skompilować ten moduł i ręcznie go zainstalować w ramach serwera Apache.

Pierwszym krokiem będzie instalacja odpowiednich dodatkowych pakietów, niezbędnych do przeprowadzenia kompilacji:

aptitude install apache2-dev gcc autoconf automake

Teraz nie pozostaje nic innego jak skompilować moduł poprzez wywołanie skryptu build_apache_module.sh. Jako ego parametry podajemy wersję serwera Apache dla którego tworzymy moduły oraz ścieżkę dostępu do polecenia apxs.

$ cd apache-rt/sources
$ ./build_apache_module.sh 2.x /usr/bin/apxs2

Po kompilacji moduł można znaleźć w tym miejscu: apache2.x/.libs/mod_rt.so.

Instalacja modułu mod_rt.so w serwerze Apache

Moduły Apache, które są instalowane z pakietów znajdują się w katalogu /usr/lib/apache2/modules. Można również tam umieścić skompilowany moduł i korzystać z niego tak i z innych modułów serwera. Ja proponuję jednak umieść ten moduł w wydzielonym katalogu /usr/local/lib/apache2/modules. Myślę, że lepiej nie mieszać ze sobą plików pochodzących z pakietów i kompilowanych ze źródeł samodzielnie.

# mkdir -p /usr/local/lib/apache2/modules
# cp apache2.x/.libs/mod_rt.so /usr/local/lib/apache2/modules

Teraz plik ładujący moduł /etc/apache2/mods-available/rt.load:

1
LoadModule  rt_module  /usr/local/lib/apache2/modules/mod_rt.so

Plik z konfiguracją modułu /etc/apache2/mods-available/rt.conf:

1
LogFormat  "%S"  rt_log

I włączenie modułu w serwerze Apache:

# a2enmod rt

Pozostaje teraz jeszcze skonfigurowanie wszystkich serwerów wirtualnych tak, aby logowały dodatkowe informacje przy użyciu tego modułu. Należy w tym celu dodać w w definicji każdego serwera następujący wpis:

1
2
3
4
5
6
<VirtualHost *:80>

        .......
        CustomLog  /var/log/apache2/access.NAZWA_SERWERA_rt.log rt_log

</VirtualHost>

W podanym pliku będą zapisywane informacje o czasach odpowiedzi, które potem zostaną odpowiednio zinterpretowane przez serwer RHQ. Należy dla każdego serwera zdefiniować oddzielny plik. Będzie on nam potrzeby podczas konfiguracji serwera RHQ pod koniec wpisu.

Teraz nie pozostaje nic innego jak zrestartować serwer i sprawdzić powiedzie się jego uruchomienie i czy informacje są odkładane we wskazanych przez nas plikach.

Źródła

Tags: , , , , , ,

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