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 klustrets Resource Manager 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 och körs 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.
Avslutande (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 avbrutna tillståndet.
Borttagen (DD)
I det borttagna tillståndet körs instansen inte längre på noden. Nu underhåller Service Fabric metadata om den här instansen, som så småningom också tas bort.
Anteckning
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 underhå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 ned- och nedrullningsbara tillstånd likvärdiga.
InBuild (IB)
En InBuild-replik är en replik som har skapats eller förberetts 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 klustret Resource Manager eller befintliga repliker som har gått ned och som måste läggas till i uppsättningen igen. Dessa repliker seedas eller skapas 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 klar replik kraschar övergår den till nedtillståndet.
Avslutande (CL)
En replik anger sluttillstå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 vara av många skäl. 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 bevarade tillstånd som är associerat med den här repliken som lagras på disken rensas inte.
Ta bort repliken från klustret: Service Fabric kan behöva ta bort det bevarade 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 instansen inte längre 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 nedtillståndet körs inte replikkoden, men det bevarade 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 säkerhetskopiera repliken igen. Det här tillståndet kan till exempel vara när 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 bevarad 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.
Anteckning
Alla repliker som inte är ned- eller borttagna anses vara upp.
Anteckning
Du kan gå över 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änt (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 standby-replik.
- 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 den 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 kluster Resource Manager. 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 kluster Resource Manager. Det kan till exempel vara ett svar på en programuppgradering eller belastningsutjämning.
- P –> N: Borttagning av den primära repliken.
Anteckning
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 i stort sett förenklat för de flesta scenarier.
Nästa steg
Mer information om Service Fabric-begrepp finns i följande artikel: