Wsparcie IBM ILMT: rozwiazywanie najczestszych problemow

Gdzie szukac wsparcia IBM ILMT

Kiedy cos idzie nie tak z ILMT, pierwsze pytanie brzmi zazwyczaj "do kogo sie zwrocic?" Odpowiedz zalezy od rodzaju problemu i od tego, jak szybko potrzebujesz rozwiazania.

Oficjalne wsparcie IBM

IBM oferuje wsparcie dla ILMT przez IBM Support Portal (dawniej IBM Support Assistant). Mozesz otworzyc zgloszenie, przeszukiwac baze wiedzy (technotes) i pobierac poprawki z IBM Fix Central. Dokumentacja jest dokladna, a baza wiedzy obejmuje wiekszosc znanych problemow ze szczegolowymi krokami naprawczymi.

Tu trzeba byc szczerym. ILMT jest darmowym narzedziem. IBM dostarcza go bez oplat licencyjnych klientom Passport Advantage, i to zmienia dynamike wsparcia. Zgloszenia dotyczace ILMT nie generuja przychodu dla IBM w taki sposob jak tickety Db2 czy WebSphere. W praktyce oznacza to, ze czasy odpowiedzi bywaja dlugie. Widzielismy przypadki, gdy prosty problem z ILMT czekal dwa do trzech tygodni na merytoryczna odpowiedz. Podczas audytu taki harmonogram jest nie do przyjecia.

Niemniej wsparcie IBM to wlasciwy kanal w przypadku faktycznych bledow produktu, problemow z aktualizacja i spraw wymagajacych dostepu do kodu zrodlowego ILMT lub wewnetrznego zespolu inzynieryjnego. Jesli ILMT ulega awarii po aktualizacji lub generuje uszkodzone Audit Snapshoty, IBM jest jedyna strona, ktora moze dostarczyc poprawke na poziomie produktu.

Zasoby spolecznosci

Fora IBM Community (konkretnie sekcje BigFix i ILMT) sa zaskakujaco przydatne. Inni administratorzy ILMT publikuja pytania i dziela sie rozwiazaniami. Pracownicy IBM takze czasem odpowiadaja, choc bez gwarantowanego czasu reakcji. W przypadku typowych problemow konfiguracyjnych wyszukiwanie na forum czesto ujawnia kogos, kto napotkaj ten sam problem i opisal swoje rozwiazanie.

Niezalezni specjalisci

Tu wkraczaja firmy takie jak nasza. Niezalezni konsultanci ILMT pracuja z tym narzedziem codziennie, w dziesieciach srodowisk klienckich. Widzimy te same problemy wielokrotnie, wiec zazwyczaj potrafimy je zdiagnozowac i naprawic szybciej niz ogolna kolejka wsparcia IBM. Kompromisem jest koszt. Wsparcie IBM jest wliczone w Twoja umowe Passport Advantage, a pomoc zewnetrzna to platna usluga. Ale kiedy potrzebujesz rozwiazania w tym tygodniu, a nie za miesiac, ten koszt jest czesto uzasadniony.

10 najczestszych problemow z ILMT

Pracujemy ze srodowiskami ILMT w calej Europie i po latach doswiadczen mozemy powiedziec z pelnym przekonaniem, ze 90% problemow z ILMT wpada w te same dziesiec kategorii. Oto one, wraz z praktycznymi krokami diagnostycznymi dla kazdego z nich.

1. Agenty nie raportuja

To zdecydowanie najczestszy problem z ILMT. Agent BigFix przestaje wysylac dane do serwera, a ILMT traci widocznosc danego endpointa. Jesli na tym endpoincie dziala oprogramowanie IBM, masz luke w danych zgodnosci.

Zacznij od sprawdzenia uslugi BESClient na dotkietej maszynie. Czy dziala? Jesli nie, uruchom ja ponownie. Jesli dziala, ale nadal nie raportuje, problem jest prawie na pewno zwiazany z siecia. Agent komunikuje sie ze swoim relay BigFix na porcie 52311 (TCP). Zmiany w firewallach, aktualizacje segmentacji sieci lub zmiany konfiguracji VPN moga zablokowac ten ruch bez niczyjej wiedzy.

Otworz konsole BigFix i sprawdz kolumne "Last Report Time" dla dotkietych endpointow. Jesli pokazuje wiecej niz 7 dni wstecz, ten agent wymaga uwagi. W duzych srodowiskach zalecamy stworzenie dashboardu BigFix lub automatycznego alertu, ktory flaguje agenty milczace dluzej niz 48 godzin. Odkrycie podczas audytu, ze 15% agentow bylo offline przez miesiace, jest bolesnym doswiadczeniem.

