Posts Tagged ‘IBM’

TBSM in telco industry

Tuesday, April 12th, 2011

After months of break in posting on my blog, I’m coming back and publishing again. After spending a few months in one, bigger project for one of our bigger customers in Europe I’m full of different thoughts on TBSM and its technical use scenarios, as well as on business perspectives of getting this kind of tools to work. I will do my best to present all the interesting aspects and observations and share some of my experience.
First thing to mention is definitely form of my blog. Still the same, maybe will change the layout, but I’m definitely switching to English. Reasons can be justified by business, I believe that english publications remain valuable for polish engineers who may be looking for an interesting content in my blog, and who mostly speak english anyway, and remove the natural language barrier for audience from all over the world. I also believe in delivering more interesting content from now on and rely on your feedback more.
Like I mentioned, I’ve been participating in large TBSM project for telecommunications company in role of implementer and solution co-designer. It’s been very interesting time, lot of experience to gain, long hours and evenings spent over business services design, status and KPI rules, and dashboards. Product such as TBSM, which is highly customizable, and can basically be used in so many ways, may give you both lot of fun and trouble. Up to how open is your solution scope, TBSM design itself can take regular project time or way longer.
There are many things to say how to deal with such project requirements, how to address customer’s suggestions, how to translate use scenarios to TBSM service model, rules and dashboards. But I think it’s better to start from, say, “demythologization” of what TBSM can do and is for.
TBSM is not a network manager tool, or if you prefer – network topologies or hierarchies visualization tool. It’s rather obvious, but service models design may confuse you especially when you try to show dependency of some devices functions on other devices functions. Like you know, everything in TBSM is a service, or business service, even if representing a device, an application or a process. So presenting those objects in TBSM, named after their real, original name, like BSC or SGSN, and links connecting them in Service Viewer portlet, may confuse people less familiar with the tool and drive their minds to think that graphical link represents a physical link between devices, so has a critical meaning for signalling or data flow. Also naming services after devices doesn’t help here. Like I said, TBSM is not network manager or monitor, it just doesn’t have the right tools, like ping, telnet or cgi scripts, even though can present network objects with nice icons, KPI results and SLA violations. For network manager, you’re recommended to learn more about ITNM (IBM Tivoli Network Manager, former Micromuse Precision), if speaking about Tivoli. For open source, they’re writing interesting stuff on op5 in Linux magazine (at least recently in polish edition). For simple visualization of links between locations, I encourage to try Netcool Webtop Maps (new Webtop version was named WebGUI).
Second thing, TBSM can show many services in a tree or relationships view, but there’s a reasonable limit. They say 50’000-100’000 is fair limit nowadays. And 50 child services per parent. But watch out the product role again. It’s business services manager. Are you really running 50’000 business services in your company? So services that you make money on and their components? If yes, you must be IBM! 馃檪
Of course I’m kidding, you may run many services, much more than that and I don’t know how many services they could identify in IBM in WW total. It’s not the point. It’s rather a question: which services are important to you enough to spend weeks on analysis and workshops, identifying their dependencies, collecting technical details, establishing the missing and reconfiguring the existing monitoring and performing all tests? It still can be many, like hundreds top level services plus 10 levels of key components. But all the key components presence in TBSM service models should be justified and reasonable, and preferably: pre-documented, in order to deploy and implement a working solution on time. So TBSM shall be the last place where unverified and unconfirmed service topologies come in.
Last but not least, TBSM audience. I’ve done many projects after which TBSM box landed on shelf. So many customers order it, pay for it (maybe was volume price), are interested in it, after then just one enthusiast remain engaged and all the other personell switch back to old good monitoring tools they know from a decade. Or worse for both IBM and the customer: project slows down, become a critsit and even gets fixed, but bad impression remains. I’m that lucky that my recent project has been done by many enthusiastic people and also the customer, one among a few, has had a realistic vision of and need for TBSM use. It’s a pleasure to work with such mature customer, who is aware of TBSM place in their infrastructure and plans TBSM to be part of their information flow. Likely real life issues and obstacles, usually coming up during every implementation, are way easier to solve if there’s common understanding of what TBSM can and cannot do, and the only question remains open: when this all will be ready?
I hope to share some more interesting thoughts soon. I also encourage you to share your opinions on TBSM projects in different companies and industries, in general or in particular. Topic doesn’t really matter, can be about TBSM or Tivoli. Tivoli’s competition in monitoring or open source. Feel free to post your thoughts. I’m looking forward to hear from you about your bad experience with TBSM, Tivoli or IBM, as well as well done projects and what you’ve learned from them. Welcome and post you soon.

Aplikacje TIP, JNLP, TEP kontra Java i przegl膮darki

Friday, September 17th, 2010

Natrafi艂em niedawno na problem zwi膮zany z wersj膮 艣rodowiska uruchomieniowego Javy, jaka powinna by膰 zainstalowana na stacji roboczej administratora oprogramowania Tivoli. Za艂贸偶my, 偶e jeste艣my administratorami odpowiedzialnymi za monitoring system贸w (ITM-TEP), ich wykrywanie i zarz膮dzanie jako aktywami (TADDM-aplikacja Java Web Start i Maximo) oraz przetwarzanie zdarze艅 i monitorowanie us艂ug biznesowych (TBSM i OMNIbus WebGUI – czyli TIP). Nieraz zadawano mi pytanie: w jaki spos贸b pogodzi膰 wymagane wersje javy, kt贸re s膮 r贸偶ne i gryz膮 si臋 nawzajem?
Na szcz臋艣cie sytuacja si臋 polepsza i jest znacznie lepiej ni偶 nawet rok temu. Najnowsza wersja TADDM 7.2 i poprzednia 7.1.2 dzia艂aj膮 z Jav膮 Sun 1.6, mimo ostrze偶enia, 偶e nie jest ona wspierana. R贸wnie偶 konsola TEP w ITM 6.2.1 wzwy偶 dzia艂a ju偶 poprawnie z Jav膮 1.5 IBM i 1.6 Sun. TBSM 4.2.1 wymaga Javy IBM 1.5 ale bez problemu dzia艂a gdy obok jest Java Sun 1.6. AEL z WebGUI 7.3 dzia艂a nawet lepiej z Sun Java 1.6 ni偶 IBM 1.5.
Wniosek nasuwa si臋 sam: Wersje Javy, kt贸re s膮 obowi膮zkowe na komputerze administratora Tivoli, to IBM 1.5 i Sun 1.6. Jako ta jedyna, niekoniecznie systemowa, ale appletowa, w jednym momencie b臋dzie zawsze ustawiona jedna z nich, ale warto mie膰 drug膮 na podor臋dziu. Wszystko zale偶y od kombinacji oprogramowania, jakie chcemy uruchomi膰 naraz w 1 sesji przegl膮darki. Widzia艂em kombinacj臋 nast臋puj膮c膮 w 1 TIPie:
-WebGUI 7.3
-ITNM 3.8
-TBSM 4.2.1
-TEP Web Client poprzez iframe.
Aplikacje gryz艂y si臋, wymagania jednej wp艂ywa艂y na dzia艂anie drugiej. Z艂otym 艣rodkiem okaza艂o si臋 zainstalowanie Sun Javy 1.6 i IBM Javy 1.5, oraz skonfigurowanie TEPa, aby podczas uruchomienia Web Clienta r贸wnie偶 wymusza艂 uruchomienie si臋 w Sun Java 1.6 (polecam artyku艂: Dzi臋ki temu zabiegowi poprawnie zadzia艂a艂 i AEL, i ITNM w iframe (cho膰 i ten portlet ma problemy z ustawieniem Customizer) i TEP Web Client w portlecie inframe, wszystko w 1 sesji TIP na Firefoksie. Je艣艂i chodzi o aplikacje Webstartowe, to polecam 艣ci膮gn膮膰 sobie na pulpit plik *jnlp i napisa膰 prosty skrypt wywo艂uj膮cy mniej wi臋cej takie polecenie:
$ODPOWIEDNI_JAVA_HOME/bin/javaws .jnlp
gdzie $ODPOWIEDNI_JAVA_HOME wskazuje na binaria Javy w wersji wymaganej przez aplikacj臋 JNLP.
Teraz przegl膮darki. TBSM nie dzia艂a w IE 8.0, pojawia si臋 mn贸stwo b艂臋d贸w i przegl膮darka jest w艂a艣ciwie bezu偶yteczna. IE 7 jest wspierana i dzia艂a dobrze, ale og贸lnie od zawsze preferowa艂em Firefoxa i polecam w艂a艣nie t臋 przegl膮dark臋. Nie ma jednak r贸偶y bez kolc贸w, oficjalnie wspierany FF to 3.0, kt贸ry odejdzie niebawem w niebyt, za to s膮 jakie艣 problemy z FF 3.6. Zdaje si臋, 偶e metod膮 z艂otego 艣rodka nale偶y postawi膰 na FF 3.5.
Nie mam do艣wiadczenia z 3 pozosta艂ymi licz膮cymi si臋 graczami: Safari, Opera czy Chrome, ani z alternatywnymi starymi wygami (Netscape) ani tym bardziej z egzotykami (KBrowser), nie s膮 one zreszt膮 ani zalecane ani przede wszystkim wspierane, wi臋c nie ma za bardzo o czym pisa膰.
Standardem korporacyjnym bardzo cz臋sto jest IE, a poniewa偶 wersja 8.0 wprowadza r贸偶ne dodatkowe zabezpieczenia oraz jest natywn膮 przegl膮dark膮 w systemach Windows 2008, coraz cz臋艣ciej w艣r贸d klient贸w Tivoli po prostu nie ma 偶adnej alternatywy. Trudno oceni膰 dlaczego do tej pory TBSM jej nie wspiera, wydaje si臋 to kwesti膮 czasu i najbli偶szych fixpack贸w, cho膰 tymczasowa lista 艂at, przewidziana dla nast臋pnej paczki poprawek (TBSM 4.2.1 Fix Pack 2 Interim Fix 3), nie przewiduje dodania wsparcia dla IE 8.0.
Nie zaleca si臋 stosowania IE 6.0 w TBSM, podczas gdy dla ITNMa 3.8 jak najbardziej, wi臋c tutaj jest niezgodno艣膰. To samo dotyczy wsparcia dla Firefox 2.0 u obu produkt贸w.
WebGUI r贸wnie偶 nie wspiera Explorera 8.0 ale wspiera wersj臋 6.0 i 7.0 oraz Firefoxa 3.0. Moim wnioskiem co do wsp贸lnej przegl膮darki dla wszystkich wymienionych produkt贸w jest zatem stwierdzenie: u偶ywam albo IE 7.0 albo FF 3.5, zw艂aszcza, 偶e wedle mojego do艣wiadczenia w艂asnie taki komplet daje najwi臋ksz膮 gwarancj臋 bezb艂臋dnego dzia艂ania.
A wi臋c podsumowuj膮c, czego potrzebuje administrator Tivoli do obs艂ugi w/w produkt贸w?
– IE 7.0 lub FF 3.5
– Sun Java 1.6 i IBM Java 1.5 (wzgl臋dnie 1.6)
I to tyle.

Nowo艣ci ci膮g dalszy

Saturday, October 17th, 2009

Postanowi艂em nieco zmodyfikowa膰 wygl膮d strony. Mimo, 偶e niebawem up艂ynie rok od jej uruchomienia, jej pomys艂 nie rozwin膮艂 si臋 jeszcze zupe艂nie. Ale my艣l臋, 偶e pora zrezygnowa膰 z pierwotnego pomys艂u na blog w stylu “o tym i owym” i skoncentrowa膰 si臋 na jednym temacie: BSM-IT, czyli zarz膮dzanie biznesem poprzez narz臋dzia informatyczne. B臋d臋 wi臋c stara艂 si臋 porusza膰 na blogu sprawy przede wszystkim techniczne ale i biznesowe, zwi膮zane z nowo艣ciami, publikacjami oraz pomys艂ami w tej dziedzinie informatyki. Oczywi艣cie b臋d臋 pisa艂 g艂贸wnie o oprogramowaniu Tivoli, ale postaram si臋 nie tylko, jako 偶e m贸j blog – to mo偶e troch臋 w kwestii wyja艣nienia – nie jest ani “sterowany”, ani nawet “sponsorowany” przez IBM, nie jest to kana艂 komunikacji firmy z otoczeniem, a dok艂adnie – jak zaznaczy艂em w dementi – przedstawia on wy艂膮cznie moje stanowisko i opinie co do niekt贸rych spraw. Poniewa偶 zajmuj臋 si臋 oprogramowaniem Tivoli na codzie艅 i posiadam pewn膮 wiedz臋, do艣wiadczenia i spostrze偶enia, chcia艂bym si臋 nimi podzieli膰 i w razie potrzeby pom贸c, podpowiedzie膰 jakie艣 rozwi膮zanie. Podpowiedzie膰 tym z Was, kt贸rzy r贸wnie偶 na codzie艅 wdra偶aj膮, planuj膮 wdro偶enia lub naprawiaj膮 instalacje (sic!) Tivoli. Je艣li chodzi o rozwi膮zania to tu uwaga – m贸j blog nie jest kana艂em alternatywnym dla us艂ug wsparcia IBM, czy jakiegokolwiek kana艂u informacji IBM, ale raczej swoist膮 form膮 mojej autorskiej publikacji, a tak偶e – mam nadziej臋 – okazj膮 do nauczenia si臋 lub dowiedzenia czego艣 nowego od czytelnik贸w. Tak wi臋c nie sprzedaj臋 niniejszym 偶adnych us艂ug, nie wyr臋czam wsparcia IBM, nie prezentuj臋 stanowiska firmy ale informuj臋 o nowo艣ciach, dobrych praktykach i publikacjach. A wszystko po to, aby troch臋 dopom贸c w poruszaniu si臋 w g膮szczu informacji wok贸艂 produkt贸w firmy i uczyni膰 prac臋 z Tivoli cho膰 troch臋 艂atwiejsz膮. Je艣li to wog贸le mo偶liwe 馃槈

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.