Magas rendelkezésre állású vállalati üzembe helyezés az App Service Environment használatával

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.