Anslutning för datalandningszon mellan regioner
Om du har en närvaro i mer än en Azure-region och behöver vara värd för dina dataplattforms- och dataprogram i flera geografiska områden blir anslutningen något mer komplicerad.
Distributioner i flera regioner har vanligtvis en prenumeration på anslutningshubben på varje enskild Azure-plats. Till exempel, om du har tjänster som körs i både östra USA och västra Europa, ska du konfigurera en anslutningshubbsprenumeration med delade nätverksresurser i varje region. Delade nätverksresurser omfattar:
- Virtuella nätverksinstallationer (som Azure Firewall)
- ExpressRoute-gateways
- VPN Gateways
- Virtuella Hub-nätverk (i en 'hub and spoke'-arkitektur) eller vWAN Hubbar (i en vWAN-konfiguration)
bild 1: Anslutning mellan regioner.
I "hub-spoke-spoke-hub"-arkitekturen är de virtuella nätverken i anslutningshubbarna ofta anslutna med hjälp av Global Peering för virtuella nätverk. För större miljöer är ett vanligt alternativ att använda ExpressRoute Global Reach. Oavsett vilket anslutningsalternativ du väljer kan du uppnå global routing och uppkoppling mellan nätverk i flera geografier. Det innebär att du kan flytta data mellan regioner med hjälp av virtuella nätverksinstallationer, nätverkssäkerhetsgrupper och routningstabeller, eftersom trafiken inte blockeras i någon av anslutningsprenumerationerna.
Viktig
Den här artikeln och andra artiklar i nätverksavsnittet beskriver affärsöverskridande enheter som delar data. Detta kanske dock inte är din ursprungliga strategi och att du först måste börja på basnivå.
Utforma ditt nätverk så att du så småningom kan implementera vår rekommenderade konfiguration mellan datalandningszoner. Se till att landningszonerna för datahantering är direkt anslutna till styrningslandningszonerna.
Global peering för virtuella nätverk (rekommenderas)
Du kan ansluta datalandningszoner mellan regioner med direkt global peering för virtuella nätverk. I den här konfigurationen, om vi fortsätter med vårt tidigare exempelscenario, kommer den virtuella maskinen i Västeuropa att få direkt åtkomst till lagringskontots privata slutpunkt i Östra USA, utan att förlita sig på någon hub-och-ekerkonstruktion eller vWAN-nätverksarkitektur. Data läses in direkt av den virtuella maskinen via en privat slutpunkt, bearbetas och lagras sedan på lagringskontot i Västeuropa.
Hantering av användaråtkomst i global peering för virtuella nätverk
Det finns inga särskilda fördelar eller nackdelar för något av de föreslagna anslutningsalternativen för datalandningszoner mellan regioner.
Sammanfattning: /
Tjänsthantering i global peering för virtuella nätverk
Global virtuell nätverkspeering har ingen virtuell nätverksapparat som fungerar som en enda felpunkt eller en begränsning av genomströmning. Data skickas inte via dina anslutningshubbar, så du behöver inte skala de virtuella enheterna och gatewayerna i anslutningshubbarna. Den här bristen på skalning minskar hanteringskostnaderna för ditt centrala Azure-plattformsteam. Du behöver inte heller vitlista enskilda regionövergripande anslutningar. Dina datateam kan komma åt data från datalandningszoner i andra regioner utan att behöva vänta på ändringar i routningstabellen.
I den här nätverksdesignen kan ditt centrala Azure-plattformsteam inte längre inspektera och logga all trafik med en layer 7-brandvägg. Analysscenariot i molnskala är dock en sammanhängande plattform som omfattar flera prenumerationer, vilket möjliggör skalning och övervinner begränsningar på plattformsnivå, så det är inte en nackdel. Du kan spela in nätverksloggar genom nätverkssäkerhetsgruppens flödesloggar. Du kan konsolidera och lagra andra loggar på program- och tjänstnivå med hjälp av tjänstspecifika diagnostikinställningar.
Du kan samla in alla dessa loggar i stor skala med hjälp av Azure Policy-definitioner för diagnostikinställningar.
I vissa scenarier måste du begränsa på grund av regelmässiga eller juridiska konsekvenser. Du kan till exempel ha en lokal förordning som kräver att vissa datauppsättningar stannar inom ett partikeldatacenter, så att du inte får överföra dem mellan regioner. Du kan lita på att nätverkssäkerhetsgrupper hjälper dig att följa den här typen av regel, vilket bara tillåter trafik att röra sig i en riktning från USA, östra till Europa, västra och inte tvärtom. I dina nätverkssäkerhetsgrupper kan du se till att trafik från östra USA nekas medan trafik från västra Europa tillåts.
Den här lösningsmetoden påverkar inte bandbredden och svarstiden och gör att kunderna kan fortsätta att vara kompatibla samtidigt som de kombinerar datauppsättningar från flera regioner. Det här alternativet påverkar inte heller DNS-arkitekturen och gör att du kan använda en Azure-inbyggd lösning baserat på Privata DNS-zoner i Azure.
Sammanfattning:
Peeringkostnad för globalt virtuellt nätverk
Anteckning
När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten och inte för VNet-peering. Du kan läsa det officiella uttalandet i FAQ: Hur fungerar fakturering när du kommer åt en privat endpoint från ett peerkopplat nätverk?.
Med den här nätverksdesignen debiteras du för dina privata slutpunkter (per timme) och all inkommande och utgående trafik som skickas via dem. Du måste också betala en dataöverföringskostnad för trafik mellan regioner. Du debiteras dock inte några globala kostnader för peering-ingress och utgående peering i det globala virtuella nätverket och har anmärkningsvärda kostnadsfördelar jämfört med det traditionella eker-hubb-hub-spoke-alternativet.
Sammanfattning:
Bandbredd och svarstid i global peering för virtuella nätverk
Påverkan på bandbredd och svarstid är lägre i Global Peering för Virtuella Nätverk än i det traditionella spoke-hub-hub-spoke-alternativet. Global peering för virtuella nätverk innehåller ett lägre antal hopp för datautbyte mellan regioner och har inga virtuella nätverksinstallationer som begränsar dataflödet. Det enda som dikterar den bandbredd och svarstid du kan uppnå för trafik mellan regioner är de fysiska gränserna för våra datacenter (hastigheten på fiberoptiska kablar, gatewayer och routrar).
Sammanfattning:
Sammanfattning av peering för globala virtuella nätverk
Global-virtuellt nätverkspeering mellan datalandningszoner i olika regioner erbjuder betydande fördelar, särskilt när datatrafiken mellan regioner ökar inom din dataplattform. Det förenklar tjänsthanteringen för ditt centrala Azure-plattformsteam och drar särskilt nytta av användningsfall som kräver låg svarstid och hög bandbredd. Det ger också betydande kostnadsfördelar jämfört med det traditionella designalternativet spoke-hub-hub-spoke.
Traditionell nav-eker-eker-nav-design (rekommenderas inte)
Det andra alternativet för dataöverföringar mellan regioner är den traditionella spoke-hub-hub-spoke-modellen. I vårt exempelscenario, om en virtuell dator i datalandningszonen A som finns i Västeuropa läser in en datauppsättning som lagras i ett lagringskonto från datalandningszonen B som finns i Östra USA, passerar data två lokala virtuella nätverkspeeringar (anslutning mellan hubb och ekrar), en global virtuell nätverkspeering (anslutning mellan hubbar) och två gatewayer eller nätverksvirtuella apparater innan det läses in av den virtuella datorn och sedan flyttas tillbaka till det lokala lagringskontot.
Hantering av användaråtkomst i traditionell spoke-hub-hub-spoke-design
Det finns inga särskilda fördelar eller nackdelar för något av de föreslagna anslutningsalternativen för datalandningszoner mellan regioner.
Sammanfattning: /
Tjänsthantering i traditionell spoke-hub-hub-spoke-design
Den här lösningsmetoden är välkänd och överensstämmer med andra anslutningsmönster mellan regioner, vilket gör det enkelt att införa och implementera. Det påverkar inte heller DNS-arkitekturen och gör att du kan använda en Azure-inbyggd lösning baserat på Privata DNS-zoner i Azure.
Det här anslutningsalternativet fungerar sömlöst om du konfigurerar det korrekt, men det har nackdelar. Trafik mellan regioner nekas ofta som standard och måste aktiveras från fall till fall. Ett ärende måste skickas till ditt centrala Azure-plattformsteam för varje enskilt krav på nödvändig dataåtkomst mellan regioner så att ditt team kan vitlista varje specifik anslutning mellan en virtuell dator och ett lagringskonto över regionerna. Den här processen ökar avsevärt hanteringskostnaderna. Det gör även dina dataprojektteam långsammare eftersom de inte kan komma åt de data de behöver.
Observera också att i det här alternativet fungerar anslutningshubbar som enskilda felpunkter. Vid driftstopp för nätverksvirtuell enhet eller gateway misslyckas anslutningen och de motsvarande dataplattformarna. Du har också hög risk att felkonfigurera vägar i anslutningshubbarna. Den här felkonfigurationen kan orsaka allvarligare avbrott i dataplattformen och leda till en rad beroende arbetsflöden och dataproduktfel.
Du bör övervaka mängden data som du behöver överföra mellan regioner när du använder den här lösningsmetoden. Med tiden kan den här övervakningen omfatta gigabyte eller terabyte data som rör sig genom dina centrala instanser. Eftersom bandbredden för virtuella nätverksinstallationer ofta är begränsad till ett en- eller tvåsiffrigt gigabyte-dataflöde kan enheterna fungera som en kritisk flaskhals som begränsar trafikflödet mellan regioner och datatillgångarnas delningsförmåga. På grund av den här flaskhalsen kan dina delade nätverksresurser kräva skalningsmekanismer som ofta är tidskrävande och kostsamma och kan påverka andra arbetsbelastningar i din klientorganisation.
Sammanfattning:
Traditionell eker-hubb –Hub-Spoke designkostnad
Notera
När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten och inte för VNet-peering. Du kan läsa det officiella meddelandet i FAQ: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.
I den traditionella spoke-hub-hub-spoke-designen debiteras du för de två lagringskontonas privata slutpunkter (per timme) och all trafik för inkommande och utgående data som passerar via dem. Du debiteras också för ingående och utgående trafik för en lokal virtuell nätverkspeering och en global virtuell nätverkspeering mellan dina anslutningshubbar. Du debiteras dock inte för den första peeringen för virtuella nätverk, som vi förklarade i föregående anteckning.
Dina virtuella nätverksinstallationer i det centrala nätverket medför också betydande kostnader om du väljer den här nätverksdesignen. Den här kostnaden beror på att du antingen måste köpa extra licenser för att skala enheterna baserat på efterfrågan eller betala avgiften per bearbetad gigabyte, som med Azure Firewall.
Sammanfattning:
Bandbredd och latens i traditionell stråle-nav-stråledesign
Den här nätverksdesignen har allvarliga bandbreddsbegränsningar. Dina virtuella nätverksinstallationer i det centrala nätverket blir kritiska flaskhalsar när din plattform växer, vilket begränsar användningsfall för datalandningszoner mellan regioner och delning av dina datamängder. Det gör det också troligt att flera kopior av dina datauppsättningar skapas över tid. Den här designen påverkar också svarstiden, vilket är särskilt viktigt för analysscenarier i realtid, eftersom dina data passerar många hopp.
Sammanfattning:
Design av traditionell spoke-hub-hub-spoke
Spoke-hub-hub-spoke-designen är välkänd och etablerad i många organisationer, vilket gör det enkelt att införa i en befintlig miljö. Det har dock betydande nackdelar för tjänsthantering, kostnad, bandbredd och svarstid. Dessa problem är särskilt märkbara när antalet användningsfall mellan regioner växer.
Slutsats
Global virtuell nätverkspeering har många fördelar jämfört med traditionell ekernav-nav-ekerdesign, eftersom den är kostnadseffektiv, lätthanterlig och erbjuder tillförlitlig anslutning över regioner. Även om traditionell eker-nav-nav-eker-design kan vara ett genomförbart alternativ medan din datavolym och behovet av datautbyte mellan regioner är lågt, rekommenderar vi att du använder metoden global peering för virtuella nätverk när mängden data som du behöver utbyta mellan regioner växer.