Megjegyzés:
Az App Service Environment 3-es verziója az architektúra fő összetevője. A 3. verzió már elérhető. Az 1. és a 2. verzió 2024 . augusztus 31-én megszűnik.
A rendelkezésre állási zónák fizikailag különálló adatközpont-gyűjtemények egy adott régióban. Az erőforrások zónák közötti üzembe helyezése biztosítja, hogy a zónákra korlátozott kimaradások ne befolyásolják az alkalmazások rendelkezésre állását. Ez az architektúra bemutatja, hogyan javíthatja az App Service-környezet üzembe helyezésének rugalmasságát egy zónavörös architektúrában való üzembe helyezéssel. Ezek a zónák nem kapcsolódnak a közelséghez. Különböző előfizetésekhez különböző fizikai helyekre képezhetik le őket. Az architektúra egy előfizetéses üzembe helyezést feltételez.
Ha az App Service-környezetet zónaredundánsként konfigurálja, a platform automatikusan üzembe helyezi a Azure-alkalmazás Szolgáltatáscsomag példányait a kijelölt régió három zónájában. Ezért az App Service-csomag minimális példányszáma mindig három.
A rendelkezésre állási zónákat támogató Azure-szolgáltatások lehetnek zónaredundánsak, zónaredundánsak vagy mindkettők. A zonal-szolgáltatások üzembe helyezhetők egy adott zónában. A zónaredundáns szolgáltatások automatikusan üzembe helyezhetők a zónák között. Részletes útmutatásért és javaslatokért tekintse meg a rendelkezésre állási zónák támogatását. Az App Service Environment (v2) előző verziója csak a zónatelepítéseket támogatta, de az aktuális verzió (v3) támogatja a zónaredundáns üzembe helyezéseket.
Az architektúra referencia-implementációja elérhető a GitHubon.
Architektúra
Töltse le az architektúra Visio-fájlját.
A referencia-implementáció App Service Environment alhálózataiban található erőforrások megegyeznek a standard App Service Environment üzembehelyezési architektúrában lévő erőforrásokkal. Ez a referencia-implementáció az App Service Environment v3 és az Azure Cache for Redis zónaredundáns képességeit használja a magasabb rendelkezésre állás biztosításához. Vegye figyelembe, hogy a referenciaarchitektúra hatóköre egyetlen régióra korlátozódik.
Workflow
Ez a szakasz az architektúrában használt szolgáltatások rendelkezésre állásának természetét ismerteti:
Az App Service Environment 3-at a zónaredundancia konfigurálhatja. A zónaredundanciát csak az App Service-környezet létrehozásakor konfigurálhatja, és csak olyan régiókban, amelyek támogatják az Összes App Service Environment v3-függőséget. A zónaredundáns App Service-környezetben minden App Service-csomagnak legalább három példánysal kell rendelkeznie, hogy három zónában lehessen üzembe helyezni őket. A minimális díj kilenc példányra szól. További információkért tekintse meg ezt a díjszabási útmutatót. Részletes útmutatásért és javaslatokért tekintse meg az App Service Environment rendelkezésre állási zónák támogatását.
Az Azure Virtual Network az egyetlen régióban található összes rendelkezésre állási zónára kiterjed. A virtuális hálózat alhálózatai a rendelkezésre állási zónákat is keresztezik. További információkért tekintse meg az App Service Environment hálózati követelményeit.
Az Application Gateway v2 zónaredundáns. A virtuális hálózathoz hasonlóan régiónként több rendelkezésre állási zónára is kiterjed. Ezért egyetlen application gateway elegendő egy magas rendelkezésre állású rendszerhez, ahogy az a referenciaarchitektúrában is látható. A referenciaarchitektúra az Application Gateway WAF-termékváltozatát használja, amely fokozott védelmet nyújt a gyakori fenyegetések és biztonsági rések ellen az Open Web Application Security Project (OWASP) alapvető szabálykészletének (CRS) implementációja alapján. További információ: Application Gateway v2 és WAF v2 skálázása.
Az Azure Firewall beépített támogatást nyújt a magas rendelkezésre álláshoz. Több zónát is átléphet további konfiguráció nélkül.
Szükség esetén konfigurálhat egy adott rendelkezésre állási zónát is a tűzfal telepítésekor. További információt az Azure Firewall és a rendelkezésre állási zónákban talál. (Ezt a konfigurációt a referenciaarchitektúra nem használja.)
A Microsoft Entra ID egy magas rendelkezésre állású, rendkívül redundáns globális szolgáltatás, amely a rendelkezésre állási zónákra és régiókra terjed ki. További információ: A Microsoft Entra rendelkezésre állásának előmozdítása.
A GitHub Actions folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) képességeket biztosít ebben az architektúrában. Mivel az App Service Environment a virtuális hálózatban található, a virtuális hálózatban egy virtuális gép használható jumpboxként az appok App Service-csomagokban való üzembe helyezéséhez. A művelet létrehozza az alkalmazásokat a virtuális hálózaton kívül. A fokozott biztonság és a zökkenőmentes RDP/SSH-kapcsolat érdekében fontolja meg az Azure Bastion használatát a jumpboxhoz.
Az Azure Cache for Redis egy zónaredundáns szolgáltatás. A zónaredundáns gyorsítótár több rendelkezésre állási zónában üzembe helyezett virtuális gépen fut. Ez a szolgáltatás nagyobb rugalmasságot és rendelkezésre állást biztosít.
Considerations
Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek készlete. További információ: Microsoft Azure Well-Architected Framework.
Availability
App Service Environment
Az App Service-környezetet a rendelkezésre állási zónákban is üzembe helyezheti, hogy rugalmasságot és megbízhatóságot biztosítson az üzletileg kritikus fontosságú számítási feladatokhoz. Ezt a konfigurációt zónaredundanciának is nevezik.
A zónaredundancia megvalósításakor a platform automatikusan üzembe helyezi az App Service-csomag példányait a kiválasztott régió három zónájában. Ezért az App Service-csomag minimális példányszáma mindig három. Ha háromnál nagyobb kapacitást ad meg, és a példányok száma hárommal osztható meg, a példányok egyenletesen lesznek üzembe helyezve. Ellenkező esetben a rendszer hozzáadja a fennmaradó példányokat a fennmaradó zónához, vagy üzembe helyezi a fennmaradó két zónában.
- Az App Service-környezet létrehozásakor konfigurálja a rendelkezésre állási zónákat.
- Az App Service-környezetben létrehozott összes App Service-csomaghoz legalább három példány szükséges. Ezek automatikusan zónaredundánsak lesznek.
- A rendelkezésre állási zónákat csak új App Service-környezet létrehozásakor adhatja meg. A meglévő App Service-környezetek nem alakíthatók át rendelkezésre állási zónák használatára.
- A rendelkezésre állási zónák csak a régiók egy részhalmazában támogatottak.
További információ: App Service-környezet migrálása a rendelkezésre állási zónák támogatásához.
Rugalmasság
Az App Service-környezetben futó alkalmazások alkotják az Application Gateway háttérkészletét . Amikor az alkalmazáshoz érkező kérés a nyilvános internetről érkezik, az átjáró továbbítja a kérést az App Service-környezetben futó alkalmazásnak. Ez a referenciaarchitektúra a fő webes előtérben, az állapotellenőrzéseket valósítja megvotingApp
. Ez az állapotadat-mintavétel ellenőrzi, hogy a webes API és a Redis-gyorsítótár kifogástalan állapotban van-e. A mintavételt megvalósító kód a Startup.cs-ben látható:
var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
{
Path = "/health"
};
services.AddHealthChecks()
.AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
.AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));
Az alábbi kód bemutatja, hogyan konfigurálja a commands_ha.azcli szkript a háttérkészleteket és az application gateway állapotmintát:
# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
"name": "votapp",
"routingPriority": 100,
"hostName": "${APPGW_APP1_URL}",
"backendAddresses": [
{
"fqdn": "${INTERNAL_APP1_URL}"
}
],
"certificate": {
"data": "${CERT_DATA_1}",
"password": "${PFX_PASSWORD}"
},
"probePath": "/health"
}
]
Ha valamelyik összetevő (a webes előtér, az API vagy a gyorsítótár) sikertelen az állapotadat-mintavételen, az Application Gateway átirányítja a kérést a háttérkészlet másik alkalmazásához. Ez a konfiguráció biztosítja, hogy a kérés mindig egy teljesen elérhető App Service Environment-alhálózaton legyen átirányítva az alkalmazáshoz.
Az állapotadat-mintavétel a standard referencia-implementációban is implementálva van. Ott az átjáró egyszerűen hibát ad vissza, ha az állapotadat-mintavétel sikertelen. A magas rendelkezésre állású megvalósítás azonban javítja az alkalmazás rugalmasságát és a felhasználói élmény minőségét.
Költségoptimalizálás
A költségoptimalizálás a szükségtelen kiadások csökkentéséről és a működési hatékonyság javításáról szól. További információ: A költségoptimalizálási pillér áttekintése.
A magas rendelkezésre állású architektúra költségei hasonlóak a standard üzemelő példányéhoz.
A következő különbségek befolyásolhatják a költségeket:
- Egy zónaredundáns App Service-környezetben legalább kilenc App Service-csomagpéldányért kell fizetnie. További információkért tekintse meg az App Service Environment díjszabását.
- Az Azure Cache for Redis szintén zónaredundáns szolgáltatás. A zónaredundáns gyorsítótár olyan virtuális gépeken fut, amelyek több rendelkezésre állási zónában vannak üzembe helyezve, így nagyobb rugalmasságot és rendelkezésre állást biztosítanak.
A magas rendelkezésre állású, rugalmas és rendkívül biztonságos rendszerek kompromisszuma a költségek növelése. A díjszabási kalkulátor segítségével értékelheti ki az igényeit a díjszabással kapcsolatban.
Deployment considerations
Ez a referencia-implementáció ugyanazt az éles szintű CI/CD-folyamatot használja, mint a szabványos üzembe helyezés, csak egy jumpbox virtuális géppel. Dönthet azonban úgy, hogy a három zóna mindegyikéhez egy jumpboxot használ. Ez az architektúra csak egy jumpboxot használ, mert a jumpbox nem befolyásolja az alkalmazás rendelkezésre állását. A jumpbox csak üzembe helyezéshez és teszteléshez használható.
A forgatókönyv üzembe helyezése
Az architektúra referencia-implementációjának üzembe helyezésével kapcsolatos információkért tekintse meg a GitHub-olvasót. Használja a szkriptet a magas rendelkezésre állású üzembe helyezéshez.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerzők:
- Mély Bhattacharya | Felhőmegoldás-tervező
- Suhas Rao | Felhőmegoldás-tervező
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
Következő lépések
Ezt az architektúrát úgy módosíthatja, hogy horizontálisan skálázhatja az alkalmazásokat ugyanabban a régióban vagy több régióban a várt maximális terhelési kapacitás alapján. Az alkalmazások több régióban történő replikálása segíthet csökkenteni a szélesebb körű földrajzi adatközpont-meghibásodások, például a földrengések vagy más természeti katasztrófák által okozott kockázatokat. A horizontális skálázásról további információt az App Service-környezetekkel rendelkező Geo Distributed Scale című témakörben talál. Globális és magas rendelkezésre állású útválasztási megoldás esetén fontolja meg az Azure Front Door használatát.