Rekommendationer för användning av tillgänglighetszoner och regioner

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:05 Lägg till redundans på olika nivåer, särskilt för kritiska flöden. Tillämpa redundans på beräknings-, data-, nätverks- och andra infrastrukturnivåer i enlighet med de identifierade tillförlitlighetsmålen.

Relaterade guider:Flerregionaldesignredundans | med hög tillgänglighet

Den här guiden beskriver rekommendationerna för att avgöra när arbetsbelastningar ska distribueras mellan tillgänglighetszoner eller regioner.

När du utformar en lösning för Azure måste du bestämma om du ska distribuera över flera tillgänglighetszoner i en region eller distribuera till flera regioner. Det här beslutet påverkar lösningens tillförlitlighet, kostnad och prestanda samt teamets förmåga att driva lösningen. Den här guiden innehåller information om viktiga affärskrav som påverkar ditt beslut, vilka metoder du kan tänka på, vilka kompromisser som ingår i varje metod och effekten av varje metod på grundpelarna i Azure Well-Architected Framework.

Beslutet om de bästa Azure-regionerna att använda för din lösning är ett viktigt val. Guiden Välj Azure-regioner beskriver hur du väljer och arbetar i flera geografiska regioner. Ditt val av hur du använder regioner och tillgänglighetszoner i din lösning påverkar också flera av grundpelarna i Well-Architected Framework:

  • Tillförlitlighet: Ditt val av distributionsmetod kan hjälpa dig att minimera olika typer av risker. Genom att sprida din arbetsbelastning över ett mer geografiskt distribuerat område kan du i allmänhet uppnå högre återhämtning.
  • Kostnadsoptimering: Vissa arkitekturmetoder kräver att du distribuerar fler resurser än andra, vilket kan öka dina resurskostnader. Andra metoder är att skicka data mellan geografiskt avgränsade tillgänglighetszoner eller regioner, vilket kan medföra avgifter för nätverkstrafik. Det är också viktigt att tänka på den löpande kostnaden för att hantera dina resurser, vilket vanligtvis är högre när du har omfattande affärskrav.
  • Prestandaeffektivitet: Tillgänglighetszoner ansluts tillsammans via en nätverkslänk med hög bandbredd och låg svarstid, vilket är tillräckligt för att de flesta arbetsbelastningar ska kunna aktivera synkron replikering och kommunikation mellan zonerna. Men om din arbetsbelastning har testats och är känslig för nätverksfördröjning mellan zoner kan du behöva överväga att fysiskt lokalisera arbetsbelastningens komponenter nära varandra för att minimera svarstiden när de kommunicerar.
  • Operational Excellence: En komplex arkitektur kräver mer arbete för att distribuera, konfigurera och hantera. För en lösning med hög tillgänglighet kan du dessutom behöva planera hur du redundansväxlar till en sekundär uppsättning resurser. Redundansväxling, återställning efter fel och transparent omdirigering av trafiken kan vara komplicerat, särskilt när manuella steg krävs. Det är en bra idé att automatisera dina distributions- och hanteringsprocesser. Mer information finns i grundguiderna för operational excellence, inklusive OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design och OE:11 Deployment practices (OE:09-uppgiftsautomatisering), OE:10 Automation-design och OE:11-distributionsmetoder.

Hur du utformar din lösning gäller säkerhetspelare. Vanligtvis ändrar inte beslut om huruvida och hur du använder tillgänglighetszoner och regioner din säkerhetsstatus. Azure tillämpar samma säkerhetstrygghet på varje region och tillgänglighetszon.

Tips

För många produktionsarbetsbelastningar ger en zonredundant distribution den bästa balansen mellan kompromisser. Du kan utöka den här metoden med asynkron säkerhetskopiering av data till en annan region. Om du inte är säker på vilken metod du ska välja börjar du med den här typen av distribution.

Överväg andra arbetsbelastningsmetoder när du behöver de specifika fördelar som dessa metoder ger, men var medveten om de kompromisser som ingår.

Definitioner

Period Definition
Aktiv-aktiv En arkitektur där flera instanser av en lösning aktivt bearbetar begäranden samtidigt.
Aktiv-passiv En arkitektur där en instans av en lösning anges som primär och bearbetar trafik, och en eller flera sekundära instanser distribueras för att hantera trafik om den primära är otillgänglig.
Asynkron replikering En datareplikeringsmetod där data skrivs och checkas in på en plats. Vid ett senare tillfälle replikeras ändringarna till en annan plats.
Tillgänglighetszon En avgränsad grupp datacenter i en region. Varje tillgänglighetszon är oberoende av de andra, med sin egen infrastruktur för ström, kylning och nätverk. Många regioner stöder tillgänglighetszoner.
Datacenter En anläggning som innehåller servrar, nätverksutrustning och annan maskinvara för att stödja Azure-resurser och arbetsbelastningar.
Lokalt redundant distribution En distributionsmodell där en resurs distribueras till en enda region utan referens till en tillgänglighetszon. I en region som stöder tillgänglighetszoner kan resursen distribueras i någon av regionens tillgänglighetszoner.
Distribution i flera regioner En distributionsmodell där resurser distribueras till flera Azure-regioner.
Länkade regioner En relation mellan två Azure-regioner. Vissa Azure-regioner är anslutna till en annan definierad region för att aktivera specifika typer av lösningar i flera regioner. Nyare Azure-regioner är inte kopplade.
Region En geografisk perimeter som innehåller en uppsättning datacenter.
Regionarkitektur Den specifika konfigurationen av Azure-regionen, inklusive antalet tillgänglighetszoner och om regionen är kopplad till en annan region.
Synkron replikering En datareplikeringsmetod där data skrivs och checkas in på flera platser. Varje plats måste bekräfta slutförandet av skrivåtgärden innan den övergripande skrivåtgärden anses vara slutförd.
Zonindelad (fäst) distribution En distributionsmodell där en resurs distribueras till en specifik tillgänglighetszon.
Zonredundant distribution En distributionsmodell där en resurs distribueras över flera tillgänglighetszoner. Microsoft hanterar datasynkronisering, trafikdistribution och redundans om en zon upplever ett avbrott.

