Megbízhatóság az Azure Functionsben

Az Azure Functions egy eseményvezérelt számítási szolgáltatás, amely lehetővé teszi kis kódblokkok (függvények) futtatását anélkül, hogy explicit módon ki kellene építenie vagy kezelnie kellene az infrastruktúrát. A függvények képesek reagálni az eseményekre, például HTTP-kérésekre, időzítőkre, üzenetsor-üzenetekre és más Azure-szolgáltatások változásaira, így kiválóan alkalmasak az adatok feldolgozására, a rendszerek integrálására és a háttérfeladatok futtatására.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan teheti rugalmassá az Azure Functionst a különböző lehetséges kimaradásokkal és problémákkal szemben, beleértve az átmeneti hibákat, a rendelkezésre állási zónák hibáit és az egész régióra kiterjedő hibákat. Emellett az Azure Functions szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat is kiemeli.

Termelési üzembe helyezési javaslatok

Az Azure Well-Architected-keretrendszer megbízhatóságra, teljesítményre, biztonságra, költségekre és műveletekre vonatkozó javaslatokat nyújt. Annak megértéséhez, hogy ezek a területek hogyan befolyásolják egymást, és hogyan járulnak hozzá egy megbízható Azure Functions-megoldáshoz, tekintse meg az Azure Functions architektúrával kapcsolatos ajánlott eljárásait.

A megbízhatósági architektúra áttekintése

Az Azure Functions üzembe helyezésekor fontos, hogy több fogalmat is megismerjen:

• Üzemeltetési tervek: A csomagok a függvényalkalmazások üzemeltetési környezetét képviselik. A terv meghatározza az elérhető számítási erőforrásokat, a díjszabási modellt és a skálázási viselkedést.

• Tárfiókok: Amikor függvényalkalmazást hoz létre, meg kell adnia egy hosting tárfiókot. A tárfiók a függvényalkalmazás belső műveleteinek szempontjainak kezelésére szolgál, beleértve a függvénykódok tárolását, naplózását és egyidejűségének kezelését (például blobbérleteket bizonyos triggertípusok esetében).

  Az üzembe helyezéshez tárfiókot is használhat. Ez a tárhelyfiók lehet ugyanaz, mint a gazdagép tárhelyfiókja, vagy akár egy másik tárhelyfiók is.

  Fontos

  A tárfiókok az Azure Functions megbízhatósági architektúrájának kritikus részei, és konfigurálnia kell őket úgy, hogy megfeleljenek a függvényalkalmazás rugalmassági követelményeinek.

• Eseményindítók és kötések: Ezek lehetővé teszik, hogy a függvény reagáljon az eseményekre, fogadjon és írjon adatokat más szolgáltatásokból.

• Durable Functions: A tartós függvények állapotalapú függvények, beleértve a hosszú ideig futó vezényléseket és állapotalapú entitásokat.

  A Durable Functions használatakor konfiguráljon egy tárolószolgáltatót, amely tárolja az állapotot. Értékelnie kell a választott állapottároló megbízhatósági jellemzőit, és konfigurálnia kell azt a rugalmassági követelményeknek megfelelően.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Vegye figyelembe a függvényalkalmazások átmeneti hibáinak kezelésére vonatkozó alábbi javaslatokat:

• Triggerek és kötések: Az Azure Functions platform beépített átmeneti hibakezelést tartalmaz számos eseményindítóhoz és kötéshez. Ha átmeneti hiba történik, miközben egy támogatott eseményindító aktiválódik, vagy egy támogatott kötés adatokat olvas vagy ír, a platform automatikusan újrapróbálkozza a műveletet. Ez a beépített újrapróbálkozási viselkedés segít biztosítani, hogy az ideiglenes kapcsolati problémák vagy a szolgáltatásjelek ne akadályozzák meg a függvény végrehajtását. További információ: Azure Functions hibakezelés és újrapróbálkozás.

  Ez a védelem azonban csak átmeneti hibákra terjed ki. Az állandó hibákat, például a helytelenül konfigurált kapcsolati karakterláncot vagy egy törölt erőforrást, a rendszer nem próbálja újra.

  Az állandó hibákat és az ismétlődő átmeneti hibákat hibaként kezeli a rendszer, és konfigurálhatja a naplózást a függvényvégrehajtási hibák adatainak rögzítéséhez. További információkért tekintse meg az Azure Functions monitorozásának konfigurálását ismertető témakört.

• A függvény kódja: A függvény törzsén belül Ön a felelős az átmeneti hibák kezeléséért, amikor külső szolgáltatások felé irányuló hívásokat kezdeményez. Az újrapróbálkozási logikát, az időtúllépéseket és az áramkör-megszakító mintákat a függvénykódban végrehajtott külső szolgáltatáshívásokhoz megfelelően kell implementálnia. A függvényeket úgy tervezheti meg, hogy idempotensek legyenek, ahol csak lehetséges, hogy az újrapróbálkozás ne okozzon ismétlődő mellékhatásokat.

• Ügyfelek: Minden olyan ügyfélalkalmazásnak, amely szinkron módon csatlakozik a függvényekhez, például HTTP-kapcsolattal csatlakozik, rugalmasnak kell lennie az átmeneti hibákkal szemben.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

A használati csomagok nem támogatják a rendelkezésre állási zónákat. Ha a zónaredundancia követelmény a számítási feladathoz, fontolja meg inkább a Rugalmas fogyasztási tervet, a Prémium csomagtervet vagy a Dedikált (App Service) csomagtípust.

A rugalmas fogyasztási csomagok támogatják a zónaredundáns telepítéseket.

A prémium csomagok támogatják a zónaredundáns üzemelő példányokat.

A zónaredundancia engedélyezésekor a platform automatikusan elterjeszti a tervkivitelezéseket a kijelölt régió összes rendelkezésre állási zónájában. Ha a régió bármely rendelkezésre állási zónája problémába ütközik, a függvények továbbra is az egészséges zónákban lévő példányokon futnak.

Emellett engedélyeznie kell a zónaredundáns tárolást (ZRS) a gazdagép tárfiókján, ami biztosítja, hogy az rugalmas legyen a zónakimaradásokkal szemben is.

A dedikált (App Service) csomag támogatja a zónaredundáns üzembe helyezéseket. Ha a zónaredundancia engedélyezve van, a platform automatikusan elterjeszti a példányokat a kijelölt régió összes rendelkezésre állási zónájában. Konfigurálja a zónaredundanciát a tervben. A zónaredundancia kezelésének módjáról az Azure App Service megbízhatósága című témakörben olvashat bővebben.

Ha nem engedélyezi a zónaredundanciát, a csomag nem zónaalapú vagy regionális, ami azt jelenti, hogy a csomagpéldányok a régión belül vagy ugyanazon a zónán belül bármely rendelkezésre állási zónában elhelyezhetők, és nem rugalmasak a rendelkezésre állási zóna hibáival szemben. A terv használatakor tapasztalhat leállási időszakot a régió bármelyik zónájában fennálló üzemzavar esetén.

Követelmények

• Régiótámogatás: A zónaredundáns Flex Consumption-csomagok egy adott régióban helyezhetők üzembe. Az Azure CLI használatával lekérheti a támogatott régiók aktuális listáját. További információt a rendelkezésre állási zónákat támogató régiók megtekintése című témakörben talál.

• Régiótámogatás: Zónákra kiterjedő Prémium csomagok az alábbi régiókban telepíthetők:

  Amerika	Európa	Közel-Kelet	Africa	Ázsia és a Csendes-óceáni térség
  Dél-Brazília	Közép-Franciaország	Közép-Izrael	Dél-Afrika északi régiója	Ausztrália keleti régiója
  Közép-Kanada	Középnyugat-Németország	Közép-Katar		Közép-India
  USA középső régiója	Észak-Olaszország	Egyesült Arab Emírségek északi régiója		Kína 3. északi régiója
  USA keleti régiója	Észak-Európa			Kelet-Ázsia
  USA 2. keleti régiója	Kelet-Norvégia			Kelet-Japán
  USA déli középső régiója	Közép-Svédország			Délkelet-Ázsia
  USA 2. nyugati régiója	Észak-Svájc
  USA 3. nyugati régiója	Egyesült Királyság déli régiója
  	Nyugat-Európa

