Windows Server 2008

System Center Operations Manager 2007: Wprowadzenie i instalacja Udostępnij na: Facebook

Autor: Łukasz Rutkowski

Opublikowano: 9 czerwca 2009

Wprowadzenie  Wprowadzenie
Wymagania przedinstalacyjne  Wymagania przedinstalacyjne
Podsumowanie  Podsumowanie
Przydatne miejsca  Przydatne miejsca
 

Microsoft twierdzi, że produkt System Center Operations Manager 2007 to najlepszy sposób na monitorowanie środowiska w głównej mierze opartego na systemach Windows. Trudno się z tą tezą nie zgodzić, przecież to Microsoft sam najlepiej powinien wiedzieć, jakie błędy występują w jego własnym środowisku.

Następca MOMa 2005, szczególnie po implementacji Service Packa 1, ma się znakomicie. Rok czasu wystarczył na „rozgrzanie się” produktu, kolejne implementacje poprawek do Management Packów spowodowały usprawnienie monitorowania aplikacji, usług i systemów.

 

Wprowadzenie

SCOM 2007, lub jak wolą twórcy OpsMgr 2007, jest dość ciekawą aplikacją, która w zależności od chęci monitorowania architektury, składa się z kilku podstawowych elementów:

Pobierz
Pobierz artykuł w pliku:
  • RMS (Root Management Server) – główny serwer, na którym działają usługi konfiguracyjne i SDK, dzięki czemu do tego serwera można podłączyć się konsolą, łączy się on z bazą danych, przekazuje informacje do Data Warehouse i wielu innych
  • MS (Management Server) – serwer zarządzający agentami, zbierający z nich informacje i dystrybuujący konfigurację (RMS także może pełnić rolę zarządzającą agentami, lecz nie jest to zalecane ze względu na zbyt duże obciążenia zasobów)
  • Gateway Server – serwer/brama, który umożliwia monitorowanie serwerów będących w oddzielnej domenie (bez obustronnego uwierzytelnienia) lub komputerów w grupach roboczych. Zastosowanie tego serwera ma na celu stworzenie jednego punktu wymiany certyfikatów pomiędzy agentami a MSem
  • Reporting Server – serwer raportowy, na którym działa usługa SQL Reporting Services i odwołuje się do bazy Data Warehouse
  • ACS Collector i ACS Gateway – usługi, które służą do zbierania i przekazywania do bazy danych wszystkich logów Security z serwerów Windows, a następnie do analizy bezpieczeństwa

Architektura SCOM 2007

Rysunek 1: Architektura SCOM 2007.

Proces instalacji na potrzeby artykułu został przygotowany na jednym serwerze wirtualnym. Znalazły się na nim komponenty: SQL Server 2005 EE, SQL Reporting Services 2005 , RMS oraz Reporting Server.

Ostatnim elementem, na który należy zwrócić uwagę, to instalacja serwera na systemach x64 – nic nie trzeba dodatkowego robić. Instalator sam rozpoznaje system i instaluje odpowiednie pliki. Zalecam jednak instalację SQL Server także w wersji x64, żeby uniknąć problemów z kompatybilnością. Jednym z zaleceń Microsoft jest używanie wyłącznie systemów 64-bitowych.

 Do początku strony Do początku strony

Wymagania przedinstalacyjne

Zanim zabierzemy się za instalację, warto zaopatrzyć się w kilka przydatnych aplikacji, bez których nasz system nie będzie w stanie stanąć na równe nogi. A zatem:

  • SQL Server 2005 EE SP2 + Reporting Services – zaleca się wersję Enterprise, gdyż wspiera nieograniczoną ilość procesorów, a poza tym takie opcje jak Online Restore, Online Indexing czy Fast Recovery.
  • Windows Powershell 1.0 – do obsługi poleceń w PowerShellu.
  • IIS + ASP .NET – do instalacji z płyty instalacyjnej Windows, ale tylko w przypadku, jeśli chcemy używać konsoli webowej.
  • .NET Framework 2.0 i 3.0 – na większości systemów jest uaktualniony Framework 2.0, więc zaleca się zainstalowane jedynie poprawek.
  • MDAC 2.8 – w wersji Windows 2003 Server SP2 i R2 jest już uaktualniony MDAC.

Warto także zwrócić uwagę na fakt, iż serwer RMS potrzebuje minimum 2 GB pamięci RAM. No i podstawowa cecha – komputer musi być dołączony do domeny, bez tego ani rusz. Przydatnym narzędziem jest tutaj Prerequisite Viewer, który sprawdzi przed instalacją wszystkie wymagane komponenty. W oknie System Center Operations Manager 2007 Setup wybieramy Check Prerequisites.

Okno powitalne SCOM 2007

Rysunek 2: Okno powitalne SCOM 2007.

W oknie, które się pojawi zaznaczamy wszystkie opcje i wybieramy Check. Dla zobrazowania problemu nie został zainstalowany Service Pack do SQL Server 2005. Po pojawieniu się błędów nie radzę instalować na siłę komponentów SCOMa, tylko doprowadzić do zapalenia się wszystkich lampek na zielony kolor.

Gdy testujemy system monitorujący, ilość pamięci nie musi być większa niż 2 GB (u mnie wynosi 1 GB), ale wierzcie – będzie chodziło wszystko dość wolno. 2 GB jest także przeznaczone dla systemów, na którym będzie działać Data Warehouse. Jak zatem widać, najlepiej zaopatrzyć się w 64-bitową maszynę i nie martwić się o ograniczenia 4 GB RAM. W dalszej części instalacji pominiemy instalację Data Warehouse i serwera raportowego, a skupimy się w głównej mierze na głównych komponentach i ich konfiguracji.

Sprawdzenie komponentów wymaganych do instalacji

Rysunek 3: Sprawdzenie komponentów wymaganych do instalacji.

Po instalacji SQL Server Service Pack 2 (SCOM także działa z SP1) Prerequisite Viewer nie ma już zastrzeżeń, co do komponentów wymaganych do instalacji. Wybieramy Close i przechodzimy z powrotem do okna Setup, gdzie wybieramy Install Operations Manager 2007 .

Pomyślnie zakończone sprawdzanie systemu

Rysunek 4: Pomyślnie zakończone sprawdzanie systemu.

Z początku wita nas znane okno instalatora.

Okno instalatora

Rysunek 5: Okno instalatora.

Po akceptacji licencji i wpisaniu danych personalnych, przechodzimy do okna wyboru komponentów do instalacji. Ponieważ nasze laboratorium będzie składało się z jednego serwera zarządzającego, wszystkie elementy widoczne na ekranie powinny być zaznaczone.

Wybór komponentów do instalacji

Rysunek 6: Wybór komponentów do instalacji.

Od razu policzmy, ile powinniśmy przeznaczyć miejsca na czystą instalację systemu, bez modułu raportowego.

  • Baza danych = 1000 MB
  • Management Server = 73 MB
  • Interfejsy użytkowników = 51 MB
  • Konsola Web = 27 MB

W sumie około 1200 MB na całkowicie czystą instalację. Pamiętajmy jednak, że od razu po instalacji załadowane zostają główne Management Packi, które zostają w pewnej części zachowane w bazie danych. Po instalacji przejrzymy jeszcze, jak nasze zasoby zostały obciążone, a tymczasem instalujemy dalej.

Kolejne okno ostrzega nas, że Prerequisite Viewer znalazł ostrzeżenia, ale my ignorujemy to wskazanie. Teraz musimy nazwać naszą Management Group. Niech to będzie SCOM-LAB.

Nadanie nazwy dla Management Group

Rysunek 7: Nadanie nazwy dla Management Group.

W tym oknie jest jeszcze jeden krok, który dość często jest pomijany, a jest bardzo ważny z punktu widzenia zarządzania i bezpieczeństwa. Warto stworzyć w Active Directory grupę SCOM Administrators, do której przydzielimy użytkowników z prawami administratora do systemu SCOM. Są dwa powody, dla których funkcja ta nie powinna być pomijana:

  1. Nie każdy administrator powinien mieć możliwość zabawy SCOMem
  2. Jeśli już ktoś coś popsuje, zawsze grono ludzi będzie zawężone

Klikamy Next. Kolejne okno to wybór bazy danych i instancji, na której działać będzie baza OperationsManager.

Wybór bazy danych dla SCOM

Rysunek 8: Wybór bazy danych dla SCOM.

Jeśli to jest właśnie nasza baza, przechodzimy do kolejnego kroku. Musimy teraz podać lokalizację, gdzie baza danych będzie przetrzymywana (plik bazy) oraz jest nominalną wielkość. Wielkość domyślna wynosi 1000 MB (czyli nawet nie 1 GB). Im mniejsza wartość, tym lepiej dla środowiska, gdyż przyspieszy to wyciąganie danych z bazy do konsoli.

Lokalizacja i wielkość bazy danych SCOM

Rysunek 9: Lokalizacja i wielkość bazy danych SCOM.

Teraz kolejny bardzo ważny krok. Należy podać konto, które będzie głównym kontem, na którym serwer zarządzający będzie działał, czyli Management Server Action Account.

Mniej restrykcyjne polisy w firmie = konto z prawami Lokalnego Administratora na serwerach, na których będzie instalowany agent. Bardziej restrykcyjne polisy = konto z prawami Local User, Performance Monitor User oraz prawo Allow log on locally permission (SetInteractiveLogonRight)

Konto, na którym ma działać SCOM

Rysunek 10: Konto, na którym ma działać SCOM.

W następnym kroku podajemy użytkownika i hasło do konta Config and SDK. Tutaj już użytkownik musi mieć prawo lokalnego administratora na systemie z serwerem zarządzającym. Od nas zależy, czy wykorzystamy konto z AD, czy konto Local System. Powszechnie używane są konta stworzone w AD, co jest tzw. best practice.

Następnym krokiem jest podanie metody uwierzytelnienia się z konsolą Web. Jeśli wykorzystujemy konsolę wyłącznie w intranecie, Windows Authentication jest w zupełności wystarczające, natomiast skonfigurowanie SSL-a na IIS wymagane jest przy metodie Forms Authentication, gdzie za każdym razem przy próbie logowania będziemy mieli pop-up z prośbą o zalogowanie się.

Wybór sposobu logowania do konsoli Web

Rysunek 11: Wybór sposobu logowania do konsoli Web.

Kolejne okno teoretycznie powinniśmy ominąć, lecz zalecam nie robienie tego. Jest to okno z pytaniem o wysyłanie błędów związanych ze SCOM-em do Microsoftu. Bardzo, ale to bardzo zalecam włączenie tej opcji i wysłanie paczek w przypadku błędów z systemem. Dzięki włączonej tej opcji w dużej mierze powstał Service Pack 1 i 80% błędów zostało w nim rozwiązanych, które właśnie były zgłaszane przez Windows Error Reporting . Nie bójmy się tego włączać, nie wysyła to żadnych poufnych danych, żadnych nazw użytkowników ani informacji o naszym środowisku.

Czy wysyłać informacje o błędach do Microsoft? Tak!

Rysunek 12: Czy wysyłać informacje o błędach do Microsoft? Tak!.

Dopiero następne okno możemy pominąć, chyba, że chcemy, aby Microsoft wiedział, w jakim procencie całego czasu korzystania ze SCOMa wykorzystujemy dane jego fragmenty, aby to je właśnie najbardziej rozwijać w przyszłości.

Ten punkt pomińmy i… kolejny także. Włącza on bowiem możliwość uzyskania poprawek do SCOMa przy pomocy Microsoft Update. Czyli dwuklik na Next/Next i kreator oznajmia, że jest w pełni gotowości do rozpoczęcie instalacji systemu System Center Operations Manager 2007 Service Pack 1.

System jest gotowy do instalacji

Rysunek 13: System jest gotowy do instalacji.

Po około 10 minutach nasz system jest gotowy do pierwszego uruchomienia. Zanim nastąpi pierwsze uruchomienie konsoli, zalecane jest wykonanie kilku dodatkowych czynności.

Zanim uruchomimy konsolę

Rysunek 14: Zanim uruchomimy konsolę.

