Wstęp

Największa przemiana, jaką zaobserwowaliśmy w przeciągu okresu trwania serii Operations Manager, czyli od 2000 roku, było pojawienie się produktu z rodziny System Center: Operations Manager 2007. Był to produkt o tyle innowacyjny, że cały silnik, wszystkie elementy aplikacji, a nawet nazewnictwo obiektów stanęło całkowicie na głowie. Dostaliśmy po prostu inny produkt niż ten, którego firmy używały do tej pory – MOM 2005. Od 5 lat obserwujemy ogromny postęp jaki został poczyniony w rozbudowie aplikacji. Microsoft i firmy partnerskie dostarczyły setek Management Packów do monitorowania swoich usług, dostaliśmy connectory do innych aplikacji i rozszerzyliśmy monitorowanie o środowiska heterogeniczne, takie jak Red Hat, Solaris czy AIX. To czego brakowało, to zebranie udostępnianych w czasie komponentów w jedno zwarte rozwiązanie. Operations Manager 2012 spowodował, że obraz środowiska stał się kompletny. Wprowadził szereg nowości, zmian w architekturze i funkcjonalności, ale jeden z nich stał się kluczowy dla całej sprawy – urządzenia sieciowe nareszcie są monitorowane w taki sposób, jaki powinny być monitorowanie kilka lat temu.

Architektura

Pule serwerów

Największą niespodzianką, jaka dotyczy architektury, to… brak głównego serwera, bez którego poprzednia wersja nie mogła istnieć. Root Management Server nie jest już integralnym składnikiem infrastruktury systemu monitorowania. Czy to oznacza, że skrótu RMS pozbędziemy się już na zawsze?

Zamiast RMS będziemy posiadać same Management Serwery, które swoją funkcją będą przypominać RMS – wszystkie będą mogły pełnić jego funkcje, tj. posiadać dostęp do bazy czy dystrybuować konfigurację do agentów. Wewnętrzne procesy replikacji konfiguracji dbały będą o to, aby wszystkie Management Serwery posiadały najnowsze dane przed wysłaniem ich na agentów.

Jak zatem dostawać się będzie agent ze swoimi danymi? Dostawać się będzie nie do serwera, a do puli serwerów, tzw. Resource Pool. Resource Pool to zestaw Management Serwerów obsługujących pewną czynność. Domyślnie predefiniowane są trzy pule:

• All Management Servers Resource Pool – pula Management Serwerów do obsługi agentów
• AD Assignment Resource Pool – pula Management Serwerów, które mogą zostać przypisane do automatycznego przydziału obsługi agentów w trakcie integracji Active Directory z OpsMgr 2012
• Notification Resource Pool – pula Management Serwerów, która obsługuje wysyłanie powiadomień do serwera SMTP

Rysunek 1 - Resource Pools w OpsMgr 2012

Wykorzystanie Resource Pool wiąże się głównie ze wsparciem dla wysokiej dostępności. Oznacza bowiem, że jeśli jeden z Management Serwerów będzie offline (brak sieci, awaria serwera), wszystkie czynności związane z obsługą agentów (wysyłanie konfiguracji, przyjmowanie alarmów) zostaną przekazane na pozostałe serwery równomiernie. Można to trochę porównać do działania Active Directory, gdzie w przypadku utraty połączenia z kontrolerem domeny w oddziale, stacje mogą korzystać z dobrodziejstw LDAP serwerów np. w centrali.

Powiecie – przecież Active Directory ma coś na wzór RMS, gdyż serwer może być PDC, RID, Infrastructure Master, Domain Naming Master itd. Zgadza się – dlatego wspomniałem wcześniej, że RMS całkowicie nie wymarł. Jeden z Management Serwerów musi posiadać funkcję tak zwanego emulatora RMS.

Rysunek 2 - RMS Emulator w OpsMgr 2012

Po co to wszystko? Ano po to, aby starsze Management Packi, które wymagały istnienia Root Management Serwera, np. korzystające z takiej klasy, mogły dalej działać. Rolę RMS Emulator możemy kontrolować dzięki nowym cmd-letom PowerShella: get-scomrmsemulator i set-scomrmsemulator.

Agenty

Agent także przeszedł drobne modyfikacje. Może nie aż tak drastyczne jak role serwera, ale trochę ułatwiające pracę z jego konfiguracją. Teraz możemy pewne elementy agenta ustawiać z poziomu Panelu Sterowania systemu operacyjnego. Pojawił się tam bowiem Operations Manager Agent.

Rysunek 3 - Agent OpsMgr 2012

Rzeczy, które możemy zmieniać na podstawie tego dodatku do panelu sterowania, są dwie:

• Automatycznie przypisać Management Groups (grupę zarządzającą) z poziomu integracji z Active Directory
• Ręcznie przypisać Management Groups (grupę zarządzającą) bez integracji z Active Directory

Rysunek 4 - Przypisywanie grup zarządzających do agenta OpsMgr 2012 (Multihoming)

A co z agentami i monitorowaniem UNIX-ów? Zostaliśmy uraczeni zestawem fajerwerków. Czy przydatnych? Owszem, i to bardzo. Zniknął toporny kreator monitorowania UNIX/Linux. Wykrywanie po otwartym SSH podając konto z prawami root? Można, ale czemu nie skorzystać z kolejnych udogodnień, jakie daje nam Operations Manager 2012?

Rysunek 5 - Wykrywanie UNIX w OpsMgr 2012

Oprócz możliwości wykrycia po SSH z prawami pewnego użytkownika systemu, jak to było w przypadku poprzedniej wersji SCOM-a, mamy teraz w końcu możliwość użycia klucza SSH i podania passphrase! Czy teraz administratorzy UNIX-a czują się bardziej bezpieczni? Zapewne nie, ale możemy pójść dalej – jeśli nasz użytkownik jest pozbawiony praw roota mamy kolejną możliwość podniesienia uprawnień poprzez polecenia „sudo” bądź „su” – jak komu przyjdzie ochota.

Rysunek 6 - Podniesienie uprawnień do root w OpsMgr 2012

Instalacja agentów zatem jest dość mocno usprawniona w Operations Manager 2012. Tak naprawdę to ciężko cokolwiek jeszcze w tej kwestii udoskonalić jeśli chodzi o instalację agentów na systemach Windows, więc tutaj nie zaszły żadne szczególne zmiany.

Wymagania systemowe

Jeśli chodzi o wymagania hardware, zmieniło się dużo. Jak właściwie każda nowa aplikacja – tak samo Operations Manager 2012 jest aplikacją 64-bitową i Management Server oraz baza danych może być instalowana tylko na systemie 64-bitowym, w dodatku tylko na Windows Server 2008 R2. Minimalne wymagania sprzętowe i systemowe najlepiej przedstawi poniższa tabela.

Jak widać, znaczną część należy instalować na komputerach z najnowszymi systemami operacyjnymi. To jednak zrozumiałe, skoro już niedługo kończą się wsparcia dla systemów XP oraz 2003.

Możliwości

Monitorowanie urządzeń sieciowych

Przechodzimy do najprzyjemniejszej części, a mianowicie do tego, co się pojawiło nowego w kontekście monitorowania. Najważniejszą funkcją jest znaczne rozszerzenie monitorowania urządzeń sieciowych. Według Microsoft 99% urządzeń sieciowych dostępnych na rynku jest wspierana przez ten moduł monitorowania. Nie jest to jednak dziwne – około 99% urządzeń wspiera monitorowanie przez SNMP podstawowych modułów jak pamięć, procesor czy interfejsy sieciowe, gdyż te moduły zawarte są w standardowym module SMNP – w drzewie mib-2. Wszystkie inne rozszerzenia monitorowania zapewne niedługo powstaną, które będą pozwalać na jeszcze bardziej dogłębną analizę urządzenia.

Rysunek 7 - Urządzenia sieciowe w OpsMgr 2012

Wykrywanie urządzeń sieciowych także zostało rozbudowane o ważne elementy na trzech płaszczyznach. Po pierwsze community string, którego używamy do wykrywania urządzeń na podstawie SNMPv2 jest teraz traktowane jako RunAs Account, co pozwala na przypisanie wielu kont po kolei w trakcie wykrywania urządzeń – jeśli jedno nie będzie działać, system spróbuje drugiego.

Rysunek 8 - RunAs Account - Community String

Druga kwestia to typ wykrywania. OpsMgr 2012 pozwala na wykrywanie rekursywne oraz specyficzne. Specyficzne jest proste – wykrywa te urządzenia, które mu się wskaże, natomiast rekursywne pozwala na wykrywanie urządzeń po tablicy ARP wskazanego wcześniej urządzenia i porównując do podanego w kreatorze wzorca, kolejne urządzenia będą wykrywane. Przykład: Wykrywamy nasz główny router o IP 192.168.100.1 oraz wszystkie urządzenia w tablicy ARP o masce 192.168.*.1|254 , gdyż np. wiemy, że urządzenia z końcówką 1 to tylko routery, a 254 to firewalle.

Rysunek 9 - Wykrywanie urządzeń sieciowych w OpsMgr 2012

Rysunek 10 - Filtrowanie wykrywania urządzeń z tablicy ARP

Trzecia i bardzo ważna rzecz, to fakt możliwości wykorzystania SNMPv3 to wykrywania urządzeń sieciowych i komunikacji z nimi. Tak samo jak w przypadku SNMPv2 należy utworzyć RunAs Account, ale zamiast prostego Community String należy uzupełnić protokoły uwierzytelnienia i dostępności (MD5|SHA, AES|DES).

Rysunek 11 - Tworzenie konta SMNPv3 w OpsMgr 2012

Jakkolwiek do monitorowania urządzeń sieciowych, tak samo jak w przypadku agentów, wykorzystywana jest pula management serwerów, tak do wykrywania (następuje ono wg ustalonego harmonogramu, np. raz w tygodniu o północy) jest potrzebny stricte jeden serwer (MS lub Gateway) i tylko on będzie wykrywał urządzenia sieciowe.

Po wykryciu urządzeń sieciowych możemy już przejść do widoków, które pozwalają na zgłębienie właściwości i stanu środowiska sieciowego.

Rysunek 12 - Lista widoków urządzeń sieciowych w OpsMgr 2012

Najważniejszymi widokami są Dashboardy. Ponieważ powszechna była krytyka, że obecne dashboardy ładują się bardzo wolno i są po prostu nieprzejrzyste, przeszły one bardzo duże zmiany. Zaimplemetowane w OpsMgr 2012 są o wiele lepsze. Rzeczywiście przekazują skumulowaną wiedzę na temat interfejsów, wykorzystania łącz, wolnej pamięci, konfigurację oraz alarmy. Dodatkowo istnieje bardzo ważny widok – widok sąsiedztwa (Vicinity View), który pokazuje połączenia pomiędzy urządzeniami sieciowymi oraz serwery wpięte do tych urządzeń bezpośrednio. Dzięki temu wiemy dokładnie, w którym miejscu nastąpiła awaria i dlaczego serwer nie umie połączyć się z bazą danych.

Rysunek 13 - Widok sąsiedztwa w OpsMgr 2012

Tak jak wspomniałem, nie monitorujemy już tylko zwykłego pinga SNMP – teraz monitorujemy out-of-the-box pamięć, procesor, stan interfejsów, ich zużycie oraz poziom błędów, czyli właściwie wszystko, co daje nam podstawowy mib-2. Zbierane są też podstawowe liczniki wydajnościowe odnoszące się do wspomnianych elementów urządzenia. Nie jest to oczywiście bardzo wysublimowane monitorowanie, ale w kontekście ogólnego rzutu okiem na infrastrukturę w zupełności wystarczy.

Monitorowanie wydajności aplikacji ASP.NET