• Operációs rendszerek: A Windows- és Linux-csomagok is támogatottak.

• Minimális példányszám: Legalább két mindig készen álló példányra van szükség, ha a zónaredundancia engedélyezve van a Prémium csomagokhoz.

• Gazdagép tárfiókja: Konfigurálnia kell a függvényalkalmazás alapértelmezett gazdagéptároló-fiókját a zónaredundáns tárolás (ZRS) használatára. Ha olyan tárolófiókot használ, amely nincs ZRS-re beállítva, előfordulhat, hogy az alkalmazás nem várt módon viselkedik zóna leállás alatt.

• Üzembe helyezési tároló tárfiókja: Ha külön tárfiókot használ az alkalmazás üzembehelyezési tárolója számára, akkor azt is zónaredundánsként kell frissítenie.

Megfontolások

A zónaredundancia csak az üzembe helyezett alkalmazások folyamatos üzemidejét garantálja. A rendelkezésre állási zónák kimaradása hatással lehet az Azure Functions bizonyos aspektusaira, annak ellenére, hogy az alkalmazás továbbra is kiszolgálja a forgalmat. Ilyen viselkedés például a tervméretezés, az alkalmazáslétrehozás, az alkalmazáskonfiguráció és az alkalmazás közzététele.

Példányok eloszlása zónák között

Ha zónaredundánsként konfigurálja a Flex Consumption-csomag alkalmazásait, a platform automatikusan elosztja a csomagpéldányokat a kijelölt régió több zónája között, és különböző szabályok vonatkoznak a mindig kész és az igény szerinti példányokra:

• A mindig készen lévő példányok körbeforgásos módon vannak elosztva legalább két zóna között.

  A zóna rugalmasságának biztosítása érdekében a platform automatikusan legalább két mindig készen álló példányt tart fenn minden függvényenkénti skálázási függvényhez vagy csoporthoz, függetlenül attól, hogy az alkalmazás mindig készen áll-e a konfigurációra. A platform által létrehozott példányok platform által felügyeltek, mindig készen álló példányként vannak számlázva, és nem módosítják a mindig kész konfigurációs beállításokat.

• Az igény szerinti példányok eseményforrás-kötetek eredményeként jönnek létre, mivel az alkalmazás mérete meghaladja a mindig készen álló példányok számát. Az igény szerinti példányokat a rendelkezésre állási zónák között a lehető legjobb módon osztják el. A gyorsabb felskálázás elsőbbséget jelent a zónák közötti egyenletes eloszlással szemben. A platform idővel megpróbálja kiegyenlíteni az eloszlást.

Ha az Elastic Premium-függvényalkalmazás-csomagokat zónaredundánsként konfigurálja, a platform automatikusan elosztja a csomagpéldányokat a kijelölt régió több zónája között. A példányterjesztés az alábbi szabályokat követi, még akkor is, ha az alkalmazás fel- és felskálázható:

• A függvényalkalmazások minimális száma kettő.
• Ha a zónák számánál nagyobb kapacitást ad meg, a példányok csak akkor oszlanak el egyenletesen, ha a kapacitás a zónák számának többszöröse.
• A kapacitásérték, amely nagyobb, mint a zónák száma * példányok száma, esetén az extra példányok a fennmaradó zónák között oszlanak el.

Amikor a Functions egy zónaredundáns Prémium csomaghoz rendel példányokat, a legjobb erőfeszítés alapú zónaelosztást használja, amelyet az alapul szolgáló Azure Virtuális gép-méretezési csoportok kínálnak. A Prémium csomag akkor tekinthető kiegyensúlyozottnak , ha minden zónában azonos számú virtuális gép található a Prémium csomag által használt összes többi zónában, plusz vagy mínusz egy virtuális géppel.

Cost

A zónaredundancia engedélyezéséhez nincs plusz költség. A zónaredundáns csomagok díjszabása megegyezik az egyzónás csomagokkal.

