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 se tato vysoká dostupnost zachovala. Proto i v případě selhání jednoho uzlu v clusteru budou služby dál dostupné. I když tato integrovaná redundance poskytovaná platformou může některým stačit, v některých případech je žádoucí, aby služba zálohovala data (do externího úložiště).

Poznámka

Je důležité zálohovat a obnovovat data (a otestovat, jestli fungují podle očekávání), abyste mohli obnovit scénáře ztráty dat.

Poznámka

Microsoft doporučuje použít pravidelné zálohování a obnovení ke konfiguraci zálohování dat spolehlivých stavových služeb a reliable actors.

Služba může například chtít zálohovat data, aby byla chráněna 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 stav omylem odstraní nebo poškodí. K tomu může dojít například v případě, že správce s dostatečnými oprávněními chybně odstraní službu.
• 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.
• Offline zpracování dat. Může být vhodné mít offline zpracování dat pro business intelligence, které probíhá odděleně od služby, která data generuje.

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, aniž by se blokovaly operace čtení nebo zápisu. Rozhraní API pro obnovení umožňují obnovení stavu oddílu služby ze zvolené 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 má kontrolní body a protokol, je možné úplné zálohování obnovit samo.

Problém s úplným zálohováním nastává, když jsou kontrolní body velké. Například replika, která má 16 GB stavu, bude mít kontrolní body, které přičtou přibližně 16 GB. Pokud máme cíl bodu obnovení na pět 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ých pomocí CheckpointThresholdInMB) protokolů.

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

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

Spolehlivé služby zálohování

Autor služby má plnou kontrolu nad tím, kdy provádět zálohy a kam se budou zálohy ukládat.

Ke spuštění zálohování musí služba vyvolat zděděnou členovou funkci BackupAsync.
Zálohy lze provádět 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 lze určit úplné nebo přírůstkové zálohování, a také funkci zpětného volání, která se vyvolá, Func<< BackupInfo, CancellationToken, Task<bool>>> když je složka zálohování místně vytvořena a je připravena k přesunutí do externího úložiště.

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

await this.BackupAsync(myBackupDescription);

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

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

Uživatelé můžou zvýšit pravděpodobnost, že budou moct provádět přírůstkové zálohování pomocí MinLogSizeInMB konfigurace nebo TruncationThresholdFactor. Zvýšení těchto hodnot zvyšuje využití disku na repliku. Další informace najdete v tématu Konfigurace služby 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 do jiného umístění. Tato funkce také vrátí logickou hodnotu, která označuje, jestli se jí podařilo úspěšně přesunout záložní složku do cílového umístění.

Následující kód ukazuje, jak je možné použít metodu BackupCallbackAsync 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, ExternalBackupStore která se používá pro rozhraní se službou Azure Blob Storage, a UploadBackupFolderAsync je to metoda, 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í za provozu. Více než jedno BackupAsync volání najednou se bude volat FabricBackupInProgressException , aby se omezilo příchozí zálohování na jednu.
• Pokud replika převezme služby při selhání, zatímco probíhá zálohování, je možné, že zálohování nebylo dokončeno. Jakmile se tedy převzetí služeb při selhání dokončí, je na službě, aby zálohování BackupAsync podle potřeby restartovat.

Obnovení spolehlivých služeb

Obecně platí, že případy, kdy budete potřebovat provést operaci obnovení, spadají do jedné z těchto kategorií:

• Oddíl služby ztratil data. Například disk pro dvě ze tří replik pro oddíl (včetně primární repliky) se poškodí nebo vymaže. Nový primární server může potřebovat obnovit data ze zálohy.
• Dojde ke ztrátě celé služby. Správce například odebere celou službu, a proto je potřeba obnovit službu a data.
• 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 zpět, aby se odstranila příčina poškození, a nepoškozená data musí být obnovena.

I když je možné použít mnoho přístupů, nabízíme několik příkladů použití RestoreAsync k zotavení z výše uvedených scénářů.

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

V takovém případě modul runtime automaticky detekuje ztrátu dat a vyvolá OnDataLossAsync rozhraní API.

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

• Přepište 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 zálohu do složky backup, pokud byla komprimovaná).
• Metoda OnDataLossAsync poskytuje .RestoreContext RestoreAsync Zavolejte rozhraní API na zadaném RestoreContext.
• 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ředaný do RestoreContext.RestoreAsync volání obsahuje člen s názvem BackupFolderPath. Při obnovování jedné úplné zálohy by tato BackupFolderPath záloha měla být nastavená na místní cestu ke složce, která obsahuje vaši úplnou zálohu. Při obnovování úplné zálohy a řady přírůstkových záloh by měla být nastavena 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 , BackupFolderPath pokud poskytnutá záloha neobsahuje úplnou zálohu. Může také vyvolat ArgumentException , pokud BackupFolderPath má přerušený řetězec přírůstkových záloh. Pokud například obsahuje úplnou zálohu, první přírůstkovou a třetí přírůstkovou zálohu, ale ne druhou přírůstkovou zálohu.

Poznámka

RestorePolicy je ve výchozím nastavení nastavená na Bezpečné. To znamená, že RestoreAsync rozhraní API selže s argumentem Výjimka, pokud zjistí, že složka backup obsahuje stav, který je starší nebo roven stavu obsaženému v této replice. RestorePolicy.Force lze použít k vynechání této bezpečnostní kontroly. Tato hodnota je určena jako součást .RestoreDescription

Odstraněná nebo ztracená služba

Pokud je služba odebrána, musíte ji nejprve znovu vytvořit, aby bylo možné obnovit data. 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 spuštěná, musí se rozhraní API pro obnovení dat (OnDataLossAsync výše) vyvolat na každém oddílu této služby. Jedním ze způsobů, jak toho dosáhnout, je použití FabricClient.TestManagementClient.StartPartitionDataLossAsync na 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 upozornění je, že ID oddílu se teď mohlo změnit, protože modul runtime dynamicky vytváří ID oddílů. 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á obnovit pro každý oddíl.

Poznámka

K obnovení celé služby se nedoporučuje používat FabricClient.ServiceManager.InvokeDataLossAsync všechny oddíly, protože to může poškodit stav clusteru.

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 neplatným směrovým kódem oblasti. V takovém případě se neplatná telefonní čísla replikují, protože Service Fabric neví o povaze uložených dat.

První věcí, kterou je třeba udělat po zjištění tak závažné chyby, která způsobuje poškození dat, je zablokování služby na úrovni aplikace a pokud je to možné, upgrade na verzi kódu aplikace, která chybu neobsahuje. 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 obnovení nejnovější zálohy dostačující, protože nejnovější zálohy můžou 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 ztráta služby. 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ž tato záloha). Tento postup opakujte pro každý oddíl. OnDataLossAsync Když se teď zavolá na oddíl v produkčním clusteru, bude poslední záloha nalezená v externím úložišti ta, kterou vybral výše uvedený proces.

Teď můžete 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 možnost, že obnovovaná záloha je starší než stav oddílu před ztrátou dat. Z tohoto důvodu byste měli obnovit pouze jako poslední možnost, abyste obnovili co nejvíce dat.
• Řetězec, který představuje cestu k záložní složce a cesty k souborům uvnitř složky backup, může být delší 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, jako je Directory.Move, vyvolá výjimku PathTooLongException . Jedním z alternativních řešení je přímé volání rozhraní API kernel32, jako CopyFileje .

Zálohování a obnovení Reliable Actors

Reliable Actors Framework je postaven na Reliable Services. Služba ActorService, která hostuje objekty actor,je stavovou spolehlivou službou. Proto jsou všechny funkce zálohování a obnovení dostupné ve službě Reliable Services dostupné také pro reliable actors (s výjimkou chování, která jsou specifická pro poskytovatele stavu). Vzhledem k tomu, že zálohy se budou provádět 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 bude probíhat 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í/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ž vytváříte vlastní třídu služby actor, musíte ji zaregistrovat také při registraci objektu actor.

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

Výchozí poskytovatel stavu pro Reliable Actors je KvsActorStateProvider. Přírůstkové zálohování není ve výchozím nastavení povolené pro KvsActorStateProvider. Přírůstkové zálohování můžete povolit tak, že vytvoříte KvsActorStateProvider příslušné 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 nepřevezměla úplnou zálohu, protože se stala primární.
• Některé záznamy protokolu byly od posledního zálohování zkráceny.

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

Při obnovení z řetězu záloh by měla cesta BackupFolderPath podobně jako Reliable Services 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ří.

Poznámka

KvsActorStateProvider aktuálně ignoruje možnost RestorePolicy.Safe. Podpora této funkce se plánuje v nadcházející verzi.

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

Je důležité zajistit, aby se důležitá data zálohovala a bylo možné je obnovit. To lze provést voláním rutiny v PowerShellu Start-ServiceFabricPartitionDataLoss , která může vyvolat ztrátu dat v konkrétním oddílu a otestovat, jestli funkce zálohování a obnovení dat ve vaší službě funguje podle očekávání. Je také možné programově vyvolat ztrátu dat a obnovit z této události.

Poznámka

Ukázkovou implementaci funkcí zálohování a obnovení najdete v aplikaci Web Reference na GitHubu. Další podrobnosti najdete ve službě Inventory.Service .

Pod pokličkou: další podrobnosti o zálohování a obnovení

Tady jsou některé další podrobnosti o zálohování a obnovení.

Backup

Reliable State Manager 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 protokolů. Reliable State Manager přebírá v určitých bodech přibližné (zjednodušené) kontrolní body, aby zmírnil tlak transakčního protokolu a zlepšil dobu obnovení. Při BackupAsync zavolání správce spolehlivého stavu dá všem objektům Reliable pokyn, aby zkopírovaly své nejnovější soubory kontrolních bodů do místní záložní složky. Správce spolehlivého stavu pak zkopíruje všechny záznamy protokolu od počátečního ukazatele až po nejnovější záznam protokolu do záložní složky. Vzhledem k tomu, že do zálohy jsou zahrnuty všechny záznamy protokolu až po nejnovější záznam protokolu a Správce spolehlivého stavu zachovává protokolování dopsaného zápisu, správce spolehlivého stavu zaručuje, že všechny transakce, které jsou potvrzeny (CommitAsync úspěšně se vrátil), budou zahrnuty do zálohy.

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

Obnovení

Reliable State Manager poskytuje možnost obnovení ze zálohy pomocí RestoreAsync rozhraní API.
Metodu RestoreAsync v RestoreContext systému lze volat pouze uvnitř OnDataLossAsync metody. Logická hodnota vrácená uživatelem OnDataLossAsync označuje, jestli služba obnovila svůj stav z externího zdroje. Pokud vrátí OnDataLossAsync hodnotu true, Service Fabric znovu sestaví všechny ostatní repliky z tohoto primárního serveru. Service Fabric zajišťuje, že repliky, které budou přijímat OnDataLossAsync první přechod volání na primární roli, ale nebudou mít udělený stav čtení nebo zápisu. To znamená, že pro implementátory StatefulService se nebudou volat, RunAsync dokud OnDataLossAsync se úspěšně nedokončí. OnDataLossAsync Pak se vyvolá na novém primárním serveru. Dokud služba toto rozhraní API úspěšně nedokončí (tím, že vrátí hodnotu true nebo false) a nedokončí příslušnou rekonfiguraci, bude se rozhraní API dál volat jedno po druhém.

RestoreAsync nejprve odstraní veškerý existující stav v primární replice, na kterou byla volána. Pak Reliable State Manager vytvoří všechny spolehlivé objekty, které existují ve složce zálohování. Dále budou spolehlivé objekty vyzvá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řehrávají do objektů Reliable. Tento krok zajistí, aby byl obnovený stav konzistentní.

Další kroky

• Reliable Collections
• Reliable Services – rychlý start
• 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