Haveriberedskap i Azure Service Fabric

  • Artikel

En viktig del av att leverera hög tillgänglighet är att säkerställa att tjänster kan överleva alla olika typer av fel. Detta är särskilt viktigt för fel som är oplanerade och utanför din kontroll.

Den här artikeln beskriver några vanliga fellägen som kan vara katastrofer om de inte modelleras och hanteras korrekt. Den beskriver också åtgärder och åtgärder som ska utföras om en katastrof inträffar ändå. Målet är att begränsa eller eliminera risken för stilleståndstid eller dataförlust när fel, planerade eller på annat sätt, inträffar.

Undvika katastrof

Huvudmålet med Azure Service Fabric är att hjälpa dig att modellera både din miljö och dina tjänster på ett sådant sätt att vanliga feltyper inte är katastrofer.

I allmänhet finns det två typer av katastrof-/felscenarier:

  • Maskin- och programvarufel
  • Driftfel

Maskin- och programvarufel

Maskinvaru- och programvarufel är oförutsägbara. Det enklaste sättet att överleva fel är att köra fler kopior av tjänsten över maskinvaru- eller programvarufelgränser.

Om tjänsten till exempel bara körs på en dator är felet för den datorn en katastrof för den tjänsten. Det enkla sättet att undvika den här katastrofen är att se till att tjänsten körs på flera datorer. Testning är också nödvändigt för att säkerställa att felet på en dator inte stör tjänsten som körs. Kapacitetsplanering säkerställer att en ersättningsinstans kan skapas någon annanstans och att kapacitetsminskningen inte överbelastar de återstående tjänsterna.

Samma mönster fungerar oavsett vad du försöker undvika felet med. Om du till exempel är orolig för felet med ett SAN körs du över flera SAN. Om du är orolig för förlusten av ett rack med servrar körs du över flera rack. Om du är orolig för förlusten av datacenter bör tjänsten köras över flera Azure-regioner, över flera Azure-Tillgänglighetszoner eller i dina egna datacenter.

När en tjänst sträcker sig över flera fysiska instanser (datorer, rack, datacenter, regioner) omfattas du fortfarande av vissa typer av samtidiga fel. Men enskilda och till och med flera fel av en viss typ (till exempel en enskild virtuell dator eller nätverkslänk som misslyckas) hanteras automatiskt och är därför inte längre en "katastrof".

Service Fabric tillhandahåller mekanismer för att expandera klustret och hanterar återställning av misslyckade noder och tjänster. Med Service Fabric kan du också köra många instanser av dina tjänster för att förhindra att oplanerade fel förvandlas till verkliga katastrofer.

Det kan finnas skäl till varför det inte är möjligt att köra en distribution som är tillräckligt stor för att sträcka sig över fel. Det kan till exempel krävas fler maskinvaruresurser än vad du är villig att betala för i förhållande till risken för fel. När du hanterar distribuerade program kan ytterligare kommunikationshopp eller tillståndsreplikeringskostnader över geografiska avstånd orsaka oacceptabla svarstider. Där den här raden ritas skiljer sig åt för varje program.

För programvarufel kan felet finnas i den tjänst som du försöker skala. I det här fallet förhindrar inte fler kopior katastrofen, eftersom feltillståndet är korrelerat mellan alla instanser.

Driftfel

Även om din tjänst sträcker sig över hela världen med många redundans kan den fortfarande uppleva katastrofala händelser. Någon kan till exempel oavsiktligt konfigurera om DNS-namnet för tjänsten eller ta bort det direkt.

Anta till exempel att du har en tillståndskänslig Service Fabric-tjänst och att någon har tagit bort tjänsten av misstag. Om det inte finns någon annan åtgärd är den tjänsten och allt tillstånd som den hade nu borta. Dessa typer av driftskatastrofer ("oops") kräver olika åtgärder och steg för återställning än vanliga oplanerade fel.

De bästa sätten att undvika dessa typer av driftfel är att:

  • Begränsa driftåtkomsten till miljön.
  • Strikt granska farliga åtgärder.
  • Införa automatisering, förhindra manuella eller out-of-band-ändringar och verifiera specifika ändringar mot miljön innan du antar dem.
  • Se till att destruktiva åtgärder är "mjuka". Mjuka åtgärder börjar inte gälla omedelbart eller kan ångras inom ett tidsfönster.

Service Fabric tillhandahåller mekanismer för att förhindra driftsfel, till exempel att tillhandahålla rollbaserad åtkomstkontroll för klusteråtgärder. De flesta av dessa driftfel kräver dock organisatoriska insatser och andra system. Service Fabric tillhandahåller mekanismer för att överleva driftfel, särskilt säkerhetskopiering och återställning för tillståndskänsliga tjänster.

Hantera fel

Målet med Service Fabric är automatisk hantering av fel. Men för att hantera vissa typer av fel måste tjänsterna ha ytterligare kod. Andra typer av fel bör inte åtgärdas automatiskt av säkerhets- och affärskontinuitetsskäl.

Hantera enskilda fel

Enskilda datorer kan misslyckas av alla möjliga orsaker. Ibland är det maskinvaruorsaker, till exempel strömförsörjning och maskinvarufel i nätverket. Andra fel finns i programvara. Dessa inkluderar fel i operativsystemet och själva tjänsten. Service Fabric identifierar automatiskt dessa typer av fel, inklusive fall där datorn isoleras från andra datorer på grund av nätverksproblem.

Oavsett tjänsttyp leder körning av en enskild instans till stilleståndstid för tjänsten om den enkla kopian av koden misslyckas av någon anledning.

För att hantera ett enskilt fel är det enklaste du kan göra att se till att dina tjänster körs på fler än en nod som standard. För tillståndslösa tjänster kontrollerar du att är InstanceCount större än 1. För tillståndskänsliga tjänster är den minsta rekommendationen att TargetReplicaSetSize och MinReplicaSetSize båda är inställda på 3. Om du kör fler kopior av tjänstkoden ser du till att tjänsten kan hantera alla enskilda fel automatiskt.

Hantera samordnade fel

Samordnade fel i ett kluster kan bero på antingen planerade eller oplanerade infrastrukturfel och ändringar eller planerade programvaruändringar. Service Fabric modellerar infrastrukturzoner som upplever samordnade fel som feldomäner. Områden som kommer att uppleva samordnade programvaruändringar modelleras som uppgraderingsdomäner. Mer information om feldomäner, uppgraderingsdomäner och klustertopologi finns i Beskriva ett Service Fabric-kluster med hjälp av kluster Resource Manager.

Som standard tar Service Fabric hänsyn till fel- och uppgraderingsdomäner när du planerar var dina tjänster ska köras. Som standard försöker Service Fabric se till att dina tjänster körs över flera fel- och uppgraderingsdomäner så att dina tjänster förblir tillgängliga om planerade eller oplanerade ändringar inträffar.

Anta till exempel att fel i en strömkälla gör att alla datorer i ett rack misslyckas samtidigt. Om flera kopior av tjänsten körs blir förlusten av många datorer i feldomänfel bara ännu ett exempel på ett enda fel för en tjänst. Därför är det viktigt att hantera fel- och uppgraderingsdomäner för att säkerställa hög tillgänglighet för dina tjänster.

När du kör Service Fabric i Azure hanteras feldomäner och uppgraderingsdomäner automatiskt. I andra miljöer kanske de inte är det. Om du skapar egna kluster lokalt måste du mappa och planera feldomänlayouten korrekt.

Uppgraderingsdomäner är användbara för modelleringsområden där programvara uppgraderas samtidigt. Därför definierar uppgraderingsdomäner ofta de gränser där programvara tas bort under planerade uppgraderingar. Uppgraderingar av både Service Fabric och dina tjänster följer samma modell. Mer information om löpande uppgraderingar, uppgraderingsdomäner och Service Fabric-hälsomodellen som hjälper till att förhindra oavsiktliga ändringar från att påverka klustret och tjänsten finns i:

Du kan visualisera klustrets layout med hjälp av den klusterkarta som finns i Service Fabric Explorer:

Noder spridda över feldomäner i Service Fabric Explorer

Anteckning

Modelleringsområden för fel, löpande uppgraderingar, körning av många instanser av tjänstkod och -tillstånd, placeringsregler för att säkerställa att dina tjänster körs över fel- och uppgraderingsdomäner och inbyggd hälsoövervakning är bara några av de funktioner som Service Fabric tillhandahåller för att hålla normala driftproblem och fel från att förvandlas till katastrofer.

Hantera samtidiga maskinvaru- eller programvarufel

Vi har pratat om enskilda fel. Som du ser är de enkla att hantera för både tillståndslösa och tillståndskänsliga tjänster bara genom att behålla fler kopior av koden (och tillståndet) som körs över fel- och uppgraderingsdomäner.

Flera samtidiga slumpmässiga fel kan också inträffa. Dessa är mer benägna att leda till stilleståndstid eller en faktisk katastrof.

Tillståndslösa tjänster

Antalet instanser för en tillståndslös tjänst anger önskat antal instanser som behöver köras. När någon (eller alla) av instanserna misslyckas svarar Service Fabric genom att automatiskt skapa ersättningsinstanser på andra noder. Service Fabric fortsätter att skapa ersättningar tills tjänsten är tillbaka till önskat antal instanser.

Anta till exempel att den tillståndslösa tjänsten har värdet InstanceCount -1. Det här värdet innebär att en instans ska köras på varje nod i klustret. Om vissa av dessa instanser misslyckas identifierar Service Fabric att tjänsten inte är i önskat tillstånd och försöker skapa instanserna på noderna där de saknas.

Tillståndskänsliga tjänster

Det finns två typer av tillståndskänsliga tjänster:

  • Tillståndskänslig med beständiga tillstånd.
  • Tillståndskänslig med icke-beständiga tillstånd. (Tillståndet lagras i minnet.)

Återställning från fel i en tillståndskänslig tjänst beror på typen av tillståndskänslig tjänst, hur många repliker tjänsten hade och hur många repliker som misslyckades.

I en tillståndskänslig tjänst replikeras inkommande data mellan repliker (den primära och alla aktiva sekundärfiler). Om en majoritet av replikerna tar emot data anses data vara kvorum som bekräftats. (För fem repliker är tre ett kvorum.) Det innebär att det när som helst finns minst ett kvorum med repliker med de senaste data. Om repliker misslyckas (till exempel två av fem) kan vi använda kvorumvärdet för att beräkna om vi kan återställa. (Eftersom de återstående tre av fem replikerna fortfarande är uppe garanteras det att minst en replik har fullständiga data.)

När ett kvorum med repliker misslyckas deklareras partitionen vara i ett kvorumförlusttillstånd . Anta att en partition har fem repliker, vilket innebär att minst tre är garanterade att ha fullständiga data. Om ett kvorum (tre av fem) repliker misslyckas kan Service Fabric inte avgöra om de återstående replikerna (två av fem) har tillräckligt med data för att återställa partitionen. Om Service Fabric identifierar kvorumförlust är standardbeteendet att förhindra ytterligare skrivningar till partitionen, deklarera kvorumförlust och vänta på att ett kvorum med repliker återställs.

Att avgöra om en katastrof har inträffat för en tillståndskänslig tjänst och sedan hantera den följer tre steg:

  1. Avgöra om det har skett kvorumförlust eller inte.

    Kvorumförlust deklareras när en majoritet av replikerna av en tillståndskänslig tjänst är nere samtidigt.

  2. Avgöra om kvorumförlusten är permanent eller inte.

    För det mesta är fel tillfälliga. Processer startas om, noder startas om, virtuella datorer startas om och nätverkspartitioner repareras. Ibland är dock misslyckanden permanenta. Om felen är permanenta eller inte beror på om den tillståndskänsliga tjänsten behåller sitt tillstånd eller om den bara behåller det i minnet:

    • För tjänster utan beständiga tillstånd resulterar ett fel i ett kvorum eller flera repliker omedelbart i permanent kvorumförlust. När Service Fabric identifierar kvorumförlust i en tillståndskänslig icke-beständig tjänst fortsätter den omedelbart till steg 3 genom att deklarera (potentiell) dataförlust. Att fortsätta med dataförlust är logiskt eftersom Service Fabric vet att det inte är någon idé att vänta på att replikerna ska komma tillbaka. Även om de återställs går data förlorade på grund av tjänstens icke-bevarade natur.
    • För tillståndskänsliga beständiga tjänster gör ett kvorumfel eller flera repliker att Service Fabric väntar på att replikerna ska komma tillbaka och återställa kvorumet. Detta resulterar i ett tjänststopp för alla skrivningar till den berörda partitionen (eller "replikuppsättningen") för tjänsten. Läsningar kan dock fortfarande vara möjliga med minskade konsekvensgarantier. Den standardtid som Service Fabric väntar på att kvorumet ska återställas är oändligt, eftersom det är en (potentiell) dataförlusthändelse som medför andra risker. Det innebär att Service Fabric inte fortsätter till nästa steg om inte en administratör vidtar åtgärder för att deklarera dataförlust.

  3. Avgöra om data går förlorade och återställa från säkerhetskopior.

    Om kvorumförlust har deklarerats (antingen automatiskt eller genom administrativa åtgärder) går Service Fabric och tjänsterna vidare till att avgöra om data faktiskt gick förlorade. Nu vet Service Fabric också att de andra replikerna inte kommer tillbaka. Det var det beslut som fattades när vi slutade vänta på att kvorumförlusten skulle lösa sig själv. Det bästa tillvägagångssätt för tjänsten är vanligtvis att frysa och vänta på specifika administrativa åtgärder.

    När Service Fabric anropar OnDataLossAsync metoden beror det alltid på misstänkt dataförlust. Service Fabric ser till att det här anropet levereras till den bästa återstående repliken. Det här är den replik som har gjort mest framsteg.

    Anledningen till att vi alltid säger misstänkt dataförlust är att det är möjligt att den återstående repliken har samma tillstånd som den primära gjorde när kvorum förlorades. Men utan det tillståndet att jämföra det med finns det inget bra sätt för Service Fabric eller operatörer att veta säkert.

    Så vad gör en typisk implementering av OnDataLossAsync metoden?

    1. Implementeringsloggarna som OnDataLossAsync har utlösts och utlöser alla nödvändiga administrativa aviseringar.

    2. Vanligtvis pausar och väntar implementeringen på att ytterligare beslut och manuella åtgärder ska vidtas. Detta beror på att även om säkerhetskopior är tillgängliga kan de behöva förberedas.

      Om två olika tjänster till exempel samordnar information kan dessa säkerhetskopior behöva ändras för att säkerställa att informationen som dessa två tjänster bryr sig om efter återställningen är konsekvent.

    3. Ofta finns det några andra telemetri eller avgaser från tjänsten. Dessa metadata kan finnas i andra tjänster eller i loggar. Den här informationen kan användas vid behov för att avgöra om det fanns några anrop som togs emot och bearbetades på den primära som inte fanns i säkerhetskopian eller replikerades till den här repliken. Dessa anrop kan behöva spelas upp igen eller läggas till i säkerhetskopian innan återställningen är möjlig.

    4. Implementeringen jämför den återstående replikens tillstånd med det som finns i alla tillgängliga säkerhetskopior. Om du använder tillförlitliga Service Fabric-samlingar finns det verktyg och processer tillgängliga för detta. Målet är att se om tillståndet i repliken är tillräckligt och att se vad säkerhetskopian kan saknas.

    5. När jämförelsen är klar och när återställningen har slutförts (om det behövs) ska tjänstkoden returnera sant om några tillståndsändringar har gjorts. Om repliken fastslog att det var den bästa tillgängliga kopian av tillståndet och inte gjorde några ändringar returnerar koden falskt.

      Värdet true anger att alla andra återstående repliker nu kan vara inkonsekventa med den här. De tas bort och återskapas från den här repliken. Värdet false anger att inga tillståndsändringar har gjorts, så att de andra replikerna kan behålla det de har.

Det är mycket viktigt att tjänstförfattare övar potentiella dataförlust- och felscenarier innan tjänster distribueras i produktion. För att skydda mot risken för dataförlust är det viktigt att regelbundet säkerhetskopiera tillståndet för alla dina tillståndskänsliga tjänster till ett geo-redundant lager.

Du måste också se till att du har möjlighet att återställa tillståndet. Eftersom säkerhetskopior av många olika tjänster görs vid olika tidpunkter måste du se till att dina tjänster efter en återställning har en konsekvent vy över varandra.

Tänk dig till exempel en situation där en tjänst genererar ett tal och lagrar det och sedan skickar det till en annan tjänst som också lagrar det. Efter en återställning kan du upptäcka att den andra tjänsten har numret men inte den första, eftersom dess säkerhetskopia inte inkluderade den åtgärden.

Om du får reda på att de återstående replikerna inte är tillräckliga för att fortsätta i ett scenario med dataförlust och du inte kan rekonstruera tjänsttillståndet från telemetri eller avgaser, avgör säkerhetskopieringarnas frekvens ditt bästa möjliga mål för återställningspunkt (RPO). Service Fabric innehåller många verktyg för att testa olika felscenarier, inklusive permanent kvorum och dataförlust som kräver återställning från en säkerhetskopia. Dessa scenarier ingår som en del av testbarhetsverktygen i Service Fabric, som hanteras av felanalystjänsten. Mer information om dessa verktyg och mönster finns i Introduktion till tjänsten felanalys.

Anteckning

Systemtjänster kan också drabbas av kvorumförlust. Effekten är specifik för tjänsten i fråga. Till exempel påverkar kvorumförlust i namngivningstjänsten namnmatchning, medan kvorumförlust i redundanshanteraren blockerar nya skapande och redundansväxlingar.

Service Fabric-systemtjänsterna följer samma mönster som dina tjänster för tillståndshantering, men vi rekommenderar inte att du försöker flytta dem från kvorumförlust och till potentiell dataförlust. I stället rekommenderar vi att du söker stöd för att hitta en lösning som är riktad mot din situation. Det är vanligtvis bättre att bara vänta tills de nedreplikerna returneras.

Felsöka kvorumförlust

Repliker kan vara nere tillfälligt på grund av ett tillfälligt fel. Vänta en stund när Service Fabric försöker ta upp dem. Om replikerna har varit nere i mer än en förväntad tid följer du dessa felsökningsåtgärder:

  • Repliker kanske kraschar. Kontrollera hälsorapporter på repliknivå och dina programloggar. Samla in kraschdumpar och vidta nödvändiga åtgärder för att återställa.
  • Replikprocessen kan ha slutat svara. Kontrollera detta genom att granska programloggarna. Samla in processdumpar och stoppa sedan processen som inte svarar. Service Fabric skapar en ersättningsprocess och försöker återställa repliken.
  • Noder som är värdar för replikerna kan vara nere. Starta om den underliggande virtuella datorn för att aktivera noderna.

Ibland kanske det inte går att återställa repliker. Enheterna har till exempel misslyckats eller så svarar inte datorerna fysiskt. I dessa fall måste Service Fabric uppmanas att inte vänta på replikåterställning.

Använd inte dessa metoder om potentiell dataförlust är oacceptabel för att få tjänsten online. I så fall bör alla ansträngningar göras för att återställa fysiska datorer.

Följande åtgärder kan resultera i dataförlust. Kontrollera innan du följer dem.

Anteckning

Det är aldrig säkert att använda dessa metoder på annat sätt än på ett riktat sätt mot specifika partitioner.

  • Använd API:et Repair-ServiceFabricPartition -PartitionId eller System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) . Med det här API:et kan du ange partitionens ID för att flytta från kvorumförlust och till potentiell dataförlust.
  • Om klustret stöter på frekventa fel som gör att tjänster hamnar i ett kvorumförlusttillstånd och potentiell dataförlust är acceptabelt, kan det hjälpa tjänsten att återställas genom att ange ett lämpligt QuorumLossWaitDuration-värde . Service Fabric väntar på det angivna QuorumLossWaitDuration värdet (standardvärdet är oändligt) innan återställningen utförs. Vi rekommenderar inte den här metoden eftersom den kan orsaka oväntade dataförluster.

Tillgänglighet för Service Fabric-klustret

I allmänhet är Service Fabric-klustret en mycket distribuerad miljö utan enskilda felpunkter. Ett fel på en nod orsakar inte tillgänglighets- eller tillförlitlighetsproblem för klustret, främst på grund av att Service Fabric-systemtjänsterna följer samma riktlinjer som tidigare. Det vill säga att de alltid körs med tre eller flera repliker som standard och systemtjänster som är tillståndslösa körs på alla noder.

De underliggande Service Fabric-nätverken och felidentifieringsskikten är helt distribuerade. De flesta systemtjänster kan återskapas från metadata i klustret eller veta hur de synkroniserar om sitt tillstånd från andra platser. Tillgängligheten för klustret kan komprometteras om systemtjänsterna hamnar i kvorumförlustsituationer som de som beskrevs tidigare. I dessa fall kanske du inte kan utföra vissa åtgärder i klustret (som att starta en uppgradering eller distribuera nya tjänster), men själva klustret är fortfarande igång.

Tjänster i ett kluster som körs fortsätter att köras under dessa förhållanden om de inte kräver skrivningar till systemtjänsterna för att fortsätta fungera. Om redundanshanteraren till exempel har kvorumförlust fortsätter alla tjänster att köras. Men tjänster som misslyckas kan inte startas om automatiskt, eftersom detta kräver att Redundanshanteraren deltar.

Fel i ett datacenter eller en Azure-region

I sällsynta fall kan ett fysiskt datacenter bli tillfälligt otillgängligt på grund av strömavbrott eller nätverksanslutningar. I dessa fall är dina Service Fabric-kluster och -tjänster i det datacentret eller Azure-regionen otillgängliga. Dina data bevaras dock.

För kluster som körs i Azure kan du visa uppdateringar om avbrott på azure-statussidan. Om det är högst osannolikt att ett fysiskt datacenter delvis eller fullständigt förstörs kan alla Service Fabric-kluster som finns där eller tjänsterna i dem gå förlorade. Den här förlusten omfattar alla tillstånd som inte säkerhetskopieras utanför datacentret eller regionen.

Det finns flera olika strategier för att överleva det permanenta eller varaktiga felet för ett enskilt datacenter eller en enda region:

  • Kör separata Service Fabric-kluster i flera sådana regioner och använd någon mekanism för redundans och återställning efter fel mellan dessa miljöer. Den här typen av aktiv/aktiv/passiv modell med flera kluster kräver ytterligare hanterings- och driftkod. Den här modellen kräver också samordning av säkerhetskopior från tjänsterna i ett datacenter eller en region så att de är tillgängliga i andra datacenter eller regioner när ett fel uppstår.

  • Kör ett enda Service Fabric-kluster som sträcker sig över flera datacenter. Den minsta konfiguration som stöds för den här strategin är tre datacenter. Mer information finns i Distribuera ett Service Fabric-kluster över Tillgänglighetszoner.

    Den här modellen kräver ytterligare konfiguration. Fördelen är dock att fel i ett datacenter konverteras från en katastrof till ett normalt fel. Dessa fel kan hanteras av de mekanismer som fungerar för kluster inom en enda region. Feldomäner, uppgraderingsdomäner och Service Fabric-placeringsregler säkerställer att arbetsbelastningar distribueras så att de tolererar normala fel.

    Mer information om principer som kan hjälpa dig att driva tjänster i den här typen av kluster finns i Placeringsprinciper för Service Fabric-tjänster.

  • Kör ett enda Service Fabric-kluster som sträcker sig över flera regioner med hjälp av den fristående modellen. Det rekommenderade antalet regioner är tre. Mer information om fristående Service Fabric-konfiguration finns i Skapa ett fristående kluster .

Slumpmässiga fel som leder till klusterfel

Service Fabric har begreppet startvärdesnoder. Det här är noder som upprätthåller tillgängligheten för det underliggande klustret.

Startvärdesnoder hjälper till att säkerställa att klustret stannar kvar genom att upprätta lån med andra noder och fungera som tiebreakers vid vissa typer av fel. Om slumpmässiga fel tar bort en majoritet av startvärdesnoderna i klustret och de inte tas tillbaka snabbt, stängs klustret automatiskt av. Klustret misslyckas sedan.

I Azure hanterar Service Fabric-resursprovidern Service Fabric-klusterkonfigurationer. Som standard distribuerar resursprovidern startvärdesnoder mellan fel- och uppgraderingsdomäner för den primära nodtypen. Om den primära nodtypen är markerad som silver- eller guldhållbarhet försöker klustret att höja upp en annan nod som inte är seed-nod från den primära nodtypens tillgängliga kapacitet när du tar bort en startvärdesnod (antingen genom att skala i din primära nodtyp eller genom att ta bort den manuellt). Det här försöket misslyckas om du har mindre tillgänglig kapacitet än vad klustrets tillförlitlighetsnivå kräver för din primära nodtyp.

I både fristående Service Fabric-kluster och Azure är den primära nodtypen den som kör fröna. När du definierar en primär nodtyp drar Service Fabric automatiskt nytta av antalet noder som tillhandahålls genom att skapa upp till nio startvärdesnoder och sju repliker av varje systemtjänst. Om en uppsättning slumpmässiga fel tar ut en majoritet av dessa repliker samtidigt går systemtjänsterna till kvorumförlust. Om en majoritet av startvärdesnoderna går förlorade stängs klustret av strax därefter.

Nästa steg