Ha azonban egy olyan alkalmazásban engedélyezi a rendelkezésre állási zónákat, amelyek minden függvényenkénti skálázási függvényhez vagy csoporthoz két példánynál kevesebb példányt konfigurálnak, a platform automatikusan létrehoz két mindig készen álló típusú példányt minden függvényenkénti skálázási függvényhez vagy csoporthoz. Ezek az új példányok úgy is számlázzák, mint mindig készen álló példányok.

Ha azonban két példánynál kevesebb példányt tartalmazó csomagban engedélyezi a rendelkezésre állási zónákat, a platform minimálisan két példányszámot kényszerít ki az adott csomaghoz, és mindkét példányért díjat kell fizetnie.

A teljes díjszabást az Azure Functions díjszabásában találja.

A rendelkezésre állási zóna támogatásának konfigurálása

• Hozzon létre egy új zónaredundáns Azure Functions-tervet. Új csomag létrehozásakor engedélyezheti a zónaredundanciát. Részletes lépésekért lásd : Zónaredundáns függvényalkalmazás létrehozása.

• Zónaredundancia engedélyezése egy meglévő terven: A zónaredundancia engedélyezéséhez frissíthet egy meglévő Flex Consumption-csomagot. Részletes lépésekért lásd: Zónaredundancia engedélyezése egy meglévő terven.

• Hozzon létre egy új zónaredundáns Azure Functions csomagot. Új csomag létrehozásakor engedélyezheti a zónaredundanciát. Részletes lépésekért lásd : Zónaredundáns függvényalkalmazás létrehozása.

• Zónaredundancia engedélyezése egy meglévő terven: Prémium csomagok esetén a zónaredundanciát csak a csomag létrehozásakor engedélyezheti. Meglévő Prémium csomagokat nem alakíthat zónaredundánssá. Ehelyett át kell telepítenie az alkalmazást úgy, hogy egy egymás melletti üzembe helyezést hoz létre egy új Prémium csomagbeli alkalmazásban. További információ: Zónaredundancia engedélyezése meglévő terven.

Kapacitástervezés és -kezelés

A zónaredundáns függvényalkalmazások akkor is futnak, ha a régióban lévő zónák kimaradásban szenvednek.

A zónakimaradás során az Azure Functions észleli az elveszett példányokat, és automatikusan megpróbál helyettesítő példányokat keresni vagy létrehozni az kifogástalan állapotú zónákban. Ez a folyamat a lehető legjobb erőfeszítéssel történik, de nem garantált. Ha a számítási feladatnak bizonyos számú példánysal kell rendelkeznie a várt szolgáltatási szint fenntartásához, fontolja meg a mindig készen álló példányok számának túlzott kiépítését . Ez a megközelítés lehetővé teszi, hogy a megoldás elviseljen némi kapacitásvesztést, és a teljesítmény romlása nélkül működjön tovább. További információ: Kapacitás kezelése túlkiépítés használatával.

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy terv zónaredundáns, a gazdagép tárfiókja ZRS-t használ, és az összes rendelkezésre állási zóna működőképes.

• Zónák közötti művelet: Ha zónaredundanciát konfigurál az Azure Functionsben, a kérések automatikusan el vannak osztva az egyes rendelkezésre állási zónák példányai között. Egy kérés bármelyik rendelkezésre állási zónában lévő példányra kerülhet.

• Zónaközi adatreplikálás: Az Azure Functions egy állapot nélküli számítási szolgáltatás, így nincs ügyféladatok replikálása a zónák között. A platform automatikusan replikálja a konfigurációt a zónák között.

  Ha a hosztszolgáltatás tárfiókja ZRS-t használ, az Azure Storage szinkron módon replikálja az adatokat több elérhetőségi zónában.

  A Durable Functions esetében tekintse át a társzolgáltatót, és ismerje meg, hogyan replikálja az adatokat a zónák között.

Viselkedés zónahiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy terv zónaredundáns, a gazdagép tárfiókja ZRS-t használ, és rendelkezésre állási zónakimaradás történik.

• Észlelés és válasz: Az Azure Functions platform felelős a rendelkezésre állási zónában fellépő hibák észleléséért. Nem kell semmit tennie a zóna átváltásának kezdeményezéséhez.

• Értesítés: A Microsoft nem értesíti automatikusan, ha egy zóna le van omlva. Az Azure Resource Health használatával azonban figyelheti az egyes erőforrások állapotát, és beállíthat Resource Health-riasztásokat a problémákról való értesítéshez. Az Azure Service Health használatával is megismerheti a szolgáltatás általános állapotát, beleértve a zónahibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

• Aktív kérések: Ha egy rendelkezésre állási zóna nem érhető el, a hibás rendelkezésre állási zónában lévő példányhoz csatlakoztatott folyamatban lévő kérések leállnak, és újra kell próbálkozni. Az átmeneti hibakezelési útmutatót követve győződjön meg arról, hogy az alkalmazások készen állnak.

• Várható adatvesztés: A zónahibák várhatóan nem okoznak adatvesztést, mivel az Azure Functions állapot nélküli szolgáltatás.

  Ha a gazdagép tárfiókja ZRS-t használ, az Azure Storage biztosítja, hogy zónahiba esetén ne következzen be adatvesztés.

  A Durable Functions esetében tekintse át a tárolószolgáltatót, és ismerje meg, hogy lehetséges-e adatvesztés zónahiba esetén.

• Várható állásidő: A zónakimaradások során a kapcsolatok rövid megszakításokat tapasztalhatnak, amelyek általában néhány másodpercig tartanak a forgalom újraelosztása során. Az átmeneti hibakezelési útmutatót követve győződjön meg arról, hogy az alkalmazások készen állnak.

• Forgalom átirányítása: Az Azure Functions észleli az elveszett példányokat az adott zónából, és megpróbálja megtalálni az új helyettesítő példányokat. Miután az Azure Functions megtalálja a megfelelő pótlásokat, szükség szerint elosztja a forgalmat az új példányok között.

  Fontos

  Az Azure nem garantálja, hogy a több példány kérésének teljesülése sikeres lesz zónakiesés esetén. A platform megpróbálja a lehető legjobban visszapótolni az elveszett példányokat. Ha garantált kapacitásra van szüksége a rendelkezésre állási zóna meghibásodása során, hozza létre és konfigurálja a terveket a zónaveszteség figyelembe vételéhez a kapacitás túlkiépítésével.

• Nem futtatókörnyezeti viselkedések: A zónaredundáns függvényalkalmazás-csomagban lévő alkalmazások továbbra is futnak és kiszolgálják a forgalmat, még akkor is, ha egy rendelkezésre állási zóna leállást tapasztal. A rendelkezésre állási zónák leállása azonban hatással lehet a nem futtatási viselkedésre. Ilyen viselkedés például a függvényalkalmazások skálázása, az alkalmazások létrehozása, az alkalmazáskonfiguráció és az alkalmazások közzététele.

Zóna helyreállítása

A rendelkezésre állási zóna helyreállításakor az Azure Functions automatikusan visszaállítja a rendelkezésre állási zónában lévő példányokat, eltávolítja a többi rendelkezésre állási zónában létrehozott ideiglenes példányokat, és a szokásos módon átirányítja a példányok közötti forgalmat.

Zónahibák tesztelése

Az Azure Functions platform kezeli a zónaredundáns erőforrások forgalmi útválasztását, feladatátvételét és zónahelyreállítását. Nem kell semmit kezdeményeznie. Mivel ez a szolgáltatás teljes mértékben felügyelt, nem kell ellenőriznie a rendelkezésre állási zónák meghibásodási folyamatait.

Rugalmasság régiószintű hibákhoz

Az Azure Functions egy egyrégiós szolgáltatás. Ha a régió elérhetetlenné válik, az Azure Functions-erőforrás is elérhetetlenné válik.

Egyéni többrégiós megoldások a rugalmasság érdekében

A kimaradások során bekövetkező végrehajtásvesztés elkerülése érdekében ugyanazokat a függvényeket redundánsan üzembe helyezheti több régióban lévő alkalmazásokban.

Ön a felelős a következőért:

• Függvényalkalmazások üzembe helyezése több régióban
• A régiók közötti forgalomeloszlás kezelése
• Feladatátvételi mechanizmusok implementálása
• Adatkonzisztenciának biztosítása régiók között (ha van)
• Régiók közötti telepítések figyelése és kezelése

Ha ugyanazt a függvénykódot több régióban futtatja, két gyakran használt mintát érdemes figyelembe venni: aktív-aktív és aktív-passzív. A következő szakaszok röviden ismertetik ezeket a mintákat, de nem nyújtanak részletes útmutatást vagy konfigurációs lépéseket.

Aktív-aktív minta HTTP-triggerfüggvényekhez

Aktív-aktív mintázat esetén a függvények mindkét régióban aktívan futnak és dolgozzák fel az eseményeket, akár párhuzamosan, akár váltakozva. A kritikus HTTP-aktivált függvényekhez aktív-aktív mintát kell használnia az Azure Front Doorral kombinálva, amely több régióban futó függvények között irányíthatja és eloszthatja a HTTP-kéréseket. Az Azure Front Door rendszeres időközönként ellenőrizheti az egyes végpontok állapotát is. Ha egy régióban egy függvény nem válaszol az állapot-ellenőrzésekre, az Azure Front Door kiveszi a rotációból, és csak a fennmaradó kifogástalan állapotú függvényekhez továbbítja a forgalmat.

Aktív-passzív minta nem HTTP-triggerfüggvényekhez

Az eseményvezérelt, nem HTTP-aktivált függvények (például a Service Bus és az Event Hubs által aktivált függvények) esetében használjon aktív-passzív mintát. Aktív-passzív minta esetén a függvények aktívan futnak az eseményeket fogadó régióban, míg a második régióban ugyanazok a függvények tétlenek maradnak. Az aktív-passzív minta lehetővé teszi, hogy csak egyetlen függvény dolgozza fel az egyes üzeneteket, ami fontos az adatkonzisztenciának fenntartásához, ugyanakkor olyan mechanizmust is biztosít, amely a másodlagos régióba való feladatátvételt egy olyan katasztrófa esetén, mint egy régiókimaradás.

A függvényalkalmazás feladatátvételét más szolgáltatások feladatátvételi viselkedésével kell figyelembe venni, például:

• Azure Service Bus georeplikálás és geo-vészhelyreállítás
• Azure Event Hubs földrajzi replikálás és katasztrófa utáni helyreállítás

Vegyünk egy példa topológiát egy Azure Event Hubs-eseményindító használatával, ahol az Event Hubs-névtér geo-vészhelyreállításra van konfigurálva. Ebben az esetben az aktív-passzív minta a következő összetevőket igényli:

• Az Azure Event Hubs elsődleges és másodlagos régióban is üzembe van helyezve.
• A geokatasztrófa-helyreállítás engedi az elsődleges és másodlagos eseményközpontok párosítását. Ez egy aliast is létrehoz, amellyel csatlakozhat az Event Hubs-névtérhez, és a kapcsolatadatok módosítása nélkül válthat az elsődlegesről a másodlagosra.
• Az elsődleges és a másodlagos (feladatátvételi) régióba üzembe helyezett függvényalkalmazások esetén a másodlagos régióban lévő alkalmazás lényegében tétlen, mivel az üzeneteket nem küldik oda.
• A függvényalkalmazás a megfelelő Event Hubs-névtér közvetlen (nem alias) kapcsolati sztringjén aktiválódik.
• Az Event Hubs-névtér kiadóinak az alias kapcsolat sztringjére kell publikálniuk.

Feladatátvétel előtt a kiadók a megosztott alias útvonalon keresztül az elsődleges eseményközpontba küldenek. Az elsődleges függvényalkalmazás kizárólag az elsődleges eseményközpontot figyeli. A másodlagos alkalmazás passzív és inaktív.

A feladatátvétel kezdeményezése után a megosztott aliasra küldő közzétevők a másodlagos eseményközpontba kerülnek. A másodlagos függvényalkalmazás mostantól aktívvá válik, és automatikusan elindul. A másodlagos régióba történő hatékony feladatátvétel teljes egészében az eseményközpontból vezérelhető, és a függvények csak akkor válnak aktívvá, ha a megfelelő eseményközpont aktív.

Tartós funkciók

A Durable Functions többrégiós vészhelyreállítását lásd: Vészhelyreállítás és geoeloszlás az Azure Durable Functionsben.

A szolgáltatás karbantartásával szembeni rugalmasság

Az Azure Functions rendszeres szolgáltatásfrissítéseket és egyéb karbantartási feladatokat hajt végre.

• Átmeneti hibarugalmasság: A szolgáltatáskarbantartás során előfordulhat, hogy a függvényalkalmazást futtató példányok újraindulnak, vagy átmeneti megszakításokat tapasztalnak. Győződjön meg arról, hogy a függvényalkalmazással kommunikáló ügyfélalkalmazások rugalmasak az átmeneti hibákkal szemben.

• Zónaredundancia engedélyezése: Ha engedélyezi a zónaredundanciát a csomagban, akkor a platformfrissítések során is javíthatja a rugalmasságot. Ha több példányt helyez üzembe a tervben, és engedélyezi a zónaredundanciát a csomaghoz, további rugalmassági réteget biztosít, ha egy példány vagy zóna nem megfelelő állapotúvá válik a frissítés során.

A frissítés során várható kapacitás fenntartása érdekében a platform automatikusan hozzáadja a csomag további példányait a frissítési folyamat során.

• Zónaredundancia engedélyezése: Ha engedélyezi a zónaredundanciát a csomagban, akkor a platformfrissítések során is javíthatja a rugalmasságot. A frissítési tartományok olyan virtuális gépek gyűjteményeiből állnak, amelyek a frissítés során offline állapotba kerülnek, és rendelkezésre állási zónákra vannak leképezve. Ha több példányt helyez üzembe a tervben, és engedélyezi a zónaredundanciát a csomaghoz, további rugalmassági réteget biztosít, ha egy példány vagy zóna nem megfelelő állapotúvá válik a frissítés során.

• App Service-környezet: Ha a függvényalkalmazást App Service-környezetben üzemelteti, testre szabhatja a frissítési ciklust. Ha ellenőriznie kell a frissítéseknek a számítási feladatra gyakorolt hatását, engedélyezze a manuális frissítéseket. Ez a módszer lehetővé teszi az ellenőrzés és tesztelés elvégzését egy nem termelési példányon, mielőtt alkalmazva lenne az éles példányra.

  A karbantartási beállításokról további információt az App Service Environment tervezett karbantartásával kapcsolatos frissítési beállításokban talál.

Az alkalmazástelepítések rugalmassága

Az alkalmazástelepítések az éles környezetben felmerülő problémák kockázatát mutatják. Ha problémákat okoz, készen kell állnia a frissítés visszaállítására. Azt is szabályoznia kell, hogy a frissítések hogyan legyenek bevezetve, hogy minimálisra csökkenjen az alkalmazás újraindítása miatti fennakadás.

A Rugalmas kihasználtságú csomagok támogatják a webhelyfrissítési stratégiákat, amelyek többféle módon is üzembe helyezhetik az alkalmazásfrissítéseket, beleértve a nulla állásidős üzemelő példányok működés közbeni frissítéseit is.

Az Azure Functions üzembehelyezési pontjai lehetővé teszik a függvényalkalmazások leállási idő nélküli üzembe helyezését. Az üzembehelyezési pontok használatával minimalizálhatja az üzembe helyezések és a konfigurációs módosítások hatását a felhasználók számára. Az üzembehelyezési pontok emellett csökkentik az alkalmazás újraindításának valószínűségét. Az alkalmazás újraindítása átmeneti hibát okoz.

Szolgáltatásiszint-szerződés

Az Azure-szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell a rendelkezésre állási elvárás eléréséhez. További információ: SLA-k az online szolgáltatásokhoz.

Az Azure Functions különböző rendelkezésre állási SLA-kat biztosít a használati csomaghoz és más csomagtípusokhoz.

Kapcsolódó tartalom

• Rendelkezésre állási zónák konfigurálása az Azure Functionshez
• Vészhelyreállítás és geoeloszlás az Azure Durable Functionsben
• Azure Front Door létrehozása
• Az Event Hubs feladatátvételi szempontjai
• Az Azure Architecture Center rendelkezésre állási zónákkal kapcsolatos útmutatója
• Megbízhatóság az Azure-ban