Dela via

Anslutning mellan regioner för datalandningszoner

  • Artikel

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. Om du till exempel har tjänster som körs i både USA, östra och Europa, västra, konfigurerar du en prenumeration på anslutningshubben med delade nätverksresurser i varje region. Delade nätverksresurser omfattar:

  • Virtuella nätverksinstallationer (som Azure Firewall)
  • ExpressRoute-gatewayer
  • VPN-gatewayer
  • Virtuella hubbnätverk (i en hubb- och ekerarkitektur) eller vWAN Hubs (i en vWan-konfiguration)

Anslut itet mellan regionerBild 1: Anslut ivitet mellan regioner.

I arkitekturen hub-spoke-spoke-hub är anslutningshubbarnas virtuella nätverk ofta anslutna med global VNet-peering. 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 routning och anslutning mellan ekernätverk i flera geografiska områden. 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.

Viktigt!

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 datahanteringslandningszonerna är direkt anslutna till landningszonerna för styrning.

Du kan ansluta datalandningszoner mellan regioner med direkt global VNet-peering. I den här konfigurationen, om vi fortsätter vårt tidigare exempelscenario, kommer den virtuella datorn i Europa, västra, direkt åt lagringskontots privata slutpunkt i USA, östra, utan att förlita sig på någon hubb- och eker- eller vWAN-nätverksarkitektur. Data läses in direkt av den virtuella datorn via en privat slutpunkt, bearbetas och lagras sedan på lagringskontot i Europa, västra.

Hantering av användaråtkomst i global VNet-peering

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 VNet-peering

Global VNet-peering har ingen virtuell nätverksinstallation som fungerar som en enda fel- eller begränsningsdataflöde. 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 tillåtalistning av enskilda anslutningar mellan regioner. 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 avbilda nätverksloggar med hjälp av flödesloggar för nätverkssäkerhetsgrupp. Du kan konsolidera och lagra andra loggar på program- och tjänstnivå med hjälp av tjänstspecifika diagnostik Instä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 USA, östra nekas när trafik från Europa, västra 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å Azure Privat DNS Zones.

Sammanfattning:

Global VNet-peeringkostnad

Kommentar

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 den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat 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ågon global VNet-peering-ingress- och utgående kostnad. På grund av detta har alternativet Global VNet-peering anmärkningsvärda kostnadsfördelar det traditionella eker-hub-hub-spoke-alternativet som beskrivs senare i den här artikeln.

Sammanfattning:

Bandbredd och svarstid i global VNet-peering

Påverkan på bandbredd och svarstid är mycket lägre i global VNet-peering än i det traditionella alternativet spoke-hub-hub-spoke. Global VNet-peering 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:

Global VNet-peeringsammanfattning

Global VNet-peering mellan datalandningszoner i olika regioner ger enorma 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.

Det andra alternativet för dataöverföringar mellan regioner är den traditionella eker-hub-hub-spoke-designen. I vårt exempelscenario, om en virtuell dator i datalandningszonen A som finns i Europa, västra läser in en datauppsättning som lagras i ett lagringskonto från datalandningszon B i USA, östra, passerar data två lokala VNet-peerings (anslutning mellan hubb och ekrar), en global VNet-peering (anslutning mellan hubbar) och två gatewayer eller virtuella nätverksinstallationer innan de 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å Azure Privat DNS Zones.

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. Det innebär att ett ärende måste skickas till ditt centrala Azure-plattformsteam för varje obligatoriskt krav på dataåtkomst mellan regioner så att ditt team kan tillåtalistning av varje specifik anslutning mellan en virtuell dator och lagringskonto mellan regioner. 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. I den virtuella nätverksinstallationen eller gatewayens stilleståndstid misslyckas anslutningen och motsvarande dataplattformar. 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 detta 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 designkostnad för Spoke-Hub-Hub-Spoke

Kommentar

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 den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.

I den traditionella designen spoke-hub-hub-spoke debiteras du dina två lagringskontons privata slutpunkter (per timme) och all inkommande och utgående trafik som skickas via dem. Du debiteras också för inkommande och utgående trafik för en lokal VNet-peering och den globala VNet-peeringen mellan dina anslutningshubbar. Du debiteras dock inte för den första VNet-peeringen, som vi förklarade i föregående anteckning.

Dina virtuella nätverksinstallationer i det centrala nätverket blir också en betydande kostnad om du väljer den här nätverksdesignen. Det beror på att du antingen måste köpa extra licenser för att skala ut enheterna baserat på efterfrågan eller så måste du betala avgiften per bearbetad gigabyte för dem, som med Azure Firewall.

Sammanfattning:

Bandbredd och svarstid i traditionell eker-hubb-ekerdesign

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:

Sammanfattning av traditionell eker-hubb-ekerdesign

Spoke-hub-hub-spoke-designen är välkänd och etablerad i många organisationer, vilket gör det enkelt att etablera 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 VNet-peering har många fördelar jämfört med den traditionella eker-hubb-ekerdesignen, eftersom den är kostnadseffektiv, lätthanterad och erbjuder tillförlitlig anslutning mellan regioner. Även om traditionell eker-hub-hub-spoke-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 VNet-peering när mängden data som du behöver utbyta mellan regioner växer.

Nästa steg