Share via

Vészhelyreállítás az Azure Service Fabricben

  • Cikk

A magas rendelkezésre állás biztosításának kritikus része annak biztosítása, hogy a szolgáltatások képesek legyenek túlélni a különböző típusú hibákat. Ez különösen fontos a nem tervezett és a kontrollon kívüli hibák esetén.

Ez a cikk néhány gyakori hibamódot ismertet, amelyek vészhelyzetek lehetnek, ha nincsenek megfelelően modellve és kezelve. Emellett ismerteti azokat a kockázatcsökkentéseket és műveleteket is, amelyeket katasztrófa esetén el kell végezni. A cél az állásidő vagy az adatvesztés kockázatának korlátozása vagy kiküszöbölése, ha hibák, tervezett vagy egyéb hibák történnek.

A katasztrófa elkerülése

Az Azure Service Fabric fő célja, hogy segítsen a környezet és a szolgáltatások oly módon történő modellezésében, hogy a gyakori hibatípusok ne legyenek katasztrófák.

Általában kétféle katasztrófa-/meghibásodási forgatókönyv létezik:

  • Hardver- és szoftverhibák
  • Működési hibák

Hardver- és szoftverhibák

A hardver- és szoftverhibák kiszámíthatatlanok. A hibák túlélésének legegyszerűbb módja a szolgáltatás több példányának futtatása a hardver- vagy szoftverhibahatárok között.

Ha például a szolgáltatás csak egy gépen fut, az adott gép meghibásodása az adott szolgáltatás szempontjából katasztrófa. A katasztrófa elkerülésének egyszerű módja annak biztosítása, hogy a szolgáltatás több gépen fusson. Tesztelésre is szükség van annak biztosításához, hogy egy gép meghibásodása ne zavarja meg a futó szolgáltatást. A kapacitástervezés biztosítja, hogy máshol is létre lehessen hozni egy cserepéldányt, és hogy a kapacitás csökkenése ne terhelje túl a fennmaradó szolgáltatásokat.

Ugyanez a minta működik, függetlenül attól, hogy mit próbál elkerülni a hiba. Ha például egy SAN hibája miatt aggódik, több SAN-ra is futtathat. Ha aggódik egy kiszolgálóállvány elvesztése miatt, több állványon fut. Ha aggódik az adatközpontok elvesztése miatt, a szolgáltatásnak több Azure-régióban, több Azure-Availability Zones vagy saját adatközpontokban kell futnia.

Ha egy szolgáltatás több fizikai példányra (gépekre, állványokra, adatközpontokra, régiókra) terjed ki, akkor is előfordulhatnak egyidejű hibák. Egy adott típusú hiba (például egyetlen virtuális gép vagy hálózati kapcsolat meghibásodása) kezelése azonban automatikusan megtörténik, és így már nem "katasztrófa".

A Service Fabric mechanizmusokat biztosít a fürt bővítéséhez, és kezeli a sikertelen csomópontok és szolgáltatások visszaállítását. A Service Fabric emellett lehetővé teszi a szolgáltatások számos példányának futtatását, hogy megakadályozza a nem tervezett hibák valódi katasztrófákká való alakítását.

Előfordulhat, hogy nem valósítható meg egy olyan üzemelő példány futtatása, amely elég nagy a hibák lefedéséhez. Előfordulhat például, hogy több hardvererőforrást vesz igénybe, mint amennyit hajlandó fizetni a meghibásodás esélyéhez képest. Ha elosztott alkalmazásokkal foglalkozik, a földrajzi távolságok közötti további kommunikációs ugrások vagy állapotreplikációs költségek elfogadhatatlan késést okozhatnak. A sor rajzolása az egyes alkalmazások esetében eltérő.

Konkrétan szoftverhibák esetén előfordulhat, hogy a hiba a skálázni kívánt szolgáltatásban van. Ebben az esetben a több példány nem akadályozza meg a katasztrófát, mert a hibaállapot az összes példányban korrelál.

Működési hibák

Még akkor is katasztrofális eseményeket tapasztalhat, ha a szolgáltatása szerte a világon sok redundanciával rendelkezik. Előfordulhat például, hogy valaki véletlenül újrakonfigurálja a szolgáltatás DNS-nevét, vagy azonnal törli azt.

Tegyük fel például, hogy volt egy állapotalapú Service Fabric-szolgáltatása, és valaki véletlenül törölte a szolgáltatást. Hacsak nincs más megoldás, akkor a szolgáltatás és az összes állapot, amely már nem érhető el. Az ilyen típusú operatív katasztrófák ("hoppá") a rendszeres nem tervezett hibáktól eltérő kockázatcsökkentést és helyreállítási lépéseket igényelnek.

Az ilyen típusú működési hibák elkerülésének legjobb módjai a következők:

  • A környezethez való operatív hozzáférés korlátozása.
  • Szigorúan naplózd a veszélyes műveleteket.
  • Automatizálást kényszeríthet ki, megakadályozhatja a manuális vagy sávon kívüli módosításokat, és érvényesítheti az adott módosításokat a környezeten, mielőtt életbe lépteti őket.
  • Győződjön meg arról, hogy a romboló műveletek "helyreállíthatóak". A helyreállítható műveletek nem lépnek érvénybe azonnal, vagy egy időkereten belül visszavonhatók.

A Service Fabric olyan mechanizmusokat biztosít, amelyek megakadályozzák a működési hibákat, például szerepköralapú hozzáférés-vezérlést biztosítanak a fürtműveletekhez. A működési hibák többségéhez azonban szervezeti erőfeszítésekre és más rendszerekre van szükség. A Service Fabric mechanizmusokat biztosít a működési hibák túléléséhez, különösen az állapotalapú szolgáltatások biztonsági mentéséhez és visszaállításához.

Hibák kezelése

A Service Fabric célja a hibák automatikus kezelése. Bizonyos típusú hibák kezeléséhez azonban a szolgáltatásoknak további kóddal kell rendelkezniük. Biztonsági és üzletmenet-folytonossági okokból nem szabad automatikusan kezelni az egyéb típusú hibákat.

Önálló hibák kezelése

Az önálló gépek sokféle okból meghiúsulhatnak. Néha hardveres okok, például tápegységek és hálózati hardverhibák. Más hibák a szoftverben vannak. Ezek közé tartoznak az operációs rendszer és maga a szolgáltatás hibái. A Service Fabric automatikusan észleli az ilyen típusú hibákat, beleértve azokat az eseteket is, amikor a gép hálózati problémák miatt el lesz különítve a többi géptől.

A szolgáltatás típusától függetlenül egyetlen példány futtatása állásidőt eredményez a szolgáltatás számára, ha a kód egyetlen példánya bármilyen okból meghiúsul.

Az egyetlen hiba kezeléséhez a legegyszerűbb, ha biztosítja, hogy a szolgáltatások alapértelmezés szerint több csomóponton fussanak. Állapot nélküli szolgáltatások esetén győződjön meg arról, hogy InstanceCount az 1-nél nagyobb. Állapotalapú szolgáltatások esetén a minimális javaslat az, hogy TargetReplicaSetSize és MinReplicaSetSize mindkettő 3-ra van állítva. A szolgáltatáskód további példányainak futtatása biztosítja, hogy a szolgáltatás képes automatikusan kezelni az egyetlen hibát.

Koordinált hibák kezelése

A fürtök koordinált hibáit okozhatják a tervezett vagy nem tervezett infrastruktúrahibák és -módosítások, illetve a tervezett szoftvermódosítások. A Service Fabric olyan infrastruktúra-zónákat modellez, amelyek hibatartományként koordinált hibákat tapasztalnak. Az összehangolt szoftvermódosításokat tapasztaló területek frissítési tartományokként vannak modellezve. A tartalék tartományokról, a frissítési tartományokról és a fürttopológiáról további információt a Service Fabric-fürt leírása a fürt Resource Manager használatával című témakörben talál.

Alapértelmezés szerint a Service Fabric a tartalék és frissítési tartományokat veszi figyelembe a szolgáltatások futtatásának megtervezésekor. Alapértelmezés szerint a Service Fabric megpróbálja biztosítani, hogy a szolgáltatások több tartalék és frissítési tartományon fussanak, így ha tervezett vagy nem tervezett módosítások történnek, a szolgáltatások továbbra is elérhetők maradnak.

Tegyük fel például, hogy egy áramforrás meghibásodása miatt az állvány összes gépe egyszerre meghibásodik. Ha a szolgáltatás több példánya fut, a tartalék tartomány számos gépének elvesztése csak egy példa lehet egy szolgáltatás meghibásodására. Ezért kritikus fontosságú a tartalék és frissítési tartományok kezelése a szolgáltatások magas rendelkezésre állásának biztosításához.

Amikor a Service Fabricet az Azure-ban futtatja, a rendszer automatikusan kezeli a tartalék tartományokat és a frissítési tartományokat. Más környezetekben előfordulhat, hogy nem. Ha saját fürtöket hoz létre a helyszínen, ügyeljen arra, hogy megfelelően képezze le és tervezze meg a tartalék tartomány elrendezését.

A frissítési tartományok olyan modellezési területeken hasznosak, ahol a szoftvereket egyszerre frissítik. Emiatt a frissítési tartományok gyakran meghatározzák azokat a határokat is, ahol a szoftver lekerül a tervezett frissítések során. A Service Fabric és a szolgáltatások frissítései is ugyanazt a modellt követik. A működés közbeni frissítésekkel, a frissítési tartományokkal és a Service Fabric állapotmodellel kapcsolatos további információkért, amelyek segítenek megakadályozni, hogy a nem kívánt módosítások hatással legyen a fürtre és a szolgáltatásra, lásd:

A fürt elrendezését a Service Fabric Explorer elérhető fürttérkép használatával jelenítheti meg:

A csomópontok a tartalék tartományok között oszlanak el a Service Fabric Explorer

Megjegyzés

A meghibásodási területek modellezése, a működés közbeni frissítések, a szolgáltatáskód és az állapot számos példányának futtatása, az elhelyezési szabályok, amelyek biztosítják, hogy a szolgáltatások hiba- és frissítési tartományokon fussanak, és a beépített állapotfigyelés csak néhány olyan szolgáltatás, amelyet a Service Fabric biztosít, hogy a normál működési problémák és hibák ne forduljanak át katasztrófákká.

Egyidejű hardver- vagy szoftverhibák kezelése

Egyszeres hibákról beszéltünk. Amint láthatja, az állapot nélküli és az állapotalapú szolgáltatások esetében is könnyen kezelhetők, ha a kód (és állapot) több példányát futtatja a tartalék és a frissítési tartományok között.

Több egyidejű véletlenszerű hiba is előfordulhat. Ezek valószínűleg állásidőhöz vagy tényleges katasztrófához vezetnek.

Állapot nélküli szolgáltatások

Az állapot nélküli szolgáltatások példányainak száma azt jelzi, hogy hány példányt kell futtatni. Ha a példányok bármelyike (vagy az összes) meghibásodik, a Service Fabric úgy válaszol, hogy automatikusan létrehoz helyettesítő példányokat más csomópontokon. A Service Fabric mindaddig nem hoz létre cseréket, amíg a szolgáltatás vissza nem kerül a kívánt példányszámra.

Tegyük fel például, hogy az állapot nélküli szolgáltatás InstanceCount értéke -1. Ez az érték azt jelenti, hogy a fürt minden csomópontján egy példánynak kell futnia. Ha egyes példányok meghibásodnak, a Service Fabric észleli, hogy a szolgáltatás nem a kívánt állapotban van, és megpróbálja létrehozni a példányokat azokon a csomópontokon, amelyekről hiányoznak.

Állapotalapú szolgáltatások

