Budowa WMI

WMI jest zbudowane z czterech zasadniczych warstw:

• Managed Objects – komponenty systemu, którymi WMI zarządzane przez WMI. Mogą to być na przykład dyski, interfejsy sieciowe, zainstalowane aplikacje. Zarządzanym obiektem może być również zbiór innych komponentów – na przykład cały komputer może być zarządzanym obiektem, a jego elementami są dyski i karty sieciowe

• Providers – zestaw API do dostępu do Managed Objects

• WMI Infrastructure – zasadniczy element całego WMI, składa się na niego CIM Object Manager oraz CIM Repository. CIMOM jest to proces lub usługa, która na podstawie danych od provider-ów utrzymuje CIM Repository

• Management Applications lub Data Consumers – aplikacje korzystające z danych WMI poprzez API

: Schemat budowy WMI [za: “Windows Internals”]

Aby Manager obiektów CIM mógł zwracać konsumentom jakiekolwiek dane na temat obiektów zarządzanych, niezbędne jest dostarczenie do niego w sposób usystematyzowany danych na ich temat. Rolę tych dostarczycieli, jak sama nazwa wskazuje, pełnią Providerzy. W momencie, kiedy do CIMOM-a przyjdzie żądanie danych, których nie ma w danej chwili w repozytorium, wyszukuje on w bazie metadanych, który provider jest odpowiedzialny za obsługę danego obiektu zarządzanego i oczekuje, że ten zwróci mu niezbędne dane. Specyfikacja pozostawia dowolność w sposobie implementacji takiego doręczyciela – może to być plik wykonywalny (*.exe), biblioteka łącz dynamicznych (*.dll), lub usługa systemowa. Ważne jest, aby CIMOM „zrozumiał” otrzymaną informację i przekazał ją do konsumenta. Systemy Windows dostarczają szeroki wachlarz Providerów, aby ułatwić pracę z nimi.

Dodatkowo dostawców informacji można podzielić na dwie grupy ze względu na pełnione funkcje:

• Event Provider – generują powiadomienia o zdarzeniach. w momencie, gdy w systemie ma miejsce jakieś zdarzenie, informacja o jego wystąpieniu jest przekazywana do WMI. Tu z kolei usługa dopasowuje zdarzenie, do jednego lub więcej zarejestrowanych konsumentów zdarzeń (konsumenci zdarzeń – event consumers, to aplikacje, które zgłosiły do WMI chęć otrzymywania powiadomień o danych zdarzeniach)

: Schemat działania Event Providera [za: “Developing WMI Solutions”]

• Data Provider – zajmują się dostarczaniem danych, które są dostarczane do konsumentów na żądanie. Idąc krok dalej dostarczycieli danych można podzielić pod względem rodzaju informacji, jakie dostarczają – klasy, instancje klas, metody lub właściwości.

Tabela: Typy Providerów WMI

Równie ważny jest jeszcze jeden podział dostarczycieli danych: ze względu na sposób przechowywania i zwracania danych. Prezentuje go poniższa tabela:

2. Klasyfikacja sposobów dostarczania danych do WMI

. Pola instancji obiektu __Win32Provider

W celu uporządkowania i pogrupowania obiektów w repozytorium CIM, zostały one pogrupowane w przestrzenie nazw (namespace). Godnym podkreślenia, jest fakt, że podział ten jest całkowicie logiczny. Na przykład przestrzeń nazw CIMV2, zawiera wszystkie klasy opisujące lokalne środowisko Windows, a także ich instancje. Zgodnie z tą filozofią, bez sensu byłoby szukać w tym namespace klas opisujących funkcjonowanie routera. Logiczne byłoby z kolei, zdefiniować przestrzeń nazw routera, a następnie wypełnić ją odpowiednimi klasami i ich instancjami. Niezwykle istotną rzeczą jest także fakt, że uprawnienia do poszczególnych obiektów WMI są realizowane na poziomie przestrzeni nazw. Znaczy to dokładnie tyle, że chcąc nadać jakiemuś konsumentowi (aplikacji) możliwość korzystania z danych obiektów WMI, należy nadać je na poziomie namespace.

: Zestaw przestrzeni nazw na Windows Server 2008 R2

. Nowoutworzona instancja obiektu __NAMESPACE

. Nowoutworzone klasy i ich asocjacja

W każdym środowisku korporacyjnym niezmiernie istotnym aspektem zarządzania infrastrukturą jest wykrywanie i reakcja na zakłócenia działania usług. Biorąc pod uwagę kluczowość owego zagadnienia wykształciły się dwa modele powiadamiania o zdarzeniach:

• Synchroniczny – aplikacja monitorująca okresowo sprawdza stan infrastruktury i/lub obiektów zarządzanych

• Asynchroniczny – jedynym zadaniem aplikacji zarządzającej jest zapisanie się jako subskrybent informacji, a następnie odpowiednia reakcja na otrzymywane powiadomienia. Śledzeniem zmian powinien zająć się inny element infrastruktury

Ze względu na obciążenie łącz sieciowych oraz procesora WMI implementuje asynchroniczny sposób powiadamiania o wydarzeniach.

Pomimo definiowania filtrów do wszystkich rodzajów zdarzeń za pomocą WMI Query Language (WQL – patrz Rozdział 4.), można je sklasyfikować ze względu na źródło pochodzenia:

• Zdarzenia wewnętrzne – są podnoszone w odpowiedzi na zmiany w wewnętrznej bazie CIM. Przykładem takiego wyzwalacza może być skasowanie, stworzenie lub modyfikacja definicji klasy, instancji lub przestrzeni nazw. Śledzenie takich zmian umożliwia nie tylko bycie o nich powiadamianym, ale także śledzić na bieżąco, co się zmieniło. Na przykład konsument zdarzenia chce być powiadamiany o tworzeniu nowych procesów (instancje obiektów Win32_Process), aby je monitorować na danej maszynie.

• Zdarzenia zewnętrzne – jego źródłem jest obiekt spoza standardowego modelu WMI. Co za tym idzie taki incydent musi zostać podniesiony przez dodatkowy Event Provider. Microsoft w dokumentacji definiuje zdarzenia zewnętrzne, jako incydenty zachodzące w „prawdziwym świecie”, ponieważ w większości przypadków dotyczą one fizycznej maszyny lub komponentu oprogramowania.

• Zdarzenia czasowe – ten rodzaj wydarzeń wyłamuje się z asynchronicznego modelu informowania w WMI. Konsument tworząc nową subskrypcję, może jednocześnie utworzyć instancję któregoś z obiektów _IntervalTimerInstruction, _AbsoluteTimerInstruction, Win32_LocalTime lub Win32_UTCTime. Następnie zmuszony jest on do zdefiniowania i powiązania filtra WQL z logicznym konsumentem, który powiadomienia zdefiniowane danym filtrem będzie otrzymywać. Zdarzenia czasowe są narzędziem, dostarczającym zwykłe powiadomienia w określonym czasie

Drugą częścią modelu zdarzeniowego są subskrybenci powiadomień (konsumenci). Ze względu na sposób przechowywania informacji o nich przez WMI, można ich podzielić na dwie grupy”

• Konsumenci tymczasowi – otrzymują powiadomienia tylko w czasie swojego działania. WMI informacje o rejestracji takich konsumentów przetrzymuje w pamięci operacyjnej. W przypadku restartu maszyny hostującej usługę WMI, wszystkie dane o rejestracji subskrybenta zostaną utracone. Zastosowaniem takiej konsumpcji może być aplikacja, która monitoruje i wyświetla dane na temat zużycia miejsca na dyskach twardych. Jednakże nie jest konieczne, aby dane były zbierane, gdy odbiorca nie jest uruchomiony.

• Konsumenci trwali – architektura trwałych konsumentów wymaga, aby byli zdefiniowani oni wewnątrz repozytorium CIM, żeby nawet w przypadku restartu maszyny, informacja o nim została zachowana. Dodatkowo trwały konsument otrzymuje powiadomienia także będąc nieaktywnym. Osiągane jest to poprzez zastosowanie subskrybentów „logicznych” oraz „fizycznych”. Sam fakt zarejestrowania powoduje powstanie konsumenta logicznego, a ten z kolei definiuje aplikację, lub bibliotekę go obsługującą, która jest konsumentem logicznym. Przykładem zastosowania takiej architektury może być rejestracja aplikacji defragmentującej dyski jako konsumenta trwałego wydarzenia podnoszonego, kiedy stopień fragmentacji danych na danym woluminie przekroczy 10%. Gdy takie wydarzenie będzie mieć miejsce, WMI zareaguje wyszukując konsumenta logicznego w repozytorium. Następnie sczytując informacje o nim odnajdzie instancję konsumenta fizycznego, a następnie spróbuje uruchomić go, jeśli ten nie działa.

Autor:

Daniel Stefaniak
(MVP, MCT, MCITP, MCTS, MCSA, MCP, CCNA)