2. Nieaktualny katalog oprogramowania

ILMT identyfikuje oprogramowanie IBM przez dopasowywanie sygnatur plikow do wbudowanego katalogu. IBM regularnie aktualizuje ten katalog, aby objac nowe wersje produktow, poprawic bledne identyfikacje i poprawic dokladnosc detekcji. Kiedy katalog jest nieaktualny, ILMT zaczyna pokazywac wpisy "unknown" dla produktow, ktore powinien rozpoznawac, lub blednie identyfikuje jeden produkt jako inny.

Naprawa jest prosta. Pobierz najnowszy katalog ze strony IBM lub uzyj fixleta aktualizacji katalogu BigFix ILMT, aby wypchnac aktualizacje automatycznie. IBM zazwyczaj publikuje aktualizacje katalogu co kilka tygodni, ale kwartalna aktualizacja jest rozsadnym harmonogramem dla wiekszosci organizacji. Upewnij sie tylko, ze ktos faktycznie jest za to odpowiedzialny, bo w praktyce nikt nie jest i katalog po cichu staje sie pol roku nieaktualny.

3. Nagle skoki PVU

Generujesz raport i wartosci PVU dla produktu dramatycznie wzrosly w porownaniu z ubieglym miesiacem. Zanim wpadniesz w panike, sprawdz trzy rzeczy.

Po pierwsze, sprawdz zmiany konfiguracji VM. Czy ktos zwieksyl liczbe vCPU na maszynie wirtualnej z oprogramowaniem IBM? ILMT oblicza PVU na podstawie szczytowej pojemnosci w okresie raportowania, wiec tymczasowe zwiekszenie na potrzeby testow wydajnosciowych i tak sie liczy. Po drugie, sprawdz migracje DRS. W srodowiskach VMware z wlaczonym Dynamic Resource Scheduler maszyna wirtualna moze migrowac na hosta z wieksza liczba fizycznych rdzeni. To zmienia obliczenia PVU nawet jesli sama liczba vCPU maszyny sie nie zmienila. Po trzecie, zweryfikuj mapowanie procesorow. ILMT uzywa tablicy PVU IBM do przeliczania rdzeni procesorow na wartosci PVU. Jesli dodano nowy model serwera do srodowiska, a ILMT nie ma prawidlowego mapowania, obliczenie PVU moze byc bledne.

Otworz inwentarz sprzetowy ILMT dla dotkietego serwera i porownaj aktualne informacje o procesorze z poprzednim okresem raportowania. Odpowiedz zazwyczaj tam sie znajdzie.

4. Raporty pokazuja 0 PVU dla znanych produktow IBM

Wiesz, ze WebSphere dziala na serwerze, ale raporty ILMT pokazuja dla niego 0 PVU. To problem z regulami bundlingu. Produkt jest wykrywany przez skaner, ale jest przypisany do zlej metryki licencyjnej lub wylaczony z obliczen PVU ze wzgledu na konfiguracje bundlingu.

Sprawdz konfiguracje bundlingu w katalogu oprogramowania ILMT. Czasem produkt jest przypisany do pakietu, ktory ustawia jego wklad PVU na zero, poniewaz IBM traktuje go jako zawarty w innym produkcie. Jesli Twoje faktyczne uprawnienia nie odpowiadaja temu zalozeniu bundlingowemu, raport jest mylacy. To jeden z tych problemow, ktory wyglada nieszkodliwie, ale powoduje powazne konsekwencje podczas audytu. Audytor, ktory zobaczy znany produkt IBM z zerowym zuzyciem PVU, zacznie kopac glebiej.

5. Spadek wydajnosci serwera ILMT

ILMT dzialal szybko zaraz po wdrozeniu. Teraz importy danych trwaja godzinami, interfejs webowy jest powolny, a generowanie Audit Snapshota przeciaza serwer. To problem wzrostu bazy danych.

ILMT przechowuje historyczne dane ze skanow, a z czasem baza danych rosnie. Srodowiska z wiecej niz 5000 endpointow sa szczegolnie narazone na ten problem. Rozwiazaniem jest polaczenie konserwacji bazy danych (reorganizacja tabel, aktualizacja statystyk), archiwizacji starych danych, ktore nie sa juz potrzebne do celow zgodnosci, i ewentualnie zwiekszenia zasobow CPU i pamieci serwera. Dokumentacja IBM zawiera szczegolowe wytyczne dotyczace harmonogramow konserwacji bazy danych ILMT. Jesli nigdy nie uruchamiales zadan konserwacyjnych na swojej bazie ILMT, zacznij od tego.

6. Zdublowane wpisy w katalogu oprogramowania

Ten sam produkt IBM pojawia sie wielokrotnie w raportach ILMT, czasem z roznymi metrykami licencyjnymi. Dzieje sie tak zazwyczaj, gdy niestandardowe sygnatury oprogramowania koliduja z wbudowanymi wpisami katalogu IBM. Jesli ktos stworzyl wlasna sygnature dla produktu, ktory IBM pozniej dodal do oficjalnego katalogu, koncowo masz dwa wpisy.

Przejrzyj swoje niestandardowe sygnatury i porownaj je z aktualnym oficjalnym katalogiem. Usun wszystkie wlasne wpisy, ktore pokrywaja sie z tym, co katalog IBM juz obejmuje. Po oczyszczeniu reimportuj katalog i pozwol ILMT ponownie przetworzyc dane. Duplikaty powinny zniknac przy nastepnym cyklu importu.

7. Brak danych wirtualizacji VMware

ILMT pokazuje "unknown" jako typ wirtualizacji na serwerach, o ktorych wiesz, ze sa maszynami wirtualnymi VMware. Oznacza to, ze ILMT nie jest w stanie okreslic fizycznego hosta, na ktorym dzialaja te VM, a bez tej informacji nie moze obliczyc wartosci PVU sub-capacity. Te maszyny wirtualne domyslnie podlegaja obliczeniom full-capacity w raportach.

Zrodlem problemu jest prawie zawsze narzedzie BigFix VM Manager. Ten komponent laczy sie z Twoim vCenter i pobiera dane mapowania VM-do-hosta, ktorych potrzebuje ILMT. VM Manager albo w ogole nie jest skonfigurowany, dane logowania do vCenter wygasly, albo polaczenie z vCenter jest blokowane przez firewall. Sprawdz konfiguracje VM Manager w konsoli BigFix, zweryfikuj dane logowania i upewnij sie, ze serwer BigFix moze nawiazac polaczenie z vCenter na wymaganych portach. W srodowiskach, gdzie zespol VMware i zespol ILMT to oddzielne grupy, ta integracja czesto po cichu sie psuje, bo nikt nie jest odpowiedzialny za polaczenie miedzy tymi dwoma systemami.

8. Niekompletne dane PowerVM LPAR

Jesli uruchamiasz oprogramowanie IBM na systemach Power, ILMT potrzebuje danych z Hardware Management Console (HMC), aby obliczac wartosci sub-capacity dla Twoich partycji LPAR. Kiedy te dane sa brakujace lub niekompletne, ILMT domyslnie stosuje licencjonowanie full-capacity dla dotkietych systemow Power. Na serwerze POWER9 z 24 rdzeniami po 120 PVU na rdzen roznica miedzy sub-capacity a full-capacity moze byc ogromna.

Sprawdz konfiguracje polaczenia HMC w ILMT. Najczestsze przyczyny to dane logowania HMC zmienione podczas rutynowej konserwacji bez aktualizacji konfiguracji ILMT, zmiany w polaczeniu sieciowym miedzy serwerem ILMT a HMC, lub aktualizacje firmware HMC ktore zmienily zachowanie API. Jesli niedawno aktualizowalei firmware HMC, zweryfikuj czy polaczenie z ILMT nadal dziala.

9. Aktualizacja ILMT psuje raporty

Zaktualizowales ILMT do najnowszej wersji i teraz Twoje historyczne raporty wygladaja inaczej. Wartosci PVU sie zmienily, produkty ktore wczesniej byly prawidlowo identyfikowane teraz pokazuja inne wartosci, lub format Audit Snapshota uleg zmianie. To frustrujace, ale sie zdarza.

IBM czasem zmienia metodologie obliczen, logike dopasowywania katalogu lub formaty raportow miedzy wersjami ILMT. Sama aktualizacja nie jest bledna. Nowa wersja po prostu inaczej interpretuje te same dane. Przed aktualizacja zawsze przeczytaj notatki wydania (release notes) dla docelowej wersji. Dokumentuja one zmiany w zachowaniu obliczen i znane problemy. Jesli jestes w trakcie audytu lub zbliasz sie do przegladu zgodnosci, odloz aktualizacje na czas po zakonczeniu tego procesu. I zawsze testuj aktualizacje na instancji nieprodukcyjnej ILMT, jesli taka posiadasz.

