Sdílet prostřednictvím

Připojení přistávací zóny dat napříč oblastmi

  • Článek

Pokud máte více než jednu oblast Azure a potřebujete hostovat datovou platformu a datové aplikace napříč několika zeměpisnými oblastmi, bude připojení o něco složitější.

Nasazení ve více regionech obecně mají předplatné centra připojení v jednotlivých umístěních Azure. Pokud máte například služby spuštěné ve Východ USA a Západní Evropě, zřídíte předplatné uzlu konektivity se sdílenými síťovými prostředky v každé oblasti. Mezi sdílené síťové prostředky patří:

  • Síťová virtuální zařízení (například Azure Firewall)
  • Brány ExpressRoute
  • Brány VPN
  • Virtuální sítě centra (v architektuře hvězdicové topologie) nebo centra vWAN (v nastavení vWAN)

Připojení mezi oblastmi Obrázek 1: Připojení mezi oblastmi

V architektuře hub-spoke-spoke-hub jsou virtuální sítě připojovacích uzlů často propojeny pomocí Globálního propojení virtuálních sítí. Pro větší prostředí je běžnou alternativou použití expressRoute Global Reach. Bez ohledu na to, kterou možnost připojení zvolíte, můžete dosáhnout globálního směrování a propojení mezi paprskovými sítěmi napříč několika zeměpisnými oblastmi. To znamená, že můžete přesouvat data mezi oblastmi pomocí síťových virtuálních zařízení, skupin zabezpečení sítě a směrovacích tabulek, vzhledem k tomu, že provoz není v žádném předplatném připojení blokovaný.

Důležitý

Tento článek a další články v části Síťování popisují mezipodnikové jednotky, které sdílejí data. Nemusí to ale být vaše počáteční strategie a že musíte začít nejprve na základní úrovni.

Navrhněte sítě tak, abyste mohli nakonec implementovat naše doporučené nastavení mezi cílovými zónami dat. Ujistěte se, že cílové zóny správy dat jsou přímo připojené k cílovým zónám řízení.

Můžete propojit cílové zóny dat napříč oblastmi pomocí globálního přímého propojování virtuálních sítí. V tomto nastavení, pokud budeme pokračovat v našem předchozím ukázkovém scénáři, virtuální počítač v Západní Evropě přistupuje přímo k privátnímu koncovému bodu úložiště ve východní části USA, aniž by se spoléhal na architektury sítě typu hub a spoke nebo sítě virtuální WAN. Data přímo načítá virtuální počítač přes privátní koncový bod, zpracuje se a pak se uloží zpět do účtu úložiště v oblasti Západní Evropa.

Správa přístupu uživatelů v globálním propojení virtuálních sítí

Pro některou z navrhovaných možností připojení cílové zóny dat mezi oblastmi neexistují žádné konkrétní výhody ani nevýhody.

Shrnutí: /

Správa služeb v globálním propojení virtuálních sítí

Propojení globálních virtuálních sítí nemá žádné virtuální síťové zařízení, které by fungovalo jako jediný bod selhání nebo snižovalo propustnost. Data se neodesílají prostřednictvím center připojení, takže nemusíte škálovat virtuální zařízení a brány v rámci center připojení. Tento nedostatek škálování snižuje režijní náklady na správu základního týmu platformy Azure. Nemusíte také povolovat jednotlivá připojení mezi oblastmi. Vaše datové týmy mají přístup k datům z cílových zón dat v jiných oblastech, aniž by musely čekat na změny směrovací tabulky.

V tomto návrhu sítě už centrální tým platformy Azure nemůže kontrolovat a protokolovat veškerý provoz pomocí brány firewall vrstvy 7. Scénář analýzy v cloudovém měřítku je ale koherentní platforma zahrnující více předplatných, která umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhoda. Síťové záznamy můžete zaznamenávat pomocí tokových protokolů skupiny zabezpečení sítě. Pomocí nastavení diagnostiky specifické pro službu můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb.

Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí definic Azure Policy pro nastavení diagnostiky.

