Jmx środowisko konstrukcji nowoczesnych systemów



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

Rysunek1. Podstawowe elementy architektury JMX

Serwer MBean stanowi również komponent, poprzez który tzw. agenci usług, np. monitorowania zmiany wartości atrybutu, przekroczenia wartości progowej, szeregowania zdarzeń, itp., komunikują się z obiektami MBean reprezentującymi zasoby. W modelu JMX agenci usług są także implementowani jako MBean'y i rejestrowani w serwerze MBean. W celu wyjaśnienia tej koncepcji nieco szerzej, rozważmy sytuację, w której aplikacja zarządzająca klienta chce monitorować przekroczenia wartości progowej wybranego atrybutu danego MBeana. W tym celu aplikacja ta musi utworzyć MBean reprezentujący usługę monitorowania i zarejestrować go w serwerze MBean. Następnie sama aplikacja musi zarejestrować się jako obserwator zdarzeń alarmowych generowanych przez usługę monitorowania. Zwalnia to aplikację zarządzająca z ciągłego odpytywania MBean'a, reprezentującego wybrany zasób, o wartość obserwowanego atrybutu.


Należy podkreślić, że agenci odpowiednich usług mogą być dostarczeni, w formie odpowiedniej biblioteki klas, przez producenta oprogramowania zarządzającego. W znakomity sposób ułatwia to i przyśpiesza budowę aplikacji.
Architektura JMX rozwiązuje także problem komunikacji zdalnej oraz komunikacji z różnymi systemami zarządzania. Zdalne aplikacje zarządzania, napisane w języku Java, wykonują operacje na zdalnych obiektach oraz odbierają powiadomienia za pośrednictwem ich lokalnych reprezentantów, tzw. proxy. Komunikacja pomiędzy proxy i zdalnym obiektem jest ukryta przed użytkownikiem i obsługiwana przez elementy systemowe zwane odpowiednio konektorem klienta i serwera. Elementy te zapewniają komunikację z użyciem różnych protokołów, np.: RMI, HTTP/TCP lub HTTP/SSL.
Inne aplikacje zarządzające, np. wykorzystujące HTML lub SNMP, mogą skomunikować się z agentem JMX z użyciem tzw. adaptera protokołu. Przykładowo, adapter HTML przedstawia MBean'y jako strony WWW. Adapter SNMP udostępnia MBean'y jako MIB SNMP, który odpowiada na komendy protokołu SNMP.
Dostępność oraz możliwość konstrukcji konektorów i adapterów różnych protokołów sprawia, że architektura JMX jest otwarta i umożliwia współpracę istniejących systemów monitorowania i zarządzania.



  1. Model powiadamiania

Bardzo ważnym elementem współczesnych systemów monitorowania i zarządzania, decydującym o ich skalowalności, jest model dystrybucji zdarzeń, zwany inaczej modelem powiadamiania (ang. notification model). W architekturze JMX MBean może rozgłaszać informacje o zdarzeniach do innych zainteresowanych MBean’ów oraz aplikacji zarządzających, pełniących funkcje obserwatorów. W najprostszym przypadku, pokazanym na Rys.2, obserwatorzy (tu: O1 i O2) mogą znajdować się w tej samej maszynie wirtualnej Javy, w której znajduje się MBean generujący zdarzenia. W tej sytuacji rejestracja obserwatora w wybranym MBean może odbywać się w nim bezpośrednio, albo za pośrednictwem serwera MBean. Sposób rejestracji nie wpływa na powiadomienia, które zawsze przekazywane są bezpośrednio do zainteresowanego obserwatora.



Rysunek 2. Model powiadamiania w architekturze JMX

Potencjalnie bardziej skomplikowany przypadek stanowi sytuacja, gdy obserwatorzy są zdalni, to znaczy znajdują się w różnych maszynach wirtualnych Javy, które wykonywać się mogą na różnych komputerach w sieci. Jednakże i w tym przypadku obserwatorzy są obsługiwani w identyczny sposób, a fakt ich fizycznego oddalenia pozostaje całkowicie ukryty, dzięki działaniu konektorów.

Funkcja konektora w zakresie realizacji powiadamiania sprowadza się do przekazywania żądań rejestracji od zdalnych obserwatorów do MBean'a reprezentującego wybrany zasób, oraz do zwrotnego transmitowania powiadomień. Problem polega na tym, że rozważany model powiadamiania bazuje na modelu zdarzeń w języku Java, który ograniczony jest do jednej maszyny wirtualnej. Tak więc w przypadku rejestracji zdalnego obserwatora konektor serwer musi utworzyć obserwatorów lokalnych, których zadaniem jest przekazywanie odbieranych zdarzeń do bufora, w którym oczekują na przesłanie do zdalnych obserwatorów. Zdaniem autorów, wprowadzenie takiego bufora pozwala serwerowi konektora na realizację różnych strategii wysyłania zdarzeń oraz właściwy ich dobór w zależności o wymaganej jakości obsługi.



  1. Usługi dostarczane przez agentów

Jedną z bardzo ważnych części architektury JMX stanowią agenci usług, którzy ułatwiają tworzenie aplikacji monitorowania i zarządzania. W kolejnym kroku zostaną opisane podstawowe ich funkcje.



Realizacja zapytań i filtracja




Usługa ta umożliwia łatwe wyszukiwanie (filtrację) MBean'ów po nazwie (lub jej fragmencie), albo z użyciem zapytań, tj. wyrażeń definiujących ograniczenia na wartości atrybutów MBean'ów. Wynikiem zapytania jest w obydwu przypadkach lista zarządzanych zasobów na których w kolejnym etapie przetwarzania można realizować stosowne operacje.




Dynamiczne ładowanie

Jest to usługa pozwalająca na załadowanie klasy języka Java z dowolnej lokalizacji w sieci oraz utworzenie na jej podstawie MBean'a, który następnie jest rejestrowany w serwerze MBean. Dynamiczne ładowanie pozwala rozszerzać funkcjonalność agentów oraz implementować nowe zasoby w trakcie działania systemu.



Monitorowanie

Usługa monitorowania dostarcza mechanizmu odpytywania wartości atrybutów MBean'a. Zostały zdefiniowane trzy rodzaje MBean'ów monitorowania:



  • Licznikowy – obserwujący atrybut typu całkowitoliczbowego monotonicznie rosnący.

  • Pomiarowy – obserwujący atrybut typu całkowitoliczbowy lub zmiennoprzecinkowy fluktuujący w pewnym przedziale ograniczonym przez zadane wartości progowe.

  • Zgodności ciągów znaków – obserwujący zgodność lub utratę zgodności ciągu znaków z wzorcem. W obydwu przypadkach generowane jest odpowiednie powiadomienie.



Szeregowanie

Usługa ta polega na przesyłaniu powiadomień do zarejestrowanych aplikacji w odpowiednim czasie. Powiadomienia te pozwalają z kolei na uruchomienie określonych akcji. Powiadamianie czasowe może być jednokrotne lub cyklicznie powtarzalne. Serwis czasowy zarządza listą datowanych powiadomień, wyznaczających uruchomienie odpowiedniej sekwencji akcji.



Kaskadowanie

Kaskadowanie polega na tworzeniu hierarchii agentów w ten sposób, że operacja zarządzająca może być przekazywana z danego agenta do jednego z jego podagentów. W hierarchii tej wszyscy podagenci danego agenta są widoczni w ten sam sposób, tak jakby byli zarejestrowani w agencie nadrzędnym. Agent nadrzędny ukrywa także fizyczną lokalizację podagentów. Można tworzyć hierarchie agentów o dowolnej głębokości i złożoności, jednakże tylko agent nadrzędny może manipulować swoimi podagentami, pozostając sam dla nich niewidoczny.



Wyszukiwanie

Usługa wyszukiwania umożliwia znalezienie w sieci agentów, posiadających zarejestrowany w serwerze MBean tzw. obiekt odpowiadający (responder). Usługa ta może być funkcjonalnie podzielona na dwie części:



  • Aktywne wyszukiwanie innych agentów,

  • Oczekiwanie na aktywację innych agentów.

Schemat działania aktywnego wyszukiwania został przedstawiony na Rys.3. Wyszukujący klient wysyła żądanie do grupy rozgłoszeniowej. Wszyscy agenci w tej grupie posiadający zarejestrowany obiekt odpowiadający, wysyłają w odpowiedzi informacje o konektorach i protokołach, które obsługują. Rys. 3. przedstawia wersję wyszukiwania, w której obiekty odpowiadające wysyłają odpowiedź tylko do wyszukującego klienta. Istnieje także tryb wyszukiwania, w którym odpowiedź przesyłana jest do całej grupy rozgłoszeniowej.
Oczekiwanie na aktywacje innych agentów polega na monitorowaniu w grupie rozgłoszeniowej aktywacji (bądź dezaktywacji) obiektów odpowiadających. Pozwala to na aktualizację listy aktywnych agentów.




Rysunek 3.Schemat działania usługi wyszukiwania



Relacje
Usługa relacyjna umożliwia tworzenie relacji pomiędzy zarejestrowanymi MBean'ami. Relacje te mogą być dowolnie definiowane przez użytkownika i pozwalają na realizację mechanizmu zapytań odnoszących się do wzajemnie powiązanych MBean'ów.
6. Java Dynamic Management Kit
Jedną z pierwszych komercyjnych implementacji specyfikacji JMX stanowi Java Dynamic Management Kit [2]. Jest ona w pełni zgodna z opisanymi do tej pory elementami architektury JMX, jednakże dodatkowo zawiera implementację szeregu usług związanych zapewnieniem bezpieczeństwa, oraz zespół narzędzi umożliwiających współpracę z protokołem SNMP.
Mechanizmy bezpieczeństwa Java Dynamic Management można podzielić na dwie grupy:

  • Zabezpieczenie dostępu poprzez hasło,

  • Uzależnienie wykonania operacji od kontekstu.

Pierwszy z wymienionych jest standardowym mechanizmem autentykacji wbudowanym w konektor HTTP oraz adapter protokołu HTML. Podobny mechanizm, bazujący na listach dostępu (ACL), jest także wbudowany w adapter protokołu SNMP.
Zabezpieczenie dostępu poprzez hasło nie pozwala realizować selekcji żądań pochodzących od tego samego klienta oraz przydziału praw dostępu dla każdego z nich indywidualnie. Możliwość taką zapewnia sprawdzanie kontekstu. Wszystkie żądania wykonania operacji przechodzące przez konektor bądź adapter protokołu są sprawdzane przez specjalnego agenta. Może on dokonywać filtracji żądań wykonania operacji na podstawie typu operacji, MBeana, której ona dotyczy, czy też wartości argumentów. Dodatkowo każde żądanie może być filtrowane na podstawie pola kontekst, które może zawierać hasło bądź dowolne inne dane identyfikacyjne. Schemat użycia kontekstu do filtracji żądań pokazano na Rys.4.

Rysunek 4. Uzależnienie wykonania operacji od kontekstu


Obiekt sprawdzający kontekst może być zdefiniowany przez użytkownika aplikacji. Posiada on interfejs serwera MBean i jest włączany pomiędzy konektor/adapter MBean i serwer MBean implementacji.
Narzędzia ułatwiające współpracę JDM z protokołem SNMP obejmują:

  • Budowę agenta SNMP z użyciem adaptera protokołu SNMP v1 lub v2.

  • Generację reprezentacji MIB’a protokołu SNMP w postaci MBeana.

  • Menadżer SNMP API, to jest moduł ułatwiający budowę aplikacji w języku Java zarządzających agentami SNMP.


7. Proces budowy aplikacji zarządzający w środowisku JMX
Budowa aplikacji zarządzających w środowisku JMX obejmuje cztery podstawowe etapy to jest:


  1. Instrumentacja zasobów,

  2. Projekt i budowa aplikacji agenta,

  3. Generacja proxy,

  4. Projekt i implementacja aplikacji zarządzającej.

Każdy z tych etapów wymaga podjęcia szeregu decyzji projektowych. Instrumentacja m.in. wymaga określenia, które atrybuty mają być udostępnione do zarządzania i monitorowania, jakie operacje mają być dopuszczone do wykonywania na zasobie, kiedy powinny być wysyłane powiadomienia.


Projekt aplikacji agenta wymaga ustalenia kompromisu pomiędzy złożonością zarządzanej aplikacji a złożonością agenta. Najprostszy agent składa się z serwera MBean i konektora lub adaptera protokołu. Taki agent może zmieścić się w ok. 10 liniach kodu źródłowego. Rozwiązaniem przeciwstawnym jest zlokalizowanie całej logiki zarządzania w aplikacji agenta. W wielu przypadkach najodpowiedniejszym rozwiązaniem jest użycie modelu hierarchicznego, w którym logika działania koncentruje się na szczycie hierarchii.
Generacja proxy do MBean'ów jest krokiem opcjonalnym. Ułatwia ona jednakże tworzenie kodu aplikacji zarządzającej, gdyż proxy stanowi abstrakcję zdalnego zasobu.
Aplikacja zarządzająca realizuje trzy podstawowe funkcje: zapewnia dostęp do zasobów w celu odczytu informacji, wykonuje operacje na zasobach oraz udostępnia wyniki innym aplikacjom. Dwie pierwsze z tych funkcji realizuje z użyciem serwera interfejsu MBean. Budowa tej aplikacji wymaga więc zasadniczo podjęcia decyzji o sposobie gromadzenia danych, ich wizualizacji oraz formacie prezentacji.

8. Wnioski końcowe
JMX w zdecydowany sposób porządkuje i ułatwia konstrukcję aplikacji zarządzania i monitorowania. Pełne możliwości wykorzystania tej architektury wymagają jednakże dalszych badań w zakresie zastosowania jej zaawansowanych własności takich jak:

  • Optymalizacja komunikacji na drodze dynamicznego konfigurowania konektorów,

  • Uruchamianie nowych usług i dynamiczne rozszerzanie agentów.

  • Budowa i zarządzanie hierarchią agentów.

  • Wychodzenie ze stanu upadku systemu.

Chociaż kwestie te nie są obecnie rozstrzygnięte, nie ogranicza to zastosowania JMX. Tylko bardzo duże, złożone implementacje są bowiem wstanie wykorzystać te zaawansowane własności. Należy się spodziewać, że dalszy rozwój tej klasy systemów przyniesie w niedługim czasie rozwiązanie tych problemów.
Literatura
[1] Sun Microsystems Inc., Java Management Extentions Instrumentation and Agent Specification, v.1.0 (Final Release, czerwiec 2000)

[2] Sun Microsystems Inc., Java Dynamic Management Kit 4.2 Tutorial, grudzień 2000

[3] Bruce Eckel, Thinking in Java, edycja polska, Wydawnictwo Helion, 2001

[4] Ed Roman, Mastering Enterprise Java Beans, Wiley Inc., 1999/2001; dostępna także w wersji elektronicznej ze strony http://www.theserverside.com



[5] Global Grid Forum, http://www.gridforum.org




1   2


©operacji.org 2017
wyślij wiadomość

    Strona główna