Udostępnij za pośrednictwem


Skalowanie klastrów autonomicznych usługi Service Fabric

Klaster usługi Service Fabric to połączony z siecią zestaw maszyn wirtualnych lub fizycznych, do których są wdrażane i zarządzane mikrousługi. Maszyna lub maszyna wirtualna, która jest częścią klastra, jest nazywana węzłem. Klastry mogą zawierać potencjalnie tysiące węzłów. Po utworzeniu klastra usługi Service Fabric można skalować klaster w poziomie (zmienić liczbę węzłów) lub w pionie (zmienić zasoby węzłów). Klaster można skalować w dowolnym momencie, nawet gdy obciążenia są uruchomione w klastrze. W miarę skalowania klastra aplikacje są również automatycznie skalowane.

Dlaczego warto skalować klaster? Zapotrzebowanie na aplikację zmienia się w czasie. Może być konieczne zwiększenie zasobów klastra w celu spełnienia zwiększonego obciążenia aplikacji lub ruchu sieciowego lub zmniejszenia zasobów klastra, gdy zapotrzebowanie spadnie.

Skalowanie w poziomie lub w poziomie

Zmienia liczbę węzłów w klastrze. Po dołączeniu nowych węzłów do klastra klaster Resource Manager przenosi do nich usługi, co zmniejsza obciążenie istniejących węzłów. Można również zmniejszyć liczbę węzłów, jeśli zasoby klastra nie są używane wydajnie. Gdy węzły opuszczają klaster, usługi przenoszą się z tych węzłów i zwiększają obciążenie pozostałych węzłów. Zmniejszenie liczby węzłów w klastrze uruchomionym na platformie Azure może zaoszczędzić pieniądze, ponieważ płacisz za liczbę używanych maszyn wirtualnych, a nie obciążenie tych maszyn wirtualnych.

  • Zalety: Nieskończona skala, teoretycznie. Jeśli aplikacja została zaprojektowana pod kątem skalowalności, możesz włączyć nieograniczony wzrost, dodając więcej węzłów. Narzędzia w środowiskach w chmurze ułatwiają dodawanie lub usuwanie węzłów, dzięki czemu można łatwo dostosować pojemność i płacisz tylko za używane zasoby.
  • Wady: aplikacje muszą być zaprojektowane pod kątem skalowalności. Bazy danych aplikacji i trwałość mogą wymagać również dodatkowej pracy architektonicznej w celu skalowania. Niezawodne kolekcje w usługach stanowych usługi Service Fabric ułatwiają jednak skalowanie danych aplikacji.

Klastry autonomiczne umożliwiają wdrażanie klastra usługi Service Fabric lokalnie lub u wybranego dostawcy usług w chmurze. Typy węzłów składają się z maszyn fizycznych lub maszyn wirtualnych w zależności od wdrożenia. W porównaniu z klastrami działającymi na platformie Azure proces skalowania klastra autonomicznego jest nieco bardziej zaangażowany. Należy ręcznie zmienić liczbę węzłów w klastrze, a następnie uruchomić uaktualnienie konfiguracji klastra.

Usunięcie węzłów może zainicjować wiele uaktualnień. Niektóre węzły są oznaczone tagiem IsSeedNode=”true” i można je zidentyfikować, wysyłając zapytanie do manifestu klastra przy użyciu polecenia Get-ServiceFabricClusterManifest. Usunięcie takich węzłów może potrwać dłużej niż inne, ponieważ węzły początkowe będą musiały zostać przeniesione w takich scenariuszach. Klaster musi obsługiwać co najmniej trzy węzły typu węzła podstawowego.

Ostrzeżenie

Zalecamy, aby nie zmniejszyć liczby węzłów poniżej rozmiaru klastra warstwy niezawodności klastra dla klastra. Będzie to zakłócać możliwość replikacji usług systemowych usługi Service Fabric w klastrze i będzie destabilizować lub ewentualnie zniszczyć klaster.

Podczas skalowania klastra autonomicznego należy pamiętać o następujących wytycznych:

  • Zamiana węzłów podstawowych powinna być wykonywana po jednym węźle, zamiast usuwać, a następnie dodawać w partiach.
  • Przed usunięciem typu węzła sprawdź, czy istnieją jakieś węzły odwołujące się do typu węzła. Usuń te węzły przed usunięciem odpowiedniego typu węzła. Po usunięciu wszystkich odpowiednich węzłów można usunąć element NodeType z konfiguracji klastra i rozpocząć uaktualnienie konfiguracji przy użyciu polecenia Start-ServiceFabricClusterConfigurationUpgrade.

Aby uzyskać więcej informacji, zobacz skalowanie klastra autonomicznego.

Skalowanie w górę i w dół lub skalowanie w pionie

Zmienia zasoby (procesor CPU, pamięć lub magazyn) węzłów w klastrze.

  • Zalety: architektura oprogramowania i aplikacji pozostaje taka sama.
  • Wady: skala skończona, ponieważ istnieje limit liczby zasobów, które można zwiększyć w poszczególnych węzłach. Przestój, ponieważ konieczne będzie przełączenie maszyn fizycznych lub wirtualnych w tryb offline w celu dodania lub usunięcia zasobów.

Następne kroki