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:

Instance lifecycle

InBuild (IB)

Po określeniu położenia wystąpienia przez usługę Resource Manager klastra 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.

Replica lifecycle

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, 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ą 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ć:

Replica role

  • 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 przypadku specjalnych rekonfiguracji, gdy bezczynny pomocniczy element jest właściwym kandydatem do podstawowej konfiguracji.
  • 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 menedżera zasobów 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 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ł:

Cykl życia interfejsu Reliable Services — C#