Az állapotalapú szolgáltatásoknak két típusa van:

  • Állapotalapú, megőrzött állapottal.
  • Állapotalapú, nem megőrzött állapottal. (Az állapot a memóriában van tárolva.)

Az állapotalapú szolgáltatás meghibásodásából való helyreállítás az állapotalapú szolgáltatás típusától, a szolgáltatás replikáinak mennyiségétől és a sikertelen replikák mennyiségétől függ.

Állapotalapú szolgáltatásban a rendszer replikálja a bejövő adatokat a replikák között (az elsődleges és az aktív másodpéldányok között). Ha a replikák többsége megkapja az adatokat, az adatok kvórumban véglegesítettnek minősülnek. (Öt replika esetén a három kvórum lesz.) Ez azt jelenti, hogy a replikáknak legalább kvóruma lesz a legújabb adatokkal. Ha a replikák sikertelenek (például ötből kettő), a kvórumérték használatával kiszámíthatjuk, hogy helyre tudunk-e állni. (Mivel az öt replikából a fennmaradó három továbbra is működik, garantált, hogy legalább egy replika teljes adatokkal fog rendelkezni.)

Ha a replikák kvóruma sikertelen, a partíció kvórumveszteség-állapotúnak lesz deklarálva. Tegyük fel, hogy egy partíció öt replikával rendelkezik, ami azt jelenti, hogy legalább három garantáltan teljes adatokkal rendelkezik. Ha a replikák kvóruma (ötből három) sikertelen, a Service Fabric nem tudja megállapítani, hogy a fennmaradó replikák (ötből kettő) elegendő adattal rendelkeznek-e a partíció visszaállításához. Azokban az esetekben, amikor a Service Fabric kvórumvesztést észlel, az alapértelmezett viselkedése az, hogy megakadályozza a partíció további írásait, deklarálja a kvórumvesztést, és várja meg a replikák kvórumának visszaállítását.

Annak meghatározása, hogy katasztrófa történt-e egy állapotalapú szolgáltatás esetében, majd annak kezelése három szakaszból áll:

  1. Annak megállapítása, hogy volt-e kvórumvesztés vagy sem.

    A kvórumvesztés akkor lesz deklarálva, ha egy állapotalapú szolgáltatás replikáinak többsége egyszerre nem működik.

  2. Annak megállapítása, hogy a kvórumvesztés tartós-e vagy sem.

    A legtöbb esetben a hibák átmenetiek. A folyamatok újraindulnak, a csomópontok újraindulnak, a virtuális gépek újraindulnak, és a hálózati partíciók javítva lesznek. Néha azonban a hibák állandóak. Az, hogy a hibák véglegesek-e vagy sem, attól függ, hogy az állapotalapú szolgáltatás megőrzi-e az állapotát, vagy csak a memóriában tartja-e:

    • A tartós állapotú szolgáltatások esetében a kvórum vagy több replika meghibásodása azonnal végleges kvórumvesztést eredményez. Ha a Service Fabric kvórumvesztést észlel egy állapotalapú, nem állandó szolgáltatásban, azonnal a 3. lépésre lép a (lehetséges) adatvesztés deklarálásával. Az adatvesztéssel való továbblépés logikus, mert a Service Fabric tudja, hogy nincs értelme arra várni, hogy a replikák visszatérjenek. Még ha helyre is állnak, az adatok elvesznek a szolgáltatás nem tartós jellege miatt.
    • Állapotalapú állandó szolgáltatások esetén a kvórum vagy több replika hibája miatt a Service Fabric megvárja, amíg a replikák visszatérnek, és visszaállítják a kvórumot. Ez szolgáltatáskimaradást eredményez a szolgáltatás érintett partíciójára (vagy replikakészletére) irányuló írások esetében. Az olvasások azonban továbbra is lehetségesek a korlátozott konzisztenciagaranciával. A Service Fabric által a kvórum visszaállítására váró alapértelmezett idő végtelen, mivel a folytatás (potenciális) adatvesztési esemény, és egyéb kockázatokat is hordoz. Ez azt jelenti, hogy a Service Fabric csak akkor lép tovább a következő lépésre, ha a rendszergazda lépéseket tesz az adatvesztés deklarálása érdekében.

  3. Annak meghatározása, hogy az adatok elvesznek-e, és visszaállítás a biztonsági másolatokból.

    Ha a kvórumvesztést deklarálták (akár automatikusan, akár rendszergazdai művelettel), a Service Fabric és a szolgáltatások továbbhaladnak annak megállapítására, hogy az adatok valóban elvesztek-e. Ezen a ponton a Service Fabric azt is tudja, hogy a többi replika nem tér vissza. Ez volt a döntés, amikor abbahagytuk a kvórumvesztés feloldását. A szolgáltatás számára általában az a legjobb megoldás, ha lefagy, és megvárja az adott rendszergazdai beavatkozást.

    Amikor a Service Fabric meghívja a OnDataLossAsync metódust, az mindig adatvesztés gyanúja miatt történik. A Service Fabric biztosítja, hogy a hívás a legjobb fennmaradó replikára érkezik. Ez az a replika, amelyik a legnagyobb előrehaladást hajtotta végre.

    A gyanús adatvesztés oka mindig az, hogy lehetséges, hogy a fennmaradó replika ugyanolyan állapotban van, mint az elsődlegesé a kvórum elvesztésekor. Anélkül azonban, hogy ez az állapot összehasonlítható lenne, a Service Fabric és az operátorok nem tudják biztosan.

    Mit tesz tehát a OnDataLossAsync metódus egy tipikus implementációja?

    1. Az aktivált megvalósítási naplók OnDataLossAsync aktiválódnak, és elindítja a szükséges felügyeleti riasztásokat.

    2. A végrehajtás általában szünetel, és megvárja a további döntések és manuális műveletek végrehajtását. Ennek az az oka, hogy még ha rendelkezésre állnak is biztonsági másolatok, előfordulhat, hogy elő kell készíteni őket.

      Ha például két különböző szolgáltatás koordinálja az adatokat, előfordulhat, hogy módosítani kell ezeket a biztonsági másolatokat annak érdekében, hogy a visszaállítás után a két szolgáltatás számára fontos információk konzisztensek legyenek.

    3. Gyakran más telemetriai adatok vagy kimerítő adatok is vannak a szolgáltatásból. Ezek a metaadatok más szolgáltatásokban vagy naplókban is szerepelhetnek. Ezek az információk szükség szerint felhasználhatók annak megállapítására, hogy voltak-e fogadott és feldolgozott hívások az elsődleges helyen, amelyek nem voltak jelen a biztonsági másolatban, vagy replikálva voltak erre az adott replikára. Előfordulhat, hogy a visszaállítás előtt ezeket a hívásokat vissza kell játszani vagy hozzá kell adni a biztonsági mentéshez.

    4. Az implementáció összehasonlítja a fennmaradó replika állapotát az elérhető biztonsági másolatokban található állapotokkal. Ha megbízható Service Fabric-gyűjteményeket használ, ehhez rendelkezésre állnak eszközök és folyamatok . A cél annak ellenőrzése, hogy a replikán belül elegendő-e az állapot, és hogy mi hiányzik a biztonsági másolatból.

    5. Az összehasonlítás befejezése és a visszaállítás befejezése (ha szükséges) után a szolgáltatáskódnak igaz értéket kell visszaadnia, ha bármilyen állapotváltozás történt. Ha a replika megállapította, hogy ez az állapot legjobban elérhető példánya, és nem végzett módosításokat, a kód hamis értéket ad vissza.

      A true ( igaz ) érték azt jelzi, hogy a többi fennmaradó replika már inkonzisztens lehet ezzel a replikával. A replika elveti és újraépül. A false ( hamis ) érték azt jelzi, hogy nem történt állapotváltozás, így a többi replika megtarthatja azt, amije van.

Kritikus fontosságú, hogy a szolgáltatásszerzők az éles környezetben történő üzembe helyezés előtt gyakorolják a lehetséges adatvesztési és meghibásodási forgatókönyveket. Az adatvesztéssel szembeni védelem érdekében fontos rendszeresen biztonsági másolatot készíteni az állapotalapú szolgáltatások állapotáról egy georedundáns tárolóba.

Gondoskodnia kell arról is, hogy visszaállítsa az állapotot. Mivel számos különböző szolgáltatásról különböző időpontokban készít biztonsági másolatot, gondoskodnia kell arról, hogy a visszaállítás után a szolgáltatások egységesen láthassák egymást.

Vegyük például azt a helyzetet, amikor egy szolgáltatás létrehoz egy számot, és tárolja azt, majd elküldi azt egy másik szolgáltatásnak, amely szintén tárolja azt. A visszaállítás után előfordulhat, hogy a második szolgáltatásban a szám szerepel, de az első nem, mert a biztonsági másolat nem tartalmazza ezt a műveletet.

Ha azt állapítja meg, hogy a fennmaradó replikák nem elegendőek az adatvesztési forgatókönyv folytatásához, és nem tudja rekonstruálni a szolgáltatás állapotát a telemetriából vagy a kimerítésből, a biztonsági mentések gyakorisága határozza meg a lehető legjobb helyreállításipont-célkitűzést (RPO). A Service Fabric számos eszközt biztosít a különböző meghibásodási forgatókönyvek teszteléséhez, beleértve az állandó kvórumot és az adatvesztést, amely biztonsági másolatból történő visszaállítást igényel. Ezek a forgatókönyvek a Service Fabric hibaelemző szolgáltatás által felügyelt tesztelhetőségi eszközeinek részeként szerepelnek. További információ ezekről az eszközökről és mintákról: Bevezetés a hibaelemzési szolgáltatásba.

Megjegyzés

A rendszerszolgáltatások kvórumvesztést is szenvedhetnek. A hatás a szóban forgó szolgáltatásra jellemző. Például az elnevezési szolgáltatás kvórumvesztése hatással van a névfeloldásra, míg a Feladatátvétel-kezelő szolgáltatás kvórumvesztése letiltja az új szolgáltatások létrehozását és feladatátvételét.

A Service Fabric rendszerszolgáltatásai ugyanazt a mintát követik, mint az állapotkezeléshez használt szolgáltatások, de nem javasoljuk, hogy próbálja meg áthelyezni őket a kvórumvesztésből és a lehetséges adatvesztésbe. Ehelyett azt javasoljuk, hogy kérjen támogatást , hogy olyan megoldást találjon, amely az Ön helyzetére irányul. Általában célszerű egyszerűen megvárni, amíg a leállású replikák visszatérnek.

Kvórumvesztés hibaelhárítása

A replikák átmeneti hiba miatt időnként leállhatnak. Várjon egy ideig, amikor a Service Fabric megpróbálja felhozni őket. Ha a replikák a vártnál hosszabb ideig leálltak, kövesse az alábbi hibaelhárítási műveleteket:

  • Előfordulhat, hogy a replikák összeomlanak. Ellenőrizze a replikaszintű állapotjelentéseket és az alkalmazásnaplókat. Gyűjtse össze az összeomlási memóriaképeket, és tegyen meg minden szükséges műveletet a helyreállításhoz.
  • Előfordulhat, hogy a replikafolyamat nem válaszol. Ennek ellenőrzéséhez vizsgálja meg az alkalmazásnaplókat. Gyűjtse össze a folyamatképeket, majd állítsa le a nem válaszoló folyamatot. A Service Fabric létrehoz egy helyettesítő folyamatot, és megpróbálja visszahozni a replikát.
  • Előfordulhat, hogy a replikákat üzemeltető csomópontok leállnak. Indítsa újra a mögöttes virtuális gépet a csomópontok üzembe helyezéséhez.

Néha előfordulhat, hogy nem lehet helyreállítani a replikákat. Például a meghajtók meghibásodtak, vagy a gépek fizikailag nem válaszolnak. Ezekben az esetekben meg kell adni a Service Fabricnek, hogy ne várjon a replika helyreállítására.

Ne használja ezeket a módszereket, ha a lehetséges adatvesztés elfogadhatatlan a szolgáltatás online állapotba hozásához. Ebben az esetben minden erőfeszítést meg kell tenni a fizikai gépek helyreállítása érdekében.

Az alábbi műveletek adatvesztést okozhatnak. Ellenőrizze, mielőtt követi őket.

Megjegyzés

Ezeket a metódusokat soha nem biztonságos használni, csak célzott módon adott partíciókhoz.

  • Használja a vagy System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) az Repair-ServiceFabricPartition -PartitionId API-t. Ez az API lehetővé teszi a partíció azonosítójának megadását a kvórumveszteségből és a lehetséges adatvesztésbe való áthelyezéshez.
  • Ha a fürt olyan gyakori hibákat tapasztal, amelyek miatt a szolgáltatások kvórumveszteség-állapotba kerülnek, és a lehetséges adatvesztés elfogadható, a megfelelő KvórumLossWaitDuration érték megadása segíthet a szolgáltatás automatikus helyreállításában. A Service Fabric a helyreállítás előtt megvárja a megadott QuorumLossWaitDuration értéket (az alapértelmezett érték végtelen). Ez a módszer nem ajánlott, mert váratlan adatvesztést okozhat.

A Service Fabric-fürt rendelkezésre állása

A Service Fabric-fürt általában egy nagy mértékben elosztott környezet, egyetlen meghibásodási pont nélkül. Egy csomópont meghibásodása nem okoz rendelkezésre állási vagy megbízhatósági problémákat a fürt számára, elsősorban azért, mert a Service Fabric rendszerszolgáltatásai ugyanazokat az irányelveket követik, mint korábban. Ez azt jelzi, hogy alapértelmezés szerint mindig három vagy több replikával futnak, és az állapot nélküli rendszerszolgáltatások minden csomóponton futnak.

A mögöttes Service Fabric hálózatkezelési és hibaészlelési rétegek teljes mértékben el vannak osztva. A rendszerszolgáltatások többsége újraépíthető a fürt metaadataiból, vagy tudja, hogyan lehet más helyekről újraszinkronizálni az állapotukat. A fürt rendelkezésre állása sérülhet, ha a rendszerszolgáltatások kvórumvesztési helyzetekbe kerülnek, mint a korábban leírtak. Ezekben az esetekben előfordulhat, hogy bizonyos műveleteket nem tud végrehajtani a fürtön (például egy frissítés indítását vagy új szolgáltatások üzembe helyezését), de maga a fürt továbbra is működik.

A futó fürtök szolgáltatásai továbbra is ilyen körülmények között futnak, kivéve, ha írást igényelnek a rendszerszolgáltatásoknak a működés folytatásához. Ha például a Feladatátvétel-kezelő kvórumvesztésben van, az összes szolgáltatás továbbra is futni fog. A sikertelen szolgáltatások azonban nem fognak tudni automatikusan újraindulni, mert ehhez a Feladatátvétel-kezelő bevonása szükséges.

Adatközpont vagy Azure-régió hibái

Ritkán előfordulhat, hogy egy fizikai adatközpont átmenetileg elérhetetlenné válik áramkimaradás vagy hálózati kapcsolat elvesztése miatt. Ezekben az esetekben az adott adatközpontban vagy Azure-régióban lévő Service Fabric-fürtök és -szolgáltatások nem lesznek elérhetők. Az adatok azonban megmaradnak.

Az Azure-ban futó fürtök esetében az Azure állapotlapján megtekintheti a kimaradások frissítéseit. Abban az esetben, ha egy fizikai adatközpont részben vagy teljesen megsemmisül, az ott üzemeltetett Service Fabric-fürtök vagy a bennük található szolgáltatások elveszhetnek. Ez a veszteség magában foglalja azokat az állapotokat, amelyekről nem készít biztonsági másolatot az adatközponton vagy régión kívül.

Több különböző stratégia létezik egy adatközpont vagy régió állandó vagy tartós meghibásodásának túlélésére:

  • Futtasson különálló Service Fabric-fürtöket több ilyen régióban, és használjon valamilyen mechanizmust a környezetek közötti feladatátvételhez és feladat-visszavételhez. Ez a többfürtből álló aktív/aktív vagy aktív/passzív modell további felügyeleti és üzemeltetési kódot igényel. Ehhez a modellhez szükség van az egyik adatközpontban vagy régióban található szolgáltatások biztonsági mentéseinek összehangolására is, hogy azok más adatközpontokban vagy régiókban is elérhetők legyenek, ha az egyik meghibásodik.

  • Futtasson egyetlen Service Fabric-fürtöt, amely több adatközpontra is kiterjed. A stratégia minimálisan támogatott konfigurációja három adatközpont. További információ: Service Fabric-fürt üzembe helyezése Availability Zones.

    Ez a modell további beállításokat igényel. Az előnye azonban az, hogy egy adatközpont meghibásodása katasztrófahelyzetből normál meghibásodássá alakul át. Ezeket a hibákat az egyetlen régión belüli fürtök esetében működő mechanizmusok képesek kezelni. A tartalék tartományok, a frissítési tartományok és a Service Fabric elhelyezési szabályai biztosítják a számítási feladatok elosztását, hogy elviselhessék a normál hibákat.

    Az ilyen típusú fürtök szolgáltatásainak üzemeltetését segítő szabályzatokról további információt a Service Fabric-szolgáltatások elhelyezési szabályzatai című témakörben talál.

  • Futtasson egyetlen Service Fabric-fürtöt, amely több régióra is kiterjed az önálló modellel. Az ajánlott régiók száma három. Az önálló Service Fabric beállításával kapcsolatos részletekért lásd: Önálló fürt létrehozása .

Fürthibákhoz vezető véletlenszerű hibák

A Service Fabric a magcsomópontok fogalmával rendelkezik. Ezek olyan csomópontok, amelyek fenntartják a mögöttes fürt rendelkezésre állását.

A magcsomópontok segítenek biztosítani, hogy a fürt a többi csomóponttal való bérletek létrehozásával és bizonyos típusú hibák esetén tiebreakerként működjön. Ha a véletlenszerű hibák eltávolítják a fürt magcsomópontjainak többségét, és nem kerülnek vissza gyorsan, a fürt automatikusan leáll. A fürt ezután meghiúsul.

Az Azure-ban a Service Fabric-erőforrás-szolgáltató kezeli a Service Fabric-fürtkonfigurációkat. Alapértelmezés szerint az erőforrás-szolgáltató a magcsomópontokat az elsődleges csomóponttípus tartalék és frissítési tartományai között osztja el. Ha az elsődleges csomóponttípus Ezüst vagy Arany tartósságúként van megjelölve, amikor eltávolít egy magcsomópontot (vagy az elsődleges csomóponttípus skálázásával vagy manuálisan eltávolítja), a fürt megpróbál előléptetni egy másik nem magos csomópontot az elsődleges csomóponttípus rendelkezésre álló kapacitásából. Ez a kísérlet sikertelen lesz, ha kevesebb kapacitással rendelkezik, mint amennyit a fürt megbízhatósági szintje igényel az elsődleges csomóponttípushoz.

A különálló Service Fabric-fürtökben és az Azure-ban az elsődleges csomóponttípus az, amely a magokat futtatja. Amikor elsődleges csomóponttípust definiál, a Service Fabric automatikusan kihasználja a rendelkezésre álló csomópontok számát, és legfeljebb kilenc magcsomópontot és minden rendszerszolgáltatás hét replikáját hozza létre. Ha a véletlenszerű hibák egy halmaza egyszerre veszi ki a replikák többségét, a rendszerszolgáltatások kvórumvesztést jeleznek. Ha a magcsomópontok többsége elveszik, a fürt hamarosan leáll.

Következő lépések