Reliable Services és Reliable Actors biztonsági mentése és visszaállítása

Az Azure Service Fabric egy magas rendelkezésre állású platform, amely replikálja az állapotot több csomóponton a magas rendelkezésre állás fenntartása érdekében. Így még ha a fürt egyik csomópontja is meghibásodik, a szolgáltatások továbbra is elérhetők maradnak. Bár a platform által biztosított beépített redundancia bizonyos esetekben elegendő lehet, bizonyos esetekben kívánatos, hogy a szolgáltatás biztonsági másolatot készítsen az adatokról (egy külső tárolóba).

Megjegyzés

Kritikus fontosságú az adatok biztonsági mentése és visszaállítása (és annak tesztelése, hogy az a várt módon működik-e), hogy helyreállíthassa az adatvesztési forgatókönyveket.

Megjegyzés

A Microsoft azt javasolja, hogy rendszeres biztonsági mentést és visszaállítást használjon a Reliable Stateful szolgáltatások és a Reliable Actors adatmentésének konfigurálásához.

Előfordulhat például, hogy egy szolgáltatás biztonsági másolatot szeretne készíteni az adatokról a következő forgatókönyvek elleni védelem érdekében:

• Egy teljes Service Fabric-fürt végleges elvesztése esetén.
• Szolgáltatáspartíció replikáinak többségének végleges elvesztése
• Rendszergazdai hibák, amelyekkel az állapot véletlenül törlődik vagy megsérül. Ez például akkor fordulhat elő, ha egy megfelelő jogosultsággal rendelkező rendszergazda tévesen törli a szolgáltatást.
• A szolgáltatás adatsérülést okozó hibái. Ez például akkor fordulhat elő, ha egy szolgáltatáskód frissítése hibás adatokat kezd írni egy megbízható gyűjteménybe. Ilyen esetben előfordulhat, hogy a kódot és az adatokat is vissza kell állítani egy korábbi állapotba.
• Offline adatfeldolgozás. Célszerű lehet offline adatfeldolgozást készíteni az üzleti intelligenciához, amely az adatokat létrehozó szolgáltatástól elkülönítve történik.

A Biztonsági mentés/visszaállítás funkció lehetővé teszi a Reliable Services API-ra épülő szolgáltatások számára a biztonsági másolatok létrehozását és visszaállítását. A platform által biztosított biztonsági mentési API-k lehetővé teszik a szolgáltatáspartíciók állapotának biztonsági mentését anélkül, hogy blokkolják az olvasási vagy írási műveleteket. A visszaállítási API-k lehetővé teszik egy szolgáltatáspartíció állapotának visszaállítását egy kiválasztott biztonsági másolatból.

A biztonsági mentés típusai

Két biztonsági mentési lehetőség közül választhat: Teljes és Növekményes. A teljes biztonsági mentés olyan biztonsági mentés, amely tartalmazza a replika állapotának újbóli létrehozásához szükséges összes adatot: ellenőrzőpontokat és az összes naplórekordot. Mivel rendelkezik az ellenőrzőpontokkal és a naplóval, a teljes biztonsági mentés önmagában is visszaállítható.

A teljes biztonsági mentéssel kapcsolatos probléma akkor merül fel, ha az ellenőrzőpontok nagyok. Egy 16 GB-os állapotú replika például körülbelül 16 GB méretű ellenőrzőpontokkal rendelkezik. Ha a helyreállítási pont célja öt perc, a replikáról öt percenként biztonsági másolatot kell készíteni. Minden biztonsági mentéshez 16 GB ellenőrzőpontot kell másolnia az 50 MB-os (konfigurálható CheckpointThresholdInMB) naplók mellett.

Erre a problémára a növekményes biztonsági mentés a megoldás, ahol a biztonsági mentés csak a legutóbbi biztonsági mentés óta módosított naplórekordokat tartalmazza.

Mivel a növekményes biztonsági mentések csak az utolsó biztonsági mentés óta változnak (nem tartalmazzák az ellenőrzőpontokat), általában gyorsabbak, de önmagukban nem állíthatók vissza. Növekményes biztonsági mentés visszaállításához a teljes biztonsági mentési láncra szükség van. A biztonsági mentési lánc egy biztonsági mentési lánc, amely egy teljes biztonsági mentéssel kezdődik, amelyet számos egymást követő növekményes biztonsági mentés követ.

Megbízható szolgáltatások biztonsági mentése

A szolgáltatás szerzője teljes mértékben szabályozza, hogy mikor készítsen biztonsági másolatot, és hol tárolja a biztonsági másolatokat.

A biztonsági mentés elindításához a szolgáltatásnak meg kell hívnia az örökölt tagfüggvényt BackupAsync.
A biztonsági másolatok csak elsődleges replikákból készíthetők, és írási állapot megadását igénylik.

Ahogy az alább látható, BackupAsync egy BackupDescription objektumot vesz fel, amelyben megadhat egy teljes vagy növekményes biztonsági mentést, valamint egy visszahívási függvényt, amely akkor lesz meghívva, Func<< BackupInfo, CancellationToken, Task<bool>>> amikor a biztonsági mentési mappa helyileg lett létrehozva, és készen áll arra, hogy áthelyezze őket egy külső tárolóba.

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

await this.BackupAsync(myBackupDescription);

A növekményes biztonsági mentésre irányuló kérés meghiúsulhat a következővel: FabricMissingFullBackupException. Ez a kivétel azt jelzi, hogy a következő dolgok egyike történik:

• a replika soha nem készített teljes biztonsági másolatot, mivel elsődlegessé vált,
• néhány naplórekordot az utolsó biztonsági mentés óta csonkítottak, vagy
• replika túllépte a korlátot MaxAccumulatedBackupLogSizeInMB .

A felhasználók növelhetik a növekményes biztonsági mentések valószínűségét a vagy TruncationThresholdFactora konfigurálásávalMinLogSizeInMB. Ezeknek az értékeknek a növelése növeli a replikalemezenkénti használatot. További információ: Reliable Services Configuration

BackupInfo információkat nyújt a biztonsági mentésről, beleértve annak a mappának a helyét, ahol a futtatókörnyezet mentette a biztonsági mentést (BackupInfo.Directory). A visszahívási függvény áthelyezheti a BackupInfo.Directory fájlt egy külső tárolóba vagy egy másik helyre. Ez a függvény egy bool értéket is visszaad, amely azt jelzi, hogy sikerült-e áthelyezni a biztonsági mentési mappát a célhelyre.

Az alábbi kód bemutatja, hogyan használható a BackupCallbackAsync metódus a biztonsági mentés Azure Storage-ba való feltöltéséhez:

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

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

    return true;
}

Az előző példában ExternalBackupStore az Azure Blob Storage-hoz való kapcsolódáshoz használt mintaosztály, amely UploadBackupFolderAsync tömöríti a mappát, és az Azure Blob Store-ba helyezi.

Vegye figyelembe:

• Replikánként egy adott időpontban csak egy biztonsági mentési művelet lehet repülés közben. Egyszerre több BackupAsync hívásra is sor FabricBackupInProgressException kerül, hogy a biztonsági mentéseket egyre korlátozza.
• Ha egy replika feladatátvételt hajt végre, amíg a biztonsági mentés folyamatban van, előfordulhat, hogy a biztonsági mentés nem fejeződött be. Így a feladatátvétel befejezése után a szolgáltatás felelőssége újraindítani a biztonsági mentést, szükség szerint meghívással BackupAsync .

Reliable Services visszaállítása

Általában az alábbi kategóriákba tartoznak azok az esetek, amikor esetleg visszaállítási műveletet kell végrehajtania:

• A szolgáltatáspartíció adatai elvesztek. Egy partíció (beleértve az elsődleges replikát is) három replikájának lemeze például sérült vagy törölve lesz. Előfordulhat, hogy az új elsődlegesnek vissza kell állítania az adatokat egy biztonsági másolatból.
• A teljes szolgáltatás elveszett. A rendszergazda például eltávolítja a teljes szolgáltatást, így a szolgáltatást és az adatokat vissza kell állítani.
• A szolgáltatás sérült alkalmazásadatokat replikált (például egy alkalmazáshiba miatt). Ebben az esetben a szolgáltatást frissíteni vagy visszaállítani kell a sérülés okának eltávolításához, és a nem sérült adatokat vissza kell állítani.

Bár számos megközelítés lehetséges, néhány példát mutatunk be a RestoreAsync fenti forgatókönyvek alapján történő helyreállításra.

Partíciós adatvesztés a Reliable Servicesben

Ebben az esetben a futtatókörnyezet automatikusan észleli az adatvesztést, és meghívja az API-t OnDataLossAsync .

A szolgáltatás szerzőjének a következő műveleteket kell végrehajtania a helyreállításhoz:

• A virtuális alaposztály metódusának OnDataLossAsyncfelülbírálása.
• Keresse meg a legújabb biztonsági mentést a szolgáltatás biztonsági másolatait tartalmazó külső helyen.
• Töltse le a legújabb biztonsági mentést (és tömörített biztonsági mentés esetén törölje a biztonsági mentést a biztonsági mentés mappájába).
• A OnDataLossAsync metódus a következőt RestoreContextbiztosítja: . Hívja meg az RestoreAsync API-t a megadott RestoreContextwebhelyen.
• Igaz értéket ad vissza, ha a helyreállítás sikeres volt.

Az alábbiakban egy példa a metódus implementálására OnDataLossAsync :

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 A hívásnak RestoreContext.RestoreAsync átadott szolgáltatás tartalmaz egy nevű tagot BackupFolderPath. Egyetlen teljes biztonsági mentés visszaállításakor ezt BackupFolderPath a teljes biztonsági mentést tartalmazó mappa helyi elérési útjára kell állítani. A teljes biztonsági mentés és számos növekményes biztonsági mentés visszaállításakor a mappa helyi elérési útját kell beállítani, BackupFolderPath amely nem csak a teljes biztonsági mentést tartalmazza, hanem az összes növekményes biztonsági mentést is. RestoreAsync a hívás akkor aktiválható FabricMissingFullBackupException , ha a BackupFolderPath megadott nem tartalmaz teljes biztonsági mentést. Akkor is dobhat ArgumentException , ha BackupFolderPath a növekményes biztonsági mentések megszakadt lánca van. Ha például tartalmazza a teljes biztonsági mentést, az első növekményes és a harmadik növekményes biztonsági mentést, de a második növekményes biztonsági mentést nem.

Megjegyzés

A RestorePolicy alapértelmezés szerint Biztonságos értékre van állítva. Ez azt jelenti, hogy az RestoreAsync API az ArgumentException hibával hiúsul meg, ha azt észleli, hogy a biztonsági mentési mappa olyan állapotot tartalmaz, amely régebbi vagy egyenlő a replikában található állapotnál. RestorePolicy.Force segítségével kihagyhatja ezt a biztonsági ellenőrzést. Ez a beállítás a részeként RestoreDescriptionvan megadva.

Törölt vagy elveszett szolgáltatás

Ha egy szolgáltatás el lett távolítva, először újra létre kell hoznia a szolgáltatást az adatok visszaállítása előtt. Fontos, hogy ugyanazzal a konfigurációval hozza létre a szolgáltatást, például particionálási sémát, hogy az adatok zökkenőmentesen visszaállíthatók legyenek. A szolgáltatás üzembe helyezését követően a szolgáltatás minden partícióján meg kell hívni az adatok visszaállításához szükséges API-t (OnDataLossAsync fent). Ennek egyik módja a FabricClient.TestManagementClient.StartPartitionDataLossAsync használata minden partíción.

Ettől a ponttól kezdve a megvalósítás megegyezik a fenti forgatókönyvével. Minden partíciónak vissza kell állítania a legújabb releváns biztonsági mentést a külső tárolóból. Az egyik kikötés az, hogy a partícióazonosító módosult, mivel a futtatókörnyezet dinamikusan hoz létre partícióazonosítókat. Így a szolgáltatásnak el kell tárolnia a megfelelő partícióadatokat és szolgáltatásnevet, hogy azonosítsa a megfelelő legújabb biztonsági mentést az egyes partíciókról való visszaállításhoz.

Megjegyzés

Nem ajánlott minden partíción használni FabricClient.ServiceManager.InvokeDataLossAsync a teljes szolgáltatás visszaállításához, mivel ez megsérülhet a fürt állapotában.

Sérült alkalmazásadatok replikálása

Ha az újonnan üzembe helyezett alkalmazásfrissítésben hiba lépett fel, az adatsérülést okozhat. Előfordulhat például, hogy egy alkalmazásfrissítés elkezdi frissíteni a Reliable Dictionary összes telefonszámrekordját érvénytelen körzetszámmal. Ebben az esetben az érvénytelen telefonszámok replikálódnak, mivel a Service Fabric nem ismeri a tárolt adatok jellegét.

Egy ilyen, adatsérülést okozó, rendkívül gyakori hiba észlelése után az első teendő a szolgáltatás rögzítése az alkalmazás szintjén, és ha lehetséges, frissítsen az alkalmazáskód azon verziójára, amely nem rendelkezik a hibával. A szolgáltatáskód kijavítása után is előfordulhat azonban, hogy az adatok továbbra is sérültek, ezért előfordulhat, hogy az adatokat vissza kell állítani. Ilyen esetekben előfordulhat, hogy nem elegendő a legújabb biztonsági mentés visszaállítása, mivel a legújabb biztonsági másolatok is sérültek lehetnek. Így meg kell találnia az utolsó biztonsági mentést, amely az adatok sérülése előtt készült.

Ha nem tudja biztosan, hogy mely biztonsági másolatok sérültek, üzembe helyezhet egy új Service Fabric-fürtöt, és visszaállíthatja az érintett partíciók biztonsági másolatait a fenti "Törölt vagy elveszett szolgáltatás" forgatókönyvhöz hasonlóan. Minden partíció esetében kezdje el visszaállítani a biztonsági másolatokat a legutóbbitól a legkevésbé. Ha olyan biztonsági mentést talál, amely nem rendelkezik sérüléssel, helyezze át/törölje a partíció összes olyan biztonsági másolatát, amely újabb volt (mint a biztonsági másolat). Ismételje meg ezt a folyamatot minden partíció esetében. Most, amikor OnDataLossAsync a rendszer meghívja a partíciót az éles fürtben, a külső tárolóban található utolsó biztonsági mentés lesz a fenti folyamat által kiválasztott biztonsági másolat.

A "Törölt vagy elveszett szolgáltatás" szakaszban található lépések segítségével visszaállíthatja a szolgáltatás állapotát az állapotba, mielőtt a hibás kód sérülte az állapotot.

Vegye figyelembe:

• A visszaállításkor előfordulhat, hogy a visszaállítandó biztonsági másolat régebbi, mint a partíció állapota az adatok elvesztése előtt. Emiatt csak végső megoldásként állítsa vissza a lehető legtöbb adatot.
• A biztonsági mentési mappa elérési útját és a biztonsági mentési mappában található fájlok elérési útját jelölő sztring 255 karakternél hosszabb lehet a FabricDataRoot elérési úttól és az alkalmazástípus nevének hosszától függően. Ez bizonyos .NET-metódusok, például Directory.Movea kivétel kidobását okozhatja PathTooLongException . Az egyik megkerülő megoldás a kernel32 API-k közvetlen meghívása, például CopyFile: .

Reliable Actors biztonsági mentése és visszaállítása

A Reliable Actors Framework a Reliable Servicesre épül. Az AktorSzolgáltatás, amely az aktor(ok)t üzemelteti, állapotalapú megbízható szolgáltatás. Ezért a Reliable Servicesben elérhető összes biztonsági mentési és visszaállítási funkció elérhető a Reliable Actors számára is (kivéve az állapotszolgáltatóra jellemző viselkedéseket). Mivel a biztonsági mentések partíciónként lesznek készítve, a partícióban lévő összes szereplő állapotáról biztonsági mentés készül (és a visszaállítás hasonló, és partíciónként történik). A biztonsági mentés/visszaállítás végrehajtásához a szolgáltatás tulajdonosának létre kell hoznia egy egyéni aktorszolgáltatás-osztályt, amely az ActorService osztályból származik, majd az előző szakaszokban ismertetett Reliable Serviceshez hasonló biztonsági mentést/visszaállítást kell végeznie.

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

Egyéni aktorszolgáltatás-osztály létrehozásakor ezt is regisztrálnia kell az aktor regisztrálásakor.

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

A Reliable Actors alapértelmezett állapotszolgáltatója a .KvsActorStateProvider A növekményes biztonsági mentés alapértelmezés szerint nincs engedélyezve a esetében KvsActorStateProvider. A növekményes biztonsági mentés engedélyezéséhez hozzon létre KvsActorStateProvider egy megfelelő beállítást a konstruktorban, majd adja át az ActorService konstruktornak az alábbi kódrészletben látható módon:

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

A növekményes biztonsági mentés engedélyezése után a növekményes biztonsági mentés a FabricMissingFullBackupException kivétellel meghiúsulhat az alábbi okok valamelyike miatt, és a növekményes biztonsági mentés(ek) elvégzése előtt teljes biztonsági másolatot kell készítenie:

• A replika soha nem készített teljes biztonsági másolatot, mióta elsődlegessé vált.
• Néhány naplórekord csonkult a legutóbbi biztonsági mentés óta.

Ha a növekményes biztonsági mentés engedélyezve van, KvsActorStateProvider nem használ körkörös puffert a naplórekordok kezeléséhez, és rendszeres időközönként csonkítja azt. Ha a felhasználó 45 percig nem készít biztonsági másolatot, a rendszer automatikusan csonkítja a naplórekordokat. Ez az időköz konstruktorban KvsActorStateProvider történő megadásával logTruncationIntervalInMinutes konfigurálható (hasonlóan a növekményes biztonsági mentés engedélyezéséhez). A naplórekordok akkor is csonkulhatnak, ha az elsődleges replikának egy másik replikát kell létrehoznia az összes adat elküldésével.

Ha biztonsági mentési láncból végez visszaállítást, a Reliable Serviceshez hasonlóan a BackupFolderPath fájlnak tartalmaznia kell egy teljes biztonsági mentést tartalmazó alkönyvtárral rendelkező alkönyvtárakat, és más alkönyvtárakat, amelyek növekményes biztonsági mentés(ek)et tartalmaznak. A visszaállítási API megfelelő hibaüzenettel küldi el a FabricException hibát, ha a biztonsági mentési lánc érvényesítése sikertelen.

Megjegyzés

KvsActorStateProvider jelenleg figyelmen kívül hagyja a RestorePolicy.Safe beállítást. Ennek a funkciónak a támogatását egy hamarosan megjelenő kiadásban terveztük.

Biztonsági mentés és visszaállítás tesztelése

Fontos gondoskodni arról, hogy a kritikus adatokról biztonsági másolat készüljön, és azokból vissza lehessen őket állítani. Ez a powershell-parancsmag meghívásával Start-ServiceFabricPartitionDataLoss végezhető el, amely adatvesztést okozhat egy adott partíción annak teszteléséhez, hogy a szolgáltatás adatmentési és visszaállítási funkciója a várt módon működik-e. Az eseményből programozott módon is meghívható az adatvesztés és a visszaállítás.

Megjegyzés

A biztonsági mentési és visszaállítási funkciók minta implementációját a GitHub webhivatkozási alkalmazásában találja. További részletekért tekintse meg a Inventory.Service szolgáltatást.

A motorháztető alatt: további részletek a biztonsági mentésről és a visszaállításról

Íme néhány további részlet a biztonsági mentésről és a visszaállításról.

Backup

A Reliable State Manager lehetővé teszi, hogy konzisztens biztonsági mentéseket hozzon létre az olvasási és írási műveletek blokkolása nélkül. Ehhez egy ellenőrzőpont- és naplómegőrzési mechanizmust használ. A Reliable State Manager bizonyos pontokon intelligens (egyszerűsített) ellenőrzőpontokat használ, hogy enyhítse a tranzakciónapló nyomását, és javítsa a helyreállítási időt. Amikor BackupAsync a rendszer meghívja, a Reliable State Manager arra utasítja az összes Reliable objektumot, hogy másolja a legújabb ellenőrzőpont-fájlokat egy helyi biztonsági mentési mappába. Ezután a Reliable State Manager az összes naplórekordot átmásolja a "start pointer" kezdettől a legújabb naplórekordig a biztonsági mentési mappába. Mivel a biztonsági mentés a legújabb naplórekordig minden naplórekordot tartalmaz, és a Reliable State Manager megőrzi az előre írt naplózást, a Reliable State Manager garantálja, hogy a véglegesített (CommitAsync sikeresen visszaadott) összes tranzakció szerepel a biztonsági mentésben.

A meghívást követően BackupAsync véglegesíteni kívánt tranzakciók lehetnek a biztonsági másolatban vagy sem. Miután a helyi biztonsági mentési mappát feltöltötte a platform (azaz a helyi biztonsági mentést a futtatókörnyezet befejezi), a rendszer meghívja a szolgáltatás biztonsági mentési visszahívását. Ez a visszahívás felelős a biztonsági mentési mappa külső helyre, például az Azure Storage-ba való áthelyezéséért.

Visszaállítás

A Reliable State Manager lehetővé teszi a biztonsági másolatból való visszaállítást az RestoreAsync API használatával.
A RestoreAsync metódus bekapcsolva RestoreContext csak a metóduson OnDataLossAsync belül hívható meg. Az által visszaadott OnDataLossAsync bool jelzi, hogy a szolgáltatás visszaállította-e az állapotát egy külső forrásból. Ha a visszaadott érték igaz, a OnDataLossAsync Service Fabric újraépíti az elsődleges replika összes többi replikáját. A Service Fabric biztosítja, hogy azok a replikák, amelyek elsőként fogadják OnDataLossAsync a hívásátváltást az elsődleges szerepkörre, de nem kapnak olvasási vagy írási állapotot. Ez azt jelenti, hogy a StatefulService implementálói nem lesznek meghívva, RunAsync amíg OnDataLossAsync sikeresen be nem fejeződik. OnDataLossAsync Ezután a rendszer meghívja az új elsődleges elemet. Amíg egy szolgáltatás sikeresen be nem fejezi ezt az API-t (igaz vagy hamis értéket ad vissza), és nem fejezi be a megfelelő újrakonfigurálást, az API-t a rendszer folyamatosan meghívja.

RestoreAsync először elveti az összes meglévő állapotot abban az elsődleges replikában, amelybe be lett hívva. Ezután a Reliable State Manager létrehozza a biztonsági mentési mappában található összes Reliable objektumot. Ezután a Reliable objektumokat a rendszer arra utasítja, hogy állítsa vissza azokat a biztonsági mentési mappában lévő ellenőrzőpontokról. Végül a Reliable State Manager helyreállítja a saját állapotát a biztonsági mentési mappában lévő naplórekordokból, és elvégzi a helyreállítást. A helyreállítási folyamat részeként a rendszer a biztonsági mentési mappában véglegesített naplórekordokat tartalmazó kezdőponttól kezdődő műveleteket visszajátssza a Reliable objektumokra. Ez a lépés biztosítja, hogy a helyreállított állapot konzisztens legyen.

Következő lépések

• Reliable Collections
• A Reliable Services rövid útmutatója
• Reliable Services-értesítések
• Reliable Services-konfiguráció
• Fejlesztői referencia a Reliable Collectionshez
• Rendszeres biztonsági mentés és visszaállítás az Azure Service Fabricben