Posts Tagged ‘WebGUI’

Netcool OMNIbus WebGUI 7.3.1 FP6 plays Java

Tuesday, May 14th, 2013

I’ve been trying to install OMNIbus WebGUI 7.3.1 Fix Pack 6 and the fix pack is not providing with installation script with relevant path to Java executables.

Obviously I didn’t read the readme first, so I was made to experience on my own skin various problems because of that:

1. IBM Java available within TIP cannot be used. It’s starting from within IAGLOBAL_TIP_HOME directory which in my case is standard /opt/IBM/tivoli/tipv2 and as such acts as Java process which according to the installer can be TIP process itself, the installer doesn’t recognize if this is TIPProfile or anything else, it will just stop by saying: I found another Java process in TIP HOME, please stop all processes in TIP HOME!

2. ITM Java couldn’t be used too. It’s TBSM Agent I have here plus ITM 6.2.3 for Linux agent which runs Java 1.5. It’s not supported.

3. I couldn’t use my JRE for Java plugin in WebGUI or TBSM Dashboard server. It’s not supported too.

The only one Java that works in hidden deep in installation directory structure, and Readme will tell you its name:

<FixPackDir>/COI/PackageSteps/WebSphereUPDI/FILES/7.0.0.17-WS-UPDI-LinuxIA32/JDK/jre.pak/repository/package.java.jre/java/jre

Nice. Why isn’t it passed in the install.sh?

Hypothetical question.

New Tivoli Integrated Portal 2.2.0.11

Monday, May 13th, 2013

From some time new version of Tivoli Integrated Portal, cutely referred to as TIP, is available and numbered 2.2.0.11. (Reminder, so called TIP 3.x is not TIP in fact, it is DASH, means Dashboard Application Services Hub and even though it works on same components, it should be considered as another thing).

What does it all mean to TBSM and TCR and WebGUI administrators?

In order to install the top code level available at the moment (today is 13th of May 2013), you need to download and install:

1. TBSM 6.1.0.0 – I make assumption it’s the code level for most of users yet – which installs with Netcool WebGUI 7.3.1.0 and TIP 2.2.0.3 and Impact GUI Server 6.1.0.

2. TCR – which runs TIP 2.1 itself but can install over TBSM code with TIP 2.2.0.3 with no issues.

3. TIP 2.2.0.7 fix pack – I suggest installing it before trying later TIP fix packs first. FITSuit is prerequisite to this one.

4. TBSM 6.1 Fix Pack 1 – this will install Dashboard Server component upgrade which does require minimum TIP 2.2.0.7

5. Netcool OMNIbus WebGUI 7.3.1 FP6 – it is prerequisite to TIP 2.2.0.11

6. TIP 2.2.0.11 – with relevant FITSuit – on top of everything

If You start from TCR 2.1 installation and want to upgrade to TIP 2.2.0.11, you need to start from TIP 2.2.0 refresh pack (and FITSuit) and continue straight with TIP 2.2.0.11 after all (assuming you have no WebGUI).

Here’s short list of compatible (“certified”) components the new TIP fix pack can install on:

*************************************************************
Tivoli Integrated Portal FixPack 2.2.0.11 Installation
*************************************************************
PASS: Installed TCRStandalone 2.1.1.0 is certified with tip2.2.0.11.
PASS: Installed TBSM 6.1.0.1 is certified with tip2.2.0.11.
FAIL: Installed OMNIbusWebGUI 7.3.1.0 is not certified with tip2.2.0.11. Certified versions: 7.3.1.5,7.3.1.6,7.4.0.0.

 

 

 

A few tips for successful new TBSM 4.2.1 failover + existing OMNIbus 7.3 failover

Wednesday, August 31st, 2011

I’d like to present a quick check list for successful TBSM 4.2.1 failover implementation in existing TIP/WebGUI and OMNIbus environment. Some of you may have gone through this, and can confirm it’s not that piece of cake unless you know some secrets. True, details always change the final picture, hence I’m presenting just a check-list to follow, at least a guidance especially for newcomers to the topic.

1. First. Update your software to the most recent releases, including Fix packs and interim fix packs. Even better – if releasing soon, wait for the next one. There’s always something in the fixed code that you may want to have more. Or, read at least the APARs record for incoming or latest fix pack, to learn more whether there’s something useful for failover coming.
Second – collect all the manuals and tips/tricks borrowed from your good mates who have done it and stuck couple of times before. Every single script, automating the pain of many files configuration does matter. If you’re lucky and have good mates, You may even not need this check list here 😉
2. I assume the worst scenario – OMNIbus 7.3.0 exists before TBSM installation, so you’ll have to go through schema updates, and dashboard server over WebGUI installation. On another hand, this situation should turn out with a stable ObjectServers failover set already up, running and for free. I’m assuming that your Object servers are two in the multitier architecture, being specific – they’re a virtual aggregation pair. And secondly, the gateway is configured properly with correct sync types and intervals, and just does its job too.
3. Learn on both ObjectServer alerts.status table schemas. They must be the same. When changing from Primary ObjectServer to backup one, TBSM data server does not discover the schema automatically again. TBSM Event broker reads alerts.status columns ordered by ‘OrdinalPosition’, and it means, that ordinal position of each column must be the same on each ObjectServer. It means that you need to run bsm schema updates on existing ObjectServers carefully, with respect to all the previous schema updates. And do not change the previous order, the original, predefined columns in alerts.status must remain on their places.
Secondly, make also sure that alerts.service_deps table and clear_service_deps automation were imported correctly too.
4. Update the gateway mapping and table definition files after all. Do the update for alerts.status RAD_, TEC_, ITM_ and BSM_ fields mapping, and alerts.service_deps fields mapping.
5. TBSM does not support a fail back to the original Primary data server. The last Primary is primary as long, as it goes down itself. Also, TBSM does not automatically fail back from backup ObjectServer if it is Primary to TBSM, after failover situation. Second information is important for your FO_GATE configuration, as events synced from Primary ObjectServer to Backup one must stay updated in Backup alerts.status and alerts.service_deps after the failback too.
6. For TBSM data and dashboard servers configuration, better use the fo_config script. It’s smart and easy. Watch out on DASH_ settings, they will be applied on dashboard server. Script will also secure the previous versions of files it updates.
7. If you apply FO against running production server, plan for a maintenance window, as the FO implementation does require restarting data and dashboard servers, and we assume your dashboard servers will be running on existing production TIPs with WebGUI, with band of NOC guys online, just watching the AEL, right?
8. The key store file being created during TBSM “primary” server installation should be reused during the “backup” TBSM installation. Keep an eye on it, secure it and pass it when the secondary TBSM installer asks for it.
9. Service details portlet on Service Administration and Service Availability pages is part of Webtop, and will get updated with clickedOn event from the Service Tree portlet during failover only if data sources in WebGUI were previously set correctly.
10. Tipadmin may be not the best idea for a user to test the failover. Go for nco users, and VMM object server plugin instead. Install the plugin on all machines, so data and dashboard servers. Unless you have to integrate with LDAP.
11. If you really want to, you may experiment with the newest settings introduced with TBSM 4.2.1 FP2 and IF3 – consumerQueue and eventsInThread. No risk, no fun.
12. If ObjectServer contains a lot of previously raised events, prepare for EventBroker and ConsistencyChecker hard times. Java heap size analysis and values increase may become needed on both Data servers.
13. Switch on finer or finest tracing and logging levels. Don’t get scary though.
14. Run Primary data server first, then wait and observe the primary’s trace.log until it contains exceptions on detecting not operational backup rad facade. It’s a signal for you to start your backup data server. Even before running any TBSM data server, make sure that Object servers and gateway are up. After data servers start the dashboard servers.
15. When testing the failover, give TBSM, TIP and ObjectServers some time to synchronize and resynchronize before sending next test events. Of course in real life, during regular operations, there can be no time for switch to backup server or failback and TBSM may miss an event match to service instances. Keep this in mind.
16. Observe, make notes, and report the failover scenarios results. Do needed corrections, clean old events to have clear picture and restart again, and again, until it works perfectly. Then let it go for real events.

