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égekben és összetettségben különböznek. Javasoljuk, hogy a következő szolgáltatások alapján válasszon szolgáltatásokat:

• A megbízhatóságra, a rendelkezésre állásra, a teljesítményre és a 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-üzemelteté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 védett fejlesztőszoftverek nem futnak PaaS-szolgáltatásokban vagy tárolóalapú alkalmazásokban. Ez a korlátozás hatással lenne a számítási platform kiválasztására.

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 beállításokkal 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?

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 egy adott Azure-régióra vannak korlátozva, 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 elosztásra 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.

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

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érelmeket egy megfelelő regionális üzembehelyezési bélyegzőre:

A kritikus fontosságú tervezési módszertan többrégiós üzembe helyezést igényel. 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áskövetelményeket, mivel az egyes megközelítések jelentős kompromisszumokkal járnak. Kritikus fontosságú számítási feladatok esetén erősen ajánljuk az aktív/aktív modellt.

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

A rendelkezésre állási zónák magas rendelkezésre állású regionális üzembe helyezéseket biztosíthatnak egy régió különböző adatközpontjaiban. Szinte az összes Azure-szolgáltatás egy zónakonfigurációban érhető el, ahol a szolgáltatás delegálva van egy adott zónába vagy egy zónaredundáns konfigurációba, ahol a platform automatikusan biztosítja, hogy a szolgáltatás több zónára kiterjedjen, é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 zonális 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 kiválasztott régiókra. Emellett 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 kimaradás több Azure-régiót is érint, a rendszer minden párban legalább egy régiót rangsorolja a helyreállításhoz.

• Adatkonzisztencia. Konzisztencia-kihívások 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 minden 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 Safe Deployment Practice (SDP) keretrendszer biztosítja, hogy az Azure-platform összes kód- és konfigurációmódosítása (tervezett karbantartás) szakaszos bevezetésen menjen keresztül. A rendszer a kiadás során elemzi az állapot romlását. A kanári- és próbafázisok sikeres befejezése után a platformfrissítések regionális párok között szerializálva lesznek, í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 kimaradás kapacitásproblémát eredményezhet, ahol a kínálat átmenetileg nem felel meg a keresletnek.

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ény- és rendelkezésreállási céloknak, miközben teljesítik az adattárolási és adatmegőrzési követelményeket.

  Egyes adatmegfelelési követelmények például korlátozhatják a rendelkezésre álló régiók számát, és potenciálisan veszélyeztethetik a tervezést. Ilyen esetekben határozottan javasoljuk, hogy a hibák előrejelzése, észlelése és megválaszolása érdekében adjon hozzá további befektetést az operatív burkolókba. Tegyük fel, hogy 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ék tartományok elkülönítésével, hogy mindkét régió aktív konfigurációban legyen üzembe helyezve, é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 veszélyezteté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 méretezési egységeket) a kiválasztott régióban a kockázat csökkentése érdekében, és használja a rendelkezésre állási zónákat az adatközpontszintű hibatűrés biztosításához. A földrajzi eloszlás ilyen jelentős kompromisszuma azonban jelentősen korlátozza az elérhető összetett SLO-t és az általános megbízhatóságot.

  Fontos

  A 99,99%-nál nagyobb vagy egyenlő SLO-t célzó forgatókönyvek esetében legalább három üzembehelyezési régiót ajánlunk. Az összes felhasználói folyamat összetett SLO-jának kiszámítása. Győződjön meg arról, hogy ezek a célok igazodnak az üzleti célokhoz.

• A nagy mennyiségű forgalmat bonyolító nagy léptékű alkalmazásforgatókönyvek esetében úgy tervezheti meg a 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ón belül. A további regionális üzembehelyezési bélyegek magasabb összetett SLO-t érhetnek el. További információ: többrégiós célok megvalósítása.

• A helyreállítási pont célkitűzéseinek (RPO) és a helyreállítási idő célkitűzéseinek (RTO) meghatározása és érvényesíté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 a nem tervezett karbantartások regionális rangsorolását.

• Az Azure-erőforrások földrajzilag együtt vannak helyezve a felhasználókkal a hálózati késés minimalizálása és a teljes körű teljesítmény maximalizálása érdekében.

  • Olyan megoldásokat is használhat, mint a Tartalomkézbesítési hálózat (CDN) vagy a peremhálózati gyorsítótárazás az elosztott felhasználói bázisok optimális hálózati késésének eléréséhez. 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.

Tárolóra bontás

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 tárolók absztrakciós réteget biztosítanak az alkalmazáskódhoz és annak függőségeihez, és elkülönítik 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 helyezhetik üzembe az 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, mert több tárolót is üzemeltethet ugyanazon a virtualizált infrastruktúrán. Mivel az összes szoftver megtalálható a tárolóban, az alkalmazást a futtatókörnyezettől és a tárverzióktól függetlenül különböző operációs rendszereken is áthelyezheti. A tárolók kezelése is egyszerűbb, mint a hagyományos virtualizált üzemeltetés esetén.

A kritikus fontosságú alkalmazásoknak gyorsan skálázniuk kell a teljesítmény szűk keresztmetszeteinek elkerülése érdekében. Mivel a tárolólemezképek előre összeállítottak, az indítást csak az alkalmazás indításakor korlátozhatja, 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 lévő 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ó között van megosztva, és egyetlen támadási pontot hoz létre. A gazda virtuális gép (VM) hozzáférése azonban korlátozott, mert a tárolók el vannak különítve az alapul szolgáló 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 őrizze meg az adatokat külső tároló csatlakoztatásával vagy egy külső adatbázis használatával.

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.

• Lehetőség szerint rangsorolja a Linux-alapú tároló-futtatókörnyezeteket. A rendszerképek egyszerűbbek, és a Linux-csomópontok és -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épébő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 az Azure Container Registryben. A georeplikációs használatával minden régióban replikálhatja a tárolólemezképeket. Engedélyezze a Tárolóregisztrációs adatbázisokhoz készült Microsoft Defendert a tárolólemezképek biztonsági réseinek vizsgálatához. Győződjön meg arról, hogy a beállításjegyzékhez való hozzáférést a Microsoft Entra ID 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óval a következő cikkek szolgálnak:

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

Fontos

Az Azure Kubernetes Service -nek (AKS) és az Azure Container Apps-nek a követelményektől függően az elsők között kell választania a tárolókezeléshez. Bár Azure-alkalmazás szolgáltatás 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 az Azure Kubernetes Service-hez

A felügyelt Kubernetes-szolgáltatás, az AKS lehetővé teszi a gyors fürtkiépítést összetett fürtfelügyeleti tevékenységek nélkül, és speciális hálózatkezelési és identitáskezelési képességeket tartalmazó funkciókészletet kínál. A javaslatok teljes halmazáért tekintse meg az Azure Well-Architected Framework áttekintését – AKS.

Fontos

Vannak olyan alapvető konfigurációs döntések, amelyeket az AKS-fürt újratelepítése nélkül nem lehet módosítani. 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, a Microsoft Entra integrációja, 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:

• Az AKS-fürtök üzembe helyezése különböző Azure-régiókban skálázási egységként a megbízhatóság és a rendelkezésre állás maximalizálása érdekében. A 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 a közelségi elhelyezési csoportokkal minimalizálhatja az elcsatolások közötti késést.

• Az éles fürtökhöz készült AKS Uptime 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 méretezé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ását , hogy automatikusan módosítsa az ügynökcsomópontok számát az erőforrás-korlátozásokra válaszul.

• A podok vízszintes automatikus skálázásával a processzorhasználat vagy más metrikák alapján módosíthatja az üzemelő példányok podjainak számát.

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

• Poderőforrás-kérelmek é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ási feladatokhoz. A számítási feladatok összetevőinek dedikált csomópontkészleteinek a speciális infrastruktúra-erőforrásokra, például a nagy memóriájú GPU-ra vonatkozó virtuális gépekre vonatkozó követelményeken kell alapulnia. Általánosságban elmondható, hogy a szükségtelen felügyeleti többletterhelés csökkentése érdekében kerülje a csomópontkészletek nagy számának üzembe helyezését.

• A dedikált csomópontok biztosításához és az erőforrás-igényes alkalmazások korlátozásához használjon elenyhítéseket és tűréseket .

• Értékelje ki az alkalmazás affinitási és affinitási követelményeit, és konfigurálja a tárolók csomópontokon való megfelelő elhelyezését.

Biztonság

Az alapértelmezett vanília Kubernetes jelentős konfigurációt igényel a kritikus fontosságú helyzetek megfelelő biztonsági helyzetének biztosításához. Az AKS különböző biztonsági kockázatokat kezel a dobozon kívül. A funkciók közé tartoznak a privát fürtök, a Log Analyticsbe való naplózás és bejelentkezés, a megerősí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álata a fürt identitásának és hozzáférés-kezelésének kezeléséhez a működési többletterhelés csökkentéséhez és a konzisztens hozzáférés-kezelés alkalmazásához.

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

• A Microsoft Entra-integrációt központosított fiókkezeléshez és jelszavakhoz, alkalmazáshozzáférés-kezeléshez és fokozott identitásvédelemhez használhatja. Használja a Kubernetes RBAC-t a 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 GitHub nyilvános AKS-ütemtervére és kibocsátási megjegyzéseire , 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.

• Az ajánlott eljárásokhoz való igazodás érdekében alkalmazza az AKS ellenőrzőlistájában található útmutatást.

• 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 időszakokat 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ózat

Értékelje ki a használati esetnek leginkább megfelelő hálózati beépülő modulokat. Határozza meg, hogy szükség van-e a podok közötti forgalom részletes szabályozására. Azure-támogatás kubenet, Azure CNI, és hozzon saját CNI-t 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 forgalmának 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ályzatokkal egységesen alkalmazhat központosított védelmet az AKS-fürtökre. Szabályzat-hozzárendelések alkalmazása előfizetési hatókörben vagy annál magasabb szinten, hogy konzisztenciát keltsen a fejlesztői csapatok között.

• Az Azure Policy használatával szabályozhatja, hogy mely függvényeket kapják meg a podok, és hogy a futtatás ellentmond-e a szabályzatnak. Ezt a hozzáférést az AKS-hez készült Azure Policy-bővítmény á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 az Azure Policy használatával.

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

Feljegyzés

Amikor üzembe helyez egy Azure-beli célzónát, az Azure-szabályzatokat, amelyek biztosítják, hogy a célzóna implementációja biztosítsa a konzisztens megbízhatóságot és biztonságot.

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

Tervezési szempontok és javaslatok Azure-alkalmazás szolgáltatáshoz

Webes és API-alapú számítási feladatok esetén az 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 tekintse meg az App Service megbízhatósági szempontjait és az App Service működési kiválóságát.

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 kimerülése gyakori hibaforgatókönyv. Ezt a problémát prediktív módon kell észlelnie terhelésteszteléssel, miközben az Azure Diagnostics használatával monitorozza a portokat. 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 kimerülése egy másik hibaforgatókönyv. Ez 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. A javaslatokért tekintse meg a TCP- és SNAT-portokat.

Méretezhetőség

Tervezze meg a jövőbeli méretezhető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ása érdekében, hogy megfelelő erőforrások álljanak rendelkezésre a szolgáltatáskérések számára. Értékelje ki az apponkénti skálázást az App Service nagy sűrűségű üzemeltetéséhez.

• Vegye figyelembe, hogy az App Service-nek az App Service-csomagonkénti példányok alapértelmezett, helyreállítható korlátja van.

• Automatikus méretezési szabályok alkalmazása. Egy App Service-csomag felskálázódik, ha a profilon belüli bármely szabály teljesül, de csak akkor skálázódik, 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 műveletet hajtson végre a vertikális felskálázás és a skálázás terén is. Több skálázási szabály viselkedésének megismerése egyetlen profilban.

• Vegye figyelembe, hogy az apponkénti skálázást az App Service-csomag szintjén engedélyezheti, hogy az alkalmazás az azt futtató App Service-csomagtól függetlenül skálázhasson. Az alkalmazások az elérhető csomópontokhoz lesznek lefoglalva egy optimális megoldással, amely egyenletes eloszlást tesz lehetővé. Bár az egyenletes terjesztés nem garantált, a platform biztosítja, hogy ugyanazon alkalmazás két példánya ne ugyanazon a példányon üzemel.

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 külső eszközbe az Azure Event Hubson keresztül.

• Az Application Insights alkalmazásteljesítmény-monitorozása részletes elemzéseket nyújt az alkalmazások teljesítményével kapcsolatban.

• A kritikus fontosságú alkalmazásoknak képesnek kell lenniük öngyógyulni, ha vannak hibák. Engedélyezze az automatikus javítást a nem megfelelő feldolgozók automatikus újrahasznosításához.

• Megfelelő állapot-ellenőrzéseket kell használnia az összes kritikus alsóbb rétegbeli függőség felméréséhez, ami segít az általános állapot biztosításában. Határozottan javasoljuk, hogy engedélyezze az állapot-ellenőrzést a nem reagáló munkavállalók azonosításához.

Telepítés

Az App Service-csomagonkénti példányok 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. Az App Service-csomagok üzembe helyezése rendelkezésre állási zónák konfigurációjában annak biztosítása érdekében, hogy a feldolgozó csomópontok el legyenek osztva a régión belüli zónák között. Érdemes lehet megnyitni egy támogatási jegyet, 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.

Container Registry

A tárolóregisztrációs adatbázisok olyan tároló futtatókörnyezetekben üzembe helyezett rendszerképeket üzemeltetnek, mint az AKS. A tárolóregisztrációs adatbázisokat gondosan konfigurálnia kell a kritikus fontosságú számítási feladatokhoz. A kimaradások nem okozhatnak 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 az Azure Container Registryre összpontosítanak, és megismerik a központosított és összevont üzemi modellekhez kapcsolódó kompromisszumokat.

Kialakítási szempontok

• Formátum. Érdemes lehet olyan tárolóregisztrációs adatbázist használni, 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 fel. Vagy üzembe helyezheti dedikált összetevőként egy adott alkalmazás-számítási feladathoz.

• Nyilvános nyilvántartások. A tárolólemezképek a Docker Hubban 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ázisban vannak tárolva. Ez nem feltétlenül probléma, 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. Egyes alkalmazási helyzetekben a nyilvános tárolólemezké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

• Olyan tárolóregisztrációs adatbázispéldányokat használjon, amelyek az alkalmazás számítási feladatainak vannak szentelve. Ne hozzon létre függőséget egy központosított szolgáltatáson, kivéve, ha a szervezeti rendelkezésre állási és megbízhatósági követelmények teljes mértékben összhangban vannak az alkalmazással.

  Az ajánlott alapvető architektúramintá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 Hubtól függő használati esetek szabályozásának korlátait.

• Az Azure Container Registry rangsorolása tárolólemezképek üzemeltetéséhez.

Tervezési szempontok és javaslatok az Azure Container Registryhez

Ez a natív szolgáltatás számos funkciót kínál, 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 földrajzi replikációt az összes üzembehelyezési régióban a regionális függőségek eltávolításához és a késés optimalizálásához. A Tárolóregisztrációs adatbázis georeplikációs szolgáltatással támogatja a magas rendelkezésre állást több konfigurált régióra, így 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 képkérelmeket szolgál ki. Amikor a régió újra online állapotba kerül, a Tárolóregisztrációs adatbázis helyreállítja és replikálja annak módosításait. Ez a funkció emellett beállításjegyzék-elhelyezést is biztosít az egyes konfigurált régiókon belül, 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 Prémium szintű tárolóregisztrációs szint támogatja a zónaredundanciát , hogy védelmet nyújtson a zónahiba ellen. A Prémium szint a privát végpontokat is támogatja, hogy megakadályozza a beállításjegyzékhez való jogosulatlan hozzáférést, ami megbízhatósági problémákhoz vezethet.

A rendszerképek ugyanazon Azure-régiókon belül közel állnak a felhasználó számítási erőforrásokhoz.

Képzárolás

A rendszerképek például manuális hiba miatt törölhetők. A Tárolóregisztrációs adatbázis támogatja a rendszerképek vagy adattárak zárolását a módosítások vagy törlések megakadályozása érdekében. Ha egy korábban üzembe helyezett rendszerképverziót módosítanak, az azonos verziójú központi telepítések 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 helyzetekben ez kiszámíthatatlan viselkedéshez vezethet, amely befolyásolhatja az alkalmazások üzemidejét.

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

A Microsoft Entra integrált hitelesítésével leküldhet és lekérhet képeket 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, skáláz é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-függvények. Az Azure Functions használatakor az alkalmazáslogika különböző kód- vagy függvényblokkokként lesz implementálva, amelyek eseményekre, például HTTP-kérésre vagy üzenetsorra reagálva futnak. Az egyes függvények szükség szerint skálázhatók az igények kielégítése érdekében.

• Azure Logic Apps. A Logic Apps leginkább olyan automatizált munkafolyamatok létrehozására és futtatására alkalmas, amelyek különböző alkalmazásokat, adatforrásokat, szolgáltatásokat és rendszereket integrálnak. Az Azure Functionshez 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 kódblokkokat, például a feltételes kódot és a hurkokat.

• Azure API Management. Az API Management használatával közzéteheti, átalakíthatja, karbantarthatja és figyelheti a fokozott biztonságú API-kat a Használat réteg használatával.

• Power Apps és Power Automate. Ezek az eszközök alacsony kód- vagy kód nélküli fejlesztési élményt nyújtanak egyszerű munkafolyamat-logikával és integrációval, 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 esetekhez. Ez az egyszerűség azonban a méretezhetőség, a megbízhatóság és a teljesítmény rugalmasságának a költsége, és ez a legtöbb kritikus fontosságú alkalmazásforgatókönyv esetében nem járható út.

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

Tervezési szempontok és javaslatok az Azure Functionshez

A kritikus fontosságú számítási feladatok kritikus és nem kritikus rendszerfolyamatokkal rendelkeznek. Az Azure Functions életképes választás olyan folyamatokhoz, amelyek nem rendelkeznek ugyanolyan szigorú üzleti követelményekkel, mint a kritikus rendszerfolyamatok. Jól használható olyan eseményvezérelt folyamatokhoz, amelyek rövid élettartamú folyamatokkal rendelkeznek, mivel a függvények a lehető leggyorsabban futtatható különböző műveleteket hajtanak végre.

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ányok 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 méretezé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.

Vannak biztonsági szempontok. Ha 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 vektorok ellen.

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

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

Tervezési szempontok és javaslatok az Azure Logic Appshez

Az Azure Functionshez 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ód biztosítsa az egybérlős üzembe helyezést, és mérsékelje a zajos szomszéd forgatókönyveket. Ez a mód az Azure Functionsen alapuló tárolóalapú egybérlős Logic Apps-futtatókörnyezetet használja. Ebben a módban a logikai alkalmazás több állapotalapú és állapot nélküli munkafolyamatot is tartalmazhat. Tisztában kell lennie a konfigurációs korlátokkal.

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

Számos olyan alkalmazás, amely már rendelkezik helyszíni telepítéssel, virtualizálási technológiákat és redundáns hardvereket használ a kritikus fontosságú megbízhatósági szintek biztosításához. A modernizációt gyakran akadályozzák azok az üzleti korlátozások, amelyek megakadályozzák a kritikus fontosságú számítási feladatokhoz javasolt natív felhőbeli alapkonfigurációs (North Star-) architektúramintával való teljes igazítást. Ezért sok alkalmazás alkalmaz fázisalapú megközelítést, a kezdeti felhőtelepítések virtualizálást és Azure Virtual Machines-et használnak elsődleges alkalmazásüzemeltetési modellként. Bizonyos esetekben szükség lehet az infrastruktúra szolgáltatásként való használatára (IaaS- virtuális gépek):

• 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 vagy 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.
• Külső számítási feladatokhoz nincs gyártói támogatás.

Ez a szakasz a virtuális gépek és a kapcsolódó 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 felhőbeli natív és az IaaS-migrálási forgatókönyveket transzponáló, kritikus fontosságú tervezési módszertan főbb szempontjait.

Kialakítási szempontok

• Az IaaS virtuális gépek használatának ü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 telepítését.

• Az Azure a virtuális gépek rendelkezésre állásának növeléséhez nyújt képességeket:

  • A rendelkezésre állási zónák a virtuális gépek régión belüli fizikailag elkülönített adatközpontokban való elosztásával még magasabb szintű megbízhatóságot érhetnek el.
  • Az Azure-beli virtuálisgép-méretezési csoportok funkcióval automatikusan skálázhatók a csoportokban lévő virtuális gépek száma. Emellett képességeket is biztosítanak a példány állapotának figyeléséhez és a nem megfelelő példányok automatikus javításához.
  • A rugalmas vezénylésű méretezési csoportok a virtuális gépek tartalék tartományok közötti automatikus elosztásával védelmet nyújthatnak a hálózati, lemez- és áramkimaradások ellen.

Tervezési javaslatok

Fontos

Ha lehetséges, használja a PaaS-szolgáltatásokat és -tárolókat a működési összetettség és a költségek csökkentése érdekében. Csak akkor használja az IaaS virtuális gépeket, ha szükséges.

• A virtuálisgép-termékváltozatok megfelelő méretei a hatékony erőforrás-kihasználtság érdekében.

• 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ú, polcon kívüli szoftvert helyez üzembe, forduljon a szoftver gyártójához, és tesztelje megfelelően, mielőtt üzembe helyezené a szoftvert éles környezetben.

• A rendelkezésre állási zónákban nem üzembe helyezhető számítási feladatokhoz használjon olyan rugalmas virtuálisgép-méretezési csoportokat , amelyek három vagy több virtuális gépet tartalmaznak. A hibatartományok megfelelő számának konfigurálásáról további információt a Hibatartományok kezelése méretezési csoportokban című témakörben talál.

• Rangsorolja a virtuálisgép-méretezési csoportok használatát a méretezhetőség és a zónaredundancia szempontjából. Ez a pont különösen fontos a különböző terhelésű számítási feladatok esetében. Ha például az aktív felhasználók vagy kérések másodpercenkénti száma változó terhelés.

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

• 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 implementálását gyakori/meleg készenléti virtuális gépek használatával a regionális feladatátvételhez.

• Használjon standard rendszerképeket az Azure Marketplace-ről a karbantartandó egyéni rendszerképek helyett.

• Automatizált folyamatok implementálása a virtuális gépek módosításainak üzembe helyezéséhez és bevezetéséhez, elkerülve a manuális beavatkozást. További információ: IaaS-szempontok az üzemeltetési eljárások tervezési területén.

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

• Figyelje a virtuális gépeket, és győződjön meg arról, hogy a diagnosztikai naplók és metrikák egységes adatgyűjtőbe kerülnek.

• Szükség esetén implementálja a kritikus fontosságú alkalmazásforgatókönyvek biztonsági eljárásait, 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 adatplatform szempontjait.

Adatplatform