Repliky a instance

Tento článek poskytuje přehled o životním cyklu replik stavových služeb a instancí bezstavových služeb.

Instance bezstavových služeb

Instance bezstavové služby je kopie logiky služby, která běží na jednom z uzlů clusteru. Instance v rámci oddílu je jedinečně identifikována svým InstanceId. Životní cyklus instance je modelován v následujícím diagramu:

InBuild (IB)

Jakmile Správce prostředků clusteru určí umístění instance, přejde do tohoto stavu životního cyklu. Instance se spustí v uzlu. Hostitel aplikace se spustí, instance se vytvoří a pak se otevře. Po dokončení spuštění instance přejde do připraveného stavu.

Pokud se hostitel nebo uzel aplikace pro tuto instanci chybově ukončí, přejde do vyřazeného stavu.

Připraveno (RD)

V připraveném stavu je instance na uzlu spuštěná a běží. Pokud je tato instance spolehlivou službou, byla vyvolána metoda RunAsync .

Pokud hostitel nebo uzel aplikace pro tuto instanci spadne, přechází do vyřazeného stavu.

Zavírání (CL)

Ve koncovém stavu se Azure Service Fabric nachází v procesu vypnutí instance na tomto uzlu. Toto vypnutí může být způsobeno mnoha důvody – například upgrade aplikace, vyrovnávání zatížení nebo odstraněná služba. Po dokončení vypnutí přejde do vyřazeného stavu.

Vyřazeno (DD)

V vyřazeném stavu už instance není v uzlu spuštěná. V tomto okamžiku Service Fabric udržuje metadata o této instanci, která se nakonec také odstraní.

Poznámka:

K přechodu z libovolného stavu do vyřazeného stavu je možné použít možnost ForceRemove zapnuto Remove-ServiceFabricReplica.

Repliky stavových služeb

Replika stavové služby je kopie logiky služby spuštěné na jednom z uzlů clusteru. Replika navíc udržuje kopii stavu této služby. Dva související koncepty popisují životní cyklus a chování stavových replik:

• Životní cyklus repliky
• Role repliky

Následující diskuse vysvětluje trvalé stavové služby. U stavových služeb nestálých (nebo v paměti) jsou stavy mimo provoz a vyřazení ekvivalentní.

InBuild (IB)

Replika InBuild je replika vytvořená nebo připravená pro připojení do sady replik. V závislosti na roli repliky má IB jinou sémantiku.

Pokud dojde k chybovému ukončení hostitele aplikace nebo uzlu repliky InBuildu, přejde do stavu down.

• Primární repliky InBuild: Primární InBuild jsou první repliky pro oddíl. K této replice obvykle dochází při vytváření oddílu. Primární repliky InBuild vznikají také tehdy, když se všechny repliky oddílu restartují nebo odstraní.

• IdleSecondary InBuild repliky: Jedná se o nové repliky vytvořené Správcem prostředků clusteru nebo existující repliky, které zmizely, a je potřeba je přidat zpět do sady. Tyto repliky jsou vytvořené nebo připravené primárním uzlem dříve než se mohou připojit k sadě replik jako ActiveSecondary a účastnit se potvrzování operací kvora.

• Repliky inbuildu ActiveSecondary: Tento stav se v některých dotazech pozoruje. Jedná se o optimalizaci, kdy se sada replik nemění, ale repliku je potřeba sestavit. Replika samotná se řídí normálními přechody stavového automatu (jak je popsáno v části o rolích replik).

Připraveno (RD)

Připravená replika je replika, která se účastní replikace a potvrzování kvora při operacích. Stav připravenosti se vztahuje na primární a aktivní sekundární repliky.

Pokud dojde k chybovému ukončení hostitele aplikace nebo uzlu pro připravenou repliku, přejde do stavu down.

Zavírání (CL)

Replika přejde do koncového stavu v následujících scénářích:

• Vypnutí kódu repliky: Service Fabric může potřebovat vypnout spuštěný kód repliky. Toto vypnutí může být z mnoha důvodů. Může k tomu dojít například kvůli upgradu aplikace, prostředků infrastruktury nebo infrastruktury nebo kvůli chybě hlášené replikou. Po dokončení repliky se replika přesune do stavu down. Trvalý stav přidružený k této replice, která je uložená na disku, se nevyčistí.

• Odebrání repliky z clusteru: Service Fabric může potřebovat odebrat trvalý stav a vypnout spuštěný kód pro repliku. Toto vypnutí může být z mnoha důvodů, například vyrovnávání zatížení.

Vyřazeno (DD)

V vyřazeném stavu už instance není v uzlu spuštěná. Na uzlu také není žádný stav. V tomto okamžiku Service Fabric udržuje metadata o této instanci, která je také nakonec odstraněna.

Dolů (D)

Ve stavu down není kód repliky spuštěný, ale trvalý stav této repliky na daném uzlu existuje. Replika může být mimo provoz z mnoha důvodů– například kvůli výpadku uzlu, chybě v kódu repliky, upgradu aplikace nebo selhání repliky.

Service Fabric otevře neaktivní repliku podle potřeby, například po dokončení upgradu na uzlu.

Role repliky není ve stavu nefunkčnosti relevantní.

Otevření (OP)

Neaktivní replika přejde do stavu aktivace, když Service Fabric potřebuje znovu aktivovat repliku. Tento stav může být například po dokončení upgradu kódu pro aplikaci na uzlu.

Pokud dojde k pádu hostitele aplikace nebo uzlu pro spuštěnou repliku, přejde do neaktivního stavu.

Role repliky není ve stavu otevření relevantní.

StandBy (SB)

Replika StandBy je replika trvalé služby, která přestala fungovat a byla poté znovu zpřístupněna. Tuto repliku může Service Fabric používat, pokud potřebuje přidat další repliku do sady replik (protože replika už má část stavu a proces sestavení je rychlejší). Po vypršení platnosti StandByReplicaKeepDuration se pohotovostní replika odstraní.

Pokud dojde k chybovému ukončení hostitele aplikace nebo uzlu pro pohotovostní repliku, přejde do stavu down.

Role repliky není v pohotovostním stavu relevantní.

Poznámka:

Všechny repliky, které nejsou nefunkční nebo vyřazené, se považují za up.

Poznámka:

K přechodu z libovolného stavu do vyřazeného stavu je možné použít volbu ForceRemove na Remove-ServiceFabricReplica.

Role repliky

Role repliky určuje její funkci v sadě replik:

• Primární (P): V sadě replik je jeden primární, který je zodpovědný za provádění operací čtení a zápisu.
• ActiveSecondary (S): Jedná se o repliky, které přijímají aktualizace stavu z primárního serveru, aplikují je a posílají zpět potvrzení. V sadě replik existuje několik aktivních sekundárních souborů. Počet těchto aktivních sekundárních souborů určuje počet chyb, které může služba zpracovat.
• IdleSecondary (I): Tyto repliky jsou sestaveny primárním serverem. Než mohou být povýšeni na aktivní sekundární server, přijímají stav ze serveru primárního.
• Žádná (N): Tyto repliky nemají v sadě replik odpovědnost.
• Neznámá (U):Toto je počáteční role repliky před tím, než obdrží jakékoli volání rozhraní API ChangeRole ze služby Service Fabric.

Následující diagram znázorňuje přechody rolí repliky a některé ukázkové scénáře, ve kterých mohou nastat:

• U -> P: Vytvoření nové primární repliky.
• U -> I: Vytvoření nové nečinné repliky.
• U -> N: Odstranění pohotovostní repliky.
• I -> S: Povýšení nečinného sekundárního na aktivní sekundární tak, aby jeho potvrzení přispělo kvorum.
• I -> P: Povýšení nečinného sekundárního na primární. K tomu může dojít v rámci speciálních rekonfigurací, pokud je nečinná sekundární sekundární položka správným kandidátem na primární.
• I -> N: Odstranění nečinné sekundární repliky.
• S -> P: Povýšení aktivní sekundární na primární. Příčinou může být selhání primárního serveru nebo přesun primárního serveru iniciovaný Správcem prostředků clusteru. Může například reagovat na upgrade aplikace nebo vyrovnávání zatížení.
• S -> N: Odstranění aktivní sekundární repliky.
• P -> S: Degradace primární repliky. Příčinou může být primární přesun iniciovaný Správcem prostředků clusteru. Může například reagovat na upgrade aplikace nebo vyrovnávání zatížení.
• P -> N: Odstranění primární repliky.

Poznámka:

Programovací modely vyšší úrovně, jako jsou Reliable Actors a Reliable Services, skryjí koncept rolí replik od vývojáře. V Actors je pojem role zbytečný. Ve službách je pro většinu scénářů do značné míry zjednodušená.

Další kroky

Další informace o konceptech Service Fabric najdete v následujícím článku:

Životní cyklus Reliable Services – C#