Udostępnij za pośrednictwem

Skalowanie klastrów usługi Azure Service Fabric

  • Artykuł

Klaster usługi Service Fabric to połączony z siecią zestaw maszyn wirtualnych lub fizycznych, w którym są wdrażane mikrousługi i zarządzane. 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 wtedy, 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 w przypadku spadku zapotrzebowania.

Skalowanie do i w poziomie lub skalowanie w poziomie

Zmienia liczbę węzłów w klastrze. Po dołączeniu nowych węzłów do klastra Resource Manager klastra 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 są przenoszone z tych węzłów i zwiększa się 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 chmury ułatwiają dodawanie lub usuwanie węzłów, dzięki czemu można łatwo dostosować pojemność i płacić tylko za używane zasoby.
  • Wady: aplikacje muszą być zaprojektowane pod kątem skalowalności. Bazy danych aplikacji i trwałość mogą również wymagać dodatkowej pracy architektonicznej w celu skalowania. Niezawodne kolekcje w usługach stanowych usługi Service Fabric ułatwiają jednak skalowanie danych aplikacji.

Zestawy skalowania maszyn wirtualnych to zasób obliczeniowy platformy Azure, którego można użyć do wdrożenia kolekcji maszyn wirtualnych i zarządzania nią jako zestawu. Każdy typ węzła zdefiniowany w klastrze platformy Azure jest konfigurowany jako oddzielny zestaw skalowania. Każdy typ węzła można następnie skalować w poziomie lub w poziomie niezależnie, mieć otwarte różne zestawy portów i mogą mieć różne metryki pojemności.

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

  • podstawowe typy węzłów z uruchomionymi obciążeniami produkcyjnymi powinny zawsze mieć co najmniej pięć węzłów.
  • Typy węzłów innych niż podstawowe z uruchomionymi stanowymi obciążeniami produkcyjnymi powinny mieć zawsze pięć lub więcej węzłów.
  • Typy węzłów innych niż podstawowe z uruchomionymi bezstanowymi obciążeniami produkcyjnymi powinny zawsze mieć co najmniej dwa węzły.
  • Każdy typ węzła poziomu trwałości Gold lub Silver powinien zawsze mieć pięć lub więcej węzłów.
  • Nie usuwaj losowych wystąpień/węzłów maszyn wirtualnych z typu węzła, zawsze używaj funkcji skalowania zestawów skalowania maszyn wirtualnych. Usunięcie losowych wystąpień maszyn wirtualnych może negatywnie wpłynąć na zdolność systemów do prawidłowego równoważenia obciążenia.
  • W przypadku korzystania z reguł autoskalowania ustaw reguły tak, aby skalowanie w poziomie (usuwanie wystąpień maszyn wirtualnych) odbywało się w jednym węźle naraz. Skalowanie w dół więcej niż jednego wystąpienia w danym momencie nie jest bezpieczne.

Ponieważ typy węzłów usługi Service Fabric w klastrze składają się z zestawów skalowania maszyn wirtualnych w zapleczu, można skonfigurować reguły automatycznego skalowania lub ręcznie skalować każdy typ węzła/zestaw skalowania maszyn wirtualnych.

Skalowanie programowe

W wielu scenariuszach skalowanie klastra ręcznie lub przy użyciu reguł skalowania automatycznego jest dobrym rozwiązaniem. Jednak w przypadku bardziej zaawansowanych scenariuszy mogą nie być odpowiednie. Potencjalne wady tych podejść obejmują:

  • Ręczne skalowanie wymaga zalogowania się i jawnego żądania operacji skalowania. Jeśli operacje skalowania są wymagane często lub w nieprzewidywalnych czasach, takie podejście może nie być dobrym rozwiązaniem.
  • Gdy reguły automatycznego skalowania usuwają wystąpienie z zestawu skalowania maszyn wirtualnych, nie usuwają automatycznie wiedzy o tym węźle ze skojarzonego klastra usługi Service Fabric, chyba że typ węzła ma poziom trwałości Silver lub Gold. Ponieważ reguły automatycznego skalowania działają na poziomie zestawu skalowania (a nie na poziomie usługi Service Fabric), reguły automatycznego skalowania mogą usuwać węzły usługi Service Fabric bez bezpiecznego zamykania. To niegrzeczne usunięcie węzła spowoduje pozostawienie stanu węzła usługi Service Fabric "ghost" po operacjach skalowania w poziomie. Użytkownik indywidualny (lub usługa) musi okresowo czyścić stan usuniętego węzła w klastrze usługi Service Fabric.
  • Typ węzła z poziomem trwałości Gold lub Silver automatycznie czyści usunięte węzły, więc nie jest potrzebne żadne dodatkowe czyszczenie.
  • Chociaż istnieje wiele metryk obsługiwanych przez reguły automatycznego skalowania, nadal jest to ograniczony zestaw. Jeśli twój scenariusz wywołuje skalowanie na podstawie niektórych metryk, które nie zostały uwzględnione w tym zestawie, reguły automatycznego skalowania mogą nie być dobrym rozwiązaniem.

