Vészhelyreállítás és geoterjesztés az Azure Durable Functions
A Microsoft arra törekszik, hogy az Azure-szolgáltatások mindig elérhetők legyenek. Előfordulhatnak azonban nem tervezett szolgáltatáskimaradások. Ha az alkalmazás rugalmasságot igényel, a Microsoft azt javasolja, hogy konfigurálja az alkalmazást a georedundancia érdekében. Emellett az ügyfeleknek rendelkezniük kell egy vészhelyreállítási tervvel a regionális szolgáltatáskimaradás kezeléséhez. A vészhelyreállítási terv fontos része, hogy előkészíti a feladatátvételt az alkalmazás és a tár másodlagos replikájára abban az esetben, ha az elsődleges replika elérhetetlenné válik.
A Durable Functions alapértelmezés szerint minden állapot megmarad az Azure Storage-ban. A feladatközpont az Azure Storage-erőforrások logikai tárolója, amelyet vezénylésekhez és entitásokhoz használnak. Az vezénylő, a tevékenység és az entitásfüggvények csak akkor kommunikálhatnak egymással, ha ugyanahhoz a feladatközponthoz tartoznak. Ez a dokumentum a feladatközpontokra fog hivatkozni, amikor az Azure Storage-erőforrások magas rendelkezésre állásának megőrzésére vonatkozó forgatókönyveket ismerteti.
Megjegyzés
A cikkben található útmutató feltételezi, hogy az alapértelmezett Azure Storage-szolgáltatót használja Durable Functions futtatókörnyezeti állapot tárolására. Azonban konfigurálhat más tárolószolgáltatókat is, amelyek máshol tárolják az állapotot, például egy SQL Server-adatbázist. Az alternatív tárolószolgáltatók esetében különböző vészhelyreállítási és geoelosztási stratégiákra lehet szükség. Az alternatív tárolószolgáltatókkal kapcsolatos további információkért tekintse meg a Durable Functions tárolószolgáltatók dokumentációját.
A vezénylések és entitások olyan ügyfélfüggvények használatával indíthatók el, amelyek maguk http-kapcsolaton vagy más támogatott Azure Functions eseményindító-típusokon keresztül aktiválódnak. Ezek a beépített HTTP API-k használatával is aktiválhatók. Az egyszerűség kedvéért ez a cikk az Azure Storage- és HTTP-alapú függvények eseményindítóit érintő forgatókönyvekre, valamint a rendelkezésre állás növelésére és a vészhelyreállítási tevékenységek állásidejének minimalizálására szolgáló lehetőségekre összpontosít. Más eseményindító-típusok, például a Service Bus vagy az Azure Cosmos DB-eseményindítók nem lesznek explicit módon lefedve.
Az alábbi forgatókönyvek Active-Passive konfigurációkon alapulnak, mivel azOkat az Azure Storage használata vezérli. Ez a minta egy biztonsági mentési (passzív) függvényalkalmazás üzembe helyezéséből áll egy másik régióban. A Traffic Manager figyelni fogja az elsődleges (aktív) függvényalkalmazást a HTTP-elérhetőség érdekében. A feladatátvétel a backup függvényalkalmazásba történik, ha az elsődleges feladat meghiúsul. További információ: Az Azure Traffic Managerprioritási Traffic-Routing metódusa.
Megjegyzés
- A javasolt Active-Passive konfiguráció biztosítja, hogy az ügyfél mindig képes új vezényléseket aktiválni HTTP-en keresztül. Annak következtében azonban, hogy két függvényalkalmazás ugyanazt a feladatközpontot használja a tárolóban, néhány háttérbeli tárolási tranzakció el lesz osztva mindkettő között. Ez a konfiguráció ezért többletköltségeket von maga után a másodlagos függvényalkalmazás esetében.
- A mögöttes tárfiók és a feladatközpont az elsődleges régióban jön létre, és mindkét függvényalkalmazás megosztja.
- A redundánsan üzembe helyezett függvényalkalmazásoknak ugyanazokat a függvényhozzáférés-kulcsokat kell használniuk, ha HTTP-kapcsolaton keresztül aktiválódnak. A Functions Runtime egy felügyeleti API-t tesz elérhetővé, amely lehetővé teszi a felhasználók számára a függvénykulcsok programozott hozzáadását, törlését és frissítését. A kulcskezelés az Azure Resource Manager API-k használatával is lehetséges.
1. forgatókönyv – Elosztott terhelésű számítási feladatok megosztott tárterülettel
Ha az Azure számítási infrastruktúrája meghibásodik, előfordulhat, hogy a függvényalkalmazás elérhetetlenné válik. Az ilyen állásidő lehetőségének minimalizálása érdekében ez a forgatókönyv két, különböző régiókban üzembe helyezett függvényalkalmazást használ. A Traffic Manager úgy van konfigurálva, hogy észlelje az elsődleges függvényalkalmazás problémáit, és automatikusan átirányítsa a forgalmat a másodlagos régióban lévő függvényalkalmazásra. Ez a függvényalkalmazás ugyanazt az Azure Storage-fiókot és feladatközpontot használja. Ezért a függvényalkalmazások állapota nem vész el, és a munka a szokásos módon folytatódhat. Miután visszaállította az állapotot az elsődleges régióba, az Azure Traffic Manager automatikusan elindítja az adott függvényalkalmazásra irányuló útválasztási kéréseket.
Ennek az üzembe helyezési forgatókönyvnek több előnye is van:
- Ha a számítási infrastruktúra meghibásodik, a munka adatvesztés nélkül folytatódhat a feladatátvételi régióban.
- A Traffic Manager automatikusan elvégzi az automatikus feladatátvételt az kifogástalan állapotú függvényalkalmazásba.
- A Traffic Manager automatikusan újra létrehozza a forgalmat az elsődleges függvényalkalmazás felé a szolgáltatáskimaradás kijavítása után.
Ennek a forgatókönyvnek a használata azonban megfontolandó:
- Ha a függvényalkalmazás dedikált App Service-csomaggal van üzembe helyezve, a számítási infrastruktúra replikálása a feladatátvételi adatközpontban növeli a költségeket.
- Ez a forgatókönyv a számítási infrastruktúrában bekövetkező kimaradásokra vonatkozik, de a tárfiók továbbra is a függvényalkalmazás meghibásodási pontja marad. Storage-szolgáltatáskimaradás esetén az alkalmazás állásidőt szenved.
- Ha a függvényalkalmazás feladatátvételt kap, nagyobb lesz a késés, mivel a tárfiókhoz a régiók között fog hozzáférni.
- A tárolási szolgáltatás egy másik régióból való elérése magasabb költségekkel jár a hálózati kimenő forgalom miatt.
- Ez a forgatókönyv a Traffic Managertől függ. Figyelembe véve a Traffic Manager működését, előfordulhat, hogy egy tartós függvényt használó ügyfélalkalmazásnak újra le kell kérdeznie a függvényalkalmazás címét a Traffic Managerből.
Megjegyzés
A Durable Functions bővítmény 2.3.0-s verziójától kezdve két függvényalkalmazás biztonságosan futtatható egyszerre ugyanazzal a tárfiókkal és feladatközpont-konfigurációval. Az első elindítandó alkalmazás egy alkalmazásszintű blobbérletet szerez be, amely megakadályozza, hogy más alkalmazások üzeneteket lopjanak el a feladatközpont üzenetsoraiból. Ha az első alkalmazás nem fut, a bérlete lejár, és egy második alkalmazás szerezheti be, amely ezután folytatja a feladatközpont üzeneteinek feldolgozását.
A 2.3.0-s verzió előtt az ugyanazon tárfiók használatára konfigurált függvényalkalmazások egyidejűleg dolgozzák fel az üzeneteket, és frissítik a tárolási összetevőket, ami sokkal magasabb általános késést és kimenő költségeket eredményez. Ha az elsődleges és replika alkalmazásokban valaha is eltérő kód van üzembe helyezve, akár ideiglenesen is, akkor a vezénylések végrehajtása a két alkalmazás vezénylőfüggvényeinek inkonzisztenciái miatt is meghiúsulhat. Ezért javasoljuk, hogy a vészhelyreállítási célokra geoterjesztést igénylő alkalmazások a Durable bővítmény 2.3.0-s vagy újabb verzióját használják.
2. forgatókönyv – Elosztott terhelésű számítás regionális tárolóval
Az előző forgatókönyv csak a számítási infrastruktúra meghibásodására vonatkozik. Ha a tárolási szolgáltatás meghibásodik, az a függvényalkalmazás leállását eredményezi. A tartós függvények folyamatos működésének biztosítása érdekében ez a forgatókönyv egy helyi tárfiókot használ minden régióban, ahol a függvényalkalmazások üzembe vannak helyezve.
Ez a megközelítés az előző forgatókönyvhöz ad további fejlesztéseket:
- Ha a függvényalkalmazás meghibásodik, a Traffic Manager gondoskodik a feladatátvételről a másodlagos régióba. Mivel azonban a függvényalkalmazás a saját tárfiókjára támaszkodik, a tartós függvények továbbra is működnek.
- A feladatátvétel során nincs további késés a feladatátvételi régióban, mivel a függvényalkalmazás és a tárfiók együtt van helyezve.
- A tárolási réteg meghibásodása hibákat okoz a tartós függvényekben, ami viszont átirányítást vált ki a feladatátvételi régióba. Mivel a függvényalkalmazás és a tárterület régiónként el van különítve, a tartós függvények továbbra is működni fognak.
Fontos szempontok ehhez a forgatókönyvhöz:
- Ha a függvényalkalmazás dedikált App Service-csomaggal van üzembe helyezve, a számítási infrastruktúra replikálása a feladatátvételi adatközpontban növeli a költségeket.
- Az aktuális állapot nem feladatátvétel, ami azt jelenti, hogy a meglévő vezénylések és entitások gyakorlatilag szüneteltetve lesznek, és nem érhetők el, amíg az elsődleges régió helyre nem áll.
Összefoglalva, az első és a második forgatókönyv közötti kompromisszum az, hogy a késés megmarad, és a kimenő forgalom költségei minimálisra csökkennek, de a meglévő vezénylések és entitások nem lesznek elérhetők az állásidő alatt. Hogy ezek a kompromisszumok elfogadhatók-e, az alkalmazás követelményeitől függ.
3. forgatókönyv – Elosztott terhelésű számítás GRS megosztott tárolóval
Ez a forgatókönyv egy módosítás az első forgatókönyvben, egy megosztott tárfiók implementálásával. A fő különbség az, hogy a tárfiók úgy jön létre, hogy engedélyezve van a georeplikáció. Funkcionálisan ez a forgatókönyv ugyanazokat az előnyöket biztosítja, mint az 1. forgatókönyv, de további adat-helyreállítási előnyöket tesz lehetővé:
- A georedundáns tárolás (GRS) és az olvasási hozzáférésű GRS (RA-GRS) maximalizálja a tárfiók rendelkezésre állását.
- Ha a Storage szolgáltatás regionális leállása van, manuálisan kezdeményezhet feladatátvételt a másodlagos replikára. Szélsőséges körülmények között, amikor egy régió egy jelentős katasztrófa miatt elveszik, a Microsoft regionális feladatátvételt kezdeményezhet. Ebben az esetben nincs szükség beavatkozásra az Ön részéről.
- Feladatátvétel esetén a tartós függvények állapota megmarad a tárfiók utolsó replikációig, amely általában néhány percenként történik.
A többi forgatókönyvhöz hasonlóan fontos szempontokat is figyelembe kell venni:
- A replika feladatátvétele eltarthat egy ideig. A feladatátvétel befejezéséig és az Azure Storage DNS-rekordjainak frissítéséig a függvényalkalmazás leáll.
- A georeplikált tárfiókok használata megnövekedett költségekkel jár.
- A GRS-replikáció aszinkron módon másolja az adatokat. A legutóbbi tranzakciók némelyike elveszhet a replikációs folyamat késése miatt.
Megjegyzés
Az 1. forgatókönyvben leírtak szerint erősen ajánlott, hogy az ezzel a stratégiával üzembe helyezett függvényalkalmazások a Durable Functions bővítmény 2.3.0-s vagy újabb verzióját használják.
További információkért tekintse meg az Azure Storage vészhelyreállítási és tárfiók-feladatátvételi dokumentációját.