Porównanie TBSM 4.1.1 i 4.2

Dzisiejszy wpis poświęcę porównaniu dwóch ostatnich wydań TBSM – oznaczonych numerem 4.1.1 oraz 4.2.

W podręczniku Administrator’s Guide do TBSM 4.2 (PDF) znajduje się sekcja What’s new in TBSM Version 4.2. Pozwolę sobie przyjrzeć się jej z bliska i odnieść do poszczególnych punktów, plus dodać kilka własnych.

 

1. Warstwa prezentacji – NGF vs. TIP

TBSM 4.1.1 TBSM 4.2
Netcool GUI Foundation (NGF) – poprzednie rozwiązanie, wspólne dla wszystkich aplikacji webowych Netcool (RAD, Impact, Webtop, Reporter). Zawartość stron jak i same strony definiuje się z poziomu przeglądarki, natomiast strony przechowywane są w wewnętrznej bazie danych NGF. Pod spodem NGF pracuje serwer Tomcat. Tivoli Integrated Portal (TIP), jest to nowa, wspólna konsola dla produktów Tivoli, która umożliwia tworzenie stron, zakładek, widoków, portletów oraz wykresów. Pod spodem TIP to aplikacja eWAS, który uruchamia się jako osobna usługa (Windows) lub proces (UNIX). Oprócz warstwy prezentacji TIP dostarcza również mechanizm bezpieczeństwa.

 

2. Raporty – BIRT vs TCR 1.2

TBSM 4.1.1 TBSM 4.2
Technologia: Business Intelligence and Reporting Tool (BIRT) – w TBSM 4.1.1 raporty są predefiniowane i dostarczane wraz z pluginem BIRT, instalowanym na serwerze NGF. Raporty historyczne to osobny element tylko instalacji zaawansowanej. Po zainstalowaniu, na liście stron pojawia się nowa pozycja: TBSM Reports, która prowadzi do strony psml, zawierającej tabelę z wszystkimi typami raportów. Ich zmiana wymaga więc nieco odręcznej gimnastyki. Oczywiście do ich działania wymagany jest dostęp do TDW oraz uruchomiony ITMAgent monitorujący TBSMa. Technologia: Tivoli Common Reporting (TCR), czyli wspólny dla wszystkich produktów Tivoli serwer raportowy. Obsługuje on raporty BIRTowe, dodając warstwę organizacji raportów w tzw. zestawy (Report sets), umożliwia również z poziomu przeglądarki instalację nowych raportów oraz zmiany w konfiguracji istniejących. W paczce z TBSM 4.2 dostajemy TCR w wersji 1.2, który integruje się z TIP. Tylko TBSM 4.2 jest (na razie) produktem, z którym dostarczany jest TCR.

 

3. Bezpieczeństwo

TBSM 4.1.1 TBSM 4.2
Netcool Security Manager (NCSM) – wspólny dla wszystkich aplikacji Netcool (RAD, Impact, Webtop, Reporter) system bezpieczeństwa w TBSM 4.1.1 posiada wewnętrzną bazę HSQL oraz interfejs webowy w NGF. Security Manager może łączyć się z zewnętrznymi repozytoriami użytkowników: OMNIbus, LDAP, Active Directory. Tivoli Integrated Portal (TIP) – prócz warstwy prezentacji dostarcza również mechanizmów autentykacji oraz bezpieczeństwa opartego o Websphere Security.

 

4. Rozłożenie komponentów

TBSM 4.1.1 TBSM 4.2
3 kluczowe komponenty – TBSM server, OMNIbus(+License Server) oraz NCSM. W zasadzie dałoby się prawdopodobnie wydzielić jeszcze bazę danych Postgres, ale nigdy tego nie próbowałem. TBSM dostarczany jest z OMNIbusem 7.1 ale zadziała również z 7.2.1. Zadziała również z wersją NCSM niższą niż dostarczana w paczce, czyli z 1.3. TBSM 4.1.1 można również integrować z Netcool/Webtop, ale wymagana wersja to 2.1. 3 kluczowe komponenty – ale trochę inaczej rozkładające się: OMNIbus, Dashboard Server oraz Data Server. W paczce z TBSM 4.2 jest dostarczany OMNIbus 7.2. Dashboard server jest to po prostu TIP, czyli prezentacja i security, natomiast Data server to przede wszystkim serwer bazy danych Postgres. Serwery Data i Dashboard, gdy instalowane odddzielnie, komunikują się ze sobą poprzez aplikacje eWASowe.

 

5. Reguły zdarzeń i agregacji

TBSM 4.1.1 TBSM 4.2
2 typy reguł zdarzeń – jedna oparta na stanach: dobry-zły-marginalny a druga numeryczna. Pierwsza z reguł może zwracać wartości odpowiadające stanom dobry-marginalny-zły, natomiast druga może zwracać wartości numeryczne i dodatkowo opcjonalnie stan zły lub marginalny dla zadanych progów wartości numerycznej. Jeśli chodzi o reguły agregacji to trzeba się trochę naklikać, ażeby zamodelować reguły przekazywania zdarzeń od najbardziej potomnych usług do tych najbardziej nadrzędnych – trzeba zdefiniować odpowiednią regułę agregacyjną na każdym poziomie hierarchii. 3 typy reguł zdarzeń – oprócz dwóch z wersji 4.1.1 dochodzi nowa – tekstowa, a więc oparta o wartości tekstu, np. kodu błędu. Natomiast zamiast konieczności definiowania reguł agregacji na każdym poziomie hierarchii usług, można zdefiniować przekazanie stanu do rodzica w nowym osobnym dialogu GUI.

 

6. Integracja z TADDM

TBSM 4.1.1 TBSM 4.2
Tivoli Application Dependency Discovery Manager (TADDM) – to system do wykrywania aplikacji, komputerów oraz elementów konfiguracji (Configuration Items – CI) w sieci oraz relacji między nimi, oparty o bazę konfiguracji CMDB (CCMDB). Na płycie z TBSM 4.1.1 znajduje się tzw. Discovery toolkit (zwany krócej xmltoolkitem), czyli middleware do mapowania modelu usług i relacji w TADDM na model w TBSM. Łączy się on z API serwerem w TADDM, pobiera jego model i umieszcza definicje w TBSM w tzw. Service Component Registry czyli SCR. Xmltoolkit działa tylko z TADDM w wersji 7.1. Discovery toolkit w TBSM 4.2 łączy się i z API serwerem i bezpośrednio z bazą danych CMDB poprzez JDBC, przez co jest znacznie szyszy. Działa zarówno z TADDM 7.1 jak i 7.1.2. Może działać również z TBSM 4.1.1, choć podczas takiej instalacji wymagana jest migracja schematu bazy danych poprzedniego TBSM. Jest to jednak w pełni wspierane rozwiązanie.

 

7. Integracja z TSLA

TBSM 4.1.1 TBSM 4.2
Tivoli Service Level Advisor (TSLA) – to system do zarządzania umowami SLA (Service Level Agreement). TBSM integruje się z TSLA poprzez tzw. data injector, czyli mechanizm wstrzykujący do bazy pomiarów TSLA dane o dostępności usług, oraz przesyłający definicję samych usług i szablonów, tak, że TSLA automatycznie tworzy definicje offeringów oraz SLA i SLO. Można również tworzyć własne SLO i SLA, oceniające jakość usług w TBSM. Dodatkowo można w TBSM zdefiniować numeryczną regułę zdarzeń tak, by w TSLA pojawiła się jako osobna metryka (KPI), dla której można tworzyć osobne SLA. Integracja z TSLA w TBSM 4.2 wygląda identycznie, nie zmieniło się nic w dotychczasowej funkcjonalności. Trochę szkoda, że nie da się tworzyć metryk (KPI) w TSLA, opartych o tekstowe reguły zdarzeń z TBSM.

 

8. Wspierane platformy

TBSM 4.1.1 TBSM 4.2
5 głównych – AIX, Linux (SLES oraz RHEL), Windows 2003, Solaris oraz HP-UX. Próbowałem także na Windows XP – działa ale nie jest wspierane w sensie server, tylko client. 6 platform – AIX, Linux (SLES i RHEL), Windows (2003 i 2008), Solaris, HP-UX oraz zLinux. Także próbowałem na Windows XP i także działa ale także nie jest wspierane w sensie server, tylko client.

 

9. Integracja z Webtop

TBSM 4.1.1 TBSM 4.2
W TBSM 4.1.1 jest wbudowana część funkcjonalności Webtop 2.1 – np. portlety typu Active Event List oraz rola webtop user. Nie jest to w pełni działający Webtop, brak map, encji oraz widoków. Można jednak zainstalować pełną wersję Webtop 2.1 “na” TBSM 4.1.1, uzyskujemy wtedy funkcjonalność obu produktów w jednej konsoli NGF. Z TBSM 4.2 został zintegrowany pełny Webtop 2.2. Webtop 2.2 jest dostępny również jako osobny produkt i dla firm, które chcą migrować jedynie do nowszego wydania, bez kupowania TBSM, istnieje taka możliwość.

 

To tyle. Mam nadzieję, że to krótkie porównanie okaże się dla kogoś z Was interesujące i pomocne.
Pozdrawiam
MP

2 Responses to “Porównanie TBSM 4.1.1 i 4.2”

  1. Pawl0 says:

    Hej,

    Bardzo ciekawe porównanie. W kwestii tak złożonego tworu, jak TIVOLI jest to bardzo cenny i pomocny tekst. Będę tu chyba częściej zaglądał 🙂

    Przy okazji mam pytanie odnośnie Webtop-a 2.2. Dotychczas miałem kontakt tylko z Webtop-em 2.1 – czy w wersji 2.2 zmienił się sposób licencjonowania (czy nadal jest per-connection ) ?

  2. admin says:

    Dziękuję i mam nadzieję, że kolejne artykuły również będą interesujące.

    Jeśli chodzi o licencjonowanie, to sprawa jest skomplikowana i zawsze należy dopytać się przedstawicieli IBM (porada kolegi;), niemniej pewne informacje można znaleźć na stronie:
    http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS208-268

    Pozdrowienia

Leave a Reply