10. Agent wdrozony, ale nie skanuje

Agent BigFix jest zainstalowany i raportuje do serwera. Widzisz endpoint w konsoli BigFix. Ale ILMT nie ma danych ze skanowania oprogramowania dla tej maszyny. Agent jest zdrowy, wiec co sie dzieje?

Sam fakt, ze agent BigFix jest online, nie oznacza automatycznie, ze przeprowadza skanowanie oprogramowania. Skan oprogramowania to oddzielna akcja, ktora musi byc skierowana na endpoint przez konsole BigFix. Sprawdz status akcji skanowania dla dotkietej maszyny. Poszukaj fixleta skanowania oprogramowania ILMT i zweryfikuj, czy zostal aktywowany i pomyslnie zastosowany. W srodowiskach, gdzie regularnie dodaje sie nowe serwery, latwo pominac skierowanie akcji skanowania na nowe endpointy, szczegolnie jesli proces wdrazania nie obejmuje kroku aktywacji skanowania BigFix.

Kiedy szukac pomocy, a kiedy naprawic samemu

Nie kazdy problem z ILMT wymaga pomocy z zewnatrz. Oto uczciwy podzial na to, co mozesz ogarnac wewnetrznie, a co warto eskalowac.

Napraw samodzielnie

Problemy z polaczeniami agentow sa najczestszym problemem ILMT i zazwyczaj najlatwiejszym do rozwiazania. Jesli BESClient jest zatrzymany, uruchom go ponownie. Jesli firewall blokuje port 52311, uzgodnij z zespolem sieciowym jego otwarcie. To zadania operacyjne, ktore Twoj zespol infrastruktury moze obsluzyc przy podstawowej znajomosci BigFix.

Aktualizacje katalogu to rowniez zadanie do samodzielnego wykonania. Pobierz najnowszy katalog, zastosuj go przez fixlet BigFix i zweryfikuj, czy import zakonczyl sie poprawnie. To okolo 30 minut aktywnej pracy.

Zalezy od zlozonosci

Problemy z katalogiem wykraczajace poza proste aktualizacje naleza do szarej strefy. Jesli masz zdublowane wpisy, kolidujace niestandardowe sygnatury lub produkty, ktore ILMT blednie identyfikuje, naprawa wymaga zrozumienia, jak dziala mechanizm dopasowywania katalogu ILMT na poziomie technicznym. Niektoree organizacje maja te wiedze w zespole. Wiele nie ma.

Problemy z integracja VMware i PowerVM sa podobne. Jesli naprawa polega na "zaktualizuj haslo do vCenter w VM Manager", nie potrzebujesz pomocy. Jesli naprawa wymaga przebudowy sposobu zbierania danych o wirtualizacji przez ILMT w wielu vCenter w roznych strefach sieciowych, to juz inna rozmowa.

Siegnij po pomoc eksperta

Problemy z danymi zwiazane z audytem to obszar, gdzie bledy sa kosztowne. Jesli Twoje dane ILMT maja luki, nieprawidlowe obliczenia PVU lub brakujace serwery, a stoisz w obliczu audytu IBM lub przegladu zgodnosci, siegnij po profesjonalna pomoc. Koszt konsultanta przegladajacego Twoje dane to ulamek tego, ile kosztowaloby stwierdzenie audytowe o nielicencjonowanym oprogramowaniu. Widzielismy organizacje, ktore probowaly naprawic dane ILMT samodzielnie przed audytem i pogorszyly sytuacje, usuwajac dane lub blednie konfigurujac reguly bundlingu.

Jesli Twoj ILMT byl zaniedbany przez szesc miesiecy lub dluzej, profesjonalny przeglad jest prawie zawsze szybszy niz rozwiazywanie problemow po kolei. Doswiadczony konsultant moze ocenic calef srodowisko w kilka dni i przygotowac priorytetyzowany plan naprawczy. Wykonanie tego samego wewnetrznie, bez rozpoznawania wzorcow plynacego z pracy z dziesiatkami srodowisk ILMT, zajmuje zazwyczaj tygodnie.

Zasoby wsparcia IBM ILMT

Oto kluczowe zasoby, ktore warto miec pod reka, jesli zarzadzasz srodowiskiem ILMT.

