Temat poruszony w tym artykule coraz częściej przewija się w róznych organizacjach IT. Jak zapewnić atualność bazy CMDB dla środowisk szybko-zmiennych (Chmura) i jak budować strukture logiczną CMDB dla usług IaaS (infrastructure as a Service).

Wbrew pozorom – logiczne rozwiązanie jest dośc proste. I dośc podobne dla jednego i drugiego przypadku. W usługach szybkozmiennych i IaaS odchodzimy od CI przywiązanych do sprzętu – komponentu HW. Oczywiście – „pod spodem” dalej stoją maszyny fizyczne, chassis, fizyczne urządzenia sieciowe itd. Niemniej – warstwa powyżejjest de facto warstwą aplikacyjną. Stąd logiczne ułożenie tych CI w CMDB również musi odpowiadać logice aplikacji.

IaaS

Na początek rozważmy prosty przypadek – wystawiona dośc statyczna (rzadko zmienialna) usługa IaaS. Przykładem niech będzie AWS:

1

Odpowiedzialność po stornie klienta AWS (IT) zaczyna się od File Systemów (maszyn wirtualnych). Oczywiście – ich konfiguracja (w rozumieniu Zarządzania Konfiguracją) będzie posiadała podobne atrybuty jak maszyn fizycznych, z zastrzeżeniem, że:

Dodatkowo – z perspektywy konfiguracji całej usługi liczy się wysycenie usługi (wolumen skonsumowanych „parametrów” – core-ów, pamięci, storage-u, transferu itd.)

Zmienia się perspektywa, z której patrzymy na CI – zamiast parametrów pojedynczych maszyn (one sa istotne z punktu widzenia wydajności usług aplikacyjnych, niemniej tracą swój priorytet w kontekście wpływu pojedynczych komponentów na działanie Usługi), bardziej interesuje nas ilość instancji oraz wysycenie/utylizacja całej usługi.

Dlaczego zatem nie zmienić perspektywy również w CMDB? Model „klasyczny” zakłada, że CI jest „maszyna” (fizyczna lub wirtulana) – urządzenie. Wolumeny RAM, Storage itd. – to atrybuty. A gdyby odwrócić ten model? Niech zdefiniowana konfiguracja maszyny/urządzenia zostanie CI – np. „Serwer WWW dla usługi X” jako zestaw parametrów konfiguracyjnych, jakie musi posiadać każda VM w okreśłonej roli/konfiguracji. A parametrem niech będzie ilośc instancji danej konfiguracji. Dokładnie tak definiowana jest konfiguracja aplikacji i baz danych.

2

Jakie zalety daje taka zmiana perspektywy? O ile jeszcze kilka lat temu serwery liczyło się maksymalnie w dziesiątkach – obecnie są to setki i tysiące (oczywiście w dużych organizacjach). Dopisanie kolejnego serwera, często o innej konfiguracji niż poprzednia – nie było wielkim wyzwaniem dla utrzymujących CMDB. Ba, dla serwerów fizycznych miało to dodatkowy sens – komponenty fizyczne „psują się” fizycznie – wymiana RAM, wymiana dysku, wymiana karty sieciowej – to przecież kiedyś podstawowe czynności naprawcze. W dzisiejszym IT łatwiej jest „zabić” wadliwą VM i wystawić nową, niż manipulować konfiguracją maszyny.

Predefiniowane konfiuracje to również już standard. Stąd – łatwiej jest zarządzać w perspektywie rzadko zmienialnej konfiguracją, a częstozmienialnej – wolumetrią.

Środowiska szybkozmienialne

I dochodzimy do clue rozważań. Załóżmy, że zarządzamy środowiskiem, gdzie funkcjonuje kilkaset – kilka tysięcy maszyn wirtualnych w kilkunastu predefiniowanych konfiguracjach. W modelu klasycznym struktura CMDB wyglądałaby tak, jak pierwsza opcja na diagramie poniżej (Model klasyczny). A w modelu, gdzie CI-em jest konfiguracja, a atrybutem (lub instancją konfiguracji) maszyny, tak, jak w kmodelu dla IaaS.

grafika_blog_pwys_duza

Pytanie: Który model jest łatwiejszy do utrzymania w CMDB? Dla którego przeliczanie relacji, analizy wpływu Incydentów i Zmian będą liczone poprawniej, który w końcu w wypadku zmiany IMAC (Installatin, Move and Change) nie „rozsypie” struktur Usługi? Oczywiście ten drugi.

Dodatkową zaleta tego modelu jest obsługa zmian w środowiskach szybkozmienialnych: jeśli zasoby przydzialane są dynamicznie (skrypty) lub np. zarządzamy środowiskiem testowym, gdzie cykl życia maszyny to mniej niż 24h – łatwiej jest traktować taką maszynę jako instację i zliczać jako atrybut ilość instacji, niż za każdą zmianą IMAC dekomponować usługę na nowo.

Jedynym pozostałym zagadnieniem jest – jak realizować audytowalnośc takiego środowiska. Znów najprostsze rozwiązania sa najlepsze – zamiast autodiscovery monitorującego całą infrastrukturę wystarczy zastosować mechanizm notyfikacji o zmianie. Na przykład według poniższego schematu.
pwys_blog_4

Prawda, że proste?

Jeśli chcecie dowiedzieć się więcej o takim podejściu – zapraszamy do kontaktu: blog@spoc.pl.

# # #

Skomentuj

Dodaj komentarz

Dołącz do nas:

Wejdź na naszą stronę i sprawdź aktualne oferty pracy.
Jeśli chcesz zdobyć wiedzę na temat ServiceNow i zostać certyfikowanym specjalistom sprawdź ofertę szkoleń.

W swojej pracy używasz ServiceNow i chcesz podzielić się swoją wiedza? Napisz do nas koniecznie na blog@spoc.pl.