Posts Tagged ‘OMNIbus’

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

ITM 6.2.2 i ITPA 6.2.2 dost臋pne

Tuesday, September 22nd, 2009

Ca艂kiem niedawno pokaza艂a si臋 nowa wersja IBM Tivoli Monitoring (ITM) w wersji 6.2.2 oraz paczkowany razem z serwerem agent IBM Tivoli Performance Analyzer, r贸wnie偶 w wersji 6.2.2. Oczywi艣cie wraz z nowym ITM pojawi艂y si臋 inne aplikacje woko艂o-agentowe: agenci systemowi, Universal Agent, Agent Builder. Ale w tym wpisie przyjrz臋 si臋 dw贸m wymienionym w tytule produkcjom.

Najwa偶niejsze zmiany to d艂ugo wyczekiwane przeprojektowanie okna dialogowego do kolekcji danych historycznych – teraz wygl膮da ono jak okno dialogowe do edycji sytuacji. Mo偶na tak偶e specyfikowa膰 na jakich monitorowanych systemach maj膮 dzia艂a膰 ustawienia. Do zmiany ustawie艅 zosta艂y dodane nowe polecenia z poziomu tacmd. Ale to nic w por贸wnaniu z ciekawym zabiegiem, nazywanym autonomi膮 agent贸w. Pojawi艂a si臋 nowa kategoria agenta – Tivoli System Monitor Agent (TSMA), kt贸ry mo偶e dzia艂a膰 niezale偶nie od dost臋pno艣ci serwera TEMS. Taki agent posiada prywatny zestaw sytuacji, harmonogram kolekcji danych historycznych oraz potrafi wysy艂a膰 zdarzenia w formie trap贸w SNMP do np. sondy OMNIbus SNMP. Agenty TSMA, a tak偶e tradycyjne agenty ITM mo偶na kontrolowa膰 poprzez wsp贸lny Agent Service Interface. Z mi艂ych dodatk贸w jest zachowanie agenta po rekonfiguracji – teraz mo偶na za偶yczy膰 sobie by restart odby艂 si臋 nie od razu ale p贸藕niej. Mamy r贸wnie偶 od艣wie偶enie interfejsu graficznego TEP – nowy pasek narz臋dzi oraz rysowanie lini bazowych (baseline) na wykresach w TEPie.

Natomiast je艣li chodzi o ITPA 6.2.2, to najwa偶niejsz膮 informacj膮 jest, 偶e nie wsp贸艂pracuje on z ITM w wersjach ni偶szych ni偶… 6.2.2! Ma to swoje uzasadnienie w postaci usprawnie艅 w zakresie wydajno艣ci, za艂o偶eniem by艂o jej podniesienie, zw艂aszcza przy du偶ej ilo艣ci wykonywanych oblicze艅 trend贸w. Skoro jeste艣my ju偶 przy obliczeniach, od teraz zadania TPA obs艂uguj膮 zar贸wno 32 jak i 64 bitowe liczby ca艂kowite i u艂amki dziesi臋tne w parametrach. Ponadto dodano funkcje monitorowania w艂asnej wydajno艣ci TPA, szczeg贸lnie przydatne w du偶ych systemach. Lista wspieranych platform pozosta艂a niezmieniona, nale偶y jedynie zwr贸ci膰 uwag臋 na wymaganie TCR w wersji 1.2 do zainstalowania raport贸w.

Nie sprawdzi艂em jeszcze osobi艣cie nowych funkcji, ale ju偶 wkr贸tce b臋dzie okazja, zatem mo偶e pojawi sie kolejny wpis na temat ITM i ITPA. Ju偶 teraz w g艂owie mrowi si臋 od pomys艂贸w na wykorzystanie nowych funkcji ITM i ITPA: szersza wsp贸艂praca z OMNIbusem, mo偶e wreszcie zestaw zada艅 do obliczenia trend贸w z danych zebranych przez agenta TBSM? Kto wie.

Czego potrzebuj臋 do zarz膮dzania moj膮 infrastruktur膮 IT?

Monday, August 31st, 2009

Ostatni weekend sierpnia 2009, do艣膰 gor膮ca niedziela i odchodz膮cy powoli do historii letni sezon – w domu, w pracy, w biznesie. Czas powrotu z pi臋knych pla偶, urokliwych g贸r, dzia艂ki, namiotu i przyjemnego spowolnienia i rozlu藕nienia. Czas podsumowa艅 i ogl膮dania zdj臋膰, pojawiania si臋 z urlopu koleg贸w z pracy, przyjaci贸艂, kontrahent贸w. Czas powrotu do koncentracji na projektach, sprawach, kontraktach, wdro偶eniach. Czas podsumowania: to na czym stan臋li艣my w projekcie?

W bran偶y IT jak zwykle ciekawie. Nied艂ugo pojawi si臋 w sprzeda偶y nowy Windows 7, Google planuje wypuszczenie swojej wersji systemu operacyjnego Chrome OS, Intel pracuje nad rewolucyjnym procesorem graficznym Larabee, maj膮cym odebra膰 cz臋艣膰 rynku Nvidii i ATI. Z mojego podw贸rka – IBM nadal rozwija swe g艂owne aktualnie idee Smarter Planet oraz Cloud Computing, wpisuj膮c si臋 w og贸lnorynkowy trend maj膮cy na celu tworzenie rozwi膮za艅 IT, kt贸re zaspokoj膮 potrzeby biznesowe z jednej strony i oszcz臋dz膮 艣rodowisko naturalne z drugiej. To na razie tyle w 艣wiecie, pozostaje grom temat贸w wewn臋trznych: modernizacja serwerowni, rozbudowa data center, zarz膮dzanie energi膮 i redukcja jej zu偶ycia, rozwi膮zanie problem贸w wydajno艣ciowych naszych aplikacji i us艂ug, doko艅czenie wdro偶e艅, spotkania, spotkania, spotkania…

Biznes IT, jak ca艂y 艣wiat, ulega ci膮g艂ej komplikacji. Poniewa偶 aplikacji, serwer贸w aplikacji, typ贸w baz danych, sposob贸w komunikacji oraz platform uruchomieniowych jest obecnie bez liku, przed dyrektorami d/s IT stoi odwieczny problem: jak to wszystko zliczy膰, podliczy膰, ogarn膮膰, zmierzy膰, po艂膮czy膰, roz艂膮czy膰 i pokaza膰 na wykresie szefowi, 偶e mamy najlepszy sprz臋t i soft na 艣wiecie? Dla os贸b ci膮gle pozostaj膮cych w kontakcie z nowymi technologiami oraz trendami nie ma z odpowiedzeniem na te pytania najmniejszego problemu, zdarza si臋 jednak, 偶e klock贸w IT zaczyna by膰 zbyt wiele. Chcia艂bym tym wpisem spr贸bowa膰 podsumowa膰 i stworzy膰 wyobra偶enie odpowiedniej strategii zarz膮dzania infrastruktur膮 IT, niezale偶nie od brand贸w, firm programistycznych oraz polityki. Taka strategia, kt贸ra mo偶e nie od razu kompletnie, ale w ko艅cu zawsze b臋dzie wdra偶ana za ka偶dym razem, gdy mamy na celu stworzenie sprawnego multisystemu komputerowego. Specjalnie u偶ywam s艂owa multisystem na okre艣lenie systemu system贸w, czyli razem wszystkiego co mamy. W terminologii BSM nazwa艂bym to super us艂ug膮 i umiejscowi艂bym j膮 na samym szczycie hierarchii i nazwa艂 w艂a艣nie: IT, wszystko, multisystem.

A wi臋c c贸偶 mamy w serwerowni: routery, switche, UNIXy, Windowsy, bazy Oracle, DB2, serwer pocztowy, DHCP, domeny, LDAP, Tomcaty, Apache, JBossy, stuff z HP, BMC, IBM Tivoli, jakie艣 MySQL i dziesi膮tki us艂ug WebService, setki serwer贸w, tysi膮ce stacji roboczych itp., itd. O, kto艣 w艂膮czy艂 jeszcze jednego LPARa na AIX. Du偶o tego. Przyda si臋 z pewno艣ci膮 jeszcze jeden rodzaj oprogramowania, tym razem 偶eby ogarn膮膰 to wszystko i wiedzie膰 co mamy: wykrywanie element贸w sieciowych i aplikacji. W Tivoli do tego celu, maj膮c do dyspozycji r贸偶ne funkcje, mo偶na u偶y膰 trzech program贸w: ITNM (Network Manager, dawniej Netcool Precision), TADDM (Tivoli Application Dependency Discovery Manager) oraz Netcool Proviso.

Powiedzmy, 偶e wszystko jest wykryte, znamy wszystkie MIBy, IP, porty itp. Mo偶na zesk艂adowa膰 te informacje w bazie danych konfiguracji, zwanej potocznie CMDB (Configuration Management Data Base). Mo偶na r贸wnie偶 pokusi膰 si臋 o zarz膮dzanie sprz臋tem – przypisywanie odpowiedzialno艣ci itp., z ang. Asset Management oraz zmian膮, aby dopilnowa膰 by tylko zatwierdzone do u偶ytku maszyny i aplikacje mia艂y wst臋p do firmowej sieci. W Tivoli s艂u偶y do tego obecnie platforma Maximo i CCMDB. W bazie konfiguracji mo偶emy r贸wnie偶 przechowywa膰 katalog us艂ug, SLA, zdarze艅 – s艂owem wszystkiego co mo偶e pojawi膰 si臋 w sieci, co chcemy monitorowa膰, w jakich zakresach, pod gro藕b膮 jak wysokich kar finansowych, cokolwiek zosta艂o zdefiniowane w ITIL, a nawet wi臋cej.

Skoro ju偶 wiemy co mamy, nale偶a艂oby to obmonitorowa膰. Obecnie tendencje s膮 dwie: przy u偶yciu agent贸w (oprogramowanie do zainstalowania na zdalnej maszynie) lub bezagentowo (probowanie zdanej maszyny bez instalowania na niej czegokolwiek dodatkowo). Niekt贸rych rzeczy nie da si臋 zrobi膰 bezagentowo, np. ze wzgl臋du na polityk臋 bezpiecze艅stwa w firmie. Niemniej wachlarz mo偶liwo艣ci jest spory, w Tivoli: ITM for Applications i for Transactions, ITCAM oraz monitorowanie zdarze艅 Netcool OMNIbus. Na osobn膮 uwag臋 zas艂uguje monitorowanie zu偶ycia energii: ITM for Energy Management. Oczywi艣cie wszystkie dane pomiarowe nale偶y gdzie艣 przechowa膰, zsumaryzowa膰, skonfrontowa膰 z progami katalogowymi, wszcz膮膰 alarm, je艣li progi zostan膮 przekroczone oraz opisa膰 w raporcie. Do tego celu przyda si臋 szybka hurtownia danych, katalog SLA, QLA i KPI b膮d藕 KQI, system do korelacji, eskalacji i wizualizacji zdarze艅 oraz dobry system raportowy. Tivoli dostarcza takie narz臋dzia, np. Netcool Impact, Webtop, TBSM i TCR. Analiz臋 biznesow膮 danych umo偶liwia pakiet Cognos a zarz膮dzanie jako艣ci膮: TSLA, TNSQM i Maximo SLA Manager.

Na koniec, maj膮c ju偶 raport na temat kiepskich czas贸w odpowiedzi, ilo艣ci transakcji, d艂ugo艣ci kolejek i temperatur w serwerowni, a w zwi膮zku z tym uszczerbku jako艣ci naszych us艂ug mo偶na spokojnie przyst膮pi膰 do poprawy sytuacji, czyli… otworzy膰 zg艂oszenie serwisowe (Tivoli Service Request Manager) i otrzyma膰 bilecik (ticket). I upewni膰 si臋, 偶e wszystkie zmiany, resety i awarie przebiegn膮 obs艂u偶one automatycznie (Tivoli Systems Automation). I to ju偶 wszystko – mniej wi臋cej. Bo oczywi艣cie spraw臋 mo偶na skompikowa膰 jeszcze bardziej. Np. a czy oprogramowanie do zarz膮dzania moj膮 infrastruktur膮 jest wydajne? Mo偶e by je obmonitorowa膰? Uff…

Tak jak napisa艂em we wst臋pie: jest czas na powr贸t do spraw sprzed wakacji. Mimo, i偶 lista oprogramowania do monitorowania i zarz膮dzania infrastruktur膮 IT jest d艂uga i sprawa wygl膮da na skomplikowan膮, prawid艂owe rozpoznanie wszystkiego w 艣rodowisku IT i zarz膮dzanie t膮 wiedz膮 jest obecnie kluczowym czynnikiem sukcesu dzia艂u informatycznego, a wi臋c i ca艂ej firmy, poprzez redukcj臋 koszt贸w dzia艂u, zakup贸w, zwi臋kszenie wykorzystania wolnych zasob贸w, podniesienie bezpiecze艅stwa, uzyskanie warto艣ci dodanej z integracji i opanowanie wci膮偶 bytuj膮cych tu i 贸wdzie “bia艂ych plam” na mapie naszego systemu informatycznego. Ale najwa偶niejsze – moim zdaniem – na pocz膮tek to by sobie wyobrazi膰 proces zarz膮dzania IT jako ca艂o艣膰, kt贸ra nie ko艅czy si臋 tylko na zintegrowaniu dw贸ch-trzech system贸w i zaprezentowaniu jakichkolwiek raport贸w. Chodzi o to, by zbudowa膰 sp贸jne rozwi膮zanie o szerokich mo偶liwo艣ciach, pocz膮wszy od stwierdzenia stanu faktycznego infrastruktury, przez rozpoznanie w膮skich garde艂 wydajno艣ci, na pe艂nym raportowaniu i zarz膮dzaniu jako艣ci膮 sko艅czywszy. I tak偶e aby takie rozwi膮zania projektowa膰 od samego pocz膮tku wdro偶e艅, doskonale rozumiej膮c miejsce i rol臋 ka偶dego z element贸w, do kt贸rej zosta艂 powo艂any. Tylko wtedy uda uzyska膰 si臋 dzia艂aj膮cy kompleksowo, zgodnie z oczekiwaniami i przysz艂o艣ciowy multisystem zarz膮dczy IT. Nawet je艣li nie obejdzie si臋 bez godzin spotka艅, konsultacji, korekt i telefon贸w do serwisu – efekt powinien zadowoli膰 ka偶dego, i firm臋 i klient贸w.