Projekt inżynierski podręcznik użytkownika

Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Informatyki, Eletroniki i Telekomunikacji Katedra Informatyki Projekt inżynierski podręcznik użytkownika Platforma udostępniająca skalowalną komunikację w środowisku rozproszonym Konrad Tendera, Jarosław Janik Tomasz Hankus Opiekun: dr inż. Tomasz Szydło Kraków 2013

2 1. O produkcie OSGi jest technologią, umożliwiającą wprowadzenie modularności do budowanych aplikacji i systemów na zupełnie nowym poziomie. Uzyskuje się ją poprzez system zarządzania modułami. Moduł to zgrupowanie fragmentów kodu, który udostępnia pewne usługi może to być pojedyncza klasa, pakiet, a nawet cały system. Rozbicie na moduły pozwala podzielić aplikację na szereg fragmentów, w którym każdy odpowiada za daną funkcjonalność. Z kolei każdy moduł może być niezależną jednostką lub częścią innego większego modułu. System zarządzania jakim jest OSGi pozwala na szybką wymianę małej części większej struktury bez konieczności ingerencji w inne jednostki. Po uruchomieniu platformy OSGi użytkownik może dowolnie zarządzać dostępnymi modułami. Niestety może korzystać jedynie z usług zarejestrowanych w tym kontenerze. Niniejsza aplikacja wprowadza komunikację między kontenerami, dodając możliwość korzystania ze zdalnych usług. Dzięki scentralizowanemu repozytorium każdy zarejestrowany kontener może korzystać z serwisów zarejestrowanych w innych kontenerach. Aplikacja zbudowana jest z 3 głownych modułow: Core - zarządza usługami w kontenerze, DBManager - odpowiada za komunikację z repozytorium bazy danych, Distribution - obsługuje komunikację między kontenerami. Podręcznik ten opisuje: instalację i konfigurację kontenera Apache Karaf, wdrożenie bazy danych MongoDB w formie klastra, wdrożenie serwera komunikacji RabbitMQ w formie klastra, sposób konfiguracji DBManagera, aby mógł połączyć się z serwerem bazodanowym, sposób konfiguracji Distribution, aby mógł połączyć się z serwerem RabbitMQ, uruchomienie przykładowego bundla w oparciu o środowisko uruchomieniowe Apache Karaf. Wymagania środowiskowe Do poprawnego działania aplikacji potrzebne są: Java Runtime Environment (JRE) w wersji 1.7 lub nowszej, środowisko uruchomieniowe dla modułów oparte na implementacji OSGi Equinox, dla maszyn przygotowanych do instalacji MongoDB odblokowane następujące porty: 27017 - port, na którym przyjmowane będą połączenia,

3 28017 - port do udostępnienia statusu przez sieć (Web UI) (opcjonalnie), dla maszyn przygotowany do instalacji serwera RabbitMQ odblokowane następujące porty: 5672 - port, na którym serwer nasłuchuje na komunikaty przychodzące, 5671 - port do połączenia zabezpieczonego protokołem SSL z wymianą certyfikatów (opcjonalnie). 2. Konfiguracja zewnętrznych systemów W tej sekcji przedstawione zostały kroki potrzebne do przygotowania zewnętrznych systemów wymaganych do poprawnego działania platformy. 2.1. Instalacja środowiska uruchomieniowego Karaf Pliki wykonywalne dostępne są na podstronie fundacji Apache, dotyczącej projektu Karaf[1]. Dostępne są także źródła programu, jeśli ktoś woli samemu dokonać kompilacji w celu lepszej optymalizacji. Przewodnik ten skupia się na przygotowanych przez producenta gotowych plikach binarnych. Wymagana jest wersja 2.3.0 lub nowsza. Po ściągnięciu ze strony pliku dla systemu operacyjnego Linux dokonujemy jego rozpakowania (w przypadku wersji 2.3.0): $ tar -zxvf apache-karaf-2.3.0.tar.gz Po rozpakowaniu środowisko uruchomieniowe jest prawie gotowe do pracy. Można wyróżnić w nim 3 główne katalogi: bin - przechowywane są w nim wszystkie pliki binarne. Najważniejszym z nich jest plik wykonywalny karaf, za pomocą którego uruchamiane jest całe środowisko i konsola, dzięki której możemy wykonywać operację na bundlach. Aby je uruchomić w terminalu z katalogu bin wpisujemy: $./karaf etc - przechowywane są w nim wszystkie pliki konfiguracyjne, deploy - folder, który jest nadzorowany przez Apache Karaf i gdy tylko pojawią się w nim bundle w formacie JAR, to zostają od razu wystartowane. Oczywiście dzieje się tak, gdy wszystkie zależności modułu zostały spełnione. Platforma komunikacji opiera się na implementacji specyfikacji OSGi Equinox, przez co należy zedytować plik konfiguracyjny etc/config.properties. Znajdujemy w nim linikę, wskazującą wykorzystywany framework i modyfikujemy ją w następujący sposób: karaf.framework=equinox

4 Jeśli chcemy skorzystać z udostępnionego przez platformę systemu logowania należy dodać do pliku konfiguracyjnego etc/system.properties linikę, opisującą zmienną środowiskową Javy, wskazującą położenie pliku konfiguracyjnego logback. Wskazane jest umieszczenie go w folderze etc/. W tym przypadku dodana właściwość będzie wyglądać następująco: logback.configurationfile=${karaf.home}/etc/logback.xml Aby ułatwić pracę w środowisku uruchomieniowym Apache Karaf warto jest zainstalować webową wersję panelu konfiguracyjnego. Aby tego dokonać należy w konsoli Apache Karafa wpisać następującą komendę: root@karaf> features:install webconsole Nastęnie w przeglądarce należy umieścić poniższy URL, aby dostać się do panelu konfiguracyjnego: http://localhost:8181/system/console Aby się zalogowac należy użyć domyślnych wartośći: użytkownik: karaf hasło: karaf Po więcej informacji należy sięgnąć do dostępnego na stronie domowej projektu podręcznika[2]. 2.2. Wdrożenie serwera komunikacji RabbitMQ w klastrze Zawarta tutaj instrukcja powstała na podstawie oficjalnej dokumentacji RabbitMQ[3]. 2.2.1. Wstęp Poniżej przedstawiona instrukcja opisuje instalację serwera RabbitMQ na 4 węzłach, które nazwiemy odpowiednio: rabbit1, rabbit2, rabbit3, rabbit4, a ich adresy będą następujące: 150.156.205.150, 150.156.205.151, 150.156.205.152, 150.156.205.153. Jeśli instrukcja nie stanowi inaczej, wszystkie polecenia należy wykonać na każdym z węzłów klastra. Instalację rozpoczniemy od stworzenia konta użytkownika, któremu nadamy prawa do uruchamiania serwera. Należy jako root wydać następujące polecenia: # addgroup rabbitmq # adduser rabbit --ingroup rabbitmq 2.2.2. Pobieranie i instalacja serwera RabbitMQ Ze strony domowej RabbitMQ[5] ściągamy interesującą nas wersję. Istnieją wersje przeznaczone dla konkretnych systemów operacyjnych, na przykład Debian/Ubuntu, Fedora, Windows, które umożliwiają szybką instalację, lecz poniższa instrukcja będzie dotyczyć

5 instalacji działającej na każdym systemie bez wględu na to jaki system pakietów jest używany, a przetestowana została na systemie Ubuntu Server 12.04.1 TLS 32 bit. Pierwszym krokiem jest ściągnięcie aktualnej wersji archiwum. Mozna to zrobic używając polecenia: $ wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.0.1/rabbitmq-servergeneric-unix-x.tar.gz Kolejnym krokiem jest rozpakowanie ściągnietego archiwum poleceniem: $ tar -zxvf rabbitmq-server-generic-unix-x.tar.gz gdzie X zastępujemy numerem wersji, np. 2.7.0. Przed przystąpieniem do dalszych kroków należy się upewnić, że posiadamy najnowszą wersję Erlanga. Można to wykonać wpisując polecenie erl do konsoli. Spowoduje to uruchomienie powłoki Erlang oraz wyświetlenie dodatkowo informacji o posiadanej wersji: Erlang R14B04 (erts-5.8.5) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll :false] Jeżeli zamiast uruchomienia powłoki otrzymamy informację o tym, że komenda nie została znaleziona należy zainstalować najnowszą wersję Erlanga. Większość obecnych systemów operacyjnych umożliwia to za pośrednictwem wbudowanego repozytorium pakietów. Dla przykładu we wspomnianym już Ubuntu Server należy wydać polecenie: $ sudo apt-get update && sudo apt-get install erlang które dodatkowo zainstaluje wszystkie niezbędne zależności oraz pakiet erlang-ssl potrzebny do skonfigurowania połączenia SSL z wymianą certyfikatów w serwerze RabbitMQ. Na tym etapie można już uruchomić serwer z domyślną konfiguracją używając dowolnego użytkownika. Należy przejść do katalogu, do którego rozpakowane zostało archiwum oraz użyć polecenia: $./sbin/rabbitmq-server Ze względu, że użyta została domyślna konfiguracja wszystkie pliki tymczasowe tworzone są w aktualnym katalogu. Nie jest porządane, aby każdy mógł włączyć serwer RabbitMQ, dlatego konieczna jest dalsza konfiguracja. Jako użytkownik root należy stworzyć katalog, w którym umieszczone zostaną pliki binarne instalacji i dowiązanie symboliczne, które ułtawi pracę i ewentualną zmianę wersji: # mkdir -p /usr/rabbitmq-x # ln -s /usr/rabbitmq-x /usr/rabbitmq Nastepnie należy przenieść rozpakowane pliki do nowo stworzonego folderu i zmienić ich właściciela (na użytkownika rabbit) poleceniem (również z konta użytkownika root): # mv -T rabbitmq_server-x/ /usr/rabbitmq-x # chown -R rabbit:rabbitmq /usr/rabbitmq

6 W celu łatwiejszego zarządzania (uruchamiania, wyłączania, wykonywania komend) jako użytkownik rabbit trzeba dodać do pliku.bashrc w katalogu domowym tego użytkownika następującą linię: PATH=$PATH:/usr/rabbitmq/sbin Należy również dodać zmienną środowiskową RABBITMQ_HOME. Można to zrobić poprzez dopisanie (jak powyżej) w pliku /.bashrc użytkownika rabbit następującej linii: export RABBITMQ_HOME=/usr/rabbitmq 2.2.3. Konfiguracja i uruchomienie Pierwszym krokiem do wprowadzenia niestandardowej konfiguracji serwera jest utworzenie niezbędnych katalogów, które będą podawane jako parametry (katalogi tworzymy z poziomu użytkownika root): # mkdir -p /var/rabbitmq/{log,lib/mnesia} # chown -R rabbit:rabbitmq /var/rabbitmq Następnie (już jako użytkownik rabbit, a nie root) tworzymy plik konfiguracyjny w lokalizacji /usr/rabbitmq/etc/rabbitmq/rabbitmq-env.conf. Plik ten nie może znajdować się w innej lokalizacji niż podana i zawierać on będzie wszystkie zmienne środowiskowe, które będą eksportowane w momencie uruchamiania serwera. Dodajemy w nim następujące wpisy: RABBITMQ_CONFIG_FILE=$RABBITMQ_HOME/etc/rabbitmq/rabbitmq.config #tutaj przetrzymywana jest konfiguracja RABBITMQ_MNESIA_BASE=/var/rabbitmq/lib/mnesia RABBITMQ_LOG_BASE=/var/rabbitmq/log NODENAME=rabbit@rabbitX # gdzie X jest jest cyfra od 1-4 w naszym przypadku. Pole to jest opcjonalne, jednak zmieniamy domyslna konfiguracje dla przejrzystego pokazania dalszych krokw. Wszystkie pozostałe zmienne pozostawiamy z wartościami domyślnymi. Należy jeszcze stworzyć plik rabbitmq.config: $ touch /usr/rabbitmq/etc/rabbitmq/rabbitmq/rabbitmq.config Po takim skonfigurowaniu serwera możemy go włączyć używając użytkownika rabbit i wykonując komendę: $ rabbitmq-server -detached opcja -detached odpowiada za uruchomienie serwera w tle. Na tym etapie posiadamy czystą instalację serwera RabbitMQ działającego na pojedynczej maszynie. W dalszych rozdziałach znajduje się konfiguracja wersji klastrowej oraz pluginu, dzięki któremu możemy monitorować pracę serwera z poziomu przeglądarki.

