Jmx środowisko konstrukcji nowoczesnych systemów



Pobieranie 152,24 Kb.
Strona1/2
Data24.10.2017
Rozmiar152,24 Kb.
  1   2

JMX - środowisko konstrukcji nowoczesnych systemów

monitorowania i zarządzania

Aleksander Laurentowski, Krzysztof Zieliński


{al,kz}@ics.agh.edu.pl

Katedra Informatyki

Akademia Górniczo-Hutnicza

Al. Mickiewicza 30

30-059 Kraków



  1. Wprowadzenie

Zagadnienia zarządzania i monitorowania aplikacji rozproszonych leżą w centrum uwagi zarówno operatorów telekomunikacyjnych, jak i dostawców usług sieciowych oraz firm produkujących oprogramowanie. Pojęcie aplikacji rozproszonej obejmuje oprogramowanie systemowe urządzeń aktywnych w sieci, usługi sieciowe, oraz aplikacje zorientowane na pewne typowe zastosowania takie jak handel elektroniczny, usługi finansowe i bankowe jak czy też zastosowania naukowe jak np. obliczenia dużej skali realizowane na klastrach komputerów w tzw. modelu gridowym [5]. Na obecnym etapie rozwoju tych systemów dominującym modelem oprogramowania jest model obiektowy, coraz wyraźniej ewoluujący w kierunku modelu komponentowego [4]. Sprawia to, że wszystkie składowe monitorowanego, bądź zarządzanego systemu reprezentowane są przez obiekty oprogramowania, a funkcje monitorowania/zarządzania sprowadzają się do obserwacji lub wymuszania zmian stanów atrybutów obiektów, powiązań (relacji) między obiektami lub śledzenia wykonania ich metod.


Szczególne znaczenie w budowie tych systemów zajmuje język Java. Wynika to nie tylko z wielu zalet tego języka manifestujących się na etapie tworzenia i wykonania kodu [3], lecz także z istnienia szeregu konsorcjów przemysłowych wspierających rozwój standardowych interfejsów programowych (API) w tym języku, dla określonych dziedzin zastosowań, które wcześniej zdominowane były przez produkty różnych firm, nie zawsze ze sobą współpracujące. W tym kontekście opracowanie specjalnego API dla monitorowania i zarządzania aplikacji rozproszonych, pod nazwą JMX (Java Management Extension) [1], było naturalnym krokiem rozwoju tej klasy systemów.
Przedmiotem niniejszego artykułu jest zwięzłe omówienie specyfikacji JMX oraz jej pierwszej komercyjnej implementacji, opracowanej przez firmę Sun Microsystems pod nazwą Java Dynamic Management. Celem tego artykułu jest przedstawienie nowych koncepcji w zakresie konstrukcji nowoczesnego oprogramowania do monitorowania i zarządzania, spójnych z linią rozwojową współczesnych systemów, dostosowanego do wymagań aplikacji mobilnych, o dynamicznie zmiennej konfiguracji oraz systemów gridowych.



  1. Wymagania oprogramowania systemów monitorowania i zarządzania

Technologia JMX wnosi szereg istotnych zmian w zakresie koncepcji oprogramowania systemów monitorowania i zarządzania. Klasyczne systemy zarządzania sieciami są zazwyczaj dużymi scentralizowanymi aplikacjami monitorującymi zasoby poprzez bezpośrednie sterowanie reprezentujących ich agentów. Agent wykonuje komendy, zbiera dane oraz odczytuje stany zasobu. Jest on zazwyczaj usytuowany w pobliżu kontrolowanego przez niego zasobu i nie jest wyposażony w inteligencję pozwalającą mu samodzielnie podejmować decyzje. Rola agenta w tych systemach ogranicza się do wykonania operacji zleconych przez zarządzający system centralny.


W odróżnieniu od tego podejścia JMX dostarcza usług zarządzania realizowanych bezpośrednio na poziomie zasobów. W tym celu agenci są wyposażeni w inteligencję umożliwiającą im autonomiczne działanie. Zwalnia to aplikację zarządzającą od rutynowych zadań takich jak np. odpytywanie o stan, co redukuje obciążenie sieci i zwiększa skalowalność systemu.
Patrząc na istniejące systemy zarządzania z szerszej perspektywy uwidacznia się ich zależność od różnych protokołów komunikacji oraz technologii implementacji. Stawia to w trudnej sytuacji twórców oprogramowania, którzy muszą wybrać jedną z nich, bądź zdecydować się na implementacje kilku, aby zaspokoić wymagania rynku.
JMX wprowadza standardowy interfejs do zarządzanych zasobów, umożliwiając użycie dowolnej technologii budowy aplikacji zarządzających. Aplikacje te mają bowiem zapewniony dostęp do zasobów pod warunkiem, że komunikują się z nim poprzez agenta JMX. Ponadto, JMX udostępnia rozproszony model zarządzania, który jest niezależny od protokołu komunikacji. Oznacza to, że aplikacja bazuje na wykorzystaniu określonego API, a nie właściwościach określonego protokołu.
Dodatkowo każda implementacja JMX z definicji dostarcza komponentów do instrumentacji systemów, zapewniających wsparcie dostępu do ich zasobów, oraz elastyczną architekturę rozpraszającą funkcje zarządzania, które mogą być rozszerzane w czasie pracy systemów sieciowych zorientowanych na usługi (ang. service-driven). W systemach tych udostępniane są dowolne usługi, które mogą być dynamiczne tworzone i ładowane w trakcie działania systemu, wtedy kiedy są rzeczywiście potrzebne. Oznacza to, że także funkcje monitorowania i zarządzania muszą posiadać tą własność. JMX spełnia te wymagania w całej rozciągłości.


  1. Architektura i komponenty JMX

JMX posiada trójwarstwową architekturę złożoną z:



Aktualna specyfikacja JMX (v.1.0) definiuje funkcjonalność i interfejsy tylko dwóch niższych poziomów architektury systemów zarządzania, to jest poziomu instrumentacji i agentów. Specyfikacja poziomu trzeciego ogranicza się do opisu podstawowych usług i ich interakcji z pozostałymi dwoma poziomami.


Zgodnie ze specyfikacją JMX, zasoby są widziane poprzez interfejs zarządzania, to jest zbiór atrybutów, operacji i powiadomień (ang. notifications), do których aplikacja zarządzająca ma dostęp. Instrumentacja zasobu sprowadza się do konstrukcji obiektu Java reprezentującego interfejs zarządzający. Podstawowymi komponentami poziomu instrumentacji są: (i) takie właśnie zarządzalne obiekty zwane MBean (Managed Bean), (ii) model powiadamiania, oraz (iii) metaklasy opisujące budowę MBean'ów.
MBean jest podstawową cegiełką używaną w procesie instrumentacji zasobów, zgodną ze specyfikacją JMX. Jeśli zasób przeznaczony do zarządzania lub monitorowania jest obiektem Javy, to sam może stanowić MBean. Często jednak MBean jest obiektem Java reprezentującym zasób, który jest fizycznie odmiennej natury, np. jest interfejsem urządzenia aktywnego sieci. Zwłaszcza do tego celu dedykowany jest specjalny typ MBean'ów, tzw. MBeany modelujące (ang. model MBeans). Twórca interfejsu MBean'a określa, które atrybuty i operacje będą dostępne dla aplikacji zarządzających. Zakłada się, że producenci sprzętu mogą dostarczać MBean'y dla swoich urządzeń, przystosowując je w ten sposób do bezpośredniego włączenia do systemu zarządzania zbudowanego zgodnie z architekturą JMX.
Z punktu widzenia organizacji przetwarzania operacji, JMX wykorzystuje model klient-serwer. Agent jest w nim odpowiedzialny za przetwarzanie wywołań od dowolnej liczby klientów (aplikacji zarządzających), żądających dostępu do zasobów udostępnianych przez agenta. Jego funkcja sprowadza się zatem do zbierania wywołań operacji oraz ich dystrybucji do obiektów MBean i zwrotnego przekazywania odpowiedzi. To agent zatem jest odpowiedzialny za komunikację i transmisję danych, jednocześnie zwalniając zarządzane zasoby z tej czasochłonnej funkcji.
W architekturze JMX centralnym komponentem agenta jest tzw. serwer MBean (ang. MBean server). Jest to rejestr obiektów MBeans, które są reprezentowane przez danego agenta i to właśnie on implementuje standardowy interfejs do zarządzania zasobami. Klient, korzystając z mechanizmów introspekcji, może zażądać definicji interfejsu wybranego obiektu MBean, a następnie na jej podstawie sformułować wywołanie operacji odczytu atrybutów obiektu, zmiany stanu obiektu, lub zarejestrować się jako obserwator określonego zdarzenia.
P
odstawowe elementy architektury JMX zostały pokazane na Rys.1.


  1   2


©operacji.org 2017
wyślij wiadomość

    Strona główna