Replica's en exemplaren

Dit artikel biedt een overzicht van de levenscyclus van replica's van stateful services en exemplaren van stateless services.

Exemplaren van staatloze services

Een exemplaar van een staatloze service is een kopie van de servicelogica die wordt uitgevoerd op een van de knooppunten van het cluster. Een exemplaar binnen een partitie wordt uniek geïdentificeerd door de InstanceId. De levenscyclus van een exemplaar wordt gemodelleerd in het volgende diagram:

InBuild (IB)

Nadat de cluster-Resource Manager een plaatsing voor het exemplaar heeft bepaald, treedt deze levenscyclusstatus in. Het exemplaar wordt gestart op het knooppunt. De toepassingshost wordt gestart, het exemplaar wordt gemaakt en vervolgens geopend. Nadat het opstarten is voltooid, wordt het exemplaar overgezet naar de status Gereed.

Als de toepassingshost of het knooppunt voor dit exemplaar vastloopt, wordt de status verwijderd.

Gereed (RD)

In de status Gereed is het exemplaar actief op het knooppunt. Als dit exemplaar een betrouwbare service is, is RunAsync aangeroepen.

Als de toepassingshost of het knooppunt voor dit exemplaar vastloopt, wordt de status verwijderd.

Sluiten (CL)

In de afsluitende status is Azure Service Fabric bezig met het afsluiten van het exemplaar op dit knooppunt. Deze afsluiting kan verschillende oorzaken hebben, bijvoorbeeld een upgrade van een toepassing, taakverdeling of de service die wordt verwijderd. Nadat het afsluiten is voltooid, gaat het over naar de status Verwijderd.

Verwijderd (DD)

In de status Verwijderd wordt het exemplaar niet meer uitgevoerd op het knooppunt. Op dit punt onderhoudt Service Fabric de metagegevens over dit exemplaar, die uiteindelijk ook worden verwijderd.

Notitie

Het is mogelijk om over te schakelen van elke status naar de verwijderde status met behulp van de optie ForceRemove op Remove-ServiceFabricReplica.

Replica's van stateful services

Een replica van een stateful service is een kopie van de servicelogica die wordt uitgevoerd op een van de knooppunten van het cluster. Bovendien wordt in de replica een kopie van de status van die service bijgehouden. Twee gerelateerde concepten beschrijven de levenscyclus en het gedrag van stateful replica's:

• Levenscyclus van replica
• Replicarol

In de volgende discussie worden persistente stateful services beschreven. Voor vluchtige (of in-memory) stateful services zijn de statussen Omlaag en Verwijderd gelijkwaardig.

InBuild (IB)

Een InBuild-replica is een replica die is gemaakt of voorbereid voor deelname aan de replicaset. Afhankelijk van de replicarol heeft de IB verschillende semantiek.

Als de toepassingshost of het knooppunt voor een InBuild-replica vastloopt, gaat deze over naar de status Down.

• Primaire InBuild-replica's: Primaire InBuild zijn de eerste replica's voor een partitie. Deze replica gebeurt meestal wanneer de partitie wordt gemaakt. Primaire InBuild-replica's ontstaan ook wanneer alle replica's van een partitie opnieuw worden opgestart of worden verwijderd.

• IdleSecondary InBuild-replica's: dit zijn nieuwe replica's die zijn gemaakt door de cluster-Resource Manager, of bestaande replica's die uit zijn gegaan en opnieuw moeten worden toegevoegd aan de set. Deze replica's worden geseed of gebouwd door de primaire instantie voordat ze aan de replicaset kunnen worden gekoppeld als ActiveSecondary en kunnen deelnemen aan quorumbevestiging van bewerkingen.

• ActiveSecondary InBuild-replica's: deze status wordt waargenomen in sommige query's. Het is een optimalisatie waarbij de replicaset niet verandert, maar er wel een replica moet worden gebouwd. De replica zelf volgt de normale status van de machineovergangen (zoals beschreven in de sectie over replicarollen).

Gereed (RD)

Een gereede replica is een replica die deelneemt aan replicatie en quorumbevestiging van bewerkingen. De status Gereed is van toepassing op primaire en actieve secundaire replica's.

Als de toepassingshost of het knooppunt voor een kant-en-klare replica vastloopt, wordt deze overgezet naar de status Down.

Sluiten (CL)

Een replica treedt in de volgende scenario's naar de slotstatus:

• De code voor de replica afsluiten: Service Fabric moet mogelijk de actieve code voor een replica afsluiten. Deze afsluiting kan verschillende redenen hebben. Dit kan bijvoorbeeld gebeuren vanwege een upgrade van een toepassing, infrastructuur of infrastructuur, of vanwege een fout die is gerapporteerd door de replica. Wanneer het sluiten van de replica is voltooid, gaat de replica over naar de status Omlaag. De persistente status die is gekoppeld aan deze replica die op schijf is opgeslagen, wordt niet opgeschoond.

