Dynamiczne konfigurowanie ról Configure Manager Roles przy użyciu VMM oraz Operations Manager, część 1

Autor: Chris Adams

Opublikowano: 14 września 2009

Zawartość strony

	VMM: Przygotowanie fundamentów
	Instalacja VMM Server
	Instalacje VMM Agent
	Biblioteka VMM: Składnik rozwiązania do dynamicznego inicjowania obsługi administracyjnej
	Nie dla pomocy klonów
	Stosowanie profili i szablonów
	Zastosowanie narzędzia WAIK

Centra danych ewoluują z dnia na dzień, a tempo zmian dodatkowo zwiększyło się po wprowadzeniu wirtualizacji. System Configuration Manager 2007 przy pomocy platformy wirtualizacji firmy Microsoft implementuje mechanizm dynamicznego inicjowania obsługi administracyjnej, co umożliwia skalowanie usług klienckich i zwiększanie efektywności rozwiązań. Ponad 300-tysięczna baza klientów zmusiła firmę Microsoft do niestandardowego spojrzenia na problem skalowania i poszukiwania nowych sposobów zwiększania stopnia automatyzacji oraz wydajności. Zdobyte przez nas doświadczenia mogą pomóc innym firmom w osiąganiu analogicznych efektów.

VMM: Przygotowanie fundamentów

Pierwszym krokiem do pomyślnego skonstruowania infrastruktury Configuration Manager, która może być skalowana szybko i rozlegle, jest odejście od modelu "bazującego na serwerach" na rzecz modelu "bazującego na usługach". W świecie usług jednostkami skali są obiekty sprzętowe, takie jak procesory, pamięć, dyski czy sieci, natomiast fizyczne serwery, w których umieszczone zostały te zasoby, mają mniejsze znaczenie.

Implementowanie modelu usługowego należy rozpocząć od zbudowania infrastruktury maszyny wirtualnej (VM). Zanim przejdziemy do omówienia szczegółowych zagadnień, zajmijmy się podstawowymi zagadnieniami. System Center Virtual Machine Manager 2008 (w skrócie VMM) oferuje wiele opcji konfiguracyjnych dostępnych w centrum danych. VMM składa się z czterech komponentów, które charakteryzują się różnymi jednostkami skalowania:

1. Virtual Machine Manager Server
2. Virtual Machine Manager Library
3. Virtual Machine Manager Agent
4. Virtual Machine Manager Self-Service Portal

Rozwiązanie jest zbudowane zgodnie z koncepcją dynamicznego inicjowania obsługi administracyjnej. Pierwsze trzy elementy zostaną omówione w tym artykule. Natomiast informacje na temat komponentu VMM Self-Service Portal znaleźć można w artykule System Requirements: VMM Self-Service Portal.

 Do początku strony

Instalacja VMM Server

Mózg całej operacji, VMM Server, bazuje na bazie danych VMM, która powinna zostać uruchomiona w klastrze SQL Server. Klaster zapewnia wysoką dostępność silnika zadań, który realizuje wszystkie zadania związane z hostem i systemami gościnnymi maszyny wirtualnej (VM) m.in. tworzeniem i przenoszeniem maszyn wirtualnych oraz wyznaczaniem miejsca magazynowania.

VMM Server stanowi pojedynczy serwer, który dostarcza administratorom informacji dotyczących fizycznych hostów oraz zasobów wirtualnych. Dzięki zastosowaniu dostępnych w centrach danych technologii sprzętowych, takich jak Direct-Attached Storage (DAS) oraz Storage-Area Networks (SAN), można przetransformować dotychczasowe środowisko w arcydzieło w dziedzinie dynamicznego inicjowania obsługi administracyjnej.

Pierwsza instalacja VMM wiąże się z zainstalowaniem dwóch komponentów: VMM Server (wraz z bazą danych) oraz pierwszego wystąpienia biblioteki (VMM Library). Należy z rozwagą zaplanować tę operację, korzystając np. z godnego polecenia artykułu Planning for High Availability.

 Do początku strony

Instalacje VMM Agent

Następnie należy przygotować bazujące na systemie Windows serwery wirtualizacji do wykorzystania w infrastrukturze VMM. Można zastosować system Windows Server 2008 z rolą Hyper-V lub autonomiczny system Hyper-V Server. VMM oferuje dwie metody konfigurowania hostów wirtualnych: odkrywanie w oparciu o Active Directory oraz własnoręczną instalację.

Skoncentrujemy się na odkrywaniu w oparciu o Active Directory, ponieważ podejście to jest bardziej popularne. Proces jest dość prosty, w zasadzie wystarczy określić domyślną lokalizację magazynu maszyn wirtualnych (np. D:\VMs) oraz zadecydować, czy rola Hyper-V ma zostać zainstalowana w systemie Windows Server 2008 (o ile nie została ona jeszcze skonfigurowana).

VMM Agent jest instalowany na wszystkich serwerach Windows, które działają jako Local System (System lokalny). Komunikuje się z hostem za pośrednictwem Windows Remote Management (WinRM). Instalacja systemu agenta wiąże się z włączeniem usługi WinRM, która umożliwia bazującą na protokole HTTP komunikację między zarządzanym hostem a VMM Server.

Po zakończeniu procesu instalacji konsola VMM Administrator Console powinna prezentować listę hostów dostępnych w centrum danych.

 Do początku strony

Biblioteka VMM: Składnik rozwiązania do dynamicznego inicjowania obsługi administracyjnej

Fundament w postaci VMM Server został już postawiony. Teraz pora zająć się biblioteką. Biblioteka VMM (VMM Library) stanowi podstawowy składnik rozwiązania do dynamicznego inicjowania obsługi administracyjnej. Biblioteka to główna jednostka skali w systemie VMM. Infrastruktura może zawierać wiele serwerów bibliotek, podczas gdy serwerów VMM nie można dodawać. Biblioteka to składnik mechanizmu wdrażania i inicjowania obsługi administracyjnej. Podczas instalacji pierwsza biblioteka VMM jest umieszczana na serwerze VMM, dodatkowe biblioteki powinny zostać rozmieszczone na innych serwerach. W firmie Microsoft staramy się utrzymywać instalacje bibliotek możliwie jak najbliżej obsługiwanego przez nich hosta. Załóżmy na przykład, że mamy grupę hostów składającą się z ośmiu serwerów Hyper-V, które obsługują centrum danych Seattle, natomiast pomocnicze centrum danych znajduje się w Bostonie i zawiera jednego hosta Hyper-V (patrz Rysunek 1). W Seattle umieścilibyśmy wiele serwerów bibliotek obsługujących grupę hostów, natomiast w Bostonie wystarczyłby jeden serwer biblioteki.

Rysunek 1: Zastosowanie wielu bibliotek w systemie System Center Virtual Machine Manager.

Biblioteki centrów danych służą do przechowywania wirtualnych dysków twardych, skryptów oraz obrazów. Utrzymywanie bibliotek w pobliżu obsługiwanych hostów umożliwia skrócenie czasu oczekiwania na zainicjowanie obsługi administracyjnej.

Po dodaniu odpowiednich serwerów bibliotek do infrastruktury warto poznać metody inicjowania obsługi administracyjnej dla wybranych usług.

 Do początku strony

Nie dla pomocy klonów

W przypadku wykorzystania wirtualizacji dostępnych jest kilka technik inicjowania obsługi administracyjnej. Jedną z nich jest klonowanie, które polega na tym, że przechowywana jest cała maszyna, w tym także informacje charakterystyczne dla maszyny, takie jak jej nazwa, adres IP oraz dane dotyczące profilu.

Klonowanie bywa przydatne w pewnych sytuacjach, ale w przypadku dynamicznego inicjowania obsługi administracyjnej przysparza więcej kłopotów niż korzyści. Pierwszy problem wynika z tego, że mechanizm klonowania wymaga, aby komputer pozostał częścią infrastruktury (w kontekście Active Directory, Operations Manager itp.), pomimo iż sam system nie jest dostępny w trybie online (znajduje się w bibliotece). To prowadzi do pojawiania się fałszywych wskazań podczas budowania dynamicznych usług w centrum danych np. system jest prezentowany jako dostępny, gdy w rzeczywistości znajduje się w trybie offline.

Druga wada klonowania związana jest z wymaganiami dotyczącymi miejsca do magazynowania. Wszystkie jednostki skali (zdefiniowane jako jeden serwer = jedna jednostka skali) są przechowywane w całości, w związku z czym maszyny wirtualne mają duże wymagania dotyczące miejsca na dysku. Na przykład sklonowany punkt dystrybucji Configuration Manager 2007 (DP) zawiera trzy wirtualne dyski twarde o łącznym rozmiarze 130 GB. Co więcej, w rozwiązaniu zastosowanym przez firmę Microsoft jedna lokacja może wykorzystywać nawet sześć punktów dystrybucji. A zatem proces klonowania mógłby potrzebować 780 GB w bibliotece. Wymagania te rosną w zawrotnym tempie.

Metoda inicjowania obsługi administracyjnej o nazwie "podstawowy obraz" stanowi z reguły lepsze rozwiązanie. Zgodnie z jej założeniami tworzony jest obraz podstawowego systemu operacyjnego, na którym zainstalowane są jedynie domyślne usługi niezbędne do działania systemu. Firma Microsoft wykorzystuje trzy podstawowe obrazy Windows Server 2003 R2, Windows Server 2008 oraz Windows Server 2008 R2, które znajdują się na wirtualnych dyskach twardych (VHD) w bibliotece. Każdy podstawowy obraz ma rozmiar między 6 GB a 10 GB, co stanowi dużo wydajniejsze rozwiązanie niż 130 GB potrzebne w przypadku klonowania.

 Do początku strony

Stosowanie profili i szablonów

Po określeniu metody inicjowania obsługi administracyjnej należy stworzyć profile. Profile stanowią definiowane na poziomie VMM jednostki, które w bardzo ogólny sposób opisują sprzęt lub system operacyjny. Profil sprzętu (Hardware) definiuje takie aspekty jak liczba procesorów, liczba i typ dysków twardych (IDE lub SCSI) oraz konfiguracja sieci. Profil gościnnego systemu operacyjnego zawiera charakterystyczne dla systemu Windows informacje dotyczące określonych, wspieranych ról. Profil ten definiuje takie aspekty jak nazwa maszyny, klucze produktu oraz dane związane z domeną.

Dynamiczne inicjowanie obsługi administracyjnej odbywa się w oparciu o profile sprzętu lub gościnnego systemu operacyjnego. Klienckie role Configuration Manager ulegają rozszerzeniu, ale podstawowe założenia pozostają takie same dla wszystkich profili. Bardziej szczegółowe informacje na temat tworzenia profili sprzętowych i gościnnego systemu operacyjnego oraz szablonów znaleźć można w blogu autora artykułu Virtual Machine Manager Library: This ain’t got no Card Catalog and you are the Crazy Librarian.

Po stworzeniu profili można zająć się szablonami. Szablony opisują szczegółowe cechy sprzętu oraz systemu operacyjnego serwera, dzięki czemu nie muszą być one definiowane osobno dla każdej maszyny. Kluczowa różnica pomiędzy profilami a szablonami leży w ich precyzyjności: szablony są bardzo dokładne, natomiast profile nie. Profile opisują na przykład, jak typ adaptera sieciowego ma zostać zbudowany, ale nie obejmują informacji dotyczących połączenia dla tego adaptera. Tego typu informacje stanowią część szablonu.

W związku z tym trzystopniowy proces polega na stworzeniu profilu sprzętu, następnie profilu gościnnego systemu operacyjnego, a na zakończenie szablonu dla lokacji. Stosując to podejście w przykładzie Seattle-Boston, trzeba byłoby rozpocząć od punktów dystrybucji Configuration Manager oraz ich osobnych grup hostów w centrach danych Seattle oraz Boston. Po pierwsze należałoby stworzyć profile sprzętu, później skonfigurować informacje o systemie operacyjnym dla całej infrastruktury, a na zakończenie zbudować szablony dla poszczególnych lokacji w oparciu o te profile. Ponieważ centra danych Seattle oraz Boston korzystają z różnych sieci, szablony umożliwiają wprowadzenie dodatkowych modyfikacji.

 Do początku strony

Zastosowanie narzędzia WAIK

Po skonfigurowaniu profili oraz szablonów nadeszła pora, aby przejść do dynamicznego inicjowania obsługi administracyjnej systemu operacyjnego. W rozwiązaniu firmy Microsoft oznacza to zastosowanie narzędzia Windows Automated Installation Toolkit (WAIK), które umożliwia dostosowywanie instalacji Windows (patrz Rysunek 2). W świecie dynamicznego inicjowania obsługi administracyjnej pełna instalacja systemu operacyjnego nie jest wykonalna, ponieważ zajęłaby zbyt dużo czasu.

Rysunek 2: Krok po kroku: Podział procesu dynamicznego inicjowania obsługi administracyjnej w warstwie systemu operacyjnego.

Wykorzystujemy dość popularny proces o nazwie sysprep, który usuwa z zainstalowanego systemu wszelkie informacje charakterystyczne dla maszyny lub użytkowników. Na zwykłym serwerze, na którym uruchomiony został program sysprepped, podczas pierwszego wykonania użytkownik widzi tylko listę pytań, serwer realizuje pozostałe zadania. Proces udzielania odpowiedzi na pytania zostaje zautomatyzowany przy pomocy pliku instalacji bez nadzoru. W zależności od systemu operacyjnego plik ten jest przechowywany w bibliotece i odwołanie do niego stanowi część profilu gościnnego systemu operacyjnego.

Korzyścią płynącą z podziału procesu instalacji jest możliwość dowiadywania się, krok po kroku, jakie wymagania muszą zostać spełnione przed wdrożeniem nowej usługi. Po określeniu tych wymagań należy opracować plan działania, aby zrealizować odpowiednie zadania przy pomocy pliku instalacji bez nadzoru.

W drugiej części opisano budowanie pliku instalacji bez nadzoru, konfigurację roli lokacji Configuration Manager, testowanie środowiska ze wsparciem dla dynamicznego inicjowania obsługi administracyjnej, testowanie i weryfikację środowiska oraz łączenie elementów w całość.

• Dynamiczne konfigurowanie ról Configure Manager Roles przy użyciu VMM oraz Operations Manager, część 2

O autorze

Chris Adams pełni funkcję głównego menedżera programu w dziale Management & Services w firmie Microsoft. Specjalizuje się w rozwiązaniach System Center Configuration Manager oraz System Center Virtual Machine Manager.

Do początku strony