Haveriberedskap i Azure Service Fabric

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.

I den här artikeln beskrivs några vanliga fellägen som kan vara katastrofer om de inte modelleras och hanteras korrekt. Den beskriver också åtgärder som ska vidtas om en katastrof ändå inträffar. Målet är att begränsa eller eliminera risken för driftavbrott eller dataförlust när fel, planerade eller andra, 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

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

Om din tjänst till exempel bara körs på en dator är felet på 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 den tjänst 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 bekymrad över felet i ett SAN kan du köra över flera SAN-nätverk. Om du är orolig över förlusten av ett serverrack kan du köra över flera rack. Om du är orolig över datacentrets förlust bör din tjänst köras i flera Azure-regioner, över flera Azure-tillgänglighetszoner eller mellan 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 misslyckas) hanteras automatiskt och är därför inte längre en "katastrof".

Service Fabric finns mekanismer för att expandera klustret och hantera att ta tillbaka misslyckade noder och tjänster. Service Fabric också att köra många instanser av dina tjänster för att förhindra att oplanerade fel omvandlas 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 ta mer maskinvaruresurser än vad du är beredd 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. Var 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 om. I det här fallet förhindrar inte fler kopior katastrofen eftersom feltillståndet är korrelerat över alla instanser.

Driftfel

Även om tjänsten är över hela världen med många redundanser kan det fortfarande uppleva allvarliga händelser. Någon kan till exempel av misstag konfigurera om DNS-namnet för tjänsten eller ta bort det direkt.

Anta till exempel att du har en tillståndsfull tjänst Service Fabric och att någon har tagit bort den tjänsten av misstag. Om det inte finns någon annan åtgärd är tjänsten och hela tillståndet som den hade nu borta. Dessa typer av operativa katastrofer ("hoppsan") kräver olika åtgärder för återställning än vanliga, oplanerade fel.

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

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

Service Fabric funktioner för att förhindra driftfel, till exempel rollbaserad åtkomstkontroll för klusteråtgärder. De flesta av dessa driftfel kräver dock organisatoriskt arbete och andra system. Service Fabric tillhandahåller mekanismer för att klara driftfel, särskilt säkerhetskopiering och återställning av tillståndsful-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änster ha ytterligare kod. Andra typer av fel bör inte åtgärdas automatiskt av säkerhets- och affärskontinuier.

Hantera enskilda fel

Enskilda datorer kan misslyckas av alla typer av orsaker. Ibland beror det på maskinvaruorsaken, till exempel strömförsörjning och maskinvarufel i nätverket. Andra fel gäller programvara. Dessa omfattar 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 typ av tjänst resulterar körning av en enda instans i driftstopp för den tjänsten om den enskilda kopian av koden av någon anledning misslyckas.

Det enklaste du kan göra för att hantera ett enskilt fel är 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 InstanceCount är större än 1. För tillståndsful-tjänster är den minsta rekommendationen TargetReplicaSetSize att och båda är inställda på MinReplicaSetSize 3. Om du kör fler kopior av tjänstkoden säkerställer du att tjänsten kan hantera ett enskilt fel automatiskt.

Hantera koordinerade fel

Koordinerade fel i ett kluster kan bero på planerade eller oplanerade infrastrukturfel och ändringar eller planerade programvaruändringar. Service Fabric modeller infrastrukturzoner som drabbas av koordinerade fel som feldomäner. Områden som kommer att uppleva koordinerade programvaruändringar modelleras som uppgraderingsdomäner. Mer information om feldomäner, uppgraderingsdomäner och klustertopologi finns i Describe a Service Fabric cluster by using Klusterresurshanteraren.

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 Service Fabric att dina tjänster körs över flera fel- och uppgraderingsdomäner så att tjänsterna förblir tillgängliga om planerade eller oplanerade ändringar inträffar.

Anta till exempel att fel på en strömkälla gör att alla datorer i ett rack misslyckas samtidigt. När flera kopior av tjänsten körs omvandlas förlusten av många datorer i feldomänfel till ett annat exempel på ett enskilt 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 en Service Fabric 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 din feldomänlayout på rätt sätt.

Uppgraderingsdomäner är användbara för modelleringsområden där programvara uppgraderas samtidigt. Därför definierar uppgraderingsdomäner ofta även gränserna där programvara tas ned 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 din tjänst finns i:

• Programuppgradering
• Självstudie om programuppgradering
• Service Fabric hälsomodell

Du kan visualisera layouten för klustret med hjälp av klusterkartan som finns i Service Fabric Explorer:

Hantera samtidiga maskinvaru- eller programvarufel

Vi har talat om enskilda fel. Som du ser är de enkla att hantera för både tillståndslösa och tillståndslösa tjänster genom att se till att fler kopior av koden (och tillståndet) körs över fel- och uppgraderingsdomäner.

Flera samtidiga slumpmässiga fel kan också inträffa. Det är mer troligt att detta leder till driftstopp eller en faktisk katastrof.

Tillståndslösa tjänster

Antalet instanser för en tillståndslös tjänst anger önskat antal instanser som måste köras. När någon (eller alla) av instanserna misslyckas 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 det önskade instansantalet.

Anta till exempel att den tillståndslösa tjänsten har InstanceCount värdet -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 Service Fabric att tjänsten inte är i önskat tillstånd och försöker skapa instanserna på noderna där de saknas.

Tillståndsful-tjänster

Det finns två typer av tillståndsful-tjänster:

• Tillståndsfull med bestående tillstånd.
• Tillståndsful med icke-bestående tillstånd. (Tillstånd lagras i minnet.)

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

I en tillståndsfull tjänst replikeras inkommande data mellan repliker (den primära och alla aktiva secondaries). Om en majoritet av replikerna tar emot data betraktas data som kvorum intvorum. (För fem repliker är tre ett kvorum.) Det innebär att det alltid finns minst ett kvorum med repliker med 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 repliker fortfarande fungerar är det garanterat att minst en replik har fullständiga data.)

När ett kvorum med repliker misslyckas deklareras partitionen som i ett kvorumförlusttillstånd. Säg 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. I fall Service Fabric identifierar kvorumförlust är standardbeteendet att förhindra ytterligare skrivningar till partitionen, deklarera kvorumförlust och vänta tills ett kvorum med repliker återställs.

Att avgöra om en katastrof inträffade för en tillståndsfull tjänst och sedan hantera den följer tre steg:

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

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

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

   I de flesta fall är felen tillfälliga. Processer startas om, noder startas om, virtuella datorer startas om och nätverkspartitioner helas. Ibland är dock fel permanenta. Om felen är permanenta eller inte beror på om den tillståndsfulla tjänsten bevarar sitt tillstånd eller om den bara finns i minnet:

   • För tjänster utan bestående 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åndsful 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 Service Fabric vet att det inte finns någon anledning 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-beständiga natur.
   • För tillståndsful persistenta tjänster orsakar ett fel i ett kvorum eller flera repliker Service Fabric vänta tills replikerna kommer tillbaka och återställa kvorum. Detta resulterar i ett tjänstavbrott för skrivningar till den berörda partitionen (eller "replikuppsättningen") av 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ändlig, eftersom det är en (potentiell) dataförlusthändelse som medför andra risker. Det innebär att Service Fabric inte går vidare 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ällas från säkerhetskopior.

   Om kvorumförlust har deklarerats (antingen automatiskt eller via administrativ åtgärd) Service Fabric tjänsterna vidare till att avgöra om data faktiskt gick förlorade. Nu vet Service Fabric även att de andra replikerna inte kommer tillbaka. Det var beslutet som togs när vi slutade vänta på att kvorumförlusten skulle lösas. Den bästa åtgärden för tjänsten är vanligtvis att låsa och vänta på en viss administrativ åtgärd.

   När Service Fabric anropar OnDataLossAsync metoden beror det alltid på misstänkt dataförlust. Service Fabric ser till att 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 när kvorumet 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 OnDataLossAsync som har utlösts och utlöser eventuella administrativa aviseringar.

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

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

   3. Det finns ofta någon annan telemetri eller uttömning från tjänsten. Dessa metadata kan finnas i andra tjänster eller i loggar. Den här informationen kan användas efter behov för att avgöra om det fanns några anrop som tagits emot och bearbetats på den primära som inte fanns i säkerhetskopian eller replikerades till den här specifika 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 en Service Fabric samlingar finns det verktyg och processer tillgängliga för att göra det. Målet är att se om tillståndet i repliken är tillräckligt och för att se vad säkerhetskopian kan saknas för.

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

      Värdet true anger att 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å de andra replikerna kan behålla det de har.

Det är ytterst viktigt att tjänstförfattare övar på 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 backa upp tillståndet för någon av dina tillståndsfula 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 tas vid olika tidpunkter måste du se till att dina tjänster har en konsekvent vy över varandra efter en återställning.

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 kanske du upptäcker att den andra tjänsten har numret, men den första inte, eftersom dess säkerhetskopiering inte innehåller den åtgärden.

Om du upptäcker 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 uttömning avgör säkerhetskopieringsfrekvensen ditt bästa möjliga mål för återställningspunkt (RPO). Service Fabric 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. De här scenarierna 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 felanalystjänsten.

Felsöka kvorumförlust

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

• Repliker kan krascha. Kontrollera hälsorapporter på repliknivå och programloggarna. Samla in kraschdumpar och vidta nödvändiga åtgärder för att återställa.
• Replikprocessen kan ha sluta svara. Kontrollera programloggarna för att kontrollera detta. Samla in processdumpar och stoppa sedan processen som inte svarar. Service Fabric skapar en ersättningsprocess och försöker ta repliken tillbaka.
• Noderna som är värdar för replikerna kan vara nere. Starta om den underliggande virtuella datorn för att starta om 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 Service Fabric du bli tillsagd att inte vänta på replikåterställning.

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

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

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

Tillgänglighet för Service Fabric kluster

I allmänhet är Service Fabric en starkt distribuerad miljö utan enskilda felpunkter. Ett fel på en nod orsakar inte tillgänglighets- eller tillförlitlighetsproblem för klustret, främst eftersom Service Fabric-systemtjänsterna följer samma riktlinjer som tidigare. Det innebär 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ätverks- och felidentifieringslager är fullständigt distribuerade. De flesta systemtjänster kan återskapas från metadata i klustret eller veta hur de ska synkronisera om tillståndet från andra platser. Tillgängligheten för klustret kan bli komprometterad om systemtjänsterna får kvorumförlustsituationer som de som beskrivs ovan. I dessa fall kanske du inte kan utföra vissa åtgärder på klustret (t.ex. 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 att fungera. Om du till exempel Redundanshanteraren kvorumförlust fortsätter alla tjänster att köras. Men alla tjänster som misslyckas kommer inte att kunna starta om automatiskt, eftersom detta kräver inblandning av Redundanshanteraren.

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ätverksanslutning. I dessa fall är 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 ett fysiskt datacenter helt eller delvis 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 det datacentret eller den regionen.

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

• Kör separata Service Fabric 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 havererar.

• Kör ett enskilt Service Fabric 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 haveri i ett datacenter konverteras från en katastrof till ett normalt fel. De här felen kan hanteras av mekanismerna 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 hantera tjänster i den här typen av kluster finns i Placeringsprinciper för Service Fabric tjänster.

• Kör ett enskilt Service Fabric som sträcker sig över flera regioner med hjälp av den fristående modellen. Det rekommenderade antalet regioner är tre. Se Skapa ett fristående kluster för information om fristående Service Fabric installationsprogrammet.

Slumpmässiga fel som leder till klusterfel

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

Startnoder hjälper till att säkerställa att klustret håller sig upp genom att upprätta lån med andra noder och fungerar som tiebreakers vid vissa typer av fel. Om slumpmässiga fel tar bort en majoritet av start seed-noderna 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 över fel- och uppgraderingsdomäner för den primära nodtypen. Om den primära nodtypen har markerats som Silver- eller Guld-hållbarhet försöker klustret att höja upp en annan nod som inte är seed från den primära nodtypens tillgängliga kapacitet när du tar bort en startpunktsnod (antingen genom att skala in den primära nodtypen eller genom att ta bort den manuellt). Det här försöket misslyckas om du har mindre tillgänglig kapacitet än klustrets tillförlitlighetsnivå kräver för din primära nodtyp.

I både fristående Service Fabric och Azure är den primära nodtypen den som kör kärnorna. När du definierar en primär nodtyp Service Fabric automatiskt det antal noder som tillhandahålls genom att skapa upp till nio startpunktsnoder 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 in i kvorumförlust. Om en majoritet av start seed-noderna går förlorade stängs klustret av strax efter.

Nästa steg

• Lär dig hur du simulerar olika fel med hjälp av testbarhetsramverket.
• Läs andra resurser för haveriberedskap och hög tillgänglighet. Microsoft har publicerat en stor mängd vägledning om dessa ämnen. Även om vissa av dessa resurser refererar till specifika tekniker för användning i andra produkter innehåller de många allmänna metodtips som du kan använda i Service Fabric kontexten:
  • Tillgänglighetschecklista
  • Utföra ett haveriberedskapsgranskning
  • Haveriberedskap och hög tillgänglighet för Azure-program
• Läs mer Service Fabric om supportalternativen.