Zotavení po havárii v Azure Service Fabric

Důležitou součástí zajištění vysoké dostupnosti je zajistit, aby služby byly v pořádku i po všech různých typech selhání. To je zvláště 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áriemi, pokud nejsou modelovány a spravovány správně. Popisuje také omezení rizik a akce, které je třeba v případě havárie přesto udělat. Cílem je omezit nebo eliminovat riziko výpadku nebo ztráty dat, když dojde k selháním, plánovanému nebo jinému.

Předcházení havárii

Hlavním cílem Azure Service Fabric je pomoct vám modelovat prostředí i služby tak, aby běžné typy selhání nebyly havárie.

Obecně existují dva typy scénářů havárie nebo selhání:

• Chyby hardwaru a softwaru
• Provozní chyby

Chyby hardwaru a softwaru

Chyby hardwaru a softwaru jsou nepředvídatelné. Nejjednodušší způsob, jak se pojí chyby, je provoz více kopií služby napříč hranicemi hardwarových nebo softwarových chyb.

Pokud například vaše služba běží jenom na jednom počítači, je selhání tohoto počítače pro službu havárií. Jednoduchým způsobem, jak se této havárii vyhnout, je zajistit, aby služba běžela na několika 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, že náhradní instanci lze vytvořit jinde a že snížení kapacity nepřetěžuje zbývající služby.

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

Když je služba rozložená mezi několik fyzických instancí (počítače, stojany, datacentra, oblasti), stále dochází k některým typům souběžných selhání. Ale selhání jednoho nebo dokonce několika selhání určitého typu (například selhání jednoho virtuálního počítače nebo síťového propojení) se zkrátí automaticky, takže už nejsou "havárií".

Service Fabric poskytuje mechanismy pro rozšíření clusteru a zpracovává návrat uzlů a služeb, které selhaly. Service Fabric také umožňuje spuštění mnoha instancí služeb, aby se neplánované chyby neprotoly v reálné havárie.

Spuštění nasazení natolik velkého, aby se mohlo pohánět s chybami, nemusí být možné. Může například trvat více hardwarových prostředků, než jste ochotni platit vzhledem k pravděpodobnosti selhání. Při práci s distribuovanou aplikací můžou další komunikační segmenty směrování nebo náklady na replikaci stavu napříč geografickými vzdálenostmi způsobit nepřijatelnou latenci. Kde je tento řádek nakreslen, se pro každou aplikaci liší.

Konkrétně u softwarových chyb může být chyba ve službě, kterou se pokoušíte škálovat. V takovém případě havárii nezabrání více kopií, protože stav selhání koreluje se všemi instancemi.

Provozní chyby

I když je vaše služba rozložená po celém světě s mnoha redundancemi, stále může docházet k katastrofálním událostem. 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 jste měli stavovou službu Service Fabric někdo ji omylem odstranil. Pokud neexistuje nějaké jiné omezení rizik, tato služba a veškerý stav, který měla, jsou teď 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ším způsobem, jak se vyhnout těmto typům provozních chyb, jsou:

• Omezte provozní přístup k prostředí.
• Důsledně auditovat nebezpečné operace.
• Zavedení automatizace, prevence ručních nebo nesměšných změn a ověření konkrétních změn v prostředí před jejich provedením.
• Zajistěte, aby destruktivní operace byly "soft". Softwarové operace se ne projeví okamžitě nebo je možné je vrátit zpět během časového okna.

Service Fabric poskytuje mechanismy pro prevenci provozních chyb, jako je například poskytování řízení přístupu na základě role pro operace clusteru. Většina těchto provozních chyb ale vyžaduje úsilí organizace a další systémy. Service Fabric poskytuje mechanismy pro zbývající provozní chyby, zejména zálohování a obnovení stavových služeb.

Správa selhání

Cílem této Service Fabric je automatická správa selhání. Aby se ale některé typy selhání zvládly, musí mít služby další kód. Jiné typy selhání by se z bezpečnostních a obchodních důvodů neměly automaticky řešit.

Zpracování jednotlivých selhání

Jednotlivé počítače selžou z nejrůznějších důvodů. Někdy je to hardwarová příčina, jako jsou napájecí zdroje a selhání síťového hardwaru. Jiné chyby 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 ostatních počítačů.

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

Aby bylo možné zvládnout jakékoli selhání, nejjednodušší věcí, kterou můžete udělat, je zajistit, aby vaše služby ve výchozím nastavení byly spuštěny na více než jednom uzlu. U bez stavových služeb se ujistěte, že InstanceCount je větší než 1. U stavových služeb je minimální doporučení, že a TargetReplicaSetSize jsou obě nastavené na hodnotu MinReplicaSetSize 3. Spuštění dalších kopií kódu služby zajišťuje, že vaše služba dokáže automaticky zvládnout jakékoli selhání.

Řešení koordinovaných selhání

Koordinovaná selhání v clusteru mohou být způsobená plánovanými nebo neplánovanými selháními a změnami infrastruktury nebo plánovanými změnami softwaru. Service Fabric zóny infrastruktury, u které se jako domény selhání vyskytnou koordinovaná selhání. Oblasti, kde bude docházet ke koordinovaným softwarovým změnám, jsou modelovány 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 Service Fabric clusteru pomocí Správce prostředků clusteru.

Ve výchozím nastavení Service Fabric domény selhání a upgradu při plánování, kde by měly být služby spuštěny. Ve výchozím nastavení se Service Fabric, aby vaše služby běží napříč několika doménami selhání a upgradování, 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í selhání všech počítačů v racku současně. Když je spuštěných více kopií služby, ztráta mnoha počítačů při selhání domény selhání se změní na další příklad jediného selhání služby. To je důvod, proč je správa domén selhání a upgradu zásadní pro zajištění vysoké dostupnosti vašich služeb.

Pokud používáte službu Service Fabric Azure, domény selhání a domény upgradu se spravují automaticky. V jiných prostředích to nemusí být. Pokud v místním prostředí používáte vlastní clustery, nezapomeňte správně namapovat a naplánovat rozložení domény selhání.

Upgradovací domény jsou užitečné pro oblasti modelování, kde bude software upgradován současně. Z tohoto důvodu upgradování domén také často definuje hranice, kde se software během plánovaných upgradů zahodí. Upgrady služeb Service Fabric i vašich služeb se budou řídit stejným modelem. Další informace o upgradech se selháním, upgradovaných doménách 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 v těchto tématu:

• Upgrade aplikace
• Kurz upgradu aplikace
• Service Fabric modelu stavu

Rozložení clusteru můžete vizualizovat pomocí mapy clusteru, kterou poskytuje Service Fabric Explorer:

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

Mluvili jsme o jediném selhání. Jak vidíte, je snadné je zpracovat pro bez stavové i stavové služby tím, že udržujete více kopií kódu (a stavu) spuštěných napříč doménami selhání a upgradů.

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

Bezvýcové služby

Počet instancí bez stavové služby udává požadovaný počet instancí, které musí být spuštěné. Pokud dojde k selhání některých (nebo všech) instancí, Service Fabric automaticky vytvoří náhradní instance na jiných uzlech. Service Fabric pokračuje ve vytváření nahrazení, dokud se služba nevrátí do požadovaného počtu instancí.

Předpokládejme například, že bezvýcová služba má InstanceCount hodnotu -1. Tato hodnota znamená, že jedna instance by měla být spuštěná 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, kde chybí.

Stavové služby

Existují dva typy stavových služeb:

• Stav s trvalým stavem.
• Stav se stavem bez trvalého uložení. (Stav je uložený v paměti.)

Obnovení stavové služby z neúspěšného provozu závisí na typu stavové služby, počtu replik, které měla služba obsahovat, a počtu replik, které selhaly.

Ve stavové službě se příchozí data replikují mezi replikami (primární a jakákoli aktivní sekundární). Pokud většina replik obdrží data, považují se za potvrzená data kvora . (Pro pět replik, tři budou kvorum.) To znamená, že v jakémkoli okamžiku bude k dispozici alespoň kvorum replik s nejnovějšími daty. Pokud se repliky nezdaří (například dvě než pět), můžeme použít hodnotu kvora k výpočtu, jestli můžeme provést obnovení. (Vzhledem k tomu, že zbývající tři z pěti replik jsou stále v, je zaručeno, že nejméně jedna replika bude mít úplná data.)

V případě selhání kvora repliky je oddíl deklarován jako ve stavu ztráty kvora . Řekněme, že oddíl má pět replik, což znamená, že k úplným datům mají zaručená aspoň tři repliky. Pokud kvorum (tři pět) replik selže, Service Fabric nemůže určit, jestli zbývající repliky (dvě z nich) mají dostatek dat pro obnovení oddílu. V případech, kdy Service Fabric detekuje ztrátu kvora, její výchozí chování je zabránit dalším zápisům do oddílu, deklarovat ztrátu kvora a počkat na obnovení kvora replik.

Určení, jestli došlo k havárii pro stavovou službu a pak ji spravovat podle tří fází:

1. Zjištění, zda došlo ke ztrátě kvora nebo ne.

   Ztráta kvora je deklarována v případě, že většina replik stavové služby je mimo provoz.

2. Určení, zda je ztráta kvora trvalá.

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

   • U služeb bez trvalého stavu dojde k selhání kvora nebo většího počtu replik okamžitě v trvalé ztrátě kvora. Když Service Fabric detekuje ztrátu kvora ve stavové netrvalé službě, okamžitě pokračuje krokem 3 tím, že deklaruje (možná) ztrátu dat. Řízení ztráty dat dává smysl, protože Service Fabric ví, že není potřeba čekat na to, aby se repliky vrátily zpátky. I po obnovení budou data ztracena z důvodu netrvalého charakteru služby.
   • U stavových trvalých služeb způsobí selhání kvora nebo většího počtu replik Service Fabric počkat, až se repliky vrátí a obnoví kvorum. Výsledkem je výpadek služby pro jakékoli zápisy do ovlivněného oddílu (neboli sady replik) služby. Nicméně je možné, že čtení je stále možné se sníženými zárukami konzistence. Výchozí doba, po kterou Service Fabric čeká na obnovení kvora, je nekonečná, protože pokračuje v případě (potenciální) událost ztráty dat a přináší další rizika. To znamená, že Service Fabric nebude pokračovat k dalšímu kroku, pokud správce neprovede akci k deklaraci ztráty dat.

3. Určení, zda jsou data ztracena, a obnovení ze zálohy.

   Pokud došlo ke ztrátě kvora (buď automaticky, nebo prostřednictvím akce správy), Service Fabric a služby se přesunou k určení, jestli se data skutečně ztratila. V tomto okamžiku Service Fabric taky ví, že se ostatní repliky nevrátí. To bylo rozhodnutí, které bylo provedeno, když jsme zastavili čekání na vyřešení ztráty kvora. Nejlepší akci pro službu je obvykle zablokovat a čekat na konkrétní zásah správce.

   Když Service Fabric volá OnDataLossAsync metodu, je vždy z důvodu podezřelé ztráty dat. Service Fabric zajistí, že se toto volání doručí do nejlepší zbývající repliky. To je to, že replika provedla nejvíce.

   Důvodem, kdy vždycky říkáme podezření na ztrátu dat, je to, že zbývající replika má stejný stav jako primární v případě ztráty kvora. Nicméně bez tohoto stavu pro porovnání s, neexistuje žádný dobrý způsob, jak Service Fabric nebo operátory znát, zda jsou.

   Co to dělá Typická implementace OnDataLossAsync metody?

   1. Implementační protokoly, které OnDataLossAsync byly aktivovány, a aktivují všechny nezbytné výstrahy pro správu.

   2. Implementace se obvykle pozastavuje a čeká na další rozhodování a ruční akce, které je potřeba provést. Důvodem je to, že i když jsou zálohy k dispozici, může být potřeba je připravit.

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

   3. Často se z této služby vyskytuje nějaká další telemetrie nebo začerpání. Tato metadata mohou být obsažena v jiných službách nebo v protokolech. Tyto informace můžete podle potřeby použít k určení, jestli se v primárním umístění neobjevila žádná volání, která se neobjevila v záloze nebo replikují do této konkrétní repliky. Aby bylo možné obnovení provést, možná budete muset tato volání přehrajte nebo přidat do zálohy.

   4. Implementace porovnává stav zbývající repliky s, která je obsažena v jakémkoli dostupném zálohování. Pokud používáte Service Fabric Reliable Collections, existují nástroje a procesy k dispozici. Cílem je zjistit, jestli je stav v replice dostatečný, a zjistit, co může zálohování chybět.

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

      Hodnota true značí, že všechny ostatní zbývající repliky teď můžou být nekonzistentní s tímto. Budou z této repliky vyřazeny a znovu sestaveny. Hodnota false znamená, že se neudělaly žádné změny stavu, takže ostatní repliky můžou zachovat, co mají.

Před nasazením služeb v produkčním prostředí je důležité, aby tvůrci služeb v praxi nasadili potenciální scénáře ztráty dat a selhání. Aby se zabránilo ochraně před ztrátou dat, je důležité pravidelně zálohovat stav jakékoli stavové služby na geograficky redundantní úložiště.

Musíte také zajistit, aby bylo možné obnovit stav. Vzhledem k tomu, že se zálohují spousty různých služeb v různou dobu, je potřeba zajistit, aby po obnovení byly vaše služby konzistentní.

Představte si třeba situaci, kdy jedna služba vygeneruje číslo a uloží ji, a pošle ji do jiné služby, která je také ukládá. Po obnovení si můžete všimnout, že druhá služba má číslo, ale první z nich ne, protože její záloha nezahrnovala tuto operaci.

Pokud zjistíte, že zbývající repliky nejsou dostačující pro pokračování v případě ztráty dat, a nemůžete rekonstruovat stav služby z telemetrie nebo výfuku, bude frekvence zálohování určovat nejlepší možný cíl bodu obnovení (RPO). Service Fabric poskytuje 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ů pro testování v Service Fabric, které spravuje služba pro analýzu chyb. Další informace o těchto nástrojích a vzorcích najdete v tématu Úvod do služby analýzy chyb.

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

Kvůli přechodnému selhání se repliky můžou považovat za občasné. Počkejte nějakou dobu, než se Service Fabric pokusí je přenést. Pokud se repliky neprovozují déle než očekávanou dobu trvání, postupujte podle těchto kroků pro řešení potíží:

• Může dojít k chybě replik. Kontroluje sestavy stavu na úrovni repliky a protokoly aplikací. Shromážděte výpisy stavu systému a proveďte potřebné akce k obnovení.
• Je možné, že proces repliky přestane reagovat. Zkontrolujte protokoly aplikací, abyste ověřili tuto kontrolu. Shromážděte výpisy procesu a potom zastavte nereagující proces. Service Fabric vytvoří náhradní proces a pokusí se repliku přenést zpátky.
• Uzly, které hostují repliky, mohou být mimo provoz. Pokud chcete uzly přenést, restartujte příslušný virtuální počítač.

V některých případech nemusí být možné repliky obnovit. Například jednotky se nezdařily nebo fyzické počítače nereagují. V těchto případech Service Fabric nutné, aby nečekaly na obnovení repliky.

Nepoužívejte tyto metody, pokud se potenciální ztráta dat neakceptuje k převedení služby do režimu online. V takovém případě by se mělo provádět veškeré úsilí k obnovování fyzických počítačů.

Následující akce mohou mít za následek ztrátu dat. Před provedením tohoto postupu ověřte.

• Použijte Repair-ServiceFabricPartition -PartitionId System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) rozhraní API nebo. Toto rozhraní API umožňuje zadat ID oddílu pro přesunutí ztráty kvora a potenciální ztráty dat.
• Pokud se v clusteru vyskytují časté chyby, které způsobují, že se služby přestanou do stavu ztráty kvora, a může dojít ke ztrátě dat, zadáním příslušné hodnoty QuorumLossWaitDuration může vaše služba automaticky obnovit. Service Fabric QuorumLossWaitDuration před provedením obnovení počká na poskytnutou hodnotu (výchozí je nekonečno). Tuto metodu nedoporučujeme, protože může způsobit neočekávané ztráty dat.

Dostupnost clusteru Service Fabric clusteru

Obecně platí, že Service Fabric cluster je vysoce distribuované prostředí bez jediného bodu selhání. Selhání jednoho uzlu nezpůsobí problémy s dostupností nebo spolehlivostí clusteru, především proto, že systémové služby Service Fabric dodržují stejné pokyny, které jste uvedli 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é, běží na všech uzlech.

Základní vrstvy Service Fabric sítě a detekce selhání 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 stav z jiných míst. Dostupnost clusteru může být ohrožena, pokud se systémové služby dostane do situací ztráty kvora, jako jsou situace popsané výše. V těchto případech možná nebudete moct provádět určité operace v clusteru (například spuštění upgradu nebo nasazení nových služeb), ale samotný cluster je stále v provozu.

Služby na spuštěném clusteru budou v těchto podmínkách dál běžet, pokud nevyžadují, aby zápisy do systémových služeb dál fungovaly. Pokud například dojde Správce převzetí služeb při selhání kvora, všechny služby budou dál běžet. 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 může být fyzické datové centrum dočasně nedostupné z důvodu ztráty napájení nebo připojení k síti. V těchto případech budou vaše Service Fabric clustery a služby v tomto datacentru nebo oblasti Azure nedostupné. Vaše data se však 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 by došlo k částečnému nebo úplnému zničení fyzického datacentra, můžou se ztratit všechny clustery Service Fabric, které jsou v nich hostované, nebo služby v nich. Tato ztráta zahrnuje všechny stavy, které nejsou zálohované mimo toto datové centrum nebo oblast.

Existuje několik různých strategií pro zachování trvalého nebo trvalého selhání jednoho datacentra nebo oblasti:

• Spusťte samostatné Service Fabric clustery 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 aktivní/aktivní nebo aktivní/pasivní s více clustery vyžaduje další kód pro správu a provoz. 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, když dojde k selhání.

• Spusťte jeden cluster Service Fabric, který zahrnuje více datových center. Minimální podporovaná konfigurace pro tuto strategii jsou 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 ale je, že selhání jednoho datacentra se z havárie převede na normální selhání. Tato selhání mohou být zpracována mechanismy, které fungují pro clustery v rámci jedné oblasti. Domény selhání, upgradovací domény a pravidla Service Fabric umístění zajišťují distribuci úloh, 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 Service Fabric služby.

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

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

Service Fabric má koncept předimových uzlů. Jedná se o uzly, které udržují dostupnost základního clusteru.

Předimédové uzly pomáhají zajistit, aby cluster zůstal v provozu, a to navázáním zapůjčení s jinými uzly a obsluhujícími během určitých druhů selhání jako průkopníky. Pokud náhodná selhání odeberou většinu dosázek v clusteru a nevrátí se rychle zpět, cluster se automaticky vypne. Cluster pak selže.

V Azure spravuje Service Fabric prostředků konfiguraci Service Fabric clusteru. Poskytovatel prostředků ve výchozím nastavení distribuuje základní uzly mezi domény selhání a upgrady pro primární typ uzlu. Pokud je primární typ uzlu označený jako stálost Silver nebo Gold a odeberete dosazovaný uzel (š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 nesedového uzlu z dostupné kapacity primárního typu uzlu. Tento pokus selže, pokud máte méně dostupné kapacity, než vyžaduje úroveň spolehlivosti clusteru pro váš typ primárního uzlu.

V samostatných Service Fabric i v Azure je primárním typem uzlu ten, který spouští zásobník. Při definování primárního typu uzlu bude Service Fabric automaticky využívat počet uzlů poskytovaných vytvořením až devíti počátečních uzlů a sedmi replik každé systémové služby. Pokud sada náhodných selhání vychytá většinu těchto replik současně, systémové služby zasánou ztrátu kvora. Pokud dojde ke ztrátě většiny předimových uzlů, cluster se brzy po ukončení 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 vysokou dostupnost. Microsoft k těmto tématům publikoval velké množství pokynů. 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 Service Fabric kontextu:
  • Kontrolní seznam k dostupnosti
  • Postup zotavení po havárii
  • Zotavení po havárii a vysoká dostupnost pro aplikace Azure
• Přečtěte si Service Fabric možnosti podpory.