Sdílet prostřednictvím


Připojení cílové zóny dat mezi oblastmi

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 oblastech mají obecně předplatné centra připojení v jednotlivých umístěních Azure. Pokud máte například služby spuštěné v oblasti USA – východ i Západní Evropa, nastavíte předplatné centra připojení 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 Gateway
  • Virtuální sítě centra (v hvězdicové architektuře) nebo virtuální sítě WAN (v nastavení virtuální sítě Wan)

Připojení ivity mezi oblastmiObrázek 1: Připojení ivity napříč oblastmi

V architektuře hvězdicového hvězdicového centra jsou virtuální sítě rozbočovačů připojení často propojené pomocí globálního partnerského vztahu 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ítě popisují organizační 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ě zásad správného řízení.

Cílové zóny dat můžete propojit mezi oblastmi pomocí přímého globálního partnerského vztahu virtuálních sítí. Pokud v tomto nastavení budeme pokračovat v našem předchozím ukázkovém scénáři, virtuální počítač v oblasti Západní Evropa přistupuje přímo k privátnímu koncovému bodu účtu úložiště USA – východ bez nutnosti spoléhat se na žádné hvězdicové architektury sítě nebo síťové architektury virtuální sítě 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 uživatelských přístupů v globálním partnerském vztahu 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.

Souhrn: /

Správa služeb v globálním partnerském vztahu virtuálních sítí

Globální partnerský vztah virtuálních sítí nemá žádné síťové virtuální zařízení, které funguje jako jediný bod selhání nebo omezování propustnosti. 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é protokoly můžete zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě. Další protokoly na úrovni aplikací a služeb můžete konsolidovat a ukládat pomocí diagnostických Nastavení specifických pro službu.

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 architekturu DNS a umožňuje používat řešení nativní pro Azure založené na zónách Azure Privátní DNS.

Souhrn:

Globální náklady na partnerský vztah virtuálních sítí

Poznámka:

Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, a ne za partnerský vztah 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ě?

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 za provoz mezi oblastmi. Nebudete ale účtovat žádné globální poplatky za příchozí a výchozí přenos dat v partnerském vztahu virtuálních sítí. Z tohoto důvodu má možnost globálního partnerského vztahu virtuálníchsítích sítě (VNet Peering) důležité výhody tradičních paprskových hvězdicových hvězdic popsaných dále v tomto článku.

Souhrn:

Šířka pásma a latence v globálním partnerském vztahu virtuálních sítí

Dopad na šířku pásma a latenci je v globálním partnerském vztahu virtuálních sítí mnohem nižší než u tradiční možnosti hvězdicové hvězdicové hvězdicové architektury. Globální partnerský vztah virtuálních sítí obsahuje nižší počet segmentů směrování pro výměnu dat cílové zóny mezi oblastmi 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).

Souhrn:

Souhrn globálních partnerských vztahů 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 v rámci datové platformy zvyšuje. 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é náklady oproti tradiční možnosti návrhu hvězdicové hvězdicové hvězdicové architektury.

Další možností přenosu dat mezi oblastmi je tradiční návrh hvězdicového hvězdicového paprsku. Pokud v našem ukázkovém scénáři virtuální počítač v cílové zóně dat A hostovaný v západní Evropě načte datovou sadu uloženou v účtu úložiště z cílové zóny dat B hostované v oblasti USA – východ, data procházejí dvěma místními partnerskými vztahy virtuálních sítí (připojení mezi centrem a paprsky), jeden globální partnerský vztah virtuálních sítí (připojení mezi rozbočovači) a dvě brány nebo síťová virtuální zařízení před načtením virtuálním počítačem a pak se přesunou zpět do místního účtu úložiště.

Správa uživatelských přístupů v tradičním návrhu hvězdicové hvězdicové hvězdicové architektury

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.

Souhrn: /

Správa služeb v tradičním návrhu hvězdicové hvězdicové hvězdicové 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 Privátní DNS.

I když tato možnost připojení funguje bez problémů, pokud ji nastavíte správně, má nevýhodu. Provoz mezi oblastmi je ve výchozím nastavení často odepřen a musí být povolen pro případ. To znamená, že 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ě mezi 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ů. Z tohoto důvodu 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.

Souhrn:

Náklady na návrh tradiční hvězdicové hvězdicové architektury

Poznámka:

Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, a ne za partnerský vztah 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é příchozí a výchozí provoz jednoho místního partnerského vztahu virtuálních sítí a globálního partnerského vztahu virtuálních sítí mezi vašimi rozbočovači připojení. Za první partnerský vztah virtuálních sítí se vám ale nebudou účtovat poplatky, jak jsme vysvětlili v předchozí poznámce.

Pokud zvolíte tento návrh sítě, budou vaše centrální síťová virtuální zařízení také výrazně nákladná. Je to proto, že buď musíte zakoupit dodatečné licence, abyste mohli škálovat zařízení na základě poptávky, nebo musíte zaplatit poplatek za zpracovaný gigabajt, stejně jako u služby Azure Firewall.

Souhrn:

Šířka pásma a latence v návrhu tradiční hvězdicové hvězdicové hvězdicové architektury

Tento návrh sítě má závažná omezení šířky pásma. Virtuální zařízení centrální sítě se stávají kritickými místy, protože vaše platforma roste, což omezuje případy použití cílové zóny dat napříč oblastmi a sdílení 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 segmenty směrování.

Souhrn:

Souhrnný tradiční návrh hvězdicové hvězdicové hvězdicové architektury

Návrh hvězdicové architektury je dobře známý a zavedený v mnoha organizacích, což usnadňuje vytvoření 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í partnerský vztah virtuálních sítí má oproti tradičnímu návrhu hvězdicové architektury mnoho výhod, protože je nákladově efektivní, snadno spravovaný a nabízí spolehlivé připojení napříč oblastmi. I když tradiční návrh hvězdicové architektury může být realizovatelná možnost, zatímco objem dat a potřeba výměny dat mezi oblastmi je nízký, doporučujeme použít globální partnerský vztah virtuálních sítí, protože objem dat, která potřebujete k výměně napříč oblastmi, roste.

Další kroky