7 2.2.4. Konfiguracja wersji klastrowej Opis konfiguracji został stworzony na podstawie oficjalnej dokumentacji RabbitMQ[4]. Każdy z węzłów może być węzłem RAM lub dyskowym (domyślny w przypadku pojedynczych węzłów). Oznacza to, że niektóre z metadanych są przetrzymywane w pamięci RAM lub na dysku. Z oczywistych względów pierwszy typ zapewnia większą wydajność, ale zalecane jest, aby w każdym klastrze był minimum jeden węzeł dyskowy. Pierwszym krokiem, aby skonfigurować serwer RabbitMQ w wersji klastrowej jest konfiguracja zawartości pliku /var/rabbitmq/lib/.erlang.cookie tak, aby na każdym węźle wchodzącym w skład klastra była ona taka sama. Plik ten zawiera ciąg znaków alfanumerycznych o dowolnej długości. Najlepszym i zarazem najłatwiejszym rozwiązaniem jest wygenerowanie zawartości pliku na jednym węźle i skopiowanie na pozostałe (na przykład przy użyciu komendy scp). Jeżeli zawartość wspomnianych plików jest już jednakowa na wszystkich węzłach możemy przystąpić do łączenia ich w jeden klaster. Na każdym z węzłów (oprócz rabbit1 ) należy wykonać następujące komendy: $ rabbitmqctl stop_app $ rabbitmqctl join_cluster --ram rabbit@rabbit1 $ rabbitmqctl start_app Opcja ram oznacza, że dany węzeł będzie węzłem typu RAM. Po wykonaniu tych komend na wszystkich węzłach zalecane jest (a przynajmniej tak okazało się podczas konfiguracji) żeby ponownie wyłączyć oraz włączyć aplikację na każdym z węzłów poleceniami: $ rabbitmqctl stop_app $ rabbitmqctl start_app Dla sprawdzenia czy cały klaster został utworzony należy wykonać na dowolnym węźle polecenie: $ rabbitmqctl cluster_status Przy założeniu, że węzły rabbit1 oraz rabbit2 są węzłami dyskowymi, a rabbit3 oraz rabbit4 węzłami RAM oraz polecenie zostało wydane na węźle rabbit2 wynik powinien wyglądać następujaco: [{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]},{ram,[rabbit@rabbit3, rabbit@rabbit4]}]}, {running_nodes,[rabbit@rabbit2]}] Lista kilku przydatnych poleceń: rabbitmq-server -detached - uruchomienie serwera w tle rabbitmqctl stop_app - zatrzymuje aplikację RabbitMQ rabbitmqctl start_app - uruchamia aplikację RabbitMQ rabbitmqctl reset - przywraca konfigurację domyślną serwera

8 rabbitmqctl cluster_status - wyświetla stan klastra rabbitmqctl change_cluster_node_type ram/disc - zmienia typ węzła na RA- M/dyskowy Materiały źródłowe [1] Lista dostępnych archiwów apache karaf. http://karaf.apache.org/index/ community/download.html. [2] Podręcznik projektu apache karaf. http://karaf.apache.org/manual/latest-2.2. x/quick-start.html. [3] Dokumentacja projektu rabbitmq. http://www.rabbitmq.com/documentation. html. [4] Opis konfiguracji wersji klastrowej serwera rabbitmq. http://www.rabbitmq.com/ clustering.html. [5] Strona pobierania serwera rabbitmq. http://www.rabbitmq.com/download.html.