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. Applikationsvä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 ett avslutat tillstånd.

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 ett avslutat tillstånd.

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. Vid denna tidpunkt underhåller Service Fabric metadata om den här instansen, som så småningom också tas bort.

Anmärkning

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åndsbaserade tjänster

En replik av en tillståndsbaserad tjänst är en kopia av tjänstlogiken som körs på en av noderna i klustret. Dessutom bibehåller repliken en kopia av tjänstens tillståndet. Två relaterade begrepp beskriver livscykeln och beteendet hos statusrepliker.

• Repliklivscykel
• Replikroll

Följande diskussion beskriver beständiga tillståndsbevarande tjänster. För volatila (eller minnesinterna) tillståndsberoende tjänster är de nerstängda och bortkopplade 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 genererade eller skapade av den primära innan de kan ansluta till replikuppsättningen som ActiveSecondary och delta i kvorumbekräftelse av operationer.

• ActiveSecondary InBuild-repliker: Det här tillståndet observeras i vissa sökfrå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 Redo-replik är en replik som deltar i replikering och bekräftelse av kvorum för å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)

Ett replikat går in i avslutningstillstå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 kopplat till den här repliken och lagras på disken rensas inte upp.

• 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. Vid denna tidpunkt 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 vilande replik öppnas vid behov av Service Fabric, till exempel när uppgraderingen har slutförts på noden.

Replikrollen är inte relevant i nedläge.

Öppning (OP)

En nerstängd replik går in i öppningstillståndet när Service Fabric behöver starta om repliken. 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 startande replik kraschar, går den över till avstängt läge.

Replikrollen är inte relevant i den inledande fasen.

StandBy (SB)

En standby-replika är en replika av en beständig tjänst som gick ned och sedan återstartades. 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 slängs väntelägesrepliken.

Om programvärden eller noden för en väntelägesreplik kraschar, övergår de till nere-läget.

Replikrollen är inte relevant i vänteläge.

Anmärkning

Alla kopior som inte är nere eller borttagna anses vara upp.

Anmärkning

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 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ärer i replika setet. 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 status från den primära enheten innan de kan befordras till en aktiv sekundär enhet.
• 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 reservreplik.
• 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ären är rätt kandidat att bli 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å övergång till reservnod av den primära noden eller en förflyttning av den primära som initieras av Klusterresurs hanteraren. 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: Radering av den primära repliken.

Anmärkning

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:

Livscykel för Reliable Services – C#