Zálohování a obnovení Reliable Services a Reliable Actors

Azure Service Fabric je platforma s vysokou dostupností, která replikuje stav napříč několika uzly, aby byla tato vysoká dostupnost zachována. Takže i když jeden uzel v clusteru selže, budou služby dál dostupné. I když tato integrovaná redundance poskytovaná platformou může pro některé stačit, v některých případech je žádoucí, aby služba zálohovala data (do externího úložiště).

Například služba může chtít zálohovat data, aby se chránila před následujícími scénáři:

• V případě trvalé ztráty celého clusteru Service Fabric.
• Trvalá ztráta většiny replik oddílu služby
• Chyby správy, kdy se stát omylem odstraní nebo poškodí. K tomu může dojít například v případě, že správce s dostatečným oprávněním službu omylem odstraní.
• Chyby ve službě, které způsobují poškození dat K tomu může dojít například v případě, že upgrade kódu služby začne zapisovat chybná data do spolehlivé kolekce. V takovém případě může být nutné vrátit kód i data do dřívějšího stavu.
• Zpracování offline dat. Může být vhodné mít offline zpracování dat pro business intelligence, ke kterým dochází odděleně od služby, která generuje data.

Funkce Zálohování/obnovení umožňuje službám založeným na rozhraní API Reliable Services vytvářet a obnovovat zálohy. Rozhraní API zálohování poskytovaná platformou umožňují zálohování stavu oddílu služby bez blokování operací čtení nebo zápisu. Rozhraní API pro obnovení umožňují obnovení stavu oddílu služby z vybrané zálohy.

Typy zálohování

Existují dvě možnosti zálohování: úplné a přírůstkové. Úplná záloha je záloha, která obsahuje všechna data potřebná k opětovnému vytvoření stavu repliky: kontrolní body a všechny záznamy protokolu. Vzhledem k tomu, že obsahuje kontrolní body a protokol, můžete úplné zálohování obnovit sami.

Problém s úplnými zálohami nastane, když jsou kontrolní body velké. Například replika, která má 16 GB stavu, bude mít kontrolní body, které se sčítají přibližně do 16 GB. Pokud máme cíl bodu obnovení 5 minut, musí se replika zálohovat každých pět minut. Pokaždé, když zálohuje, musí zkopírovat 16 GB kontrolních bodů kromě 50 MB (konfigurovatelné pomocí CheckpointThresholdInMB) protokolů.

Řešením tohoto problému jsou přírůstkové zálohování, kde zálohování obsahuje pouze změněné záznamy protokolu od poslední zálohy.

Vzhledem k tomu, že přírůstkové zálohování jsou pouze změny od poslední zálohy (nezahrnuje kontrolní body), jsou obvykle rychlejší, ale nelze je obnovit sami. K obnovení přírůstkové zálohy se vyžaduje celý řetěz záloh. Řetěz záloh je řetěz záloh, který začíná úplným zálohováním a následuje řada souvislých přírůstkových záloh.

Backup Reliable Services

Autor služby má plnou kontrolu nad tím, kdy provádět zálohy a kde budou zálohy uloženy.

Pokud chcete spustit zálohu, musí služba vyvolat zděděnou členovou funkci BackupAsync.
Zálohy je možné vytvářet pouze z primárních replik a vyžadují udělení stavu zápisu.

Jak je znázorněno níže, BackupAsync přebírá BackupDescription objekt, kde může určit úplné nebo přírůstkové zálohování a funkci zpětného volání, Func<< BackupInfo, CancellationToken, Task<bool>>> která se vyvolá při místním vytvoření záložní složky a je připravená k přesunutí do některého externího úložiště.

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

await this.BackupAsync(myBackupDescription);

Požadavek na provedení přírůstkové zálohy může selhat s FabricMissingFullBackupException. Tato výjimka značí, že se děje jedna z následujících věcí:

• replika nikdy nezabrala úplnou zálohu, protože se stala primárním,
• některé záznamy protokolu od posledního zálohování byly zkráceny nebo
• replika prošla limitem MaxAccumulatedBackupLogSizeInMB .

Uživatelé mohou zvýšit pravděpodobnost, že budou moci provádět přírůstkové zálohování konfigurací MinLogSizeInMB nebo TruncationThresholdFactor. Zvýšením těchto hodnot se zvýší využití disku na repliku. Další informace naleznete v tématu Konfigurace Reliable Services

BackupInfo poskytuje informace týkající se zálohování, včetně umístění složky, do které modul runtime uložil zálohu (BackupInfo.Directory). Funkce zpětného BackupInfo.Directory volání může přesunout do externího úložiště nebo jiného umístění. Tato funkce také vrátí logickou hodnotu, která označuje, jestli byla schopna úspěšně přesunout záložní složku do cílového umístění.

Následující kód ukazuje, jak lze metodu BackupCallbackAsync použít k nahrání zálohy do Služby Azure Storage:

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

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

    return true;
}

V předchozím příkladu je ukázková třída, která se používá k rozhraní se službou Azure Blob Storage, a UploadBackupFolderAsync je to metoda, ExternalBackupStore která komprimuje složku a umístí ji do úložiště objektů blob Azure.

Poznámky:

• V každém okamžiku může na repliku existovat pouze jedna operace zálohování na každou repliku. Více než jedno BackupAsync volání najednou vyvolá omezení FabricBackupInProgressException letových záloh na jeden.
• Pokud replika převezme služby při selhání, zatímco probíhá zálohování, možná se zálohování nedokončilo. Jakmile se tedy převzetí služeb při selhání dokončí, je odpovědností služby restartovat zálohování vyvoláním BackupAsync podle potřeby.

Obnovení Reliable Services

Obecně platí, že případy, kdy může být potřeba provést operaci obnovení, spadají do jedné z těchto kategorií:

• Oddíl služby ztratil data. Například disk pro dva ze tří replik pro oddíl (včetně primární repliky) se poškodí nebo vymaže. Nová primární databáze může potřebovat obnovit data ze zálohy.
• Celá služba se ztratí. Správce například odebere celou službu, a proto je potřeba službu a data obnovit.
• Služba replikovala poškozená data aplikace (například kvůli chybě aplikace). V takovém případě musí být služba upgradována nebo vrácena, aby se odstranila příčina poškození a je nutné obnovit neškoděná data.

Mnoho přístupů je sice možné, ale nabízíme několik příkladů použití RestoreAsync k obnovení z výše uvedených scénářů.

Ztráta dat oddílů ve službě Reliable Services

V tomto případě modul runtime automaticky zjistí ztrátu dat a vyvolá OnDataLossAsync rozhraní API.

Autor služby musí k obnovení provést následující:

• Přepsat metodu OnDataLossAsyncvirtuální základní třídy .
• Vyhledejte nejnovější zálohu v externím umístění, které obsahuje zálohy služby.
• Stáhněte si nejnovější zálohu (a dekomprimujte ji do záložní složky, pokud byla komprimovaná).
• Metoda OnDataLossAsync poskytuje RestoreContext. RestoreAsync Zavolejte rozhraní API na zadaném RestoreContextrozhraní API.
• Pokud obnovení proběhlo úspěšně, vraťte hodnotu true.

Následuje příklad implementace OnDataLossAsync metody:

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 předání do RestoreContext.RestoreAsync hovoru obsahuje člena volané BackupFolderPath. Při obnovování jedné úplné zálohy by mělo být nastavené BackupFolderPath na místní cestu ke složce, která obsahuje úplnou zálohu. Při obnovování úplné zálohy a řady přírůstkových záloh by se měla nastavit místní cesta ke složce, BackupFolderPath která obsahuje nejen úplné zálohování, ale také všechny přírůstkové zálohy. RestoreAsync volání může vyvolat FabricMissingFullBackupException , pokud poskytnutá BackupFolderPath služba neobsahuje úplné zálohování. Může se také hodit ArgumentException , pokud BackupFolderPath má poškozený řetězec přírůstkových záloh. Pokud například obsahuje úplné zálohování, první přírůstkové a třetí přírůstkové zálohování, ale žádné druhé přírůstkové zálohování.

Odstraněná nebo ztracená služba

Pokud je služba odebraná, musíte nejprve znovu vytvořit službu, aby bylo možné data obnovit. Je důležité vytvořit službu se stejnou konfigurací, například schématem dělení, aby bylo možné data bez problémů obnovit. Jakmile je služba v provozu, musí se rozhraní API pro obnovení dat (OnDataLossAsync výše) vyvolat v každém oddílu této služby. Jedním ze způsobů, jak toho dosáhnout, je použití FabricClient.TestManagementClient.StartPartitionDataLossAsync v každém oddílu.

Od tohoto okamžiku je implementace stejná jako výše uvedený scénář. Každý oddíl musí obnovit nejnovější relevantní zálohu z externího úložiště. Jedním z důvodů je, že id oddílu se teď mohlo změnit, protože modul runtime vytváří ID oddílů dynamicky. Služba proto musí uložit příslušné informace o oddílu a název služby, aby identifikovala správnou nejnovější zálohu, ze které se má provést obnovení pro každý oddíl.

Replikace poškozených dat aplikace

Pokud má nově nasazený upgrade aplikace chybu, může to způsobit poškození dat. Upgrade aplikace může například začít aktualizovat každý záznam telefonního čísla ve Spolehlivém slovníku s neplatným směrovým číslem oblasti. V takovém případě se neplatná telefonní čísla budou replikovat, protože Service Fabric neví o povaze uložených dat.

První věc, kterou je třeba udělat, když zjistíte takovou eregovanou chybu, která způsobuje poškození dat, je ukotvit službu na úrovni aplikace a pokud je to možné, upgradujte na verzi kódu aplikace, který nemá chybu. I po opravení kódu služby však můžou být data stále poškozená, a proto může být potřeba data obnovit. V takových případech nemusí být dostatečné k obnovení nejnovější zálohy, protože nejnovější zálohy mohou být také poškozené. Proto musíte najít poslední zálohu, která byla provedena před poškozením dat.

Pokud si nejste jistí, které zálohy jsou poškozené, můžete nasadit nový cluster Service Fabric a obnovit zálohy ovlivněných oddílů stejně jako výše uvedený scénář Odstraněná nebo ztracená služba. Pro každý oddíl začněte obnovovat zálohy od nejnovějších po nejmenší. Jakmile najdete zálohu, která nemá poškození, přesuňte nebo odstraňte všechny zálohy tohoto oddílu, které byly novější (než toto zálohování). Tento postup opakujte pro každý oddíl. Když OnDataLossAsync se teď zavolá na oddíl v produkčním clusteru, poslední záloha nalezená v externím úložišti bude ta, kterou vybere výše uvedený proces.

Teď je možné pomocí kroků v části Odstraněná nebo ztracená služba obnovit stav služby do stavu před poškozením kódu chyby.

Poznámky:

• Při obnovení existuje šance, že je záloha, která se obnovuje, starší než stav oddílu před ztrátou dat. Z tohoto důvodu byste měli obnovit pouze poslední možnost obnovení co nejvíce dat.
• Řetězec, který představuje cestu k záložní složce a cesty souborů uvnitř záložní složky může být větší než 255 znaků v závislosti na délce cesty FabricDataRoot a názvu typu aplikace. To může způsobit, že některé metody .NET, například Directory.Move, vyvolat PathTooLongException výjimku. Jedním z alternativních řešení je přímé volání rozhraní API jádra 32, například CopyFile.

Zálohování a obnovení Reliable Actors

Reliable Actors Framework je postaven na Reliable Services. ActorService, který hostuje objekty actor, je stavová spolehlivá služba. Všechny funkce zálohování a obnovení dostupné v Reliable Services jsou proto také dostupné pro Reliable Actors (s výjimkou chování, které jsou specifické pro poskytovatele stavu). Vzhledem k tomu, že zálohy budou provedeny na základě jednotlivých oddílů, budou se zálohovat stavy pro všechny aktéry v daném oddílu (a obnovení je podobné a proběhne na základě jednotlivých oddílů). Pokud chcete provést zálohování nebo obnovení, měl by vlastník služby vytvořit vlastní třídu služby actor, která je odvozena z třídy ActorService, a pak provést zálohování a obnovení podobné Reliable Services, jak je popsáno výše v předchozích částech.

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

Když vytvoříte vlastní třídu služby actor, musíte ji zaregistrovat i při registraci objektu actor.

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

Výchozí zprostředkovatel stavu pro Reliable Actors je KvsActorStateProvider. Přírůstkové zálohování není ve výchozím nastavení KvsActorStateProviderpro . Přírůstkové zálohování můžete povolit tak, že vytvoříte KvsActorStateProvider odpovídající nastavení v jeho konstruktoru a pak ho předáte konstruktoru ActorService, jak je znázorněno v následujícím fragmentu kódu:

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

Po povolení přírůstkového zálohování může provedení přírůstkového zálohování selhat s výjimkou FabricMissingFullBackupException z jednoho z následujících důvodů a před provedením přírůstkových záloh budete muset provést úplné zálohování:

• Replika nikdy nezabrala úplnou zálohu, protože se stala primárním serverem.
• Některé záznamy protokolu byly od posledního vytvoření zálohy zkráceny.

Pokud je povolené přírůstkové zálohování, KvsActorStateProvider nepoužívá ke správě záznamů protokolu cyklický vyrovnávací paměť a pravidelně je zkracuje. Pokud uživatel po dobu 45 minut neprobíná žádnou zálohu, systém záznamy protokolu automaticky zkrátí. Tento interval lze nakonfigurovat zadáním logTruncationIntervalInMinutes v KvsActorStateProvider konstruktoru (podobně jako při povolování přírůstkového zálohování). Záznamy protokolu se také můžou zkrátit, pokud primární replika potřebuje vytvořit jinou repliku odesláním všech dat.

Při obnovení z řetězce zálohování, podobně jako Reliable Services, by služba BackupFolderPath měla obsahovat podadresáře s jedním podadresářem obsahujícím úplné zálohování a další podadresáře obsahující přírůstkové zálohy. Rozhraní API pro obnovení vyvolá výjimku FabricException s příslušnou chybovou zprávou, pokud se ověření řetězu zálohování nezdaří.

Testování zálohování a obnovení

Je důležité zajistit zálohování důležitých dat a obnovit je z něj. Můžete to provést vyvoláním rutiny v PowerShellu Start-ServiceFabricPartitionDataLoss , která může vyvolat ztrátu dat v určitém oddílu a otestovat, jestli funkce zálohování a obnovení dat pro vaši službu fungují podle očekávání. Je také možné programově vyvolat ztrátu a obnovení dat z této události.

Pod kapotou: další podrobnosti o zálohování a obnovení

Tady je několik dalších podrobností o zálohování a obnovení.

Backup

Správce spolehlivého stavu poskytuje možnost vytvářet konzistentní zálohy bez blokování operací čtení nebo zápisu. K tomu využívá kontrolní bod a mechanismus trvalosti protokolu. Reliable State Manager přebírá přibližné (zjednodušené) kontrolní body v určitých bodech, aby se zmírnit tlak z transakčního protokolu a zlepšit dobu obnovení. Při BackupAsync zavolání správce Reliable State Manager dává všem spolehlivým objektům pokyn, aby zkopírovaly nejnovější soubory kontrolních bodů do místní záložní složky. Potom Správce spolehlivého stavu zkopíruje všechny záznamy protokolu počínaje počátečním ukazatelem na nejnovější záznam protokolu do záložní složky. Vzhledem k tomu, že všechny záznamy protokolu až do nejnovějšího záznamu protokolu jsou zahrnuty do zálohy a Správce spolehlivého stavu zachovává protokolování před zápisem, Reliable State Manager zaručuje, že všechny transakce, které jsou potvrzeny (CommitAsync úspěšně vráceny), jsou zahrnuty do zálohy.

Jakákoli transakce, která se potvrdí po BackupAsync zavolání, může nebo nemusí být v zálohování. Jakmile platforma naplní místní složku zálohování (tj. místní zálohování dokončí modul runtime), vyvolá se zpětné volání zálohování služby. Toto zpětné volání zodpovídá za přesun záložní složky do externího umístění, jako je Azure Storage.

Obnovení

Správce spolehlivého stavu poskytuje možnost obnovení ze zálohy pomocí RestoreAsync rozhraní API.
Tuto RestoreAsync metodu RestoreContext OnDataLossAsync lze volat pouze uvnitř metody. Logická hodnota vrácená OnDataLossAsync indikuje, jestli služba obnovila svůj stav z externího zdroje. Pokud se OnDataLossAsync vrátí hodnota true, Service Fabric znovu sestaví všechny ostatní repliky z tohoto primárního serveru. Service Fabric zajišťuje, že repliky, které obdrží OnDataLossAsync první přechod volání na primární roli, ale nemají udělený stav čtení nebo stav zápisu. To znamená, že pro implementátory StatefulService se nebudou volat, RunAsync dokud OnDataLossAsync se úspěšně nedokončí. OnDataLossAsync Potom se vyvolá na novém primárním serveru. Dokud služba toto rozhraní API úspěšně nedokončí (vrácením hodnoty true nebo false) a dokončí příslušnou rekonfiguraci, bude se rozhraní API vždy volat po jednom.

RestoreAsync nejprve zahodí veškerý existující stav v primární replice, na které byl volána. Potom Správce spolehlivého stavu vytvoří všechny spolehlivé objekty, které existují v záložní složce. Dále jsou spolehlivá objekty instruovány k obnovení ze svých kontrolních bodů ve složce zálohování. Správce spolehlivého stavu nakonec obnoví svůj vlastní stav ze záznamů protokolu ve složce zálohování a provede obnovení. V rámci procesu obnovení se operace začínající od počátečního bodu, které mají potvrzené záznamy protokolu ve složce zálohování, přehrají do spolehlivých objektů. Tento krok zajišťuje, že obnovený stav je konzistentní.

Další kroky

• Reliable Collections
• Rychlý start pro Reliable Services
• Oznámení Reliable Services
• Konfigurace Reliable Services
• Referenční informace pro vývojáře pro Reliable Collections
• Pravidelné zálohování a obnovení v Azure Service Fabric