Spis tresci
Zanim zaczniesz: planowanie wdrozenia ILMT
Wdrazalismy ILMT w srodowiskach od 30 endpointow do ponad 15 000. Jeden czynnik wplywa na powodzenie instalacji bardziej niz wszystkie pozostale razem wziete: planowanie. Zanim pobierzesz pierwszy instalator, musisz dokladnie wiedziec, jak duze jest Twoje srodowisko i jakich zasobow bedzie potrzebowal ILMT.
Na poczatek podziel swoje srodowisko na kategorie. Male srodowisko to wszystko ponizej 100 endpointow. Srednie obejmuje od 100 do 1000. Duze oznacza 1000 lub wiecej. Te progi sa istotne, bo bezposrednio wplywaja na wymagania sprzetowe, architekture BigFix i czas trwania projektu.
Dla malego srodowiska ponizej 100 endpointow mozna uruchomic serwer BigFix i serwer ILMT na jednej maszynie. Przydziel co najmniej 4 GB RAM, 2 rdzenie CPU i 80 GB przestrzeni dyskowej. To rozsadny punkt wyjscia na potrzeby weryfikacji koncepcji lub dla organizacji z niewielkim portfolio oprogramowania IBM.
Srednie srodowiska wymagaja oddzielnych serwerow. Serwer BigFix powinien miec co najmniej 8 GB RAM, 4 rdzenie CPU i 200 GB dysku. Serwer ILMT potrzebuje wlasnej maszyny z 8 GB RAM, 4 rdzeniami i 100 GB przestrzeni. ILMT korzysta z wbudowanej instancji DB2 do przechowywania danych, a ta baza rosnie wraz z rozwojem srodowiska i historia raportow. Nie lekcewazycie wymagan dyskowych. Widzielismy instalacje, w ktorych przestrzen dyskowa konczyla sie w ciagu szesciu miesiecy, bo ktos zaplanowal pojemnosc na podstawie danych z pierwszego dnia zamiast prognozowanego wzrostu.
Duze srodowiska wymagaja jeszcze staranniejszego planowania. Prawdopodobnie bedziesz potrzebowal przekaznikow BigFix (relay), zeby rozlozyc obciazenie komunikacyjne agentow, szczegolnie jesli masz oddalone lokalizacje lub centra danych polaczone laczczami WAN. Przekaznik to lokalny punkt dystrybucji, z ktorym agenty komunikuja sie zamiast kontaktowac sie z centralnym serwerem BigFix przy kazdym zadaniu. Bez przekaznikow duze srodowiska przeciazaja centralny serwer, a agenty zaczynaja gubic raporty. Zaplanuj co najmniej jeden przekaznik na kazda zdalna lokalizacje lub na 500 do 1000 agentow.
Planowanie sieci zasuguje na osobna uwage. Agenty BigFix komunikuja sie z serwerem (lub przekaznikiem) domyslnie na porcie TCP 52311. Serwer ILMT potrzebuje dostepu do bazy danych BigFix, zwykle przez port TCP 50000 dla DB2 lub 1433 dla SQL Server. Jesli Twoje srodowisko obejmuje wiele stref sieciowych z firewallami miedzy nimi, udokumentuj te polaczenia wczesnie i otwieraj reguly firewalla przed rozpoczeciem instalacji. Problemy z firewallem to przyczyna numer jeden zatrzymanych wdrozen, ktore spotykamy w praktyce.
Krok 1: Instalacja serwera BigFix
BigFix jest fundamentem kazdego wdrozenia ILMT. Bez dzialajcej infrastruktury BigFix, ILMT nie ma z czym pracowac. Serwer BigFix zbiera dane z kazdego endpointa w srodowisku i przechowuje je centralnie. ILMT nastepnie odczytuje te dane, zeby generowac raporty zgodnosci licencyjnej.
Jedna wazna informacja, ktora wiele organizacji pomija: BigFix do obslugi ILMT jest bezplatny. Jesli jestes klientem IBM Passport Advantage, masz prawo uzywac BigFix wylacznie do obslugi ILMT bez dodatkowych kosztow licencyjnych. IBM pakuje to jako "BigFix Inventory" lub czasem okresla jako "komponent ILMT w BigFix." Nie musisz kupowac pelnej licencji BigFix Lifecycle ani BigFix Compliance tylko po to, zeby uruchomic ILMT. Instalator pobierzesz ze strony IBM Passport Advantage lub IBM Fix Central.
Serwer BigFix dziala na Windows Server. Aktualnie wspierane wersje to Windows Server 2016, 2019 i 2022. Wymaga backendu bazodanowego: Microsoft SQL Server lub IBM DB2. Dla nowych instalacji SQL Server Express sprawdza sie w malych srodowiskach, a srednie i duze wdrozenia powinny korzystac z SQL Server Standard lub Enterprise. Kreator instalacji przeprowadza przez konfiguracje bazy danych, generowanie certyfikatow i poczatkowa konfiguracje serwera.
Podczas instalacji utworzysz plik masthead, ktory sluzy jako punkt zaufania dla wszystkich agentow BigFix. Agenty uzywaja tego pliku do weryfikacji, ze komunikuja sie z prawidlowym serwerem. Zachowaj ten plik w bezpiecznym miejscu. Bedziesz go potrzebowal przy kazdym wdrozeniu nowego agenta.
Po uruchomieniu serwera aktywuj site BigFix Inventory. Ten site zawiera fixlety (zautomatyzowane zadania), ktore umozliwiaja skanowanie oprogramowania, zarzadzanie katalogiem i zbieranie danych niezbednych do dzialania ILMT. Bez aktywacji tego site'u BigFix bedzie zarzadzal endpointami, ale nie bedzie zbierac danych inwentaryzacyjnych, ktorych ILMT potrzebuje.
Krok 2: Wdrozenie agentow BigFix
Ten etap trwa najdluzej w niemal kazdym wdrozeniu, ktore realizowalismy. Techniczna instalacja agenta BigFix na pojedynczej maszynie jest prosta. Wdrozenie go na kazdym serwerze, na ktorym dziala oprogramowanie IBM, w roznych systemach operacyjnych, segmentach sieci i jednostkach organizacyjnych, to juz zupelnie inna historia.
Agenty BigFix sa dostepne dla systemow Windows, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu, AIX, Solaris i HP-UX. Agent jest lekki i zwykle zuzywa od 50 do 100 MB RAM przy minimalnym obciazeniu CPU. Dziala jako usluga systemowa i przezywa restarty automatycznie.
Do wdrozenia agentow na duzej skali masz kilka opcji. BigFix Client Deploy Tool to wlasne narzedzie IBM do zdalnej instalacji agentow. Dziala dobrze, gdy masz dane uwierzytelniajace administratora do docelowych maszyn i lacznosc sieciowa na porcie 52311. W srodowiskach Windows sprawdza sie wdrozenie przez zasady grupy (GPO). Zapakuj agent MSI do GPO i przypisz go do odpowiednich jednostek organizacyjnych. Jesli Twoja organizacja uzywa SCCM lub innego narzedzia do dystrybucji oprogramowania, mozesz wypchnac pakiet agenta BigFix przez istniejaca infrastrukture.
Na serwerach Linux i AIX powszechna metoda sa instalacje skryptowe. Prosty skrypt oparty na SSH, ktory kopiuje pakiet agenta, instaluje go, konfiguruje adres serwera i uruchamia usluge, moze wdrozyc agentow na dziesiatki serwerow w kilka minut. Dolacz plik masthead do pakietu wdrozeniowego, zeby agenty mogly uwierzytelnic sie z serwerem BigFix przy pierwszym polaczeniu.
I tu jest kluczowa kwestia, ktorej nie mozemy dostatecznie podkreslic: musisz wdrozyc agentow na kazdym serwerze, na ktorym dziala oprogramowanie IBM. Na kazdym bez wyjatku. Dotyczy to serwerow produkcyjnych, deweloperskich, srodowisk testowych, stagingowych, serwerow disaster recovery i kazdej maszyny, na ktorej ktos mogl zainstalowac produkt IBM. Jesli serwer ma oprogramowanie IBM, ale nie ma agenta BigFix, ILMT nie wie, ze ten serwer istnieje. Podczas audytu audytor IBM, ktory odkryje niemonitorowane serwery z oprogramowaniem IBM, potraktuje to jako luke w zgodnosci. Widzielismy organizacje, ktore starannie pokryly srodowisko produkcyjne, ale kompletnie zapomnially o laboratoriach deweloperskich i testowych, w ktorych czasem dzialalo wiecej oprogramowania IBM niz na produkcji.
Po wdrozeniu agentow sprawdz, czy wszystkie raportuja do serwera BigFix. Konsola BigFix pokazuje status agentow, w tym czas ostatniego raportu. Kazdy agent, ktory nie raportuje od ponad 24 godzin, wymaga zbadania. Typowe przyczyny to blokady firewalla, problemy z rozwiazywaniem DNS, bledny adres serwera w konfiguracji agenta lub niedzialalajca usluga agenta.
Potrzebujesz pomocy przy planowaniu wdrozenia ILMT?
Robilismy to setki razy w srodowiskach kazdej wielkosci. Powiedz nam o swojej infrastrukturze, a pomozemy zaplanowac odpowiednia architekture. Bez zobowiazan.
Uzyskaj pomoc przy wdrozeniuKrok 3: Instalacja serwera ILMT
Gdy BigFix dziala i agenty raportuja, mozesz przystapic do instalacji serwera ILMT. ILMT (aktualna wersja 9.2.x) dziala na systemie Linux, konkretnie Red Hat Enterprise Linux 7 lub 8 oraz SUSE Linux Enterprise Server 12 lub 15. To aplikacja webowa, do ktorej po instalacji uzyskujesz dostep przez przegladarke.
ILMT jest dostarczany z wbudowana instancja DB2, ktora sluzy jako wlasny magazyn danych. To jest oddzielna baza od tej, ktorej uzywa serwer BigFix. Wbudowane DB2 przechowuje dane konfiguracyjne ILMT, zaimportowane wyniki skanow i dane raportowe. Nie musisz osobno instalowac ani konfigurowac DB2. Instalator ILMT zajmuje sie tym automatycznie. Potrzebny bedzie tez Java Development Kit (JDK) na serwerze ILMT. Instalator IBM zawiera dolaczony JDK, wiec w wiekszosci przypadkow to rowniez jest obslugiwane automatycznie.
Sama instalacja przebiega przez kreator. Uruchamiasz instalator, akceptujesz umowe licencyjna, wybierasz katalog instalacyjny, konfigurujesz polaczenie z baza danych serwera BigFix, tworzysz konto administratora ILMT i pozwalasz kreatorowi zakonczyc prace. Caly proces trwa okolo 30 do 45 minut na odpowiednio przygotowanym serwerze.
Czesty blad, ktory widzimy w srednich i duzych srodowiskach: instalowanie serwera ILMT na tej samej maszynie co serwer BigFix. To dziala przy malych konfiguracjach ponizej 100 endpointow. Powyzej tej granicy obie aplikacje rywalizuja o CPU, pamiec i I/O dyskowe. BigFix nieustannie odbiera dane od agentow i zapisuje je w bazie. ILMT okresowo uruchamia duze importy danych, ktore pochaniaja znaczne zasoby. Uruchamianie obu na jednym serwerze prowadzi do wolnego generowania raportow, timeoutow importu i ogolnej niestabilnosci. Dajcie im osobne maszyny.
Po instalacji zaloguj sie do interfejsu webowego ILMT i sprawdz polaczenie z serwerem BigFix. ILMT powinien pokazywac calkowita liczbe polaczonych endpointow i ich status raportowania. Jesli liczba endpointow nie zgadza sie z tym, co widzisz w konsoli BigFix, sprawdz ustawienia polaczenia z baza danych i reguly firewalla miedzy serwerem ILMT a baza danych BigFix.
Krok 4: Konfiguracja katalogu oprogramowania i skanow
ILMT identyfikuje oprogramowanie IBM przez dopasowywanie plikow, wpisow rejestru i innych znacznikow na endpointach do katalogu oprogramowania utrzymywanego przez IBM. Ten katalog zawiera tysiace sygnatur dla produktow IBM we wszystkich wersjach i na wszystkich platformach. Bez aktualnego katalogu ILMT nie jest w stanie prawidlowo zidentyfikowac, co jest zainstalowane w Twoim srodowisku.
Pierwsze zadanie po instalacji to import najnowszego katalogu oprogramowania. Katalog mozesz pobrac z IBM Fix Central lub przez site BigFix Inventory. Importujesz go do ILMT przez interfejs webowy. IBM aktualizuje katalog mniej wiecej co kwartal, czasem czesciej. Ustaw sobie przypomnienie o regularnym sprawdzaniu aktualizacji katalogu. Nieaktualny katalog oznacza, ze ILMT moze nie rozpoznac nowo wydanych produktow IBM lub nieprawidlowo zidentyfikowac zaktualizowane wersje istniejacych.
Nastepnie skonfiguruj harmonogram skanowania. ILMT opiera sie na dwoch typach skanow uruchamianych przez agentow BigFix. Skan inwentaryzacji oprogramowania identyfikuje, jakie oprogramowanie jest zainstalowane na kazdym endpoincie. Skan wydajnosci zbiera dane o konfiguracji sprzetowej i wirtualizacyjnej. Oba skany musza byc uruchamiane regularnie. Zalecamy planowanie skanu inwentaryzacji oprogramowania co najmniej raz w tygodniu, a skanu wydajnosci codziennie. Same skany sa lekkie i zwykle koncza sie w ciagu kilku minut na endpoincie.
Trzecia krytyczna konfiguracja to polaczenie VM Managera. Tu ILMT pobiera dane o wirtualizacji. Dla srodowisk VMware musisz skonfigurowac polaczenie z serwerem vCenter. ILMT uzywa go do mapowania maszyn wirtualnych na hosty fizyczne, co jest niezbedne do obliczania wartosci PVU w trybie sub-capacity. Dla srodowisk IBM PowerVM ILMT laczy sie z Hardware Management Console (HMC). Dla Microsoft Hyper-V agent BigFix na hoscie Hyper-V zbiera niezbedne dane automatycznie, ale nadal musisz upewnic sie, ze agent jest wdrozony na kazdym hoscie Hyper-V.
Prawidlowa konfiguracja VM Managera jest kluczowa. Jesli ILMT nie moze okreslic, na ktorym hoscie fizycznym dziala maszyna wirtualna, nie jest w stanie obliczyc fizycznej pojemnosci tego hosta. Bez tej informacji ILMT przyjmuje kalkulacje pelnej pojemnosci dla dotkietych maszyn wirtualnych. Widzielismy organizacje, ktore tracily prawo do sub-capacity dla calych klastrow VMware, bo polaczenie z vCenter bylo zerwane i nikt tego nie zauwazyl przez miesiace. Przetestuj polaczenie VM Managera po konfiguracji i zweryfikuj, ze ILMT pokazuje prawidlowe mapowania hostow na maszyny wirtualne w widoku topologii.
Krok 5: Generowanie pierwszych raportow
Gdy poczatkowy import danych sie zakonczy (daj mu co najmniej 24 do 48 godzin na uruchomienie pierwszych skanow przez agentow i import danych przez ILMT), mozesz wygenerowac pierwsze raporty. Zacznij od Audit Snapshot, bo to jest raport, o ktory IBM poprosi w przypadku audytu.
Uruchom Audit Snapshot i przejrzyj go dokladnie. Twoj pierwszy raport prawie na pewno bedzie zawierac problemy. To jest zupelnie normalne. Oto czego mozesz sie spodziewac i co zrobic z kazdym problemem.
Brakujace agenty. Niektore serwery, na ktorych powinny dzialac agenty BigFix, nie pojawia sie w raporcie. Porownaj liste endpointow ILMT ze swoim inwentarzem serwerow. Kazdy serwer z oprogramowaniem IBM, ktory nie pojawia sie w ILMT, to luka, ktora trzeba zamknac. Wroc do Kroku 2 i wdroz agentow na tych maszynach.
Nieznane lub nieskategoryzowane produkty. ILMT moze wykryc instalacje oprogramowania, ktorych nie potrafi przypisac do konkretnego produktu IBM. Zwykle oznacza to, ze katalog oprogramowania nie ma sygnatury dla tej konkretnej wersji lub zainstalowane pliki nie pasuja do zadnego znanego wzorca. Sprawdz, czy dostepna jest nowsza wersja katalogu. Jesli oprogramowanie rzeczywiscie nie jest produktem IBM, mozesz wykluczyc je z raportow.
Wyzsze wartosci PVU niz oczekiwano. Poczatkowe liczby PVU moga byc wyzsze niz zakladales. Czesto dzieje sie tak dlatego, ze ILMT liczy produkty, o ktorych instalacji nie wiedziales, lub dlatego, ze konfiguracja VM Managera jest niekompletna i niektore maszyny wirtualne sa liczone przy pelnej pojemnosci. Zbadaj kazdy przypadek indywidualnie.
Luki w topologii wirtualizacji. Jesli ILMT pokazuje maszyny wirtualne bez znanego hosta, polaczenie VM Managera wymaga uwagi. Te "osierocode" maszyny wirtualne beda liczone w raporcie przy pelnej pojemnosci. Zweryfikuj polaczenia z vCenter, HMC lub hostami Hyper-V.
Nie panikuj z powodu poczatkowych wynikow. Pierwszy raport to narzedzie diagnostyczne, a nie werdykt zgodnosci. Napraw znalezione problemy, poczekaj na kolejny cykl importu danych i wygeneruj kolejny raport. Kazda iteracja powinna wygladac lepiej niz poprzednia. Wiekszosc srodowisk osiaga stabilny, dokladny stan w ciagu dwoch do czterech tygodni aktywnego dostrajania.
Problemy z pierwszymi raportami ILMT?
Interpretacja danych ILMT po swiezej instalacji to jeden z najczestszych powodow, dla ktorych organizacje sie z nami kontaktuja. Mozemy przejrzec Twoje poczatkowe raporty i pomoc dojsc do czystego stanu bazowego.
Popros o przeglad raportowNajczestsze bledy instalacyjne
Po latach wdrazania i przejmowania srodowisk ILMT widzielismy te same bledy wielokrotnie. Unikniecie ich zaoszczedzi Ci sporo czasu i frustracji.
Uzycie niewlasciwej wersji DB2
ILMT wymaga konkretnych wersji DB2. Instalacja niewspieranej wersji prowadzi do niejasnych bledow podczas konfiguracji lub, co gorsza, do cichego uszkodzenia danych, ktore wychodzi na jaw dopiero po miesiacach. Zawsze sprawdz dokument wymagan systemowych ILMT pod katem dokladnej macierzy wersji DB2, zanim zaczniesz. Jesli korzystasz z wbudowanego DB2 dostarczanego z instalatorem ILMT, ten problem jest rozwiazany automatycznie. Klopoty pojawiaja sie, gdy organizacje probuja uzyc istniejaccej instancji DB2, ktora przypadkiem jest w innej wersji.
Niewystarczajaca przestrzen dyskowa na dane skanow
Dane ze skanow kumuluja sie w czasie. Kazdy skan inwentaryzacji oprogramowania i skan wydajnosci generuje dane, ktore BigFix przechowuje, a ILMT importuje. Dla sredniego srodowiska z cotygodniowymi skanami nalzezy liczyc sie ze wzrostem bazy danych BigFix o kilka gigabajtow miesiecznie. Baza danych ILMT rowniez rosnie, szczegolnie jesli zachowujesz historyczne dane za dlugie okresy raportowania. Zalecamy przydzielenie co najmniej podwojonej poczatkowej pojemnosci dyskowej i ustawienie alertow monitoringowych przy 70% wykorzystania. Brak wolnego miejsca na serwerze BigFix lub ILMT to jeden z najszybszych sposobow na utworzenie luk w danych zgodnosci.
Brak przekaznikow w zdalnych lokalizacjach
Jesli masz serwery w wielu centrach danych lub strefach sieciowych polaczonych laczami WAN, potrzebujesz przekaznikow BigFix. Bez nich kazdy agent komunikuje sie bezposrednio z centralnym serwerem BigFix. To dziala dobrze w sieci lokalnej. Przez polaczenie WAN prowadzi do wolnego raportowania agentow, nieudanych przesylanych skanow i znacznego zuzycia pasma. Pojedynczy przekaznik w kazdej zdalnej lokalizacji rozwiazuje wszystkie te problemy. Zainstaluj przekaznik na serwerze Windows lub Linux w zdalnej lokalizacji, skieruj lokalne agenty na niego, a przekaznik obsluzy cala komunikacje z serwerem centralnym.
Brak konfiguracji VM Managera
Widzimy to w niemal polowie przejmowanych srodowisk. Serwer BigFix dziala, agenty sa wdrozone, ILMT generuje raporty, ale polaczenie VM Managera nigdy nie zostalo skonfigurowane lub w pewnym momencie przestalo dzialac. Skutek: kazda maszyna wirtualna w dotkietym klastrze wirtualizacji jest wykazywana z pelna pojemnoscia PVU. Administrator ILMT moze nawet tego nie zauwzyc, bo raporty wygladaja na "kompletne." Po prostu pokazuja znacznie wyzsze zuzycie PVU niz jest to konieczne. Zawsze weryfikuj polaczenie VM Managera jako czesc kontroli po instalacji i monitoruj je na biezaco.
Pominiecie srodowisk deweloperskich i testowych
Serwery deweloperskie i testowe sa rownie istotne dla zgodnosci licencyjnej IBM jak serwery produkcyjne. Jesli deweloper zainstalowal DB2 lub WebSphere na testowej maszynie wirtualnej, ta instalacja zuzywa jednostki PVU. Warunki licencyjne IBM nie rozrozniaja miedzy wykorzystaniem produkcyjnym a nieprodukcyjnym, chyba ze posiadasz specyficzna licencje nieprodukcyjna. Wdroz agentow BigFix na kazdym serwerze w kazdym srodowisku. Widzielismy ustalenia audytowe, gdzie wiekszosc luki zgodnosci pochodzila z niemonitorowanych serwerow deweloperskich i testowych, a nie z produkcji.