Dokumentacja IBM ILMT to oficjalna dokumentacja produktu umieszczona w IBM Knowledge Center. Obejmuje instalacje, konfiguracje, rozwiazywanie problemow i interpretacje raportow. Dokumentacja jest szczegolowa, ale nawigacja po niej bywa utrudniona. Zacznij od sekcji rozwiazywania problemow, jesli masz konkretna kwestie do rozstrzygnecia.

IBM Fix Central to miejsce, z ktorego pobierasz poprawki ILMT, aktualizacje i pliki katalogu. Dodaj te strone do zakladek, bo bedziesz jej potrzebowal przy kazdej aktualizacji katalogu oprogramowania lub zastosowaniu wersji serwisowej.

Forum BigFix (czesc IBM Community) to najbardziej aktywne zrodlo spolecznosciowe dla pytan o BigFix i ILMT. Inni administratorzy dziela sie rozwiazaniami, pracownicy IBM czasem odpowiadaja, a mozesz przeszukiwac lata zarchiwizowanych dyskusji w poszukiwaniu odpowiedzi na typowe problemy.

Notatki wydania ILMT (release notes) sa publikowane z kazda nowa wersja i poprawka. Zawsze czytaj je przed aktualizacja. Dokumentuja nowe funkcje, poprawki bledow, znane problemy i zmiany w metodologii obliczen, ktore moga wplynac na Twoje raporty.

Tablica PVU IBM wymienia wartosci PVU dla kazdego modelu procesora, ktory IBM rozpoznaje. Ta tablica jest aktualizowana, gdy pojawiaja sie nowe modele procesorow. Jesli ILMT pokazuje nieoczekiwane wartosci PVU dla nowego modelu serwera, sprawdz czy tablica PVU w Twojej instalacji ILMT jest aktualna.

Zapobieganie problemom z ILMT

Wiekszosc problemow z ILMT, ktore widzimy, mozna bylo zapobiec. Pojawiaja sie, bo nikt aktywnie nie zajmuje sie utrzymaniem systemu. ILMT to jedno z tych narzedzi, ktore dziala po cichu w tle, dopoki nie przestanie, a wtedy masz przed soba miesiace nawarstwionych problemow do rozplatania.

Oto praktyczna checklista zapobiegawcza.

Co miesiac: przeglad stanu agentow. Sprawdz w konsoli BigFix agenty, ktore nie raportowaly w ciagu ostatnich 7 dni. Skonfiguruj automatyczny alert, jesli Twoja wersja BigFix to obsluguje. Naprawiaj nieraportujace agenty natychmiast, zamiast pozwalac liście rosnac. Ten jeden nawyk zapobiega najczestszemu problemowi ILMT.

Co kwartal: aktualizacja katalogu oprogramowania. Pobierz i zastosuj najnowszy katalog od IBM. Zweryfikuj, ze import zakonczyl sie bez bledow. Przejrzyj wszystkie nowe wpisy "unknown" ktore pojawily sie po aktualizacji i zbadaj je. Aktualny katalog oznacza dokladna identyfikacje produktow.

Co kwartal: przeglad raportow. Wygeneruj Audit Snapshot i przejrzyj go pod katem anomalii. Szukaj nieoczekiwanych skokow PVU, produktow pokazujacych 0 PVU, serwerow bez danych i wpisow z "nieznan" wirtualizacja. Wychwycenie tych problemow kwartalnie oznacza, ze masz do zbadania najwyzej trzy miesiace danych, a nie trzy lata.

Na biezaco: dokumentuj konfiguracje ILMT. Zapisz polaczenia z vCenter, konfiguracje HMC, niestandardowe reguly bundlingu i wszystkie niestandardowe ustawienia w srodowisku ILMT. Kiedy osoba, ktora pierwotnie konfigurowala ILMT, odejdzie z firmy (a odejdzie), ta dokumentacja to roznica miedzy plynnym przekazaniem a zaczynaniem od zera.

Przed kazda aktualizacja: testuj na srodowisku nieprodukcyjnym. Jesli masz testowe srodowisko ILMT, zaktualizuj je najpierw i sprawdz, czy raporty wygladaja poprawnie, zanim dotkniesz produkcji. Jesli nie masz srodowiska testowego, wygeneruj przynajmniej pelny Audit Snapshot przed aktualizacja, aby miec punkt odniesienia do porownania po zakonczeniu procesu.

Najczesciej zadawane pytania