Posts Tagged ‘Webtop’

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?

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.