Webbprogram med hög tillgänglighet för flera regioner

Den här exempelarkitekturen baseras på exempelarkitekturen för basic-webbprogram och utökar den så att den visar:

• Beprövade metoder för att förbättra skalbarhet och prestanda i ett Azure App Service-webbprogram
• Så här kör du ett Azure App Service-program i flera regioner för att uppnå hög tillgänglighet

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Det här arbetsflödet hanterar arkitekturens aspekter i flera regioner och bygger vidare på basic-webbappen.

• Primära och sekundära regioner. I den här arkitekturen används två regioner för att få en högre tillgänglighet. Programmet distribueras i varje region. Under normal drift dirigeras nätverkstrafiken till den primära regionen. Om den primära regionen blir otillgänglig vidarebefordras trafiken till den sekundära regionen.
• Front Door. Azure Front Door är den rekommenderade lastbalanseraren för implementeringar i flera regioner. Den integreras med brandväggen för webbprogram (WAF) för att skydda mot vanliga kryphål och använder Front Door inbyggda innehållscachelagringsfunktioner. I den här arkitekturen konfigureras Front Door för prioritetsdirigering , vilket skickar all trafik till den primära regionen om den inte blir otillgänglig. Om den primära regionen blir otillgänglig dirigerar Front Door all trafik till den sekundära regionen.
• Geo-replikering av lagringskonton, SQL Database och/eller Azure Cosmos DB.

Komponenter

Viktiga tekniker som används för att implementera den här arkitekturen:

• Microsoft Entra ID är en molnbaserad identitets- och åtkomsthanteringstjänst som ger anställda åtkomst till molnappar som utvecklats för din organisation.
• Azure DNS är en värdtjänst för DNS-domäner som ger namnmatchning med hjälp av Microsoft Azure-infrastrukturen. Genom att använda Azure som värd för dina domäner kan du hantera dina DNS-poster med samma autentiseringsuppgifter, API:er, verktyg och fakturering som för dina andra Azure-tjänster. Om du vill använda ett anpassat domännamn (till exempel contoso.com) skapar du DNS-poster som mappar det anpassade domännamnet till IP-adressen. Mer information finns i Konfigurera ett anpassat domännamn i Azure App Service.
• Azure Content Delivery Network är en global lösning för att leverera innehåll med hög bandbredd genom att cachelagra det på strategiskt placerade fysiska noder över hela världen.
• Azure Front Door är en layer 7-lastbalanserare. I den här arkitekturen dirigerar den HTTP-begäranden till webbklientdelen. Front Door tillhandahåller också en brandvägg för webbprogram (WAF) som skyddar programmet mot vanliga sårbarheter och sårbarheter. Front Door används också för en CDN-lösning (Content Delivery Network ) i den här designen.
• Azure AppService är en fullständigt hanterad plattform för att skapa och distribuera molnprogram. Med den kan du definiera en uppsättning beräkningsresurser för en webbapp som ska köras, distribuera webbappar och konfigurera distributionsplatser.
• Azure Function Apps kan användas för att köra bakgrundsaktiviteter. Funktioner anropas av en utlösare, till exempel en timerhändelse eller ett meddelande som placeras i kön. Använd Durable Functions för tidskrävande tillståndskänsliga uppgifter.
• Azure Storage är en molnlagringslösning för moderna datalagringsscenarier som erbjuder hög tillgänglighet, massivt skalbar, beständig och säker lagring för en mängd olika dataobjekt i molnet.
• Azure Redis Cache är en högpresterande cachelagringstjänst som tillhandahåller ett minnesinternt datalager för snabbare hämtning av data, baserat på redis-cachen för implementering med öppen källkod.
• Azure SQL Database är en relationsdatabas som en tjänst i molnet. SQL-databas delar sin kodbas med Microsoft SQL Server-databasmotorn.
• Azure Cosmos DB är en globalt distribuerad, fullständigt hanterad databas med låg svarstid, flera modeller och flera fråge-API:er för hantering av data i stor skala.
• Azure Cognitive Search kan användas för att lägga till sökfunktioner som sökförslag, fuzzy-sökning och språkspecifik sökning. Azure Search används ofta tillsammans med ett annat datalager, i synnerhet om det primära datalagret kräver strikt konsekvens. Med den här metoden lagras auktoritativa data i det andra datalagret och sökindexet i Azure Search. Azure Search kan även användas för att sammanställa ett enda sökindex från flera datalager.

Information om scenario

Det finns flera allmänna metoder för att uppnå hög tillgänglighet i olika regioner:

• Aktiv/passiv med frekvent vänteläge: trafiken går till en region, medan den andra väntar i hett vänteläge. Frekvent vänteläge innebär att App Service i den sekundära regionen allokeras och alltid körs.

• Aktiv/passiv med kallt vänteläge: trafiken går till en region, medan den andra väntar i kallt vänteläge. Kallt vänteläge innebär att App Service i den sekundära regionen inte allokeras förrän det behövs för redundansväxling. Den här metoden kostar mindre att köra, men tar vanligtvis längre tid att ansluta vid fel.

• Aktiv/aktiv: båda regionerna är aktiva och begäranden lastbalanseras mellan dem. Om en region blir otillgänglig tas den ur rotation.

Den här referensen fokuserar på aktiv/passiv med frekvent vänteläge.

Potentiella användningsfall

Dessa användningsfall kan dra nytta av en distribution i flera regioner:

• Utforma en plan för affärskontinuitet och haveriberedskap för LoB-program.

• Distribuera verksamhetskritiska program som körs i Windows eller Linux.

• Förbättra användarupplevelsen genom att hålla program tillgängliga.

Rekommendationer

Dina krav kan vara annorlunda från den arkitektur som beskrivs här. Använd rekommendationerna i det här avsnittet som en utgångspunkt.

Regional länkning

Varje Azure-region är kopplad till en annan region inom samma geografiska område. I allmänhet väljer du regioner från samma regionala par (till exempel USA, östra 2 och USA, centrala). Exempel på fördelar med det:

• Om det uppstår ett brett avbrott prioriteras återställning av minst en region av varje par.
• Planerade uppdateringar av Azure-systemet utförs sekventiellt i hopparade regioner för att minimera eventuella driftstopp.
• I de flesta länder är regionala par belägna inom samma geografiska område för att uppfylla kraven på datahemvist.

Se dock till att båda regioner har stöd för alla Azure-tjänster som krävs för ditt program. Se Tjänster per region. Mer information om regionala par finns i Business continuity and disaster recovery (BCDR): Azure Paired Regions (Affärskontinuitet och haveriberedskap: Länkade Azure-regioner).

Resursgrupper

Överväg att placera den primära regionen, den sekundära regionen och Front Door i separata resursgrupper. Med den här allokeringen kan du hantera de resurser som distribueras till varje region som en enda samling.

App Service-appar

Vi rekommenderar att skapa webbappen och webb-API:et som separata App Service-appar. Då kan du köra dem i separata App Service-planer så att de kan skalas var för sig. Om du inte behöver den här nivån av skalning inledningsvis kan du distribuera apparna i samma plan och flytta dem till separata planer senare om det behövs.

Front Door-konfiguration

Routning. Front Door stöder flera routningsmekanismer. Använd prioritetsroutning för scenariot som beskrivs i den här artikeln. Med den här inställningen skickar Front Door alla begäranden till den primära regionen om inte slutpunkten för den regionen blir oåtkomlig. Då flyttas processen automatiskt över till den sekundära regionen. Ange ursprungspoolen med olika prioritetsvärden, 1 för den aktiva regionen och 2 eller högre för vänteläge eller passiv region.

Hälsoavsökning. Front Door använder en HTTPS-avsökning för att övervaka tillgängligheten för varje serverdel. Avsökningen ger Front Door ett pass/fail-test för redundansväxling till den sekundära regionen. En begäran skickas till en angiven URL-sökväg. Avsökningen misslyckas om den får ett icke-200-svar inom en viss tidsgräns. Du kan konfigurera hälsoavsökningsfrekvensen, antalet exempel som krävs för utvärdering och antalet lyckade exempel som krävs för att ursprunget ska markeras som felfritt. Om Front Door markerar ursprunget som degraderat redundansväxlar det till det andra ursprunget. Mer information finns i Hälsoavsökningar.

Vi rekommenderar att du skapar en sökväg för hälsoavsökningar i programmets ursprung som rapporterar programmets övergripande hälsa. Den här hälsoavsökningen bör kontrollera kritiska beroenden som App Service-appar, lagringskö och SQL Database. Annars kan avsökningen rapportera ett felfritt ursprung när kritiska delar av programmet faktiskt misslyckas. Å andra sidan ska hälsoavsökningen inte användas för att kontrollera tjänster med lägre prioritet. Om en e-posttjänst exempelvis kraschar kan programmet växla till en andra provider eller bara skicka e-post senare. Mer information om det här designmönstret finns i Hälsoslutpunktsövervakningsmönster.

Att skydda ursprung från Internet är en viktig del av implementeringen av en offentligt tillgänglig app. Mer information om Microsofts rekommenderade design- och implementeringsmönster för att skydda appens inkommande kommunikation med Front Door finns i nätverkssäkerhetsimplementeringen.

CDN. Använd Front Door inbyggda CDN-funktioner för att cachelagera statiskt innehåll. Den största fördelen med ett nätverk för innehållsleverans är att svarstiden minskas för användare, eftersom innehåll cachelagras på en Edge-server som är geografiskt nära användaren. Med nätverk för innehållsleverans kan också belastningen på programmet minskas eftersom den trafiken inte hanteras av programmet. Front Door erbjuder dessutom dynamisk webbplatsacceleration så att du kan leverera en bättre övergripande användarupplevelse för webbappen än vad som skulle vara tillgängligt med endast cachelagring av statiskt innehåll.

SQL Database

Använd aktiva geo-replikerings - och automatiska redundansgrupper för att göra dina databaser motståndskraftiga. Med aktiv geo-replikering kan du replikera dina databaser från den primära regionen till en eller flera (upp till fyra) andra regioner. Grupper för automatisk redundans bygger på aktiv geo-replikering genom att du kan redundansväxla till en sekundär databas utan några kodändringar i dina appar. Redundansväxlingar kan utföras manuellt eller automatiskt enligt principdefinitioner som du skapar. För att kunna använda grupper för automatisk redundans måste du konfigurera anslutningssträngarna med redundansväxlingen anslutningssträng skapas automatiskt för redundansgruppen i stället för de enskilda databasernas anslutningssträng.

Azure Cosmos DB

Azure Cosmos DB stöder geo-replikering mellan regioner i aktivt-aktivt mönster med flera skrivregioner. Du kan också ange en region som skrivbar region och de andra som skrivskyddade repliker. Om det uppstår ett regionalt avbrott kan du redundansväxla genom att välja en annan region som skrivregion. Klienten skickar automatiskt SDK-skrivåtgärder till den aktuella skrivregionen så du behöver inte uppdatera klientkonfigurationen efter en redundansväxling. Mer information finns i Global datadistribution med Azure Cosmos DB.

Lagring

Använd skrivskyddad geo-redundant lagring med läsbehörighet (RA-GRS) för Azure Storage. Data replikeras till en sekundär region med RA-GRS-lagring. Du har skrivskyddad åtkomst till data i den sekundära regionen via en separat slutpunkt. Användarinitierad redundansväxling till den sekundära regionen stöds för geo-replikerade lagringskonton. När ett lagringskonto startas uppdateras DNS-poster automatiskt för att göra det sekundära lagringskontot till det nya primära lagringskontot. Redundansväxlingar bör endast utföras när du anser att det är nödvändigt. Det här kravet definieras av organisationens haveriberedskapsplan och du bör överväga konsekvenserna enligt beskrivningen i avsnittet Överväganden nedan.

Om det uppstår ett regionalt avbrott eller ett haveri kan Azure Storage-teamet besluta att utföra en geo-redundansväxling till den sekundära regionen. För dessa typer av redundansväxlingar krävs ingen kundåtgärd. Återställning efter fel till den primära regionen hanteras också av Azure-lagringsteamet i dessa fall.

I vissa fall är objektreplikering för blockblobar en tillräcklig replikeringslösning för din arbetsbelastning. Med den här replikeringsfunktionen kan du kopiera enskilda blockblobar från det primära lagringskontot till ett lagringskonto i den sekundära regionen. Fördelarna med den här metoden är en detaljerad kontroll över vilka data som replikeras. Du kan definiera en replikeringsprincip för mer detaljerad kontroll över de typer av blockblobar som replikeras. Exempel på principdefinitioner är, men är inte begränsade till:

• Endast blockblobar som lagts till efter att principen har skapats replikeras
• Endast blockblobar som har lagts till efter ett visst datum och en viss tid replikeras
• Endast blockblobar som matchar ett angivet prefix replikeras.

Kölagring refereras som ett alternativt meddelandealternativ till Azure Service Bus för det här scenariot. Men om du använder kölagring för din meddelandelösning gäller vägledningen ovan i förhållande till geo-replikering här, eftersom kölagring finns på lagringskonton. Det är dock viktigt att förstå att meddelanden inte replikeras till den sekundära regionen och att deras tillstånd är oupplösligt från regionen.

Azure Service Bus

Använd premiumnivån för dina namnområden för att dra nytta av den högsta motståndskraft som erbjuds för Azure Service Bus. Premiumnivån använder tillgänglighetszoner, vilket gör dina namnområden motståndskraftiga mot avbrott i datacenter. Om det uppstår en omfattande katastrof som påverkar flera datacenter kan geo-haveriberedskapsfunktionen som ingår i premiumnivån hjälpa dig att återställa. Funktionen Geo-Haveriberedskap säkerställer att hela konfigurationen av ett namnområde (köer, ämnen, prenumerationer och filter) kontinuerligt replikeras från ett primärt namnområde till ett sekundärt namnområde när det är kopplat. Du kan när som helst initiera en redundansväxling från den primära till den sekundära. Redundansväxlingen pekar om det valda aliasnamnet för namnområdet till det sekundära namnområdet och bryter sedan parkopplingen. Redundansväxlingen är nästan omedelbar när den har initierats.

Azure Cognitive Search

I Cognitive Search uppnås tillgänglighet via flera repliker, medan affärskontinuitet och haveriberedskap (BCDR) uppnås via flera söktjänster.

I Cognitive Search är repliker kopior av ditt index. Med flera repliker kan Azure Cognitive Search göra datoromstarter och underhåll mot en replik, medan frågekörningen fortsätter på andra repliker. Mer information om hur du lägger till repliker finns i Lägga till eller minska repliker och partitioner.

Du kan använda Tillgänglighetszoner med Azure Cognitive Search genom att lägga till två eller flera repliker i söktjänsten. Varje replik placeras i en annan tillgänglighetszon i regionen.

För BCDR-överväganden, se dokumentationen om flera tjänster i separata geografiska regioner .

Azure Cache for Redis

Alla nivåer i Azure Cache for Redis erbjuder standardreplikering för hög tillgänglighet, men Premium- eller Enterprise-nivån rekommenderas för att ge en högre återhämtningsnivå och återställning. Granska hög tillgänglighet och haveriberedskap för en fullständig lista över funktioner och alternativ för återhämtning och återställning för dessa nivåer. Dina affärskrav avgör vilken nivå som passar bäst för infrastrukturen.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare. Tänk på dessa punkter när du utformar för hög tillgänglighet mellan regioner.

Azure Front Door

Azure Front Door redundansväxlar automatiskt om den primära regionen blir otillgänglig. När Front Door redundansväxlar finns det en tidsperiod (vanligtvis cirka 20–60 sekunder) när klienterna inte kan nå programmet. Varaktigheten påverkas av följande faktorer:

• Frekvens för hälsoavsökningar. Ju oftare hälsoavsökningarna skickas, desto snabbare kan Front Door identifiera stilleståndstid eller att ursprunget kommer tillbaka felfritt.
• Exempelstorlekskonfiguration. Den här konfigurationen styr hur många exempel som krävs för hälsoavsökningen för att identifiera att det primära ursprunget inte kan nås. Om det här värdet är för lågt kan du få falska positiva identifieringar av tillfälliga problem.

Front Door är en möjlig felpunkt i systemet. Om tjänsten misslyckas kan klienterna inte komma åt ditt program under driftstoppet. Läs serviceavtalet för Front Door och avgör huruvida användning av enbart Front Door uppfyller företagets krav på hög tillgänglighet. Om det inte räcker bör du överväga att lägga till ytterligare en trafikhanteringslösning som extra skydd. Om Front Door-tjänsten slutar fungera ändrar du posterna för kanoniska namn (CNAME) i DNS så att de pekar mot den andra trafikhanteringstjänsten. Det här steget måste utföras manuellt och programmet förblir otillgängligt tills DNS-ändringarna har spridits.

Azure Front Door Standard- och Premium-nivån kombinerar funktionerna i Azure Front Door (klassisk), Azure CDN Standard från Microsoft (klassisk) och Azure WAF till en enda plattform. Med Azure Front Door Standard eller Premium minskar felpunkterna och ger förbättrad kontroll, övervakning och säkerhet. Mer information finns i Översikt över Azure Front Door-nivån.

SQL Database

Målet för återställningspunkt (RPO) och det uppskattade mål för återställningstid (RTO) för SQL Database dokumenteras i Översikt över affärskontinuitet med Azure SQL Database.

Tänk på att aktiv geo-replikering effektivt fördubblar kostnaden för varje replikerad databas. Sandbox-, test- och utvecklingsdatabaser rekommenderas vanligtvis inte för replikering.

Azure Cosmos DB

Mål för RPO och återställningstid (RTO) för Azure Cosmos DB kan konfigureras via de konsekvensnivåer som används, vilket ger kompromisser mellan tillgänglighet, datahållbarhet och dataflöde. Azure Cosmos DB ger en lägsta RTO på 0 för en avslappnad konsekvensnivå med flera original eller ett RPO på 0 för stark konsekvens med en master. Mer information om konsekvensnivåer i Azure Cosmos DB finns i Konsekvensnivåer och datahållbarhet i Azure Cosmos DB.

Lagring

RA-GRS-lagring ger varaktig lagring, men det är viktigt att tänka på följande faktorer när du överväger att utföra en redundansväxling:

• Förutse dataförlust: Datareplikering till den sekundära regionen utförs asynkront. Om en geo-redundans utförs bör därför viss dataförlust förväntas om ändringar i det primära kontot inte har synkroniserats helt med det sekundära kontot. Du kan kontrollera egenskapen Senaste synkroniseringstid för det sekundära lagringskontot för att se den senaste gången data från den primära regionen skrevs till den sekundära regionen.

• Planera ditt mål för återställningstid (RTO) i enlighet med detta: Redundans till den sekundära regionen tar vanligtvis ungefär en timme, så din DR-plan bör ta hänsyn till den här informationen när du beräknar dina RTO-parametrar.

• Planera återställningen noggrant: Det är viktigt att förstå att när ett lagringskonto redundansväxlas går data i det ursprungliga primära kontot förlorade. Det är riskabelt att försöka återställa till den primära regionen utan noggrann planering. När redundansväxlingen är klar konfigureras den nya primära - i redundansregionen - för lokalt redundant lagring (LRS). Du måste konfigurera om den som geo-replikerad lagring manuellt för att initiera replikering till den primära regionen och sedan ge tillräckligt med tid för att låta kontona synkroniseras.

• Tillfälliga fel, till exempel ett nätverksfel, utlöser inte någon redundansväxling i lagringen. Designa programmet så att det kan hantera att tillfälligt fel. Bland alternativen för åtgärder finns:

  • Läsa från den sekundära regionen.
  • Tillfälligt byta till ett annat lagringskonto för nya skrivåtgärder (till exempel för att köa meddelanden).
  • Kopiera data från den sekundära regionen till ett annat lagringskonto.
  • Tillhandahåll begränsad funktionalitet tills systemet återställs efter ett fel.

Mer information finns i Vad du gör om ett avbrott i Azure Storage inträffar?.

Mer information om hur du använder objektreplikering för blockblobar finns i dokumentationen om förutsättningar och varningar för objektreplikering .

Azure Service Bus

Det är viktigt att förstå att geo-haveriberedskapsfunktionen som ingår i Premium Azure Service Bus-nivån möjliggör omedelbar kontinuitet för åtgärder med samma konfiguration. Den replikerar dock inte meddelandena som finns i köer eller ämnesprenumerationer eller köer med obeställbara meddelanden. Därför krävs en åtgärdsstrategi för att säkerställa en smidig redundansväxling till den sekundära regionen. En detaljerad beskrivning av andra överväganden och åtgärdsstrategier finns i dokumentationen om viktiga saker att tänka på och överväganden för haveriberedskap .

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Begränsa inkommande trafik Konfigurera programmet så att det endast accepterar trafik från Front Door. Detta säkerställer att all trafik går via WAF innan du når appen. Mer information finns i Hur gör jag för att låsa åtkomsten till min serverdel till endast Azure Front Door?

Resursdelning för korsande ursprung (CORS) Om du skapar en webbplats och ett webb-API som separata appar kan webbplatsen inte göra AJAX-anrop på klientsidan till API:et om du inte aktiverar CORS.

App Services har inbyggt stöd för CORS. Programkod behöver inte skrivas. Läs mer på sidan om att använda en API-app från JavaScript med CORS. Lägg till webbplatsen i listan över tillåtna ursprung för API:et.

SQL Database-kryptering Använd transparent datakryptering om du behöver kryptera vilande data i databasen. Den här funktionen utför kryptering och dekryptering i realtid för en hel databas (inklusive säkerhetskopior och transaktionsloggfiler), utan att det krävs ändringar i programmet. Kryptering medför viss fördröjning, så det kan vara bra att åtskilja de data som måste vara säkra i en egen databas och aktivera kryptering endast för den databasen.

Identitet När du definierar identiteter för komponenterna i den här arkitekturen använder du systemhanterade identiteter där det är möjligt för att minska behovet av att hantera autentiseringsuppgifter och riskerna med att hantera autentiseringsuppgifter. Om det inte går att använda systemhanterade identiteter kontrollerar du att varje användarhanterad identitet bara finns i en region och aldrig delas över regiongränser.

Tjänstbrandväggar När du konfigurerar tjänstbrandväggarna för komponenterna ska du se till att endast de region-lokala tjänsterna har åtkomst till tjänsterna och att tjänsterna endast tillåter utgående anslutningar, vilket uttryckligen krävs för replikering och programfunktioner. Överväg att använda Azure Private Link för ytterligare förbättrad kontroll och segmentering. Mer information om hur du skyddar webbprogram finns i Baslinje med hög tillgänglighet zonredundant webbapp.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Cachelagring Använd cachelagring för att minska belastningen på servrar som hanterar innehåll som inte ändras ofta. Varje återgivningscykel på en sida kan påverka kostnaden eftersom den förbrukar beräkning, minne och bandbredd. Dessa kostnader kan minskas avsevärt med hjälp av cachelagring, särskilt för statiska innehållstjänster, till exempel JavaScript-ensidesappar och medieströmningsinnehåll.

Om appen har statiskt innehåll använder du CDN för att minska belastningen på klientdelsservrarna. För data som inte ändras ofta använder du Azure Cache for Redis.

Tillståndslösa appar som har konfigurerats för automatisk skalning är mer kostnadseffektiva än tillståndskänsliga appar. För ett ASP.NET program som använder sessionstillstånd lagrar du det i minnet med Azure Cache for Redis. Mer information finns i ASP.NET Sessionstillståndsprovider för Azure Cache for Redis. Ett annat alternativ är att använda Azure Cosmos DB som ett serverdelstillståndsarkiv via en sessionstillståndsprovider. Se Använda Azure Cosmos DB som en ASP.NET sessionstillstånd och cachelagringsprovider.

Funktioner Överväg att placera en funktionsapp i en dedikerad App Service-plan så att bakgrundsaktiviteter inte körs på samma instanser som hanterar HTTP-begäranden. Om bakgrundsaktiviteter körs tillfälligt bör du överväga att använda en förbrukningsplan som faktureras baserat på antalet körningar och resurser som används i stället för varje timme.

Mer information finns i kostnadsavsnittet i Microsoft Azure Well-Architected Framework.

Använd priskalkylatorn för att beräkna kostnader. De här rekommendationerna i det här avsnittet kan hjälpa dig att minska kostnaderna.

Azure Front Door

Azure Front Door-faktureringen har tre prisnivåer: utgående dataöverföringar, inkommande dataöverföringar och routningsregler. Mer information finns i Priser för Azure Front Door. Prisdiagrammet inkluderar inte kostnaden för att komma åt data från ursprungstjänsterna och överföra till Front Door. Dessa kostnader debiteras baserat på dataöverföringsavgifter, som beskrivs i Prisinformation om bandbredd.

Azure Cosmos DB

Det finns två faktorer som avgör prissättningen för Azure Cosmos DB:

• Det etablerade dataflödet eller enheter för begäranden per sekund (RU/s).

  Det finns två typer av dataflöde som kan etableras i Azure Cosmos DB, standard och autoskalning. Standarddataflödet allokerar de resurser som krävs för att garantera de RU/s som du anger. För autoskalning etablerar du det maximala dataflödet, och Azure Cosmos DB skalas omedelbart upp eller ned beroende på belastningen, med minst 10 % av det maximala dataflödet för autoskalning. Standarddataflöde faktureras för det dataflöde som etableras varje timme. Autoskalningsdataflöde debiteras för det maximala dataflöde som förbrukas varje timme.

• Förbrukad lagring. Du debiteras en fast avgift för den totala mängden lagringsutrymme (GB) som förbrukas för data och indexen under en viss timme.

Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.

Prestandaeffektivitet

En stor fördel med Azure App Service är möjligheten att skala programmet baserat på belastning. Följande är några saker att tänka på när du planerar att skala programmet.

App Service-app

Om din lösning innehåller flera App Service-appar kan du överväga att distribuera dem till separata App Service-planer. Då körs de på separata instanser och kan skalas oberoende av varandra.

SQL Database

Öka skalbarheten för en SQL-databas genom att tillämpa sharding på databasen. Det innebär att tillämpa horisontell partitionering på databasen. Med horisontell partitionering kan du skala ut databasen horisontellt med Elastic Database-verktyg. Potentiella fördelar med horisontell partitionering:

• Bättre transaktionsdataflöde.
• Frågor kan köras snabbare i en delmängd av gällande data.

Azure Front Door

Front Door kan utföra SSL-avlastning och minskar också det totala antalet TCP-anslutningar med serverdelswebbappen. Detta förbättrar skalbarheten eftersom webbappen hanterar en mindre mängd SSL-handskakningar och TCP-anslutningar. Dessa prestandavinster gäller även om du vidarebefordrar begäranden till webbappen som HTTPS på grund av den höga nivån av återanvändning av anslutningar.

Azure Search

Med Azure Search elimineras arbetet med komplexa datasökningar från det primära datalagret. Dessutom kan den skalas för att hantera belastningen. Läs mer på sidan om att skala resursnivåer för fråge- och indexeringsarbetsbelastningar i Azure Search.

Driftsäkerhet

Driftskvalitet avser de driftsprocesser som distribuerar ett program och håller det igång i produktion och är en förlängning av vägledningen för välarkitekterat ramverkstillförlitlighet . Den här vägledningen ger en detaljerad översikt över hur du utformar återhämtning i ditt programramverk för att säkerställa att dina arbetsbelastningar är tillgängliga och kan återställas från fel i valfri skala. En grundläggande grundsats i den här metoden är att utforma din programinfrastruktur så att den är högtillgänglig, optimalt i flera geografiska regioner som den här designen illustrerar.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• Arvind Boggaram Pandurangaiah Setty | Senior konsult

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Djupdykning i Azure Front Door – trafikroutningsmetoder

• Skapa hälsoavsökningar som rapporterar programmets övergripande hälsotillstånd baserat på mönster för slutpunktsövervakning

• Aktivera automatiska redundansgrupper i Azure SQL

• Säkerställa affärskontinuitet och haveriberedskap med hjälp av azure-kopplade regioner

Relaterade resurser

• N-nivåprogram för flera regioner är ett liknande scenario. Den visar ett N-nivåprogram som körs i flera Azure-regioner

• Designprinciper för Azure-program