Nätverksdesign för flera regioner

Den här artikeln beskriver hur du utformar Azure nätverk som sträcker sig över flera regioner. Ett nätverk med flera regioner ger hög tillgänglighet mot regionala avbrott, betjänar geografiskt distribuerade användare med lägre svarstid och har stöd för reglerade krav på datahemvist.

Vad den här artikeln beskriver

Den här artikeln beskriver zon kontra regional redundans, routningsstrategier mellan regioner, val av hubbtopologi för distributioner i flera regioner, aktivt-aktivt kontra aktivt-passivt redundansmönster och överväganden för replikeringsfördröjning.

Vem behöver den här artikeln

Läs den här artikeln om din miljö matchar något av följande villkor:

• Din arbetsbelastning kräver skydd för haveriberedskap mot fel i en hel Azure-region.
• Du betjänar användare i flera geografiska områden och behöver minimera nätverksfördröjningen.
• Regel- eller efterlevnadskrav kräver att data ligger inom specifika geografiska gränser.
• Dina affärskontinuitetsmål definierar ett mål för återställningstid (RTO) som en enda region inte kan uppfylla ensam.

Om din arbetsbelastning fungerar i en enda region och zonredundanta distributioner uppfyller dina tillgänglighetskrav kanske du inte behöver någon design för flera regioner ännu. Börja med en topologi med nav och eker eller Virtual WAN i en region och utöka senare.

Azure tjänster och funktioner

I följande tabell visas de Azure tjänster och funktioner som möjliggör nätverk i flera regioner:

Varför flera regioner kräver flera virtuella nätverk

Ett virtuellt nätverk (VNet) sträcker sig över en enda region. Undernät inom det virtuella nätverket sträcker sig över alla tillgänglighetszoner i regionen, men själva det virtuella nätverket kan inte sträcka sig över regiongränser. Nätverk i flera regioner innebär därför att du distribuerar flera virtuella nätverk, ett eller flera per region, och ansluter dem med tjänster mellan regioner.

Den här grundläggande begränsningen formar varje design för flera regioner:

• Varje region behöver ett eget VNet-adressutrymme (inte överlappande med andra regioner för peering).
• Trafik mellan regioner kräver en uttrycklig anslutningsmekanism: Global VNet-peering, Virtual WAN mellan hubbar eller gatewaybaserad routning.
• Globala lastbalanseringstjänster (Traffic Manager eller Front Door) dirigerar användarna till rätt regional distribution.

Vägledning för undernäts- och adressplanering finns i PLANERING av IP-adresser.

Tillgänglighetszoner jämfört med regional redundans

Innan du utformar en topologi för flera regioner bör du förstå de två nivåerna av infrastrukturredundans i Azure:

Börja med zonredundans. Zonredundanta distributioner skyddar mot de vanligaste felscenarierna (problem med enskilda datacenter) utan komplexiteten i routning i flera regioner. Lägg till regional redundans när ditt företag kräver skydd mot regionomfattande avbrott eller när du behöver hantera geografiskt distribuerade användare.

Referens för zonredundanta nätverkstjänster

I följande tabell visas zonredundanta distributionsalternativ för kärnnätverkstjänster. Distribuera dem i varje region där du kör belastningar:

Så här väljer du en trafikroutningsmetod mellan regioner

Använd följande beslutstabell för att välja rätt tjänst för att dirigera trafik mellan regioner:

Så här väljer du en navtopologi för flera regioner

När du har bestämt dig för att utöka nätverket mellan regioner väljer du ett hubbmönster för att hantera anslutningar mellan regioner:

En detaljerad jämförelse av hub-and-spoke-topologi kontra Virtual WAN i en och samma region finns i Hub-and-spoke-topologi och Virtual WAN.

Designöverväganden

Förutsättningar

Innan du utformar ett nätverk för flera regioner måste du kontrollera att du har:

• Driftsatte och testade en topologi för en enda region. Börja med hub-and-spoke eller Virtual WAN.
• Definierade krav på hög tillgänglighet och haveriberedskap: RTO, mål för återställningspunkter (RPO) och efterlevnadsmandat.
• Skapade en ip-adressplan som inte överlappar varandra i alla regioner. Se Planering av IP-adresser.
• Identifierade vilka arbetsbelastningar som endast behöver regional redundans jämfört med zonredundans.

Aktiv-aktiv kontra aktiv-passiv driftsättningsmönster

Distributionsmodellen för flera regioner avgör hur trafiken flödar under normal drift och under ett regionalt fel:

Active-active

Båda regionerna hanterar trafik samtidigt. En global lastbalanserare, till exempel Traffic Manager eller Front Door, distribuerar begäranden mellan regioner baserat på närhet, prestanda eller vikt.

När du ska använda aktiv-aktiv:

• Ditt program kan hantera begäranden i valfri region utan regionspecifika tillståndsberoenden.
• Du behöver den lägsta möjliga RTO:n (växling vid fel sker omedelbart eftersom den fungerande regionen redan betjänar trafiken).
• Du vill använda kapacitet i båda regionerna under normal drift (kostnadseffektivitet).

Nätverksöverväganden:

• Båda regionerna måste ha identisk nätverksinfrastruktur, inklusive brandväggar, gatewayer och lastbalanserare.
• Datareplikering mellan regioner måste hålla båda distributionerna aktuella.
• Intervallen för DNS-TTL och hälsoavsökningar avgör hur snabbt Traffic Manager styr om trafik. Front Door ger snabbare redundans på anslutningsnivå.

Active-passive

En region (primär) hanterar all trafik. Den sekundära regionen är fortsatt redo, men hanterar inte användarförfrågningar förrän en växlingshändelse inträffar.

När du ska använda aktiv-passiv:

• Ditt program har strikta krav för skrivregionen eller kan inte enkelt replikera tillstånd.
• Kostnadsbegränsningar förhindrar att full kapacitet körs i två regioner samtidigt.
• Din RTO-tolerans tillåter den tid som krävs för att aktivera den sekundära regionen.

Nätverksöverväganden:

• Den passiva regionens nätverksinfrastruktur kan använda lägre nivåer eller minskad kapacitet fram till felväxling.
• Automatisk redundansväxling kräver hälsokontroller med lämpliga tröskelvärden (undvik flapping).
• Testa redundansväxling regelbundet. Nätverkskonfigurationer i den passiva regionen kan avvika om de inte valideras.
• Håll routningstabeller och NSG-regler synkroniserade mellan regioner. Använd mallar för infrastruktur som kod för att se till att den passiva regionen matchar den primära regionens säkerhetsstatus.
• Företablera VPN- eller ExpressRoute-gatewayer i den passiva regionen. Gatewayetablering kan ta 20–45 minuter. Det är för långsamt för de flesta RTO-mål.

Välja mellan aktivt-aktivt och aktivt-passivt nätverk

Valet mellan aktivt-aktivt och aktivt-passivt nätverk påverkar nätverksstorlek, kostnad och driftskomplexitet:

Datareplikering och svarstid

Replikering mellan regioner introducerar nätverksfördröjning som påverkar programdesignen. Azure-regioner inom samma geografiska område uppvisar vanligtvis 1–10 ms latens tur och retur för närliggande regionpar (till exempel East US till East US 2) och 30–70 ms för mer avlägsna par (till exempel East US till West US). Transatlantiska eller transpacifiska regionpar kan överstiga 100 ms.

Viktiga designöverväganden:

• Replikeringstopologi: Välj synkron replikering endast för regionpar med låg svarstid (< 10 ms). Använd asynkron replikering för avlägsna par för att undvika försämrad programprestanda.
• Bandbreddsplanering: Beräkna dataflödeskrav för replikering och ta hänsyn till kostnader för global VNet-peering per GB-dataöverföring. Replikering av stora datavolymer mellan avlägsna regioner kan medföra betydande avgifter för utgående datatrafik.
• Konfliktlösning: Aktiva-aktiva mönster med dubbelriktade skrivningar kräver konfliktlösningsstrategier på program- eller databasskiktet. Nätverket tillhandahåller anslutning, men program måste hantera skrivkonflikter.
• Privata slutpunkter för PaaS-replikering: När du replikerar Azure SQL, Cosmos DB eller Lagring mellan regioner använder du privata slutpunkter i varje region för att behålla replikeringstrafiken på Microsoft stamnät och undvika offentlig Internetexponering.

Kostnadsöverväganden

Nätverk i flera regioner ökar kostnaderna genom duplicerad infrastruktur och dataöverföring mellan regioner. Planera din budget kring dessa primära kostnadsdrivrutiner:

• Dataöverföring mellan regioner: Global VNet-peering och Virtual WAN-trafik mellan hubbar medför avgifter per GB för data som passerar regionsgränser. Trafik inom regionen mellan peerkopplade virtuella nätverk i samma region sker utan extra kostnad inom samma zon och debiteras till en lägre taxa mellan zoner.
• Duplicerade nätverksinstallationer: Varje region kräver sin egen brandvägg, lastbalanserare och gatewayinstanser. Active-active-driftsättningar fördubblar dessa kostnader. Aktiv-passiva distributioner kan minska kostnaderna genom att använda mindre nivåer i väntelägesregionen och skala upp under redundansväxling.
• Globala avgifter för belastningsutjämning: Både Traffic Manager och Front Door debiteras baserat på DNS-frågor eller begäranden som bearbetas. Front Door debiterar dessutom för dataöverföring från edge-PoP:ar till backend-servrar.
• ExpressRoute och VPN Gateway: Design för flera regioner kräver ofta gatewayinstanser i varje region. ExpressRoute-kretsar som ansluter flera regioner medför månatliga portavgifter och uppmätta dataavgifter per GB.
• Optimera med trafiklokalitet: Utforma programnivåer för att minimera anrop mellan regioner. Behåll läsrepliker samlokaliserade med beräkningsresurserna i varje region för att minska bandbreddsanvändningen för replikering och latenskänsliga frågor.

Säkerhetsfrågor

Ett nätverk med flera regioner introducerar säkerhetsöverväganden utöver distributioner i en region:

• Trafiken ligger kvar på Microsoft stamnät. All trafik mellan regioner via Global VNet Peering eller Virtual WAN-anslutning mellan hubbar passerar Microsofts stamnät, inte det offentliga internet.
• Distribuera zonredundanta brandväggar i varje region. Varje regional nod behöver en egen brandväggsinstans för trafikinspektion. Distribuera brandväggar mellan tillgänglighetszoner för att bevara säkerheten vid zonfel.
• Front Door WAF ger gränssäkerhet. När du använder Front Door inspekterar dess integrerade Web Application Firewall trafiken innan den når någon regional distribution. Detta ger ett första lager av skydd vid nätverkskanten.
• Planera DNS-redundans noggrant. Traffic Manager-redundans beror på DNS TTL. Kortare TTL:er möjliggör snabbare redundans men ökar DNS-frågevolymen. Front Door tillhandahåller redundans på anslutningsnivå som inte är beroende av att klientens DNS-cache upphör att gälla.
• ExpressRoute Global Reach-trafik förblir privat. Trafik mellan lokala platser som är anslutna via Global Reach berör aldrig det offentliga Internet. Den förblir på Microsoft stamnät mellan kretsar.
• Säkra replikeringskanaler mellan regioner. Replikeringstrafik i backend via global VNet-peering är privat som standard, men använd nätverkssäkerhetsgrupper och kryptering för känsliga data under överföring.

Relaterade artiklar

Om din design för flera regioner omfattar specifika scenarier som beskrivs någon annanstans i den här guiden kan du läsa:

• Hubb-och-ekertopologi: Designmönster med en hubb per region för driftsättningar i flera regioner.
• Virtual WAN: Virtual WAN flerhubbmönster med automatisk routning mellan hubbar.
• Anslutningar mellan regioner: Detaljerad vägledning om peering, global räckvidd och anslutningsalternativ mellan hubbar.
• VNet och undernät: Design och planering av VNet per region.
• IP-adressplanering: Icke-överlappande adressutrymmen mellan regioner.
• Azure Firewall och trafikinspektion: Zonredundant distribution av brandvägg i varje regional hubb.

Learn more

Mer information om de tjänster och begrepp som beskrivs i den här artikeln finns i följande resurser:

• Översikt över Traffic Manager
• Översikt över Azure Front Door
• Översikt över peering för virtuella nätverk
• ExpressRoute Global Reach
• Virtual WAN arkitektur för globala transitnätverk
• Azure-regioner och tillgänglighetszoner

Nästa steg