Zotavení po havárii v Azure Service Fabric

Důležitou součástí poskytování vysoké dostupnosti je zajištění toho, aby služby mohly přežít všechny různé typy selhání. To je zvlášť důležité pro selhání, která jsou neplánovaná a mimo vaši kontrolu.

Tento článek popisuje některé běžné režimy selhání, které můžou být havárie, pokud nejsou modelovány a spravovány správně. Popisuje také zmírnění rizik a akce, které se mají provést, pokud dojde k havárii. Cílem je omezit nebo eliminovat riziko výpadku nebo ztráty dat v případě selhání, plánovaného nebo jiného výskytu.

Jak se vyhnout havárii

Hlavním cílem Azure Service Fabric je pomoct modelovat prostředí i služby takovým způsobem, aby běžné typy selhání nebyly katastrofy.

Obecně platí, že existují dva typy scénářů havárie/selhání:

• Chyby hardwaru a softwaru
• Provozní chyby

Chyby hardwaru a softwaru

Chyby hardwaru a softwaru jsou nepředvídatelné. Nejjednodušší způsob, jak přežít chyby, je spouštění více kopií služby napříč hranicemi chyb hardwaru nebo softwaru.

Pokud například vaše služba běží jenom na jednom počítači, selhání tohoto počítače je pro tuto službu katastrofou. Jednoduchým způsobem, jak se této havárii vyhnout, je zajistit, aby služba běžela na více počítačích. Testování je také nezbytné, aby se zajistilo, že selhání jednoho počítače nenaruší spuštěnou službu. Plánování kapacity zajišťuje, aby se náhradní instance vytvořila jinde a snížení kapacity nepřetěžuje zbývající služby.

Stejný vzor funguje bez ohledu na to, co se snažíte vyhnout selhání. Pokud se například obáváte selhání sítě SAN, narazíte na několik sítí SAN. Pokud máte obavy o ztrátu racku serverů, běžíte na několika rackech. Pokud máte obavy o ztrátu datových center, měla by vaše služba běžet napříč několika oblastmi Azure, napříč několika Zóny dostupnosti Azure nebo ve vašich vlastních datacentrech.

Když je služba rozložená mezi více fyzickými instancemi (počítače, racky, datacentra, oblasti), stále podléháte některým typům souběžných selhání. Jedno a dokonce i několik selhání určitého typu (například jeden virtuální počítač nebo síťové propojení selhává) se zpracovává automaticky, takže už nejsou "katastrofou".

Service Fabric poskytuje mechanismy pro rozšíření clusteru a zpracovává přenesení uzlů a služeb, které selhaly. Service Fabric také umožňuje spouštět mnoho instancí vašich služeb, aby se zabránilo neplánovaným selháním v přeměně na skutečné havárie.

Může se jednat o důvody, proč spuštění nasazení dostatečně velkého rozsahu pro selhání není možné. Může například trvat více hardwarových prostředků, než jste ochotni platit vzhledem k pravděpodobnosti selhání. Pokud pracujete s distribuovanými aplikacemi, můžou další komunikační směrování nebo náklady na replikaci stavu napříč geografickými vzdálenostmi způsobit nepřijatelnou latenci. Kde se tato čára vykreslí, se pro každou aplikaci liší.

V případě softwarových chyb může být chyba ve službě, kterou se pokoušíte škálovat. V tomto případě více kopií nezabrání havárii, protože stav selhání je korelován napříč všemi instancemi.

Provozní chyby

I když je vaše služba rozložená po celém světě s mnoha redundancemi, může stále zaznamenat katastrofální události. Někdo může například omylem překonfigurovat název DNS pro službu nebo ho přímo odstranit.

Řekněme například, že máte stavovou službu Service Fabric a někdo tuto službu omylem odstranil. Pokud neexistuje nějaké další omezení rizik, tato služba a celý stav, který už měl, jsou pryč. Tyto typy provozních havárií ("oops") vyžadují různá omezení rizik a kroky pro obnovení než běžné neplánované selhání.

Nejlepšími způsoby, jak se vyhnout těmto typům provozních chyb, je:

• Omezte provozní přístup k prostředí.
• Přísně auditujte nebezpečné operace.
• Vynucujte automatizaci, předejdete ručním nebo zastaralým změnám a před provedením těchto změn ověříte konkrétní změny v prostředí.
• Ujistěte se, že destruktivní operace jsou "měkké". Softwarové operace se neprojeví okamžitě nebo je můžete vrátit zpět v časovém intervalu.

Service Fabric poskytuje mechanismy, které brání provozním chybám, jako je poskytování řízení přístupu na základě role pro operace clusteru. Většina těchto provozních chyb však vyžaduje úsilí organizace a další systémy. Service Fabric poskytuje mechanismy pro přežití provozních chyb, zejména zálohování a obnovení stavových služeb.

Správa selhání

Cílem Service Fabric je automatická správa selhání. Aby se ale mohly zpracovat některé typy selhání, musí mít služby další kód. Jiné typy selhání by se neměly automaticky řešit z důvodů bezpečnosti a kontinuity podnikových procesů.

Zpracování jednotlivých selhání

Jeden počítač může selhat z nejrůznějších důvodů. Někdy se jedná o hardwarové příčiny, jako jsou napájecí zdroje a selhání síťového hardwaru. Další selhání jsou v softwaru. Patří sem selhání operačního systému a samotné služby. Service Fabric tyto typy selhání automaticky rozpozná, včetně případů, kdy se počítač kvůli problémům se sítí izoluje od jiných počítačů.

Bez ohledu na typ služby má spuštění jedné instance za následek výpadek této služby, pokud tato jedna kopie kódu z nějakého důvodu selže.

Pokud chcete zvládnout jakékoli selhání, nejjednodušší věc, kterou můžete udělat, je zajistit, aby vaše služby běžely ve výchozím nastavení na více než jednom uzlu. U bezstavových služeb se ujistěte, že InstanceCount je větší než 1. U stavových služeb je minimální doporučení nastaveno TargetReplicaSetSize na MinReplicaSetSize hodnotu 3. Spuštěním více kopií kódu služby zajistíte, že vaše služba dokáže automaticky zpracovat jakékoli selhání.

Zpracování koordinovaných selhání

Koordinovaná selhání v clusteru můžou být způsobená plánovanými nebo neplánovanými chybami infrastruktury a změnami nebo plánovanými změnami softwaru. Modely Service Fabric modelují zóny infrastruktury, u které dochází ke koordinovaným selháním jako domén selhání. Oblasti, které budou mít zkušenosti se koordinovanými změnami softwaru, se modelují jako upgradované domény. Další informace o doménách selhání, upgradovaných doménách a topologii clusteru najdete v tématu Popis clusteru Service Fabric pomocí Správce prostředků clusteru.

Service Fabric ve výchozím nastavení při plánování, kde se mají služby spouštět, považuje domény selhání a upgradu. Service Fabric se ve výchozím nastavení snaží zajistit, aby vaše služby běžely napříč několika doménami selhání a upgradovaly, aby v případě plánovaných nebo neplánovaných změn zůstaly vaše služby dostupné.

Řekněme například, že selhání zdroje napájení způsobí, že všechny počítače v racku současně selžou. Při spuštění více kopií služby se ztráta mnoha počítačů v selhání domény selhání změní na další příklad jediného selhání služby. Proto je správa domén selhání a upgradu důležitá pro zajištění vysoké dostupnosti vašich služeb.

Při spouštění Service Fabric v Azure se domény selhání a upgradující domény spravují automaticky. V jiných prostředích nemusí být. Pokud vytváříte vlastní clustery místně, nezapomeňte správně namapovat a naplánovat rozložení domény selhání.

Domény upgradu jsou užitečné pro oblasti modelování, ve kterých se software upgraduje současně. Z tohoto důvodu domény upgradu také často definují hranice, kde se software během plánovaných upgradů odebral. Upgrady Service Fabric i vašich služeb se řídí stejným modelem. Další informace o postupném upgradu, upgradování domén a modelu stavu Service Fabric, který pomáhá zabránit neúmyslným změnám v ovlivnění clusteru a vaší služby, najdete tady:

• Upgrade aplikací
• Kurz upgradu aplikace
• Model stavu Service Fabric

Rozložení clusteru můžete vizualizovat pomocí mapy clusteru poskytované v Service Fabric Exploreru:

Zpracování souběžných selhání hardwaru nebo softwaru

Mluvili jsme o jednotlivých selháních. Jak vidíte, jsou snadno ovladatelné pro bezstavové i stavové služby, a to tak, že si zachováte více kopií kódu (a stavu) spuštěných napříč doménami selhání a upgradu.

Může také dojít k několika souběžných náhodným selháním. To je pravděpodobnější, že dojde k výpadku nebo skutečné havárii.

Bezstavové služby

Počet instancí bezstavové služby označuje požadovaný počet instancí, které je potřeba spustit. Pokud jakékoli (nebo všechny) instance selžou, Service Fabric odpoví automatickým vytvářením náhradních instancí na jiných uzlech. Service Fabric nadále vytváří náhrady, dokud se služba nevrátí do požadovaného počtu instancí.

Předpokládejme například, že bezstavová služba má InstanceCount hodnotu -1. Tato hodnota znamená, že jedna instance by měla běžet na každém uzlu v clusteru. Pokud některé z těchto instancí selžou, Service Fabric zjistí, že služba není v požadovaném stavu, a pokusí se vytvořit instance na uzlech, ve kterých chybí.

Stavové služby

Existují dva typy stavových služeb:

• Stavový s trvalým stavem.
• Stavový s neudržovaným stavem. (Stav je uložen v paměti.)

Obnovení ze selhání stavové služby závisí na typu stavové služby, počtu replik, které služba měla, a na tom, kolik replik selhalo.

Ve stavové službě se příchozí data replikují mezi replikami (primární a jakékoli aktivní sekundární). Pokud většina replik přijímá data, data se považují za potvrzená kvora . (Pro pět replik budou tři kvorum.) To znamená, že v každém okamžiku bude kvorum replik s nejnovějšími daty kvorum. Pokud repliky selžou (řekněme dva z pěti), můžeme hodnotu kvora použít k výpočtu, jestli můžeme obnovit. (Vzhledem k tomu, že zbývající tři z pěti replik jsou stále vzhůru, je zaručeno, že alespoň jedna replika bude mít úplná data.)

Pokud kvorum replik selže, je oddíl deklarován jako ve stavu ztráty kvora. Řekněme, že oddíl má pět replik, což znamená, že alespoň tři jsou zaručené, že mají úplná data. Pokud selže kvorum (tři z pěti) replik, Service Fabric nedokáže určit, jestli zbývající repliky (dva z pěti) mají dostatek dat k obnovení oddílu. V případech, kdy Service Fabric zjistí ztrátu kvora, je výchozím chováním zabránit dalším zápisům do oddílu, deklarovat ztrátu kvora a čekat na obnovení kvora replik.

Určení, jestli došlo k havárii stavové služby, a jeho správa se řídí třemi fázemi:

1. Určení, jestli nedošlo ke ztrátě kvora nebo ne.

   Ztráta kvora se deklaruje, když je současně spuštěna většina replik stavové služby.

2. Určení, jestli je ztráta kvora trvalá nebo ne.

   Ve většině případů jsou selhání přechodná. Procesy se restartují, uzly se restartují, virtuální počítače se znovu spustí a opraví se síťové oddíly. Někdy jsou ale selhání trvalá. Jestli jsou selhání trvalá, nebo ne, závisí na tom, jestli stavová služba uchovává svůj stav nebo jestli je uchovává pouze v paměti:

   • U služeb bez trvalého stavu může selhání kvora nebo více replik okamžitě narušovat trvalou ztrátu kvora. Když Service Fabric zjistí ztrátu kvora ve stavové non-trvalé službě, okamžitě pokračuje krokem 3 deklarací (potenciální) ztráty dat. Pokračování ke ztrátě dat dává smysl, protože Service Fabric ví, že neexistuje žádný bod, než se repliky vrátí. I když se obnoví, data budou ztracena z důvodu neudržované povahy služby.
   • V případě stavových trvalých služeb způsobí selhání kvora nebo více replik replik, že Service Fabric počká, až se repliky vrátí a obnoví kvorum. Výsledkem je výpadek služby pro všechny zápisy do ovlivněného oddílu (neboli sady replik) služby. Čtení ale může být stále možné s omezenými zárukami konzistence. Výchozí doba, po kterou Service Fabric čeká na obnovení kvora, je neomezená, protože pokračováním je (potenciální) událost ztráty dat a nese další rizika. To znamená, že Service Fabric nebude pokračovat k dalšímu kroku, pokud správce neprohlásí ztrátu dat.

3. Určení ztráty dat a obnovení ze záloh

   Pokud byla deklarována ztráta kvora (buď automaticky, nebo prostřednictvím akce správy), Service Fabric a služby se přesouvají, aby se určilo, jestli se data skutečně ztratila. V tuto chvíli Service Fabric také ví, že ostatní repliky se nevrátí. To bylo rozhodnutí, kdy jsme přestali čekat na ztrátu kvora, aby se vyřešila sama. Nejlepší postup pro službu je obvykle ukotvit a čekat na konkrétní zásah správce.

   Když Service Fabric volá metoduOnDataLossAsync, je to vždy kvůli podezření na ztrátu dat. Service Fabric zajišťuje, že se toto volání doručí do nejlepší zbývající repliky. Podle toho, která replika dosáhla největšího pokroku.

   Důvod, proč vždy říkáme podezřelou ztrátu dat, je, že je možné, že zbývající replika má stejný stav jako primární, když došlo ke ztrátě kvora. Bez tohoto stavu ale neexistuje žádný dobrý způsob, jak service Fabric nebo operátory zjistit.

   Co tedy dělá typická implementace OnDataLossAsync metody?

   1. Protokoly implementace, které OnDataLossAsync se aktivovaly, a aktivují se všechny nezbytné výstrahy správy.

   2. Implementace se obvykle pozastaví a čeká na další rozhodnutí a ruční akce. Důvodem je to, že i v případě, že jsou k dispozici zálohy, může být potřeba je připravit.

      Pokud například dvě různé služby koordinují informace, může být nutné tyto zálohy upravit, aby se zajistilo, že po obnovení budou tyto dvě služby konzistentní.

   3. Často existuje nějaká jiná telemetrie nebo vyčerpání ze služby. Tato metadata mohou být obsažena v jiných službách nebo v protokolech. Tyto informace je možné podle potřeby použít k určení, jestli byla přijata a zpracována nějaká volání v primárním serveru, která nebyla v zálohování nebo replikována do této konkrétní repliky. Tato volání může být potřeba přehrát nebo přidat do zálohy, než bude možné provést obnovení.

   4. Implementace porovná stav zbývající repliky s stavem, který je obsažen v jakýchkoli dostupných zálohách. Pokud používáte spolehlivé kolekce Service Fabric, jsou k dispozici nástroje a procesy . Cílem je zjistit, jestli stav v replice stačí, a zjistit, co může zálohování chybět.

   5. Po dokončení porovnání a po dokončení obnovení (v případě potřeby) by kód služby měl vrátit hodnotu true , pokud byly provedeny nějaké změny stavu. Pokud replika zjistila, že se jedná o nejlepší dostupnou kopii stavu a neprovádí žádné změny, vrátí kód hodnotu false.

      Hodnota true znamená, že všechny ostatní zbývající repliky teď můžou být nekonzistentní s touto replikou. Z této repliky budou vyřazeny a znovu sestaveny. Hodnota false označuje, že nebyly provedeny žádné změny stavu, takže ostatní repliky můžou zachovat, co mají.

Je důležité, aby autoři služeb před nasazením služeb v produkčním prostředí procvičili potenciální scénáře ztráty dat a selhání. Pokud chcete chránit před možností ztráty dat, je důležité pravidelně zálohovat stav jakékoli stavové služby do geograficky redundantního úložiště.

Musíte také zajistit, že máte možnost obnovit stav. Vzhledem k tomu, že zálohy mnoha různých služeb se provádějí v různých časech, je potřeba zajistit, aby po obnovení měly vaše služby konzistentní přehled.

Představte si například situaci, kdy jedna služba vygeneruje číslo a uloží ji a pak ji odešle do jiné služby, která ji také ukládá. Po obnovení můžete zjistit, že druhá služba má číslo, ale první ne, protože její záloha tuto operaci nezahrnovala.

Pokud zjistíte, že zbývající repliky nejsou dostatečné k pokračování ve scénáři ztráty dat a nemůžete rekonstruovat stav služby z telemetrie nebo vyčerpání, frekvence záloh určuje nejlepší možný cíl bodu obnovení (RPO). Service Fabric nabízí mnoho nástrojů pro testování různých scénářů selhání, včetně trvalého kvora a ztráty dat, které vyžadují obnovení ze zálohy. Tyto scénáře jsou součástí nástrojů testovatelnosti ve službě Service Fabric spravované službou Analýza chyb. Další informace o těchto nástrojích a vzorech najdete v tématu Úvod do služby Analýza chyb.

Řešení potíží se ztrátou kvora

Repliky můžou být přerušovaně kvůli přechodnému selhání. Chvíli počkejte, až se je Service Fabric pokusí vyvolat. Pokud došlo k výpadku replik po delší dobu, než se čekalo, postupujte podle těchto akcí pro řešení potíží:

• Repliky můžou selhát. Zkontrolujte sestavy stavu na úrovni repliky a protokoly vaší aplikace. Shromážděte výpisy stavu systému a proveďte potřebné akce k obnovení.
• Proces repliky mohl přestat reagovat. Zkontrolujte protokoly aplikace a ověřte to. Shromážděte výpisy stavu procesu a pak zastavte nereagující proces. Service Fabric vytvoří náhradní proces a pokusí se repliku vrátit zpět.
• Uzly, které hostují repliky, můžou být nedostupné. Restartujte základní virtuální počítač, aby se uzly spustily.

Někdy nemusí být možné obnovit repliky. Například jednotky selhaly nebo počítače fyzicky nereagují. V těchto případech je potřeba Service Fabric říct, aby nečekaly na obnovení repliky.

Tyto metody nepoužívejte, pokud je potenciální ztráta dat nepřijatelná k tomu, aby služba byla online. V takovém případě by se veškeré úsilí mělo provést směrem k obnovení fyzických počítačů.

Následující akce můžou vést ke ztrátě dat. Než je budete sledovat, zkontrolujte je.

• Repair-ServiceFabricPartition -PartitionId Použijte rozhraní API.System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) Toto rozhraní API umožňuje zadat ID oddílu, aby se přesunulo mimo ztrátu kvora a do potenciální ztráty dat.
• Pokud u vašeho clusteru dochází k častým chybám, které způsobují, že služby přejdou do stavu ztráty kvora a potenciální ztráta dat je přijatelná, můžete zadat odpovídající hodnotu QuorumLossWaitDuration , která může vaší službě pomoct automaticky obnovit. Service Fabric před provedením obnovení počká na zadanou QuorumLossWaitDuration hodnotu (výchozí hodnota je nekonečná). Tuto metodu nedoporučujeme, protože může způsobit neočekávané ztráty dat.

Dostupnost clusteru Service Fabric

Obecně platí, že cluster Service Fabric je vysoce distribuované prostředí bez kritických bodů selhání. Selhání jednoho uzlu nezpůsobí problémy s dostupností nebo spolehlivostí clusteru, a to především proto, že systémové služby Service Fabric dodržují stejné pokyny uvedené dříve. To znamená, že vždy běží se třemi nebo více replikami ve výchozím nastavení a systémové služby, které jsou bezstavové spuštěné na všech uzlech.

Základní vrstvy detekce selhání a sítě Service Fabric jsou plně distribuované. Většinu systémových služeb je možné znovu vytvořit z metadat v clusteru nebo zjistit, jak znovu synchronizovat jejich stav z jiných míst. Dostupnost clusteru může být ohrožena, pokud se systémové služby dostanou do situací ztráty kvora, jako jsou ty popsané výše. V těchto případech možná nebudete moct v clusteru provádět určité operace (například spuštění upgradu nebo nasazení nových služeb), ale samotný cluster je stále v provozu.

Služby ve spuštěném clusteru budou v těchto podmínkách běžet, pokud nevyžadují zápisy do systémových služeb, aby mohly dál fungovat. Pokud je například správce převzetí služeb při selhání ve ztrátě kvora, budou všechny služby nadále spuštěny. Všechny služby, které selžou, se ale nebudou moct automaticky restartovat, protože to vyžaduje zapojení Správce převzetí služeb při selhání.

Selhání datacentra nebo oblasti Azure

Ve výjimečných případech se fyzické datové centrum může dočasně stát nedostupným ze ztráty napájení nebo síťového připojení. V těchto případech nebudou vaše clustery a služby Service Fabric v daném datacentru nebo oblasti Azure dostupné. Vaše data se ale zachovají.

U clusterů spuštěných v Azure můžete zobrazit aktualizace výpadků na stránce stavu Azure. Ve vysoce nepravděpodobném případě, že fyzické datové centrum je částečně nebo zcela zničeno, může dojít ke ztrátě všech clusterů Service Fabric hostovaných v nich nebo služeb uvnitř nich. Tato ztráta zahrnuje jakýkoli stav, který není zálohovaný mimo toto datové centrum nebo oblast.

Existuje několik různých strategií pro přežití trvalého nebo trvalého selhání jednoho datacentra nebo oblasti:

• Spusťte samostatné clustery Service Fabric v několika takových oblastech a použijte nějaký mechanismus pro převzetí služeb při selhání a navrácení služeb po obnovení mezi těmito prostředími. Tento typ modelu s více clustery aktivní/ aktivní nebo aktivní/pasivní vyžaduje další kód pro správu a operace. Tento model také vyžaduje koordinaci záloh ze služeb v jednom datacentru nebo oblasti, aby byly dostupné v jiných datacentrech nebo oblastech, pokud selže.

• Spusťte jeden cluster Service Fabric, který zahrnuje více datacenter. Minimální podporovaná konfigurace pro tuto strategii je tři datová centra. Další informace najdete v tématu Nasazení clusteru Service Fabric napříč Zóny dostupnosti.

  Tento model vyžaduje další nastavení. Výhodou je ale, že selhání jednoho datacentra se převede z havárie na normální selhání. Tato selhání můžou zpracovávat mechanismy, které fungují pro clustery v rámci jedné oblasti. Domény selhání, upgradování domén a pravidla umístění Service Fabric zajišťují distribuci úloh tak, aby tolerovali normální selhání.

  Další informace o zásadách, které můžou pomoct provozovat služby v tomto typu clusteru, najdete v tématu Zásady umístění pro služby Service Fabric.

• Spusťte jeden cluster Service Fabric, který zahrnuje více oblastí pomocí samostatného modelu. Doporučený počet oblastí je tři. Podrobnosti o samostatném nastavení Service Fabric najdete v tématu Vytvoření samostatného clusteru .

Náhodná selhání, která vedou k selhání clusteru

Service Fabric má koncept počátečních uzlů. Jedná se o uzly, které udržují dostupnost základního clusteru.

Počáteční uzly pomáhají zajistit, aby cluster zůstal vzhůru vytvořením zapůjčení s jinými uzly a sloužil jako tiebreakers během určitých druhů selhání. Pokud náhodná selhání odeberou většinu počátečních uzlů v clusteru a nepřinesou se rychle, cluster se automaticky vypne. Cluster se pak nezdaří.

Poskytovatel prostředků Service Fabric v Azure spravuje konfigurace clusteru Service Fabric. Ve výchozím nastavení poskytovatel prostředků distribuuje počáteční uzly napříč doménami selhání a upgradováním primárního typu uzlu. Pokud je primární typ uzlu označený jako Silver nebo Gold durability, odeberete počáteční uzel (buď škálováním v primárním typu uzlu, nebo jeho ručním odebráním), cluster se pokusí zvýšit úroveň jiného uzlu, který není počátečním uzlem z dostupné kapacity primárního typu uzlu. Tento pokus selže, pokud máte méně dostupnou kapacitu, než vyžaduje úroveň spolehlivosti clusteru pro váš primární typ uzlu.

V samostatných clusterech Service Fabric i v Azure je primárním typem uzlu ten, který spouští semena. Když definujete primární typ uzlu, Service Fabric automaticky využije počet uzlů, které poskytuje vytvoření až devíti počátečních uzlů a sedmi replik každé systémové služby. Pokud sada náhodných selhání současně odstraní většinu těchto replik, systémové služby zadají ztrátu kvora. Pokud dojde ke ztrátě většiny počátečních uzlů, cluster se brzy vypne.

Další kroky

• Naučte se simulovat různá selhání pomocí architektury testovatelnosti.
• Přečtěte si další prostředky pro zotavení po havárii a prostředky s vysokou dostupností. Microsoft publikoval velké množství pokynů k těmto tématům. I když některé z těchto prostředků odkazují na konkrétní techniky použití v jiných produktech, obsahují mnoho obecných osvědčených postupů, které můžete použít v kontextu Service Fabric:
  • Kontrolní seznam k dostupnosti
  • Provedení postupu zotavení po havárii
  • Zotavení po havárii a vysoká dostupnost pro aplikace Azure
• Seznamte se s možnostmi podpory Service Fabric.