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 identyfikator wystąpienia. Cykl życia wystąpienia jest modelowany na poniższym diagramie:
InBuild (IB)
Po Resource Manager klastra określi położenie wystąpienia, zostanie on wprowadzony w tym stanie 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 aplikacji lub węzeł 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 funkcję RunAsync .
Jeśli host aplikacji lub węzeł 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ż zostanie 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 zachowuje 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 do zestawu replik. W zależności od roli repliki IB ma różne semantyki.
Jeśli host aplikacji lub węzeł repliki inbuild ulega awarii, przechodzi do stanu w dół.
Podstawowe repliki InBuild: Podstawowy program InBuild to pierwsze repliki partycji. Ta replika zwykle występuje podczas tworzenia partycji. Repliki podstawowe w programie InBuild występują również wtedy, gdy wszystkie repliki ponownego uruchomienia partycji lub zostaną porzucone.
Repliki IdleSecondary InBuild: są to nowe repliki utworzone przez klaster Resource Manager lub istniejące repliki, które spadły i muszą zostać dodane z powrotem do zestawu. Te repliki są rozstawione lub tworzone przez element podstawowy, zanim będą mogły dołączyć do zestawu 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ę. 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, która uczestniczy 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: usługa Service Fabric może wymagać zamknięcia 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ół. Stan utrwalonej skojarzonej 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 utrwalonego stanu i zamknięcia uruchomionego kodu dla repliki. To zamknięcie może być z wielu powodów, na przykład równoważenie 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ż zostanie 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, uaktualnianie 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 w dół.
Otwieranie (OP)
Replika w dół wchodzi w stan otwarcia, gdy usługa Service Fabric musi ponownie przywrócić replikę. Na przykład ten stan może być 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.
StandBy (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ż pewną 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 ma znaczenia w stanie wstrzymania.
Uwaga
Każda replika, która nie działa lub została porzucona, jest uważana za up up.
Uwaga
Istnieje możliwość przejścia z dowolnego stanu do stanu porzuconego przy użyciu opcji ForceRemove w systemie Remove-ServiceFabricReplica.
Rola repliki
Rola repliki określa jej 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 poziomu podstawowego, stosują je, a następnie wysyłają potwierdzenia zwrotne. W zestawie replik istnieje wiele aktywnych sekund. Liczba tych aktywnych sekund określa liczbę błędów, które usługa może obsłużyć.
- IdleSecondary (I): Te repliki są tworzone przez podstawową. Są one odbierane ze stanu podstawowego, zanim będą mogły być awansowane 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 oraz 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 bezczynnego pomocniczego 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 ramach specjalnych rekonfiguracji, gdy bezczynny pomocniczy jest prawidłowym kandydatem na podstawowe.
- 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 Resource Manager 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 ruchem podstawowym zainicjowanym przez 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 replik od dewelopera. W aktorach pojęcie roli jest niepotrzebne. W usługach jest ona w dużej mierze uproszczona 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ł: