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:

Instance lifecycle

InBuild (IB)

Nadat clusterbronbeheer 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 wordt afgesloten met het afsluiten van het exemplaar op dit knooppunt. Deze afsluiting kan een groot aantal redenen hebben, bijvoorbeeld een toepassingsupgrade, taakverdeling of de service die wordt verwijderd. Nadat het afsluiten is voltooid, wordt deze overgezet naar de status Verwijderd.

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 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 onderhoudt de replica een kopie van de status van die service. Twee gerelateerde concepten beschrijven de levenscyclus en het gedrag van stateful replica's:

  • Levenscyclus van replica's
  • Replicarol

In de volgende discussie worden permanente stateful services beschreven. Voor vluchtige (of in-memory) stateful services zijn de status omlaag en verwijderd gelijk.

Replica lifecycle

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.

  • Inactieve InBuild-replica's: dit zijn nieuwe replica's die worden gemaakt door clusterresourcebeheer of bestaande replica's die zijn uitgegaan en moeten worden toegevoegd aan de set. Deze replica's worden gezaaid of gebouwd door de primaire replica voordat ze de replicaset kunnen samenvoegen als ActiveSecondary en 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 moet een replica worden gebouwd. De replica zelf volgt de normale statusmachineovergangen (zoals beschreven in de sectie over replicarollen).

Gereed (RD)

Een kant-en-klare 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 Offline.

Sluiten (CL)

Een replica voert in de volgende scenario's de afsluitstatus in:

  • De code voor de replica afsluiten: Mogelijk moet Service Fabric de actieve code voor een replica afsluiten. Deze afsluiting kan om verschillende 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, wordt de replica overgestapt op de status Down. De persistente status die is gekoppeld aan deze replica die is opgeslagen op de 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. 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 over 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 de persistente status voor die replica bestaat op dat knooppunt. Een replica kan om verschillende redenen offline zijn, bijvoorbeeld omdat het knooppunt uitvalt, de replicacode vastloopt, een upgrade van de toepassing of replicafouten.

Een offlinereplica wordt naar behoefte geopend door Service Fabric, bijvoorbeeld wanneer de upgrade op het knooppunt is voltooid.

De replicarol is niet relevant in de status Down.

Openen (OP)

Een offlinereplica treedt in de openingsstatus op wanneer Service Fabric de replica opnieuw moet ophalen. 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 Offline.

De replicarol is niet relevant in de openingsstatus.

StandBy (SB)

Een StandBy-replica is een replica van een persistente service die is uitgeschakeld en vervolgens is geopend. Deze replica kan worden gebruikt door Service Fabric 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 Offline.

De replicarol is niet relevant in de stand-bystatus.

Notitie

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 op 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 secondaries 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 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:

Replica role

  • U -> P: Een nieuwe primaire replica maken.
  • U -> I: Het maken van een nieuwe inactieve 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 secundaire 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. Het kan bijvoorbeeld reageren 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 gestart door clusterresourcebeheer. Het kan bijvoorbeeld reageren 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 idee 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:

Levenscyclus van Reliable Services - C#