Zagadnienia dotyczące projektowania puli zasobów

2025-03-22

Pula zasobów to logiczne grupowanie serwerów zarządzających i/lub serwerów bramy, które są używane do dystrybucji pracy między sobą i przejmowania pracy od członka, który uległ awarii. 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 trzech członków musi być w puli, aby utrzymać kworum, które musi stanowić więcej niż 50% członków kworum głosujących w puli, aby utrzymać dostępność puli. Jeśli masz tylko dwóch członków grupy i jeden jest niedostępny, stracisz kworum.

Dla każdej puli zasobów utworzonej w konsoli Operacje, baza danych programu Operations Manager, która jest nazywana domyślnym obserwatorem, zawsze ma przyznany głos, nawet jeśli liczba członków w puli jest parzysta, aby umożliwić 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, ponieważ wymaga wdrożenia co najmniej dwóch serwerów zarządzania, aby zachować wysoką dostępność 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; jednak uczestniczy w decyzjach kworum. Nigdy nie jest używane w normalnych okolicznościach i dlatego nie należy tego rozważać.

Istnieją dwa typy członkostwa:

Automatyczne
Podręcznik

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, analizy kondycji monitoringu rozproszonego i oczyszczania bazy danych.
Pula zasobów powiadomień	Przepływy pracy usługi subskrypcji alertów są ukierunkowane na tę pulę zasobów, aby zapewnić obsługę powiadomień o alertach.
Pula zasobów przypisywania AD	Przepływy pracy integracji usługi AD są przeznaczone dla tej puli zasobów w celu wspierania automatycznego przypisywania agenta do serwerów zarządzania.

Ponieważ członkostwo w zasobniku "Wszystkie Serwery Zarządzania" jest automatyczne, każdy nowo uruchomiony serwer zarządzania automatycznie staje się 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 puli zasobów dla Wszystkich Serwerów Zarządzania jest w trybie tylko do odczytu. Aby zmienić członkostwo w puli 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

Poniższe przykłady demonstrują dostępność 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 aktywowany automatycznie i nie zapewnia żadnych korzyści, ponieważ jest tylko dwóch członków i nie osiągnięto 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ą trzej członkowie głosujący — dwa serwery zarządzania i domyślny obserwator.
Jeśli wyłączysz domyślnego obserwatora, utracisz wysoką dostępność dla zasobu.

Trzy serwery zarządzania

Domyślny obserwator jest domyślnie włączony.
Pula ma wysoką dostępność, ponieważ są czterej członkowie głosujący — 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 członków, a zasoby nie mogą już zarządzać obciążeniami monitorowania.
Domyślny obserwator nie zwiększa liczby serwerów zarządzania, które mogą być wyłączone, dlatego nie poprawia 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ęciu głosujących członków — 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% członków z prawem głosu, a pula zasobów przestaje działać do zarządzania obciążeniami związanymi z monitorowaniem.
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 czterech członków kworum, co pozwala na niedostępność tylko jednego członka.

Pięć serwerów zarządzania

Domyślny obserwator jest domyślnie włączony.
Duża dostępność jest zapewniona dla puli, ponieważ istnieje sześciu głosujących członków — 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, stanowi to dokładnie 50% głosujących członków, a pula zasobów przestaje funkcjonować 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 poprawia 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, gdzie liczba członków jest nieparzysta, możesz rozważyć usunięcie domyślnego obserwatora z listy członków. 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 roli, jaką pełni domyślny obserwator, każdy serwer zarządzania w puli wykonuje zapytania do własnej lokalnej usługi SDK, co 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.

Serwer pojedynczej 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 SDK i dlatego nie mogą wykonywać zapytań w odniesieniu do bazy danych operacyjnej.

Dwa serwery bramy

Domyślny obserwator jest domyślnie włączony.
Brak wysokiej dostępności, ponieważ są tylko dwóch członków puli, a domyślny obserwator nie jest uczestnikiem, ponieważ serwery bramy nie komunikują się bezpośrednio z bazą danych operacyjnych. 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 serwery bramy jako członkowie głosujący.
Domyślnie, aby zachować kworum, tylko jeden serwer bramy może być niedostępny. Jeśli dwa serwery bramy nie działają, jest to mniej niż 50% głosujących członków, a pula zasobów nie działa już w zarządzaniu obciążeniami związanymi z monitorowaniem.
Domyślny obserwator nie powinien być używany w tym miejscu, ponieważ serwery bramy nie mają lokalnej usługi SDK i dlatego nie mogą wykonywać zapytań w odniesieniu do bazy danych operacyjnej.

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 są połączeni z pulami 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 puli Wszystkie serwery zarządzania, puli Powiadomienia oraz puli 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 Discovery dokonuje wdrożenia agenta, pobiera certyfikat z agenta, podpisuje certyfikat, umożliwia ponowne wdrożenie certyfikatu 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.