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.

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.

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.

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 usług Reliable Services — C#