V některých scénářích je potřeba omezit omezení kvůli zákonným nebo právním dopadům. Můžete mít například místní nařízení, které vyžaduje, aby určité datové sady zůstaly v datacentru částic, takže je nesmíte přenášet napříč oblastmi. Můžete se spolehnout na skupiny zabezpečení sítě, které vám pomůžou s dodržováním tohoto typu pravidla, takže provoz může přecházet pouze v jednom směru z USA – východ do Západní Evropy, a ne naopak. V rámci skupin zabezpečení sítě můžete zajistit, aby byl provoz pocházející z OBLASTI USA – východ odepřen, zatímco provoz pocházející z západní Evropy je povolený.

Tento přístup k řešení nemá vliv na šířku pásma a latenci a umožňuje zákazníkům zůstat v souladu se zásadami a současně kombinovat datové sady z více oblastí. Tato možnost také nemá žádný vliv na vaši architekturu DNS a umožňuje používat řešení nativní pro Azure založené na zónách Azure Private DNS.

Shrnutí:

Globální náklady na peering virtuálních sítí

Poznámka

Při přístupu k soukromému koncovému bodu prostřednictvím propojené sítě se vám budou účtovat pouze samotný soukromý koncový bod, a ne za propojení virtuálních sítí (VNet peering). Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?.

Díky tomuto návrhu sítě se vám budou účtovat vaše privátní koncové body (za hodinu) a veškerý příchozí a odchozí provoz odesílaný přes ně. Musíte také zaplatit náklady na přenos dat pro provoz mezi oblastmi. Nebudou vám účtovány žádné náklady za globální propojení virtuálních sítí pro příchozí a odchozí data a má to významné úspory ve srovnání s tradiční možností paprsek-uzel-uzel-paprsek.

Shrnutí:

Šířka pásma a latence při propojení globálních virtuálních sítí

Dopad na šířku pásma a latenci je nižší při globálním propojení virtuálních sítí (Global Peering) než u tradiční možnosti hvězdicové architektury. Globální párování virtuálních sítí obsahuje nižší počet hopů pro výměnu dat mezi regiony v zóně datového uložení a nemá žádná síťová virtuální zařízení omezující propustnost. Jedinými věcmi, které diktují šířku pásma a latenci, které můžete dosáhnout pro provoz mezi oblastmi, jsou fyzické limity našich datacenter (rychlost kabelů, bran a směrovačů optických vláken).

Shrnutí:

Souhrn globálního propojení virtuálních sítí

Globální partnerský vztah virtuálních sítí mezi cílovými zónami dat v různých oblastech nabízí obrovské výhody, zejména když se přenos dat mezi oblastmi zvyšuje v rámci datové platformy. Zjednodušuje správu služeb pro základní tým platformy Azure a zejména výhody použití případů, které vyžadují nízkou latenci a velkou šířku pásma. Nabízí také významné úspory nákladů oproti tradiční možnosti návrhu paprskového uspořádání.

Další možností pro přenos dat mezi regiony je tradiční návrh hvězdicového uspořádání s centrálním uzlem. Pokud v našem ukázkovém scénáři virtuální počítač v datové přistávací zóně A hostované v oblasti Západní Evropa načte datovou sadu uloženou v úložišti z datové přistávací zóny B hostované v oblasti USA – východ, data procházejí dvěma napojeními místních virtuálních sítí (připojení mezi centrem a okraji), jedním globálním napojením virtuálních sítí (připojení mezi rozbočovači) a dvěma branami nebo síťovými virtuálními zařízeními, než je načte virtuální počítač a poté se přesunou zpět do místního úložiště.

Správa uživatelských přístupů v tradiční architektuře typu paprsek-centrum-centrum-paprsek.

Pro některou z navrhovaných možností připojení cílové zóny dat mezi oblastmi neexistují žádné konkrétní výhody ani nevýhody.

Shrnutí: /

Správa služeb v tradičním návrhu paprsek-hub-hub-paprsek architektury

Tento přístup řešení je dobře známý a konzistentní s jinými vzory připojení mezi oblastmi, což usnadňuje přijetí a implementaci. Nemá také žádný vliv na architekturu DNS a umožňuje používat řešení nativní pro Azure založené na zónách Azure Private DNS.

I když tato možnost připojení funguje bez problémů, pokud ji nastavíte správně, má nevýhodu. Provoz mezi oblastmi bývá ve výchozím nastavení často odepřen a musí být povolen jednotlivě podle konkrétních případů. Lístek musí být odeslán vašemu základnímu týmu platformy Azure pro každý požadavek na přístup k datům napříč oblastmi, aby váš tým mohl povolit všechna konkrétní připojení mezi virtuálním počítačem a účtem úložiště napříč oblastmi. Tento proces výrazně zvyšuje režijní náklady na správu. Zpomalí se také týmy datových projektů, protože nemají přístup k datům, která potřebují.

Měli byste si také uvědomit, že v této možnosti fungují centra připojení jako jediné body selhání. V případě výpadku síťového virtuálního zařízení nebo brány dojde k selhání připojení a odpovídajících datových platforem. Máte také vysoké riziko chybné konfigurace tras v centrech připojení. Tato chybná konfigurace může způsobit vážné výpadky datové platformy a vést k řadě závislých pracovních postupů a selhání datových produktů.

Při použití tohoto řešení byste měli monitorovat množství dat, která potřebujete k přenosu mezi oblastmi. V průběhu času může toto monitorování zahrnovat gigabajty nebo terabajty dat procházejících centrálními instancemi. Vzhledem k tomu, že šířka pásma síťových virtuálních zařízení je často omezená na propustnost jednoho nebo dvoumístného gigabajtu, můžou zařízení fungovat jako kritický kritický bod, který omezuje tok provozu mezi oblastmi a možností sdílení vašich datových prostředků. Kvůli tomuto kritickému bodu můžou vaše sdílené síťové prostředky vyžadovat mechanismy škálování, které jsou často časově náročné a nákladné a můžou mít vliv na jiné úlohy ve vašem tenantovi.

Shrnutí:

Tradiční hvězdicové centrum – náklady na návrhHub-Spoke

Poznámka

Při přístupu k privátnímu koncovému bodu v rámci propojené sítě vám budou účtovány pouze samotný privátní koncový bod, a ne propojení virtuálních sítí. Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?.

V tradičním návrhu hvězdicové hvězdicové hvězdicové architektury se vám budou účtovat privátní koncové body dvou účtů úložiště (za hodinu) a veškerý příchozí a výchozí provoz odesílaný přes ně. Účtuje se vám také za příchozí a odchozí datový provoz při propojení jedné místní virtuální sítě a globálního propojení virtuálních sítí mezi vašimi centry připojení. Nicméně, za první propojení virtuálních sítí se vám neúčtují poplatky, jak jsme vysvětlili v předchozí poznámce.

Pokud zvolíte tento návrh sítě, účtují se vám také významné náklady na virtuální zařízení centrální sítě. Tyto náklady jsou způsobené tím, že musíte buď zakoupit dodatečné licence pro škálování zařízení na základě poptávky, nebo zaplatit poplatek za zpracovaný gigabajt, stejně jako u služby Azure Firewall.

Shrnutí:

Šířka pásma a latence v návrhu tradiční architektury paprsek-uzel-uzel-paprsek

Tento návrh sítě má závažná omezení šířky pásma. Virtuální zařízení vaší centrální sítě se stávají kritickými překážkami, jak vaše platforma roste, což omezuje využití zón pro uložení dat napříč regiony a sdílení vašich datových sad. Zároveň je pravděpodobné, že se v průběhu času vytvoří více kopií datových sad. Tento návrh má také velký vliv na latenci, což je zvláště důležité pro scénáře analýzy v reálném čase, protože vaše data procházejí mnoha uzly.

Shrnutí:

Návrh tradičního modelu typového hubově-paprskového systému

Návrh typu "paprsek-náboj-náboj-paprsek" je dobře známý a zavedený v mnoha organizacích, což usnadňuje zavedení v existujícím prostředí. Má ale významné nevýhody pro správu služeb, náklady, šířku pásma a latenci. Tyto problémy jsou obzvláště patrné, protože počet případů použití napříč oblastmi roste.

Závěr

Globální virtuální síťové propojení má mnoho výhod oproti klasickému hvězdicovému návrhu, jelikož je nákladově efektivní, snadno spravovatelné a poskytuje spolehlivé připojení napříč regiony. I když tradiční návrh hvězdicové topologie může být realizovatelný, pokud je objem dat a potřeba výměny dat mezi regiony nízké, doporučujeme použít globální propojení virtuálních sítí, protože objem dat, která potřebujete k výměně napříč regiony, roste.

Další kroky