Sposób podejścia do skalowania usługi Service Fabric zależy od scenariusza. Jeśli skalowanie jest nietypowe, prawdopodobnie wystarczy możliwość ręcznego dodawania lub usuwania węzłów. W przypadku bardziej złożonych scenariuszy reguły automatycznego skalowania i zestawy SDK ujawniające możliwość programowego skalowania oferują zaawansowane alternatywy.

Istnieją interfejsy API platformy Azure, które umożliwiają aplikacjom programową pracę z zestawami skalowania maszyn wirtualnych i klastrami usługi Service Fabric. Jeśli istniejące opcje skalowania automatycznego nie działają w danym scenariuszu, te interfejsy API umożliwiają zaimplementowanie niestandardowej logiki skalowania.

Jedną z metod implementowania tej funkcji automatycznego skalowania "w domu" jest dodanie nowej usługi bezstanowej do aplikacji usługi Service Fabric w celu zarządzania operacjami skalowania. Tworzenie własnej usługi skalowania zapewnia najwyższy stopień kontroli i możliwości dostosowywania w zakresie zachowania skalowania aplikacji. Może to być przydatne w scenariuszach wymagających dokładnej kontroli nad tym, kiedy lub jak aplikacja jest skalowana w poziomie lub w poziomie. Jednak ta kontrolka wiąże się z kompromisem złożoności kodu. Użycie tej metody oznacza, że musisz posiadać kod skalowania, który nie jest trywialny. W ramach metody usługi RunAsync zestaw wyzwalaczy może określić, czy skalowanie jest wymagane (w tym sprawdzanie parametrów, takich jak maksymalny rozmiar klastra i skalowanie chłodni).

Interfejs API używany do interakcji zestawu skalowania maszyn wirtualnych (zarówno w celu sprawdzenia bieżącej liczby wystąpień maszyn wirtualnych, jak i modyfikowania go) jest płynną biblioteką obliczeniową usługi Azure Management. Biblioteka fluent compute udostępnia łatwy w użyciu interfejs API do interakcji z zestawami skalowania maszyn wirtualnych. Aby korzystać z samego klastra usługi Service Fabric, użyj elementu System.Fabric.FabricClient.

Kod skalowania nie musi jednak działać jako usługa w klastrze, aby można było skalować. Zarówno IAzure , jak i FabricClient może łączyć się ze skojarzonymi zasobami platformy Azure zdalnie, dzięki czemu skalowanie usługi może być aplikacją konsolową lub usługą systemu Windows działającą spoza aplikacji usługi Service Fabric.

Na podstawie tych ograniczeń możesz zaimplementować bardziej dostosowane modele automatycznego skalowania.

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 do trybu offline w celu dodania lub usunięcia zasobów.

Zestawy skalowania maszyn wirtualnych to zasób obliczeniowy platformy Azure, którego można użyć do wdrożenia kolekcji maszyn wirtualnych i zarządzania nią jako zestawu. Każdy typ węzła zdefiniowany w klastrze platformy Azure jest konfigurowany jako oddzielny zestaw skalowania. Każdy typ węzła może być zarządzany oddzielnie. Skalowanie typu węzła w górę lub w dół obejmuje dodanie nowego typu węzła (ze zaktualizowaną jednostkę SKU maszyny wirtualnej) i usunięcie starego typu węzła.

Podczas skalowania klastra platformy Azure należy pamiętać o następujących wskazówkach:

  • W przypadku skalowania w dół typu węzła podstawowego nigdy nie należy go skalować w dół niż pozwala na to warstwa niezawodności .

Proces skalowania typu węzła w górę lub w dół różni się w zależności od tego, czy jest to typ węzła innego niż podstawowy, czy podstawowy.

Skalowanie typów węzłów innych niż podstawowe

Utwórz nowy typ węzła z potrzebnymi zasobami. Zaktualizuj ograniczenia umieszczania uruchomionych usług, aby uwzględnić nowy typ węzła. Stopniowo (pojedynczo) zmniejsz liczbę wystąpień starego typu węzła do zera, aby niezawodność klastra nie miała wpływu. Usługi będą stopniowo migrowane do nowego typu węzła, ponieważ stary typ węzła zostanie zlikwidowany.

Skalowanie typu węzła podstawowego

Wdróż nowy typ węzła podstawowego ze zaktualizowaną jednostkę SKU maszyny wirtualnej, a następnie wyłącz oryginalne wystąpienia typu węzła podstawowego pojedynczo, aby usługi systemowe były migrowane do nowego zestawu skalowania. Sprawdź, czy klaster i nowe węzły są w dobrej kondycji, a następnie usuń oryginalny zestaw skalowania i stan węzła dla usuniętych węzłów.

Jeśli nie jest to możliwe, możesz utworzyć nowy klaster i przywrócić stan aplikacji (jeśli dotyczy) ze starego klastra. Nie trzeba przywracać żadnego stanu usługi systemowej. Są one tworzone ponownie podczas wdrażania aplikacji w nowym klastrze. Jeśli właśnie uruchomiono aplikacje bezstanowe w klastrze, wystarczy wdrożyć aplikacje w nowym klastrze, nie masz nic do przywrócenia.

Następne kroki