Replica's en exemplaren
Dit artikel bevat een overzicht van de levenscyclus van replica's van stateful services en exemplaren van stateless services.
Exemplaren van stateless 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 Cluster Resource Manager een plaatsing voor het exemplaar heeft bepaald, wordt deze levenscyclusstatus ingevoerd. 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 overgestapt op de status Gereed.
Als de toepassingshost of het knooppunt voor dit exemplaar vastloopt, wordt deze overgezet naar 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 deze overgezet naar de status Verwijderd.
Sluiten (CL)
Azure Service Fabric is bezig met het afsluiten van het exemplaar op dit knooppunt. Deze afsluiting kan verschillende oorzaken hebben, bijvoorbeeld een toepassingsupgrade, taakverdeling of de service die wordt verwijderd. Nadat het afsluiten is voltooid, wordt deze overgezet naar de verwijderde status.
Verwijderd (DD)
In de status Verwijderd wordt het exemplaar niet meer uitgevoerd op het knooppunt. Op dit moment onderhoudt Service Fabric de metagegevens over dit exemplaar, die uiteindelijk ook worden verwijderd.
Notitie
Het is mogelijk om over te stappen van elke status naar de verwijderde status met behulp van de optie ForceRemove ingeschakeld 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. Daarnaast onderhoudt de replica een kopie van de status van die service. In twee gerelateerde concepten wordt de levenscyclus en het gedrag van stateful replica's beschreven:
- Levenscyclus van replica
- Replicarol
In de volgende discussie worden persistente stateful services beschreven. Voor vluchtige (of in-memory) stateful services zijn de statussen down en dropped equivalent.
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, wordt deze overgestapt op de status Down.
Primaire InBuild-replica's: Primary InBuild zijn de eerste replica's voor een partitie. Deze replica treedt meestal op wanneer de partitie wordt gemaakt. Primaire InBuild-replica's ontstaan ook wanneer alle replica's van een partitie opnieuw worden opgestart of verwijderd.
IdleSecondary InBuild-replica's: dit zijn nieuwe replica's die worden gemaakt door clusterresourcebeheer of bestaande replica's die omlaag zijn gegaan en die weer moeten worden toegevoegd aan de set. Deze replica's worden geseed of gebouwd door de primaire replica voordat ze de replicaset als ActiveSecondary kunnen samenvoegen 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 wordt gewijzigd, maar een replica moet worden gebouwd. De replica zelf volgt de overgangen van de normale statusmachine (zoals beschreven in de sectie over replicarollen).
Gereed (RD)
Een ready 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 overgestapt op de status Down.
Sluiten (CL)
Een replica voert de afsluitstatus in de volgende scenario's in:
De code voor de replica afsluiten: Service Fabric moet mogelijk de actieve code voor een replica afsluiten. Deze afsluiting kan om vele redenen zijn. Dit kan bijvoorbeeld gebeuren vanwege een upgrade van een toepassing, infrastructuur of infrastructuur of vanwege een fout die door de replica is gerapporteerd. Wanneer de replica is gesloten, gaat de replica over naar de status Down. De persistente status die is gekoppeld aan deze replica die is opgeslagen op schijf, 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. Dit afsluiten 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 moment onderhoudt Service Fabric de metagegevens over dit exemplaar, die uiteindelijk ook worden verwijderd.
Omlaag (D)
In de status Offline wordt de replicacode niet uitgevoerd, maar bestaat de persistente status voor die replica op dat knooppunt. Een replica kan om verschillende redenen niet beschikbaar zijn, bijvoorbeeld omdat het knooppunt uitvalt, een crash in de replicacode, een toepassingsupgrade of replicafouten.
Een offlinereplica wordt naar behoefte door Service Fabric geopend, bijvoorbeeld wanneer de upgrade op het knooppunt is voltooid.
De replicarol is niet relevant in de status Down.
Openen (OP)
Een offlinereplica voert de openingsstatus in wanneer Service Fabric de replica weer omhoog moet brengen. 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 overgestapt op de status Down.
De replicarol is niet relevant in de openingsstatus.
StandBy (SB)
Een StandBy-replica is een replica van een persistente service die is onderbroken en vervolgens is geopend. Deze replica kan door Service Fabric worden gebruikt als deze een andere replica moet toevoegen 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, wordt deze overgestapt op de status Down.
De replicarol is niet relevant in de stand-bystatus.
Notitie
Alle replica's die niet omlaag of verwijderd zijn, worden beschouwd als omhoog.
Notitie
Het is mogelijk om over te stappen van elke status naar de verwijderde status met behulp van de optie ForceRemove aan Remove-ServiceFabricReplica.
Replicarol
De rol van de replica bepaalt de functie in de replicaset:
- Primair (P): er is één primaire in de replicaset die verantwoordelijk is voor het uitvoeren van lees- en schrijfbewerkingen.
- ActiveSecondary (S):dit zijn replica's die statusupdates ontvangen van de primaire versie, deze toepassen en vervolgens bevestigingen terugsturen. Er zijn meerdere actieve secundaire databases in de replicaset. Het aantal actieve secundaire secundaire bestanden bepaalt het aantal fouten dat de service kan verwerken.
- IdleSecondary (I): deze replica's worden gebouwd door de primaire replica. Ze ontvangen de status van de primaire server 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 overgangen van de replicarol en enkele voorbeeldscenario's waarin ze kunnen optreden:
- U -> P: Een nieuwe primaire replica maken.
- U - I: Het maken van een nieuwe niet-actieve> replica.
- U -> N: Verwijdering van een stand-byreplica.
- I -> S: Promotie van de niet-actieve secundaire naar actieve secundaire, zodat de bevestigingen bijdragen aan quorum.
- I -> P: Promotie van de niet-actieve secundaire naar primaire. Dit kan gebeuren onder speciale herconfiguraties wanneer de niet-actieve secundaire de juiste kandidaat is om primair te zijn.
- I -> N: Verwijdering van de secundaire replica die niet actief is.
- 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 clusterresourcebeheer. Dit kan bijvoorbeeld het antwoord zijn 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 Cluster Resource Manager. Dit kan bijvoorbeeld het antwoord zijn 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 van de ontwikkelaar. In Actors is het begrip van een rol niet nodig. In Services is het grotendeels vereenvoudigd voor de meeste scenario's.
Volgende stappen
Zie het volgende artikel voor meer informatie over Service Fabric-concepten: