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.