Megbízhatóság az Azure Functionsben
Ez a cikk az Azure Functions megbízhatósági támogatását ismerteti, és ismerteti a régión belüli rugalmasságot a rendelkezésre állási zónákkal, valamint a régiók közötti helyreállítással és üzletmenet-folytonossággal. Az Azure megbízhatósági alapelveinek részletesebb áttekintéséért tekintse meg az Azure megbízhatóságát.
Az Azure Functions rendelkezésre állási zónájának támogatása Prémium (Elastic Premium) és Dedikált (App Service) csomagokban is elérhető. Ez a cikk a prémium csomagok zónaredundancia-támogatásával foglalkozik. A dedikált csomagok zónaredundanciájával kapcsolatban lásd az App Service migrálását a rendelkezésre állási zónák támogatásához.
Rendelkezésre állási zóna támogatása
Az Azure rendelkezésre állási zónái legalább három fizikailag különálló adatközpont-csoport az egyes Azure-régiókban. Az egyes zónákban lévő adatközpontok független energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Helyi zónahiba esetén a rendelkezésre állási zónák úgy vannak kialakítva, hogy az egy zóna érintettsége esetén a fennmaradó két zóna támogassa a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.
A hibák a szoftver- és hardverhibáktól az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tűzesetek. A hibáktól való tolerancia az Azure-szolgáltatások redundanciával és logikai elkülönítésével érhető el. Az Azure-beli rendelkezésre állási zónákkal kapcsolatos részletesebb információkért tekintse meg a Régiók és a rendelkezésre állási zónák című témakört.
Az Azure rendelkezésre állási zónákkal kompatibilis szolgáltatások a megfelelő megbízhatósági és rugalmassági szintet biztosítják. Ezek kétféleképpen konfigurálhatók. Ezek lehetnek zónaredundánsak, a zónák közötti automatikus replikációval vagy a zónák közötti automatikus replikációval, egy adott zónába rögzített példányokkal. Ezeket a megközelítéseket kombinálhatja is. A zónaredundáns és a zónaredundáns architektúrával kapcsolatos további információkért tekintse meg a rendelkezésre állási zónák és régiók Javaslatok.
Az Azure Functions támogatja a zónaredundáns üzembe helyezést.
Ha zónaredundánsként konfigurálja a Függvényeket, a platform automatikusan elterjeszti a függvényalkalmazás-példányokat a kijelölt régió három zónájában.
A zónaredundáns üzembe helyezéssel történő példányterjesztést a következő szabályok határozzák meg, még akkor is, ha az alkalmazás fel- és felskálázódik:
- A függvényalkalmazások minimális száma három.
- Ha háromnál nagyobb kapacitást ad meg, a példányok csak akkor oszlanak el egyenletesen, ha a kapacitás a 3 többszöröse.
- 3*N-nél nagyobb kapacitásérték esetén a további példányok a fennmaradó egy vagy két zónában vannak elosztva.
Fontos
Az Azure Functions a Azure-alkalmazás szolgáltatásplatformon futtatható. Az App Service platformon a Prémium csomagfüggvény-alkalmazásokat futtató csomagokat elastic Premium-csomagoknak nevezzük, olyan termékváltozatnevekkel, mint az EP1. Ha úgy dönt, hogy prémium csomagban futtatja a függvényalkalmazást, mindenképpen hozzon létre egy SKU-névvel rendelkező csomagot, amely "E" kezdetű, például EP1. A "P" kezdetű App Service-csomag termékváltozatainak nevei, például a P1V2 (Prémium V2 Kis csomag) valójában dedikált üzemeltetési csomagok. Mivel dedikáltak, és nem rugalmas prémium szintűek, a "P" kezdetű termékváltozatnevekkel rendelkező csomagok nem fognak dinamikusan skálázni, és növelhetik a költségeket.
Regionális elérhetőség
A zónaredundáns Prémium csomagok a következő régiókban érhetők el:
| Észak-, Dél- és Közép-Amerika | Európa | Közel-Kelet | Afrika | Ázsia és a Csendes-óceáni térség |
|---|---|---|---|---|
| Dél-Brazília | Közép-Franciaország | Izrael középső régiója | Dél-Afrika északi régiója | Kelet-Ausztrália |
| Közép-Kanada | Középnyugat-Németország | Közép-Katar | Közép-India | |
| Az USA középső régiója | Észak-Olaszország | Egyesült Arab Emírségek északi régiója | Észak-Kína 3. 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 | Az Egyesült Királyság déli régiója | |||
| Nyugat-Európa |
Előfeltételek
A rendelkezésre állási zóna támogatása a Prémium csomag egyik tulajdonsága. A rendelkezésre állási zónák engedélyezésére vonatkozó jelenlegi követelmények/korlátozások a következők:
- A rendelkezésre állási zónákat csak akkor engedélyezheti, ha prémium szintű csomagot hoz létre a függvényalkalmazáshoz. Meglévő Prémium csomagokat nem alakíthat át rendelkezésre állási zónák használatára.
- A függvényalkalmazás tárfiókjához zónaredundáns tárfiókot (ZRS) kell használnia. Ha más típusú tárfiókot használ, a Functions nem várt viselkedést jeleníthet meg egy zónakimaradás során.
- Mind a Windows, mind a Linux támogatott.
- Rugalmas prémium vagy dedikált üzemeltetési csomagban kell üzemeltetni. A zónaredundancia dedikált csomagokkal való használatáról az App Service migrálása a rendelkezésre állási zónába című témakörben tájékozódhat.
- A rendelkezésre állási zónák támogatása jelenleg nem érhető el a használatalapú csomagokban lévő függvényalkalmazásokhoz.
- A Prémium csomagban üzemeltetett függvényalkalmazásoknak legalább három készen álló példányszámúnak kell lenniük .
- A platform ezt a minimális számot a színfalak mögött kényszeríti ki, ha háromnál kevesebb példányszámot ad meg.
- Ha nem prémium csomagot vagy olyan méretezési egységet használ, amely támogatja a rendelkezésre állási zónákat, nem támogatott régióban van, vagy nem biztos benne, tekintse meg a migrálási útmutatót.
Díjszabás
A rendelkezésre állási zónák engedélyezéséhez nincs plusz költség. A zónaredundáns Premium App Service-csomagok díjszabása megegyezik az egyzónás Prémium csomag díjszabásával. Minden használt App Service-csomagért a választott termékváltozat, a megadott kapacitás és az automatikus skálázási feltételek alapján skálázható példányok alapján kell fizetnie. Ha engedélyezi a rendelkezésre állási zónákat, de egy App Service-csomaghoz háromnál kisebb kapacitást ad meg, a platform minimálisan három példányszámot kényszerít ki az adott App Service-csomaghoz, és a három példányért díjat számít fel.
Zónaredundáns Prémium csomag és függvényalkalmazás létrehozása
Jelenleg kétféleképpen helyezhet üzembe zónaredundáns Premium-csomagot és függvényalkalmazást. Használhatja az Azure Portalt vagy egy ARM-sablont.
Nyissa meg az Azure Portalt, és lépjen a Függvényalkalmazás létrehozása lapra. A függvényalkalmazások portálon való létrehozásával kapcsolatos információk itt találhatók.
Az Alapszintű beállítások lapon töltse ki a függvényalkalmazás mezőit. Különös figyelmet kell fordítani az alábbi táblázatban szereplő mezőkre (az alábbi képernyőképen is kiemelve), amelyek speciális követelményeket támasztanak a zónaredundanciával kapcsolatban.
Beállítás Ajánlott érték Megjegyzések a zónaredundanciához Régió Előnyben részesített régió Az előfizetés, amelyben létrehozta az új függvényalkalmazást. A fenti listából ki kell választania egy olyan régiót, amely engedélyezve van a rendelkezésre állási zónában. 
Az Üzemeltetés lapon töltse ki a függvényalkalmazás üzemeltetési csomagjának mezőit. Különös figyelmet kell fordítani az alábbi táblázatban szereplő mezőkre (az alábbi képernyőképen is kiemelve), amelyek speciális követelményeket támasztanak a zónaredundanciával kapcsolatban.
Beállítás Ajánlott érték Megjegyzések a zónaredundanciához Storage-fiók Zónaredundáns tárfiók Ahogy az előfeltételek szakaszban már említettük, határozottan javasoljuk, hogy használjon zónaredundáns tárfiókot a zónaredundáns függvényalkalmazáshoz. Csomag típusa Functions Premium Ez a cikk bemutatja, hogyan hozhat létre zónaredundáns alkalmazást egy Prémium csomagban. A zónaredundancia jelenleg nem érhető el a használatalapú csomagokban. Az App Service-csomagok zónaredundanciájával kapcsolatos információk ebben a cikkben találhatók. Zónaredundancia Engedélyezve Ez a mező kitölti azt a jelzőt, amely meghatározza, hogy az alkalmazás zónaredundáns-e vagy sem. Csak akkor választhat Enabled, ha a 2. lépésben említett régiót támogató zónaredundanciát választott.
A függvényalkalmazás létrehozásának további folyamatához hozza létre a függvényalkalmazást a szokásos módon. A létrehozási folyamat többi részében nincsenek olyan mezők, amelyek befolyásolnák a zónaredundanciát.
A zónaredundáns terv létrehozása és üzembe helyezése után az új csomagban üzemeltetett függvényalkalmazások zónaredundánsnak minősülnek.
Rendelkezésre állási zóna migrálása
Az Azure Function Apps jelenleg nem támogatja a meglévő függvényalkalmazás-példányok helyszíni migrálását. A nyilvános több-bérlős Prémium csomag nem rendelkezésre állási zónából a rendelkezésre állási zónába való migrálásával kapcsolatos információkért tekintse meg az App Service migrálását a rendelkezésre állási zónák támogatására.
Zónaleállási élmény
A zónaredundáns függvényalkalmazások összes elérhető függvényalkalmazás-példánya engedélyezve van, és eseményeket dolgoz fel. Ha egy zóna lemegy, a Functions észleli az elveszett példányokat, és szükség esetén automatikusan megpróbál új helyettesítő példányokat keresni. A rugalmas méretezési viselkedés továbbra is érvényes. A zónaletöltési forgatókönyvben azonban nincs garancia arra, hogy a további példányokra vonatkozó kérések sikeresek lehetnek, mivel az elveszett példányok visszatöltése a legjobb munkamennyiség alapján történik. A rendelkezésre állási zónában engedélyezett Prémium csomagban üzembe helyezett alkalmazások továbbra is futnak, még akkor is, ha az ugyanabban a régióban lévő más zónák kimaradásban szenvednek. Előfordulhat azonban, hogy a nem futásidejű viselkedés továbbra is hatással lehet más rendelkezésre állási zónák leállása miatt. Ezek a befolyásolt viselkedések közé tartozhat a Prémium csomag skálázása, az alkalmazás létrehozása, az alkalmazáskonfiguráció és az alkalmazás közzététele. A Prémium csomagok zónaredundanciája csak az üzembe helyezett alkalmazások folyamatos üzemidejét garantálja.
Amikor a Functions egy zónaredundáns Premium-csomaghoz rendel példányokat, akkor az azure-beli virtuálisgép-méretezési csoportok által kínált legjobb munkamennyiség-zónaelosztást használja. A Prémium csomag akkor tekinthető kiegyensúlyozottnak, ha minden zónában azonos számú virtuális gép (± 1 virtuális gép) található a Prémium csomag által használt összes többi zónában.
Régiók közötti vészhelyreállítás és üzletmenet-folytonosság
A vészhelyreállítás (DR) a nagy hatású események, például a természeti katasztrófák vagy az állásidőt és adatvesztést eredményező sikertelen üzemelő példányok helyreállításáról szól. A katasztrófa okától függetlenül a legjobb megoldás egy jól definiált és tesztelt DR-terv, valamint egy olyan alkalmazásterv, amely aktívan támogatja a DR-t. Mielőtt elkezdene gondolkodni a vészhelyreállítási terv létrehozásáról, tekintse meg a Javaslatok a vészhelyreállítási stratégia megtervezéséhez.
A DR-ről a Microsoft a megosztott felelősségi modellt használja. Egy megosztott felelősségi modellben a Microsoft biztosítja, hogy az alapinfrastruktúra és a platformszolgáltatások elérhetők legyenek. Ugyanakkor számos Azure-szolgáltatás nem replikálja automatikusan az adatokat, vagy egy meghibásodott régióból visszaesik egy másik engedélyezett régióba történő keresztreplikáláshoz. Ezekért a szolgáltatásokért Ön felel a számítási feladathoz használható vészhelyreállítási terv beállításáért. Az Azure-platformon szolgáltatásként (PaaS) futó szolgáltatások többsége funkciókkal és útmutatással támogatja a DR-t, és szolgáltatásspecifikus funkciókkal támogatja a gyors helyreállítást a dr. csomag fejlesztéséhez.
Ez a szakasz ismerteti azokat a stratégiákat, amelyekkel üzembe helyezheti a Functionst a vészhelyreállítás engedélyezéséhez.
Többrégiós vészhelyreállítás
Mivel nincs elérhető beépített redundancia, a függvények egy függvényalkalmazásban futnak egy adott Azure-régióban. 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. A többrégiós üzemelő példányokkal kapcsolatos további információkért tekintse meg a magas rendelkezésre állású többrégiós webalkalmazás útmutatását.
Ha ugyanazt a függvénykódot több régióban futtatja, két mintát kell figyelembe venni: aktív-aktív és aktív-passzív.
Aktív-aktív minta HTTP-triggerfüggvényekhez
Az aktív-aktív mintával a függvények mindkét régióban aktívan futtatják és feldolgozják az eseményeket, ismétlődő módon vagy forgásban. Javasoljuk, hogy az Azure Front Doorral együtt aktív-aktív mintát használjon a kritikus HTTP-aktivált függvényekhez, amelyek több régióban futó függvények között irányíthatják és ciklikus időszeletelhetik a HTTP-kéréseket. A bejárati ajtó 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ények felé továbbítja a forgalmat.
Fontos
Bár erősen ajánlott az aktív-passzív mintát használni a nem HTTPS-triggerfüggvényekhez. A nem HTTP által aktivált függvényekhez létrehozhat aktív-aktív üzemelő példányokat. Figyelembe kell azonban vennie, hogy a két aktív régió hogyan kommunikál vagy egyeztet egymással. Ha ugyanazt a függvényalkalmazást két régióban helyezi üzembe, és mindegyik ugyanazon a Service Bus-üzenetsoron aktiválódik, azok versengő fogyasztókként fognak működni az üzenetsor várólistájának törlésekor. Ez azt jelenti, hogy az egyes üzeneteket csak az egyik példány dolgozza fel, de azt is jelenti, hogy az egyetlen Service Bus-példányon továbbra is egyetlen hibapont van.
Ehelyett két Service Bus-üzenetsort helyezhet üzembe, egy elsődleges régióban, egy pedig egy másodlagos régióban. Ebben az esetben két függvényalkalmazással rendelkezhet, amelyek mindegyike a régiójukban aktív Service Bus-üzenetsorra mutat. Ezzel a topológiával az a kihívás, hogyan oszlanak el az üzenetsor-üzenetek a két régió között. Ez gyakran azt jelenti, hogy minden közzétevő megpróbál közzétenni egy üzenetet mindkét régióban, és minden üzenetet mindkét aktív függvényalkalmazás feldolgoz. Bár ez létrehozza a kívánt aktív/aktív mintát, más kihívásokat is teremt a számítási feladatok duplikálása, valamint az adatok konszolidálásának ideje és módja körül.
Aktív-passzív minta nem HTTPS-eseményindító függvényekhez
Ajánlott aktív-passzív mintát használni az eseményvezérelt, nem HTTP által aktivált függvényekhez, például a Service Bus és az Event Hubs által aktivált függvényekhez.
A nem HTTP-eseményindító függvények redundanciájának létrehozásához használjon aktív-passzív mintát. Aktív-passzív mintával 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, miközben egy mechanizmust biztosít a másodlagos régióba való feladatátvételhez egy katasztrófa esetén. A függvényalkalmazások együttműködnek a partnerszolgáltatások feladatátvételi viselkedésével, például az Azure Service Bus georedukálásával és az Azure Event Hubs georedukálásával.
Vegyünk egy példa topológiát egy Azure Event Hubs-eseményindító használatával. 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 lehetővé teszi az elsődleges és a másodlagos eseményközpontok párosítására. Ez egy aliast is létrehoz, amellyel csatlakozhat az eseményközpontokhoz, és a kapcsolati adatok módosítása nélkül válthat az elsődlegesről a másodlagosra.
- A függvényalkalmazások az elsődleges és a másodlagos (feladatátvételi) régióban is üzembe vannak helyezve, és a másodlagos régióban lévő alkalmazás lényegében tétlen, mert az üzeneteket nem küldi el oda.
- A függvényalkalmazás a megfelelő eseményközpont közvetlen (nem alias) kapcsolati sztring aktiválódik.
- Az eseményközpont közzétevőinek közzé kell tenni az alias kapcsolati sztring.
A feladatátvétel előtt a közzétevők a megosztott alias útvonalára küldenek 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. 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.
További információ és szempontok a Service Bus és az Event Hubs feladatátvételével kapcsolatban.