Az Azure-ban kritikus fontosságú számítási feladatok alkalmazásplatform-szempontjai

Az Azure számos számítási szolgáltatást biztosít a magas rendelkezésre állású alkalmazások üzemeltetéséhez. A szolgáltatások képességükben és összetettségükben különböznek. Javasoljuk, hogy a következő szolgáltatások alapján válasszon szolgáltatásokat:

• A megbízhatóságra, rendelkezésre állásra, teljesítményre és biztonságra vonatkozó nem funkcionális követelmények.
• Olyan döntési tényezők, mint a méretezhetőség, a költség, az működőképesség és az összetettség.

Az alkalmazásüzemeltési platform kiválasztása kritikus döntés, amely minden más tervezési területet érint. Előfordulhat például, hogy az örökölt vagy saját fejlesztésű szoftverek nem paaS-szolgáltatásokban vagy tárolóalapú alkalmazásokban futnak. Ez a korlátozás befolyásolná a számítási platform kiválasztását.

A kritikus fontosságú alkalmazások több számítási szolgáltatást is használhatnak több összetett számítási feladat és mikroszolgáltatás támogatására, amelyek mindegyike különböző követelményekkel rendelkezik.

Ez a tervezési terület a számítási kijelöléssel, a tervezéssel és a konfigurációs lehetőségekkel kapcsolatos javaslatokat nyújt. Azt is javasoljuk, hogy ismerkedjen meg a Számítási döntési fával.

Fontos

Ez a cikk az Azure Well-Architected Framework kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a Mi az a kritikus fontosságú számítási feladat? című témakörrel.

Platformerőforrások globális elosztása

A kritikus fontosságú számítási feladatok tipikus mintája a globális erőforrások és a regionális erőforrások.

Az Azure-szolgáltatások, amelyek nem korlátozódnak egy adott Azure-régióra, globális erőforrásként vannak üzembe helyezve vagy konfigurálva. Egyes használati esetek közé tartozik a forgalom több régió közötti elosztása, egy teljes alkalmazás állandó állapotának tárolása és a globális statikus adatok gyorsítótárazása. Ha a skálázási egységek architektúrájára és a globális terjesztésre is szüksége van, gondolja át, hogyan vannak optimálisan elosztva vagy replikálva az erőforrások az Azure-régiók között.

Az egyéb erőforrások regionálisan vannak üzembe helyezve. Ezek az erőforrások, amelyek az üzembehelyezési bélyeg részeként vannak üzembe helyezve, általában egy skálázási egységnek felelnek meg. Egy régió azonban több bélyeggel is rendelkezhet, és a bélyegek egynél több egységből is lehetnek. A regionális erőforrások megbízhatósága kritikus fontosságú, mivel ők felelősek a fő számítási feladat futtatásáért.

Az alábbi képen a magas szintű kialakítás látható. A felhasználó egy központi globális belépési ponton keresztül fér hozzá az alkalmazáshoz, amely ezután átirányítja a kéréseket egy megfelelő regionális üzembehelyezési bélyegzőre:

A kritikus fontosságú tervezési módszertanhoz többrégiós üzembe helyezésre van szükség. Ez a modell regionális hibatűrést biztosít, így az alkalmazás akkor is elérhető marad, ha egy teljes régió leáll. Többrégiós alkalmazások tervezésekor fontolja meg a különböző üzembehelyezési stratégiákat, például az aktív/aktív és az aktív/passzív, valamint az alkalmazásra vonatkozó követelményeket, mivel az egyes megközelítések jelentős kompromisszumot jelentenek. Kritikus fontosságú számítási feladatok esetén határozottan javasoljuk az aktív/aktív modellt.

Nem minden számítási feladat támogatja vagy igényli több régió egyidejű futtatását. Az optimális tervezési döntés meghatározásához mérlegelnie kell az alkalmazásra vonatkozó követelményeket a kompromisszumokkal szemben. Bizonyos, alacsonyabb megbízhatósági célokkal rendelkező alkalmazási forgatókönyvek esetében az aktív/passzív vagy horizontális skálázás megfelelő alternatíva lehet.

A rendelkezésre állási zónák magas rendelkezésre állású regionális üzemelő példányokat biztosíthatnak egy régió különböző adatközpontjaiban. Szinte minden Azure-szolgáltatás elérhető egy zónaszintű konfigurációban, ahol a szolgáltatás egy adott zónába van delegálva, vagy egy zónaredundáns konfigurációban, ahol a platform automatikusan biztosítja, hogy a szolgáltatás kiterjedjen a zónákra, és ellenálljon a zónakimaradásnak. Ezek a konfigurációk az adatközpont szintjéig biztosítják a hibatűrést.

Kialakítási szempontok

• Regionális és zónaszintű képességek. Nem minden szolgáltatás és képesség érhető el minden Azure-régióban. Ez a szempont hatással lehet a választott régiókra. A rendelkezésre állási zónák nem minden régióban érhetők el.

• Regionális párok. Az Azure-régiók regionális párokba vannak csoportosítva, amelyek egyetlen földrajzi régióban két régióból állnak. Egyes Azure-szolgáltatások párosított régiókat használnak az üzletmenet folytonosságának biztosítása és az adatvesztés elleni védelem biztosítása érdekében. Az Azure georedundáns tárolás (GRS) például automatikusan replikálja az adatokat egy másodlagos párosított régióba, biztosítva, hogy az adatok tartósak legyenek, ha az elsődleges régió nem állítható helyre. Ha egy szolgáltatáskimaradás több Azure-régiót érint, az egyes párok legalább egy régiója prioritást élvez a helyreállításhoz.

• Adatkonzisztencia. Konzisztenciaproblémák esetén fontolja meg egy globálisan elosztott adattár, egy bélyegzett regionális architektúra és egy részben aktív/aktív üzembe helyezés használatát. Részleges üzembe helyezés esetén egyes összetevők az összes régióban aktívak, míg mások központilag az elsődleges régión belül találhatók.

• Biztonságos üzembe helyezés. Az Azure biztonságos üzembehelyezési gyakorlatának (SDP) keretrendszere biztosítja, hogy az Azure-platformon végrehajtott összes kód- és konfigurációmódosítás (tervezett karbantartás) szakaszos bevezetésen megy keresztül. Az állapot elemzése a kiadás során romlik. A kanári- és próbafázisok sikeres befejezése után a platformfrissítések a regionális párok között szerializálódnak, így az egyes párokban csak egy régió frissül egy adott időpontban.

• Platformkapacitás. Mint minden felhőszolgáltató, az Azure is rendelkezik véges erőforrásokkal. Az elérhetetlenség a régiók kapacitáskorlátozásainak következménye lehet. Regionális kimaradás esetén az erőforrások iránti kereslet megnő, amikor a számítási feladat a párosított régión belül próbál helyreállni. A szolgáltatáskimaradás kapacitásproblémát eredményezhet, ahol a kínálat átmenetileg nem felel meg az igényeknek.

Tervezési javaslatok

• A megoldás üzembe helyezése legalább két Azure-régióban a regionális kimaradások elleni védelem érdekében. Olyan régiókban helyezze üzembe, amelyek rendelkeznek a számítási feladathoz szükséges képességekkel és jellemzőkkel. A képességeknek meg kell felelniük a teljesítménnyel és a rendelkezésre állással kapcsolatos céloknak, miközben teljesítik az adattárolási és adatmegőrzési követelményeket.

  Előfordulhat például, hogy egyes adatmegfelelési követelmények korlátozzák az elérhető régiók számát, és potenciálisan biztonsági réseket kényszerítenek ki a tervezésben. Ilyen esetekben határozottan javasoljuk, hogy adjon hozzá további befektetést az operatív burkolókkal a hibák előrejelzéséhez, észleléséhez és megválaszolásához. Tegyük fel, hogy egy két régióval rendelkező földrajzi régióra van korlátozva, és ezek közül csak az egyik támogatja a rendelkezésre állási zónákat (3 + 1 adatközponti modell). Hozzon létre egy másodlagos üzembehelyezési mintát tartaléktartomány-elkülönítéssel, hogy mindkét régió üzembe helyezhető legyen egy aktív konfigurációban, és győződjön meg arról, hogy az elsődleges régió több üzembehelyezési bélyeget is tartalmaz.

  Ha a megfelelő Azure-régiók nem minden szükséges képességet kínálnak, készüljön fel a regionális üzembehelyezési bélyegek konzisztenciájának sérülésére a földrajzi elosztás rangsorolása és a megbízhatóság maximalizálása érdekében. Ha csak egyetlen Azure-régió megfelelő, helyezzen üzembe több üzembehelyezési bélyeget (regionális skálázási egységeket) a kiválasztott régióban a kockázat csökkentése érdekében, és használjon rendelkezésre állási zónákat az adatközpontszintű hibatűrés biztosításához. A földrajzi elosztás ilyen jelentős kompromisszuma azonban jelentősen korlátozza az elérhető összetett SLA-t és az általános megbízhatóságot.

  Fontos

  Olyan forgatókönyvek esetében, amelyek 99,99%-nál nagyobb vagy egyenlő SLO-t céloznak meg, legalább három üzembehelyezési régiót ajánlunk az összetett SLA és az általános megbízhatóság maximalizálása érdekében. Számítsa ki az összes felhasználói folyamat összetett SLA-ját . Győződjön meg arról, hogy az összetett SLA megfelel az üzleti céloknak.

• Olyan nagy léptékű alkalmazásforgatókönyvek esetén, amelyek jelentős mennyiségű forgalmat bonyolítanak le, úgy tervezzen meg egy megoldást, hogy több régióra skálázva navigáljon a lehetséges kapacitáskorlátozások között egyetlen régióban. A további regionális üzembehelyezési bélyegek magasabb összetett SLA-t eredményeznek. A globális erőforrások használata korlátozza az összetett SLA növelését, amelyet több régió hozzáadásával érhet el.

• A helyreállítási időkorlátok (RPO) és a helyreállítási időkorlátok (RTO) meghatározása és ellenőrzése.

• Egyetlen földrajzi helyen rangsorolja a regionális párok használatát, hogy kihasználják az SDP szerializált bevezetéseit a tervezett karbantartáshoz, és regionális rangsorolást a nem tervezett karbantartásokhoz.

• Az Azure-erőforrások földrajzi elhelyezkedése a felhasználókkal a hálózati késés minimalizálása és a teljes teljesítmény maximalizálása érdekében.

  • Az elosztott felhasználói bázisok optimális hálózati késésének eléréséhez olyan megoldásokat is használhat, mint a Content Delivery Network (CDN) vagy a peremhálózati gyorsítótárazás. További információ: Globális forgalomirányítás, alkalmazáskézbesítési szolgáltatások, gyorsítótárazás és statikus tartalomkézbesítés.

• Az üzembehelyezési régiók kiválasztásakor az aktuális szolgáltatás rendelkezésre állását a termékfejlesztési ütemtervekhez igazíthatja. Előfordulhat, hogy egyes szolgáltatások nem érhetők el azonnal minden régióban.

Elkülönítés konténerek használatával

A tároló tartalmazza az alkalmazáskódot, valamint az alkalmazás futtatásához szükséges kapcsolódó konfigurációs fájlokat, kódtárakat és függőségeket. A containerization absztrakciós réteget biztosít az alkalmazáskódhoz és annak függőségeihez, és elkülöníti az alapul szolgáló üzemeltetési platformtól. Az egyetlen szoftvercsomag rendkívül hordozható, és konzisztensen futtatható a különböző infrastruktúraplatformokon és felhőszolgáltatókon. A fejlesztőknek nem kell átírni a kódot, és gyorsabban és megbízhatóbban helyezhetnek üzembe alkalmazásokat.

Fontos

Javasoljuk, hogy használjon tárolókat a kritikus fontosságú alkalmazáscsomagokhoz. Javítják az infrastruktúra kihasználtságát, mivel több tárolót is üzemeltethet ugyanazon a virtualizált infrastruktúrán. Mivel a tárolóban minden szoftver megtalálható, a futtatókörnyezettől és a kódtár verzióitól függetlenül áthelyezheti az alkalmazást különböző operációs rendszerek között. A tárolók kezelése is egyszerűbb, mint a hagyományos virtualizált üzemeltetés esetében.

A kritikus fontosságú alkalmazásoknak gyorsan kell méretezniük a teljesítmény szűk keresztmetszeteinek elkerülése érdekében. Mivel a tárolórendszerképek előre fel vannak építve, korlátozhatja, hogy az indítás csak az alkalmazás rendszerindítása során történjen, ami gyors méretezhetőséget biztosít.

Kialakítási szempontok

• Figyelés. A monitorozási szolgáltatások nehezen férnek hozzá a tárolókban található alkalmazásokhoz. Általában külső szoftverre van szüksége a tárolóállapot-mutatók, például a PROCESSZOR- vagy RAM-használat gyűjtéséhez és tárolásához.

• Biztonság. Az üzemeltetési platform operációsrendszer-kernele több tárolóban van megosztva, és egyetlen támadási pontot hoz létre. A gazdagép virtuálisgép-hozzáférésének kockázata azonban korlátozott, mert a tárolók el vannak különítve a mögöttes operációs rendszertől.

• Állapot. Bár az adatok tárolhatók egy futó tároló fájlrendszerében, az adatok nem maradnak meg a tároló újbóli létrehozásakor. Ehelyett külső tároló csatlakoztatásával vagy külső adatbázis használatával őrizheti meg az adatokat.

Tervezési javaslatok

• Az összes alkalmazásösszetevő tárolóba helyezése. Tárolórendszerképek használata az alkalmazástelepítési csomagok elsődleges modelljeként.

• Ha lehetséges, rangsorolja a Linux-alapú tároló-futtatókörnyezeteket. A rendszerképek egyszerűbbek, és a Linux-csomópontok/-tárolók új funkciói gyakran jelennek meg.

• A tárolók nem módosíthatók és cserélhetők, rövid életciklussal.

• Mindenképpen gyűjtse össze az összes releváns naplót és metrikát a tárolóból, a tároló gazdagépről és a mögöttes fürtből. Küldje el az összegyűjtött naplókat és metrikákat egy egységes adatgyűjtőbe további feldolgozás és elemzés céljából.

• Tárolórendszerképek tárolása Azure Container Registry. A georeplikációval minden régióban replikálhatja a tárolórendszerképeket. Engedélyezze Microsoft Defender tárolóregisztrációs adatbázisok számára a tárolólemezképek biztonságirés-vizsgálatának biztosítását. Győződjön meg arról, hogy a beállításjegyzékhez való hozzáférést Microsoft Entra azonosító kezeli.

Tároló üzemeltetése és vezénylése

Számos Azure-alkalmazásplatform képes hatékonyan tárolókat üzemeltetni. Ezeknek a platformoknak vannak előnyei és hátrányai. Hasonlítsa össze a lehetőségeket az üzleti követelmények kontextusában. Azonban mindig optimalizálja a megbízhatóságot, a méretezhetőséget és a teljesítményt. További információért lásd a következő cikkeket:

• Számítási döntési fa
• Tárolóbeállítás-összehasonlítások

Fontos

Azure Kubernetes Service (AKS) és az Azure Container Apps legyen az első tárolófelügyeleti lehetőség a követelményektől függően. Bár Azure App Service nem vezénylő, alacsony súrlódású tárolóplatformként továbbra is megvalósítható alternatívája az AKS-nek.

Tervezési szempontok és javaslatok a Azure Kubernetes Service

A felügyelt Kubernetes-szolgáltatás, az AKS lehetővé teszi a gyors fürtkiépítést anélkül, hogy összetett fürtfelügyeleti tevékenységeket kellene elvégeznie, és olyan funkciókészletet kínál, amely fejlett hálózatkezelési és identitáskezelési képességeket tartalmaz. A javaslatok teljes készletét lásd: Azure Well-Architected Framework review – AKS.

Fontos

Vannak olyan alapvető konfigurációs döntések, amelyeket nem lehet módosítani az AKS-fürt újbóli üzembe helyezése nélkül. Ilyen például a nyilvános és a privát AKS-fürtök közötti választás, az Azure Network Policy engedélyezése, Microsoft Entra integráció, valamint a felügyelt identitások használata az AKS-hez szolgáltatásnevek helyett.

Megbízhatóság

Az AKS kezeli a natív Kubernetes vezérlősíkot. Ha a vezérlősík nem érhető el, a számítási feladat állásidőt tapasztal. Használja ki az AKS által kínált megbízhatósági funkciókat:

• AKS-fürtök üzembe helyezése különböző Azure-régiókban méretezési egységként a megbízhatóság és a rendelkezésre állás maximalizálása érdekében. Rendelkezésre állási zónák használatával maximalizálhatja a rugalmasságot egy Azure-régióban az AKS vezérlősík és ügynökcsomópontok fizikailag különálló adatközpontokban való elosztásával. Ha azonban a közös elhelyezés késése probléma, az AKS üzembe helyezését egyetlen zónán belül végezheti el, vagy közelségi elhelyezési csoportokkal minimalizálhatja az csomópontok közötti késést.

• Az éles fürtökhöz készült AKS Üzemidő SLA használatával maximalizálhatja a Kubernetes API-végpontok rendelkezésre állási garanciáit.

Méretezhetőség

Vegye figyelembe az AKS méretezési korlátait, például a csomópontok számát, a fürtnkénti csomópontkészleteket és az előfizetésenkénti fürtöket.

• Ha a skálázási korlátok kényszerek, használja ki a skálázási egységek stratégiáját, és helyezzen üzembe több egységet fürtökkel.

• Engedélyezze a fürt automatikus skálázási funkcióját , hogy automatikusan módosítsa az ügynökcsomópontok számát az erőforrás-korlátozásokra válaszul.

• A podok automatikus horizontális skálázásával a processzorhasználat vagy más metrikák alapján módosíthatja az üzembe helyezésben lévő podok számát.

• Nagy léptékű és kipukkanó forgatókönyvek esetén fontolja meg a virtuális csomópontok széles körű és gyors skálázásra való használatát.

• Poderőforrás-kérések és -korlátok meghatározása az alkalmazástelepítési jegyzékekben. Ha nem, teljesítményproblémák léphetnek fel.

Elkülönítés

A számítási feladat és a rendszereszközök által használt infrastruktúra közötti határok fenntartása. Az infrastruktúra megosztása magas erőforrás-kihasználtsághoz és zajos szomszéd forgatókönyvekhez vezethet.

• Használjon külön csomópontkészleteket a rendszer- és számításifeladat-szolgáltatásokhoz. A számítási feladatok összetevőinek dedikált csomópontkészleteinek speciális infrastruktúra-erőforrásokra, például nagy memóriájú GPU-ra vonatkozó követelményeken kell alapulnia. Általánosságban elmondható, hogy a felesleges felügyeleti többletterhelés csökkentése érdekében ne helyezzen üzembe nagy számú csomópontkészletet.

• Használjon fertőzöttségeket és tűréseket a dedikált csomópontok biztosításához és az erőforrás-igényes alkalmazások korlátozásához.

• Értékelje ki az alkalmazás-affinitási és az affinitás-ellenes követelményeket, és konfigurálja a tárolók megfelelő áthelyezését a csomópontokon.

Biztonság

Az alapértelmezett vanília Kubernetes jelentős konfigurációt igényel a kritikus fontosságú forgatókönyvek megfelelő biztonsági állapotának biztosításához. Az AKS a dobozon kívül különböző biztonsági kockázatokkal foglalkozik. A funkciók közé tartoznak a privát fürtök, a Log Analytics naplózása és bejelentkezése, a rögzített csomópontrendszerképek és a felügyelt identitások.

• Az AKS biztonsági alapkonfigurációjában megadott konfigurációs útmutató alkalmazása.

• Az AKS-funkciók használatával kezelhetők a fürt identitás- és hozzáférés-kezelési funkciói, így csökkenthetők a működési terhelések, és konzisztens hozzáférés-kezelést alkalmazhatnak.

• A felügyelt identitások használata szolgáltatásnevek helyett a hitelesítő adatok kezelésének és rotálásának elkerülése érdekében. Felügyelt identitásokat a fürt szintjén adhat hozzá. A pod szintjén felügyelt identitásokat használhat Microsoft Entra Számítási feladat ID keresztül.

• Használja Microsoft Entra integrációt a központosított fiókkezeléshez és jelszavakhoz, az alkalmazáshozzáférés-kezeléshez és a fokozott identitásvédelemhez. Használja a Kubernetes RBAC-t Microsoft Entra azonosítóval a minimális jogosultság érdekében, és minimalizálja a rendszergazdai jogosultságok megadását a konfiguráció és a titkos kódok hozzáférésének védelme érdekében. Emellett az Azure szerepköralapú hozzáférés-vezérlésével korlátozhatja a Kubernetes-fürtkonfigurációs fájlhoz való hozzáférést. Korlátozza a tárolók által végrehajtható műveletekhez való hozzáférést, adja meg a legkevesebb engedélyt, és kerülje a legfelső szintű jogosultságok eszkalálásának használatát.

Frissítések

A fürtöket és csomópontokat rendszeresen frissíteni kell. Az AKS a natív Kubernetes kiadási ciklusával összhangban támogatja a Kubernetes-verziókat .

• Iratkozzon fel a Nyilvános AKS-ütemtervre és kibocsátási megjegyzésekre a GitHubon, hogy naprakész maradjon a közelgő változásokról, fejlesztésekről, és ami a legfontosabb, a Kubernetes-verziókiadásokról és -elavulásokról.

• Alkalmazza az AKS ellenőrzőlistájában található útmutatást az ajánlott eljárásoknak való megfelelés érdekében.

• Vegye figyelembe az AKS által a csomópontok és/vagy fürtök frissítéséhez támogatott különböző módszereket. Ezek a módszerek lehetnek manuálisak vagy automatizáltak. A tervezett karbantartással karbantartási ablakokat határozhat meg ezekhez a műveletekhez. Az új képek hetente jelennek meg. Az AKS emellett támogatja az automatikus frissítési csatornákat az AKS-fürtök kubernetes és/vagy újabb csomópontrendszerképek újabb verzióira való automatikus frissítéséhez, ha elérhetők.

Hálózatkezelés

Értékelje ki a használati esetnek leginkább megfelelő hálózati beépülő modulokat. Határozza meg, hogy a podok közötti forgalom részletes szabályozására van-e szükség. Az Azure támogatja a kubenetet, az Azure CNI-t, és saját CNI-t hoz adott használati esetekhez.

Rangsorolja az Azure CNI használatát a hálózati követelmények és a fürt méretének felmérése után. Az Azure CNI lehetővé teszi az Azure- vagy Calico-hálózati szabályzatok használatát a fürtön belüli forgalom szabályozásához.

Figyelés

A monitorozási eszközöknek képesnek kell lenniük naplók és metrikák rögzítésére a futó podokból. A Kubernetes Metrics API-ból is adatokat kell gyűjtenie az erőforrások és számítási feladatok állapotának monitorozásához.

• Az Azure Monitor és az Application Insights segítségével metrikákat, naplókat és diagnosztikákat gyűjthet az AKS-erőforrásokból hibaelhárítás céljából.

• Kubernetes-erőforrásnaplók engedélyezése és áttekintése.

• Prometheus-metrikák konfigurálása az Azure Monitorban. A Monitor tárolóelemzései előkészítést biztosítanak, lehetővé teszik a monitorozási képességeket a dobozon kívül, és a beépített Prometheus-támogatással fejlettebb képességeket is lehetővé tesz.

Szabályozás

A szabályzatok használatával egységesen alkalmazhat központosított biztosítékokat az AKS-fürtökre. Szabályzat-hozzárendelések alkalmazásával egy előfizetési hatókörben vagy annál magasabb szinten konzisztenciát alakíthat ki a fejlesztői csapatok között.

• Az Azure Policy használatával szabályozhatja, hogy mely függvények legyenek a podok számára megadva, és hogy a futtatás ellentmond-e a szabályzatnak. Ezt a hozzáférést az AKS Azure Policy bővítménye által biztosított beépített szabályzatok határozzák meg.

• Konzisztens megbízhatósági és biztonsági alapkonfiguráció létrehozása az AKS-fürt- és podkonfigurációkhoz Azure Policy használatával.

• Az AKS Azure Policy bővítményével vezérelheti a podfüggvényeket, például a gyökérjogjogokat, és letilthatja a szabályzatnak nem megfelelő podokat.

Megjegyzés

Amikor üzembe helyez egy Azure-beli célzónát, a célzóna-implementációnak biztosítania kell a konzisztens megbízhatóságot és biztonságot biztosító Azure-szabályzatokat.

A kritikus fontosságú referenciaimplementációk alapszintű szabályzatkészletet biztosítanak az ajánlott megbízhatósági és biztonsági konfigurációk eléréséhez.

Tervezési szempontok és javaslatok a Azure App Service

Webes és API-alapú számítási feladatok esetén a App Service az AKS megvalósítható alternatívája lehet. Alacsony súrlódású tárolóplatformot biztosít a Kubernetes összetettsége nélkül. A javaslatok teljes halmazáért lásd: A App Service megbízhatósági szempontjai és az App Service működési kiválósága.

Megbízhatóság

Értékelje ki a TCP- és SNAT-portok használatát. A TCP-kapcsolatok az összes kimenő kapcsolathoz használatosak. Az SNAT-portok a nyilvános IP-címek felé irányuló kimenő kapcsolatokhoz használatosak. Az SNAT-portok elfogyása gyakori hibaforgatókönyv. Ezt a problémát prediktív módon kell észlelnie terhelésteszteléssel, miközben Azure Diagnostics használ a portok monitorozásához. SNAT-hibák esetén vagy több vagy nagyobb feldolgozóra kell skáláznia, vagy kódolási eljárásokat kell alkalmaznia az SNAT-portok megőrzéséhez és újrafelhasználásához. Példák a használható kódolási eljárásokra, például a kapcsolatkészletezésre és az erőforrások lusta betöltésére.

A TCP-portok elfogyása egy másik hibaforgatókönyv. Akkor fordul elő, ha egy adott feldolgozó kimenő kapcsolatainak összege meghaladja a kapacitást. Az elérhető TCP-portok száma a feldolgozó méretétől függ. Javaslatokért lásd: TCP- és SNAT-portok.

Méretezhetőség

Tervezze meg a jövőbeli skálázhatósági követelményeket és az alkalmazások növekedését, hogy a kezdetektől fogva megfelelő javaslatokat alkalmazzon. Ezzel elkerülheti a technikai migrálási adósságot a megoldás növekedésével.

• Engedélyezze az automatikus skálázást annak biztosításához, hogy megfelelő erőforrások álljanak rendelkezésre a szolgáltatáskérések számára. Értékelje ki az alkalmazásonkénti skálázást a nagy sűrűségű üzemeltetéshez a App Service.

• Vegye figyelembe, hogy App Service a példányok alapértelmezett, helyreállítható korlátja App Service csomagonként.

• Automatikus skálázási szabályok alkalmazása. Egy App Service-terv felskálázódik, ha a profilon belüli bármely szabály teljesül, de csak akkor skáláz, ha a profilon belüli összes szabály teljesül. A vertikális felskálázási és a vertikális felskálázási szabálykombinációval biztosíthatja, hogy az automatikus skálázás képes legyen a vertikális felskálázásra és a vertikális felskálázásra is. Több skálázási szabály viselkedésének megismerése egyetlen profilban.

• Vegye figyelembe, hogy az alkalmazásonkénti skálázást a App Service csomag szintjén engedélyezheti, hogy az alkalmazások a skálázást az azt üzemeltető App Service csomagtól függetlenül engedélyezhessék. Az alkalmazások az elérhető csomópontokhoz vannak lefoglalva egy egyenletes elosztáshoz szükséges legjobb megközelítéssel. Bár a páros disztribúció nem garantált, a platform biztosítja, hogy ugyanazon alkalmazás két példánya ne ugyanazon a példányon futzon.

Figyelés

Monitorozza az alkalmazás viselkedését, és hozzáférjen a megfelelő naplókhoz és metrikákhoz, hogy az alkalmazás a várt módon működjön.

• A diagnosztikai naplózással alkalmazásszintű és platformszintű naplókat is betölthet a Log Analyticsbe, az Azure Storage-ba vagy egy harmadik féltől származó eszközbe Azure Event Hubs keresztül.

• Az Application Insights segítségével végzett alkalmazásteljesítmény-monitorozás részletes betekintést nyújt az alkalmazások teljesítményébe.

• A kritikus fontosságú alkalmazásoknak képesnek kell lenniük az öngyógyulására, ha hibák történnek. Engedélyezze az automatikus javítást a nem kifogástalan állapotú feldolgozók automatikus újrahasznosításához.

• A kritikus alárendelt függőségek értékeléséhez megfelelő állapotellenőrzéseket kell használnia, amelyek segítenek a teljes állapot biztosításában. Határozottan javasoljuk, hogy engedélyezze az állapot-ellenőrzést a nem reagáló feldolgozók azonosításához.

Üzembe helyezés

A példányok App Service csomagonkénti alapértelmezett korlátjának megkerüléséhez helyezzen üzembe App Service csomagokat több skálázási egységben egyetlen régióban. Helyezzen üzembe App Service csomagokat egy rendelkezésre állási zóna konfigurációjában, hogy a munkavégző csomópontok el legyenek osztva a régión belüli zónák között. Fontolja meg egy támogatási jegy megnyitását, hogy a feldolgozók maximális számát a normál csúcsterhelés kiszolgálásához szükséges példányszám kétszeresére növelje.

Tárolóregisztrációs adatbázis

A tárolóregisztrációs adatbázisok olyan tároló-futtatókörnyezetekben üzembe helyezett rendszerképeket üzemeltetnek, mint az AKS. Gondosan konfigurálnia kell a tárolóregisztrációs adatbázisokat a kritikus fontosságú számítási feladatokhoz. A kimaradás nem okozhat késést a képek lekérésében, különösen a skálázási műveletek során. Az alábbi szempontok és javaslatok a Azure Container Registry és a központosított és összevont üzemi modellekkel kapcsolatos kompromisszumok vizsgálatára összpontosítanak.

Kialakítási szempontok

• Formátum. Fontolja meg egy tárolóregisztrációs adatbázis használatát, amely a Docker által biztosított formátumra és szabványokra támaszkodik a leküldéses és a lekéréses műveletekhez is. Ezek a megoldások kompatibilisek és többnyire felcserélhetők.

• Üzembehelyezési modell. A tárolóregisztrációs adatbázist központi szolgáltatásként helyezheti üzembe, amelyet a szervezeten belül több alkalmazás használ. Vagy üzembe helyezheti dedikált összetevőként egy adott alkalmazás számítási feladatához.

• Nyilvános regisztrációs adatbázisok. A tárolórendszerképek Docker Hub vagy más, az Azure-on és egy adott virtuális hálózaton kívül létező nyilvános regisztrációs adatbázisokban vannak tárolva. Ez nem feltétlenül jelent problémát, de különböző problémákhoz vezethet, amelyek a szolgáltatás rendelkezésre állásával, szabályozásával és adatkiszivárgásával kapcsolatosak. Bizonyos alkalmazási helyzetekben a nyilvános tárolórendszerképeket replikálnia kell egy privát tárolóregisztrációs adatbázisban a kimenő forgalom korlátozásához, a rendelkezésre állás növeléséhez vagy a lehetséges szabályozás elkerüléséhez.

Tervezési javaslatok

• Használjon az alkalmazás számítási feladatához dedikált tárolóregisztrációs adatbázispéldányokat. Ne hozzon létre függőséget egy központosított szolgáltatáshoz, hacsak a szervezeti rendelkezésre állási és megbízhatósági követelmények nincsenek teljesen összhangban az alkalmazással.

  Az ajánlott alapvető architektúra-mintában a tárolóregisztrációs adatbázisok hosszú élettartamú globális erőforrások. Érdemes lehet környezetenként egyetlen globális tárolóregisztrációs adatbázist használni. Használjon például egy globális éles beállításjegyzéket.

• Győződjön meg arról, hogy a nyilvános beállításjegyzék SLA-ja megfelel a megbízhatósági és biztonsági céloknak. Jegyezze fel a Docker Hub függő használati esetek szabályozási korlátait.

• Fontossági sorrendbe Azure Container Registry tárolólemezképek üzemeltetéséhez.

Tervezési szempontok és javaslatok a Azure Container Registry

Ez a natív szolgáltatás számos funkciót biztosít, beleértve a georeplikációt, a Microsoft Entra hitelesítést, az automatizált tárolóépítést és a Container Registry-feladatokon keresztüli javításokat.

Megbízhatóság

Konfigurálja a georeplikációt az összes üzembehelyezési régióra a regionális függőségek eltávolításához és a késés optimalizálásához. A Container Registry támogatja a magas rendelkezésre állást több konfigurált régió georeplikációja révén, és rugalmasságot biztosít a regionális kimaradásokkal szemben. Ha egy régió elérhetetlenné válik, a többi régió továbbra is kiszolgálja a rendszerkép-kérelmeket. Amikor a régió ismét online állapotba kerül, a Container Registry helyreállítja és replikálja a módosításokat. Ez a képesség a beállításjegyzékek minden konfigurált régión belüli közös elhelyezését is biztosítja, csökkentve a hálózati késést és a régiók közötti adatátvitel költségeit.

A rendelkezésre állási zónák támogatását biztosító Azure-régiókban a Premium Container Registry szint támogatja a zónaredundanciát , hogy védelmet nyújtson az zónaszintű hibák ellen. A Prémium szint a privát végpontokat is támogatja a beállításjegyzékhez való jogosulatlan hozzáférés megakadályozása érdekében, ami megbízhatósági problémákhoz vezethet.

A rendszerképek a felhasználó számítási erőforrásokhoz közel, ugyanabban az Azure-régióban üzemelnek.

Képzárolás

A rendszerképek például manuális hiba miatt törölhetők. A Container Registry támogatja a rendszerképverziók vagy adattárak zárolását a módosítások vagy törlések megelőzése érdekében. Ha egy korábban üzembe helyezett rendszerképverziót módosítanak, az azonos verziójú üzemelő példányok eltérő eredményeket adhatnak a módosítás előtt és után.

Ha meg szeretné védeni a Container Registry-példányt a törléstől, használjon erőforrás-zárolásokat.

Címkézett képek

A címkézett tárolóregisztrációs adatbázis lemezképei alapértelmezés szerint módosíthatók, ami azt jelenti, hogy ugyanaz a címke több, a beállításjegyzékbe leküldett rendszerképen is használható. Éles forgatókönyvekben ez kiszámíthatatlan viselkedéshez vezethet, amely befolyásolhatja az alkalmazás üzemidejét.

Identitás- és hozzáférés-kezelés

Használja Microsoft Entra integrált hitelesítést a rendszerképek leküldéséhez és lekéréséhez a hozzáférési kulcsok használata helyett. A fokozott biztonság érdekében teljes mértékben tiltsa le a rendszergazdai hozzáférési kulcs használatát.

Kiszolgáló nélküli számítástechnika

A kiszolgáló nélküli számítástechnika igény szerint biztosít erőforrásokat, és szükségtelenné teszi az infrastruktúra kezelését. A felhőszolgáltató automatikusan kiépít, méretez és kezel az üzembe helyezett alkalmazáskód futtatásához szükséges erőforrásokat. Az Azure számos kiszolgáló nélküli számítási platformot biztosít:

• Azure Functions. A Azure Functions használatakor az alkalmazáslogika különböző kódblokkokként vagy függvényekként van implementálva, amelyek eseményekre, például HTTP-kérésre vagy üzenetsorra reagálva futnak. Minden függvény az igényeknek megfelelően méretezhető.

• Azure Logic Apps. A Logic Apps a legmegfelelőbb olyan automatizált munkafolyamatok létrehozásához és futtatásához, amelyek különböző alkalmazásokat, adatforrásokat, szolgáltatásokat és rendszereket integrálnak. Az Azure Functions-hez hasonlóan a Logic Apps is beépített eseményindítókat használ az eseményvezérelt feldolgozáshoz. Az alkalmazáskód üzembe helyezése helyett azonban létrehozhat logikai alkalmazásokat egy olyan grafikus felhasználói felülettel, amely támogatja a kódblokkokat, például a feltételes és a hurkokat.

• Azure API Management. A API Management használatával kibővített biztonsági API-kat tehet közzé, alakíthat át, tarthat karban és monitorozhat a Használat szint használatával.

• Power Apps és Power Automate. Ezek az eszközök alacsony kódszámú vagy kód nélküli fejlesztési élményt biztosítanak, egyszerű munkafolyamat-logikával és integrációkkal, amelyek a felhasználói felületen lévő kapcsolatokon keresztül konfigurálhatók.

A kritikus fontosságú alkalmazások esetében a kiszolgáló nélküli technológiák egyszerűsített fejlesztést és üzemeltetést biztosítanak, ami értékes lehet az egyszerű üzleti használati esetekben. Ez az egyszerűség azonban a skálázhatóság, a megbízhatóság és a teljesítmény terén a rugalmasságot illeti, és ez a legtöbb kritikus fontosságú alkalmazásforgatókönyv esetében nem kivitelezhető.

Az alábbi szakaszok tervezési szempontokat és javaslatokat nyújtanak a Azure Functions és a Logic Apps alternatív platformként való használatához a nem kritikus munkafolyamat-forgatókönyvekhez.

Tervezési szempontok és javaslatok a Azure Functions

A kritikus fontosságú számítási feladatok kritikus és nem kritikus rendszerfolyamatokkal rendelkeznek. Azure Functions a kritikus rendszerfolyamatokkal azonos szigorú üzleti követelményekkel nem rendelkező folyamatok esetében megfelelő választás. Kiválóan alkalmas olyan eseményvezérelt folyamatokhoz, amelyek rövid élettartamú folyamatokkal rendelkeznek, mivel a függvények különböző műveleteket hajtanak végre, amelyek a lehető leggyorsabban futnak.

Válasszon egy Azure Functions üzemeltetési lehetőséget, amely megfelel az alkalmazás megbízhatósági szintjének. A Prémium csomagot javasoljuk, mert lehetővé teszi a számítási példány méretének konfigurálását. A dedikált csomag a legkevésbé kiszolgáló nélküli lehetőség. Automatikus skálázást biztosít, de ezek a skálázási műveletek lassabbak, mint a többi csomagé. Javasoljuk, hogy a Prémium csomaggal maximalizálja a megbízhatóságot és a teljesítményt.

Van néhány biztonsági szempont. Ha EGY HTTP-eseményindítót használ egy külső végpont elérhetővé tételéhez, webalkalmazási tűzfal (WAF) használatával biztosítson védelmet a HTTP-végpont számára a gyakori külső támadási vektoroktól.

A privát virtuális hálózatokhoz való hozzáférés korlátozásához javasoljuk a privát végpontok használatát. Emellett az adatkiszivárgási kockázatokat is mérsékelhetik, például a rosszindulatú rendszergazdai forgatókönyveket.

Kódolvasó eszközöket kell használnia Azure Functions kódon, és integrálnia kell ezeket az eszközöket a CI/CD-folyamatokkal.

Tervezési szempontok és javaslatok az Azure Logic Appshez

Az Azure Functions-hez hasonlóan a Logic Apps is beépített eseményindítókat használ az eseményvezérelt feldolgozáshoz. Az alkalmazáskód üzembe helyezése helyett azonban létrehozhat logikai alkalmazásokat egy grafikus felhasználói felülettel, amely támogatja a blokkokat, például a feltételes feltételeket, a hurkokat és más szerkezeteket.

Több üzembe helyezési mód is elérhető. Javasoljuk, hogy a Standard móddal biztosítsa az egybérlős üzemelő példányt, és mérsékelje a zajos szomszéd forgatókönyveket. Ez a mód a tárolóalapú egybérlős Logic Apps-futtatókörnyezetet használja, amely Azure Functions alapul. Ebben a módban a logikai alkalmazás több állapotalapú és állapot nélküli munkafolyamatot is tartalmazhat. Ismernie kell a konfigurációs korlátokat.

Korlátozott migrálások az IaaS-en keresztül

Számos meglévő helyszíni üzembe helyezéssel rendelkező alkalmazás virtualizálási technológiákat és redundáns hardvereket használ a megbízhatóság kritikus fontosságú szintjeinek biztosításához. A modernizációt gyakran akadályozzák olyan üzleti korlátozások, amelyek megakadályozzák a kritikus fontosságú számítási feladatokhoz ajánlott natív felhőbeli alapkonfigurációs (North Star) architektúramintához való teljes igazítást. Ezért számos alkalmazás alkalmaz szakaszos megközelítést, a kezdeti felhőbeli üzembe helyezéseket virtualizálással, az Azure Virtual Machines pedig elsődleges alkalmazásüzemeltetési modellként. Bizonyos esetekben szükség lehet az IaaS virtuális gépek használatára:

• Az elérhető PaaS-szolgáltatások nem biztosítják a szükséges teljesítményt vagy vezérlési szintet.
• A számítási feladathoz operációsrendszer-hozzáférésre, adott illesztőprogramokra, illetve hálózati és rendszerkonfigurációkra van szükség.
• A számítási feladat nem támogatja a tárolókban való futtatásokat.
• Harmadik féltől származó számítási feladatokhoz nincs szállítói támogatás.

Ez a szakasz az Azure Virtual Machines és a társított szolgáltatások használatának legjobb módjait mutatja be az alkalmazásplatform megbízhatóságának maximalizálása érdekében. Kiemeli a kritikus fontosságú tervezési módszertan kulcsfontosságú szempontjait, amelyek transzponálják a natív felhőbeli és az IaaS-migrálási forgatókönyveket.

Kialakítási szempontok

• Az IaaS virtuális gépek üzemeltetési költségei jelentősen magasabbak, mint a PaaS-szolgáltatások használatának költségei a virtuális gépek és az operációs rendszerek felügyeleti követelményei miatt. A virtuális gépek kezelése szükségessé teszi a szoftvercsomagok és -frissítések gyakori bevezetését.

• Az Azure képességeket biztosít a virtuális gépek rendelkezésre állásának növeléséhez:

  • A rendelkezésre állási csoportok a virtuális gépek tartalék tartományok közötti elosztásával és a frissítési tartományok közötti elosztásával segíthetnek a hálózati, lemez- és áramkimaradások elleni védelemben.
  • A rendelkezésre állási zónák a virtuális gépek régión belüli fizikailag elkülönített adatközpontok közötti elosztásával még magasabb szintű megbízhatóságot érhetnek el.
  • Virtual Machine Scale Sets a csoportokban lévő virtuális gépek számának automatikus skálázására szolgáló funkciókat biztosít. Emellett a példány állapotának monitorozására és a nem megfelelő állapotú példányok automatikus javítására is képesek.

Tervezési javaslatok

Fontos

A PaaS-szolgáltatások és -tárolók használata lehetőség szerint a működési összetettség és a költségek csökkentése érdekében. Csak akkor használjon IaaS virtuális gépeket, ha szükséges.

• A virtuálisgép-termékváltozatok megfelelő méretezése a hatékony erőforrás-használat biztosításához.

• Három vagy több virtuális gép üzembe helyezése rendelkezésre állási zónákban az adatközpontszintű hibatűrés elérése érdekében.

  • Ha kereskedelmi célú, nem megfelelő szoftvereket helyez üzembe, forduljon a szoftver gyártójához, és tesztelje megfelelően, mielőtt üzembe helyezené a szoftvert éles környezetben.

• Olyan számítási feladatok esetén, amelyek nem helyezhetők üzembe a rendelkezésre állási zónákban, használjon három vagy több virtuális gépet tartalmazó rendelkezésre állási csoportokat .

  • A rendelkezésre állási csoportokat csak akkor vegye figyelembe, ha a rendelkezésre állási zónák nem felelnek meg a számítási feladatokra vonatkozó követelményeknek, például az alacsony késési követelményekkel rendelkező, forgalmas számítási feladatok esetében.

• A Virtual Machine Scale Sets használatának rangsorolása a méretezhetőség és a zónaredundancia érdekében. Ez a pont különösen fontos a változó terhelésű számítási feladatok esetében. Ha például az aktív felhasználók vagy kérések száma másodpercenként változó terhelést jelent.

• Ne érje el közvetlenül az egyes virtuális gépeket. Amikor csak lehetséges, használjon előttük terheléselosztókat.

• A regionális kimaradások elleni védelem érdekében helyezzen üzembe alkalmazás virtuális gépeket több Azure-régióban.

  • Az aktív üzembehelyezési régiók közötti forgalom optimális irányításáról a hálózat- és kapcsolattervezési területen tájékozódhat.

• Olyan számítási feladatok esetében, amelyek nem támogatják a többrégiós aktív/aktív üzemelő példányokat, fontolja meg az aktív/passzív üzemelő példányok megvalósítását a meleg/meleg készenléti virtuális gépek regionális feladatátvételhez való használatával.

• A karbantartandó egyéni rendszerképek helyett használjon Azure Marketplace szabványos rendszerképeket.

• Automatizált folyamatokat implementálhat a virtuális gépek módosításainak üzembe helyezéséhez és bevezetéséhez, így elkerülheti a manuális beavatkozást. További információ: Az IaaS szempontjai az Üzemeltetési eljárások tervezési területén.

• Alkalmazzon káoszkísérleteket, hogy alkalmazáshibákat injektáljon a virtuálisgép-összetevőkbe, és figyelje meg a hibák elhárítását. További információ: Folyamatos ellenőrzés és tesztelés.

• Monitorozza a virtuális gépeket, és győződjön meg arról, hogy a diagnosztikai naplók és metrikák egy egyesített adatfoglóba vannak betöltve.

• Szükség esetén implementálja a kritikus fontosságú alkalmazásforgatókönyvek biztonsági gyakorlatait, valamint az Azure-beli IaaS számítási feladatok biztonsági ajánlott eljárásait.

Következő lépés

Tekintse át az adatplatformmal kapcsolatos szempontokat.

Adatplatform