Repliki i wystąpienia
Ten artykuł zawiera omówienie cyklu życia replik usług stanowych i wystąpień usług bezstanowych.
Wystąpienia usług bezstanowych
Wystąpienie usługi bezstanowej to kopia logiki usługi uruchomionej w jednym z węzłów klastra. Wystąpienie w partycji jest unikatowo identyfikowane przez jego identyfikator InstanceId. Cykl życia wystąpienia jest modelowany na poniższym diagramie:
InBuild (IB)
Gdy menedżer zasobów klastra określi położenie wystąpienia, wchodzi w ten stan cyklu życia. Wystąpienie jest uruchamiane w węźle. Zostanie uruchomiony host aplikacji, wystąpienie zostanie utworzone, a następnie otwarte. Po zakończeniu uruchamiania wystąpienie przechodzi do stanu gotowego.
Jeśli host lub węzeł aplikacji dla tego wystąpienia ulegnie awarii, przechodzi do stanu porzuconego.
Gotowe (RD)
W stanie gotowości wystąpienie jest uruchomione w węźle. Jeśli to wystąpienie jest niezawodną usługą, wywołano metodę RunAsync .
Jeśli host lub węzeł aplikacji dla tego wystąpienia ulegnie awarii, przechodzi do stanu porzuconego.
Zamykanie (CL)
W stanie zamknięcia usługa Azure Service Fabric jest w trakcie zamykania wystąpienia w tym węźle. To zamknięcie może być spowodowane wieloma przyczynami — na przykład uaktualnienie aplikacji, równoważenie obciążenia lub usunięcie usługi. Po zakończeniu zamykania przechodzi do stanu porzuconego.
Porzucone (DD)
W stanie porzuconym wystąpienie nie jest już uruchomione w węźle. W tym momencie usługa Service Fabric przechowuje metadane dotyczące tego wystąpienia, które również zostaną usunięte.
Uwaga
Istnieje możliwość przejścia z dowolnego stanu do stanu porzuconego przy użyciu opcji ForceRemove w systemie Remove-ServiceFabricReplica.
Repliki usług stanowych
Replika usługi stanowej to kopia logiki usługi uruchomionej w jednym z węzłów klastra. Ponadto replika utrzymuje kopię stanu tej usługi. Dwa powiązane pojęcia opisują cykl życia i zachowanie replik stanowych:
- Cykl życia repliki
- Rola repliki
W poniższej dyskusji opisano utrwalone usługi stanowe. W przypadku usług stanowych nietrwałych (lub w pamięci) stany w dół i porzucone są równoważne.
InBuild (IB)
Replika InBuild to replika utworzona lub przygotowana do dołączania zestawu replik. W zależności od roli repliki IB ma różne semantyki.
Jeśli host aplikacji lub węzeł repliki inbuild ulegnie awarii, przechodzi do stanu w dół.
Repliki podstawowe w programie InBuild: Podstawowy program InBuild to pierwsze repliki partycji. Ta replika zwykle występuje podczas tworzenia partycji. Repliki podstawowe w programie InBuild również występują, gdy wszystkie repliki ponownego uruchomienia partycji lub zostaną porzucone.
Repliki IdleSecondary InBuild: są to nowe repliki, które są tworzone przez menedżera zasobów klastra lub istniejące repliki, które spadły i muszą zostać dodane z powrotem do zestawu. Te repliki są rozmieszczane lub kompilowane przez element podstawowy, zanim będą mogły dołączyć zestaw replik jako ActiveSecondary i uczestniczyć w potwierdzaniu kworum operacji.
Repliki ActiveSecondary InBuild: ten stan jest obserwowany w niektórych zapytaniach. Jest to optymalizacja, w której zestaw replik nie zmienia się, ale należy skompilować replikę. Sama replika jest zgodna z normalnymi przejściami maszyny stanu (zgodnie z opisem w sekcji dotyczącej ról repliki).
Gotowe (RD)
Gotowa replika to replika uczestnicząca w replikacji i potwierdzaniu kworum operacji. Stan gotowości ma zastosowanie do replik podstawowych i aktywnych pomocniczych.
Jeśli host aplikacji lub węzeł gotowej repliki ulegnie awarii, przechodzi do stanu w dół.
Zamykanie (CL)
Replika wprowadza stan zamknięcia w następujących scenariuszach:
Zamknięcie kodu repliki: może być konieczne zamknięcie uruchomionego kodu dla repliki. To zamknięcie może być z wielu powodów. Na przykład może się to zdarzyć z powodu uaktualnienia aplikacji, sieci szkieletowej lub infrastruktury albo z powodu błędu zgłoszonego przez replikę. Po zakończeniu zamykania repliki replika przechodzi do stanu w dół. Utrwalonego stanu skojarzonego z tą repliką, która jest przechowywana na dysku, nie jest czyszczona.
Usunięcie repliki z klastra: usługa Service Fabric może wymagać usunięcia stanu utrwalonego i zamknięcia uruchomionego kodu dla repliki. To zamknięcie może być z wielu powodów, na przykład równoważenia obciążenia.
Porzucone (DD)
W stanie porzuconym wystąpienie nie jest już uruchomione w węźle. Nie ma również stanu pozostawionego w węźle. W tym momencie usługa Service Fabric przechowuje metadane dotyczące tego wystąpienia, które również zostaną usunięte.
W dół (D)
W stanie w dół kod repliki nie jest uruchomiony, ale stan utrwalone dla tej repliki istnieje w tym węźle. Replika może być wyłączona z wielu powodów — na przykład węzeł jest wyłączony, awaria w kodzie repliki, uaktualnienie aplikacji lub błędy repliki.
Replika w dół jest otwierana przez usługę Service Fabric zgodnie z wymaganiami, na przykład po zakończeniu uaktualniania w węźle.
Rola repliki nie jest odpowiednia w stanie wyłączonym.
Otwieranie (OP)
Replika w dół przechodzi w stan otwarcia, gdy usługa Service Fabric musi ponownie przywrócić replikę. Na przykład ten stan może być następujący po zakończeniu uaktualniania kodu dla aplikacji w węźle.
Jeśli host aplikacji lub węzeł otwierającej repliki ulegnie awarii, przechodzi do stanu w dół.
Rola repliki nie jest odpowiednia w stanie otwierania.
Wstrzymanie (SB)
Replika rezerwowa to replika utrwalonej usługi, która została wyłączona, a następnie została otwarta. Ta replika może być używana przez usługę Service Fabric, jeśli musi dodać kolejną replikę do zestawu replik (ponieważ replika ma już część stanu, a proces kompilacji jest szybszy). Po wygaśnięciu funkcji StandByReplicaKeepDuration replika rezerwowa zostanie odrzucona.
Jeśli host aplikacji lub węzeł repliki rezerwowej ulegnie awarii, przechodzi do stanu w dół.
Rola repliki nie jest odpowiednia w stanie wstrzymania.
Uwaga
Każda replika, która nie jest wyłączona lub porzucona, jest uważana za w górę.
Uwaga
Istnieje możliwość przejścia z dowolnego stanu na stan porzucony przy użyciu opcji ForceRemove w systemie Remove-ServiceFabricReplica.
Rola repliki
Rola repliki określa jego funkcję w zestawie replik:
- Podstawowy (P): istnieje jeden podstawowy w zestawie replik, który jest odpowiedzialny za wykonywanie operacji odczytu i zapisu.
- ActiveSecondary (S): są to repliki, które odbierają aktualizacje stanu z serwera podstawowego, stosują je, a następnie wysyłają potwierdzenia z powrotem. W zestawie replik istnieje wiele aktywnych sekund. Liczba tych aktywnych sekund określa liczbę błędów, które może obsłużyć usługa.
- IdleSecondary (I): te repliki są kompilowane przez element podstawowy. Są one odbierane ze stanu podstawowego, zanim będą mogły zostać podniesione do aktywnej pomocniczej.
- Brak (N): Te repliki nie mają odpowiedzialności w zestawie replik.
- Nieznany (U): Jest to początkowa rola repliki przed odebraniem wywołania interfejsu API ChangeRole z usługi Service Fabric.
Na poniższym diagramie przedstawiono przejścia ról repliki i przykładowe scenariusze, w których mogą wystąpić:
- U -> P: Tworzenie nowej repliki podstawowej.
- U -> I: Tworzenie nowej bezczynnej repliki.
- U -> N: Usuwanie repliki rezerwowej.
- I -> S: Podwyższenie poziomu bezczynności pomocniczej do aktywnego pomocniczego, aby jego potwierdzenia przyczyniły się do kworum.
- I -> P: Podwyższenie poziomu bezczynności pomocniczej do podstawowej. Może się to zdarzyć w specjalnych rekonfiguracjach, gdy bezczynność pomocnicza jest właściwym kandydatem na podstawowy.
- I -> N: Usunięcie bezczynnej repliki pomocniczej.
- S -> P: Podwyższenie poziomu aktywnej pomocniczej do podstawowej. Może to być spowodowane przejściem w tryb failover podstawowego lub podstawowego ruchu zainicjowanego przez menedżera zasobów klastra. Na przykład może to być w odpowiedzi na uaktualnienie aplikacji lub równoważenie obciążenia.
- S -> N: Usunięcie aktywnej repliki pomocniczej.
- P -> S: degradacja repliki podstawowej. Może to być spowodowane podstawowym przenoszeniem zainicjowanym przez usługę Resource Manager klastra. Na przykład może to być w odpowiedzi na uaktualnienie aplikacji lub równoważenie obciążenia.
- P -> N: Usunięcie repliki podstawowej.
Uwaga
Modele programowania wyższego poziomu, takie jak Reliable Actors i Reliable Services, ukrywają koncepcję ról repliki od dewelopera. W aktorach pojęcie roli jest niepotrzebne. W obszarze Usługi jest to w dużej mierze uproszczone w przypadku większości scenariuszy.
Następne kroki
Aby uzyskać więcej informacji na temat pojęć związanych z usługą Service Fabric, zobacz następujący artykuł: