Dela via

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: Multiregional designredundans | 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 möjlighet att använda 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å, de 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 det väldefinierade ramverket:

  • Tillförlitlighet: Ditt val av distributionsmetod kan hjälpa dig att minimera olika typer av risker. Genom att sprida arbetsbelastningen över ett mer geografiskt distribuerat område kan du i allmänhet uppnå högre återhämtning.
  • Kostnadsoptimering: Vissa arkitekturmetoder kräver distribution av fler resurser än andra, vilket kan öka dina resurskostnader. Andra metoder omfattar att skicka data över 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äcker för de flesta arbetsbelastningar för att möjliggöra 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 hitta komponenterna för arbetsbelastningen 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 komplext, 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-infrastruktur som kod, OE:09-uppgiftsautomation, OE:10 Automation-design och OE:11-distributionsmetoder.

Hur du än 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.

Dricks

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 är avsedd 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.
Availability zone En avgränsad grupp datacenter inom 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 för 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 i 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 för regionarkitekturer.

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 en 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 de återstående zonerna 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:

  • Zonindelade resurser fästs i en specifik tillgänglighetszon. Du kan kombinera flera zonindelade distributioner i 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 är spridda ö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 till 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. Men i slutändan är det 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 dina resurser på ett intelligent sätt 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 metoder för säker distribution.

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å delat ansvar

Principen för delat ansvar beskriver hur ansvarsområden delas 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 använda 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 drift av ett distribuerat system.

Din egen kod behöver rekommenderade metoder och designmönster för att hantera fel på ett korrekt sätt. Dessa metoder är ännu viktigare vid redundansväxling, till exempel sådana som inträffar när en tillgänglighetszon eller region redundans 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 risktolerans 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 Sannolikhet
Maskinvarustopp Problem med hårddisk eller nätverksutrustning.

Värdomstarter.		 Hög. Eventuell återhämtningsstrategi bör ta hänsyn till dessa risker.
Datacenterstopp Ström-, kyl- eller nätverksfel i ett helt datacenter.

Naturkatastrof i en del av ett storstadsområde.		 Medium
Regionstopp 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öretagsintressenter så att du kan fatta välgrundade beslut om de risker som du bör minimera.

Dricks

Oavsett tillförlitlighetsmål måste alla arbetsbelastningar ha viss åtgärd för haveriberedskap. Om din arbetsbelastning kräver höga tillförlitlighetsmål bör dina åtgärdsstrategier 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 minimera.

Å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ällningspunkter (RPO). De här målen hjälper dig att avgöra vilka metoder som ska uteslutas. Om du inte har 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 på drifttid (SLO). Du kan till exempel ha ett affärskrav på att lösningen måste uppfylla 99,9 % drifttid.

Azure tillhandahåller serviceavtal (SLA) för varje tjänst. Ett serviceavtal anger vilken 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 sättet som ett Azure-serviceavtal anger tjänstens tillgänglighet inte alltid matchar hur du tänker på hälsotillståndet för din arbetsbelastning.

Dina arkitektoniska beslut påverkar lösningens sammansatta SLO. I allmänhet, ju mer redundans du skapar i din lösning, desto högre är din SLO 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.

Dataresidens

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.

Kommentar

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 spridd användarbas.

Om användarna är koncentrerade till ett område kan en distribution med en region förenkla dina driftskrav och minska kostnaderna. Du måste dock överväga om en distribution med en 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 arbetsbelastningen i 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 i 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. Fundera på om du kan uppfylla 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 principen om enkelhet.

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 lagring.

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) eller zonredundant distribution eller distribution i flera regioner. Den här tabellen sammanfattar några av grundpelarnas problem:

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ög kostnad
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

Resten av den här artikeln beskriver 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 lösningen 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 svarstidskänsliga arbetsbelastningar kan den här metoden också resultera i lägre prestanda. Dina arbetsbelastningskomponenter 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.

Den här tabellen sammanfattar några av grundpelarnas problem:

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 inte några bandbreddskostnader mellan regioner.
Prestandaeffektivitet För de flesta arbetsbelastningar: Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket svarstidskänsliga arbetsbelastningar: Låg prestanda. Komponenter är inte garanterade att finnas i samma tillgänglighetszon, så du kan se lägre prestanda för komponenter med hög svarstid.
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 din infrastruktur och dina 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 lösningen som distribuerats till ett enda datacenter med säkerhetskopior i en annan region.

När du implementerar den här metoden måste du noga ö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 (infrastructure-as-code) 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 lösningen ä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.

Den här tabellen sammanfattar några av grundpelarnas problem:

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. Normalt 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 svarstidskänsliga arbetsbelastningar: Låg prestanda. Komponenter är inte garanterade att finnas i samma tillgänglighetszon, så du kan se lägre prestanda för komponenter med hög svarstid.
Driftseffektivitet Under 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å val 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 på datahemvist.
Regional tillgänglighet Hög. Du kan använda den här metoden i valfri Azure-region.

Distributionsmetod 2: Zonindelat (fästa) 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 zonbaserad 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 den inte lösningens återhämtning. För att öka återhämtningsförmågan måste du distribuera flera instanser av dina komponenter till flera tillgänglighetszoner och bestämma hur trafiken ska dirigeras 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 dessa resurser 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 genom att till exempel använda 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 aktiv-aktiv distributionsmodell för begäranden.
  • Om ett avbrott uppstår i en tillgänglighetszon 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.

Den här tabellen sammanfattar några av grundpelarnas problem:

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 datacenter eller avbrott i tillgänglighetszonen.
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 den distribueras i flera tillgänglighetszoner: Hög kostnad. Du distribuerar flera instanser av resurserna, som var och en debiteras separat.
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 redundans 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.

Dricks

När du distribuerar en resurs till en specifik tillgänglighetszon väljer du zonnumret. Sekvensen med zonnummer skiljer sig åt för varje Azure-prenumeration. Om du distribuerar resurser i 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 sprider en lastbalanserare som är inbyggd i tjänsten (som i sig omfattar tillgänglighetszoner) begäranden mellan instanserna i varje tillgänglighetszon. Om en tillgänglighetszon upplever ett avbrott dirigerar lastbalanseraren trafiken till instanser i de felfria tillgänglighetszonerna.

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 dataändring skriver lagringstjänsten ändringen till flera tillgänglighetszoner och transaktionen anses vara slutförd endast när alla dessa ändringar har slutförts. Den här processen säkerställer att varje tillgänglighetszon alltid har en uppdaterad kopia av data. Om ett avbrott uppstår i en tillgänglighetszon 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 lösningens återhämtning till problem som datacenterstopp. Eftersom data replikeras synkront måste ditt program dock vänta tills 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. Men för vissa mycket svarstidskänsliga arbetsbelastningar kan synkron replikering mellan tillgänglighetszoner påverka programmets prestanda.

Den här tabellen sammanfattar några av grundpelarnas problem:

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.
Prestandaeffektivitet För de flesta arbetsbelastningar: Acceptabel prestanda. Den här metoden kommer sannolikt att ge tillfredsställande prestanda.

För mycket svarstidskänsliga arbetsbelastningar: Låg 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 är redundans under ett avbrott i tillgänglighetszonen Microsofts ansvar 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 din infrastruktur och dina 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 noga ö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 lösningen ä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äkerhetskopieringar för att uppfylla ditt RPO.

Dricks

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

Den här tabellen sammanfattar några av grundpelarnas problem:

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. Att lägga till en säkerhetskopia till en annan region kostar vanligtvis bara något mer ä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 svarstidskänsliga arbetsbelastningar: Låg 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å val 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 utse 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

Det går mycket långsammare att kommunicera mellan regioner än att kommunicera i 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. Mer information om förväntad nätverksfördröjning när du ansluter mellan två regioner finns i Statistik över svarstider för azure-nätverk.

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 programmet inte på att alla regioner ska bekräfta en ändring. När ändringen har genomförts 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 lösningen som distribuerats till flera regioner. Datareplikering sker asynkront.

Den här tabellen sammanfattar några av grundpelarnas problem:

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 kostnader för distribution och underhåll. 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 arbetsbelastningen 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 parkopplade 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.

Den här tabellen sammanfattar 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öga kostnader. 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 lägga till betydande svarstid 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 arbetsbelastningen 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 parkopplade 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.

Regionarkitekturer

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 när regionerna inte är kopplade. De metoder som du använder för att implementera en arkitektur för flera regioner kan dock vara olika. I Azure Storage kan du till exempel använda geo-redundant lagring (GRS) med kopplade regioner. Om GRS inte är tillgängligt kan du överväga att använda funktioner som Replikering av Azure Storage-objekt eller utforma programmet för att skriva 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 vad du bör tänka på när du utformar verksamhetskritiska arbetsbelastningar finns i Dokumentation om verksamhetskritisk arbetsbelastning.

Hur Azure-tjänster stöder 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 konfigurationen av tillgänglighetszonen när du först distribuerar resursen, medan andra har stöd för att ändra distributionsmetoden senare. På samma sätt kanske vissa tjänstfunktioner inte är tillgängliga med varje distributionsmetod.

Mer information om de specifika distributionsalternativ och metoder som du bör tänka på 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 måste 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 för att ett avbrott i en Azure-tillgänglighetszon eller -region kan göra 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 pratsam.

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 typen av data som den här lösningen lagrar är datahemvist avgörande. Lamna verkar inom ett strikt regelverk som kräver att data måste finnas kvar på en viss plats.

Föreslagna metoder:

Banksystem

Woodgrove Bank driver sin huvudsakliga bankverksamhet från en stor lösning som distribueras till Azure.

Affärskrav: Detta är ett verksamhetskritiskt system. Eventuella avbrott kan orsaka stora ekonomiska konsekvenser 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 brett distribuerad geografiskt.

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. Att aktivera det här valet är viktigt för svarstiden och för kundernas krav på datahemvist.

Föreslagna metoder:

Här följer några referensarkitekturer och exempelscenarier för lösningar i 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