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 jeho ID instance. Ž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 v uzlu spuštěná a spuštěná. Pokud je tato instance spolehlivou službou, byla vyvolána metoda RunAsync .
Pokud se hostitel nebo uzel aplikace pro tuto instanci chybově ukončí, přejde 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 odstraní i.
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í diskuze popisuje 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 inBuildu je replika, která je vytvořená nebo připravená pro připojení 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 InBuildu: Primární inBuild jsou první repliky oddílu. K této replice obvykle dochází při vytváření oddílu. Primární repliky InBuild také vznikají, když se všechny repliky restartování oddílu nebo se zahodí.
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 počáteční nebo sestavené primárním serverem předtím, než se můžou připojit k sadě replik jako ActiveSecondary a účastnit se potvrzení 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. Samotná replika se řídí normálními přechody počítačů stavu (jak je popsáno v části o rolích replik).
Připraveno (RD)
Připravená replika je replika, která se účastní replikace a potvrzení kvora operací. 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á se nakonec odstraní i.
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 repliku down podle potřeby, například po dokončení upgradu na uzlu.
Role repliky není ve stavu down relevantní.
Otevření (OP)
Replika dolů přejde do stavu otevření, když Service Fabric potřebuje znovu přenést repliku zpět. Tento stav může být například po dokončení upgradu kódu pro aplikaci na uzlu.
Pokud dojde k chybovému ukončení hostitele aplikace nebo uzlu pro levou repliku, přejde do stavu down.
Role repliky není ve stavu otevření relevantní.
StandBy (SB)
Replika StandBy je replika trvalé služby, která se pokazila a byla otevřena. 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 zahodí.
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 ukončené nebo se vyřadí, se považují za up.
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.
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. Před povýšení na aktivní sekundární z primárního serveru přijímají stav.
- Žá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 převzetí služeb při selhání primárního nebo primárního přesunu iniciovaného 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: