Udostępnij za pośrednictwem

Skalowanie klastrów usługi Azure Service Fabric

  • Artykuł

Klaster usługi Service Fabric jest połączonym z siecią zestawem maszyn wirtualnych lub fizycznych, w którym wdraża się mikrousługi i nimi zarządza. 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 pionowo (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, gdy zapotrzebowanie spadnie.

Skalowanie w poziomie i w poziomie lub skalowanie w poziomie

Zmienia liczbę węzłów w klastrze. Po dołączeniu nowych węzłów do klastra menedżer zasobów 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 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 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 mieć zawsze pięć lub więcej węzłów.
  • Typy węzłów innych niż podstawowe z uruchomionymi stanowymi obciążeniami produkcyjnymi powinny zawsze mieć co najmniej pięć 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 mieć zawsze pięć lub więcej węzłów.
  • Nie usuwaj losowych wystąpień maszyn wirtualnych/węzłów z typu węzła, zawsze używaj funkcji skalowania zestawu skalowania maszyn wirtualnych. Usunięcie losowych wystąpień maszyn wirtualnych może niekorzystnie wpłynąć na zdolność systemów do prawidłowego równoważenia obciążenia.
  • Jeśli używasz reguł skalowania automatycznego, ustaw reguły, 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 skalowania automatycznego 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ą one 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 nieprzewidywalnym czasie, takie podejście może nie być dobrym rozwiązaniem.
  • Gdy reguły skalowania automatycznego usuwają wystąpienie z zestawu skalowania maszyn wirtualnych, nie usuwają automatycznie wiedzy o tym węźle z 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. Pojedyncza (lub usługa) musiałaby okresowo czyścić usunięty stan 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 skalowania automatycznego 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ść skalowania programowego oferują zaawansowane alternatywy.

Istnieją interfejsy API platformy Azure, które umożliwiają aplikacjom programowe 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 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 przypadku 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 kontrola wiąże się z kompromisem złożoności kodu. Użycie tego podejścia 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. Płynna biblioteka obliczeniowa 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 go skalować. Zarówno IAzure , jak i FabricClient może łączyć się ze skojarzonymi zasobami platformy Azure zdalnie, dzięki czemu usługa skalowania 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 ilości 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.

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 skalować go w dół niż ta 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 wystąpienia oryginalnego typu węzła podstawowego pojedynczo, aby usługi systemowe migrowały 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 ma to zastosowanie) ze starego klastra. Nie trzeba przywracać żadnego stanu usługi systemu. Są one tworzone ponownie podczas wdrażania aplikacji w nowym klastrze. Jeśli tylko uruchomiono aplikacje bezstanowe w klastrze, wystarczy wdrożyć aplikacje w nowym klastrze, ale nie masz nic do przywrócenia.

Następne kroki