Viktiga designstrategier

Azure har ett stort globalt fotavtryck. En Azure-region är en geografisk perimeter som innehåller en uppsättning datacenter. Du måste ha en fullständig förståelse för Azure-regioner och tillgänglighetszoner.

Azure-regioner har en mängd olika konfigurationer, som även kallas regionsarkitekturer.

Många Azure-regioner tillhandahåller tillgänglighetszoner, som är avgränsade grupper av datacenter. I en region är tillgänglighetszonerna tillräckligt nära för att ha anslutningar med låg latens till andra tillgänglighetszoner, men de är tillräckligt långt ifrån varandra för att minska sannolikheten för att fler än ett kommer att påverkas av lokala avbrott eller väder. Tillgänglighetszoner har oberoende infrastruktur för ström, kylning och nätverk. De är utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av återstående zoner om en zon drabbas av ett avbrott.

Följande diagram visar flera exempel på Azure-regioner. Regioner 1 och 2 stöder tillgänglighetszoner.

Diagram som visar datacenter, tillgänglighetszoner och regioner.

Om du distribuerar till en Azure-region som innehåller tillgänglighetszoner kan du använda flera tillgänglighetszoner tillsammans. Genom att använda flera tillgänglighetszoner kan du behålla separata kopior av ditt program och dina data i separata fysiska datacenter i ett stort storstadsområde.

Det finns två sätt att använda tillgänglighetszoner i en lösning:

  • Zonresurser fästs på en specifik tillgänglighetszon. Du kan kombinera flera zonindelade distributioner mellan olika zoner för att uppfylla höga tillförlitlighetskrav. Du ansvarar för att hantera datareplikering och distribuera begäranden mellan zoner. Om ett avbrott inträffar i en enda tillgänglighetszon ansvarar du för redundansväxling till en annan tillgänglighetszon.
  • Zonredundanta resurser sprids över flera tillgänglighetszoner. Microsoft hanterar spridning av begäranden mellan zoner och replikering av data mellan zoner. Om ett avbrott inträffar i en enda tillgänglighetszon hanterar Microsoft redundans automatiskt.

Azure-tjänster stöder en eller båda dessa metoder. PaaS-tjänster (Plattform som en tjänst) stöder vanligtvis zonredundanta distributioner. IaaS-tjänster (Infrastruktur som en tjänst) stöder vanligtvis zonindelade distributioner. Mer information om hur Azure-tjänster fungerar med tillgänglighetszoner finns i Azure-tjänster med stöd för tillgänglighetszoner.

När Microsoft distribuerar uppdateringar av tjänster försöker vi använda metoder som är minst störande för dig. Vi strävar till exempel efter att distribuera uppdateringar till en enda tillgänglighetszon i taget. Den här metoden kan minska den inverkan som uppdateringar kan ha på en aktiv arbetsbelastning, eftersom arbetsbelastningen kan fortsätta att köras i andra zoner medan uppdateringen pågår. I slutändan är det dock arbetsbelastningsteamets ansvar att se till att deras arbetsbelastning fortsätter att fungera under plattformsuppgraderingar. När du till exempel använder VM-skalningsuppsättningar med flexibelt orkestreringsläge eller de flesta Azure PaaS-tjänster placerar Azure intelligent dina resurser för att minska effekten av plattformsuppdateringar. Dessutom kan du överväga överetablering – distribuera fler instanser av en resurs – så att vissa instanser förblir tillgängliga medan andra instanser uppgraderas. Mer information om hur Azure distribuerar uppdateringar finns i Avancerade säkra distributionsmetoder.

Många regioner har också en länkad region. Länkade regioner stöder vissa typer av distributionsmetoder för flera regioner. Vissa nyare regioner har flera tillgänglighetszoner och har ingen länkad region. Du kan fortfarande distribuera lösningar för flera regioner till dessa regioner, men de metoder som du använder kan vara olika.

Mer information om hur Azure använder regioner och tillgänglighetszoner finns i Vad är Azure-regioner och tillgänglighetszoner?

Förstå delade ansvarsområden

Principen om delat ansvar beskriver hur ansvarsområden fördelas mellan molnleverantören (Microsoft) och dig. Beroende på vilken typ av tjänster du använder kan du ta på dig mer eller mindre ansvar för att driva tjänsten.

Microsoft tillhandahåller tillgänglighetszoner och regioner för att ge dig flexibilitet i hur du utformar din lösning för att uppfylla dina krav. När du använder hanterade tjänster tar Microsoft på sig mer av hanteringsansvaret för dina resurser, vilket till och med kan omfatta datareplikering, redundans, återställning efter fel och andra uppgifter som rör driften av ett distribuerat system.

Din egen kod behöver rekommenderade metoder och designmönster för att hantera fel på ett smidigt sätt. Dessa metoder är ännu viktigare vid redundansväxling, till exempel sådana som inträffar när en tillgänglighetszon eller regionredundans inträffar, eftersom redundansväxling mellan zoner eller regioner vanligtvis kräver att programmet försöker ansluta igen till tjänster.

Identifiera viktiga affärs- och arbetsbelastningskrav

Om du vill fatta ett välgrundat beslut om hur du använder tillgänglighetszoner och regioner i din lösning måste du förstå dina krav. Dessa krav bör drivas av diskussioner mellan lösningsdesigners och affärsintressenter.

Risktolerans

Olika organisationer har olika grader av risktolerans. Även inom en organisation är risktoleransen ofta olika för varje arbetsbelastning. De flesta arbetsbelastningar behöver inte extremt hög tillgänglighet. Vissa arbetsbelastningar är dock så viktiga att det till och med är värt att minimera risker som sannolikt inte kommer att inträffa, till exempel större naturkatastrofer som påverkar ett brett geografiskt område.

Den här tabellen innehåller några av de vanliga risker som du bör tänka på i en molnmiljö:

Risk Exempel Sannolikheten
Maskinvarustopp Problem med hårddisk eller nätverksutrustning.

Värdomstarter.		 Hög. Alla återhämtningsstrategier bör ta hänsyn till dessa risker.
Avbrott i datacenter Ström-, kylnings- eller nätverksfel i ett helt datacenter.

Naturkatastrof i en del av ett storstadsområde.		 Medel
Regionstopp En stor naturkatastrof som påverkar ett stort geografiskt område.

Nätverk eller tjänstproblem som gör en eller flera Azure-tjänster otillgängliga i en hel region.		 Låg

Det skulle vara idealiskt att minimera alla möjliga risker för varje arbetsbelastning, men det är inte praktiskt eller kostnadseffektivt att göra det. Det är viktigt att ha en öppen diskussion med företagets intressenter så att du kan fatta välgrundade beslut om de risker som du bör minska.

Tips

Oavsett tillförlitlighetsmål måste alla arbetsbelastningar ha viss riskreducering för haveriberedskap. Om din arbetsbelastning kräver höga tillförlitlighetsmål bör dina riskreduceringsstrategier vara omfattande och du bör minska risken för även händelser med låg sannolikhet. För andra arbetsbelastningar ska du fatta ett välgrundat beslut om vilka risker du är beredd att acceptera och vilka du behöver åtgärda.

Återhämtningskrav

Det är viktigt att förstå återhämtningskraven för din arbetsbelastning, inklusive mål för återställningstid (RTO) och mål för återställningspunkt (RPO). Dessa mål hjälper dig att avgöra vilka metoder som ska uteslutas. Om du inte har några tydliga krav kan du inte fatta ett välgrundat beslut om vilken metod du ska följa. Mer information finns i Målfunktionella och icke-funktionella krav.

Servicenivåmål

Du bör förstå lösningens förväntade servicenivåmål för drifttid (SLO). Du kan till exempel ha ett affärskrav som din lösning behöver för att uppfylla 99,9 % drifttid.

Azure tillhandahåller serviceavtal (SLA) för varje tjänst. Ett serviceavtal anger den drifttid du bör förvänta dig av tjänsten och de villkor som du behöver uppfylla för att uppnå det förväntade serviceavtalet. Kom dock ihåg att det sätt som ett Azure-serviceavtal anger tjänstens tillgänglighet inte alltid överensstämmer med ditt sätt att tänka på hälsotillståndet för din arbetsbelastning.

Dina arkitekturbeslut påverkar lösningens sammansatta servicenivåmål. I allmänhet, ju mer redundans du skapar i din lösning, desto högre är ditt servicenivåmål sannolikt. Många Azure-tjänster ger högre serviceavtal när du distribuerar tjänster i en zonredundant konfiguration eller konfiguration i flera regioner. Granska serviceavtalen för var och en av de Azure-tjänster som du använder för att se till att du förstår hur du maximerar tjänstens återhämtning och serviceavtal.

Dataplacering

Vissa organisationer begränsar de fysiska platser där deras data kan lagras och bearbetas. Ibland baseras dessa krav på juridiska eller regelmässiga standarder. I andra situationer kan en organisation besluta att anta en policy för datahemvist för att undvika kundproblem. Om du har strikta krav på datahemvist kan du behöva använda en distribution i en enda region eller använda en delmängd av Azure-regioner och -tjänster.

Anteckning

Undvik att göra ogrundade antaganden om dina krav på datahemvist. Om du behöver följa specifika regler kontrollerar du vad dessa standarder faktiskt anger.

Användarplats

Genom att förstå var användarna finns kan du fatta ett välgrundat beslut om hur du optimerar svarstiden och tillförlitligheten för dina behov. Azure har många alternativ för att stödja en geografiskt spridda användarbas.

Om användarna är koncentrerade till ett område kan en distribution i en region förenkla dina driftskrav och minska kostnaderna. Du måste dock överväga om en distribution i en enda region uppfyller dina tillförlitlighetskrav. För verksamhetskritiska program bör du fortfarande använda en distribution i flera regioner även om användarna är samlokaliserade.

Om användarna är geografiskt spridda kan det vara bra att distribuera din arbetsbelastning över flera regioner. Azure-tjänster har olika funktioner för att stödja en distribution i flera regioner, och du kan använda Azures globala fotavtryck för att förbättra användarupplevelsen och föra dina program närmare din användarbas. Du kan använda mönstret Distributionsstämplar eller Geodes-mönstret eller replikera dina resurser över flera regioner.

Även om användarna befinner sig i olika geografiska områden bör du överväga om du behöver en distribution i flera regioner. Överväg om du kan uppnå dina krav inom en enda region med hjälp av global trafikacceleration, till exempel accelerationen som tillhandahålls av Azure Front Door.

Budget

Om du arbetar med en begränsad budget är det viktigt att tänka på kostnaderna för att distribuera redundanta arbetsbelastningskomponenter. Dessa kostnader kan omfatta ytterligare resursavgifter, nätverkskostnader och driftskostnader för att hantera fler resurser och en mer komplex miljö.

Komplexitet

Det är en bra idé att undvika onödig komplexitet i din lösningsarkitektur. Ju mer komplexitet du introducerar, desto svårare blir det att fatta beslut om din arkitektur. Komplexa arkitekturer är svårare att använda, svårare att skydda och ofta mindre högpresterande. Följ enkelhetsprincipen.

Azure-underlättande

Genom att tillhandahålla regioner och tillgänglighetszoner kan du med Azure välja en distributionsmetod som passar dina behov. Det finns många metoder som du kan välja mellan, som var och en ger fördelar och medför kostnader.

Om du vill illustrera de distributionsmetoder som du kan använda kan du överväga ett exempelscenario. Anta att du funderar på att distribuera en ny lösning som innehåller ett program som skriver data till någon form av lagring:

Diagram som visar en användare som ansluter till ett program som ansluter till lagringen.

Det här exemplet är inte specifikt för några specifika Azure-tjänster. Det är avsett att vara ett enkelt exempel för att illustrera grundläggande begrepp.

Det finns flera sätt att distribuera den här lösningen. Varje metod ger olika fördelar och medför olika kostnader. På hög nivå kan du överväga en lokalt redundant, zonindelad (fäst), zonredundant eller distribution i flera regioner . I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Lokalt redundant Zonindelad (fäst) Zonredundant Flera regioner
Tillförlitlighet Låg tillförlitlighet Beror på metod Hög eller mycket hög tillförlitlighet Hög eller mycket hög tillförlitlighet
Kostnadsoptimering Låg kostnad Beror på metod Måttlig kostnad Höga kostnader
Prestandaeffektivitet Acceptabel prestanda (för de flesta arbetsbelastningar) Höga prestanda Acceptabel prestanda (för de flesta arbetsbelastningar) Beror på metod
Driftseffektivitet Låga driftskrav Höga driftskrav Låga driftskrav Höga driftskrav

Den här tabellen sammanfattar några av de metoder som du kan använda och hur de påverkar din arkitektur:

Arkitekturproblem Lokalt redundant Zonindelad (fäst) Zonredundant Flera regioner
Efterlevnad av datahemvist Högt Högt Högt Beror på region
Regional tillgänglighet Alla regioner Regioner med tillgänglighetszoner Regioner med tillgänglighetszoner Beror på region

I resten av den här artikeln beskrivs var och en av de metoder som anges i föregående tabell. Listan över metoder är inte fullständig. Du kan välja att kombinera flera metoder eller använda olika metoder i olika delar av lösningen.

Distributionsmetod 1: Lokalt redundanta distributioner

Om du inte anger flera tillgänglighetszoner eller regioner när du distribuerar dina resurser ger Azure inga garantier om huruvida resurserna distribueras till ett enda datacenter eller delas upp i flera datacenter i regionen. I vissa situationer kan Azure också flytta resursen mellan tillgänglighetszoner.

Diagram som visar den lösning som distribuerats till ett enda datacenter i en enda tillgänglighetszon.

De flesta Azure-resurser är högtillgängliga som standard, med höga serviceavtal och inbyggd redundans i ett datacenter som hanteras av plattformen. Men ur ett tillförlitlighetsperspektiv finns det en risk att din arbetsbelastning påverkas om någon del av regionen drabbas av ett avbrott. I så fall kan din lösning vara otillgänglig eller så kan dina data gå förlorade.

För mycket latenskänsliga arbetsbelastningar kan den här metoden också resultera i lägre prestanda. Arbetsbelastningskomponenterna kanske inte är samlokaliserade i samma datacenter, så du kan observera viss svarstid för trafik inom regionen. Azure kan också transparent flytta dina tjänstinstanser mellan tillgänglighetszoner, vilket kan påverka prestandan något. Detta är dock inte ett problem för de flesta arbetsbelastningar.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet Låg tillförlitlighet. Tjänster drabbas av avbrott om ett datacenter misslyckas. Du kan dock skapa ett program som är motståndskraftigt mot andra typer av fel.
Kostnadsoptimering Lägsta kostnad. Du behöver bara ha en enda instans av varje resurs och du debiteras inga bandbreddskostnader mellan zoner eller mellan regioner.
Prestandaeffektivitet För de flesta arbetsbelastningar:Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket latenskänsliga arbetsbelastningar:Låga prestanda. Komponenter är inte garanterade att finnas i samma tillgänglighetszon, så du kan se lägre prestanda för mycket latenskänsliga komponenter.
Driftseffektivitet Hög driftseffektivitet. Du behöver bara distribuera och hantera en enda instans av varje resurs.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Hög. När du distribuerar en lösning som använder den här metoden lagras data i den Azure-region som du väljer.
Regional tillgänglighet Hög. Den här metoden kan användas i valfri Azure-region.

Lokalt redundanta distributioner med säkerhetskopiering mellan regioner

Du kan utöka en lokalt redundant distribution genom att utföra regelbundna säkerhetskopior av infrastrukturen och data till en sekundär region. Den här metoden lägger till ett extra skyddslager för att minimera ett avbrott i din primära region. Så här ser det ut:

Diagram som visar den lösning som distribuerats till ett enda datacenter med säkerhetskopior i en annan region.

När du implementerar den här metoden måste du noggrant överväga din RTO och RPO:

  • Återställningstid: Om ett regionalt avbrott inträffar kan du behöva återskapa lösningen i en annan Azure-region, vilket påverkar återställningstiden. Överväg att skapa din lösning med hjälp av en IaC-metod (infrastruktur som kod) så att du snabbt kan distribuera om till en annan region om en större katastrof inträffar. Se till att dina distributionsverktyg och processer är lika motståndskraftiga som dina program så att du kan använda dem för att distribuera om din lösning även om det uppstår ett avbrott. Planera för och repetera de steg som krävs för att återställa lösningen till ett fungerande tillstånd.
  • Återställningspunkt: Säkerhetskopieringsfrekvensen avgör hur mycket dataförlust du kan uppleva (återställningspunkten). Du kan vanligtvis styra frekvensen för säkerhetskopior så att du kan uppfylla ditt RPO.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet Måttlig tillförlitlighet. Tjänster drabbas av avbrott om ett datacenter misslyckas. Data säkerhetskopieras asynkront till en geografiskt avgränsad region, vilket minskar effekten av ett fullständigt regionavbrott genom att minimera dataförlusten. I ett fullständigt regionstopp kan du manuellt återställa åtgärder till en annan region. Återställningsprocesser kan dock vara komplexa och det kan ta tid att återställa till den andra regionen manuellt.
Kostnadsoptimering Låg kostnad. Vanligtvis kostar det bara något mer att lägga till en säkerhetskopia till en annan region än att distribuera en lokalt redundant resurs.
Prestandaeffektivitet För de flesta arbetsbelastningar:Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket latenskänsliga arbetsbelastningar:Låga prestanda. Komponenter är inte garanterade att finnas i samma tillgänglighetszon, så du kan se lägre prestanda för mycket latenskänsliga komponenter.
Driftseffektivitet Vid avbrott i en region:Låg driftseffektivitet. Redundans är ditt ansvar och kan kräva manuella åtgärder och omdistributioner.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Beror på valet av region. Data lagras främst i den Azure-region som du anger. Du måste dock välja en annan region för att lagra dina säkerhetskopior, så det är viktigt att du väljer en region som är kompatibel med dina krav för datahemvist.
Regional tillgänglighet Hög. Du kan använda den här metoden i valfri Azure-region.

Distributionsmetod 2: Zonindelat (fäst) distributioner

I en zonindelad distribution anger du att dina resurser ska distribueras till en specifik tillgänglighetszon. Den här metoden kallas ibland för en zonfäst distribution.

Diagram som visar den lösning som distribuerats till en specifik tillgänglighetszon. En zonindelad distributionsmetod används.

En zonindelad metod minskar svarstiden mellan dina komponenter. Men i sig ökar det inte återhämtningsförmågan för din lösning. För att öka din återhämtning måste du distribuera flera instanser av dina komponenter till flera tillgänglighetszoner och bestämma hur du dirigerar trafik mellan varje instans. Det här exemplet visar en aktiv-passiv trafikroutningsmetod:

Diagram som visar lösningen som distribuerats till flera tillgänglighetszoner. En aktiv-passiv trafikroutningsmetod används.

I föregående exempel distribueras en lastbalanserare över flera tillgänglighetszoner. Det är viktigt att tänka på hur du dirigerar trafik mellan instanser i olika tillgänglighetszoner, eftersom ett zonfel också kan påverka de nätverksresurser som distribueras till den zonen. Du kan också överväga att använda en global lastbalanserare, till exempel Azure Front Door eller Azure Traffic Manager, som inte distribueras till en region alls.

När du använder en zonindelad distributionsmodell tar du på dig många ansvarsområden:

  • Du måste distribuera resurser till varje tillgänglighetszon och konfigurera och hantera resurserna individuellt.
  • Du måste bestämma hur och när du ska replikera data mellan tillgänglighetszonerna och sedan konfigurera och hantera replikeringen.
  • Du ansvarar för att distribuera begäranden till rätt resurser, till exempel med hjälp av en lastbalanserare. Du måste se till att lastbalanseraren uppfyller dina återhämtningskrav. Du måste också bestämma om du vill använda en aktiv-passiv eller en distributionsmodell för aktiv-aktiv begäran.
  • Om en tillgänglighetszon upplever ett avbrott måste du hantera redundansväxlingen för att skicka trafik till resurser i en annan tillgänglighetszon.

En aktiv-passiv distribution över flera tillgänglighetszoner kallas ibland dr i regionen eller Metro DR.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet När den distribueras i en enda tillgänglighetszon:Låg tillförlitlighet. En zonindelad distribution ger ingen återhämtning till ett avbrott i ett datacenter eller en tillgänglighetszon. Du måste distribuera redundanta resurser i flera tillgänglighetszoner för att uppnå hög återhämtning.

När du distribueras i flera tillgänglighetszoner:Hög tillförlitlighet. Tjänster kan göras motståndskraftiga mot ett avbrott i datacenter eller tillgänglighetszoner.
Kostnadsoptimering När den distribueras i en enda tillgänglighetszon:Låg kostnad. En distribution med en zon kräver bara en enda instans av varje resurs.

När du distribuerar i flera tillgänglighetszoner:Hög kostnad. Du distribuerar flera instanser av resurserna, som vart och ett debiteras separat. Du måste också betala för trafik mellan zoner för datareplikering.
Prestandaeffektivitet Höga prestanda. Svarstiden kan vara mycket låg när de komponenter som hanterar en begäran finns i samma tillgänglighetszon.
Driftseffektivitet Låg driftseffektivitet. Du måste konfigurera och hantera flera instanser av tjänsten. Du måste replikera data mellan tillgänglighetszoner. Under ett avbrott i tillgänglighetszonen är redundansen ditt ansvar.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Hög. När du distribuerar en lösning som använder den här metoden lagras data i den Azure-region som du väljer.
Regional tillgänglighet Regioner med tillgänglighetszoner. Den här metoden är tillgänglig i alla regioner som stöder tillgänglighetszoner.

Den här metoden används vanligtvis för arbetsbelastningar som baseras på virtuella datorer. En fullständig lista över tjänster som stöder zonindelade distributioner finns i Tillgänglighetszonstjänst och regional support.

När du planerar en zonindelad distribution kontrollerar du att de Azure-tjänster som du använder stöds i de tillgänglighetszoner som du planerar att använda. Om du till exempel vill visa en lista över vilka SKU:er för virtuella datorer som är tillgängliga i varje tillgänglighetszon läser du Kontrollera SKU-tillgänglighet för virtuella datorer.

Tips

När du distribuerar en resurs till en specifik tillgänglighetszon väljer du zonnumret. Sekvensen med zonnummer är olika för varje Azure-prenumeration. Om du distribuerar resurser över flera Azure-prenumerationer kontrollerar du de zonnummer som du bör använda i varje prenumeration. Mer information finns i Fysiska och logiska tillgänglighetszoner.

Distributionsmetod 3: Zonredundanta distributioner

När du använder den här metoden sprids programnivån över flera tillgänglighetszoner. När begäranden tas emot genererar en lastbalanserare som är inbyggd i tjänsten (som i sig sträcker sig över tillgänglighetszoner) begäranden över instanserna i varje tillgänglighetszon. Om en tillgänglighetszon upplever ett avbrott dirigerar lastbalanseraren trafik till instanser i felfria tillgänglighetszoner.

Lagringsnivån är också spridd över flera tillgänglighetszoner. Kopior av programmets data distribueras över flera tillgänglighetszoner via synkron replikering. När programmet gör en ändring av data skriver lagringstjänsten ändringen till flera tillgänglighetszoner, och transaktionen anses bara slutföras när alla dessa ändringar är slutförda. Den här processen säkerställer att varje tillgänglighetszon alltid har en uppdaterad kopia av data. Om en tillgänglighetszon upplever ett avbrott kan en annan tillgänglighetszon användas för att komma åt samma data.

Diagram som visar lösningen som distribuerats till flera tillgänglighetszoner. En zonredundant distributionsmetod används.

En zonredundant metod ökar din lösnings återhämtning till problem som avbrott i datacenter. Eftersom data replikeras synkront måste ditt program dock vänta på att data skrivs på flera olika platser som kan finnas i olika delar av ett storstadsområde. För de flesta program är svarstiden för kommunikation mellan zoner försumbar. För vissa mycket svarstidskänsliga arbetsbelastningar kan synkron replikering mellan tillgänglighetszoner dock påverka programmets prestanda.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet Hög tillförlitlighet. Tjänsterna är motståndskraftiga mot ett avbrott i ett datacenter eller en tillgänglighetszon. Data replikeras synkront mellan tillgänglighetszoner och utan fördröjning.
Kostnadsoptimering Måttlig kostnad. Beroende på vilka tjänster du använder kan det medföra vissa kostnader för högre tjänstnivåer för att aktivera zonredundans eller vissa nätverkskostnader mellan zoner.
Prestandaeffektivitet För de flesta arbetsbelastningar:Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket latenskänsliga arbetsbelastningar:Låga prestanda. Vissa komponenter kan vara känsliga för svarstid på grund av trafik mellan zoner eller datareplikeringstid.
Driftseffektivitet Hög driftseffektivitet. Du behöver vanligtvis bara hantera en enda logisk instans av varje resurs. För de flesta tjänster, under ett avbrott i tillgänglighetszonen, ansvarar redundans för Microsoft och sker automatiskt.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Hög. När du distribuerar en lösning som använder den här metoden lagras data i den Azure-region som du väljer.
Regional tillgänglighet Regioner med tillgänglighetszoner. Den här metoden är tillgänglig i alla regioner som stöder tillgänglighetszoner.

Den här metoden är möjlig med många Azure-tjänster, inklusive Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus och många andra. En fullständig lista över tjänster som stöder zonredundans finns i Tillgänglighetszonstjänst och regional support.

Zonredundanta distributioner med säkerhetskopiering mellan regioner

Du kan utöka en zonredundant distribution genom att utföra regelbundna säkerhetskopior av infrastrukturen och data till en sekundär region. Den här metoden ger dig fördelarna med en zonredundant metod och lägger till ett skyddslager för att minimera den extremt osannolika händelsen av ett fullständigt regionstopp.

Diagram som visar lösningen som distribuerats till flera tillgänglighetszoner i en zonredundant distribution, med säkerhetskopior i en annan region.

När du implementerar den här metoden måste du noggrant överväga din RTO och RPO:

  • Återställningstid: Om ett regionalt avbrott inträffar kan du behöva återskapa lösningen i en annan Azure-region, vilket påverkar återställningstiden. Överväg att skapa din lösning med hjälp av en IaC-metod så att du snabbt kan distribuera om till en annan region under en större katastrof. Se till att dina distributionsverktyg och processer är lika motståndskraftiga som dina program så att du kan använda dem för att distribuera om din lösning även om ett avbrott inträffar. Planera för och repetera de steg som krävs för att återställa lösningen till ett fungerande tillstånd.

  • Återställningspunkt: Säkerhetskopieringsfrekvensen avgör hur mycket dataförlust du kan uppleva (återställningspunkten). Du kan vanligtvis styra frekvensen för säkerhetskopior för att uppfylla ditt RPO.

Tips

Den här metoden ger ofta en bra balans för alla arkitekturfrågor. Om du inte är säker på vilken metod du ska använda börjar du med den här typen av distribution.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet Mycket hög tillförlitlighet. Tjänsterna är motståndskraftiga mot ett avbrott i ett datacenter eller en tillgänglighetszon. För de flesta tjänster replikeras data över zoner automatiskt och utan fördröjning. Data säkerhetskopieras asynkront till en geografiskt avgränsad region. Den här säkerhetskopieringen minskar effekten av ett fullständigt regionstopp genom att minimera dataförlusten. Efter ett fullständigt regionstopp kan du manuellt återställa åtgärder till en annan region. Återställningsprocesser kan dock vara komplexa och det kan ta tid att återställa till den andra regionen manuellt.
Kostnadsoptimering Måttlig kostnad. Vanligtvis kostar det bara något mer att lägga till en säkerhetskopia till en annan region än att implementera zonredundans.
Prestandaeffektivitet För de flesta arbetsbelastningar:Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket latenskänsliga arbetsbelastningar:Låga prestanda. Vissa komponenter kan vara känsliga för svarstid på grund av trafik mellan zoner eller datareplikeringstid.
Driftseffektivitet Under ett avbrott i tillgänglighetszonen:Hög driftseffektivitet. Redundans är Microsofts ansvar och sker automatiskt.

Under ett regionalt avbrott:Låg driftseffektivitet. Redundans är ditt ansvar och kan kräva manuella åtgärder och omdistributioner.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Beror på valet av region. Data lagras främst i den Azure-region som du anger, men du måste välja en annan region för att lagra dina säkerhetskopior. Välj en region som är kompatibel med dina krav på datahemvist.
Regional tillgänglighet Regioner med tillgänglighetszoner. Den här metoden är tillgänglig i alla regioner som stöder tillgänglighetszoner.

Distributionsmetod 4: Distributioner i flera regioner

Du kan använda flera Azure-regioner tillsammans för att distribuera din lösning över ett brett geografiskt område. Du kan använda den här metoden för flera regioner för att förbättra lösningens tillförlitlighet eller för att stödja geografiskt distribuerade användare. Genom att distribuera till flera regioner minskar du också risken för att du stöter på en tillfällig resurskapacitetsbegränsning i en enda region. Om datahemvist är ett viktigt problem för din lösning bör du noga överväga vilka regioner du använder för att säkerställa att dina data endast lagras på platser som uppfyller dina krav.

Aktiva och passiva regioner

Arkitekturer i flera regioner är komplexa och det finns många sätt att utforma en lösning för flera regioner. För vissa arbetsbelastningar är det klokt att ha flera regioner som aktivt bearbetar begäranden samtidigt (aktiva-aktiva distributioner). För andra arbetsbelastningar är det bättre att ange en primär region och använda en eller flera sekundära regioner för redundans (aktiv-passiva distributioner). Det här avsnittet fokuserar på det andra scenariot, där en region är aktiv och en annan är passiv. Information om aktiva och aktiva lösningar för flera regioner finns i Mönster för distributionsstämplar och Geode-mönster.

Datareplikering

Kommunikation mellan regioner är mycket långsammare än kommunikation inom en region. I allmänhet medför ett större geografiskt avstånd mellan två regioner mer nätverksfördröjning på grund av det längre fysiska avstånd som data behöver färdas. Se Svarstidsstatistik för svarstid för azure-nätverk för förväntad nätverksfördröjning när du ansluter mellan två regioner.

Nätverksfördröjning mellan regioner kan avsevärt påverka din lösningsdesign eftersom du noggrant måste överväga hur den extra svarstiden påverkar datareplikering och andra transaktioner. För många lösningar kräver en arkitektur mellan regioner asynkron replikering för att minimera effekten av trafik mellan regioner på prestanda.

Asynkron datareplikering

När du implementerar asynkron replikering mellan regioner väntar inte programmet på att alla regioner ska bekräfta en ändring. När ändringen har checkats in i den primära regionen anses transaktionen vara slutförd. Ändringen replikeras till de sekundära regionerna vid ett senare tillfälle. Den här metoden säkerställer att svarstiden mellan regioner inte direkt påverkar programmets prestanda. Men på grund av fördröjningen i replikeringen kan ett regionomfattande avbrott leda till viss dataförlust. Den här dataförlusten kan inträffa eftersom en region kan drabbas av ett avbrott när en skrivning har slutförts i den primära regionen, men innan ändringen kan replikeras till en annan region.

Diagram som visar den lösning som distribuerats till flera regioner. Datareplikering sker asynkront.

I den här tabellen sammanfattas några av grundpelarna:

Grundpelare Påverkan
Tillförlitlighet Hög tillförlitlighet. Lösningen är motståndskraftig mot ett avbrott i ett datacenter, en tillgänglighetszon eller en hel region. Data replikeras men kanske inte är synkrona, så viss dataförlust är möjlig i ett redundansscenario.
Kostnadsoptimering Höga kostnader. Du måste distribuera separata resurser i varje region och varje resurs medför distributions- och underhållskostnader. Datareplikering mellan regioner kan också medföra betydande kostnader.
Prestandaeffektivitet Höga prestanda. Programbegäranden kräver inte trafik mellan regioner, så trafiken är vanligtvis låg svarstid.
Driftseffektivitet Låg driftseffektivitet. Du måste distribuera och hantera resurser i flera regioner. Du ansvarar också för redundans mellan regioner under ett regionalt avbrott.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Beror på val av region. Den här metoden kräver att du väljer flera regioner som din arbetsbelastning ska köras i. Välj regioner som är kompatibla med dina krav på datahemvist.
Regional tillgänglighet Många Azure-regioner är kopplade. Vissa Azure-tjänster använder länkade regioner för att replikera data automatiskt. Om du kör din arbetsbelastning i en region som inte har ett par kan du behöva använda en annan metod för att replikera dina data.
Synkron datareplikering

Om du implementerar en synkron lösning för flera regioner måste ditt program vänta tills skrivåtgärderna har slutförts i varje Azure-region innan transaktionen anses vara slutförd. Svarstiden som uppstår vid väntan på skrivåtgärder beror på avståndet mellan regionerna. För många arbetsbelastningar kan svarstid mellan regioner göra synkron replikering för långsam för att vara användbar.

Diagram som visar lösningen som distribuerats till flera regioner. Datareplikering sker synkront.

I den här tabellen sammanfattas några av grundpelarnas problem:

Grundpelare Påverkan
Tillförlitlighet Mycket hög tillförlitlighet. Lösningen är motståndskraftig mot ett avbrott i ett datacenter, en tillgänglighetszon eller en hel region. Data är alltid synkroniserade mellan regioner, så även om en fullständig regionförlust inträffar är dina data tillgängliga och slutförda i en annan region.
Kostnadsoptimering Hög kostnad. Du måste distribuera separata resurser i varje region och varje resurs medför kostnader för distribution och underhåll. Datareplikering mellan regioner kan också medföra betydande kostnader.
Prestandaeffektivitet Låg prestanda. Programbegäranden kräver trafik mellan regioner. Beroende på avståndet mellan regionerna kan synkron replikering ge längre svarstider för begäranden.
Driftseffektivitet Låg driftseffektivitet. Du måste distribuera och hantera resurser i flera regioner. Du ansvarar också för redundans mellan regioner under ett regionalt avbrott.

Den här tabellen sammanfattar några av problemen ur ett arkitekturperspektiv:

Arkitekturproblem Påverkan
Efterlevnad av datahemvist Beror på val av region. Den här metoden kräver att du väljer flera regioner som din arbetsbelastning ska köras i. Välj regioner som är kompatibla med dina krav på datahemvist.
Regional tillgänglighet Många Azure-regioner är kopplade. Vissa Azure-tjänster använder länkade regioner för att replikera data automatiskt. Om du kör din arbetsbelastning i en region som inte har ett par kan du behöva använda en annan metod för att replikera dina data.

Regionsarkitekturer

När du utformar en lösning för flera regioner bör du överväga om de Azure-regioner som du planerar att använda är kopplade.

Du kan skapa en lösning för flera regioner även om regionerna inte är kopplade. De metoder som du använder för att implementera en arkitektur för flera regioner kan dock skilja sig åt. I Azure Storage kan du till exempel använda geo-redundant lagring (GRS) med länkade regioner. Om GRS inte är tillgängligt kan du överväga att använda funktioner som Azure Storage-objektreplikering eller utforma ditt program så att det skriver till flera regioner.

Kombinera metoder för flera zoner och flera regioner

Du bör kombinera instruktioner för flera zoner och flera regioner om dina affärskrav kräver en sådan lösning. Du kan till exempel distribuera zonredundanta komponenter till varje region och även konfigurera replikering mellan regionerna. För vissa lösningar ger den här metoden en mycket hög grad av tillförlitlighet. Det kan dock vara komplicerat att konfigurera den här typen av metod, och den här metoden kan vara dyr.

Viktigt

Verksamhetskritiska arbetsbelastningar bör använda både flera tillgänglighetszoner och flera regioner. Mer information om de överväganden som du bör tänka på när du utformar verksamhetskritiska arbetsbelastningar finns i dokumentationen om verksamhetskritiska arbetsbelastningar.

Så här stöder Azure-tjänster distributionsmetoder

Det är viktigt att förstå den specifika informationen om de Azure-tjänster som du använder. Vissa Azure-tjänster kräver till exempel att du konfigurerar deras konfiguration av tillgänglighetszoner när du först distribuerar resursen, medan andra stöder att distributionsmetoden ändras senare. På samma sätt kanske vissa tjänstfunktioner inte är tillgängliga med varje distributionsmetod.

Mer information om specifika distributionsalternativ och metoder att överväga för varje Azure-tjänst finns på tillförlitlighetshubben.

Exempel

I det här avsnittet beskrivs några vanliga användningsfall och de viktiga krav som du vanligtvis behöver tänka på för varje arbetsbelastning. För varje arbetsbelastning tillhandahålls en eller flera föreslagna distributionsmetoder baserat på de krav och metoder som beskrivs i den här artikeln.

Verksamhetsspecifikt program för ett företag

Contoso, Ltd., är ett stort tillverkningsföretag. Företaget implementerar ett verksamhetsspecifikt program för att hantera vissa komponenter i sina finansiella processer.

Affärskrav: Den information som systemet hanterar är svår att ersätta, så data måste bevaras på ett tillförlitligt sätt. Arkitekterna säger att systemet behöver medföra så lite stilleståndstid och så lite dataförlust som möjligt. Contosos anställda använder systemet under hela arbetsdagen, så höga prestanda är viktigt för att undvika att teammedlemmarna väntar. Kostnaden är också ett problem eftersom ekonomiteamet måste betala för lösningen.

Föreslagen metod: Zonredundant distribution med säkerhetskopiering mellan regioner ger flera lager av återhämtning med höga prestanda.

Internt program

Fourth Coffee är ett litet företag. Företaget utvecklar ett nytt internt program som anställda kan använda för att skicka tidrapporter.

Affärskrav: För den här arbetsbelastningen är kostnadseffektivitet ett primärt problem. Fourth Coffee utvärderade affärspåverkan av stilleståndstid och beslutade att programmet inte behöver prioritera återhämtning eller prestanda. Företaget accepterar risken att ett avbrott i en Azure-tillgänglighetszon eller -region gör programmet tillfälligt otillgängligt.

Föreslagna metoder:

Migrering av äldre program

Fabrikam, Inc., migrerar ett äldre program från ett lokalt datacenter till Azure. Implementeringen använder en IaaS-metod som baseras på virtuella datorer. Programmet har inte utformats för en molnmiljö och kommunikationen mellan programnivån och databasen är mycket trafikintensiv.

Affärskrav: Prestanda är en prioritet för det här programmet. Återhämtning är också viktigt och programmet måste fortsätta att fungera även om ett Azure-datacenter drabbas av ett avbrott.

Föreslagen metod:

Sjukvårdsprogram

Lamna Healthcare Company implementerar ett nytt elektroniskt hälsoregistersystem i Azure.

Affärskrav: På grund av den typ av data som den här lösningen lagrar är datahemvist avgörande. Lamna arbetar enligt ett strikt regelverk som kräver att data måste finnas kvar på en viss plats.

Föreslagna metoder:

Banksystem

Woodgrove Bank kör sin kärnbankverksamhet från en stor lösning som distribueras till Azure.

Affärskrav: Det här är ett verksamhetskritiskt system. Eventuella avbrott kan orsaka stor ekonomisk påverkan för kunderna. Därför har Woodgrove Bank mycket låg risktolerans. Systemet behöver högsta möjliga tillförlitlighetsnivå, och arkitekturen måste minska risken för eventuella fel som kan minimeras.

Föreslagen metod: För ett verksamhetskritiskt system använder du en distribution i flera zoner i flera regioner. Se till att regionerna uppfyller företagets krav på datahemvist.

Programvara som en tjänst (SaaS)

Proseware, Inc., bygger programvara som används av företag över hela världen. Företagets användarbas är geografiskt utspridda.

Affärskrav: Proseware måste göra det möjligt för var och en av sina kunder att välja en distributionsregion som är nära kunden. Det är viktigt att aktivera det här valet för svarstid och för kundernas krav på datahemvist.

Föreslagna metoder:

Nedan följer några referensarkitekturer och exempelscenarier för lösningar för flera zoner och flera regioner:

Många Azure-tjänster ger vägledning om hur du använder flera tillgänglighetszoner, inklusive följande exempel:

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet