Utforma en geografiskt distribuerad arkitektur
Azure är ett globalt system. Genom att utforma en arkitektur som finns i mer än en Azure-region, kan vi skapa ett program som är motståndskraftigt mot haverier i hela regionen.
Din leveransspårningsportal är skalbar eftersom den innehåller flera Azure-resurser som kan skalas. Det är också motståndskraftigt mot många fel eftersom dess komponenter kan ha flera instanser. Styrelsen har dock blivit orolig för att en storskalig katastrof kan orsaka ett avbrott eftersom portalen är helt innesluten i Azure-regionen USA, östra. Du vill föreslå en modifierad arkitektur som kan redundansväxla till en annan region om regionen USA, östra inte fungerar.
Här lär vi oss hur du justerar programmets arkitektur för att stödja ett geografiskt distribuerat program. Vi ser också varför en sådan arkitektur är fördelaktig för affärskritiska program.
Ursprunglig arkitektur för webbapp
Nu ska vi ta en titt på hur spårningsportalens arkitekturdesign och de komponenter som används i lösningen. När vi har förstått hur vi använder alla delar kan vi undersöka hur vi kan stödja var och en av dessa komponenter i scenarier med geo-redundans.
Spårningsportalens design baseras på referensarkitekturen som visas i följande diagram.
Observera hur programmet använder en enda Azure-resursgrupp. Med den här resursgruppen kan vi gruppera och hantera alla våra resurser logiskt och förenkla hanteringen. Vi väljer att distribuera resursgruppen till regionen USA, östra. Även om resursgruppen inte begränsar oss till att använda samma Azure-region för de resurser som ingår, har vi beslutat att använda regionen USA, östra för alla resurser som distribueras i programmet.
Programmet använder tre kategorier av Azure-resurser. Nu ska vi ta en titt på varje kategori och se vilka resurser som används.
Nätverkskomponenter
Spårningsportalen använder följande nätverkstjänster.
| Tjänst | beskrivning |
|---|---|
| Azure DNS | Vi har konfigurerat att Azure DNS ska vara värd för våra DNS-poster i Azure. Med Azure DNS kan vi hantera våra DNS-poster med hjälp av våra Azure-autentiseringsuppgifter i Azure-portalen. |
| Application Gateway | Vi har konfigurerat lastbalanseraren i Application Gateway så att trafiken balanseras mellan flera instanser av webbklientdelen. Den här tjänsten finns i en Azure-region. |
| Azure CDN | Vi har konfigurerat att Azure CDN ska maximera leveransen av oskyddat statiskt innehåll, till exempel grafik för webbplatsen. Den här globala tjänsten cachelagrar statiskt innehåll vid närvaropunkter runt om i världen. |
Programkomponenter
I spårningsportalen används följande tjänster som stöd för kod, cache och mellanliggande lagringskrav.
| Tjänst | beskrivning |
|---|---|
| Microsoft Entra ID | Användare får åtkomst till spårningsportalen med hjälp av Microsoft Entra-konton. Katalogen och kontot replikeras globalt automatiskt. |
| Azure App Service | I spårningsportalen används två Azure App Services. Den första kör en uppsättning dynamiska webbsidor och den andra en webb-API. |
| Azure-funktionsappar | Spårningsportalen använder Azure-funktionsappar till att köra alla bakgrundsaktiviteter. Några av dessa aktiviteter körs enligt ett regelbundet schema, och andra aktiviteter används för meddelandena i en kö. |
| Azure Storage-köer | Spårningsportalen använder Azure Storage-köer med Azure Function Apps. Spårningsportalen placerar genererade meddelanden i kön och funktionsapparna bearbetar dessa meddelanden. |
| Redis-cache | Spårningsportalen använder en Redis-cache mellan klientdelens apptjänst och datalagringssystemen för att maximera frågeprestandan. |
| Azure Blob Storage | Statiskt innehåll, till exempel grafik- och videofiler, behålls som binära stora objekt (blobar) i ett Azure Storage-konto och levereras via Azure CDN. |
| Azure Search | Vi har aktiverat Azure Search i spårningsportalen. Med Azure Search kan vi göra allt innehåll sökbart och ge sökförslag och fuzzy-sökresultat till våra användare. |
Datalagringskomponenter
Spårningsportalen använder följande bevarade lagringstjänster.
| Tjänst | beskrivning |
|---|---|
| Azure SQL Database | Vi lagrar relationsdata, till exempel order- och kundinformation i Azure SQL Database. |
| Cosmos DB | Vi lagrar halvstrukturerade data, inklusive vår produktkatalog, i Cosmos DB. |
Problem med den ursprungliga arkitekturen
Den befintliga arkitekturen för spårningsportalen är utformad för skalbarhet och tillgänglighet.
Om efterfrågan till exempel är hög och svaren på användarwebbbegäranden är långsamma kan du överväga att lägga till fler instanser av klientwebbappen i App Service. Här kan Application Gateway dirigera förfrågningarna till de nyligen skapade instanserna.
Det finns dock scenarier där vår arkitekturdesign har utmaningar att övervinna, eller till och med misslyckas. Låt oss ta en titt på de olika scenarierna för att få en bättre förståelse för vilken inverkan de har på spårningsportalen.
Regionala fel
Vissa stora händelser kan orsaka avbrott i en hel Azure-region. Azure-datacenter är utformade för att vara mycket motståndskraftiga, men en massiv väderhändelse, till exempel en orkan eller översvämning, kan störa tjänsten från regionen.
Dessa händelser är ovanliga och många företag tycker att de kan godta denna risk. Konsekvenserna vid ett regionalt haveri som slår ut spårningsportalen är dock så stora att företagets ledningsgrupp har valt att eliminera risken.
Servicenivåavtal
De flesta Azure-tjänster erbjuder ett serviceavtal (SLA) eller en driftstidsgaranti. När vi utformar en programarkitektur som består av flera Azure-tjänster, beräknar vi det övergripande serviceavtalet för appen som en sammanslagning av serviceavtalen för alla tjänsterna.
Du kan beräkna detta serviceavtal genom att multiplicera serviceavtalen för komponenttjänsterna. Anta till exempel att vår app består av Azure App Service (99,95 % serviceavtal) och Microsoft Entra-ID (99,9 % serviceavtal). Det slutgiltiga beräknade serviceavtalet är 99,85 %.
Om drifttidsprocenten inte är tillräcklig för programmet, kan vi se till att programmet redundansväxlas till en annan region.
Globala, regionala och konfigurerbara komponenter
I vår design är vissa komponenter globala som standard och de är därmed inte sårbara för ett regionalt haveri.
Vissa komponenter är begränsade till en enda region, till exempel Application Gateway. Vi måste välja en alternativ tjänst för dessa typer av komponenter.
Vissa komponenter kan konfigureras att ge stöd för flera regioner. Vi kan till exempel använda alternativet geo-redundant lagring (GRS) för det Azure Storage-konto som lagrar statiskt innehåll. GRS replikerar blobbar till en annan region.
I följande tabell visas vilka komponenter som är globala, regionala och konfigurerbara.
| Komponent | Stöd för flera regioner | Kommentarer |
|---|---|---|
| Azure DNS | Global | Inga ändringar krävs. |
| Application Gateway | Regional | Varje instans av Application Gateway finns i en enda region. |
| Azure CDN | Global | Inga ändringar krävs, innehållet cachelagras globalt som standard. |
| Microsoft Entra-ID | Global | Inga ändringar krävs. |
| Azure App Service | Regional | Varje instans av appen finns i en enda region. |
| Azure-funktionsappar | Regional | Varje instans av funktionsappen finns i en enda region. |
| Azure Storage-köer | Konfigureringsbart | Du kan välja att replikera ett Azure Storage-konto till flera regioner. |
| Azure Redis Cache | Regional | Varje instans av cachen finns i en enda region. |
| Azure Blob Storage | Konfigureringsbart | Du kan välja att replikera ett Azure Storage-konto till flera regioner. |
| Azure Search | Regional | Varje instans av söktjänsten finns i en enda region. |
| Azure SQL Database | Konfigureringsbart | Du kan använda geo-replikering för att synkronisera data till flera regioner. |
| Azure Cosmos DB | Konfigureringsbart | Du kan använda geo-replikering för att synkronisera data till flera regioner. |
Föreslagen distribuerad arkitektur
Efter en undersökning föreslår du arkitekturen enligt följande diagram.
I den här designen finns det en aktiv region (USA, östra) och en reservregion (USA, västra). Regionen USA, östra hanterar alla förfrågningar från komponenterna under normala förhållanden. Om ett haveri orsakar ett regionalt fel redundansväxlar programmet till regionen USA, västra.
Nu ska vi övergripande titta på hur du har ändrat den ursprungliga arkitekturen. Vi utforskar dessa ändringar mer detaljerat i senare enheter.
Nätverk
Azure DNS och Azure CDN är som standard globala system och redan motståndskraftiga mot regionala haverier. Vi lämnar dem på plats.
När vi skapar en Azure Application Gateway tilldelar vi tjänsten till en enda region. Vi tar bort den här säkerhetsrisken genom att ersätta den här tjänsten med Azure Front Door. Front Door kan avsöka flera App Services och hantera App Service-redundans från regionen USA, östra till regionen USA, västra.
Programtjänster
Microsoft Entra ID är ett globalt system och behöver inte ändras.
Azure Storage-konton kan konfigureras för att replikera innehåll till flera regioner. Vi använder ett av de geo-redundanta lagringsalternativen för att ändra konfigurationen.
De andra komponenterna, som innefattar App Service, funktionsappar, Redis-cache och Azure Search, är regionala. Vi skapar dubbletter av dessa komponenter i regionen USA, västra i vår nya arkitekturdesign. I den här designen kan den nya regionen ta över om en redundans inträffar.
Datalagring
Azure SQL Database och Azure Cosmos DB har båda stöd för geo-replikering av data till andra regioner. Vi konfigurerar dessa tjänster för att replikera data från USA, östra till motsvarande tjänster i USA, västra.
Regionala par
En Azure-region är ett område med en enda geografi som innehåller ett eller flera Azure-datacenter. Alla regioner har par i andra regioner i samma geografi. Inom dessa par görs uppdateringar och planerat underhåll endast för en region i taget. Om det uppstår ett fel som påverkar flera regioner, prioriteras minst en region i varje par för att få en snabb återställning.
Vi rekommenderar att man placerar en arkitektur med två regioner för appen i de två regionerna i ett regionalt par. Exempelvis paras USA, östra ihop med USA, västra. Vår föreslagna design använder USA, östra för sin aktiva region och USA, västra för sin väntelägesregion.