Spis treści
Gdzie szukać wsparcia IBM ILMT
Kiedy coś idzie nie tak z ILMT, pierwsze pytanie brzmi zwykle: „do kogo się zwrócić?" Odpowiedź zależy od rodzaju problemu i od tego, jak szybko potrzebujesz rozwiązania.
Oficjalne wsparcie IBM
IBM oferuje wsparcie dla ILMT przez IBM Support Portal. Otwierasz zgłoszenie, przeszukujesz bazę wiedzy (technotes) i pobierasz poprawki z IBM Fix Central. Dokumentacja jest dokładna, a baza wiedzy obejmuje większość znanych problemów ze szczegółowymi krokami naprawczymi.
Tu trzeba być szczerym. ILMT jest bezpłatnym narzędziem. IBM dostarcza go bez opłat licencyjnych klientom Passport Advantage, i to zmienia dynamikę wsparcia. Zgłoszenia dotyczące ILMT nie generują przychodu dla IBM w taki sposób jak tickety Db2 czy WebSphere. W praktyce oznacza to, że czasy odpowiedzi bywają długie. Widzieliśmy przypadki, gdy prosty problem z ILMT czekał dwa do trzech tygodni na merytoryczną odpowiedź. Podczas audytu taki harmonogram jest nie do przyjęcia.
Niemniej wsparcie IBM to właściwy kanał w przypadku faktycznych błędów produktu, problemów z aktualizacją i spraw wymagających dostępu do kodu źródłowego ILMT lub wewnętrznego zespołu inżynieryjnego. Jeśli ILMT ulega awarii po aktualizacji lub generuje uszkodzone Audit Snapshoty, IBM jest jedyną stroną, która może dostarczyć poprawkę na poziomie produktu.
Zasoby społeczności
Fora IBM Community (konkretnie sekcje BigFix i ILMT) są zaskakująco przydatne. Inni administratorzy ILMT publikują pytania i dzielą się rozwiązaniami. Pracownicy IBM także czasem odpowiadają, choć bez gwarantowanego czasu reakcji. W przypadku typowych problemów konfiguracyjnych wyszukiwanie na forum często ujawnia kogoś, kto napotkał ten sam problem i opisał swoje rozwiązanie.
Niezależni specjaliści
Tu wkraczają firmy takie jak nasza. Niezależni konsultanci ILMT pracują z tym narzędziem codziennie, w dziesiątkach środowisk klienckich. Widzimy te same problemy wielokrotnie, więc zwykle potrafimy je zdiagnozować i naprawić szybciej niż ogólna kolejka wsparcia IBM. Kompromisem jest koszt. Wsparcie IBM jest wliczone w Twoją umowę Passport Advantage, a pomoc zewnętrzna to płatna usługa. Ale kiedy potrzebujesz rozwiązania w tym tygodniu, a nie za miesiąc, ten koszt jest zwykle uzasadniony.
10 najczęstszych problemów z ILMT
Pracujemy ze środowiskami ILMT w całej Europie i po latach doświadczeń możemy powiedzieć z pełnym przekonaniem, że 90% problemów z ILMT wpada w te same dziesięć kategorii. Oto one, wraz z praktycznymi krokami diagnostycznymi dla każdego z nich.
1. Agenty nie raportują
To zdecydowanie najczęstszy problem z ILMT. Agent BigFix przestaje wysyłać dane do serwera, a ILMT traci widoczność danego endpointa. Jeśli na tym endpoincie działa oprogramowanie IBM, masz lukę w danych zgodności.
Zacznij od sprawdzenia usługi BESClient na dotkniętej maszynie. Czy działa? Jeśli nie, uruchom ją ponownie. Jeśli działa, ale nadal nie raportuje, problem jest prawie na pewno związany z siecią. Agent komunikuje się ze swoim relay BigFix na porcie 52311 (TCP). Zmiany w firewallach, aktualizacje segmentacji sieci lub zmiany konfiguracji VPN mogą zablokować ten ruch bez niczyjej wiedzy.
Otwórz konsolę BigFix i sprawdź kolumnę „Last Report Time" dla dotkniętych endpointów. Jeśli pokazuje więcej niż 7 dni wstecz, ten agent wymaga uwagi. W dużych środowiskach zalecamy stworzenie dashboardu BigFix lub automatycznego alertu, który flaguje agenty milczące dłużej niż 48 godzin. Odkrycie podczas audytu, że 15% agentów było offline przez miesiące, jest bolesnym doświadczeniem.
2. Nieaktualny katalog oprogramowania
ILMT identyfikuje oprogramowanie IBM przez dopasowywanie sygnatur plików do wbudowanego katalogu. IBM regularnie aktualizuje ten katalog, aby objąć nowe wersje produktów, poprawić błędne identyfikacje i poprawić dokładność detekcji. Kiedy katalog jest nieaktualny, ILMT zaczyna pokazywać wpisy „unknown" dla produktów, które powinien rozpoznawać, lub błędnie identyfikuje jeden produkt jako inny.
Naprawa jest prosta. Aktualny kanał dystrybucji to fixlet site BigFix Inventory, katalog pojawia się tam automatycznie i stosujesz go przez fixlet. Dla starszych instalacji ILMT 9.x oraz środowisk odseparowanych możesz pobrać paczkę katalogu i zaimportować ją ręcznie. W obu przypadkach IBM publikuje aktualizacje co kilka tygodni, a aktualizacja raz na kwartał to minimum, które zalecamy dla produkcji. Upewnij się tylko, że ktoś faktycznie za to odpowiada, bo w praktyce nikt tego nie robi i katalog po cichu staje się pół roku nieaktualny.
3. Nagłe skoki PVU
Generujesz raport i wartości PVU dla produktu dramatycznie wzrosły w porównaniu z ubiegłym miesiącem. Zanim wpadniesz w panikę, sprawdź trzy rzeczy.
Po pierwsze, sprawdź zmiany konfiguracji VM. Czy ktoś zwiększył liczbę vCPU na maszynie wirtualnej z oprogramowaniem IBM? ILMT oblicza PVU na podstawie szczytowej pojemności w okresie raportowania, więc tymczasowe zwiększenie na potrzeby testów wydajnościowych i tak się liczy. Po drugie, sprawdź migracje DRS. W środowiskach VMware z włączonym Dynamic Resource Scheduler maszyna wirtualna może migrować na hosta z większą liczbą fizycznych rdzeni. To zmienia obliczenia PVU, nawet jeśli sama liczba vCPU maszyny się nie zmieniła. Po trzecie, zweryfikuj mapowanie procesorów. ILMT używa tablicy PVU IBM do przeliczania rdzeni procesorów na wartości PVU. Jeśli dodano nowy model serwera do środowiska, a ILMT nie ma prawidłowego mapowania, obliczenie PVU może być błędne.
Otwórz inwentarz sprzętowy ILMT dla dotkniętego serwera i porównaj aktualne informacje o procesorze z poprzednim okresem raportowania. Odpowiedź zwykle tam się znajduje.
4. Raporty pokazują 0 PVU dla znanych produktów IBM
Wiesz, że WebSphere działa na serwerze, ale raporty ILMT pokazują dla niego 0 PVU. To problem z regułami bundlingu. Produkt jest wykrywany przez skaner, ale jest przypisany do złej metryki licencyjnej lub wyłączony z obliczeń PVU ze względu na konfigurację bundlingu.
Sprawdź konfigurację bundlingu w katalogu oprogramowania ILMT. Czasem produkt jest przypisany do pakietu, który ustawia jego wkład PVU na zero, bo IBM traktuje go jako zawarty w innym produkcie. Jeśli Twoje faktyczne uprawnienia nie odpowiadają temu założeniu bundlingowemu, raport jest mylący. To jeden z tych problemów, który wygląda nieszkodliwie, ale powoduje poważne konsekwencje podczas audytu. Audytor, który zobaczy znany produkt IBM z zerowym zużyciem PVU, zacznie kopać głębiej.
5. Spadek wydajności serwera ILMT
ILMT działał szybko zaraz po wdrożeniu. Teraz importy danych trwają godzinami, interfejs webowy jest powolny, a generowanie Audit Snapshota przeciąża serwer. To problem wzrostu bazy danych.
ILMT przechowuje historyczne dane ze skanów, a z czasem baza danych rośnie. Środowiska z więcej niż 5000 endpointów są szczególnie narażone na ten problem. Rozwiązaniem jest połączenie konserwacji bazy danych (reorganizacja tabel, aktualizacja statystyk), archiwizacji starych danych, które nie są już potrzebne do celów zgodności, i ewentualnie zwiększenia zasobów CPU i pamięci serwera. Dokumentacja IBM zawiera szczegółowe wytyczne dotyczące harmonogramów konserwacji bazy danych ILMT. Jeśli nigdy nie uruchamiałeś zadań konserwacyjnych na swojej bazie ILMT, zacznij od tego. Jeśli problemy z wydajnością popychają Cię w stronę odpornej konfiguracji, podejście do wysokiej dostępności i DR dla ILMT to osobna rozmowa niż naprawa wydajności, i warto znać wspierane opcje.
6. Zdublowane wpisy w katalogu oprogramowania
Ten sam produkt IBM pojawia się wielokrotnie w raportach ILMT, czasem z różnymi metrykami licencyjnymi. Dzieje się tak zwykle, gdy niestandardowe sygnatury oprogramowania kolidują z wbudowanymi wpisami katalogu IBM. Jeśli ktoś stworzył własną sygnaturę dla produktu, który IBM później dodał do oficjalnego katalogu, na końcu masz dwa wpisy.
Przejrzyj swoje niestandardowe sygnatury i porównaj je z aktualnym oficjalnym katalogiem. Usuń wszystkie własne wpisy, które pokrywają się z tym, co katalog IBM już obejmuje. Po oczyszczeniu reimportuj katalog i pozwól ILMT ponownie przetworzyć dane. Duplikaty powinny zniknąć przy następnym cyklu importu.
7. Brak danych wirtualizacji VMware
ILMT pokazuje „unknown" jako typ wirtualizacji na serwerach, o których wiesz, że są maszynami wirtualnymi VMware. Oznacza to, że ILMT nie jest w stanie określić fizycznego hosta, na którym działają te VM, a bez tej informacji nie może obliczyć wartości PVU sub-capacity. Te maszyny wirtualne domyślnie podlegają obliczeniom full-capacity w raportach.
Źródłem problemu jest prawie zawsze narzędzie BigFix VM Manager. Ten komponent łączy się z Twoim vCenter i pobiera dane mapowania VM do hosta, których potrzebuje ILMT. Ten sam wzorzec dotyczy Hyper-V i Nutanix AHV, każda z tych platform ma w nowszych wersjach BigFix Inventory dedykowany konektor VM Manager. Hyper-V przez lata zmieniał zasady: starsze wersje ILMT opierały się na agencie BigFix na hoście Hyper-V, nowsze wspierają natywne połączenie VM Manager. Jeśli masz mieszane środowisko, zweryfikuj, z której metody korzysta każdy klaster. VM Manager może w ogóle nie być skonfigurowany, dane logowania do vCenter wygasły, albo połączenie z vCenter jest blokowane przez firewall. Sprawdź konfigurację VM Manager w konsoli BigFix, zweryfikuj dane logowania i upewnij się, że serwer BigFix może nawiązać połączenie z vCenter na wymaganych portach. W środowiskach, gdzie zespół VMware i zespół ILMT to oddzielne grupy, ta integracja często po cichu się psuje, bo nikt nie odpowiada za połączenie między tymi dwoma systemami.
8. Niekompletne dane PowerVM LPAR
Jeśli uruchamiasz oprogramowanie IBM na systemach Power, ILMT potrzebuje danych z Hardware Management Console (HMC), aby obliczać wartości sub-capacity dla Twoich partycji LPAR. Kiedy te dane są brakujące lub niekompletne, ILMT domyślnie stosuje licencjonowanie full-capacity dla dotkniętych systemów Power. Na serwerze POWER9 z 24 rdzeniami po 120 PVU na rdzeń różnica między sub-capacity a full-capacity może być ogromna.
Sprawdź konfigurację połączenia HMC w ILMT. Najczęstsze przyczyny to dane logowania HMC zmienione podczas rutynowej konserwacji bez aktualizacji konfiguracji ILMT, zmiany w połączeniu sieciowym między serwerem ILMT a HMC, lub aktualizacje firmware HMC, które zmieniły zachowanie API. Jeśli niedawno aktualizowałeś firmware HMC, zweryfikuj, czy połączenie z ILMT nadal działa.
9. Aktualizacja ILMT psuje raporty
Zaktualizowałeś ILMT do najnowszej wersji i teraz Twoje historyczne raporty wyglądają inaczej. Wartości PVU się zmieniły, produkty, które wcześniej były prawidłowo identyfikowane, teraz pokazują inne wartości, lub format Audit Snapshota uległ zmianie. To frustrujące, ale się zdarza.
IBM czasem zmienia metodologię obliczeń, logikę dopasowywania katalogu lub formaty raportów między wersjami ILMT. Sama aktualizacja nie jest błędna. Nowa wersja po prostu inaczej interpretuje te same dane. Przed aktualizacją zawsze przeczytaj notatki wydania (release notes) dla docelowej wersji. Dokumentują one zmiany w zachowaniu obliczeń i znane problemy. Jeśli jesteś w trakcie audytu lub zbliżasz się do przeglądu zgodności, odłóż aktualizację na czas po zakończeniu tego procesu. I zawsze testuj aktualizacje na instancji nieprodukcyjnej ILMT, jeśli taką posiadasz.
10. Agent wdrożony, 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, więc co się dzieje?
Sam fakt, że agent BigFix jest online, nie oznacza automatycznie, że przeprowadza skanowanie oprogramowania. Skan oprogramowania to oddzielna akcja, która musi być skierowana na endpoint przez konsolę BigFix. Sprawdź status akcji skanowania dla dotkniętej maszyny. Poszukaj fixleta skanowania oprogramowania ILMT i zweryfikuj, czy został aktywowany i pomyślnie zastosowany. W środowiskach, gdzie regularnie dodaje się nowe serwery, łatwo pominąć skierowanie akcji skanowania na nowe endpointy, szczególnie jeśli proces wdrażania nie obejmuje kroku aktywacji skanowania BigFix.
Utknąłeś z problemem ILMT?
Opisz nam problem, a powiemy Ci, czy możesz go naprawić samodzielnie, czy potrzebujesz pomocy specjalisty. Bez sprzedażowego podejścia, tylko konkretna odpowiedź.
Opisz swój problemKiedy szukać pomocy, a kiedy naprawić samemu
Nie każdy problem z ILMT wymaga pomocy z zewnątrz. Oto uczciwy podział na to, co możesz ogarnąć wewnętrznie, a co warto eskalować.
Napraw samodzielnie
Problemy z połączeniami agentów są najczęstszym problemem ILMT i zwykle najłatwiejszym do rozwiązania. Jeśli BESClient jest zatrzymany, uruchom go ponownie. Jeśli firewall blokuje port 52311, uzgodnij z zespołem sieciowym jego otwarcie. To zadania operacyjne, które Twój zespół infrastruktury może obsłużyć przy podstawowej znajomości BigFix.
Aktualizacje katalogu to również zadanie do samodzielnego wykonania. Pobierz najnowszy katalog, zastosuj go przez fixlet BigFix i zweryfikuj, czy import zakończył się poprawnie. To około 30 minut aktywnej pracy.
Zależy od złożoności
Problemy z katalogiem wykraczające poza proste aktualizacje należą do szarej strefy. Jeśli masz zdublowane wpisy, kolidujące niestandardowe sygnatury lub produkty, które ILMT błędnie identyfikuje, naprawa wymaga zrozumienia, jak działa mechanizm dopasowywania katalogu ILMT na poziomie technicznym. Niektóre organizacje mają tę wiedzę w zespole. Wiele nie ma.
Problemy z integracją VMware i PowerVM są podobne. Jeśli naprawa polega na „zaktualizuj hasło do vCenter w VM Manager", nie potrzebujesz pomocy. Jeśli naprawa wymaga przebudowy sposobu zbierania danych o wirtualizacji przez ILMT w wielu vCenter w różnych strefach sieciowych, to już inna rozmowa.
Sięgnij po pomoc eksperta
Problemy z danymi związane z audytem to obszar, gdzie błędy są kosztowne. Jeśli Twoje dane ILMT mają luki, nieprawidłowe obliczenia PVU lub brakujące serwery, a stoisz w obliczu audytu IBM lub przeglądu zgodności, sięgnij po profesjonalną pomoc. Koszt konsultanta przeglądającego Twoje dane to ułamek tego, ile kosztowałoby stwierdzenie audytowe o nielicencjonowanym oprogramowaniu. Widzieliśmy organizacje, które próbowały naprawić dane ILMT samodzielnie przed audytem i pogorszyły sytuację, usuwając dane lub błędnie konfigurując reguły bundlingu.
Jeśli Twój ILMT był zaniedbany przez sześć miesięcy lub dłużej, profesjonalny przegląd jest prawie zawsze szybszy niż rozwiązywanie problemów po kolei. Doświadczony konsultant może ocenić całe środowisko w kilka dni i przygotować priorytetyzowany plan naprawczy. Wykonanie tego samego wewnętrznie, bez rozpoznawania wzorców płynącego z pracy z dziesiątkami środowisk ILMT, zajmuje zwykle tygodnie.
Zasoby wsparcia IBM ILMT
Oto kluczowe zasoby, które warto mieć pod ręką, jeśli zarządzasz środowiskiem ILMT.
Dokumentacja IBM ILMT to oficjalna dokumentacja produktu umieszczona w IBM Knowledge Center. Obejmuje instalację, konfigurację, rozwiązywanie problemów i interpretację raportów. Dokumentacja jest szczegółowa, ale nawigacja po niej bywa utrudniona. Zacznij od sekcji rozwiązywania problemów, jeśli masz konkretną kwestię do rozstrzygnięcia.
IBM Fix Central to miejsce, z którego pobierasz poprawki ILMT, aktualizacje i pliki katalogu. Dodaj tę stronę do zakładek, bo będziesz jej potrzebować przy każdej aktualizacji katalogu oprogramowania lub zastosowaniu wersji serwisowej.
Forum BigFix to najbardziej aktywne źródło społecznościowe dla pytań o BigFix i ILMT. Kiedyś mieściło się pod parasolem IBM Community, a od 2019 roku po przejęciu przez HCL działa w strukturach HCL. Archiwum jest ciągłe, stare wątki nadal tam są, a odpowiadają ci sami inżynierowie ILMT co wcześniej.
Notatki wydania ILMT (release notes) są publikowane z każdą nową wersją i poprawką. Zawsze czytaj je przed aktualizacją. Dokumentują nowe funkcje, poprawki błędów, znane problemy i zmiany w metodologii obliczeń, które mogą wpłynąć na Twoje raporty.
Tablica PVU IBM wymienia wartości PVU dla każdego modelu procesora, który IBM rozpoznaje. Ta tablica jest aktualizowana, gdy pojawiają się nowe modele procesorów. Jeśli ILMT pokazuje nieoczekiwane wartości PVU dla nowego modelu serwera, sprawdź, czy tablica PVU w Twojej instalacji ILMT jest aktualna.
Potrzebujesz stałego wsparcia ILMT?
Nasza usługa Zarządzanie ILMT obejmuje monitorowanie agentów, aktualizacje katalogu, kwartalne raportowanie i rozwiązywanie problemów. Ty skupiasz się na biznesie, a my dbamy o zdrowie ILMT.
Zapytaj o zarządzanie ILMTZapobieganie problemom z ILMT
Większości problemów z ILMT, które widzimy, można było zapobiec. Pojawiają się, bo nikt aktywnie nie zajmuje się utrzymaniem systemu. ILMT to jedno z tych narzędzi, które działa po cichu w tle, dopóki nie przestanie, a wtedy masz przed sobą miesiące nawarstwionych problemów do rozplątania.
Oto praktyczna checklista zapobiegawcza.
Co miesiąc: przegląd stanu agentów. Sprawdź w konsoli BigFix agenty, które nie raportowały w ciągu ostatnich 7 dni. Skonfiguruj automatyczny alert, jeśli Twoja wersja BigFix to obsługuje. Naprawiaj nieraportujące agenty natychmiast, zamiast pozwalać liście rosnąć. Ten jeden nawyk zapobiega najczęstszemu problemowi ILMT.
Co kwartał: aktualizacja katalogu oprogramowania. Pobierz i zastosuj najnowszy katalog od IBM. Zweryfikuj, że import zakończył się bez błędów. Przejrzyj wszystkie nowe wpisy „unknown", które pojawiły się po aktualizacji, i zbadaj je. Aktualny katalog oznacza dokładną identyfikację produktów.
Co kwartał: przegląd raportów. Wygeneruj Audit Snapshot i przejrzyj go pod kątem anomalii. Szukaj nieoczekiwanych skoków PVU, produktów pokazujących 0 PVU, serwerów bez danych i wpisów z „nieznaną" wirtualizacją. Wychwycenie tych problemów kwartalnie oznacza, że masz do zbadania najwyżej trzy miesiące danych, a nie trzy lata.
Na bieżąco: dokumentuj konfigurację ILMT. Zapisz połączenia z vCenter, konfiguracje HMC, niestandardowe reguły bundlingu i wszystkie niestandardowe ustawienia w środowisku ILMT. Kiedy osoba, która pierwotnie konfigurowała ILMT, odejdzie z firmy (a odejdzie), ta dokumentacja to różnica między płynnym przekazaniem a zaczynaniem od zera.
Przed każdą aktualizacją: testuj na środowisku nieprodukcyjnym. Jeśli masz testowe środowisko ILMT, zaktualizuj je najpierw i sprawdź, czy raporty wyglądają poprawnie, zanim dotkniesz produkcji. Jeśli nie masz środowiska testowego, wygeneruj przynajmniej pełny Audit Snapshot przed aktualizacją, aby mieć punkt odniesienia do porównania po zakończeniu procesu.