Megbízhatóság az Azure Functionsben

A Azure Functions egy eseményvezérelt számítási szolgáltatás, amely kis kódblokkokat vagy függvényeket futtat explicit infrastruktúra kiépítése vagy kezelése nélkül. 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. Ez a képesség alkalmassá teszi a Functionst az adatfeldolgozásra, a rendszerintegrációra és a háttérfeladatokra.

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á a 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 kiemeli a Functions szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat is.

Termelési üzembe helyezési javaslatok

Az Azure Well-Architected-keretrendszer megbízhatósági, biztonsági, költség-, üzemeltetési és teljesítménybeli javaslatokat kínál. Ha szeretné megtudni, hogy ezek a területek hogyan befolyásolják egymást, és hogyan járulnak hozzá egy megbízható Functions-megoldáshoz, tekintse meg a Functions architektúrával kapcsolatos ajánlott eljárásait.

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

A Functions üzembe helyezésekor fontos, hogy megismerkedjen az alábbi fogalmakkal:

  • Üzemeltetési tervek: A csomagok a függvényalkalmazások üzemeltetési környezetét képviselik. A terv meghatározza a rendelkezésre álló 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 kezeli a függvényalkalmazás belső műveleteinek szempontjait, 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 adott eseményindító-tí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 a Functions megbízhatósági architektúrájának kritikus részét képezik. Konfigurálja őket úgy, hogy megfeleljenek a függvényalkalmazás rugalmassági követelményeinek.

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

  • Tartós függvények: A tartós függvények a Függvények egyik funkciója. Állapotmegőrző funkciókat, például hosszú ideig futó orchestrációkat és állapotmegőrző entitásokat biztosít.

    Ha tartós függvényeket használ, konfiguráljon egy tárolószolgáltatót , amely tárolja az állapotot. Értékelje ki a választott állapottároló megbízhatósági jellemzőit, és konfigurálja úgy, hogy megfeleljen a rugalmassági követelményeknek.

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: A Functions platform beépített átmeneti hibakezelést biztosít az eseményindítókhoz és kötésekhez. 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 biztosítja, hogy az ideiglenes csatlakozási problémák vagy szolgáltatáskimaradások ne akadályozzák a függvény futtatását. További információ: Functions hibakezelés és újrapróbálkozás.

    Ez a védelem csak átmeneti hibákat fed le. A platform nem próbálkozik újra az állandó hibák, például a helytelenül konfigurált kapcsolati karakterlánc vagy egy törölt erőforrás esetében.

    A platform az állandó hibákat és az ismétlődő átmeneti hibákat hibaként kezeli. A naplózás konfigurálása a függvényvégrehajtási hibák adatainak rögzítéséhez. További információ: A Függvények monitorozásának konfigurálása.

  • A függvény kódja: A függvénykódban Ön a felelős az átmeneti hibák kezeléséért, amikor a függvény külső szolgáltatásokat hív meg. Hajtsa végre az újrapróbálkozási mechanizmusokat, az időtúllépéseket és az áramkör-megszakító sablonokat a függvénykódban végzett külső szolgáltatáshívások esetén szükség szerint. Ha lehetséges, tervezzen idempotens függvényeket, hogy az újrapróbálkozás ne okozhasson ismétlődő mellékhatásokat.

  • Ügyfelek: Az olyan ügyfélalkalmazásoknak, amelyek szinkron módon csatlakoznak a függvényekhez, például HTTP-kapcsolaton keresztül, rugalmasnak kell lenniük 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 használat, a Prémium vagy a Dedikált (Azure App Service) csomag használatát.

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 kifogástalan állapotú zónákban lévő példányok használatával futnak.

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

Diagram, amely egy zónaredundáns Functions-tervet mutat be, amely három példányból áll, amelyek három zónában vannak szétoszlatva, és egy ZRS-fiókkal rendelkezik.

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. Az Azure App Service zónaredundancia kezelésével kapcsolatos további információkért lásd az App Service megbízhatósága című témakört.

A terv nem zónaalapú vagy regionális , ha nem engedélyezi a zónaredundanciát. A platform a plan példányokat bármely rendelkezésre állási zónában elhelyezheti a régión belül vagy ugyanabban a zónában. A példányok nem ellenállóak a rendelkezésre állási zónák 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: Zóna-redundáns Prémium-csomagokat a következő régiókban helyezhet üzembe.

    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 platform támogatja a zónaredundáns Windows és Linux-csomagok üzembe helyezését.

  • Minimális példányszám: A Prémium csomagok zónaredundanciához legalább két mindig készen álló példány szükséges.

  • Gazdagéptároló-fiók: Konfigurálnia kell a függvényalkalmazás alapértelmezett gazdagéptároló-fiókját a ZRS használatára. Ha olyan tárhelyfiókot használ, amely nincs konfigurálva a ZRS-hez, előfordulhat, hogy az alkalmazás váratlanul működik egy zónakimaradás során.
  • Ü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, frissítse azt zónaredundánsra.

Megfontolások

Nem futtatókörnyezeti viselkedések: 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 a Functions funkcióira, 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óna-redundánsként konfigurálja a *Flex Consumption* plan alkalmazásokat, a platform automatikusan elosztja a példányokat a kijelölt régió több zónájában, a mindig késznlévő és az igény szerinti példányokra alkalmazott különböző szabályokkal.

  • A mindig készen lévő példányok körkörös elosztás használatával legalább két zónára vannak elosztva.

    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ügyelt, mindig készen álló példányként vannak számlázva, és nem módosítják a mindig készen álló konfigurációs beállításokat.

  • Az igény szerinti példányok az eseményforrások köteteiből keletkeznek, amikor az alkalmazás mérete meghaladja a mindig rendelkezésre álló példányok számát. Az igény szerinti példányok a rendelkezésre állási zónák között a lehető legjobb erőfeszítéssel vannak elosztva. A platform előnyben részesíti a gyorsabb horizontális felskálázást 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ási csomagokat zóna-redundánsra konfigurálja, a platform automatikusan elosztja a példányokat a kijelölt régió több zónájában. 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.

  • Ha a kapacitás értéke nagyobb, mint a zónák számának és a példányok számának szorzata, a további példányok eloszlanak a fennmaradó zónák között.

Amikor a Functions egy zónaredundáns Prémium csomaghoz rendel példányokat, akkor egy lehető legjobb zónaelosztást használ, amelyet az alapul szolgáló Azure Virtual Machine Scale Sets biztosít. Azure prémium szintű csomagot kiegyensúlyozottnak tekinti, ha minden zónában ugyanannyi virtuális gép (VM) található, mint a csomag többi zónájában, plusz vagy mínusz egy virtuális gép.

Cost

A zónaredundancia engedélyezése nem jár többletköltséggel. A zónaredundáns csomagok díjszabása megegyezik az egyzónás csomagokkal. A zónaredundancia engedélyezése azonban befolyásolja a tervben szereplő példányok minimális számát.

Ha 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 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 a csomaghoz, és mindkét példányért díjat kell fizetnie.

A teljes díjszabást a 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 függvénycsomagot. Új csomag létrehozásakor engedélyezheti a zónaredundanciát. További információ: Zónaredundáns függvényalkalmazás létrehozása.

  • Zónaredundancia engedélyezése egy meglévő terven. A rendelkezésre állási zónákat be- és kikapcsolhatja a meglévő Elastic Premium-csomagok esetében. A rugalmas Prémium csomagok speciális kapacitási viselkedéssel rendelkeznek, amely eltér a dedikált (App Service-) csomagoktól, és további konfigurációs lépéseket igényel. Részletes lépésekért lásd: Zónaredundancia engedélyezése egy meglévő terven.

  • Hozzon létre egy új zóna-redundáns függvények tervet. Új csomag létrehozásakor engedélyezheti a zónaredundanciát. További információ: Zónaredundáns függvényalkalmazás létrehozása.

  • Zónaredundancia engedélyezése egy meglévő terven. Prémium csomagok esetén csak a csomag létrehozásakor engedélyezheti a zónaredundanciát. A meglévő Prémium csomagokat nem konvertálhatja zónaredundánssá. Ehelyett migrálhatja 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ó zónái kimaradásban vannak.

A zónakimaradás során a 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. A platform ezt a folyamatot minden tőle telhetőt megtesz, és nem garantálja a sikert. Ha a számítási feladathoz meghatározott számú példány szükséges a várt szolgáltatási szint fenntartásához, fontolja meg a mindig készen álló példányok számának túlterhelését . A túlterjedés lehetővé teszi, hogy a megoldás elviselje a kapacitásvesztést, és a teljesítmény csökkentése nélkül működjön tovább. További információ: Kapacitás kezelése túlfoglalással.

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 a 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: A Functions állapot nélküli számítási szolgáltatás, ezért nincs replikálandó adat 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 tartós függvények esetében tekintse át a tárolószolgá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 a ZRS-t alkalmazza, és rendelkezésre állási zónakimaradás történik.

  • Észlelés és válasz: A Functions platform felelős egy rendelkezésre állási zónában fellépő hiba észleléséért. Nem kell zóna vészátkapcsolását kezdeményeznie.

  • 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 csatlakozó folyamatban lévő kérések leállnak, és újra meg 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, mert a Functions állapot nélküli szolgáltatás.

    Ha a gazdagépen lévő tárfiók ZRS-t használ, a tárhely biztosítja, hogy zónahiba esetén ne következzen be adatvesztés.

    A tartós függvények 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: A 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 a Functions megtalálta a cserepéldányokat, 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 egy rendelkezésre állási zóna meghibásodása esetén, alakítsa ki és konfigurálja a terveket úgy, hogy a kapacitást túlméretezi a zónaveszteség lehetőségének figyelembevételé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 a 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

A Functions platform kezeli a forgalom útválasztását, átvitelét és zónaredundáns erőforrások helyreállítását. Nem kell semmit kezdeményeznie. Azure teljes mértékben kezeli ezt a funkciót, így nem kell ellenőriznie a rendelkezésre állási zónák meghibásodási folyamatait.

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

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

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

Annak érdekében, hogy elkerülhesse a szolgáltatás régiószintű leállások során történő megszakítását, ugyanazokat a függvényeket redundánsan üzembe helyezheti több régióban működő 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 felügyelete és kezelése.

Ha ugyanazt a függvénykódot több régióban futtatja, vegye figyelembe az aktív-aktív és az aktív-passzív mintákat. A következő szakaszok ezeket a mintákat ismertetik, 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ában a függvények mindkét régióban aktívan futnak és feldolgozzák az eseményeket, akár duplikált módon, akár váltakozva. Használjon aktív-aktív mintát az Azure Front Door funkcióval a kritikus, HTTP által aktivált függvényekhez, amelyek képesek HTTP-kéréseket irányítani és körforgásszerűen, vagy round-robin módszerrel elosztani a különböző régiókban futó függvények között. 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 eltávolítja a forgalomból, és csak a fennmaradó egészséges függvények felé továbbítja a forgalmat.

Diagram, amely egy aktív-aktív architektúrára példa. Azure Front Door különböző régiókban található Functions-alkalmazások közötti útvonalakat, amelyek mindegyike saját adatbázissal rendelkezik.

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

Eseményvezérelt, nem HTTP-aktivált függvények (például Azure Service Bus és Azure Event Hubs eseményindítók) esetén használjon aktív-passzív mintát. Aktív-passzív mintában a függvénypéldányok abban a régióban futnak, amely eseményeket fogad, míg a másodlagos régióban lévő példányok tétlenek maradnak. Ez a minta biztosítja, hogy csak egy függvény dolgozza fel az egyes üzeneteket, ami segít fenntartani az adatkonzisztenciát. Emellett lehetővé teszi a másodlagos régióba való feladatátvételt egy katasztrófa, például egy régiókimaradás során.

Fontolja meg a függvényalkalmazás feladatátvételét más használt szolgáltatások feladatátvételi viselkedésével együtt, például:

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

  • Az elsődleges és másodlagos régiókban üzembe helyezett Event Hubs-névterek.

  • A geokatasztrófa-helyreállítás engedi az elsődleges és másodlagos eseményközpontok párosítását. Ez a konfiguráció egy aliast is létrehoz, amellyel csatlakozhat az Event Hubs-névtérhez, és az aliast az elsődlegesről a másodlagosra válthatja a kapcsolati adatok módosítása nélkül.

  • Az elsődleges és a másodlagos régióban üzembe helyezett függvényalkalmazások. A másodlagos régióban lévő alkalmazás tétlen marad, mert nem fogad üzeneteket.

  • Az egyes függvényalkalmazások eseményindítói a direct (nem alias) kapcsolati karakterláncot használják a saját Event Hubs névterükhöz.

  • Az Event Hubs névtér közzétevői az alias kapcsolat karakterláncát használják közzétételre.

Egy aktív-passzív architektúrát bemutató ábra. Az Event Hubs geo-vészhelyreállítása több régióra terjed ki, és minden régióban külön függvényalkalmazásokat és adatbázisokat használ.

A feladatátvétel előtt azok a közzétevők, amelyek eseményeket küldenek a megosztott aliasnak, átirányítják a forgalmat az elsődleges eseményközpontba. Az elsődleges függvényalkalmazás kizárólag az elsődleges eseményközpontot figyeli. A másodlagos függvényalkalmazás passzív és tétlen marad.

A feladatátvétel indításakor a megosztott aliasnak eseményeket küldő közzétevők a másodlagos eseményközpontba kerülnek. A másodlagos függvényalkalmazás aktívvá válik, és automatikusan aktiválódik. Az eseményközpont képes a teljes feladatátvételi folyamat végrehajtására, és minden függvényalkalmazás csak akkor fut, ha a megfelelő eseményközpont aktív.

Tartós funkciók

A tartós függvények többrégiós vészhelyreállításáról további információt a Vészhelyreállítás és geoeloszlás Azure tartós függvényekben című témakörre hivatkozva találhat.

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

A 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 a függvényalkalmazást futtató példányok újraindulhatnak, vagy átmeneti megszakításokat tapasztalhatnak. 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 tervhez, további rugalmassági réteget adhat hozzá, ha egy példány vagy zóna nem megfelelő állapotúvá válik a frissítés során.

  • További ideiglenes példányok: 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, az 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. Ezzel a módszerrel ellenőrizheti és tesztelheti a nem termelési példányokat, mielőtt a frissítéseket az éles példányra alkalmazza.

    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. A frissítések bevezetésének szabályozása az alkalmazás újraindítása miatti fennakadások csökkentése érdekében.

A Rugalmas használatú csomagok támogatják a webhelyfrissítési stratégiákat, amelyek többféle módot kínálnak az alkalmazásfrissítések üzembe helyezésére. Ezek a stratégiák magukban foglalják a folyamatos frissítéseket a nulla állásidő érdekében.

A függvények ü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ákat 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.

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

Kapcsolódó tartalom

  • Last updated on