Pierwsza rzecz, to backup klucza odszyfrowującego (Encryption Key). Klucz ten pozwala na szyfrowane połączenie z bazą danych. W przypadku awarii RMSa, można nadać innemu Management Serverowi jego rolę, ale żeby nowy RMS mógł czytać z bazy danych, należy mu właśnie wgrać ów klucz.

W wersji SCOM 2007 RTM backup ten był wykonywany ręcznie poprzez polecenie systemowe. W SP1 został stworzony kreator backupu, toteż nie musimy już wykonywać wszystkiego z poziomu konsoli poleceń cmd.

Kreator backupu klucza szyfrującego

Rysunek 15: Kreator backupu klucza szyfrującego.

Klikamy Next w oknie powitalnym i wybieramy domyślną opcję Backup the Encryption Key.

Backup klucza

Rysunek 16: Backup klucza.

Ponieważ klucz powinien być przechowywany w bezpiecznym miejscu, zaleca się trzymanie go na komputerze lub dysku zupełnie nie związanym z systemem SCOM (USB, zasób sieciowy itp.).

Lokalizacja dla przechowywania backupu klucza

Rysunek 17: Lokalizacja dla przechowywania backupu klucza.

Następnie podajemy hasło zabezpieczające nasz backup.

Hasła dla backupu klucza

Rysunek 18: Hasła dla backupu klucza.

Dopiero po poprawnym potwierdzeniu hasła pojawi się przycisk Next, co też zostało wykonane. Po poprawnym zapisaniu pliku przechodzimy do kolejnej poinstalacyjnej konfiguracji, którą warto przeprowadzić przed uruchomieniem systemu.

Otwieramy SQL Management Studio i podłączamy się do naszej bazy OperationsManager. Gdy rozwinęliśmy lewe drzewko z bazą danych, klikamy na tej bazie prawym przyciskiem i wybieramy Properties. Przechodzimy do zakładki Files i widzimy nasze pliki bazy danych.

Baza danych SCOM

Rysunek 19: Baza danych SCOM.

Teraz powinniśmy włączyć automatyczny rozrost bazy o 10% w nieskończoność. Wybieramy zatem przycisk (…) w kolumnie Autogrowth i uzupełniamy pola wg poniższego rysunku dla bazy i logu.

Konfiguracja rozrostu bazy

Rysunek 20: Konfiguracja rozrostu bazy.

UWAGA – jeśli zostanie wybrana taka konfiguracja i potwierdzicie ją przyciskiem OK., a następnie wrócicie do tych ustawień ponownie, okaże się, że konfiguracja została ustawiona błędnie – rozrost będzie ograniczony do… inicjalnych ustawień! Trzeba zatem ponownie ustawić Unrestricted File Growth, co na stałe ustawi poprawny rozrost bazy danych… ale nie pliku logu, ten bowiem zostanie ustawiony na ograniczenie do… 2 TB.

Poprawnie ustawione wartości

Rysunek 21: Poprawnie ustawione wartości.

Zamykamy zatem konsolę SQL-a i konsola SCOM może być uruchomiona bez problemów.

Konsola SCOM

Rysunek 22: Konsola SCOM.

 Do początku strony Do początku strony

Podsumowanie

Instalacja systemu jest bardzo prosta. Głównie sprowadza się ona do instalacji bazy, komponentów, systemu oraz stworzenia kilku kont w AD.

W kolejnej części przedstawione zostaną kroki, które należy podjąć, aby skonfigurować nasz system do jak najlepszej pracy, trochę będzie o integracji z Active Directory oraz przygotowanie środowiska do instalacji agentów.

 Do początku strony Do początku strony

Przydatne miejsca

Zapraszam także do lektury System Center Operations Manager 2007 Unleashed, która jest pozycją wartą przeczytania od deski do deski, a także Mastering System Center Operations Manager 2007.


Łukasz Rutkowski Łukasz Rutkowski (MCSA, MCITP)
Konsultant ITSM w firmie Ingrifo. Zajmuje się wdrażaniem i wsparciem systemów monitorowania System Center Operations Manager 2007 oraz pozostałych producentów oprogramowania. Współzałożyciel Polskiej Grupy System Center.
 Do początku strony Do początku strony

Windows Server 2008