Säkerhetskopiera och återställa Reliable Services och Reliable Actors

Azure Service Fabric är en plattform med hög tillgänglighet som replikerar tillståndet över flera noder för att upprätthålla den här höga tillgängligheten. Även om en nod i klustret misslyckas fortsätter tjänsterna att vara tillgängliga. Även om den här inbyggda redundansen som tillhandahålls av plattformen kan vara tillräcklig för vissa, är det i vissa fall önskvärt att tjänsten säkerhetskopierar data (till ett externt lager).

Kommentar

Det är viktigt att säkerhetskopiera och återställa dina data (och testa att de fungerar som förväntat) så att du kan återställa från dataförlustscenarier.

Kommentar

Microsoft rekommenderar att du använder regelbunden säkerhetskopiering och återställning för att konfigurera säkerhetskopiering av tillförlitliga tillståndskänsliga tjänster och Reliable Actors.

En tjänst kanske till exempel vill säkerhetskopiera data för att skydda mot följande scenarier:

• I händelse av permanent förlust av ett helt Service Fabric-kluster.
• Permanent förlust av en majoritet av replikerna i en tjänstpartition
• Administrativa fel där tillståndet oavsiktligt tas bort eller skadas. Detta kan till exempel inträffa om en administratör med tillräcklig behörighet felaktigt tar bort tjänsten.
• Buggar i tjänsten som orsakar skadade data. Detta kan till exempel inträffa när en uppgradering av tjänstkoden börjar skriva felaktiga data till en tillförlitlig samling. I sådana fall kan både koden och data behöva återställas till ett tidigare tillstånd.
• Databearbetning offline. Det kan vara praktiskt att arbeta offline med data för business intelligence som sker separat från den tjänst som genererar data.

Med funktionen Säkerhetskopiering/återställning kan tjänster som bygger på Reliable Services-API:et skapa och återställa säkerhetskopior. Api:erna för säkerhetskopiering som tillhandahålls av plattformen tillåter säkerhetskopiering av en tjänstpartitions tillstånd, utan att blockera läs- eller skrivåtgärder. Återställnings-API:erna tillåter att en tjänstpartitions tillstånd återställs från en vald säkerhetskopia.

Typer av säkerhetskopiering

Det finns två alternativ för säkerhetskopiering: Fullständig och Inkrementell. En fullständig säkerhetskopia är en säkerhetskopia som innehåller alla data som krävs för att återskapa replikens tillstånd: kontrollpunkter och alla loggposter. Eftersom den har kontrollpunkterna och loggen kan en fullständig säkerhetskopia återställas av sig själv.

Problemet med fullständiga säkerhetskopior uppstår när kontrollpunkterna är stora. En replik som till exempel har 16 GB tillstånd har kontrollpunkter som uppgår till cirka 16 GB. Om vi har ett mål för återställningspunkt på fem minuter måste repliken säkerhetskopieras var femte minut. Varje gång den säkerhetskopierar måste den kopiera 16 GB kontrollpunkter utöver 50 MB (kan konfigureras med hjälp CheckpointThresholdInMBav ) loggar.

Lösningen på det här problemet är inkrementella säkerhetskopior, där säkerhetskopiering endast innehåller de ändrade loggposterna sedan den senaste säkerhetskopieringen.

Eftersom inkrementella säkerhetskopior bara är ändringar sedan den senaste säkerhetskopieringen (inkluderar inte kontrollpunkterna) tenderar de att vara snabbare men de kan inte återställas på egen hand. För att återställa en inkrementell säkerhetskopia krävs hela säkerhetskopieringskedjan. En säkerhetskopieringskedja är en kedja av säkerhetskopior som börjar med en fullständig säkerhetskopia och följs av ett antal sammanhängande inkrementella säkerhetskopior.

Säkerhetskopiera Reliable Services

Tjänstförfattaren har fullständig kontroll över när säkerhetskopior ska göras och var säkerhetskopior ska lagras.

För att starta en säkerhetskopia måste tjänsten anropa den ärvda medlemsfunktionen BackupAsync.
Säkerhetskopior kan endast göras från primära repliker och de kräver att skrivstatus beviljas.

Som visas nedan BackupAsync , tar in ett BackupDescription objekt, där man kan ange en fullständig eller inkrementell säkerhetskopia, samt en återanropsfunktion, Func<< BackupInfo, CancellationToken, Task<bool>>> som anropas när mappen för säkerhetskopiering har skapats lokalt och är redo att flyttas ut till viss extern lagring.

BackupDescription myBackupDescription = new BackupDescription(BackupOption.Incremental,this.BackupCallbackAsync);

await this.BackupAsync(myBackupDescription);

Begäran om att göra en inkrementell säkerhetskopiering kan misslyckas med FabricMissingFullBackupException. Det här undantaget anger att något av följande händer:

• repliken har aldrig tagit en fullständig säkerhetskopia eftersom den har blivit primär,
• några av loggposterna sedan den senaste säkerhetskopieringen har trunkerats eller
• repliken passerade gränsen MaxAccumulatedBackupLogSizeInMB .

Användare kan öka sannolikheten för att kunna göra inkrementella säkerhetskopior genom att MinLogSizeInMB konfigurera eller TruncationThresholdFactor. Om du ökar dessa värden ökar diskanvändningen per replik. Mer information finns i Reliable Services Configuration

BackupInfo innehåller information om säkerhetskopieringen, inklusive platsen för mappen där körningen sparade säkerhetskopian (BackupInfo.Directory). Återanropsfunktionen kan flytta BackupInfo.Directory till ett externt arkiv eller en annan plats. Den här funktionen returnerar också en bool som anger om den kunde flytta säkerhetskopieringsmappen till målplatsen.

Följande kod visar hur BackupCallbackAsync metoden kan användas för att ladda upp säkerhetskopian till Azure Storage:

private async Task<bool> BackupCallbackAsync(BackupInfo backupInfo, CancellationToken cancellationToken)
{
    var backupId = Guid.NewGuid();

    await externalBackupStore.UploadBackupFolderAsync(backupInfo.Directory, backupId, cancellationToken);

    return true;
}

I föregående exempel ExternalBackupStore är exempelklassen som används för att gränssnitt med Azure Blob Storage, och UploadBackupFolderAsync är den metod som komprimerar mappen och placerar den i Azure Blob Store.

Tänk på följande:

• Det kan bara finnas en säkerhetskopieringsåtgärd under flygning per replik vid en viss tidpunkt. Fler än ett BackupAsync anrop i taget genererar FabricBackupInProgressException för att begränsa säkerhetskopior under upplysning till ett.
• Om en replik redundansväxlar medan en säkerhetskopia pågår kanske säkerhetskopieringen inte har slutförts. När redundansväxlingen är klar är det därför tjänstens ansvar att starta om säkerhetskopieringen genom att BackupAsync anropa vid behov.

Återställa Reliable Services

I allmänhet faller de fall då du kan behöva utföra en återställningsåtgärd i någon av följande kategorier:

• Tjänstpartitionen förlorade data. Disken för två av tre repliker för en partition (inklusive den primära repliken) skadas eller rensas till exempel. Den nya primära kan behöva återställa data från en säkerhetskopia.
• Hela tjänsten går förlorad. En administratör tar till exempel bort hela tjänsten och därmed måste tjänsten och data återställas.
• Tjänsten replikerade skadade programdata (till exempel på grund av ett programfel). I det här fallet måste tjänsten uppgraderas eller återställas för att ta bort orsaken till skadan och icke-skadade data måste återställas.

Många metoder är möjliga, men vi erbjuder några exempel på hur du kan återställa RestoreAsync från ovanstående scenarier.

Partitionsdataförlust i Reliable Services

I det här fallet skulle körningen automatiskt identifiera dataförlusten och anropa API:et OnDataLossAsync .

Tjänstförfattaren måste utföra följande för att återställa:

• Åsidosätt metoden OnDataLossAsyncför den virtuella basklassen .
• Hitta den senaste säkerhetskopian på den externa plats som innehåller tjänstens säkerhetskopior.
• Ladda ned den senaste säkerhetskopian (och avkomprimera säkerhetskopian till mappen backup om den komprimerades).
• Metoden OnDataLossAsync tillhandahåller en RestoreContext. Anropa API:et RestoreAsync på den angivna RestoreContext.
• Returnera sant om återställningen lyckades.

Följande är ett exempel på OnDataLossAsync en implementering av metoden:

protected override async Task<bool> OnDataLossAsync(RestoreContext restoreCtx, CancellationToken cancellationToken)
{
    var backupFolder = await this.externalBackupStore.DownloadLastBackupAsync(cancellationToken);

    var restoreDescription = new RestoreDescription(backupFolder);

    await restoreCtx.RestoreAsync(restoreDescription);

    return true;
}

RestoreDescription som skickas till anropet RestoreContext.RestoreAsync innehåller en medlem med namnet BackupFolderPath. När du återställer en enda fullständig säkerhetskopia bör detta BackupFolderPath anges till den lokala sökvägen till den mapp som innehåller din fullständiga säkerhetskopia. När du återställer en fullständig säkerhetskopia och ett antal inkrementella säkerhetskopior BackupFolderPath bör du ange den lokala sökvägen till mappen som inte bara innehåller den fullständiga säkerhetskopian, utan även alla inkrementella säkerhetskopior. RestoreAsync anrop kan utlösas FabricMissingFullBackupException om den BackupFolderPath angivna inte innehåller en fullständig säkerhetskopia. Den kan också utlösas ArgumentException om BackupFolderPath den har en bruten kedja av inkrementella säkerhetskopior. Om den till exempel innehåller den fullständiga säkerhetskopian, den första inkrementella och den tredje inkrementella säkerhetskopian men ingen andra inkrementell säkerhetskopiering.

Kommentar

RestorePolicy är inställt på Säker som standard. Det innebär att API:et RestoreAsync misslyckas med ArgumentException om det upptäcker att mappen backup innehåller ett tillstånd som är äldre än eller lika med det tillstånd som finns i den här repliken. RestorePolicy.Force kan användas för att hoppa över denna säkerhetskontroll. Detta anges som en del av RestoreDescription.

Borttagen eller förlorad tjänst

Om en tjänst tas bort måste du först återskapa tjänsten innan data kan återställas. Det är viktigt att skapa tjänsten med samma konfiguration, till exempel partitioneringsschema, så att data kan återställas sömlöst. När tjänsten är igång måste API:et för att återställa data (OnDataLossAsync ovan) anropas på varje partition i den här tjänsten. Ett sätt att uppnå detta är att använda FabricClient.TestManagementClient.StartPartitionDataLossAsync på varje partition.

Från och med nu är implementeringen densamma som i scenariot ovan. Varje partition måste återställa den senaste relevanta säkerhetskopian från det externa arkivet. En varning är att partitions-ID:t nu kan ha ändrats, eftersom körningen skapar partitions-ID:t dynamiskt. Därför måste tjänsten lagra lämplig partitionsinformation och tjänstnamn för att identifiera rätt senaste säkerhetskopia att återställa från för varje partition.

Kommentar

Vi rekommenderar inte att du använder FabricClient.ServiceManager.InvokeDataLossAsync på varje partition för att återställa hela tjänsten, eftersom det kan skada klustrets tillstånd.

Replikering av skadade programdata

Om den nyligen distribuerade programuppgradering har en bugg kan det orsaka skadade data. En programuppgradering kan till exempel börja uppdatera varje telefonnummerpost i en tillförlitlig ordlista med en ogiltig riktnummer. I det här fallet replikeras de ogiltiga telefonnumren eftersom Service Fabric inte känner till typen av data som lagras.

Det första du ska göra när du har upptäckt en sådan oerhörd bugg som orsakar skada på data är att frysa tjänsten på programnivå och, om möjligt, uppgradera till den version av programkoden som inte har felet. Men även efter att tjänstkoden har åtgärdats kan data fortfarande vara skadade och därför kan data behöva återställas. I sådana fall kanske det inte räcker att återställa den senaste säkerhetskopian, eftersom de senaste säkerhetskopiorna också kan vara skadade. Därför måste du hitta den senaste säkerhetskopian som gjordes innan data skadades.

Om du inte är säker på vilka säkerhetskopior som är skadade kan du distribuera ett nytt Service Fabric-kluster och återställa säkerhetskopiorna av berörda partitioner precis som i scenariot "Borttagen eller förlorad tjänst". För varje partition börjar du återställa säkerhetskopiorna från den senaste till minst. När du hittar en säkerhetskopia som inte har skadats flyttar/tar du bort alla säkerhetskopior av den här partitionen som var nyare (än den säkerhetskopian). Upprepa den här processen för varje partition. OnDataLossAsync När anropas på partitionen i produktionsklustret är den senaste säkerhetskopieringen som hittades i det externa arkivet den som valdes av ovanstående process.

Nu kan stegen i avsnittet "Borttagen eller förlorad tjänst" användas för att återställa tjänstens tillstånd till tillståndet innan buggykoden skadade tillståndet.

Tänk på följande:

• När du återställer finns det en risk att säkerhetskopieringen som återställs är äldre än partitionens tillstånd innan data förlorades. Därför bör du bara återställa som en sista utväg för att återställa så mycket data som möjligt.
• Strängen som representerar sökvägen för säkerhetskopieringsmappen och sökvägarna för filer i mappen för säkerhetskopiering kan vara större än 255 tecken, beroende på sökvägen FabricDataRoot och namnet på programtypen. Detta kan leda till att vissa .NET-metoder, till exempel Directory.Move, genererar PathTooLongException undantaget. En lösning är att direkt anropa kernel32-API:er, till exempel CopyFile.

Säkerhetskopiera och återställa Reliable Actors

Reliable Actors Framework bygger på Reliable Services. ActorService, som är värd för aktören eller aktören, är en tillståndskänslig tillförlitlig tjänst. Därför är alla funktioner för säkerhetskopiering och återställning som är tillgängliga i Reliable Services också tillgängliga för Reliable Actors (förutom beteenden som är specifika för tillståndsprovidern). Eftersom säkerhetskopieringar görs per partition säkerhetskopieras tillstånd för alla aktörer i partitionen (och återställningen är liknande och sker per partition). För att utföra säkerhetskopiering/återställning bör tjänstägaren skapa en anpassad aktörstjänstklass som härleds från klassen ActorService och sedan göra säkerhetskopiering/återställning som liknar Reliable Services enligt beskrivningen ovan i föregående avsnitt.

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo)
    {
    }
    
    //
    // Method overrides and other code.
    //
}

När du skapar en anpassad aktörstjänstklass måste du även registrera den när du registrerar aktören.

ActorRuntime.RegisterActorAsync<MyActor>(
    (context, typeInfo) => new MyCustomActorService(context, typeInfo)).GetAwaiter().GetResult();

Standardtillståndsprovidern för Reliable Actors är KvsActorStateProvider. Inkrementell säkerhetskopiering är inte aktiverat som standard för KvsActorStateProvider. Du kan aktivera inkrementell säkerhetskopiering genom att skapa KvsActorStateProvider med rätt inställning i konstruktorn och sedan skicka den till ActorService-konstruktorn enligt följande kodfragment:

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo, null, null, new KvsActorStateProvider(true)) // Enable incremental backup
    {
    }
    
    //
    // Method overrides and other code.
    //
}

När inkrementell säkerhetskopiering har aktiverats kan inkrementell säkerhetskopiering misslyckas med FabricMissingFullBackupException av någon av följande orsaker och du måste göra en fullständig säkerhetskopia innan du gör inkrementella säkerhetskopieringar:

• Repliken har aldrig tagit en fullständig säkerhetskopia sedan den blev primär.
• Några av loggposterna trunkerades sedan den senaste säkerhetskopieringen gjordes.

När inkrementell säkerhetskopiering är aktiverad KvsActorStateProvider använder inte cirkulär buffert för att hantera loggposterna och trunkerar den regelbundet. Om ingen säkerhetskopiering görs av användaren under en period av 45 minuter trunkerar systemet automatiskt loggposterna. Det här intervallet kan konfigureras genom att logTruncationIntervalInMinutes ange i KvsActorStateProvider konstruktorn (ungefär som när inkrementell säkerhetskopiering aktiveras). Loggposterna kan också trunkeras om den primära repliken behöver skapa en annan replik genom att skicka alla sina data.

När du återställer från en säkerhetskopieringskedja, liknande Reliable Services, bör BackupFolderPath innehålla underkataloger med en underkatalog som innehåller fullständig säkerhetskopiering och andra underkataloger som innehåller inkrementella säkerhetskopior. Återställnings-API:et genererar FabricException med lämpligt felmeddelande om verifieringen av säkerhetskopieringskedjan misslyckas.

Kommentar

KvsActorStateProvider ignorerar för närvarande alternativet RestorePolicy.Safe. Stöd för den här funktionen planeras i en kommande version.

Testa säkerhetskopiering och återställning

Det är viktigt att se till att kritiska data säkerhetskopieras och kan återställas från. Detta kan göras genom att anropa cmdleten Start-ServiceFabricPartitionDataLoss i PowerShell som kan leda till dataförlust i en viss partition för att testa om funktionerna för säkerhetskopiering och återställning av data för tjänsten fungerar som förväntat. Det är också möjligt att programmatiskt anropa dataförlust och återställning från den händelsen.

Kommentar

Du hittar en exempelimplementering av funktionerna för säkerhetskopiering och återställning i webbreferensappen på GitHub. Mer information finns i tjänsten Inventory.Service .

Under huven: mer information om säkerhetskopiering och återställning

Här är lite mer information om säkerhetskopiering och återställning.

Backup

Reliable State Manager ger möjlighet att skapa konsekventa säkerhetskopior utan att blockera läs- eller skrivåtgärder. För att göra det använder den en kontrollpunkts- och loggpersistencemekanism. Reliable State Manager tar fuzzy (lätta) kontrollpunkter på vissa punkter för att minska trycket från transaktionsloggen och förbättra återställningstiderna. När BackupAsync anropas instruerar Reliable State Manager alla Reliable-objekt att kopiera sina senaste kontrollpunktsfiler till en lokal säkerhetskopia. Sedan kopierar Reliable State Manager alla loggposter, från "startpekaren" till den senaste loggposten i mappen backup. Eftersom alla loggposter upp till den senaste loggposten ingår i säkerhetskopieringen och Reliable State Manager bevarar loggning framåt, garanterar Reliable State Manager att alla transaktioner som har checkats in (CommitAsync har returnerats) ingår i säkerhetskopieringen.

Alla transaktioner som checkar in efter BackupAsync har anropats kan eller kanske inte finns i säkerhetskopian. När den lokala säkerhetskopieringsmappen har fyllts i av plattformen (det vill säga lokal säkerhetskopiering slutförs av körningen) anropas tjänstens säkerhetskopieringsåteranrop. Det här återanropet ansvarar för att flytta säkerhetskopieringsmappen till en extern plats, till exempel Azure Storage.

Återställning

Reliable State Manager ger möjlighet att återställa från en säkerhetskopia med hjälp av API:et RestoreAsync .
Metoden RestoreAsync på RestoreContext kan bara anropas i OnDataLossAsync metoden. Bool som returneras av OnDataLossAsync anger om tjänsten återställde sitt tillstånd från en extern källa. Om returnerar OnDataLossAsync true återskapar Service Fabric alla andra repliker från den här primära filen. Service Fabric ser till att repliker som tar emot OnDataLossAsync anropet första övergången till den primära rollen men inte beviljas lässtatus eller skrivstatus. Detta innebär att för StatefulService-implementerare RunAsync anropas inte förrän OnDataLossAsync det har slutförts. OnDataLossAsync Sedan anropas den nya primära. Tills en tjänst har slutfört det här API:et (genom att returnera sant eller falskt) och slutför den relevanta omkonfigurationen fortsätter API:et att anropas en i taget.

RestoreAsync tar först bort allt befintligt tillstånd i den primära repliken som den anropades för. Sedan skapar Reliable State Manager alla reliable-objekt som finns i mappen backup. Sedan instrueras Reliable-objekten att återställa från sina kontrollpunkter i mappen backup. Slutligen återställer Reliable State Manager sitt eget tillstånd från loggposterna i mappen backup och utför återställning. Som en del av återställningsprocessen spelas åtgärder som börjar från den "startpunkt" som har checkade loggposter i mappen säkerhetskopiering upp till Reliable-objekten. Det här steget säkerställer att det återställda tillståndet är konsekvent.

Nästa steg

• Tillförlitliga samlingar
• Snabbstart för Reliable Services
• Reliable Services-meddelanden
• Konfiguration av Reliable Services
• Utvecklarreferens för Reliable Collections
• Regelbunden säkerhetskopiering och återställning i Azure Service Fabric