This is it. Simple and nice, straight forward procedure, isn’t it?

TBSM 4.2.1 i OMNIbus 7.3?

Thursday, May 6th, 2010

Instalator TBSM 4.2.1, tak jak 4.2.0, umożliwia nam zainstalowanie od razu także serwer zdarzeń, jakim jest Netcool OMNIbus w wersji 7.2.1. Tymczasem od pół roku jest już dostępne nowe wydanie OMNIbusa, numerowane jako 7.3.0. Ponadto, pojawiły się już również oficjalne pakiety poprawek: FP1 oraz WebGUI IF2, zatem można zacząć zastanawiać się, czy aby nie warto zaktualizować nasz ObjectServer.
Jeśli już się na to zdecydujemy, warto wiedzieć najważniejsze: takie połączenie jest wspierane przez IBM. Zatem jak się zabrać do pracy i od czego zacząć?
Bazowy kod TBSM 4.2.1 nie jest gotowy do współpracy z OMNIbusem 7.3, musimy dołożyć zestaw poprawek Fix Pack 1. Jest to więc pierwszy krok, nie obędzie się zatem bez przerwy serwisowej również dla TBSMa. Instalacja FP1 wnosi zgodność bibliotek TBSM odpowiedzialnych za komunikację z ObjectServerem z wersją 7.3.
Drugi krok to migracja samego OMNIbusa z 7.2.1 do 7.3. Należy uruchomić instalator i postępować zgodnie z zaleceniami instrukcji. Po instalacji standardowo powstaje kopia dotychczasowego katalogu OMNIHOME a w miejsce dotychczasowego kopiowane są nowe pliki. Zatem z punktu widzenia TBSM, dzięki nowym własnym bibliotekom, komunikowanie się z nowszym ObjectServerem przebiega bez zmian. Nie wszędzie jednak podniesienie wersji OMNIbusa zostaje odnotowane, np. ekran zwracany przez $TBSM_HOME/bin/versioninfo nadal będzie informował o tym, że zainstalowano OMNIbus 7.2.1.
Na tym można by w zasadzie poprzestać, jednak OMNIbus 7.3 to również ulepszony Webtop, odtąd zwany WebGUI. Aby uzyskać dostęp do poprawionych map i widoków, należy jeszcze zainstalować WebGUI 7.3 kod bazowy oraz IF2, oba “na” istniejący TIP.

Ostatnią rzeczą, o której należy wspomnieć dla porządku, jest możliwość podniesienia wersji również agenta do monitorowania ObjectServera, kodowanego oznaczeniem KNO. Jest to krok obowiązkowy, jeśli zintegrowaliśmy wcześniej ITM i Netcool OMNIbus i monitorujemy nasz serwer zdarzeń a zarchiwizowane pomiary przechowujemy w hurtowni Warehouse. I to już w zasadzie wszystko… jeśli chodzi o podnoszenie wersji 😉 Oto bowiem, skoro zainstalowaliśmy nowy OMNIbus 7.3 i zaktualizowaliśmy TBSM, może warto poznać bliżej ich nowe funkcje? Miłej zabawy!
Jeszcze raz lista rzeczy do zainstalowania:
0) TBSM 4.2.1 – base
1) 4.2.1-TIV-BSM-FP0001-
2) Netcool OMNIbus 7.3 – base
3) (opcjonalnie) 7.3.0-TIV-NCOMNIbus--FP0001
4) Netcool OMNIbus 7.3 – Web GUI
5) Webtop-7300--InterimFix002
6) Netcool OMNIbus 7.3 Monitoring Agent