Övning – Utöka designen till flera regioner
Contoso Shoes behöver ett sätt att klara regionala avbrott. Du vill distribuera den aktuella stämpeln till en aktiv-aktiv, delad tillstånds- och topologi för flera regioner. Arkitekturen måste utformas för att omdirigera trafik till en annan region om en region misslyckas.
Aktuellt tillstånd och problem
En enda region har varit tillräcklig för programmet. Ett regionalt avbrott nyligen som påverkade nätverken gjorde dock att systemet gick offline ur ett slutanvändarperspektiv. Horisontell skalning i regionen – eller till och med distribution av en ny stämpel i regionen – skulle inte ha återställt programmet från det misslyckade tillståndet.
DNS innehas av en befintlig registrator för api.contososhoes.com. DNS-posten matchas mot serverdelens App Services-slutpunkt (apicontososhoes.azurewebsites.net) med en TTL-period (time-to-live) på två dagar. När lösningen distribueras till flera regioner måste DNS migreras.
Specifikation
- Utöka arkitekturen så att den fungerar i en aktiv-aktiv topologi med flera regioner.
- Ändra distributionsstämpelmodellen som gör att du dynamiskt kan lägga till och ta bort regioner efter behov i stället för en lista över hårdkodade resurser i två regioner.
- Om det uppstår ett regionalt fel måste trafiken dirigeras till den icke-felade regionen utan någon märkbar inverkan på klienter som redan finns i den icke-felade regionen.
- Klienter ska inte fästas på en region.
- Klienter bör inte behöva ändra URL:er för att kontakta API:et. DNS ska migreras till den globala routern.
Rekommenderad metod
För att komma igång med din design rekommenderar vi att du följer dessa steg:
1–Topologi för flera regioner
Arkitekturen måste distribueras till två eller flera Azure-regioner för att skydda mot regionala avbrott. Tänk på dessa faktorer när du väljer en region:
- Regionen måste kunna hantera datacenterstopp i den regionen.
- Azure-tjänsterna och de funktioner som används i arkitekturen måste stödjas i regionen.
- Regionen och resurserna som distribueras i regionen måste ha närhet till slutanvändarna och beroende system för att minimera nätverksfördröjningen.
Tänk igenom ett felscenario. Anta att Region 1 får 75 % av trafiken och att din nyligen tillagda Region 2 får den återstående trafiken. Båda skalas på rätt sätt för att hantera den belastningen. Det finns ett regionalt avbrott i region 1 och all trafik dirigeras nu till region 2. Kan du göra övergången smidig? Kan Region 2 stödja den ökade trafikbelastningen?
Kontrollera förloppet: Global distribution
2 – Global routning
För att klienterna ska kunna dirigeras transparent till någon av arbetsregionerna lägger du till en global lastbalanserare. Lastbalanseraren bör använda hälsokontrollerna som du lade till i föregående övning för att avgöra om en stämpel är felfri. Kan du komma på sätt att hantera frekventa och liknande begäranden som kan uppfyllas utan att nå serverdelen?
- Välj en intern Azure-tjänst som integreras med den befintliga arkitekturen och som snabbt kan redundansväxla.
- Kontrollera att nätverkets ingresssökväg har kontroller för att neka obehörig trafik.
- Minimera nätverksfördröjningen genom att betjäna slutanvändare från en edge-cache.
- Migrera befintlig DNS utan att påverka befintliga klienter.
- Ha ett automatiserat sätt att ange ett regionalt fel för att säkerställa att trafiken inte dirigeras till den felade regionen. Få också ett meddelande när regionen är tillgänglig igen så att lastbalanseraren kan återuppta routningen till den regionen.
Kontrollera förloppet: Global trafikroutning
3 – Ändringar i distributionsstämpeln
Det idealiska tillståndet är en aktiv-aktiv konfiguration som inte kräver manuell redundans och klientbegäranden kan hanteras från vilken region som helst. Tänk på vad det innebär för din arkitektur. Har du till exempel något tillstånd som lagras i den regionala stämpeln?
Vissa tjänster i den aktuella arkitekturen har geo-replikeringsfunktioner. Överväg att separera tjänsterna i olika stämplar: en stämpel som innehåller globala resurser och en annan regional stämpel som delar resurser med den globala stämpeln. En av de avgörande faktorerna bör vara livscykeln för dessa resurser. Vad är den förväntade livslängden för resursen i förhållande till andra resurser i arkitekturen? Ska resursen överleva eller dela livslängden med hela systemet eller regionen, eller ska den vara tillfällig?
Utforska tillförlitlighetsfunktionerna i De Azure-tjänster som används i arkitekturen. Du kan börja med de här funktionerna och utforska ytterligare för att maximera tillförlitligheten.
| Azure-tjänst | Funktion |
|---|---|
| Azure Cosmos DB | Skrivning i flera regioner |
| Azure Container Registry | Geo-replikering |
| Azure App Service-plan | Stöd för tillgänglighetszon |
Kontrollera förloppet: Programplattformens | dataplattform
Kontrollera ditt arbete
Här är alternativen för program- och datadesign för en liknande arkitektur. Tog du upp alla aspekter i din design?
- Vilken annan Azure-region valde du för topologin för flera regioner och varför?
- Har du aktiverat två eller flera Azure-Tillgänglighetszoner i varje Azure-region för att skydda mot datacenterfel?
- Tog du med brandväggen för webbaserade program för att styra inkommande trafik? Vilka routningsregler har du infört och varför?
- Hur stöder lastbalanseraren din befintliga DNS-post?
- Hur använde du api:et för hälsokontroll från föregående övning?
- Har du skyddat programmet från DDoS-attacker, särskilt för att förhindra att skadliga klienter kringgår lastbalanseraren och når regionala instanser?
- Hur närmade du dig DNS-migrering?
- Har du gjort några SKU-ändringar i den befintliga komponenten för att stödja topologi för flera regioner?
- Vilka Azure-tjänster lämnade du som singletons? Hur har du motiverat ditt val för varje tjänst? Har du gjort några konfigurationsändringar?
- Loggar du resurser? Tror du att det påverkar din möjlighet att inspektera loggarna för det övergripande systemet?