Delen via

Back-up maken en herstellen van Reliable Services en Reliable Actors

  • Artikel

Azure Service Fabric is een platform voor hoge beschikbaarheid dat de status repliceert over meerdere knooppunten om deze hoge beschikbaarheid te behouden. Dus zelfs als één knooppunt in het cluster mislukt, blijven de services beschikbaar. Hoewel deze ingebouwde redundantie van het platform mogelijk voldoende is voor sommige, is het in bepaalde gevallen wenselijk dat de service een back-up maakt van gegevens (naar een extern archief).

Notitie

Het is essentieel dat u een back-up maakt van uw gegevens en deze herstelt (en test of deze werkt zoals verwacht), zodat u kunt herstellen vanuit scenario's voor gegevensverlies.

Notitie

Microsoft raadt aan periodieke back-up en herstel te gebruiken voor het configureren van gegevensback-up van Reliable Stateful-services en Reliable Actors.

Een service kan bijvoorbeeld een back-up van gegevens maken om te beschermen tegen de volgende scenario's:

  • In het geval van permanent verlies van een volledig Service Fabric-cluster.
  • Permanent verlies van een meerderheid van de replica's van een servicepartitie
  • Administratieve fouten waardoor de status per ongeluk wordt verwijderd of beschadigd. Dit kan bijvoorbeeld gebeuren als een beheerder met voldoende bevoegdheden de service ten onrechte verwijdert.
  • Fouten in de service die beschadiging van gegevens veroorzaken. Dit kan bijvoorbeeld gebeuren wanneer een servicecode-upgrade begint met het schrijven van foutieve gegevens naar een betrouwbare verzameling. In dat geval moeten zowel de code als de gegevens mogelijk worden teruggezet naar een eerdere status.
  • Offline gegevensverwerking. Het kan handig zijn om offline gegevens te verwerken voor business intelligence die afzonderlijk plaatsvinden van de service waarmee de gegevens worden gegenereerd.

Met de functie Back-up/herstel kunnen services die zijn gebouwd op de Reliable Services-API back-ups maken en herstellen. De back-up-API's van het platform staan back-ups van de status van een servicepartitie toe, zonder lees- of schrijfbewerkingen te blokkeren. Met de herstel-API's kan de status van een servicepartitie worden hersteld vanuit een gekozen back-up.

Typen back-up

Er zijn twee back-upopties: Volledig en Incrementeel. Een volledige back-up is een back-up die alle gegevens bevat die nodig zijn om de status van de replica opnieuw te maken: controlepunten en alle logboekrecords. Omdat het controlepunten en het logboek bevat, kan een volledige back-up zelf worden hersteld.

Het probleem met volledige back-ups ontstaat wanneer de controlepunten groot zijn. Een replica met een status van 16 GB heeft bijvoorbeeld controlepunten die ongeveer 16 GB bedragen. Als we een herstelpuntdoelstelling van vijf minuten hebben, moet er om de vijf minuten een back-up van de replica worden gemaakt. Telkens wanneer er een back-up wordt gemaakt, moet 16 GB aan controlepunten worden gekopieerd naast 50 MB (configureerbaar met behulp van CheckpointThresholdInMB) logboeken.

Voorbeeld van volledige back-up.

De oplossing voor dit probleem zijn incrementele back-ups, waarbij back-ups alleen de gewijzigde logboekrecords bevatten sinds de laatste back-up.

Voorbeeld van incrementele back-up.

Omdat incrementele back-ups alleen wijzigingen zijn sinds de laatste back-up (inclusief de controlepunten), zijn ze meestal sneller, maar kunnen ze niet zelfstandig worden hersteld. Als u een incrementele back-up wilt herstellen, is de volledige back-upketen vereist. Een back-upketen is een keten van back-ups die beginnen met een volledige back-up en gevolgd door een aantal aaneengesloten incrementele back-ups.

Back-up van Reliable Services

De auteur van de service heeft volledige controle over wanneer back-ups moeten worden gemaakt en waar back-ups worden opgeslagen.

Als u een back-up wilt starten, moet de service de overgenomen lidfunctie BackupAsyncaanroepen.
Back-ups kunnen alleen worden gemaakt van primaire replica's en ze vereisen dat de schrijfstatus wordt verleend.

Zoals hieronder wordt weergegeven, BackupAsync neemt u een BackupDescription object op, waar u een volledige of incrementele back-up kunt opgeven, evenals een callback-functie, Func<< BackupInfo, CancellationToken, Task<bool>>> die wordt aangeroepen wanneer de back-upmap lokaal is gemaakt en klaar is om naar een externe opslag te worden verplaatst.


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

await this.BackupAsync(myBackupDescription);

De aanvraag voor het maken van een incrementele back-up kan mislukken met FabricMissingFullBackupException. Deze uitzondering geeft aan dat een van de volgende dingen gebeurt:

  • de replica heeft nooit een volledige back-up gemaakt omdat deze primair is geworden,
  • sommige logboekrecords sinds de laatste back-up is afgekapt of
  • replica heeft de MaxAccumulatedBackupLogSizeInMB limiet doorgegeven.

Gebruikers kunnen de kans vergroten dat incrementele back-ups kunnen worden uitgevoerd door deze MinLogSizeInMB te configureren of TruncationThresholdFactor. Als u deze waarden verhoogt, wordt het gebruik per replicaschijf verhoogd. Zie Reliable Services-configuratie voor meer informatie

BackupInfo bevat informatie over de back-up, inclusief de locatie van de map waarin de runtime de back-up heeft opgeslagen (BackupInfo.Directory). De callback-functie kan de BackupInfo.Directory functie verplaatsen naar een externe winkel of een andere locatie. Deze functie retourneert ook een bool die aangeeft of de back-upmap naar de doellocatie is verplaatst.

De volgende code laat zien hoe de BackupCallbackAsync methode kan worden gebruikt om de back-up te uploaden naar Azure Storage:

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

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

    return true;
}

In het voorgaande voorbeeld ExternalBackupStore is dit de voorbeeldklasse die wordt gebruikt om te interfacen met Azure Blob Storage en UploadBackupFolderAsync is dit de methode waarmee de map wordt gecomprimeerd en in het Azure Blob-archief wordt geplaatst.

Opmerking:

  • Er kan op elk gewenst moment slechts één back-upbewerking per replica worden uitgevoerd. Er wordt meer dan één BackupAsync aanroep tegelijk gegooid FabricBackupInProgressException om de inflight back-ups te beperken tot één aanroep.
  • Als een failover van een replica wordt uitgevoerd terwijl er een back-up wordt uitgevoerd, is de back-up mogelijk niet voltooid. Zodra de failover is voltooid, is het de verantwoordelijkheid van de service om de back-up opnieuw op te starten door deze indien nodig aan te BackupAsync roepen.

Reliable Services herstellen

In het algemeen vallen de gevallen waarin u mogelijk een herstelbewerking moet uitvoeren in een van deze categorieën:

  • De servicepartitie is verloren gegevens. De schijf voor twee van de drie replica's voor een partitie (inclusief de primaire replica) wordt bijvoorbeeld beschadigd of gewist. Mogelijk moet de nieuwe primaire gegevens herstellen vanuit een back-up.
  • De hele service gaat verloren. Een beheerder verwijdert bijvoorbeeld de hele service en dus de service en de gegevens moeten worden hersteld.
  • De service heeft beschadigde toepassingsgegevens gerepliceerd (bijvoorbeeld vanwege een toepassingsfout). In dit geval moet de service worden bijgewerkt of teruggezet om de oorzaak van de beschadiging te verwijderen en moeten niet-beschadigde gegevens worden hersteld.

Hoewel veel benaderingen mogelijk zijn, bieden we enkele voorbeelden voor het herstellen RestoreAsync van de bovenstaande scenario's.

Gegevensverlies partitioneren in Reliable Services

In dit geval detecteert de runtime automatisch het gegevensverlies en roept de OnDataLossAsync API aan.

De auteur van de service moet het volgende uitvoeren om te herstellen:

  • Overschrijf de methode van OnDataLossAsyncde virtuele basisklasse.
  • Zoek de meest recente back-up op de externe locatie die de back-ups van de service bevat.
  • Download de meest recente back-up (en verwijder de back-up in de back-upmap als deze is gecomprimeerd).
  • De OnDataLossAsync methode biedt een RestoreContext. Roep de RestoreAsync API aan op de opgegeven RestoreContext.
  • Retourneer waar als het herstel een succes was.

Hier volgt een voorbeeld van de implementatie van de OnDataLossAsync methode:

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 doorgegeven aan de oproep bevat een lid met de RestoreContext.RestoreAsync naam BackupFolderPath. Wanneer u één volledige back-up herstelt, moet dit BackupFolderPath worden ingesteld op het lokale pad van de map die uw volledige back-up bevat. Wanneer u een volledige back-up en een aantal incrementele back-ups herstelt, BackupFolderPath moet u instellen op het lokale pad van de map die niet alleen de volledige back-up bevat, maar ook alle incrementele back-ups. RestoreAsync aanroep kan worden veroorzaakt FabricMissingFullBackupException als de BackupFolderPath opgegeven geen volledige back-up bevat. Het kan ook worden gegooid ArgumentException als BackupFolderPath er een verbroken keten van incrementele back-ups is. Als deze bijvoorbeeld de volledige back-up bevat, worden de eerste incrementele en de derde incrementele back-up, maar niet de tweede incrementele back-up.

Notitie

RestorePolicy is standaard ingesteld op Veilig. Dit betekent dat de RestoreAsync API mislukt met ArgumentException als wordt gedetecteerd dat de back-upmap een status bevat die ouder is dan of gelijk is aan de status in deze replica. RestorePolicy.Force kan worden gebruikt om deze veiligheidscontrole over te slaan. Dit wordt opgegeven als onderdeel van RestoreDescription.

Verwijderde of verloren service

Als een service wordt verwijderd, moet u eerst de service opnieuw maken voordat de gegevens kunnen worden hersteld. Het is belangrijk om de service te maken met dezelfde configuratie, bijvoorbeeld het partitioneringsschema, zodat de gegevens naadloos kunnen worden hersteld. Zodra de service is ingeschakeld, moet de API voor het herstellen van gegevens (OnDataLossAsync hierboven) worden aangeroepen op elke partitie van deze service. Een manier om dit te bereiken is door FabricClient.TestManagementClient.StartPartitionDataLossAsync op elke partitie te gebruiken.

Vanaf dit punt is de implementatie hetzelfde als in het bovenstaande scenario. Elke partitie moet de meest recente relevante back-up uit het externe archief herstellen. Een nadeel is dat de partitie-id nu mogelijk is gewijzigd, omdat de runtime partitie-id's dynamisch maakt. Daarom moet de service de juiste partitiegegevens en servicenaam opslaan om de juiste meest recente back-up te identificeren waaruit voor elke partitie moet worden hersteld.

Notitie

Het is niet raadzaam om op elke partitie te gebruiken FabricClient.ServiceManager.InvokeDataLossAsync om de hele service te herstellen, omdat dit de status van uw cluster kan beschadigen.

Replicatie van beschadigde toepassingsgegevens

Als de zojuist geïmplementeerde toepassingsupgrade een fout heeft, kan dit leiden tot beschadiging van gegevens. Een toepassingsupgrade kan bijvoorbeeld beginnen met het bijwerken van alle telefoonnummerrecords in een betrouwbare woordenlijst met een ongeldig netnummer. In dit geval worden de ongeldige telefoonnummers gerepliceerd omdat Service Fabric niet op de hoogte is van de aard van de gegevens die worden opgeslagen.

Het eerste wat u moet doen nadat u een dergelijke egregiofout hebt gedetecteerd die gegevensbeschadiging veroorzaakt, is door de service op toepassingsniveau te blokkeren en, indien mogelijk, een upgrade uit te voeren naar de versie van de toepassingscode die niet over de fout beschikt. Zelfs nadat de servicecode is opgelost, kunnen de gegevens echter nog steeds beschadigd zijn en moeten de gegevens dus mogelijk worden hersteld. In dergelijke gevallen is het mogelijk niet voldoende om de meest recente back-up te herstellen, omdat de meest recente back-ups mogelijk ook beschadigd zijn. U moet dus de laatste back-up vinden die is gemaakt voordat de gegevens zijn beschadigd.

Als u niet zeker weet welke back-ups beschadigd zijn, kunt u een nieuw Service Fabric-cluster implementeren en de back-ups van betrokken partities herstellen, net zoals in het bovenstaande scenario 'Verwijderde of verloren service'. Begin voor elke partitie met het herstellen van de back-ups van de meest recente naar het minst. Zodra u een back-up hebt gevonden die niet over de beschadiging beschikt, verplaatst/verwijdert u alle back-ups van deze partitie die recenter waren (dan die back-up). Herhaal dit proces voor elke partitie. OnDataLossAsync Wanneer de partitie in het productiecluster wordt aangeroepen, wordt de laatste back-up die in het externe archief is gevonden, gekozen door het bovenstaande proces.

Nu kunnen de stappen in de sectie Verwijderde of verloren service worden gebruikt om de status van de service te herstellen naar de status voordat de buggycode de status heeft beschadigd.

Opmerking:

  • Wanneer u herstelt, is er een kans dat de back-up die wordt hersteld ouder is dan de status van de partitie voordat de gegevens verloren zijn gegaan. Daarom moet u alleen herstellen als laatste redmiddel om zoveel mogelijk gegevens te herstellen.
  • De tekenreeks die het pad naar de back-upmap en de paden van bestanden in de back-upmap vertegenwoordigt, kan langer zijn dan 255 tekens, afhankelijk van het pad FabricDataRoot en de lengte van de naam van het toepassingstype. Dit kan ertoe leiden dat sommige .NET-methoden, zoals Directory.Move, de PathTooLongException uitzondering genereren. Een tijdelijke oplossing is om kernel32-API's rechtstreeks aan te roepen, zoals CopyFile.

Een back-up maken van Reliable Actors en deze herstellen

Reliable Actors Framework is gebouwd op Reliable Services. De ActorService, die als host fungeert voor de actor(s) is een stateful betrouwbare service. Daarom is alle functionaliteit voor back-up en herstel die beschikbaar is in Reliable Services ook beschikbaar voor Reliable Actors (met uitzondering van gedrag dat specifiek is voor de statusprovider). Omdat back-ups per partitie worden gemaakt, wordt voor alle actoren in die partitie een back-up gemaakt (en herstel is vergelijkbaar en vindt plaats per partitie). Als u back-up/herstel wilt uitvoeren, moet de service-eigenaar een aangepaste actorserviceklasse maken die is afgeleid van de ActorService-klasse en vervolgens back-up/herstel uitvoeren die vergelijkbaar is met Reliable Services, zoals hierboven beschreven in de vorige secties.

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

Wanneer u een aangepaste actorserviceklasse maakt, moet u deze ook registreren bij het registreren van de actor.

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

De standaardstatusprovider voor Reliable Actors is KvsActorStateProvider. Incrementele back-up is niet standaard ingeschakeld voor KvsActorStateProvider. U kunt incrementele back-ups inschakelen door deze te maken KvsActorStateProvider met de juiste instelling in de constructor en deze vervolgens door te geven aan actorserviceconstructor, zoals wordt weergegeven in het volgende codefragment:

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.
    //
}

Nadat incrementele back-ups zijn ingeschakeld, kan het maken van een incrementele back-up mislukken met FabricMissingFullBackupException om een van de volgende redenen en moet u een volledige back-up maken voordat u incrementele back-ups maakt:

  • De replica heeft nooit een volledige back-up gemaakt sinds deze primair werd.
  • Sommige logboekrecords zijn afgekapt sinds de laatste back-up is gemaakt.

Wanneer incrementele back-up is ingeschakeld, KvsActorStateProvider wordt geen circulaire buffer gebruikt om de logboekrecords te beheren en deze periodiek af te kapen. Als er gedurende een periode van 45 minuten geen back-up wordt gemaakt door de gebruiker, worden de logboekrecords automatisch afgekapt door het systeem. Dit interval kan worden geconfigureerd door de constructor KvsActorStateProvider op te logTruncationIntervalInMinutes geven (vergelijkbaar met het inschakelen van incrementele back-ups). De logboekrecords worden mogelijk ook afgekapt als primaire replica een andere replica moet bouwen door alle bijbehorende gegevens te verzenden.

Wanneer u herstel uitvoert vanuit een back-upketen, vergelijkbaar met Reliable Services, moet BackupFolderPath submappen bevatten met één submap met volledige back-up en andere submappen met incrementele back-ups. De herstel-API genereert FabricException met het juiste foutbericht als de validatie van de back-upketen mislukt.

Notitie

KvsActorStateProvider negeert momenteel de optie RestorePolicy.Safe. Ondersteuning voor deze functie is gepland in een toekomstige release.

Back-up en herstel testen

Het is belangrijk om ervoor te zorgen dat er een back-up van kritieke gegevens wordt gemaakt en kan worden hersteld. U kunt dit doen door de Start-ServiceFabricPartitionDataLoss cmdlet aan te roepen in PowerShell die gegevensverlies in een bepaalde partitie kan veroorzaken om te testen of de functionaliteit voor gegevensback-up en herstel voor uw service werkt zoals verwacht. Het is ook mogelijk om programmatisch gegevensverlies en herstel vanuit die gebeurtenis aan te roepen.

Notitie

U vindt een voorbeeld van een implementatie van back-up- en herstelfunctionaliteit in de Web Reference App op GitHub. Bekijk de Inventory.Service service voor meer informatie.

Onder de schermen: meer informatie over back-up en herstel

Hier vindt u meer informatie over back-up en herstel.

Backup

Reliable State Manager biedt de mogelijkheid om consistente back-ups te maken zonder lees- of schrijfbewerkingen te blokkeren. Hiervoor wordt gebruikgemaakt van een controlepunt en een mechanisme voor logboekpersistentie. De Reliable State Manager neemt fuzzy (lichtgewicht) controlepunten op bepaalde punten om de druk uit het transactionele logboek te verlichten en hersteltijden te verbeteren. Wanneer BackupAsync wordt aangeroepen, geeft Reliable State Manager alle betrouwbare objecten de opdracht om de meest recente controlepuntbestanden naar een lokale back-upmap te kopiëren. Vervolgens kopieert Reliable State Manager alle logboekrecords, beginnend vanaf de 'beginpunt' naar de meest recente logboekrecord in de back-upmap. Omdat alle logboekrecords tot de meest recente logboekrecord zijn opgenomen in de back-up en de Reliable State Manager write-ahead-logboekregistratie behoudt, garandeert Reliable State Manager dat alle transacties die zijn doorgevoerd (CommitAsync is geretourneerd) in de back-up zijn opgenomen.

Elke transactie die doorvoert nadat BackupAsync is aangeroepen, is al dan niet aanwezig in de back-up. Zodra de lokale back-upmap is ingevuld door het platform (dat wil gezegd, lokale back-up wordt voltooid door de runtime), wordt de back-upaanroep van de service aangeroepen. Deze callback is verantwoordelijk voor het verplaatsen van de back-upmap naar een externe locatie, zoals Azure Storage.

Herstellen

Reliable State Manager biedt de mogelijkheid om te herstellen vanuit een back-up met behulp van de RestoreAsync API.
De RestoreAsync methode kan RestoreContext alleen binnen de OnDataLossAsync methode worden aangeroepen. De bool die wordt geretourneerd door OnDataLossAsync geeft aan of de service de status van een externe bron heeft hersteld. Als de OnDataLossAsync waarde waar retourneert, worden in Service Fabric alle andere replica's van deze primaire replica opnieuw opgebouwd. Service Fabric zorgt ervoor dat replica's die de eerste overgang van de aanroep naar de primaire rol ontvangen OnDataLossAsync , maar geen leesstatus of schrijfstatus krijgen. Dit impliceert dat voor StatefulService-implementers RunAsync niet wordt aangeroepen totdat OnDataLossAsync deze is voltooid. OnDataLossAsync Vervolgens wordt deze aangeroepen op de nieuwe primaire. Totdat een service deze API heeft voltooid (door waar of onwaar te retourneren) en de relevante herconfiguratie is voltooid, wordt de API één voor één aangeroepen.

RestoreAsync verwijdert eerst alle bestaande status in de primaire replica waarop deze is aangeroepen. Vervolgens worden met Reliable State Manager alle betrouwbare objecten gemaakt die aanwezig zijn in de back-upmap. Vervolgens krijgen de betrouwbare objecten de opdracht om te herstellen vanaf hun controlepunten in de back-upmap. Ten slotte herstelt Reliable State Manager zijn eigen status uit de logboekrecords in de back-upmap en voert herstel uit. Als onderdeel van het herstelproces worden bewerkingen die beginnen vanaf het 'beginpunt' die vastgelegde logboekrecords in de back-upmap hebben, opnieuw afgespeeld naar de betrouwbare objecten. Deze stap zorgt ervoor dat de herstelde status consistent is.

Volgende stappen