AVICode, bo tak zwie się firma zakupiona dwa lata temu przez Microsoft, udostępniła moduł monitorowania aplikacji Web napisanych na platformie ASP.NET. Moduł ten dostępny jest jako dodatkowy dla specyficznych sposobów licencjonowania grupowego a także jako wersja próbna do pobrania jako Management Pack. Teraz będzie to integralna część Operations Managera.

Aplikacje ASP.NET są monitorowane zarówno od strony klienta, jak i serwera. Zbierane są szczegółowe metryki wydajnościowe, zdarzenia .NET czy wyjątki kodu. Dzięki dodatkom zwanym Application Advisor i Application Diagnostics dostępnym z poziomu Menu Start folderu Operations Managera 2012, mamy dogłębny wgląd we wszystkie zdarzenia, opóźnienia w wykonywaniu kodu, wyjątki serwera IIS czy ASP oraz listę następujących po sobie zdarzeń w przypadku reakcji łańcuchowej.

Rysunek 14 - Lista aplikacji ASP w OpsMgr 2012

Rysunek 15 - Właściwości alarmu ASP.NET w OpsMgr 2012

Rysunek 16 - Właściwości zdarzenia WCF w aplikacji Application Diagnostics

Administracja

PowerShell

Operations Manager 2012 posiada całkowicie przebudowany Operations Manager Shell oparty o PowerShell 2.0. Co to oznacza? Że skrypty, które były pisane w dla poprzednich wersji po prostu nie będą działać, chyba, że zostanie zainstalowany i uruchomiony poprzedni provider (jego wsparcie w OpsMgr 2012 nie zostało usunięte). Aby przyjrzeć się nowej liście Command-Letów należy otworzyć Operations Manager Shell i wykonać polecenie Get-Help about_OpsMgr_Cmdlet_Names.

Rysunek 17 - PowerShell w OpsMgr 2012

Konsola Web

Kolejna bardzo dobra wiadomość. Jesteś operatorem środowiska Operations Manager? Dzięki zastosowaniu Framework 4.0 i funkcjonalności ASP.NET, mamy do dyspozycji wszystkie widoki, których wcześniej nie mogliśmy w stanie pokazać, np. widok dashboardów. Poza tym zmienił się adres witryny. Teraz nie musimy wchodzić na port 51908, a wystarczy wpisać http://server/OperationsManager.

Rysunek 18 - Nowa konsola Web w OpsMgr 2012

Dodatkowo dashboardy mogą być publikowane na witrynie SharePoint i to nie tylko w wersji Enterprise, ale także Standard oraz Foundation, co na pewno ucieszy osoby posiadające środowisko SPS.

Pozostałe informacje

Teoretycznie mogłoby to być wszystko, gdyby nie pewien zdumiewający fakt, który pokazuje poniższy rysunek.

Rysunek 19 - Spolszczenie elementów w OpsMgr 2012

Czyżby krok po kroku system Operations Manager 2012 miał być spolszczany? Tego nie wiedzieliśmy wcześniej, ale widać, że powoli Management Packi są tłumaczone na więcej języków niż do tej pory to było, a zatem część <LanguagePack> w XML znacznie się rozrośnie. Już podczas instalacji systemu OpsMgr 2012 było można zauważyć, że import Management Packów trwa zdecydowanie dłużej niż do tej pory.

Podsumowanie

System Center Operations Manager 2012 jest jeszcze bardziej przystosowany do pracy w środowisku heterogenicznym niż był do tej pory. Możemy śmiało powiedzieć, że konkurencja musi mieć się ostro na baczności. Rozwiązania naprawdę działają (choć to dopiero wersja Beta 1) i warto pobrać tę wersję, aby przetestować w swoim środowisku działanie tej aplikacji na kilku serwerach. Najważniejsze jest też to, że Management Packi z poprzednich wersji są w pełni kompatybilne, więc można importować to, co miało się do tej pory. Z mojej strony mogę zapewnić, że niebawem pojawi się zestaw artykułów dogłębnie traktujący o nowościach w Operations Manager 2012, a tymczasem zapraszam do dzielenia się uwagami ze swoich testów.