Udostępnij za pośrednictwem

Omówienie architektury usługi Resource Manager klastra

  • Artykuł

Menedżer zasobów klastra usługi Service Fabric to centralna usługa, która działa w klastrze. Zarządza żądanym stanem usług w klastrze, szczególnie w odniesieniu do zużycia zasobów i wszelkich reguł umieszczania.

Aby zarządzać zasobami w klastrze, menedżer zasobów klastra usługi Service Fabric musi zawierać kilka informacji:

  • Które usługi obecnie istnieją
  • Bieżące (lub domyślne) użycie zasobów poszczególnych usług
  • Pozostała pojemność klastra
  • Pojemność węzłów w klastrze
  • Ilość zasobów zużywanych w każdym węźle

Użycie zasobów danej usługi może ulec zmianie w czasie, a usługi zwykle dbają o więcej niż jeden typ zasobu. W różnych usługach mogą być mierzone zarówno rzeczywiste zasoby fizyczne, jak i fizyczne. Usługi mogą śledzić metryki fizyczne, takie jak zużycie pamięci i dysku. Częściej usługi mogą dbać o metryki logiczne — takie elementy jak "WorkQueueDepth" lub "TotalRequests". Zarówno metryki logiczne, jak i fizyczne mogą być używane w tym samym klastrze. Metryki można udostępniać w wielu usługach lub być specyficzne dla określonej usługi.

Inne uwagi

Właściciele i operatorzy klastra mogą różnić się od autorów usługi i aplikacji lub co najmniej są tymi samymi osobami noszącymi różne kapelusze. Podczas tworzenia aplikacji wiesz kilka rzeczy o tym, czego wymaga. Masz oszacowanie zasobów, które będą używane i jak należy wdrożyć różne usługi. Na przykład warstwa internetowa musi działać w węzłach uwidocznionych w Internecie, a usługi bazy danych nie powinny. W innym przykładzie usługi internetowe są prawdopodobnie ograniczone przez procesor CPU i sieć, podczas gdy usługi warstwy danych dbają bardziej o zużycie pamięci i dysku. Jednak osoba obsługująca zdarzenie na żywo dla tej usługi w środowisku produkcyjnym lub zarządza uaktualnieniem do usługi ma inne zadanie do wykonania i wymaga różnych narzędzi.

Zarówno klaster, jak i usługi są dynamiczne:

  • Liczba węzłów w klastrze może rosnąć i zmniejszać
  • Węzły o różnych rozmiarach i typach mogą pochodzić i iść
  • Usługi można tworzyć, usuwać i zmieniać ich żądane alokacje zasobów i reguły umieszczania
  • Uaktualnienia lub inne operacje zarządzania mogą być wprowadzane przez klaster na poziomie infrastruktury
  • Błędy mogą wystąpić w dowolnym momencie.

Składniki i przepływ danych menedżera zasobów klastra

Menedżer zasobów klastra musi śledzić wymagania każdej usługi i zużycie zasobów przez każdy obiekt usługi w ramach tych usług. Menedżer zasobów klastra ma dwie koncepcyjne części: agentów uruchamianych w każdym węźle i usługi odpornej na błędy. Agenci w każdym węźle śledzą raporty ładowania z usług, agregują je i okresowo zgłaszają. Usługa Cluster Resource Manager agreguje wszystkie informacje od agentów lokalnych i reaguje na podstawie bieżącej konfiguracji.

Przyjrzyjmy się następującego diagramowi:

Diagram przedstawiający usługę Menedżer zasobów klastra agreguje wszystkie informacje od agentów lokalnych i reaguje na podstawie bieżącej konfiguracji.

W czasie wykonywania może wystąpić wiele zmian. Załóżmy na przykład, że ilość zasobów zużywanych przez niektóre usługi, niektóre usługi kończą się niepowodzeniem, a niektóre węzły łączą się i opuszczają klaster. Wszystkie zmiany w węźle są agregowane i okresowo wysyłane do usługi Menedżer zasobów klastra (1,2), gdzie są ponownie agregowane, analizowane i przechowywane. Co kilka sekund usługa analizuje zmiany i określa, czy jakiekolwiek działania są niezbędne (3). Na przykład można zauważyć, że niektóre puste węzły zostały dodane do klastra. W związku z tym decyduje się przenieść niektóre usługi do tych węzłów. Menedżer zasobów klastra może również zauważyć, że określony węzeł jest przeciążony lub że niektóre usługi uległy awarii lub zostały usunięte, zwalniając zasoby w innym miejscu.

Przyjrzyjmy się poniższego diagramu i zobaczmy, co się stanie dalej. Załóżmy, że menedżer zasobów klastra określa, że zmiany są niezbędne. Koordynuje z innymi usługami systemowymi (w szczególności Menedżer trybu failover), aby wprowadzić niezbędne zmiany. Następnie niezbędne polecenia są wysyłane do odpowiednich węzłów (4). Załóżmy na przykład, że usługa Resource Manager zauważyła, że węzeł Node5 został przeciążony i dlatego postanowił przenieść usługę B z węzła Node5 do node4. Na końcu rekonfiguracji (5) klaster wygląda następująco:

Architektura usługi Resource Balancer

Następne kroki