Megbízhatóság Azure-alkalmazás szolgáltatásban
Ez a cikk a Azure-alkalmazás szolgáltatás megbízhatósági támogatását ismerteti, és a régión belüli rugalmasságot és a rendelkezésre állási zónákat, valamint a régiók közötti vészhelyreállítást és az üzletmenet folytonosságát ismerteti. Az Azure megbízhatósági alapelveinek részletesebb áttekintéséért tekintse meg az Azure megbízhatóságát.
Azure-alkalmazás szolgáltatás egy HTTP-alapú szolgáltatás webalkalmazások, REST API-k és mobil háttérrendszerek üzemeltetésére, és a Microsoft Azure teljesítményét adja hozzá az alkalmazáshoz, például:
- Biztonság
- Terheléselosztás
- Automatikus skálázás
- Automatizált felügyelet
Annak megismeréséhez, hogy a Azure-alkalmazás Szolgáltatás hogyan erősítheti meg az alkalmazás számítási feladatainak megbízhatóságát és rugalmasságát, olvassa el az App Service használatának miért fontos részét?
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áról további információt a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatok című témakörben talál.
Azure-alkalmazás szolgáltatás a rendelkezésre állási zónákban (AZ) üzembe helyezhető, így rugalmasságot és megbízhatóságot érhet el az üzleti szempontból kritikus fontosságú számítási feladatokhoz. Ezt az architektúrát zónaredundanciának is nevezik.
Ha zónaredundánsként konfigurálja az App Service-t, a platform automatikusan elterjeszti a Azure-alkalmazás Service-csomag példányait a kijelölt régió három zónájára.
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:
- Az App Service-csomag minimális példányszáma három.
- Ha háromnál nagyobb kapacitást ad meg, és a példányok száma hárommal osztható, a példányok egyenletesen oszlanak el.
- A 3*N-t meghaladó példányok száma a fennmaradó egy vagy két zónában oszlik el.
A rendelkezésre állási zóna támogatása az App Service-csomag egyik tulajdonsága. Az App Service-csomagok felügyelt több-bérlős környezetben vagy dedikált környezetben hozhatók létre az App Service Environment v3 használatával. Az App Service Environment v3-tal kapcsolatos további információkért tekintse meg az App Service Environment v3 áttekintését.
Ha az App Services nem zónaredundánsként van konfigurálva, a virtuálisgép-példányok nem zónaredundánsak, és állásidőt tapasztalhatnak a régió bármely zónájában.
A vállalati üzembehelyezési architektúrával kapcsolatos információkért tekintse meg a nagy rendelkezésre állású vállalati üzembe helyezést az App Service Environment használatával.
Előfeltételek
A rendelkezésre állási zónák engedélyezésére vonatkozó jelenlegi követelmények/korlátozások a következők:
Mind a Windows, mind a Linux támogatott.
A rendelkezésre állási zónák csak az újabb App Service-lábnyom esetében támogatottak. Még ha a támogatott régiók egyikét is használja, hibaüzenet jelenik meg, ha az erőforráscsoport nem támogatja a rendelkezésre állási zónákat. Ha biztosítani szeretné, hogy a számítási feladatok egy olyan bélyegre kerüljön, amely támogatja a rendelkezésre állási zónákat, előfordulhat, hogy létre kell hoznia egy új erőforráscsoportot, az App Service-csomagot és az App Service-t.
Az App Services-csomagnak a rendelkezésre állási zónákat támogató alábbi csomagok egyikének kell lennie:
- Több-bérlős környezetben app Service Premium v2 vagy Premium v3 csomagokkal.
- Dedikált környezetben az App Service Environment v3 használatával, amelyet izolált v2 App Service-csomagokkal használnak.
Dedikált környezetek esetén az App Service-környezetnek v3-nak kell lennie.
Fontos
Az App Service Environment v2 és v1 2024. augusztus 31-én megszűnik. Az App Service Environment v3 használata egyszerűbb, és hatékonyabb infrastruktúrán fut. Az App Service Environment v3-ról további információt az App Service Environment áttekintésében talál. Ha jelenleg az App Service Environment 2-es vagy v1-es verzióját használja, és frissíteni szeretne a v3-ra, kövesse a cikkben leírt lépéseket az új verzióra való migráláshoz.
A három zóna minimális példányszáma kényszerítve van. A platform ezt a minimális számot a színfalak mögött fogja érvényesíteni, ha háromnál kevesebb példányszámot ad meg.
A rendelkezésre állási zónák csak új App Service-csomag létrehozásakor adhatók meg. Egy már meglévő App Service-csomag nem konvertálható rendelkezésre állási zónák használatára.
A következő régiók támogatják a több-bérlős környezeteken futó Azure-alkalmazás-szolgáltatásokat:
- Kelet-Ausztrália
- Dél-Brazília
- Közép-Kanada
- Közép-India
- Az USA középső régiója
- Kelet-Ázsia
- USA keleti régiója
- USA 2. keleti régiója
- Közép-Franciaország
- Középnyugat-Németország
- Izrael középső régiója
- Észak-Olaszország
- Kelet-Japán
- Dél-Korea középső régiója
- Mexikó középső régiója
- Észak-Európa
- Kelet-Norvégia
- Közép-Lengyelország
- Közép-Katar
- Dél-Afrika északi régiója
- USA déli középső régiója
- Délkelet-Ázsia
- Közép-Spanyolország
- Közép-Svédország
- Észak-Svájc
- Egyesült Arab Emírségek északi régiója
- Az Egyesült Királyság déli régiója
- Nyugat-Európa
- USA 2. nyugati régiója
- USA 3. nyugati régiója
- A 21Vianet által üzemeltetett Microsoft Azure – Észak-Kína 3
- Azure Government – US Gov Virginia
Annak megtekintéséhez, hogy mely régiók támogatják az App Service Environment v3 rendelkezésre állási zónáinak használatát, tekintse meg a Régiók című témakört.
Erőforrás létrehozása engedélyezett rendelkezésre állási zónával
Több-bérlős zónaredundáns App Service üzembe helyezése
Ha az Azure CLI használatával szeretné engedélyezni a rendelkezésre állási zónákat, adja meg a --zone-redundant paramétert az App Service-csomag létrehozásakor. A kapacitás megadásához a paramétert is megadhatja --number-of-workers . Ha nem ad meg kapacitást, a platform alapértelmezés szerint három. A kapacitást a számítási feladatokra vonatkozó követelmény alapján kell beállítani, de nem kevesebb, mint három. A kapacitás kiválasztásának jó szabálya, hogy elegendő példányt biztosítson az alkalmazás számára, így a példányok egy zónájának elvesztése elegendő kapacitást hagy a várt terhelés kezeléséhez.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Tipp.
A példánykapacitás meghatározásához használja a következő számítást:
Mivel a platform a virtuális gépeket három zónára terjeszti, és legalább egy zóna meghibásodását figyelembe kell vennie, szorozza meg a számítási feladatok csúcspéldányainak számát a zónák/(zónák-1) vagy a 3/2 tényezővel. Ha például a tipikus csúcsterhelés négy példányt igényel, hat példányt kell üzembe helyeznie: (2/3 * 6 példány) = 4 példány.
Zónaredundáns App Service üzembe helyezése dedikált környezettel
Ha tudni szeretné, hogyan hozhat létre App Service Environment v3-at az Izolált v2 csomagban, olvassa el az App Service-környezet létrehozása című témakört.
Hibaelhárítás
| Hibaüzenet | Leírás | Ajánlás |
|---|---|---|
| A zónaredundancia nem érhető el az "RG-NAME" erőforráscsoporthoz. Telepítse az "ASP-NAME" App Service-csomagot egy új erőforráscsoportban. | A rendelkezésre állási zónák csak az újabb App Service-lábnyom esetében támogatottak. Még ha a támogatott régiók egyikét is használja, hibaüzenet jelenik meg, ha az erőforráscsoport nem támogatja a rendelkezésre állási zónákat. | Ha biztosítani szeretné, hogy a számítási feladatok egy olyan bélyegre kerüljön, amely támogatja a rendelkezésre állási zónákat, hozzon létre egy új erőforráscsoportot, App Service-csomagot és App Service-t. |
Hibatűrés
A rendelkezésre állási zóna meghibásodására való felkészüléshez túl kell építenie a szolgáltatás kapacitását annak érdekében, hogy a megoldás képes legyen a kapacitás 1/3 elvesztését elviselni, és a zónaszintű kimaradások során a teljesítmény romlása nélkül működjön tovább. Mivel a platform a virtuális gépeket három zónára terjeszti, és legalább egy zóna meghibásodását figyelembe kell vennie, szorozza meg a számítási feladatok csúcspéldányainak számát a zónák/(zónák-1) vagy a 3/2 tényezővel. Ha például a tipikus csúcsterhelés négy példányt igényel, hat példányt kell üzembe helyeznie: (2/3 * 6 példány) = 4 példány.
Zónaleállási élmény
A forgalom az összes elérhető App Service-példányhoz lesz irányítva. Abban az esetben, ha egy zóna lemegy, az App Service platform észleli az elveszett példányokat, és automatikusan megpróbálja megtalálni az új helyettesítő példányokat, és szükség szerint elterjeszti a forgalmat. Ha az automatikus skálázás konfigurálva van, és úgy dönt, hogy több példányra van szükség, az automatikus skálázás kérést is küld az App Service-nek további példányok hozzáadásához. Vegye figyelembe, hogy az automatikus skálázási viselkedés független az App Service platform viselkedésétől , és hogy az automatikus skálázási példányszám specifikációjának nem kell a háromból többnek lennie.
Feljegyzés
Nincs garancia arra, hogy a zónaleállási forgatókönyvben további példányokra vonatkozó kérések sikeresek lesznek. Az elveszett példányok visszatöltése a legjobb munkamennyiség alapján történik. Az ajánlott megoldás az App Service-csomagok létrehozása és konfigurálása, hogy figyelembe vegyék a zóna elvesztését a következő szakaszban leírtak szerint.
A rendelkezésre állási zónákkal rendelkező App Service-csomagban üzembe helyezett alkalmazások továbbra is futnak és kiszolgálják a forgalmat, 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 futtatókörnyezeti viselkedések, például az App Service-csomag skálázása, az alkalmazáslétrehozás, az alkalmazáskonfiguráció és az alkalmazás-közzététel továbbra is hatással lehetnek más rendelkezésre állási zónák leállása miatt. Az App Service-csomagok zónaredundanciájával csak az üzembe helyezett alkalmazások folyamatos üzemideje biztosítható.
Amikor az App Service-platform egy zónaredundáns App Service-csomaghoz rendel példányokat, az alapul szolgáló Azure-beli virtuálisgép-méretezési csoportok által kínált legjobb erőfeszítési zónaelosztást használja. Az App Service-csomagok akkor lesznek "kiegyensúlyozottak", ha mindegyik zónában azonos számú virtuális gép található, vagy +/- az App Service-csomag által használt összes többi zónában egy virtuális gép.
Rendelkezésre állási zóna migrálása
A meglévő App Service-példányokat vagy környezeti erőforrásokat nem migrálhatja a nem rendelkezésre állási zóna támogatásából a rendelkezésre állási zóna támogatására. A rendelkezésre állási zónák támogatásának biztosításához létre kell hoznia az erőforrásokat a rendelkezésre állási zónák engedélyezésével.
Díjszabás
Az App Service Premium v2 vagy Premium v3 csomagokat használó több-bérlős környezetek esetében nincs további költség a rendelkezésre állási zónák engedélyezésével kapcsolatban, ha az App Service-csomagban három vagy több példány található. A díjakat az App Service-csomag termékváltozata, a megadott kapacitás és az automatikus skálázási feltételek alapján skálázható példányok alapján számítjuk fel. Ha engedélyezi a rendelkezésre állási zónákat, de háromnál kisebb kapacitást ad meg, a platform minimálisan három példányszámot kényszerít ki, és a három példányért díjat számít fel. Az App Service Environment 3-hoz készült verzió eltérő díjszabási modellel rendelkezik a rendelkezésre állási zónákhoz. Az App Service Environment v3 díjszabási információiért tekintse meg a Díjszabás című témakört.
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 vészhelyreállítási stratégia tervezésére vonatkozó javaslatokat.
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 az App Service-ben üzembe helyezett webalkalmazások néhány gyakori stratégiáját ismerteti.
Amikor webalkalmazást hoz létre az App Service-ben, és kiválaszt egy Azure-régiót az erőforrás létrehozása során, az egyrégiós alkalmazás. Ha a régió katasztrófa esetén elérhetetlenné válik, az alkalmazás is elérhetetlenné válik. Ha azonos üzembe helyezést hoz létre egy másodlagos Azure-régióban többrégiós földrajzi architektúra használatával, az alkalmazás kevésbé lesz érzékeny az egyrégiós katasztrófákra, ami garantálja az üzletmenet folytonosságát. A régiók közötti adatreplikáció lehetővé teszi az utolsó alkalmazásállapot helyreállítását.
Az informatika esetében az üzletmenet-folytonossági terveket nagyrészt a helyreállítási idő célkitűzése (RTO) és a helyreállítási pont célkitűzése (RPO) vezérli. További információ az RTO-ról és az RPO-ról: Helyreállítási célkitűzések.
Az RTO körüli SLA fenntartása általában nem praktikus regionális katasztrófák esetén, és általában csak az RPO körül tervezné meg a vészhelyreállítási stratégiát (azaz az adatok helyreállítására összpontosítana, nem pedig a megszakítás minimalizálására). Az Azure-ban azonban ez nem csak praktikus, de akár egyszerű is lehet az App Service üzembe helyezése automatikus geo-feladatátvételekhez. Ez lehetővé teszi, hogy az RTO és az RPO felügyelete mellett az alkalmazások további vészhelyreállítását is elvégezheti.
A kívánt RTO- és RPO-metrikáktól függően három vészhelyreállítási architektúrát használnak általában az App Service több-bérlős és az App Service-környezetekhez is. Az egyes architektúrák leírása az alábbi táblázatban található:
| Metrika | Aktív-aktív | Aktív-passzív | Passzív/Hideg |
|---|---|---|---|
| RTO | Valós idejű vagy másodperces | Percek | Óra |
| RPO | Valós idejű vagy másodperces | Percek | Óra |
| Költség | $$$ | $$ | $ |
| Forgatókönyvek | Kritikus fontosságú alkalmazások | Magas prioritású alkalmazások | Alacsony prioritású alkalmazások |
| Többrégiós felhasználói forgalom kiszolgálásának képessége | Igen | Igen/talán | Nem |
| Kód üzembe helyezése | CI/CD-folyamatok előnyben részesítve | CI/CD-folyamatok előnyben részesítve | Biztonsági mentés és visszaállítás |
| Új App Service-erőforrások létrehozása állásidő alatt | Nem kötelező | Nem kötelező | Kötelező |
Feljegyzés
Az alkalmazás valószínűleg más Azure-beli adatszolgáltatásoktól, például az Azure SQL Database-től és az Azure Storage-fiókoktól függ. Javasoljuk, hogy az egyes függő Azure-szolgáltatásokhoz is dolgozzon ki vészhelyreállítási stratégiákat. Az SQL Database-hez lásd az Azure SQL Database aktív georeplikálását. Az Azure Storage esetében lásd az Azure Storage redundanciát.
Vészhelyreállítás többrégiós földrajzi területen
A webalkalmazások tartalmát és konfigurációit többféleképpen is replikálhatja az Azure-régiókra egy aktív-aktív vagy aktív-passzív architektúrában, például az App Service biztonsági mentésének és visszaállításának használatával. A biztonsági mentés és visszaállítás azonban időponthoz kötött pillanatképeket hoz létre, és végül a webalkalmazások verziószámozási kihívásaihoz vezet a régiók között. A vissza- és visszaállítási útmutató és a diaszteres helyreállítási útmutató összehasonlításához tekintse meg az alábbi táblázatot:
Biztonsági mentés és visszaállítás és vészhelyreállítás
| Platform | Biztonsági mentési és visszaállítási útmutató | Vészhelyreállítási útmutató |
|---|---|---|
| App Service-webalkalmazások (Ingyenes és megosztott tarifacsomagok) |
Ha a webalkalmazások az ingyenes vagy a megosztott szinten vannak üzembe helyezve, és hozzáférést igényelnek a webalkalmazások biztonsági mentési és visszaállítási képességeihez, skálázhatók fel az Alapszintű szintre vagy annál magasabb szintre. | Az App Service-erőforrások online állapotba helyezése egy másik Azure-régióban regionális katasztrófa esetén. 2025. március 31-től az App Service-alkalmazások nem lesznek vészhelyreállítási módban egy Azure-régióban bekövetkező katasztrófa során, amint azt a régiószintű hibacikkből való helyreállítás ismerteti. Javasoljuk, hogy alkalmazzon gyakran használt vészhelyreállítási technikákat az állásidő és az adatvesztés megelőzése érdekében egy regionális katasztrófa során. |
| App Service-webalkalmazások (Alapszintű, Standard és Prémium tarifacsomagok) |
A Azure-alkalmazás szolgáltatásban igény szerinti egyéni biztonsági mentéseket készíthet, vagy automatikus biztonsági mentéseket használhat. A biztonsági mentést egy meglévő alkalmazás felülírásával vagy egy új alkalmazásba vagy pontba való visszaállítással állíthatja vissza. További információért tekintse meg az alkalmazás biztonsági mentését és visszaállítását a Azure-alkalmazás Service szolgáltatásban. |
Az App Service-erőforrások egy másik Azure-régióban történő online állapotba helyezésére vonatkozó jelenlegi útmutatás a régiószintű hiba utáni helyreállításkor érhető el – Azure-alkalmazás Szolgáltatás. 2025. március 31-től a Azure-alkalmazás Service-webalkalmazások többé nem lesznek vészhelyreállítási módban egy Azure-régióban bekövetkező katasztrófa során, amint azt a régiószintű hiba cikkben ismertetett helyreállítás ismerteti. Javasoljuk, hogy alkalmazzon gyakran használt vészhelyreállítási technikákat a webalkalmazások funkcióvesztésének vagy adatainak regionális katasztrófa esetén történő megelőzéséhez. |
| App Service Environment (V2 és V3) | A Azure-alkalmazás szolgáltatáskörnyezetben igény szerinti egyéni biztonsági mentéseket készíthet, vagy automatikus biztonsági mentéseket használhat. Az automatikus biztonsági másolatok visszaállíthatók egy célalkalmazásba ugyanabban az App Service-környezetben, nem pedig egy másik App Service-környezetben. Az egyéni biztonsági másolatok visszaállíthatók egy célalkalmazásba egy másik App Service-környezetben (például egy V2 App Service-környezetből egy V3 App Service-környezetbe). A biztonsági másolatok visszaállíthatók a forrásalkalmazással azonos operációsrendszer-platform célalkalmazására. További részletekért tekintse meg az alkalmazás biztonsági mentését és visszaállítását a Azure-alkalmazás Szolgáltatásban. |
Javasoljuk, hogy alkalmazzon vészhelyreállítási útmutatást az App Service Environment-ben üzembe helyezett webalkalmazásokhoz a gyakran használt vészhelyreállítási technikák használatával. |
| Azure Functions: Dedikált terv |
Ha dedikált (App Service) csomagban futtatja a függvényalkalmazást, a függvényalkalmazás szükséges tartalmai a beépített tárterületen maradnak. Dedikált csomagban igény szerinti egyéni biztonsági mentéseket készíthet, vagy automatikus biztonsági mentéseket is használhat. A biztonsági mentést egy meglévő alkalmazás felülírásával vagy egy új alkalmazásba vagy pontba való visszaállítással állíthatja vissza. További információ: Alkalmazás biztonsági mentése és visszaállítása a Azure-alkalmazás Szolgáltatásban. Az Azure Filest nem használja dedikált csomag, de ha helytelenül konfigurálta az alkalmazást Azure Files-kapcsolattal, a biztonsági mentés nem támogatott. |
A függvényalkalmazás-erőforrások egy másik Azure-régióban, egy másik Azure-régióban történő újra online állapotba helyezéséhez kapcsolódó aktuális útmutatás a régiószintű hiba utáni helyreállítás – Azure-alkalmazás Szolgáltatás – címen érhető el. 2025. március 31-től az App Service-alkalmazások nem lesznek vészhelyreállítási módban egy Azure-régióban bekövetkező katasztrófa során, amint azt a régiószintű hibacikkből való helyreállítás ismerteti. Ehelyett tervezze meg a megbízhatóságot a függvényalkalmazásokban. A dedikált csomagokban a függvényalkalmazások gyakran használt vészhelyreállítási technikáira is hivatkozhat. |
| Azure Functions: Rugalmas felhasználás, Felhasználás és Prémium csomagok |
A Rugalmas kihasználtságú csomagban, a Használati csomagban vagy a Prémium csomagban futó függvényalkalmazások nem használhatnak egyéni vagy automatikus biztonsági mentési funkciókat az App Service-ben. Ezekben a dinamikus méretezési csomagokban a függvényalkalmazás tartalma megmarad az Azure Storage-ban. Az Azure Storage redundanciabeállításaival biztosíthatja, hogy a tárfiók megfeleljen a rendelkezésre állási és tartóssági céloknak a kimaradás során. A meglévő függvényalkalmazás-projektet .zip fájlként is letöltheti az Azure Portalról. |
Határozottan javasoljuk, hogy tervezze meg a megbízhatóságot a függvényalkalmazásokban. |
A biztonsági mentési és visszaállítási módszerek korlátainak elkerülése érdekében konfigurálja a CI-/CD-folyamatokat a kód mindkét Azure-régióban való üzembe helyezéséhez. Fontolja meg az Azure Pipelines vagy a GitHub Actions használatát. További információ: Folyamatos üzembe helyezés Azure-alkalmazás szolgáltatásban.
Üzemkimaradás észlelése, értesítés és felügyelet
Javasoljuk, hogy állítsa be a webalkalmazások figyelését és riasztásait, hogy időben értesüljenek a vészhelyzetek során. További információ: Application Insights rendelkezésre állási tesztek.
Az azure-beli alkalmazáserőforrások kezeléséhez használjon egy IaC-mechanizmust. Több régióban történő összetett üzembe helyezés esetén a régiók egymástól függetlenül történő kezeléséhez és a régiók közötti konfiguráció megbízható módon történő szinkronizálásához kiszámítható, tesztelhető és megismételhető folyamat szükséges. Fontolja meg az IaC-eszközt, például az Azure Resource Manager-sablonokat vagy a Terraformot.
Vészhelyreállítás és üzemkimaradás észlelésének beállítása
Ha többrégiós földrajzi helyen szeretne vészhelyreállítást készíteni, használhat aktív-aktív vagy aktív-passzív architektúrát.
Aktív-aktív architektúra
Az aktív-aktív vészhelyreállítási architektúrában az azonos webalkalmazások két külön régióban vannak üzembe helyezve, az Azure Front Door pedig a forgalmat mindkét aktív régióba irányítja.
Ezzel a példaarchitektúrával:
- Az azonos App Service-alkalmazások két külön régióban vannak üzembe helyezve, beleértve a tarifacsomagot és a példányok számát.
- A nyilvános forgalom közvetlenül az App Service-alkalmazásokba le van tiltva.
- Az Azure Front Door a forgalmat mindkét aktív régióba irányítja.
- Katasztrófa esetén az egyik régió offline állapotba kerül, és az Azure Front Door kizárólag az online maradó régióba irányítja a forgalmat. Az RTO egy ilyen geo-feladatátvétel során közel nulla.
- Az alkalmazásfájlokat ci-/CD-megoldással kell üzembe helyezni mindkét webalkalmazásban. Ez biztosítja, hogy az RPO gyakorlatilag nulla legyen.
- Ha az alkalmazás aktívan módosítja a fájlrendszert, az RPO minimalizálásának legjobb módja, ha csak csatlakoztatott Azure Storage-megosztásba ír ahelyett, hogy közvetlenül a webalkalmazás /otthoni tartalommegosztásba ír. Ezután használja az Azure Storage redundanciafunkcióit (GZRS vagy GRS) a csatlakoztatott megosztáshoz, amely körülbelül 15 perces RPO-t tartalmaz.
Az App Service-ben a webalkalmazás aktív-aktív architektúrájának létrehozásának lépései az alábbiak szerint vannak összefoglalva:
Két App Service-csomag létrehozása két különböző Azure-régióban. Konfigurálja a két App Service-csomagot.
Hozzon létre két webalkalmazás-példányt, mindegyik App Service-csomagban egyet.
Azure Front Door-profil létrehozása a következőkkel:
- Egy végpont.
- Két forráscsoport, egyenként 1 prioritással. Az egyenlő prioritás arra utasítja az Azure Front Doort, hogy a forgalmat mindkét régióba egyformán (tehát aktív-aktív) irányt irányítsa.
- Egy útvonal.
Csak az Azure Front Door-példányból korlátozza a webalkalmazások hálózati forgalmát.
Állítsa be és konfigurálja az összes többi háttérbeli Azure-szolgáltatást, például az adatbázisokat, a tárfiókokat és a hitelesítésszolgáltatókat.
Kód üzembe helyezése mindkét webalkalmazásban folyamatos üzembe helyezéssel.
Oktatóanyag: Magas rendelkezésre állású többrégiós alkalmazás létrehozása a Azure-alkalmazás Szolgáltatásban bemutatja, hogyan állíthat be aktív-passzív architektúrát. Ugyanazok a lépések, minimális módosításokkal (az "1" prioritás beállítása mindkét forráshoz az Azure Front Door forráscsoportjában) aktív-aktív architektúrát biztosítanak.
Aktív-passzív architektúra
Ebben a vészhelyreállítási megközelítésben az azonos webalkalmazások két külön régióban vannak üzembe helyezve, az Azure Front door pedig csak egy régióba (az aktív régióba) irányítja a forgalmat.
Ezzel a példaarchitektúrával:
Az azonos App Service-alkalmazások két külön régióban vannak üzembe helyezve.
A nyilvános forgalom közvetlenül az App Service-alkalmazásokba le van tiltva.
Az Azure Front Door a forgalmat az elsődleges régióba irányítja.
A költségmegtakarítás érdekében a másodlagos App Service-csomag úgy van konfigurálva, hogy kevesebb példányt használjon, és/vagy alacsonyabb tarifacsomagban legyen. Három lehetséges módszer létezik:
Előnyben részesített A másodlagos App Service-csomag tarifacsomagja megegyezik az elsődleges tarifacsomaggal, ugyanannyi példánysal vagy kevesebbel. Ez a megközelítés biztosítja a két App Service-csomag funkció- és virtuálisgép-méretezésének paritását. A geo feladatátvétel során az RTO csak a példányok méretezésének időpontjától függ.
Kevésbé előnyben részesített A másodlagos App Service-csomag tarifacsomagtípusa (például PremiumV3), de kisebb méretű virtuálisgép-méretezés, kisebb példányokkal. Előfordulhat például, hogy az elsődleges régió a P3V3 rétegben van, míg a másodlagos régió a P1V3 rétegben van. Ez a megközelítés továbbra is biztosítja a funkciók paritását a két App Service-csomag esetében, de a méretparitás hiánya manuális felskálázást igényelhet, amikor a másodlagos régió aktív régióvá válik. A geo feladatátvétel során az RTO attól függ, hogy mennyi idő alatt lehet vertikálisan felskálázni és skálázni a példányokat.
Legkevésbé előnyben részesített A másodlagos App Service-csomag tarifacsomagja eltér az elsődleges és a kisebb példányokétól. Előfordulhat például, hogy az elsődleges régió A P3V3 szinten van, míg a másodlagos régió S1 szinten van. Győződjön meg arról, hogy a másodlagos App Service-csomag rendelkezik az alkalmazás futtatásához szükséges összes funkcióval. A funkciók rendelkezésre állásának különbségei a kettő között késést okozhatnak a webalkalmazás helyreállításában. A geo feladatátvétel során az RTO attól függ, hogy mennyi idő alatt lehet vertikálisan felskálázni és skálázni a példányokat.
Az automatikus skálázás a másodlagos régión van konfigurálva abban az esetben, ha az aktív régió inaktívvá válik. Javasoljuk, hogy az aktív és passzív régiókban is hasonló automatikus skálázási szabályokkal rendelkezzen.
Katasztrófa esetén az elsődleges régió inaktívvá válik, és a másodlagos régió elkezdi fogadni a forgalmat, és aktív régióvá válik.
Ha a másodlagos régió aktívvá válik, a hálózati terhelés előre konfigurált automatikus skálázási szabályokat aktivál a másodlagos webalkalmazás méretezéséhez.
Előfordulhat, hogy manuálisan kell felskáláznia a másodlagos régió tarifacsomagját, ha még nem rendelkezik az aktív régióként való futtatáshoz szükséges funkciókkal. Az automatikus skálázáshoz például standard szint vagy magasabb szint szükséges.
Amikor az elsődleges régió ismét aktív, az Azure Front Door automatikusan visszairányítja a forgalmat, és az architektúra ismét aktív-passzív állapotba kerül, mint korábban.
Az alkalmazásfájlokat ci-/CD-megoldással kell üzembe helyezni mindkét webalkalmazásban. Ez biztosítja, hogy az RPO gyakorlatilag nulla legyen.
Ha az alkalmazás aktívan módosítja a fájlrendszert, az RPO minimalizálásának legjobb módja, ha csak csatlakoztatott Azure Storage-megosztásba ír ahelyett, hogy közvetlenül a webalkalmazás /otthoni tartalommegosztásba ír. Ezután használja az Azure Storage redundanciafunkcióit (GZRS vagy GRS) a csatlakoztatott megosztáshoz, amely körülbelül 15 perces RPO-t tartalmaz.
A webalkalmazás aktív-passzív architektúrájának az App Service-ben való létrehozásának lépései az alábbiak szerint vannak összefoglalva:
- Két App Service-csomag létrehozása két különböző Azure-régióban. A másodlagos App Service-csomag a korábban említett megközelítések egyikével építhető ki.
- A másodlagos App Service-csomag automatikus skálázási szabályait úgy konfigurálja, hogy az az elsődleges régió inaktívvá válásakor az elsődleges példányszámra skálázható legyen.
- Hozzon létre két webalkalmazás-példányt, mindegyik App Service-csomagban egyet.
- Azure Front Door-profil létrehozása a következőkkel:
- Egy végpont.
- Az elsődleges régió 1 prioritású forráscsoportja.
- Egy második forráscsoport, amelynek prioritása 2 a másodlagos régióban. A prioritás különbsége arra utasítja az Azure Front Doort, hogy az elsődleges régiót részesítse előnyben online állapotban (így aktív-passzív).
- Egy útvonal.
- Csak az Azure Front Door-példányból korlátozza a webalkalmazások hálózati forgalmát.
- Állítsa be és konfigurálja az összes többi háttérbeli Azure-szolgáltatást, például az adatbázisokat, a tárfiókokat és a hitelesítésszolgáltatókat.
- Kód üzembe helyezése mindkét webalkalmazásban folyamatos üzembe helyezéssel.
Oktatóanyag: Magas rendelkezésre állású többrégiós alkalmazás létrehozása a Azure-alkalmazás Szolgáltatásban bemutatja, hogyan állíthat be aktív-passzív architektúrát.
Passzív-hideg architektúra
Passzív/hideg architektúrával létrehozhatja és karbantarthatja a webalkalmazások rendszeres biztonsági mentését egy másik régióban található Azure Storage-fiókban.
Ezzel a példaarchitektúrával:
A rendszer egyetlen webalkalmazást helyez üzembe egyetlen régióban.
A webalkalmazásról rendszeresen biztonsági másolatot készítünk egy Azure Storage-fiókról ugyanabban a régióban.
A biztonsági másolatok régiók közötti replikációja az Azure Storage-fiók adatredundancia-konfigurációjától függ. Ha lehetséges, az Azure Storage-fiókot GZRS-ként kell beállítania. A GZRS szinkron zónaredundanciát kínál egy régión belül és aszinkront egy másodlagos régióban. Ha a GZRS nem érhető el, konfigurálja a fiókot GRS-ként. A GZRS és a GRS is körülbelül 15 perces RPO-t használ.
Annak biztosítása érdekében, hogy a tárfiók elsődleges régiója elérhetetlenné válása esetén lekérhesse a biztonsági másolatokat, engedélyezze az írásvédett hozzáférést a másodlagos régióhoz (a tárfiók RA-GZRS vagy RA-GRS használatával). A georedundancia előnyeinek kihasználásához az alkalmazások tervezésével kapcsolatos további információkért lásd : Magas rendelkezésre állású alkalmazások tervezése georedundancia használatával.
A webalkalmazás régiójában bekövetkezett katasztrófa során manuálisan kell üzembe helyeznie az összes szükséges App Service-függő erőforrást az Azure Storage-fiók biztonsági másolatainak használatával, valószínűleg a másodlagos régióból, olvasási hozzáféréssel. Az RTO órák vagy napok lehetnek.
Az RTO minimalizálása érdekében ajánlott egy átfogó forgatókönyvvel rendelkeznie, amely ismerteti a webalkalmazás biztonsági mentésének egy másik Azure-régióba való visszaállításához szükséges lépéseket.
Az App Service-ben a webalkalmazás passzív-hideg régiójának létrehozásának lépései az alábbiak szerint vannak összefoglalva:
Hozzon létre egy Azure Storage-fiókot a webalkalmazással azonos régióban. Válassza a Standard teljesítményszintet, és válassza ki a redundanciát georedundáns tárolásként (GRS) vagy georedundáns tárolásként (GZRS).
RA-GRS vagy RA-GZRS engedélyezése (olvasási hozzáférés a másodlagos régióhoz).
Egyéni biztonsági mentés konfigurálása a webalkalmazáshoz. Dönthet úgy, hogy beállít egy ütemtervet a webalkalmazás biztonsági mentéséhez, például óránként.
Ellenőrizze, hogy a webalkalmazás biztonsági mentési fájljai lekérhetők-e a tárfiók másodlagos régiójában.
Tipp.
Az Azure Front Door mellett az Azure más terheléselosztási lehetőségeket is kínál, például az Azure Traffic Managert. A különböző lehetőségek összehasonlítása: Terheléselosztási lehetőségek – Azure Architecture Center.
Vészhelyreállítás egyrégiós földrajzi területen
Ha a webalkalmazás régiója nem rendelkezik GZRS- vagy GRS-tárterülettel, vagy ha olyan Azure-régióban van, amely nem tartozik regionális párok közé, akkor a zónaredundáns tárolást (ZRS) vagy helyileg redundáns tárolást (LRS) kell használnia egy hasonló architektúra létrehozásához. Például manuálisan is létrehozhat egy másodlagos régiót a tárfiókhoz az alábbiak szerint:
A GRS és GZRS nélküli passzív-hideg régió létrehozásának lépései az alábbiak szerint vannak összefoglalva:
Hozzon létre egy Azure Storage-fiókot a webalkalmazás ugyanazon régiójában. Válassza a Standard teljesítményszintet, és válassza ki a redundanciát zónaredundáns tárolásként (ZRS).
Egyéni biztonsági mentés konfigurálása a webalkalmazáshoz. Dönthet úgy, hogy beállít egy ütemtervet a webalkalmazás biztonsági mentéséhez, például óránként.
Ellenőrizze, hogy a webalkalmazás biztonsági mentési fájljai lekérhetők-e a tárfiók másodlagos régiójában.
Hozzon létre egy második Azure Storage-fiókot egy másik régióban. Válassza a Standard teljesítményszintet, és válassza ki a redundanciát helyileg redundáns tárolóként (LRS).
Egy olyan eszközzel, mint az AzCopy, replikálja az egyéni biztonsági mentést (Zip, XML és naplófájlok) az elsődleges régióból a másodlagos tárolóba. Példa:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Az Azure Automation egy PowerShell-munkafolyamat-runbook használatával ütemezetten futtathatja a replikációs szkriptet. Győződjön meg arról, hogy a replikáció ütemezése a webalkalmazás biztonsági mentéséhez hasonló ütemezést követ.