Zagadnienia dotyczące projektowania puli zasobów

Pula zasobów to logiczne grupowanie serwerów zarządzania i/lub serwerów bramy używanych do dystrybucji pracy między sobą i przejęcia pracy od elementu członkowskiego, który zakończył się niepowodzeniem. Innymi słowy zapewniają one wysoką dostępność i skalowalność przepływów pracy. Podczas projektowania grupy zarządzania należy wziąć pod uwagę monitorowanie urządzeń sieciowych, systemów Linux/UNIX oraz innych obciążeń roboczych zaprojektowanych z myślą o korzystaniu z puli zasobów.

Omówienie

Pule zasobów zapewniają ciągłość monitorowania, udostępniając wiele elementów członkowskich, które są serwerami zarządzania i/lub serwerami bramy, które mogą przejąć przepływy pracy monitorowania, jeśli jeden z elementów członkowskich puli stanie się niedostępny. Pule zasobów można tworzyć do określonych celów. Można na przykład utworzyć pulę zasobów serwerów zarządzania w podstawowym centrum danych w celu monitorowania urządzeń sieciowych.

Pule zasobów stosują logikę podobną do klastrowania "większościowego zestawu węzłów", gdzie (< liczba węzłów jako elementy członkowskie puli > /2) + 1. Co najmniej w puli musi istnieć trzy elementy członkowskie, aby utrzymać kworum, co musi być więcej niż 50% elementów członkowskich głosowania kworum w puli w celu utrzymania dostępności puli. Jeśli masz tylko dwa elementy członkowskie puli i jeden jest niedostępny, utracono kworum.

Dla każdej puli zasobów utworzonej w konsoli Operacje baza danych programu Operations Manager, która jest nazywana domyślnym obserwatorem, zawsze otrzymuje głos, nawet jeśli w puli istnieje parzysta liczba elementów członkowskich umożliwiających osiągnięcie kworum. Dotyczy to również trzech pul zasobów utworzonych domyślnie podczas pierwszego tworzenia grupy zarządzania, która została omówiona w dalszej części tego artykułu. Dla wszystkich pul zasobów utworzonych przy użyciu polecenia cmdlet Programu PowerShell NewSCOM-ResourcePool jest ono domyślnie wyłączone. Uwzględnienie bazy danych programu Operations Manager jako domyślnego obserwatora zmniejsza złożoność grupy zarządzania przez wymaganie co najmniej wdrożenia dwóch serwerów zarządzania w celu utrzymania wysokiej dostępności pul zasobów.

Inną rolą obsługującą pulę zasobów są obserwatorzy. Jest to serwer zarządzania lub serwer bramy, który nie uczestniczy w ładowaniu przepływów pracy dla puli; uczestniczą jednak w decyzjach kworum. Nie jest to nigdy używane w normalnych okolicznościach i dlatego nie należy ich traktować.

Istnieją dwa typy członkostwa:

• Automatyczne
• Ręcznie

Podczas tworzenia puli zasobów jej członkostwo jest ustawione na ręczne i nie można jej ponownie skonfigurować do automatycznego. Po utworzeniu grupy zarządzania programu System Center — Operations Manager domyślnie tworzone są trzy pule zasobów z automatycznym członkostwem. W poniższej tabeli opisano te trzy pule zasobów.

Nazwa puli zasobów	opis
Pula zasobów wszystkich serwerów zarządzania	Wykonuje przepływy pracy dla obliczeń grup, dostępności, zestawień kondycji monitora rozproszonego i pielęgnacji bazy danych.
Pula zasobów powiadomień	Przepływy pracy usługi subskrypcji alertów są przeznaczone dla tej puli zasobów w celu obsługi powiadomień o alertach.
Pula zasobów przypisania usługi AD	Przepływy pracy integracji usługi AD są przeznaczone dla tej puli zasobów w celu obsługi automatycznego przypisywania agenta do serwerów zarządzania.

Ponieważ członkostwo w puli zasobów Wszystkie serwery zarządzania jest automatyczne, każdy zlecony serwer zarządzania jest automatycznie członkiem tej puli zasobów. W niektórych architekturach i zagadnieniach projektowych, takich jak te obejmujące geograficznie rozproszone operacje awaryjne, automatyczne przypisanie do puli zasobów Wszystkich serwerów zarządzania może nie być pożądane. W takich sytuacjach można zmienić przypisanie członkostwa z automatycznego na ręczne. W związku z tym serwery zarządzania należy dodać do puli zasobów Wszystkie serwery zarządzania za pomocą ręcznego przypisania.

Uwaga

Członkostwo w puli zasobów Wszystkie serwery zarządzania jest tylko do odczytu. Aby zmienić członkostwo z automatycznego na ręczne, zobacz Modyfikowanie członkostwa w puli.

Wraz z wprowadzeniem pul zasobów zaleca się, aby wszyscy członkowie łączyli się z siecią o małych opóźnieniach (mniej niż 10 ms). Pule zasobów nie powinny być wdrażane w wielu centrach danych ani w środowisku chmury hybrydowej, takiej jak Platforma Microsoft Azure.

Przykłady dostępności puli zasobów

W poniższych przykładach przedstawiono koncepcję dostępności puli zasobów na podstawie następujących konfiguracji, tylko z serwerami zarządzania lub tylko z serwerami bramy.

Pojedynczy serwer zarządzania

• Domyślny obserwator jest domyślnie włączony i nie zapewnia żadnych korzyści, ponieważ nie osiągnięto tylko dwóch elementów członkowskich i kworum.
• Brak wysokiej dostępności, ponieważ serwer zarządzania jest pojedynczym punktem awarii.

Dwa serwery zarządzania

• Domyślny obserwator jest domyślnie włączony.
• Pula ma wysoką dostępność, ponieważ istnieją trzy elementy członkowskie głosowania — dwa serwery zarządzania i domyślny obserwator.
• Jeśli wyłączysz domyślny obserwator, utracisz wysoką dostępność dla puli.

Trzy serwery zarządzania

• Domyślny obserwator jest domyślnie włączony.
• Pula ma wysoką dostępność, ponieważ istnieją cztery elementy członkowskie głosowania — trzy serwery zarządzania i domyślny obserwator.
• Domyślnie do obsługi kworum może być niedostępny tylko jeden serwer zarządzania. Jeśli dwa serwery zarządzania są niedostępne, masz dokładnie 50% głosujących elementów członkowskich, a pula zasobów nie działa już do zarządzania obciążeniami monitorowania.
• Domyślny obserwator nie zwiększa liczby serwerów zarządzania, które mogą być wyłączone, dlatego nie zwiększa dostępności puli.
• W tym scenariuszu można rozważyć usunięcie domyślnego obserwatora.

Cztery serwery zarządzania

• Domyślny obserwator jest domyślnie włączony.
• Pula ma wysoką dostępność, ponieważ istnieje pięć głosujących elementów członkowskich — cztery serwery zarządzania i domyślny obserwator.
• Domyślnie można mieć tylko dwa serwery zarządzania niedostępne do obsługi kworum. Jeśli trzy serwery zarządzania nie działają, masz mniej niż 50% głosujących elementów członkowskich, a pula zasobów nie działa już w celu zarządzania obciążeniami monitorowania.
• Domyślny obserwator w tym scenariuszu zapewnia znaczącą wartość, ponieważ zwiększa liczbę serwerów zarządzania, które mogą być wyłączone. Bez domyślnego obserwatora będziesz mieć tylko cztery elementy członkowskie kworum, co pozwala tylko na niedostępności jednego elementu członkowskiego.

Pięć serwerów zarządzania

• Domyślny obserwator jest domyślnie włączony.
• Pula ma wysoką dostępność, ponieważ istnieje sześć głosujących elementów członkowskich — pięć serwerów zarządzania i domyślny obserwator.
• Domyślnie można mieć tylko dwa serwery zarządzania niedostępne do obsługi kworum. Jeśli trzy serwery zarządzania są niedostępne, jest to dokładnie 50% głosujących elementów członkowskich, a pula zasobów nie działa już do zarządzania obciążeniami monitorowania.
• Domyślny obserwator nie zwiększa liczby serwerów zarządzania, które mogą być wyłączone, dlatego nie zwiększa dostępności puli.
• W tym scenariuszu można rozważyć usunięcie domyślnego obserwatora.

Po osiągnięciu co najmniej trzech serwerów zarządzania w puli zasobów, w której istnieje nieparzysta liczba elementów członkowskich w puli, możesz rozważyć usunięcie domyślnego obserwatora jako członka. Jeśli osiągniesz pięć serwerów zarządzania, istnieje potencjał, aby operacyjna baza danych napotkała znaczne obciążenie, co może spowodować wygenerowanie wystarczającego opóźnienia, aby wpłynąć na obliczenia puli zasobów.

Dzięki temu, jak domyślny obserwator odgrywa rolę, każdy serwer zarządzania w puli wykonuje zapytania o własną lokalną usługę ZESTAWU SDK, która umożliwia wykonywanie zapytań względem tabeli w operacyjnej bazie danych dla domyślnego obserwatora. Jeśli usługa lub baza danych zestawu SDK jest obciążona, wystąpi opóźnienie, które w przeciwnym razie nie istnieje.

Pojedynczy serwer bramy

• Domyślny obserwator jest domyślnie włączony.
• Brak wysokiej dostępności, ponieważ serwer bramy jest pojedynczym punktem awarii.
• Domyślny obserwator nie powinien być używany w tym miejscu, ponieważ serwery bramy nie mają lokalnej usługi ZESTAWU SDK i dlatego nie mogą wykonywać zapytań względem operacyjnej bazy danych.

Dwa serwery bramy

• Domyślny obserwator jest domyślnie włączony.
• Brak wysokiej dostępności, ponieważ istnieją tylko dwa elementy członkowskie puli, a domyślny obserwator nie jest uczestnikiem, ponieważ serwery bramy nie komunikują się bezpośrednio z operacyjną bazą danych. Do obsługi kworum puli wymagane są trzy serwery bramy.

Trzy serwery bramy

• Domyślny obserwator jest domyślnie włączony.
• Pula ma wysoką dostępność, ponieważ istnieją trzy elementy członkowskie głosowania — trzy serwery bramy.
• Domyślnie do obsługi kworum może być niedostępny tylko jeden serwer bramy. Jeśli dwa serwery bramy nie działają, jest to mniej niż 50% głosujących elementów członkowskich, a pula zasobów nie działa już do zarządzania obciążeniami monitorowania.
• Domyślny obserwator nie powinien być używany w tym miejscu, ponieważ serwery bramy nie mają lokalnej usługi ZESTAWU SDK i dlatego nie mogą wykonywać zapytań względem operacyjnej bazy danych.

Scenariusze monitorowania obsługujące pule zasobów

Następujące przepływy pracy są hostowane przez pule zasobów w programie Operations Manager:

• Zarządzanie urządzeniami sieciowymi
• Zarządzanie agentami systemu UNIX/Linux
• Monitorowanie adresów URL aplikacji internetowej

Uwaga

Agenci systemu Windows nie zgłaszają raportów do pul zasobów.

Monitorowanie sieci w programie Operations Manager wymaga własnej oddzielnej dedykowanej puli zasobów. Dzieje się tak, ponieważ przepływy pracy monitorowania sieci są uruchamiane na serwerach zarządzania (w module SNMP), a nie na agentach. Powoduje to duże obciążenie na serwerach zarządzania po włączeniu monitorowania portów sieciowych, zwłaszcza w przypadku wybrania większości aktywnych portów dostępnych na urządzeniu. W związku z tym w celu uzyskania lepszej wydajności zalecamy używanie dedykowanych serwerów zarządzania w dedykowanych pulach zasobów na potrzeby monitorowania sieci. Ponadto serwery zarządzania, które są członkami tej puli, powinny zostać usunięte z pul Wszystkie serwery zarządzania, powiadomienia i przypisania usługi AD.

Monitorowanie systemu Linux/UNIX w programie Operations Manager można przypisać do dedykowanej puli zasobów, jeśli jest to konieczne, aby umożliwić monitorowanie wysokiej dostępności i zarządzanie agentami, ale nie jest wymagane. Program Operations Manager używa certyfikatów do uwierzytelniania dostępu do komputerów, które zarządza. Gdy Kreator odnajdywania wdraża agenta, pobiera certyfikat z agenta, podpisuje certyfikat, wdraża certyfikat z powrotem do agenta, a następnie ponownie uruchamia agenta. Aby zapewnić wysoką dostępność, każdy serwer zarządzania w puli zasobów musi mieć wszystkie certyfikaty główne używane do podpisywania certyfikatów wdrożonych w agentach na komputerach z systemami UNIX i Linux. W przeciwnym razie, jeśli serwer zarządzania stanie się niedostępny, inne serwery zarządzania nie będą mogły ufać certyfikatom podpisanym przez serwer, który uległ awarii.

Następne kroki

Aby dowiedzieć się, jak tworzyć pule zasobów i zarządzać nimi, zobacz Jak zarządzać pulami zasobów.