Zotavení po havárii v Azure Service Fabric

  • Článek

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

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

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 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 spuštění více kopií služby napříč hranicemi chyb hardwaru nebo softwaru.

Pokud je například vaše služba spuštěná jenom na jednom počítači, znamená selhání tohoto počítače pro tuto službu havárii. 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, že náhradní instanci je možné vytvořit jinde a že snížení kapacity nepřetíží zbývající služby.

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

Pokud je služba rozložená napříč několika fyzickými instancemi (počítače, racky, datacentra, oblasti), stále dochází k některým typům souběžných selhání. Ale jedno a dokonce i více selhání určitého typu (například selhání jednoho virtuálního počítače nebo síťového propojení) se automaticky zpracovávají, takže už nejde o "havárii".

Service Fabric poskytuje mechanismy pro rozšíření clusteru a zpracovává, jak vrátit uzly a služby, které selhaly. Service Fabric také umožňuje spouštět mnoho instancí vašich služeb, aby se neplánovaná selhání přepnula do skutečných havárií.

Můžou existovat důvody, proč není možné spustit nasazení dostatečně velké na to, aby bylo možné provést selhání. Může například trvat více hardwarových prostředků, než jste ochotni platit, vzhledem k pravděpodobnosti selhání. Když pracujete s distribuovanými aplikacemi, další komunikační směrování nebo náklady na replikaci stavu napříč geografickými vzdálenostmi můžou způsobit nepřijatelnou latenci. Místo, kde je tato čára nakreslena, 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 tomto případě více kopií nezabrání havárii, protože stav selhání je korelovaný napříč všemi instancemi.

Provozní chyby

I když je vaše služba rozprostíráná po celém světě s mnoha propouštěními, může stále 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 a někdo ji omylem odstranil. Pokud nedojde k nějakému dalšímu zmírnění rizik, tato služba a veškerý stav, který měla, jsou teď pryč. Tyto typy provozních havárií vyžadují jiná zmírnění 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, je:

  • Omezte provozní přístup k prostředí.
  • Přísně auditujte nebezpečné operace.
  • Vynucujte automatizaci, zabraňte ručním nebo out-of-band změnám a před jejich provedením ověřte konkrétní změny v prostředí.
  • Ujistěte se, že destruktivní operace jsou "měkké". Měkké operace se neprojeví okamžitě nebo je můžete vrátit zpět během časového intervalu.

Service Fabric poskytuje mechanismy, které zabraňují provozním chybám, jako je například 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 však mohly služby zpracovat některé typy selhání, musí mít další kód. Jiné typy selhání by se z bezpečnostních důvodů a provozní kontinuity neměly automaticky řešit.

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 zdroje napájení a selhání síťového hardwaru. Další selhání jsou v softwaru. Patří mezi ně selhání operačního systému a samotné služby. Service Fabric automaticky detekuje tyto typy selhání, 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 vyřešit jedno 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 TargetReplicaSetSizeMinReplicaSetSize minimální doporučení nastaveno na hodnotu 3. Spuštěním více kopií kódu služby zajistíte, že služba dokáže automaticky zpracovat jednotlivá 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 selháními a změnami infrastruktury nebo plánovanými změnami softwaru. Service Fabric modeluje zóny infrastruktury, u které dochází ke koordinovaným selháním jako doménám selhání. Oblasti, u kterých dojde ke koordinovaným změnám softwaru, se modelují jako upgradované domény. Další informace o doménách selhání, doménách upgradu a topologii clusteru najdete v tématu Popis clusteru Service Fabric pomocí clusteru Resource Manager.

Service Fabric ve výchozím nastavení při plánování, kde by se vaše služby měly spouštět, bere v úvahu domény selhání a upgradů. Ve výchozím nastavení se Service Fabric snaží zajistit, aby vaše služby běžely v několika doménách 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 současně selžou všechny počítače v racku. Když je spuštěno více kopií služby, ztráta mnoha počítačů v selhání domény se změní na jen další příklad jednoho selhání služby. Proto je správa domén selhání a upgradů důležitá pro zajištění vysoké dostupnosti vašich služeb.

Pokud používáte Service Fabric v Azure, domény selhání a upgradované domény se 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í.

Upgradovací domény jsou užitečné pro oblasti modelování, ve kterých se současně upgraduje software. Z tohoto důvodu upgradované domény také často definují hranice, kde je software během plánovaných upgradů odebrán. Upgrady Service Fabric i vašich služeb se řídí stejným modelem. Další informace o upgradech se zajištěním provozu, upgradových doménách a modelu stavu Service Fabric, které pomáhají zabránit tomu, aby nezamýšlené změny ovlivnily cluster a vaši službu, najdete tady:

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

Uzly rozložené mezi domény selhání v Service Fabric Explorer

Poznámka

Modelování oblastí selhání, postupné upgrady, spouštění mnoha instancí kódu a stavu služby, pravidla umístění, která zajistí, aby vaše služby běžely napříč doménami selhání a upgradu, a integrované monitorování stavu jsou jen některé z funkcí, které Service Fabric poskytuje, aby normální provozní problémy a selhání nepřecházení v katastrofy.

Řešení souběžných selhání hardwaru nebo softwaru

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

Může také dojít k několika souběžných náhodným selháním. Ty s větší pravděpodobností povedou k výpadku nebo skutečné havárii.

Bezstavové služby

Počet instancí pro bezstavovou službu označuje požadovaný počet instancí, které je potřeba spustit. Pokud některá (nebo všechny) instance selžou, Service Fabric zareaguje automatickým vytvořením náhradních instancí na jiných uzlech. Service Fabric pokračuje ve vytváření náhrad, dokud se služba nevrátí na požadovaný počet instancí.

Předpokládejme například, že bezstavová služba má InstanceCount hodnotu -1. Tato hodnota znamená, že na každém uzlu v clusteru by měla být spuštěná jedna instance. 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:

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

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

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

Při selhání kvora replik 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 mají zaručeno, že budou mít úplná data. Pokud selže kvorum (tři z pěti) replik, Service Fabric nemůže určit, jestli zbývající repliky (dvě 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 u stavové služby došlo k havárii, a následná správa této havárie, probíhá ve třech fázích:

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

    Ztráta kvora se deklaruje, když je současně mimo provoz 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 síťové oddíly se opraví. Někdy jsou ale selhání trvalá. To, jestli jsou chyby trvalé nebo ne, závisí na tom, jestli stavová služba zachová svůj stav, nebo jestli ji uchovává jenom v paměti:

    • U služeb bez trvalého stavu způsobí selhání kvora nebo více replik okamžitě trvalou ztrátu kvora. Když Service Fabric zjistí ztrátu kvora ve stavové non-trvalé službě, okamžitě přejde ke kroku 3 deklarací (potenciální) ztráty dat. Pokračovat ve ztrátě dat má smysl, protože Service Fabric ví, že nemá smysl čekat, až se repliky vrátí. I když se obnoví, dojde ke ztrátě dat kvůli neudržované povaze služby.
    • U stavových trvalých služeb způsobí selhání kvora nebo více 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 (nebo "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 nekonečná, protože pokračování je událost (potenciální) ztráty dat a nese s sebou další rizika. To znamená, že Service Fabric nepokračuje k dalšímu kroku, pokud správce nepřistoupí k deklaraci ztráty dat.

  3. Určení, jestli dojde ke ztrátě 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řesunou k určení, jestli došlo ke skutečné ztrátě dat. Service Fabric v tuto chvíli také ví, že ostatní repliky se nevrátí. To bylo rozhodnutí, které jsme učinili, když jsme přestali čekat, až se ztráta kvora vyřeší sama. Nejlepší postup pro službu je obvykle zmrazit a počkat na konkrétní administrativní zásah.

    Když Service Fabric volá metodu OnDataLossAsync , důvodem je vždy podezření na ztrátu dat. Service Fabric zajišťuje, že se toto volání doručí do nejlepší zbývající repliky. Jedná se o to, která replika udělala největší pokrok.

    Důvod, proč vždy říkáme podezření na ztrátu dat, je to, že je možné, že zbývající replika má stejný stav jako primární replika při ztrátě kvora. Bez tohoto stavu to ale není dobrý způsob, jak to Service Fabric nebo operátory s jistotou vědět.

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

    1. Implementační protokoly, které OnDataLossAsync se aktivovaly, a aktivuje všechna potřebná upozornění správy.

    2. Implementace se obvykle pozastaví a počká na další rozhodnutí a ruční akce. 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é tyto zálohy upravit, aby se zajistilo, že po obnovení budou informace, které tyto dvě služby zajímají, konzistentní.

    3. Ze služby často dochází k nějaké jiné telemetrii nebo vyčerpání. Tato metadata mohou být obsažena v jiných službách nebo v protokolech. Tyto informace lze podle potřeby použít k určení, jestli se na primárním serveru přijala a zpracovala nějaká volání, která nebyla přítomna v záloze nebo replikována do této konkrétní repliky. Aby bylo možné provést obnovení, může být potřeba tato volání přehrát nebo přidat do zálohy.

    4. Implementace porovnává stav zbývající repliky s stavem obsaženým 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 je stav v replice dostatečný, 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 měl kód služby vrátit hodnotu true , pokud byly provedeny nějaké změny stavu. Pokud replika zjistila, že se jedná o nejlepší dostupnou kopii stavu, a neproprovedla žádné změny, kód vrátí hodnotu false.

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

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

Musíte také zajistit, abyste měli možnost obnovit stav. Vzhledem k tomu, že zálohování mnoha různých služeb se provádí v různých časech, musíte zajistit, aby po obnovení měly vaše služby konzistentní přehled o sobě navzájem.

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

Pokud zjistíte, že zbývající repliky nedostačují 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 poskytuje mnoho nástrojů pro testování různých scénářů selhání, včetně trvalé ztráty kvora a dat, které vyžadují obnovení ze zálohy. Tyto scénáře jsou součástí nástrojů testovatelnosti v Service Fabric, které spravuje služba Fault Analysis Service. Další informace o těchto nástrojích a vzorech najdete v tématu Úvod do služby Analýza chyb.

Poznámka

Systémová služba může také utrpět ztrátu kvora. Dopad je specifický pro danou službu. Například ztráta kvora ve službě pojmenování ovlivňuje překlad názvů, zatímco ztráta kvora ve službě Správce převzetí služeb při selhání blokuje vytváření nových služeb a převzetí služeb při selhání.

Systémové služby Service Fabric se řídí stejným vzorem jako vaše služby pro správu stavu, ale nedoporučujeme, abyste se je snažili přesunout ze ztráty kvora do potenciální ztráty dat. Místo toho doporučujeme vyhledat podporu , abyste našli řešení, které je cílené na vaši situaci. Obvykle je vhodnější jednoduše počkat, až se repliky dolů vrátí.

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

Repliky můžou být přerušovaně mimo provoz kvůli přechodnému selhání. Chvíli počkejte, než se je Service Fabric pokusí vyvolat. Pokud jsou repliky mimo provoz déle, než se čekalo, postupujte podle těchto akcí pro řešení potíží:

  • Repliky můžou chybově docházet. Zkontrolujte sestavy stavu na úrovni repliky a protokoly 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 zastavte nereagující proces. Service Fabric vytvoří proces nahrazení a pokusí se repliku přenést zpět.
  • Uzly, které hostují repliky, můžou být mimo provoz. Restartujte příslušný virtuální počítač, aby se uzly obnovily.

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 inkasovat, aby nečekaly na obnovení repliky.

Tyto metody nepoužívejte , pokud je potenciální ztráta dat nepřijatelná pro uvedení služby do online režimu. V takovém případě by mělo být vynaloženo veškeré úsilí na obnovení fyzických počítačů.

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

Poznámka

Nikdy není bezpečné používat tyto metody jinak než cíleně na konkrétní oddíly.

  • Repair-ServiceFabricPartition -PartitionId Použijte rozhraní API neboSystem.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId). Toto rozhraní API umožňuje zadat ID oddílu, který se má přesunout ze ztráty kvora do potenciální ztráty dat.
  • Pokud v clusteru dochází k častým selháním, která způsobují, že služby přejdou do stavu ztráty kvora a potenciální ztráta dat je přijatelná, zadání vhodné hodnoty QuorumLossWaitDuration může službě pomoct s automatickým obnovením. 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ů způsobujících 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, které jste uvedli dříve. To znamená, že ve výchozím nastavení vždy běží se třemi nebo více replikami a systémové služby, které jsou bezstavové, běží na všech uzlech.

Základní síťové vrstvy Service Fabric a detekce selhání jsou plně distribuované. Většinu systémových služeb je možné znovu sestavit z metadat v clusteru nebo zjistit, jak opětovně 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, jak je popsáno výše. V těchto případech nemusí být možné 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 spuštěný.

Služby ve spuštěném clusteru budou i nadále spuštěné za těchto podmínek, pokud k dalšímu fungování nevyžadují zápisy do systémových služeb. Pokud je například Správce převzetí služeb při selhání ve ztrátě kvora, budou všechny služby dál fungovat. 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é v důsledku výpadku napájení nebo síťového připojení. V těchto případech nebudou vaše clustery a služby Service Fabric v tomto datacentru nebo oblasti Azure k dispozici. Vaše data se ale zachovají.

V případě clusterů běžících v Azure si můžete prohlédnout aktualizace týkající se výpadků na stránce stavu Azure. Ve vysoce nepravděpodobném případě, že dojde k částečnému nebo úplnému zničení fyzického datacentra, může dojít ke ztrátě všech tam hostovaných clusterů Service Fabric nebo služeb v nich. Tato ztráta zahrnuje všechny stavy nezálohované mimo dané datové centrum nebo oblast.

Existuje několik různých strategií, jak přežít trvalé nebo trvalé 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 aktivního/aktivního nebo aktivního/pasivního modelu s více clustery vyžaduje další kód správy a provozu. 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 datacentra. 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 změní z havárie na normální selhání. Tato selhání můžou být řešena mechanismy, které fungují pro clustery v rámci jedné oblasti. Domény selhání, upgradované domény a pravidla umístění Service Fabric zajišťují distribuci úloh tak, aby tolerovala 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.

  • Pomocí samostatného modelu spusťte jeden cluster Service Fabric, který pokrývá více oblastí. 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ím 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 v pořádku tím, že u jiných uzlů vytváří zapůjčení a při určitých typech selhání slouží jako tiebreakery. Pokud náhodná selhání odeberou většinu počátečních uzlů v clusteru a nevrátí se rychle, cluster se automaticky vypne. Cluster pak selže.

V Azure spravuje konfigurace clusteru Service Fabric poskytovatel prostředků Service Fabric. Poskytovatel prostředků ve výchozím nastavení distribuuje počáteční uzly mezi domény selhání a upgrady primárního typu uzlu. Pokud je primární typ uzlu označený jako stříbrná nebo zlatá stálost, cluster se při odebrání počátečního uzlu (škálováním primárního typu uzlu nebo jeho ručním odebráním) pokusí zvýšit úroveň jiného než počátečního uzlu z dostupné kapacity primárního typu uzlu. Tento pokus selže, pokud máte menší dostupnou kapacitu, než vyžaduje úroveň spolehlivosti clusteru pro primární typ uzlu.

V samostatných clusterech Service Fabric i v Azure je primárním typem uzlu ten, který spouští základní uzly. Při definování primárního typu uzlu Service Fabric automaticky využije počet uzlů, který poskytuje, 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í současně vezme většinu těchto replik, dojde u systémových služeb ke ztrátě kvora. Pokud dojde ke ztrátě většiny počátečních uzlů, cluster se brzy poté vypne.

Další kroky