Repliker och instanser
Den här artikeln ger en översikt över livscykeln för repliker av tillståndskänsliga tjänster och instanser av tillståndslösa tjänster.
Instanser av tillståndslösa tjänster
En instans av en tillståndslös tjänst är en kopia av tjänstlogik som körs på en av noderna i klustret. En instans i en partition identifieras unikt av dess InstanceId. Livscykeln för en instans modelleras i följande diagram:
InBuild (IB)
När Klusterresurshanteraren har fastställt en placering för instansen går den in i det här livscykeltillståndet. Instansen startas på noden. Programvärden startas, instansen skapas och öppnas sedan. När starten är klar övergår instansen till klart tillstånd.
Om programvärden eller noden för den här instansen kraschar övergår den till det borttagna tillståndet.
Klar (RD)
I tillståndet redo är instansen igång på noden. Om den här instansen är en tillförlitlig tjänst har RunAsync anropats.
Om programvärden eller noden för den här instansen kraschar övergår den till det borttagna tillståndet.
Stängning (CL)
I sluttillståndet håller Azure Service Fabric på att stänga av instansen på den här noden. Den här avstängningen kan bero på många orsaker – till exempel en programuppgradering, belastningsutjämning eller den tjänst som tas bort. När avstängningen är klar övergår den till det borttagna tillståndet.
Borttagen (DD)
I det borttagna tillståndet körs inte längre instansen på noden. Nu underhåller Service Fabric metadata om den här instansen, som så småningom också tas bort.
Kommentar
Det är möjligt att övergå från alla tillstånd till det borttagna tillståndet med hjälp av alternativet ForceRemove på Remove-ServiceFabricReplica.
Repliker av tillståndskänsliga tjänster
En replik av en tillståndskänslig tjänst är en kopia av tjänstlogiken som körs på en av noderna i klustret. Dessutom upprätthåller repliken en kopia av tjänstens tillstånd. Två relaterade begrepp beskriver livscykeln och beteendet för tillståndskänsliga repliker:
- Repliklivscykel
- Replikroll
Följande diskussion beskriver beständiga tillståndskänsliga tjänster. För instabila (eller minnesinterna) tillståndskänsliga tjänster är de nedrullningsbara och borttagna tillstånden likvärdiga.
InBuild (IB)
En InBuild-replik är en replik som skapas eller förbereds för att ansluta till replikuppsättningen. Beroende på replikrollen har IB olika semantik.
Om programvärden eller noden för en InBuild-replik kraschar övergår den till nedtillståndet.
Primära InBuild-repliker: Primär InBuild är de första replikerna för en partition. Den här repliken inträffar vanligtvis när partitionen skapas. Primära InBuild-repliker uppstår också när alla repliker av en partition startas om eller tas bort.
IdleSecondary InBuild-repliker: Det här är antingen nya repliker som skapas av Klusterresurshanteraren eller befintliga repliker som har gått ned och som måste läggas till i uppsättningen igen. Dessa repliker är seedade eller skapade av den primära innan de kan ansluta replikuppsättningen som ActiveSecondary och delta i kvorum-bekräftelse av åtgärder.
ActiveSecondary InBuild-repliker: Det här tillståndet observeras i vissa frågor. Det är en optimering där replikuppsättningen inte ändras, men en replik måste skapas. Själva repliken följer de normala tillståndsdatorövergångarna (enligt beskrivningen i avsnittet om replikroller).
Klar (RD)
En Klar replik är en replik som deltar i replikering och kvorum-bekräftelse av åtgärder. Tillståndet redo gäller för primära och aktiva sekundära repliker.
Om programvärden eller noden för en redo replik kraschar övergår den till nedtillståndet.
Stängning (CL)
En replik anger stängningstillståndet i följande scenarier:
Stänga av koden för repliken: Service Fabric kan behöva stänga av koden som körs för en replik. Den här avstängningen kan bero på många orsaker. Det kan till exempel inträffa på grund av en uppgradering av program, infrastruktur eller på grund av ett fel som rapporterats av repliken. När repliken stängs övergår repliken till nedtillståndet. Det beständiga tillstånd som är associerat med den här repliken som lagras på disken rensas inte.
Tar bort repliken från klustret: Service Fabric kan behöva ta bort det beständiga tillståndet och stänga av koden som körs för en replik. Den här avstängningen kan vara av många orsaker, till exempel belastningsutjämning.
Borttagen (DD)
I det borttagna tillståndet körs inte längre instansen på noden. Det finns inte heller något tillstånd kvar på noden. Nu underhåller Service Fabric metadata om den här instansen, som så småningom också tas bort.
Ned (D)
I nedläge körs inte replikkoden, men det beständiga tillståndet för repliken finns på den noden. En replik kan vara nere av många skäl– till exempel att noden är nere, en krasch i replikkoden, en programuppgradering eller replikfel.
En nedreplik öppnas av Service Fabric efter behov, till exempel när uppgraderingen har slutförts på noden.
Replikrollen är inte relevant i nedläge.
Öppning (OP)
En nedreplik anger öppningstillståndet när Service Fabric behöver återställa repliken igen. Det här tillståndet kan till exempel vara efter att en koduppgradering för programmet har slutförts på en nod.
Om programvärden eller noden för en inledande replik kraschar övergår den till nedtillståndet.
Replikrollen är inte relevant i öppningstillståndet.
StandBy (SB)
En StandBy-replik är en replik av en beständiga tjänst som gick ned och sedan öppnades. Den här repliken kan användas av Service Fabric om den behöver lägga till en annan replik till replikuppsättningen (eftersom repliken redan har en del av tillståndet och byggprocessen går snabbare). När StandByReplicaKeepDuration upphör att gälla ignoreras väntelägesrepliken.
Om programvärden eller noden för en väntelägesreplik kraschar övergår den till nedtillståndet.
Replikrollen är inte relevant i vänteläge.
Kommentar
Alla repliker som inte är ned- eller borttagna anses vara upp.
Kommentar
Det går att övergå från alla tillstånd till det borttagna tillståndet med hjälp av alternativet ForceRemove på Remove-ServiceFabricReplica.
Replikroll
Replikens roll avgör dess funktion i replikuppsättningen:
- Primär (P): Det finns en primär i replikuppsättningen som ansvarar för att utföra läs- och skrivåtgärder.
- ActiveSecondary (S): Det här är repliker som tar emot tillståndsuppdateringar från den primära, tillämpar dem och sedan skickar tillbaka bekräftelser. Det finns flera aktiva sekundärfiler i replikuppsättningen. Antalet aktiva sekundärfiler avgör antalet fel som tjänsten kan hantera.
- IdleSecondary (I): Dessa repliker skapas av den primära. De får tillstånd från den primära innan de kan befordras till aktiv sekundär.
- Ingen (N): Dessa repliker har inget ansvar i replikuppsättningen.
- Okänd (U): Det här är den första rollen för en replik innan den tar emot ett ChangeRole API-anrop från Service Fabric.
Följande diagram illustrerar replikrollövergångarna och några exempelscenarier där de kan inträffa:
- U –> P: Skapa en ny primär replik.
- U –> I: Skapa en ny inaktiv replik.
- U –> N: Borttagning av en väntelägesreplik.
- I -> S: Befordran av den inaktiva sekundära till aktiva sekundära så att dess bekräftelser bidrar till kvorum.
- I –> P: Befordran av den inaktiva sekundära till primära. Detta kan inträffa under särskilda omkonfigurationer när den inaktiva sekundära är rätt kandidat för att vara primär.
- I –> N: Borttagning av den inaktiva sekundära repliken.
- S –> P: Befordran av den aktiva sekundära till den primära. Detta kan bero på redundansväxling av den primära eller en primär rörelse som initieras av Klusterresurshanteraren. Det kan till exempel vara ett svar på en programuppgradering eller belastningsutjämning.
- S –> N: Borttagning av den aktiva sekundära repliken.
- P –> S: Degradering av den primära repliken. Detta kan bero på en primär förflyttning som initieras av Klusterresurshanteraren. Det kan till exempel vara ett svar på en programuppgradering eller belastningsutjämning.
- P –> N: Borttagning av den primära repliken.
Kommentar
Programmeringsmodeller på högre nivå, till exempel Reliable Actors och Reliable Services, döljer begreppet replikroller från utvecklaren. I Actors är begreppet roll onödigt. I Tjänster är det till stor del förenklat för de flesta scenarier.
Nästa steg
Mer information om Service Fabric-begrepp finns i följande artikel: