Problem z AdminServerem OE12

Chyba każdy użytkownik OpenEdge’a miał lub miewa problemy z AdminServerem – centralną usługą do zarządzania innymi procesami OE. Problemy te mogą być różnej natury i różne są sposoby radzenia sobie z nimi (np. zmiana portu, restart usługi czy całego systemu itd).

Ja opiszę inny problem, który może pojawić się dla OE 12.2 i wyższej, co jest związane z instalacją Javy, która jest wymagana podczas instalacji OE. Miałem ostatnio taki właśnie problem dla OE 12.8.3 i wykorzystam go aby pokazać jak sobie radzić w takiej sytuacji tym bardziej, że mam już sygnały od Was, że macie podobny problem.

Po pierwsze, AdminServer pracuje, co możemy sprawdzić prostą komendą proadsv -query.

Problem pojawia się w środowisku OE Explorer/OE Management gdzie proces jest widoczny jako Offline a dostęp do niego zastrzeżony (Access Denied). Z tego powodu nie możemy również zarządzać innymi zasobami OE z poziomu tego środowiska.

Od wersji OE 12.2 instalator tworzy usługę Fathom_12.x z danymi uwierzytelniania LOCAL SERVICE zamiast LOCAL SYSTEM (ze względu na bezpieczeństwo i obsługę Java 11 dla serwera WWW Tomcat). Te uprawnienia mogą być niewystarczające i musimy jest zmienić. Wchodzimy do ustawień dla zdalnego AdminServera (od 12-tki każdy AdminServer jest zdalny).

Wybieramy Edit.

I podajemy login i hasło administratora systemu operacyjnego.

Po zmianie AdminServer jest już Online.

Na koniec trzeba pamiętać, że przy każdej zmianie hasła do systemu (czasem jest ona wymuszona co jakiś czas) zaktualizować je także dla AdminServera.

OE Management

OpenEdge Management (OEM), następca Fathom Management, jest dobrze znany administratorom baz danych od wielu lat. Jego zubożona wersja, OpenEdge Explorer, jest dołączana darmowo do licencji serwera baz danych. Jest więc narzędziem bardzo popularnym i ze względu na interfejs webowy, stosowanym na każdej platformie. Postanowiłem więc cofnąć się do tego produktu i napisać o kilku kwestiach, co do których pojawiają się pytania i niejasności.

O OE Explorer pisałem już tutaj.

Przypomnijmy za dokumentacją OpenEdge przykładowe konfiguracje w jakich może pracować OEM. Pierwsza, gdy wszystkie komponenty OEM znajdują się na jednej maszynie przedstawia poniższy rysunek.

Z punktu widzenia monitorowania mamy dwa rodzaje baz: baza zarządzana (managed database), taka która rejestruje się i jest zarządzana przez AdminServer oraz baza skryptowa (scripted database) jest to baza nie zarządzana przez AdminServer – w tym  przypadku trzeba na maszynie zdalnej trzeba wystartować proces dbagent. Aby to zrobić na maszynie host dodajemy w zasobach zdalnych bazę skryptową. Następnie odczytujemy komendę jaką należy uruchomić na maszynie remote np.

dbagent -db C:\WrkOpenEdge123\db\sports2000 -H hostname -S 8850 -ipver IPv4 (-S jest portem nasłuchu OEM, nie bazy).
Po uruchomieniu tej komendy agent kontaktuje się z OEM na maszynie host. Każdą bazę scripted można w prosty sposób zamienić w konsoli OEM na managed, Musi być ona uruchomiona z parametrem -S.

Poniższa konfiguracja jest już bardziej złożona – na trzech maszynach A, B i C jest zainstalowany AdminServer. Monitorowanie odbywa się na maszynie A (host). Maszyny B i C (remote) przesyłają dane do hosta. O tym jak wygląda ta komunikacja, napiszę za chwilę. Na maszynach B i C można mieć zainstalowany także OEM i skonfigurowane wszystkie potrzebne lokalne zasoby. W tej sytuacji poprzez zdalne AdminServery mamy dostęp do wszystkich trzech środowisk i to wszystko z jednej konsoli OEM.


Teraz w OEM na hoście możemy dodać zdalne AdminServery i monitorować te maszyny z jednej konsoli. Przykład mamy na poniższym rysunku.

Tu dochodzimy do ważnego punktu. Otóż w wersji OE 11.3 zmienił się mechanizm zdalnego monitorowania (messaging system), SonicMQ został zastąpiony przez ActiveMQ.
Jeśli monitorujemy środowisko posiadając wersję OE 11.3 lub wyższą możemy monitorować bazy scripted w niższych wersjach niż 11.3. Dzieje się tak dlatego, że dbagent nie korzysta z AdminServera.
Jednakże w sytuacji gdy monitorujemy całe kontenery, czyli zdalne AdminsServery, to musimy zachować kompatybilność z systemem przesyłania komunikatów. Czyli, posiadając wersję 11.3+ możemy monitorować inne wersje OE 11.3+. Jeśli zachodzi potrzeba monitorowania wcześniejszych wersji OE, trzeba zainstalować wcześniejsza wersję OEM z systemem SonicMQ.
Korzyść płynąca z ActiveMQ to większa niezawodność, ponadto możemy mieć na wszystkich maszynach zainstalowany nie tylko AdminServer ale także OEM, który w kapitalnym stopniu ułatwia konfigurację. W poprzednich wersjach po przeprowadzeniu konfiguracji trzeba było “wyłączyć” produkt OEM poprzez instrukcję unglue (włączenie instrukcją glue). W ActiveMQ nie mam tej potrzeby. W OE 12 nie ma nawet takiej instrukcji.

OpenEdge Explorer

OpenEdge Explorer nie jest tematem nowym. To okrojona wersja systemu OpenEdge Management (dawniej Fathom Management) który pojawił się w wersji Progress V9.

Wszystkie wymienione powyżej produkty mają głównie za zadanie monitorowanie parametrów systemów operacyjnych i komponentów Openedge (bazy danych, serwery aplikacji itd). Dotyczy to zarówno lokalnego komputera jak i maszyn zdalnych, a wszystko to z jednej konsoli w przeglądarce internetowej. Oprócz monitorowania można także zarządzać komponentami OE: konfigurować, uruchamiać, zatrzymywać itp. W opcji Database Administration znajdują się ponadto dodatkowe możliwości związane z obsługą funkcji baz danych. Tyle w dużym skrócie.

OE Explorer (OEE) jest, jak wspomniałem, uboższą wersją OE Management (OEM). Nie ma np. możliwości zapisu parametrów do specjalnej bazy (trending data), definiowania alertów, wyświetlania graficznych widoków, ale ma te zaletę, że jest darmowy (instaluje się automatycznie z większością licencji od wersji OE 10.2B).

Jak uruchamiamy OEE: możemy kliknąć w ikonkę OE Explorer, ale najlepiej w przeglądarce wpisać URL: localhost:9090.

Aby system wystartował musi być uruchomiony AdminServer. Sprawdzamy jego status komendą w oknie Proenv: proadsv -query i jeśli proces nie pracuje uruchamiamy go komendą: proadsv -start.

Teraz sprawdzamy czy uruchomiony jest OEE: fathom -query i w razie konieczności uruchamiamy go: fathom -start.

Teraz już powinniśmy mieć system uruchomiony. Na starcie jesteśmy proszeni o zmianę hasła. Gdybyśmy mieli pełny produkt OEM to trzeba byłoby jeszcze zdefiniować mail server (powiadomienia o przekroczeniu zdefiniowaniu wartości), bazę do przechowywania trending data itd. W OEE po zmianie hasła mamy od razu widok podobny jak na poniższym rysunku.

Aby monitorować bazę danych definiujemy nowy element Resources -> OpenEdge -> Database. Database Migration Utility służy do skonfigurowania istniejącej już bazy przy czym serwer musi być uruchomiony z podaniem numeru lub nazwy portu.

Klikając na Database Administration możemy zarządzać funkcjami np. opisanymi wcześniej Table Partitioning czy Change Data Capture, Multi-tenancy itp. Funkcje te włączamy w bazie jak na rysunku poniżej. Tych funkcjonalności nie znajdziemy w graficznym narzędziu Data Administration.

Listę włączonych funkcji widać na rysunku po prawej stronie poniżej.

Można tutaj także edytować dane zabezpieczeń (Data Security), przeglądać schemat danych, …

… zrzucać i ładować dane tabel.

W zasobach bazy danych większość widoków jest nieaktywnych dla OEE, ale w widoku Performance Summary mamy ciekawe zestawienie aktualnych parametrów:

Od razu widać, że podobne informacje możemy uzyskać poprzez narzędzie PROMON, ale o ile promon zbiera dane tylko dla bazy lokalnej, to w OEE mamy dostęp dla baz zdalnych. W ten sposób z jednej konsoli można monitorować bazy danych i inne procesy np. serwery aplikacji, data serwery itd.

A propos serwerów aplikacji: poniżej zamieszczam widok dla PASOE, aplikacja ROOT. Dla zainteresowanych tym serwerem, w OEE i OEM 12 nie ma wsparcia dla web serwisów SOAP.

Podsumowując to krótkie zestawienie, OpenEdge Explorer jest użytecznym narzędziem dla administratorów baz, niezbędnym przy konfigurowaniu nowych funkcji jak partycjonowanie tabel czy multi-tenancy oraz do monitorowania zasobów zdalnych.