Magas rendelkezésre állású többrégiós webalkalmazás

Ez a példaarchitektúra az egyszerű webalkalmazás-példaarchitektúrán alapul, és kiterjeszti a megjelenítésre:

• Bevált eljárások a Azure-alkalmazás Service-webalkalmazások méretezhetőségének és teljesítményének javításához
• Azure-alkalmazás szolgáltatásalkalmazás futtatása több régióban a magas rendelkezésre állás érdekében

Architektúra

Töltse le az architektúra Visio-fájlját.

Munkafolyamat

Ez a munkafolyamat az architektúra többrégiós aspektusaival foglalkozik, és az alapszintű webalkalmazásra épül.

• Elsődleges és másodlagos régiók. Ez az architektúra két régiót használ a magas rendelkezésre állás eléréséhez. A rendszer az összes régióban telepíti az alkalmazást. A normál működés során a hálózati forgalom az elsődleges régió felé irányul. Ha az elsődleges régió nem érhető el, a rendszer a másodlagos régió felé irányítja a forgalmat.
• Bejárati ajtó. Az Azure Front Door a többrégiós implementációkhoz ajánlott terheléselosztó. A webalkalmazási tűzfallal (WAF) integrálva védelmet nyújt a gyakori biztonsági rések ellen, és a Front Door natív tartalom-gyorsítótárazási funkcióját használja. Ebben az architektúrában a Front Door prioritási útválasztásra van konfigurálva, amely az összes forgalmat az elsődleges régióba küldi, kivéve, ha elérhetetlenné válik. Ha az elsődleges régió elérhetetlenné válik, a Front Door az összes forgalmat a másodlagos régióba irányítja.
• Tárfiókok, SQL Database és/vagy Azure Cosmos DB georeplikálása .

Összetevők

Az architektúra implementálásához használt főbb technológiák:

• A Microsoft Entra ID egy felhőalapú identitás- és hozzáférés-kezelési szolgáltatás, amellyel az alkalmazottak hozzáférhetnek a szervezet számára kifejlesztett felhőalkalmazásokhoz.
• Az Azure DNS egy üzemeltetési szolgáltatás, amely a Microsoft Azure infrastruktúráját használja a DNS-tartományok névfeloldásához. Ha tartományait az Azure-ban üzemelteti, DNS-rekordjait a többi Azure-szolgáltatáshoz is használt hitelesítő adatokkal, API-kkal, eszközökkel és számlázási információkkal kezelheti. Egyéni tartománynév (például contoso.com) használatához hozzon létre olyan DNS-rekordokat, amelyek leképzik az egyéni tartománynevet az IP-címre. További információkat az egyéni tartománynevek az Azure App Service-ben való konfigurálásával kapcsolatos cikkben olvashat.
• Az Azure Content Delivery Network egy globális megoldás a nagy sávszélességű tartalom továbbítására a világ stratégiailag elhelyezett fizikai csomópontjaiban való gyorsítótárazással.
• Az Azure Front Door egy 7. rétegbeli terheléselosztó. Ebben az architektúrában a HTTP-kéréseket a webes előtérre irányítja. A Front Door egy webalkalmazási tűzfalat (WAF) is biztosít, amely megvédi az alkalmazást a gyakori biztonsági résektől és biztonsági résektől. A Front Door a tartalomkézbesítési hálózat (CDN) megoldásához is használható ebben a kialakításban.
• A Azure-alkalmazás Service egy teljes mértékben felügyelt platform a felhőalkalmazások létrehozásához és üzembe helyezéséhez. Lehetővé teszi a webalkalmazások futtatásához, üzembe helyezéséhez és üzembehelyezési pontok konfigurálásához szükséges számítási erőforrások készletét.
• Az Azure Function Apps háttérfeladatok futtatására használható. A függvényeket egy eseményindító hívja meg, például egy időzítőesemény vagy egy üzenet, amely az üzenetsorra kerül. Hosszú ideig futó állapotalapú feladatokhoz használja a Durable Functionst.
• Az Azure Storage egy felhőalapú tárolási megoldás a modern adattárolási forgatókönyvekhez, amely magas rendelkezésre állású, nagymértékben méretezhető, tartós és biztonságos tárolást biztosít a felhőben található számos adatobjektum számára.
• Az Azure Redis Cache egy nagy teljesítményű gyorsítótárazási szolgáltatás, amely memóriabeli adattárat biztosít az adatok gyorsabb lekéréséhez a nyílt forráskódú Redis Cache-gyorsítótár alapján.
• Az Azure SQL Database egy relációs adatbázis a felhőben. Az SQL Database kódbázisa közös a Microsoft SQL Server adatbázismotorjáéval.
• Az Azure Cosmos DB egy globálisan elosztott, teljes mértékben felügyelt, alacsony késésű, többmodelles, több lekérdezési API-adatbázis, amely nagy léptékben kezeli az adatokat.
• Az Azure Cognitive Search olyan keresési funkciók hozzáadására használható, mint a keresési javaslatok, a homályos keresés és a nyelvspecifikus keresés. Az Azure Search általában egy másik adattárral együtt használatos, különösen akkor, ha az elsődleges adattár megköveteli a szigorú konzisztenciát. Ennek a megközelítésnek megfelelően a mérvadó adatokat a másik adattárban kell tárolni, a keresési indexet pedig az Azure Search-ben. Az Azure Search továbbá egyetlen, különböző adattárakból összeállított keresési index létrehozására is használható.

Forgatókönyv részletei

A régiók közötti magas rendelkezésre állás számos általános megközelítéssel érhető el:

• Aktív/passzív, gyakori készenléti állapottal: a forgalom az egyik régióba, a másik pedig a készenléti állapotban várakozik. A készenléti állapot azt jelenti, hogy a másodlagos régióban lévő App Service ki van foglalva, és mindig fut.

• Aktív/passzív hideg készenléti állapottal: a forgalom az egyik régióba kerül, míg a másik hideg készenléti állapotban várakozik. A hideg készenléti állapot azt jelenti, hogy a másodlagos régióban lévő App Service nincs lefoglalva, amíg a feladatátvételhez nem szükséges. Ezen megközelítés futtatása kevesebb költséggel jár, de a meghibásodáskor általában hosszabb időt vesz igénybe az üzembe állás.

• Aktív/Aktív: mindkét régió aktív, és a kérések terhelése el van osztva közöttük. Ha egy régió elérhetetlenné válik, az el lesz veszve a forgatásból.

Ez a referencia az aktív/passzív készenléti állapotra összpontosít.

Lehetséges használati esetek

Ezek a használati esetek többrégiós üzembe helyezést is igénybe vehetnek:

• Üzletmenet-folytonossági és vészhelyreállítási terv tervezése LoB-alkalmazásokhoz.

• Kritikus fontosságú, Windowson vagy Linuxon futó alkalmazások üzembe helyezése.

• Az alkalmazások elérhetőségének megőrzésével javíthatja a felhasználói élményt.

Ajánlások

Az Ön követelményei eltérhetnek az itt leírt architektúrától. A jelen szakaszban leírt javaslatokat tekintse kiindulópontnak.

Régiónkénti párosítás

Minden egyes Azure-régió párban áll egy másikkal egy azonos földrajzi területen belül. Régiókat általában azonos regionális párokból érdemes választani (például: USA 2. keleti régiója és USA középső régiója). Ennek előnyei például a következők:

• Ha széles körű kimaradás áll fenn, a rendszer minden párból legalább egy régió helyreállítását rangsorolja.
• A tervezett Azure-rendszerfrissítések egyszerre csak a régiópár egyik tagján jelennek meg, ami csökkenti az állásidőt.
• A legtöbb esetben a regionális párok azonos földrajzi helyen belül találhatók, hogy megfeleljenek az adatok tárolási helyére vonatkozó előírásoknak.

Azonban győződjön meg arról, hogy mindkét régió támogatja az összes Azure-szolgáltatást, amely szükséges az alkalmazásához. Lásd: Szolgáltatások régiónként. További információ a regionális párokról: Üzletmenet-folytonosság és vészhelyreállítás (BCDR): Az Azure párosított régiói.

Erőforráscsoportok

Érdemes lehet az elsődleges régiót, a másodlagos régiót és a Front Doort külön erőforráscsoportokba helyezni. Ezzel a lefoglalással egyetlen gyűjteményként kezelheti az egyes régiókban üzembe helyezett erőforrásokat.

App Service-alkalmazások

A webalkalmazást és a webes API-t külön App Service-alkalmazásokként javasolt létrehozni. Ez a kialakítás lehetővé teszi, hogy külön App Service-csomagokban futhassanak, így egymástól függetlenül lehet méretezni őket. Ha kezdetben nincs szükség ilyen szintű méretezhetőségre, az alkalmazások ugyanabba a csomagba is telepíthetők. Szükség esetén később is szét lehet választani őket.

Front Door konfiguráció

Útválasztás. A Front Door számos útválasztási mechanizmust támogat. A cikkben ismertetett forgatókönyv esetében használja a prioritási útválasztást. Ezzel a beállítással a Front Door minden kérést elküld az elsődleges régiónak, kivéve, ha az adott régió végpontja elérhetetlenné válik. Ebben az esetben automatikusan átadja a feladatokat a másodlagos régiónak. Állítsa be a forráskészletet különböző prioritási értékekkel, 1 az aktív régióhoz, 2 vagy annál magasabb értéket a készenléti vagy passzív régióhoz.

Állapotminta. A Front Door HTTPS-mintavételt használ az egyes háttérrendszerek rendelkezésre állásának figyeléséhez. A mintavétel pass/fail tesztet ad a Front Doornak a másodlagos régióba történő feladatátvételhez. Ehhez egy kérelmet küld egy meghatározott URL-címre. Ha egy bizonyos időkorláton belül nem 200-as értékű választ kap, a mintavétel meghiúsul. Konfigurálhatja az állapotadat-mintavétel gyakoriságát, a kiértékeléshez szükséges minták számát és a sikeres minták számát ahhoz, hogy a forrás kifogástalanként legyen megjelölve. Ha a Front Door csökkentettnek jelöli a forrást, az a másik forrásra omlik át. További részletekért lásd : Állapottesztek.

Ajánlott eljárásként hozzon létre egy állapotadat-mintavételi útvonalat az alkalmazás eredetében, amely az alkalmazás általános állapotát jelenti. Ennek az állapotadat-mintavételnek ellenőriznie kell a kritikus függőségeket, például az App Service-alkalmazásokat, a tárolási üzenetsort és az SQL Database-t. Ellenkező esetben előfordulhat, hogy a mintavétel kifogástalan forrást jelez, ha az alkalmazás kritikus részei ténylegesen meghibásodnak. Másrészről viszont ne használja az állapotmintát alacsonyabb prioritású szolgáltatások ellenőrzéséhez. Ha például egy e-mail-szolgáltatás áll le, az alkalmazás képes egy második szolgáltatóra váltani, vagy egyszerűen később elküldeni az e-maileket. A tervezési minta további megvitatásához tekintse meg az állapotvégpont monitorozási mintáját.

A források biztonságossá tétele az internetről a nyilvánosan elérhető alkalmazások megvalósításának kritikus része. Tekintse meg a hálózat biztonságos bejövő forgalmának megvalósítását , és ismerje meg a Microsoft ajánlott tervezési és megvalósítási mintáit az alkalmazásnak a Front Doornal való bejövő kommunikációjának biztonságossá tételéhez.

CDN. Használja a Front Door natív CDN-funkcióját a statikus tartalom gyorsítótárazásához. A CDN fő előnye, hogy csökkenti a felhasználói oldalon érzékelhető késést, mivel a tartalom gyorsítótárazása olyan peremhálózati kiszolgálón történik, amely földrajzilag a felhasználó közelében található. A CDN emellett az alkalmazás terhelését is csökkenti, mivel a forgalmat nem az alkalmazás kezeli. A Front Door emellett dinamikus webhelygyorsítást is kínál, amely lehetővé teszi, hogy jobb általános felhasználói élményt nyújtson a webalkalmazás számára, mint amennyi csak statikus tartalom gyorsítótárazásával érhető el.

SQL Database

Aktív georeplikációs és automatikus feladatátvételi csoportokkal rugalmassá teheti az adatbázisokat. Az aktív georeplikálás lehetővé teszi, hogy az adatbázisokat az elsődleges régióból egy vagy több (legfeljebb négy) másik régióba replikálja. Az automatikus feladatátvételi csoportok az aktív georeplikációra épülnek azáltal, hogy lehetővé teszik a másodlagos adatbázisba való feladatátvételt az alkalmazások kódmódosítása nélkül. A feladatátvételek manuálisan vagy automatikusan is elvégezhetők a létrehozott szabályzatdefinícióknak megfelelően. Az automatikus feladatátvételi csoportok használatához konfigurálnia kell a kapcsolati sztringeket a feladatátvételi csoporthoz automatikusan létrehozott feladatátvételi kapcsolati sztring az egyes adatbázisok kapcsolati sztring helyett.

Azure Cosmos DB

Az Azure Cosmos DB támogatja a régiók közötti georeplikálást aktív-aktív mintában, több írási régióval. Másik lehetőségként kijelölhet egy régiót írható régióként, a többit pedig írásvédett replikákként. Ha regionális leállás történik, a feladatátvételt úgy végezheti el, hogy kiválaszt egy másik régiót az írási régiónak. Az ügyfél-SDK automatikusan az aktuális írható régióba küldi az írási kérelmeket, így feladatátvétel után nem kell frissítenie az ügyfél konfigurációját. További információ: Globális adatterjesztés az Azure Cosmos DB-vel.

Tárolás

Az Azure Storage szolgáltatáshoz írásvédett georedundáns tárolást (RA-GRS) használjon. Az RA-GRS típusú tárolással a rendszer az adatokat egy másodlagos régióba replikálja. A másodlagos régióhoz csak olvasható hozzáférése van egy különálló végponton keresztül. A felhasználó által kezdeményezett feladatátvétel a másodlagos régióba támogatott a georeplikált tárfiókok esetében. A tárfiók feladatátvételének kezdeményezése automatikusan frissíti a DNS-rekordokat, hogy a másodlagos tárfiók legyen az új elsődleges tárfiók. Feladatátvételt csak akkor szabad végrehajtani, ha szükségesnek tartja. Ezt a követelményt a szervezet vészhelyreállítási terve határozza meg, és figyelembe kell vennie a következményeket az alábbi Szempontok szakaszban leírtak szerint.

Regionális kimaradás vagy katasztrófa esetén az Azure Storage csapata dönthet úgy, hogy geo-feladatátvételt hajt végre a másodlagos régióban. Az ilyen típusú feladatátvételekhez nincs szükség ügyfélműveletre. Ezekben az esetekben az Azure Storage csapata is felügyeli a feladat-visszavételt az elsődleges régióba.

Bizonyos esetekben a blokkblobok objektumreplikálása elegendő replikációs megoldás lesz a számítási feladathoz. Ez a replikációs funkció lehetővé teszi az egyes blokkblobok másolását az elsődleges tárfiókból a másodlagos régióban lévő tárfiókba. Ennek a megközelítésnek az előnyei a replikált adatok részletes szabályozása. A replikált blokkblobok típusainak részletesebb szabályozásához replikációs szabályzatot is definiálhat. A szabályzatdefiníciók például a következők:

• Csak a szabályzat létrehozása után hozzáadott blokkblobok lesznek replikálva
• Csak a megadott dátum és idő után hozzáadott blokkblobok replikálása
• Csak az adott előtagnak megfelelő blokkblobok replikálódnak.

A queue storage az Azure Service Bus alternatív üzenetkezelési lehetőségeként jelenik meg ebben a forgatókönyvben. Ha azonban üzenetkezelési megoldásához üzenetsor-tárolót használ, a georeplikációhoz képest fentebb megadott útmutatás itt is érvényes, mivel a várólista-tároló a tárfiókokban található. Fontos azonban tisztában lenni azzal, hogy az üzenetek nem replikálódnak a másodlagos régióba, és az állapotuk elválaszthatatlan a régiótól.

Azure Service Bus

Annak érdekében, hogy kihasználhassa az Azure Service Bushoz kínált legmagasabb rugalmasságot, használja a prémium szintű névtereket. A prémium szint a rendelkezésre állási zónákat használja, így a névterek rugalmasan kezelhetők az adatközpontok kimaradásával szemben. Ha egy kiterjedt katasztrófa több adatközpontot is érint, a prémium szintű Geo-vészhelyreállítás funkció segíthet a helyreállításban. A Geo-Vészhelyreállítás funkció biztosítja, hogy egy névtér (üzenetsorok, témakörök, előfizetések és szűrők) teljes konfigurációja folyamatosan replikálva legyen az elsődleges névtérből egy másodlagos névtérbe párosítva. Lehetővé teszi, hogy bármikor egyszeri feladatátvételt kezdeményezhet az elsődlegesről a másodlagosra. A feladatátvételi lépés a névtér kiválasztott aliasnevét a másodlagos névtérre irányítja át, majd megszakítja a párosítást. A feladatátvétel a kezdeményezést követően szinte azonnal megtörténik.

Azure Cognitive Search

A Cognitive Searchben a rendelkezésre állás több replikán keresztül érhető el, míg az üzletmenet-folytonosság és a vészhelyreállítás (BCDR) több keresési szolgáltatással érhető el.

A Cognitive Searchben a replikák az index másolatai. A több replika lehetővé teszi az Azure Cognitive Search számára a gép újraindítását és karbantartását egy replikán, míg a lekérdezések végrehajtása más replikákon folytatódik. További információ a replikák és partíciók hozzáadásáról: Replikák és partíciók hozzáadása vagy csökkentése.

A rendelkezésre állási zónákat az Azure Cognitive Search szolgáltatással két vagy több replika hozzáadásával használhatja a keresési szolgáltatáshoz. Minden replika egy másik rendelkezésre állási zónába kerül a régión belül.

A BCDR-vel kapcsolatos szempontokért tekintse meg a több szolgáltatást külön földrajzi régiók dokumentációjában.

Azure Cache for Redis

Bár az Azure Cache for Redis összes szintje standard replikációt kínál a magas rendelkezésre állás érdekében, a Prémium vagy a Nagyvállalati szint ajánlott magasabb szintű rugalmasságot és helyreállíthatóságot biztosítani. Tekintse át a magas rendelkezésre állási és vészhelyreállítási lehetőségeket a rugalmassági és helyreállíthatósági funkciók és lehetőségek teljes listájáért ezekhez a szintekhez. Az üzleti követelmények határozzák meg, hogy melyik szint felel meg a legjobban az infrastruktúrának.

Megfontolások

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 halmaza. További információ: Microsoft Azure Well-Architected Framework.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: A megbízhatósági pillér áttekintése. Ezeket a szempontokat érdemes figyelembe venni a régiók közötti magas rendelkezésre állás tervezésekor.

Azure Front Door

Az Azure Front Door automatikusan meghiúsul, ha az elsődleges régió elérhetetlenné válik. Amikor a Front Door meghibásodik, van egy időszak (általában 20-60 másodperc), amikor az ügyfelek nem érik el az alkalmazást. Ez az időtartam a következő tényezőktől függ:

• Az állapotadat-mintavételek gyakorisága. Minél gyakrabban küldik el az állapotmintákat, annál gyorsabban észleli a Front Door az állásidőt, vagy a forrás kifogástalan állapotba kerül.
• Mintaméret-konfiguráció. Ez a konfiguráció azt szabályozza, hogy hány minta szükséges ahhoz, hogy az állapotadat-mintavétel észlelje, hogy az elsődleges forrás elérhetetlenné vált. Ha ez az érték túl alacsony, akkor előfordulhat, hogy az időszakos problémák hamis pozitív eredményt adnak.

A Front Door a rendszer egyik lehetséges meghibásodási pontja. Ha a szolgáltatás meghiúsul, az ügyfelek nem tudnak hozzáférni az alkalmazáshoz az állásidő alatt. Tekintse át a Front Door szolgáltatói szerződést (SLA), és döntse el, hogy a Front Door egyedüli használata elegendő-e vállalata magas rendelkezésre állásra vonatkozó követelményeinek kielégítéséhez. Ha nem, akkor a biztonság érdekében érdemes lehet hozzáadni egy másik forgalomkezelési szolgáltatást a feladat-visszavételhez. Ha a Front Door szolgáltatás meghibásodik, módosítsa a saját kanonikus nevének (CNAME-) rekordját a DNS-ben úgy, hogy a többi forgalomkezelő szolgáltatásra mutasson. Ezt a lépést manuálisan kell elvégezni. Amíg a DNS-módosítások érvénybe nem lépnek, az alkalmazás nem lesz elérhető.

Az Azure Front Door Standard és a Premium szint egyetlen platformon egyesíti az Azure Front Door (klasszikus), a Microsofttól származó Azure CDN Standard és az Azure WAF képességeit. Az Azure Front Door Standard vagy Premium használata csökkenti a meghibásodási pontokat, és fokozott ellenőrzést, monitorozást és biztonságot tesz lehetővé. További információ: Az Azure Front Door szint áttekintése.

SQL Database

Az SQL Database helyreállítási pontjának célkitűzése (RPO) és becsült helyreállítási időkorlátja (RTO) az Azure SQL Database üzletmenet-folytonosságának áttekintésében található.

Ügyeljen arra, hogy az aktív georeplikációs szolgáltatás hatékonyan megduplázza az egyes replikált adatbázisok költségeit. A tesztkörnyezeti, tesztelési és fejlesztési adatbázisok általában nem ajánlottak a replikációhoz.

Azure Cosmos DB

Az Azure Cosmos DB RPO- és helyreállítási időkorlátja (RTO) konfigurálható a használt konzisztenciaszinteken keresztül, amelyek kompromisszumot biztosítanak a rendelkezésre állás, az adatok tartóssága és az átviteli sebesség között. Az Azure Cosmos DB legalább 0 RTO-t biztosít a több főkiszolgálóval való nyugodt konzisztenciaszinthez, vagy egy 0-s RPO-t az egy főkiszolgálóval való erős konzisztencia érdekében. Az Azure Cosmos DB konzisztenciaszintjeiről az Azure Cosmos DB konzisztenciaszintjeiről és az adatok tartósságáról szóló cikkben olvashat bővebben.

Tárolás

Az RA-GRS storage tartós tárolást biztosít, de a feladatátvétel során fontos figyelembe venni a következő tényezőket:

• Várható adatvesztés: A másodlagos régióba történő adatreplikálás aszinkron módon történik. Ezért geo-feladatátvétel végrehajtása esetén némi adatvesztésre kell számítani, ha az elsődleges fiók módosításai nem szinkronizálódnak teljesen a másodlagos fiókkal. A másodlagos tárfiók Utolsó szinkronizálási idő tulajdonságában megtekintheti, hogy az elsődleges régióból származó adatok utoljára mikor lettek sikeresen megírva a másodlagos régióba.

• Ennek megfelelően tervezze meg a helyreállítási időkorlátot (RTO): A másodlagos régióba történő feladatátvétel általában körülbelül egy órát vesz igénybe, ezért a DR-tervnek figyelembe kell vennie ezeket az információkat az RTO-paraméterek kiszámításakor.

• Gondosan tervezze meg a feladat-visszavételt: Fontos tisztában lenni azzal, hogy ha egy tárfiók meghibásodik, az eredeti elsődleges fiók adatai elvesznek. Az elsődleges régióba való visszavétel gondos tervezés nélkül kockázatos. A feladatátvétel befejezése után az új elsődleges – a feladatátvételi régióban – helyileg redundáns tárolásra (LRS) lesz konfigurálva. Manuálisan újrakonfigurálnia kell georeplikált tárolóként az elsődleges régióba történő replikáció elindításához, majd elegendő időt kell hagynia a fiókok szinkronizálására.

• Az átmeneti hibák, például a hálózatkimaradások nem aktiválják a tároló feladatátvételét. Tervezze alkalmazását úgy, hogy ellenálló legyen az átmeneti hibákkal szemben. A megoldási lehetőségek a következők:

  • Olvasás a másodlagos régióból.
  • Ideiglenes átváltás másik tárfiókra az új írási műveletekhez (például az üzenetek üzenetsorba való helyezéséhez).
  • Adatok átmásolása a másodlagos régióból egy másik tárfiókba.
  • Csökkentett szolgáltatás nyújtása, amíg a rendszer végre nem hajtja a feladat-visszavételt.

További információk: Mi a Mi a teendő az Azure Storage leállása esetén.

Az objektumreplikáció dokumentációjának előfeltételei és kikötései a blokkblobok objektumreplikációjának használatakor megfontolandó szempontokat ismertetik.

Azure Service Bus

Fontos tisztában lenni azzal, hogy a prémium Szintű Azure Service Bus-csomag georedukciós helyreállítási funkciója lehetővé teszi a műveletek azonnali folytonosságát ugyanazzal a konfigurációval. Azonban nem replikálja az üzenetsorokban, a témakör-előfizetésekben vagy a kézbesítetlen levelek üzenetsoraiban tárolt üzeneteket. Ezért kockázatcsökkentési stratégiára van szükség a másodlagos régióba történő zökkenőmentes feladatátvétel biztosításához. Az egyéb szempontok és a kockázatcsökkentési stratégiák részletes leírásáért tekintse meg a fontos szempontokat és a vészhelyreállítási szempontok dokumentációját.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

Bejövő forgalom korlátozása Konfigurálja az alkalmazást úgy, hogy csak a Front Doorról fogadjon forgalmat. Ez biztosítja, hogy az alkalmazás elérése előtt minden forgalom áthalad a WAF-on. További információ: Hogyan zárolja a háttérrendszerem hozzáférését csak az Azure Front Doorhoz?

Forrásközi erőforrás-megosztás (CORS) Ha külön alkalmazásként hoz létre webhelyet és webes API-t, a webhely csak akkor tud ügyféloldali AJAX-hívásokat kezdeményezni az API-hoz, ha engedélyezi a CORS-t.

Az App Services beépített támogatást nyújt a CORS használatához anélkül, hogy alkalmazáskódot kellene írni. Lásd: API-alkalmazások felhasználása JavaScriptből a CORS használatával. A webhelyet fel kell venni az API által engedélyezett származási helyek listájára.

SQL Database-titkosítás: Használja a transzparens adattitkosítás, ha az adatbázisban inaktív adatok titkosítására van szükség. Ez a szolgáltatás valós időben végzi a titkosítást és a visszafejtést a teljes adatbázisra vonatkozóan (a biztonsági mentéseket és a tranzakciós naplófájlokat is beleértve), miközben az alkalmazást nem kell módosítani. A titkosítás némi késéssel jár, ezért a védelmet igénylő adatokat érdemes elkülöníteni egy saját adatbázisba, hogy csak ezen kelljen engedélyezni a titkosítást.

Identitás Amikor identitásokat határoz meg az architektúra összetevőihez, a rendszer által felügyelt identitásokat használva lehetőség szerint csökkentse a hitelesítő adatok kezelésének szükségességét és a hitelesítő adatok kezelésével járó kockázatokat. Ha nem lehet rendszer által felügyelt identitásokat használni, győződjön meg arról, hogy minden felhasználó által felügyelt identitás csak egy régióban létezik, és soha nem lesz megosztva a régió határain.

Szolgáltatás tűzfalak Az összetevők szolgáltatás tűzfalainak konfigurálásakor győződjön meg arról, hogy csak a régió-helyi szolgáltatások férhetnek hozzá a szolgáltatásokhoz, és hogy a szolgáltatások csak kimenő kapcsolatokat engedélyeznek, ami kifejezetten szükséges a replikációhoz és az alkalmazás működéséhez. Fontolja meg az Azure Private Link használatát a további továbbfejlesztett vezérléshez és szegmentáláshoz. További információ a webalkalmazások biztonságossá tételéről: Alapkonfiguráció– magas rendelkezésre állású zónaredundáns webalkalmazás.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

Gyorsítótárazással csökkentheti a gyakran nem változó tartalmakat kiszolgáló kiszolgálók terhelését. Egy lap minden renderelési ciklusa hatással lehet a költségekre, mert számítási, memória- és sávszélesség-használatot használ fel. Ezek a költségek jelentősen csökkenthetők gyorsítótárazással, különösen statikus tartalomszolgáltatások, például egyoldalas JavaScript-alkalmazások és médiastreamelési tartalmak esetében.

Ha az alkalmazás statikus tartalommal rendelkezik, a CDN használatával csökkentheti az előtér-kiszolgálók terhelését. A gyakran nem változó adatokhoz használja az Azure Cache for Redist.

Az automatikus skálázáshoz konfigurált állapot nélküli alkalmazások költséghatékonyabbak, mint az állapotalapú alkalmazások. Munkamenet-állapotot használó ASP.NET alkalmazások esetében tárolja a memóriában az Azure Cache for Redis használatával. További információ: ASP.NET Munkamenet-állapotszolgáltató az Azure Cache for Redishez. Egy másik lehetőség az Azure Cosmos DB használata háttérállapot-tárolóként egy munkamenet-állapotszolgáltatón keresztül. Lásd: Az Azure Cosmos DB használata ASP.NET munkamenet-állapot és gyorsítótárazási szolgáltatóként.

A függvények fontolja meg, hogy egy függvényalkalmazást egy dedikált App Service-csomagba helyezzen, hogy a háttérfeladatok ne fussanak a HTTP-kéréseket kezelő példányokon. Ha a háttérfeladatok időszakosan futnak, fontolja meg egy használati terv használatát, amely a végrehajtások és a felhasznált erőforrások száma alapján kerül számlázásra, nem pedig óránként.

További információkért tekintse meg a Microsoft Azure Well-Architected Framework költség szakaszát.

A költségek becsléséhez használja a díjkalkulátort . A jelen szakaszban található javaslatok segíthetnek a költségek csökkentésében.

Azure Front Door

Az Azure Front Door számlázásának három tarifacsomagja van: kimenő adatátvitel, bejövő adatátvitel és útválasztási szabályok. További információ: Az Azure Front Door díjszabása. A díjszabási diagram nem tartalmazza a forrásszolgáltatásokból származó adatok elérésének és a Front Doorba való átvitelnek a költségét. Ezek a költségek az adatátviteli díjak alapján kerülnek számlázásra, a sávszélesség díjszabásának részleteiben leírtak szerint.

Azure Cosmos DB

Az Azure Cosmos DB díjszabását két tényező határozza meg:

• A kiosztott átviteli sebesség vagy kérelemegység másodpercenként (RU/s)..

  Az Azure Cosmos DB-ben kétféle átviteli sebesség építhető ki, a standard és az automatikus skálázás. A standard átviteli sebesség lefoglalja a megadott RU/s garantálásához szükséges erőforrásokat. Az automatikus skálázáshoz ki kell állítania a maximális átviteli sebességet, és az Azure Cosmos DB a terheléstől függően azonnal fel- vagy leskálázható, a maximális automatikus skálázási átviteli sebesség legalább 10%-ával. A normál átviteli sebesség számlázása az óránként kiosztott átviteli sebességért történik. Az automatikus skálázási átviteli sebesség számlázása az óránként felhasznált maximális átviteli sebességért történik.

• Felhasznált tárterület. Az adatokhoz és az indexekhez felhasznált teljes tárterület (GBs) egy adott órára vonatkozó átalánydíja lesz kiszámlázva.

További információért lásd a Microsoft Azure Well-Architected Framework költségekkel kapcsolatos részét.

Teljesítmény hatékonysága

Az Azure App Service egyik fő előnye az alkalmazások skálázásának lehetősége a terhelés alapján. A következő szempontokat kell szem előtt tartani az alkalmazás skálázásának tervezésekor.

App Service-alkalmazás

Ha a megoldás több App Service-alkalmazást tartalmaz, érdemes megfontolni a külön App Service-csomagokba történő telepítésüket. Ez a megoldás lehetővé teszi az egymástól függetlenül történő méretezésüket, mivel külön példányokon futnak.

SQL Database

A horizontális skálázás alkalmazásával növelhető az SQL-adatbázis méretezhetősége. A horizontális skálázás az adatbázis horizontális particionálását jelenti. A horizontális skálázás lehetővé teszi az adatbázis Elastic Database-eszközökkel történő horizontális felskálázását. A horizontális skálázás lehetséges előnyei a következők:

• Nagyobb tranzakciós átviteli sebesség.
• A lekérdezések gyorsabban futnak az adatok egy részén.

Azure Front Door

A Front Door képes SSL-kiszervezést végezni, és csökkenti a tcp-kapcsolatok teljes számát a háttér-webalkalmazással. Ez javítja a méretezhetőséget, mivel a webalkalmazás kisebb mennyiségű SSL-kézfogást és TCP-kapcsolatot kezel. Ezek a teljesítménybeli előnyök akkor is érvényesülnek, ha a kéréseket HTTPS-ként továbbítja a webalkalmazásnak a kapcsolat magas szintű újrafelhasználása miatt.

Azure Search

Az Azure Search eltávolítja az összetett adatkeresések okozta többletterhelést az elsődleges adattárolóból, továbbá a terhelésnek megfelelően méretezhető. Lásd: Az erőforrásszintek méretezése a lekérdezéshez és a számítási feladatok indexeléséhez az Azure Search szolgáltatásban.

Működés eredményessége

Az operatív kiválóság azokat az üzemeltetési folyamatokat jelenti, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben futtatják, és a jól megtervezett keretrendszer megbízhatósági útmutatójának kiterjesztése. Ez az útmutató részletes áttekintést nyújt az alkalmazás-keretrendszer rugalmasságának fejlesztéséről, hogy a számítási feladatok elérhetők legyenek, és bármilyen szinten helyre tudjanak állni a hibákból. Ennek a megközelítésnek a lényege, hogy az alkalmazásinfrastruktúra magas rendelkezésre állású legyen, optimálisan több földrajzi régióban, ahogyan azt ez a kialakítás szemlélteti.

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ő:

• Arvind Boggaram Pandurangaiah Setty | Vezető tanácsadó

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

• Részletes elemzés az Azure Front Doorról – forgalomirányítási módszerek

• Állapotminták létrehozása, amelyek az alkalmazás általános állapotát jelentik végpontfigyelési minták alapján

• Azure SQL automatikus feladatátvételi csoportok engedélyezése

• Az üzletmenet folytonosságának és vészhelyreállításának biztosítása az Azure Párosított régiók használatával

Kapcsolódó erőforrások

• A többrégiós N szintű alkalmazás hasonló forgatókönyv. Egy több Azure-régióban futó N szintű alkalmazást jelenít meg

• Tervezési alapelvek Azure-alkalmazásokhoz