• De replica verwijderen uit het cluster: Service Fabric moet mogelijk de persistente status verwijderen en de actieve code voor een replica afsluiten. Deze afsluiting kan om verschillende redenen zijn, bijvoorbeeld taakverdeling.

Verwijderd (DD)

In de status Verwijderd wordt het exemplaar niet meer uitgevoerd op het knooppunt. Er is ook geen status meer op het knooppunt. Op dit punt onderhoudt Service Fabric de metagegevens over dit exemplaar, die uiteindelijk ook worden verwijderd.

Omlaag (D)

In de status Down wordt de replicacode niet uitgevoerd, maar de persistente status voor die replica bestaat op dat knooppunt. Een replica kan om verschillende redenen offline zijn, bijvoorbeeld omdat het knooppunt niet beschikbaar is, de replicacode vastloopt, een toepassingsupgrade of replicafouten.

Service Fabric opent indien nodig een offline replica, bijvoorbeeld wanneer de upgrade op het knooppunt is voltooid.

De replicarol is niet relevant in de status Down.

Openen (OP)

Een offline replica treedt in de openingsstatus op wanneer Service Fabric de replica weer moet herstellen. Deze status kan bijvoorbeeld zijn nadat een code-upgrade voor de toepassing is voltooid op een knooppunt.

Als de toepassingshost of het knooppunt voor een geopende replica vastloopt, wordt deze overgezet naar de status Omlaag.

De replicarol is niet relevant in de openingsstatus.

StandBy (SB)

Een StandBy-replica is een replica van een persistente service die uitvalt en vervolgens is geopend. Deze replica kan worden gebruikt door Service Fabric als er een andere replica moet worden toegevoegd aan de replicaset (omdat de replica al een deel van de status heeft en het buildproces sneller is). Nadat de StandByReplicaKeepDuration is verlopen, wordt de stand-byreplica verwijderd.

Als de toepassingshost of het knooppunt voor een stand-byreplica vastloopt, gaat deze over naar de status Down.

De replicarol is niet relevant in de stand-bystatus.

Notitie

Elke replica die niet offline of verwijderd is, wordt beschouwd als boven.

Notitie

Het is mogelijk om over te schakelen van elke status naar de verwijderde status met behulp van de optie ForceRemove op Remove-ServiceFabricReplica.

Replicarol

De rol van de replica bepaalt de functie in de replicaset:

• Primair (P): Er is één primaire replicaset die verantwoordelijk is voor het uitvoeren van lees- en schrijfbewerkingen.
• ActiveSecondary (S): dit zijn replica's die statusupdates ontvangen van de primaire instantie, deze toepassen en vervolgens bevestigingen terugsturen. Er zijn meerdere actieve secundaire databases in de replicaset. Het aantal actieve secundaire databases bepaalt het aantal fouten dat de service kan verwerken.
• IdleSecondary (I): deze replica's worden gebouwd door de primaire. Ze ontvangen de status van de primaire voordat ze kunnen worden gepromoveerd naar actieve secundaire.
• Geen (N): deze replica's hebben geen verantwoordelijkheid in de replicaset.
• Onbekend (U): dit is de eerste rol van een replica voordat deze een ChangeRole API-aanroep van Service Fabric ontvangt.

In het volgende diagram ziet u de replicarolovergangen en enkele voorbeeldscenario's waarin deze zich kunnen voordoen:

• U -> P: Een nieuwe primaire replica maken.
• U -> I: Een nieuwe niet-actieve replica maken.
• U -> N: verwijdering van een stand-byreplica.
• I -> S: Promotie van de niet-actieve secundaire naar de actieve secundaire zodat de bevestigingen bijdragen aan het quorum.
• I -> P: Promotie van de niet-actieve secundaire naar primaire. Dit kan gebeuren bij speciale herconfiguraties wanneer de niet-actieve secundaire de juiste kandidaat is om primair te zijn.
• I -> N: verwijdering van de niet-actieve secundaire replica.
• S -> P: Promotie van de actieve secundaire naar primaire. Dit kan worden veroorzaakt door een failover van de primaire of een primaire verplaatsing die is geïnitieerd door de cluster Resource Manager. Het kan bijvoorbeeld zijn als reactie op een toepassingsupgrade of taakverdeling.
• S -> N: verwijdering van de actieve secundaire replica.
• P -> S: Degradatie van de primaire replica. Dit kan worden veroorzaakt door een primaire verplaatsing die is geïnitieerd door de cluster Resource Manager. Het kan bijvoorbeeld zijn als reactie op een toepassingsupgrade of taakverdeling.
• P -> N: verwijdering van de primaire replica.

Notitie

Programmeermodellen op een hoger niveau, zoals Reliable Actors en Reliable Services, verbergen het concept van replicarollen voor de ontwikkelaar. In Actors is het idee van een rol niet nodig. In Services is dit grotendeels vereenvoudigd voor de meeste scenario's.

Volgende stappen

Zie het volgende artikel voor meer informatie over Service Fabric-concepten:

Levenscyclus van Reliable Services - C#