Hi all, it’s been a while since new release of TBSM numbered 6.1 got available. Personally I haven’t much time to play around it extensively since then, however I’ve got few occasions to just take a look. So it’s highest time for more insight now.
Let’s start with the core. TBSM 6.1 core engine is pretty the same, even if it bases on two SIGNIFICANTLY different, critical components:
- DB2 as service instances and templates and rules database, no Postgres anymore.
- Impact 6.1 engine to execute rules.

By pretty the same I mean: incoming status and status dependency rules, numerical rules, dependencies and formulas, same SLA engine, same ESDA and autopopulation rules. What’s quite new is function of propagating status based on service instances relationships too. Previously you had to plan sometimes quite complex templates relationships, reflecting on logical interdependencies within types (1 service instance having independently propagated results). Now you can rely on instances connectivity. Can be simpler, and you still can go for previous option. There are some other changes in service editor and templates editor too, but let me switch to engine undercover now.
Previous file-based storage of custom canvases, view definitions, cumulative SLAs definitions and maintenance windows definitions was replaced with extended XMLtoolkit functionality. It looks XMLtoolkit becomes more important since ever – all those files, plus traditional XMLtoolkit configuration files (EventIdentifier.xml for example) are now ARTIFACTS, stored inside DB2, and marked with last update time, so it’s harder to make accidental changes and easier to track down what’s in the repo at the moment. It looks more less this:
Artifact Name Category Subcategory Time
============================================================================ ================ ============== ==========================
CanvasTemplate=CustomView,ServiceInstanceID=95,ServiceTypeID=1,.datamappings customcanvas user_tbsmadmin 2011-12-05 11:46:02.818023
CanvasTemplate=CustomView,ServiceInstanceID=95,ServiceTypeID=1,.layoutxml customcanvas user_tbsmadmin 2011-12-05 11:46:02.812388
CanvasTemplate=CustomView,ServiceInstanceID=95,ServiceTypeID=1,.props customcanvas user_tbsmadmin 2011-12-05 11:46:02.652123
EventIdentifierRules.xml eventidentifiers 2011-11-24 11:15:49.005977
LabelingRules.xml labeling 2011-11-24 11:15:48.859746
…
CDM_TO_TBSM4x_MAP.xml scrconfig 2011-11-24 11:15:48.998598
CDM_TO_TBSM4x_MAP_Templates.xml scrconfig 2011-11-24 11:15:48.869856
…
cumulTimeSLA.xml sla 2011-12-05 13:59:13.165438
AttributeGlobal.xml taddmfilters 2011-11-24 11:15:48.770682
classfilters.xml taddmfilters 2011-11-24 11:15:48.829993
…
com.collation.platform.model.topology.sys.ComputerSystem.xml taddmfilters 2011-11-24 11:15:48.761854
…
ViewDefinition_GIS.xml viewdefinition 2011-11-24 11:35:54.393365
ViewDefinition_Grid.xml viewdefinition 2011-11-24 11:35:54.418953
ViewDefinition_Relationships.xml viewdefinition 2011-11-24 11:35:54.363794

In order to make ANY change, you need to export desired artifact, do the change and import it back, with new XMLtoolkit scripts. Any parse or validation? Not aware of. And XMLtoolkit installs with TBSM automatically, even if you don’t configure it to work with TADDM or IDML books.

That’s One significant change for core engine activities – you can audit every addition of service instance or template or rule, every change of their definition with new special logging mechanism. It’s nice, you can track down who changed your beloved, manually developed over night, complex service trees. It was definitely feature missing in previous releases.

How all of this work with new Impact engine and DB2? No much feedback from the field, I’ll have a chance to take a closer look very soon, and i’ll report if found anything interesting. I expect all typical natal diseases you can see in new releases, especially something changed in engine infrastructure.

There’s much more to say about other parts – failover, and new TIP, for which I’ll dedicate a separate post.
Cheers.

Browsing my linkedIn groups posts I learned about interesting web site about application performance and business service management disciplines – APM Digest. See this interesting article about five important conditions to be met before making up a successful dashboard in BSM:

http://apmdigest.com/five-dashboard-must-haves-for-bsm

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?

Check on this, it’s interesting piece of concept.

http://www.prelert.com/products.html

However I still think this kind of software will have a real future only when the monitored software vendors standardize their status, performance and quality data to just one or two good standards. But it’s unbelievable and impossible I guess. Why to give up the uniqueness, so competitiveness of our applications? Who’d control the standards anyway? How it all would develop when new technologies applications get released?

Last week I returned from European Tivoli Technical Conference in Prague. It was a very good event, lot of technical sessions and labs, including self-paced and custom labs. I was presenting on TBSM practices in mobile telco industry and gave 2 labs myself, but also attended a lot of interesting sessions, like one about smarter building (given by Senior Technical Staff Member from IBM US), another about Tivoli Integrated Portal TIP future (TIP development/product manager) and another one, about IBM software development laboratory in Kraków, Poland (I’m part of it, so it was my duty to be there and show off a little bit
But sessions were numerous. Due to my responsibilities I couldn’t attend all of them, even if I wanted to do so. What I liked the most, was probably the self-paced labs section, where with some assistance from all-the-time-available instructors, you could go through one of selected IBM Tivoli product excercise/lab yourself, anytime during the conference, anyone! As far as I know it was the first time at ETTC, the idea itself comes from Pulse conference and is very popular there in Vegas. I’m sure it’ll be not the less popular at europeans events! It is a great chance for customers, partners, also us – IBMers, to learn many technical details directly from real specialists, and get answers on sometimes tricky questions. I strongly recommend you attending at least one SPL next time, however ask for SPL difficulty level, not all of them may meet your expectations.
I gave 2 labs myself, as I mentioned, and it was about integrating TBSM with Soap web services via WS DSA. I’m glad that many people came and they liked it, I promised to share more about what we did, so please stay in tune. I will try to share some of my thoughts also in this blog.
Meanwhile, you may want to browse the event pages, here it is:

http://www.ibm.com/training/conf/europe/Tivoli

All of you who attended the conference, you should have received an URL, that would contain all the conference resources – slides (not sure about labs, but I haven’t receive anything yet so it may be still pending). And I’m strongly recommending everybody else attending ETTC next year!

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.

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ł: http://www-01.ibm.com/support/docview.wss?uid=swg21380405). 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.

Platforma: Suse Linux Enterprise Server 10 x86, obraz vmware.
Produkty: OMNIbus 7.3, WebGUI 7.3, Impact 5.1.1
.
Opis:
Podjąłem się zintegrowania w/w produktów, lecz w najnowszych obecnie wersjach. Zamierzałem umieścić pliki w ramach 1 katalogu NCHOME: /opt/IBM/tivoli/netcool oraz jako pierwszy program, zainstalowałem OMNIbus. Instalacja poszła ok, następny jednak był Impact, który nie chciał się instalować. Otrzymywałem taki błąd:
IMPACTIN0031E The selected install path can not be used because an instance already exists there or a previous install left files behind, please try another.
.
Dzieje się tak, ponieważ instalator Impacta sprawdza wskazany mu katalog pod kątem istnienia katalogów specyficznych dla poprzednich instalacji, w tym “platform”. Ten katalog jest wspólny dla OMNIbusa i Impacta i mimo, że w przypadku świeżej instalacji kompletnie nie zawiera żadnych konfliktowych plików, zatrzymuje całą instalację Impacta. Dodatkowo, jeśli się przyjrzeć jego zawartości, zawiera on podkatalog linux2x86 jeśli zainstalowany został OMNIbus oraz linux, jeśli instalowany był Impact.
.
Rozwiązanie jest więc nastepujące:
- zainstaluj OMNIbus (jeśli jest to świeża instalacja)
- na czas instalacji zatrzymaj serwer omnibusa
- zmień katalog $NCHOME/platform na $NCHOME/_platform
- zainstaluj Impact, nie przejmuj się gdy instalator oznajmi, że nie może pod wskazanym adresem i portem odnaleźć pracującego ObjectServera, po prostu idź dalej.
- po zakończonej instalacji idź do katalogu $NCHOME/_platform i skopiuj jego zawartość do $NCHOME/platform, powinieneś widzieć wewnątrz dwa podkatalogi: linux2x86 (pliki OMNIbusa) i linux (pliki Impacta).
- uruchom OMNIbus
.
Powodzenia

Wątek niby oczywisty – TBSM 4.2.1 jest wspierany na platformach 64-bitowych, również na Windows 2008, ale w dokumentacji nie jest jasno wyjaśnione, czy także R2? O tym, oraz parę innych grepsów poniżej.
Zdarzyło mi się, że musiałem zainstalować TBSM na rzeczonym Windows 2008 Server Standard Edition R2 64bit (uff..). Oczywiście startuję instalator i bardzo szybko zostaję poinformowany o niechodzących usługach Windows. Bułeczka z masłem…
1) Greps dot. usług windows
Wejdź do Narzędzia Administracyjne->Usługi i włącz usługi: Server oraz Secondary Logon. Następnie najlepiej zacznij instalację od nowa, choć powinno się udać także z klikaniem Dalej (mi się udało).

No i dobrze, teraz pójdzie z płatka. Nic bardziej mylnego, instalacja bardzo szybko wywraca się, a w logu TBSMInstall-00.log, który wygenerowany został w katalogu domowym naszego dzielnego użytkownika, czytamy: UnrecognizedOSException. Cóż to? Dlaczego instalator stwierdził obecność 32-bitowej Visty? Może jednak R2 nie jest wspierane? Otóż jest, ale dopiero przez FP1, nie wersję GA.
2) Greps dot. wspieranej wersji Windows 2008
Ściągnij FP1 lub FP2 do TBSM i skopiuj sobie plik /TBSM/DE/.data/setup.jar a następnie użyj go zamiast oryginalnego w instalce podstawki TBSM. Cała sztuczka jest opisana w readme do FP1/FP2.

Uff.. ruszyło. Czy aby na pewno? Zaraz rozbijemy się bowiem o kolejną rafę: Postgres. Po pierwsze uwaga na to, w jaki sposób podłączyłeś się do swojego ukochanego Windows 2008. Jeśli siedzisz przy maszynie fizycznie, nic Ci nie grozi (tym razem). Ale zapewne Windows jest gdzieś dalej a Ty używasz Remote Desktop. Zaleca się w takim wypadku połączenie w trybie konsolowym.
3) Greps dot. Postgres – po raz pierwszy
Podłącz się do Windows RDP w trybie konsoli, np. wywołując mstsc /console (wersja 6.0) lub mstsc /admin (wersja 6.1).

Postgres to jeszcze conajmniej jedno wyzwanie. Użytkownik pgservice, domyślnie używany do uruchomienia usługi Tivoli Postgres Database, powinien spełniać kilka kryteriów. Nie może być Administratorem ani Super użytkownikiem. Powinien mieć przypisane prawa Log on Locally oraz Log on as a service. Uwaga, zdaje się, że domyślnie Log on Locally nie jest prawem zwykłych użytkowników, oraz jest prawem objętym polityką, więc może nie być łatwo to zmienić. Można za to spróbować dodać pgservice do grupy Backup Operators, która takie prawo posiada. Ostatnia sprawa to uprawnienie zapisu do katalogu %TBSM_HOME% – domyślnie użytkownicy takiego prawa nie posiadają i należy je dodać. Ogólnie polecam utworzenie użytkownika pgservice ręcznie w panelach administracyjnych Windows, dodać uprawnienia itp. a następnie, podczas instalacji, podać jedynie nazwę i hasło, zatem ominąć opcję “Create Windows user”.
4) Greps dot. Postgres – po raz drugi
Stwórz ręcznie użytkownika pgservice, dodaj prawa Log on Locally oraz Log on as a service, prawo zapisu do %TBSM_HOME%

Niestety życie jest brutalne, i powyższy greps może nie pomóc. W takim wypadku należy przyjrzeć się uważniej zawalonej instalacji postgres. Czy został utworzony katalog %TBSM_HOME%\pgsql8\data ? Jeśli nie, a w logach powtarza się zapis, że nie można znaleźć pg_hba.conf w tymże katalogu, znaczy to, że postgres się nie zainicjował do końca i nie zostały utworzone pliki bazodanowe. Można zrobić to samemu ręcznie, zalecam lekturę Install Guide, rozdział poświęcony nieudanej instalacji postgres, jest tam jednak błąd, jeden z parametrów pwfile należy podawać z dwoma myślnikami, nie jednym. A więc:
5) Greps dot. Postgres – po raz trzeci
Utwórz C:\temp\pfile.txt zawierający hasło użytkownika wewnętrznego bazy postgres, np. netcool (to co zostało podane podczas instalacji)
Wykonaj: runas /user:pgservice “C:\IBM\tivoli\tbsm\pgsql8\bin\initdb.exe –locale=C -U postgres -A md5 –pwfile C:\temp\pfile.txt -D C:\IBM\tivoli\tbsm\pgsql8\data”
Uruchom usługę Windows: Tivoli Postgres Database
Wykonaj: C:\IBM\tivoli\tbsm\bin\rad_db setupinit
Zaloguj się do rad_db log i sprawdz, czy tabele zostały utworzone poprawnie (\d+).

Życie byłoby jednak zbyt piękne gdyby to okazało się już być wszystkim co trzeba. Niestety, nawet powyższe kroki mogą nie spowodować, że TBSM da się uruchomić. Nawet jeśli usługa Windows TBSMDataServer będzie uruchomiona, na porcie 17310 może nie być nasłuchu, a więc de facto TBSM może nie działać. Jeśli przyjrzysz się uważnie, dziać się tak może, ponieważ usługa działa niestabilnie – pracuje, po czym samoczynnie wchodzi w tryb uruchomienia ponownie. Dlatego na koniec jeszcze jedno rozwiązanie, które okazało się w moim przypadku powodować problem: IP v6. Oczywiście było włączone i zorientowałem się w tym po 24 godzinach od napotkania problemu po raz pierwszy, po dziesiątkach prób, obejść, stosowania powyższych rad w praktyce. Nic nie działało, TBSM dalej psuł się na etapie instalacji Postgresa, a po zainicjowaniu serwera ręcznie jak w grepsie 5, usługa windows TBSM dataserver była niestabilna a w trace.log widniał wpis, że nie można nawiązać połączenia JDBC z bazą danych postgres. IP v6 teoretycznie jest przez TBSM 4.2.1 GA wspierane, ale prawdopodobnie nie działa dla sterownika JDBC Postgresa i należy je wyłączyć. Oprócz wyłączenia, pomocne może się okazać stosowanie lokalnej tablicy hostów w formacie IP v4 w C:\Windows\system32\drivers\etc\hosts. Instalowanie wszystkiego lokalnie na 1 komputerze pod adresem localhost powinno zadziałać mimo IPv6.
6) Greps 6. dot IPv6
Sprawdź czy jest używane i wyłącz, a następnie zgłoś problem pracownikom wsparcia z IBM.

To już wszystko. Po powyższych krokach (udało mi się nawet pominąć 5) zainstalowałem TBSM 4.2.1 na dwóch serwerach Windows 2008 R2 pomyślnie. Jeśli są jakieś pytania, postaram się zatem pomóc. Tymczasem – powodzenia!

Tym razem postanowiłem podzielić się swoim doświadczeniem z zakresu przygotowania ekranu operacyjnego TBSM w technologii Tivoli Integrated Portal. Popularne “dashboardy” są ważnym elementem wystroju każdego pokoju-centrum operacji IT. Wyświetlone na ścianie lub ekranach monitorów, informują o bieżącym stanie infrastruktury IT – stanie bezpieczeństwa, dostępności, obciążenia itp. Jeśli zostały dobrze przygotowane, to mimo gąszczu kolorowych ikon, wykresów, liczb i mapek umożliwiają błyskawiczną, przynajmniej pobieżną ocenę sytuacji w sieci i serwerowni przedsiębiorstwa.
Ponieważ BSM polega na zarządzaniu usługami biznesowymi, a więc usługami, których związek z IT reguluje się poprzez zestaw reguł, zależności i polityk, lecz same w sobie niekoniecznie są czytelne dla pracowników operacyjnych, ekrany operacyjne (dashboard-y) w BSM wyglądają nieco inaczej, a konkretnie zawierają inny zestaw danych, przedstawiony w sposób interesujący dla odbiorcy biznesowego. I tenże odbiorca, a raczej jego specyfika, warunkuje sposób, w jaki ekrany operacyjne w BSM zostaną zaprojektowane.
W przeciwieństwie do typowych ekranów operacyjnych, obfitujących w dane nt. zdarzeń technicznych, czasów odpowiedzi itp., ekrany BSM charakteryzują się prostotą. Zapracowany manager lub sprzedawca wymagają prostego, jasnego ale i precyzyjnego przekazu informacji, której poszukują. Oczywiście, niektórzy managerowie, którzy w przeszłości wykonywali prace inżynierskie, są zainteresowani szczegółami technicznymi, i jeśli życzą sobie dostępu do tego stopnia szczegółów, jak czasy odpowiedzi serwerów, to należy im to umożliwić. Jednak zazwyczaj ekrany BSM to przede wszystkim proste pulpity kontrolne, plansze, które zawierają najważniejsze usługi biznesowe, ich status, ew. liczby, takie jak udział procentowy poprawnie działających usług w stosunku do całej puli.
W zasadzie nie ma jednego dobrego przepisu na stworzenie pulpitu typu dashboard. Wszystko zależy od ostatecznego odbiorcy. I tu pierwsza dobra praktyka – należy zrozumieć kto i jak często będzie spoglądał na planszę z usługami. Te informacje uwarunkują bezpośrednio wstępną konfigurację bezpieczeństwa – konfigurację użytkowników, grup i ról z dostępem do do poszczególnych sekcji ekranu. Pewną praktyką jest również przygotowanie elementów wizualnych, tu można posługiwać się katalogiem elementów tożsamości wizualnej przedsiębiorstwa, jeśli taki istnieje (można zapytać w dziale marketingu lub komunikacji). Mam na myśli głównie logo i barwy przedsiębiorstwa, inne motywy graficzne, takie jak zdjęcia i grafiki, oczywiście na używanie których posiadamy licencję.
Z pewnością należy zapoznać się z treścią istniejących reguł, zależności i mapowaniem zasobów IT na usługi biznesowe, katalog zdarzeń, usług i KPI/KQI. Musimy mieć pewność, że informacja, którą przedstawimy na ekranie, będzie znacząca i potrzebna. W razie konieczności należy być może przeprojektować ten zestaw, tak, aby odpowiadał potrzebom naszego dashboardu.
Na koniec warto narysować dashboard na papierze lub utworzyć sobie projekt w programie komputerowym, a następnie krok po kroku, konsultując zmiany z klientem-odbiorcą, doprowadzić do powstania finalnego projektu, którego wdrożeniem zajmę się w następnych wpisach.
Powodzenia!