Připojení cílové zóny dat v jedné oblasti

Cílová zóna správy dat, cílové zóny dat a všechny služby v nich jsou nastavené ve stejné oblasti v nastavení jedné oblasti. Všechny cílové zóny jsou ve stejném předplatném centra připojení. Toto předplatné hostuje sdílené síťové prostředky, které můžou zahrnovat síťové virtuální zařízení (například bránu Azure Firewall), bránu ExpressRoute, bránu virtuální privátní sítě (VPN), centrální virtuální síť nebo virtuální síť WAN (centrum virtuální sítě WAN).

Obrázek 1: Jedna oblast Připojení ivity

Na základě aktuálních možností síťových služeb Azure doporučujeme použít síťovou architekturu se sítí. Měli byste nastavit partnerský vztah virtuálních sítí mezi:

• Centrum Připojení ivity a zóna Správa dat
• Centrum Připojení ivity a každá cílová zóna dat
• Zóna Správa dat a každá cílová zóna dat
• Každá cílová zóna dat

Tento článek popisuje výhody a nevýhody jednotlivých možností síťové architektury, které jsme zvážili pro analýzy v cloudovém měřítku.

První část tohoto článku se zaměřuje na model s jednou oblastí, kde jsou Správa dat zóna a všechny cílové zóny dat hostované ve stejné oblasti.

Každý vzor návrhu se vyhodnocuje pomocí následujících kritérií:

• Náklady
• Správa uživatelských přístupů
• Správa služeb
• Šířka pásma
• Latence

Jednotlivé možnosti návrhu budeme analyzovat s následujícím případem použití cílové zóny napříč daty:

Poznámka:

Virtuální počítač B (VM B) hostovaný v cílové zóně dat B načte datovou sadu z účtu úložiště A hostovaného v cílové zóně dat A. Potom virtuální počítač B tuto datovou sadu zpracuje a uloží ji do účtu úložiště B, který je hostovaný v cílové zóně dat B.

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í.

Síťová architektura se sítěmi (doporučeno)

Při přijímání analýz v cloudovém měřítku doporučujeme použít architekturu sítě. Kromě existujícího návrhu hvězdicové sítě nastaveného v rámci vašeho tenanta musíte provést dvě věci, které implementují architekturu sítě:

• Přidejte partnerské vztahy virtuálních sítí mezi všechny virtuální sítě cílové zóny dat.
• Přidejte párování virtuálních sítí mezi cílovou zónou správy dat a všemi cílovými zónami dat.

V našem ukázkovém scénáři data načtená z účtu úložiště A provozují připojení partnerského vztahu virtuálních sítí (2) nastavené mezi dvěma virtuálními sítěmi cílové zóny dat. Načte a zpracuje ho virtuální počítač B (3) a (4) a pak se odešle přes místní privátní koncový bod (5), který se uloží do účtu úložiště B.

V tomto scénáři data nepředávají centrum Připojení ivity. Zůstává v datové platformě, která se skládá z cílové zóny správy dat a jedné nebo více cílových zón dat.

Obrázek 2: Architektura sítě se sítěmi

Správa uživatelských přístupů v síťové architektuře se sítí

V návrhu architektury sítě vyžadují týmy datových aplikací jenom dvě věci, které umožňují vytvářet nové služby (včetně privátních koncových bodů):

• Zápis přístupu ke své vyhrazené skupině prostředků v cílové zóně dat
• Připojení přístupu k určené podsíti

V tomto návrhu můžou týmy datových aplikací nasazovat vlastní privátní koncové body. Pokud mají potřebná přístupová práva pro připojení privátních koncových bodů k podsíti v daném paprsku, nemusí vaše týmy při nastavování potřebného připojení podporovat.

Souhrn:

Správa služeb v síťové architektuře se sítí

V návrhu síťové architektury sítě nedochází k žádnému síťovému virtuálnímu zařízení jako jediný bod selhání nebo omezování. Nedostatek datových sad, které se odesílají přes centrum Připojení ivity, snižuje režii vašeho centrálního týmu platformy Azure za předpokladu, že není potřeba škálovat toto virtuální zařízení.

To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.

Se všemi prostředky hostovanými v rámci jednoho předplatného už centrální tým platformy Azure nekontroluje všechna data v centrálním centru Připojení ivity. Síťové protokoly můžete stále 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.

Tento návrh také umožňuje vytvořit nativní řešení DNS Azure založené na Privátní DNS zónách. Životní cyklus záznamů DNS A můžete automatizovat prostřednictvím definic Azure Policy pro privátní skupiny DNS.

Souhrn:

Náklady na síťovou architekturu 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, 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 tomto návrhu sítě platíte pouze za:

• vaše privátní koncové body (za hodinu)
• příchozí a výchozí provoz odeslaný prostřednictvím privátních koncových bodů za účelem načtení nezpracované datové sady (1) a uložení zpracované datové sady (6)

Partnerský vztah virtuálních sítí se neúčtuje (2), což je důvod, proč má tato možnost minimální náklady.

Souhrn:

Šířka pásma a latence v síťové architektuře s oky

Tento návrh nemá žádná známá omezení šířky pásma nebo latence, protože žádná síťová virtuální zařízení neomezí propustnost pro výměnu dat cílové zóny napříč daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).

Souhrn:

Souhrn architektury sítě

Pokud plánujete přijmout analýzy na úrovni cloudu, doporučujeme použít návrh sítě se sítí. Síť se sítí nabízí maximální šířku pásma a nízkou latenci s minimálními náklady, ale neposkytuje žádné kompromisy týkající se správy přístupu uživatelů nebo vrstvy DNS.

Pokud potřebujete vynutit další zásady sítě v rámci datové platformy, použijte skupiny zabezpečení sítě místo centrálních síťových virtuálních zařízení.

Tradiční hvězdicová architektura (nedoporučuje se)

Návrh hvězdicové architektury sítě je nejobraznější možností a ten, který mnoho podniků přijalo. V něm se v centru Připojení ivity nastaví průchodnost sítě pro přístup k datům v účtu úložiště A z virtuálního počítače B. Data procházejí dvěma partnerskými vztahy virtuálních sítí ((2) a (5)) a síťovým virtuálním zařízením hostovaným uvnitř centra Připojení ivity ((3) a (4)). Potom se data načtou virtuálním počítačem (6) a uloží se zpět do účtu úložiště B (8).

Obrázek 3: Hvězdicová architektura

Správa přístupu uživatelů v tradiční hvězdicové architektuře

V tradičním hvězdicovém návrhu vyžadují týmy datových aplikací jenom dvě věci, aby mohly vytvářet nové služby (včetně privátních koncových bodů):

• Zápis přístupu ke skupině prostředků v cílové zóně dat
• Připojení přístupu k určené podsíti

V tomto návrhu můžou týmy datových aplikací nasazovat vlastní privátní koncové body. Pokud mají potřebná přístupová práva pro připojení privátních koncových bodů k podsíti v daném paprsku, nemusí vaše týmy při nastavování potřebného připojení podporovat.

Souhrn:

Správa služeb v tradiční hvězdicové architektuře

Tento návrh sítě je dobře známý a konzistentní s existujícím nastavením sítě ve většině organizací. Díky tomu je návrh snadno vysvětlit a implementovat. K zajištění překladu plně kvalifikovaného názvu domény v rámci tenanta Azure můžete použít také centralizované řešení DNS nativní pro Azure s Privátní DNS zónami. Použití Privátní DNS Zón umožňuje automatizovat životní cyklus záznamů DNS A prostřednictvím zásad Azure.

Další výhodou tohoto návrhu je směrování provozu přes centrální síťové virtuální zařízení, takže síťový provoz odesílaný z jednoho paprsku do druhého je možné protokolovat a kontrolovat.

Jednou z nevýhod tohoto návrhu je, že centrální tým platformy Azure musí spravovat směrovací tabulky ručně. To je nezbytné k zajištění tranzitivity mezi paprsky, což umožňuje sdílení datových prostředků napříč několika cílovými zónami dat. Správa tras může být v průběhu času složitá a náchylná k chybám a musí být považována za předem.

Další nevýhodou tohoto nastavení sítě je způsob nastavení centrálního síťového virtuálního zařízení. Síťové virtuální zařízení funguje jako jediný bod selhání a může způsobit vážné výpadky v datové platformě, pokud dojde k selhání. S rostoucí velikostí datových sad v rámci datové platformy a nárůstem počtu případů použití cílové zóny napříč daty se prostřednictvím centrálního síťového virtuálního zařízení odesílá více provozu.

V průběhu času to může mít za následek gigabajty nebo dokonce terabajty dat odesílaných prostřednictvím centrální instance. Vzhledem k tomu, že šířka pásma stávajících síťových virtuálních zařízení je často omezená jenom na propustnost jednoho nebo dvoumístného gigabajtu, může se stát kritickým bodem, který kriticky omezuje tok provozu mezi cílovými zónami dat a omezuje sdílení datových prostředků.

Jediným způsobem, jak se tomuto problému vyhnout, je horizontální navýšení kapacity centrálního síťového virtuálního zařízení napříč několika instancemi, což má pro tento návrh velký dopad na náklady.

Souhrn:

Náklady na tradiční hvězdicovou architekturu

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ě?

Pro tuto síť se účtují každou hodinu za privátní koncové body účtů úložiště. Také se vám účtuje příchozí a výchozí provoz odesílaný prostřednictvím privátních koncových bodů, aby se načetla nezpracovaná datová sada (1) a uložila se zpracovaná datová sada (8).

Za příchozí a výchozí přenos dat jednoho partnerského vztahu virtuálních sítí (5) se účtuje zákazník. Jak už bylo zmíněno dříve, první partnerský vztah virtuálních sítí se neúčtuje (2).

Pokud použijete tento návrh sítě (3) a (4)), budete mít nakonec vysoké náklady na virtuální síťové zařízení. Musíte buď zakoupit dodatečné licence a škálovat virtuální zařízení centrální sítě na základě poptávky, nebo platit poplatky zpracovávané za gigabajt, jak to funguje se službou Azure Firewall.

Souhrn:

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

Tento návrh sítě má závažná omezení šířky pásma. Virtuální zařízení centrální sítě se stává kritickým kritickým bodem, protože vaše platforma roste, což omezuje případy použití cílové zóny napříč daty a sdílení datových sad. V průběhu času také pravděpodobně vytvoří více kopií datových sad.

Tento návrh má také vliv na latenci, což je zvláště důležité ve scénářích analýzy v reálném čase.

Souhrn:

Souhrn tradiční hvězdicové architektury

Tento hvězdicový návrh sítě má správu přístupu a některé výhody správy služeb, ale kvůli kritickým omezením správy služeb a šířky pásma a latence nemůžeme tento návrh sítě doporučit pro případy použití cílové zóny napříč daty.

Architektura projekce privátního koncového bodu (nedoporučuje se)

Další možností návrhu je projekce privátních koncových bodů v každé cílové zóně a každé cílové zóně. V tomto návrhu se v každé cílové zóně vytvoří privátní koncový bod pro účet úložiště A. To vede k prvnímu privátnímu koncovému bodu v cílové zóně dat A připojené k virtuální síti v cílové zóně A, druhému privátnímu koncovému bodu připojenému k virtuální síti v cílové zóně dat B atd.

Totéž platí pro účet úložiště B a potenciálně i pro jiné služby v cílových zónách dat. Pokud definujeme počet cílových zón dat jako n, skončíme s n privátními koncovými body pro alespoň všechny účty úložiště a potenciálně další služby v rámci cílových zón dat. To vede k exponenciálnímu zvýšení počtu privátních koncových bodů.

Obrázek 4: Architektura projekce privátního koncového bodu

Vzhledem k tomu, že všechny privátní koncové body konkrétní služby (například účet úložiště A) mají stejný plně kvalifikovaný název domény (napříkladstorageaccounta.privatelink.blob.core.windows.net), toto řešení vytváří problémy ve vrstvě DNS, která se nedá vyřešit pomocí Privátní DNS zón. Místo toho potřebujete vlastní řešení DNS, které dokáže přeložit názvy DNS na základě původu nebo IP adresy žadatele. Díky tomu se VMA připojí k privátním koncovým bodům připojeným k virtuální síti v cílové zóně dat A a aby se virtuální počítač B připojil k privátním koncovým bodům připojeným k virtuální síti v cílové zóně dat B. Můžete to provést pomocí nastavení založeného na Windows Serveru, zatímco životní cyklus záznamů DNS A můžete automatizovat pomocí kombinace protokolu aktivit a Azure Functions.

V tomto nastavení můžete načíst nezpracovanou datovou sadu v účtu úložiště A do virtuálního počítače B tak, že k datové sadě přistupujete přes místní privátní koncový bod (1). Po načtení a zpracování datové sady ((2) a (3)) ji můžete uložit do účtu úložiště B přímým přístupem k místnímu privátnímu koncovému bodu (4). V tomto scénáři nesmí data procházet žádnými partnerskými vztahy virtuálních sítí.

Správa přístupu uživatelů v architektuře projekce privátních koncových bodů

Přístup tohoto návrhu ke správě uživatelských přístupů je podobný přístupu k síťové architektuře v síti. V tomto návrhu ale můžete vyžadovat přístupová práva pro jiné cílové zóny dat, abyste mohli vytvářet privátní koncové body nejen v rámci určené cílové zóny dat a virtuální sítě, ale také v jiných cílových zónách dat a jejich příslušných virtuálních sítích.

Z tohoto důvodu vyžadují týmy datových aplikací tři věci, ne dvě, aby mohly vytvářet nové služby sami:

• Zápis přístupu ke skupině prostředků v určené cílové zóně dat
• Připojení přístupu k jejich určené podsíti
• přístup ke skupině prostředků a podsíti ve všech ostatních cílových zónách dat za účelem vytvoření příslušných místních privátních koncových bodů

Tento návrh sítě zvyšuje složitost vrstvy správy přístupu, protože týmy datových aplikací vyžadují oprávnění v každé cílové zóně dat. Návrh může být také matoucí a vést k nekonzistentnímu řízení přístupu na základě role v průběhu času.

Pokud týmům cílové zóny dat a týmům datových aplikací nejsou udělena potřebná přístupová práva, dojde k problémům popsaným v tradiční hvězdicové architektuře (nedoporučuje se).

Souhrn:

Správa služeb v architektuře projekce privátních koncových bodů

I když se tento návrh sítě podobá návrhu síťové architektury sítě, má tento návrh sítě výhodu, že žádné síťové virtuální zařízení nefunguje jako jediný bod selhání nebo omezování propustnosti. Snižuje také režii na správu centrálního týmu platformy Azure tím, že neodesílá datové sady prostřednictvím centra Připojení ivity, protože není potřeba škálovat virtuální zařízení na více instancí. To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.

Se všemi prostředky hostovanými v rámci jednoho předplatného se provoz nekontroluje v centrálním centru Připojení ivity. Síťové protokoly můžete dál zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě a můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb pomocí diagnostických Nastavení specifických pro službu. Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí zásad Azure. Na druhou stranu se adresní prostor sítě vyžadovaný vaší datovou platformou zvyšuje kvůli exponenciálnímu nárůstu požadovaných privátních koncových bodů, což není optimální.

Hlavními obavami týkajícími se této síťové architektury jsou dříve uvedené výzvy DNS. Nativní řešení Azure nemůžete použít ve formě Privátní DNS zón, takže tato architektura vyžaduje řešení třetí strany schopné přeložit plně kvalifikované názvy domén na základě původu nebo IP adresy žadatele. Musíte také vyvíjet a udržovat nástroje a pracovní postupy pro automatizaci Privátní DNS záznamů A, což výrazně zvyšuje režijní náklady na správu v porovnání s navrhovaným řešením řízeným službou Azure Policy.

Pomocí Privátní DNS zón můžete vytvořit distribuovanou infrastrukturu DNS, ale tím se vytvoří ostrovy DNS, které nakonec způsobují problémy při pokusu o přístup ke službám privátního propojení hostovaným v jiných cílových zónách ve vašem tenantovi. Tento návrh proto není proveditelnou možností.

Souhrn:

Náklady na architekturu projekce privátních koncových bodů

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 tomto návrhu sítě se vám účtují jenom privátní koncové body (za hodinu) a příchozí a výchozí provoz odesílaný těmito privátními koncovými body za načtení nezpracovaných datových sad (1) a ukládání zpracovaných datových sad (4). Kvůli exponenciálnímu zvýšení počtu privátních koncových bodů datové platformy se ale musí očekávat další náklady. Vzhledem k tomu, že se vám účtují poplatky za hodinu, množství dodatečných nákladů závisí na tom, kolik privátních koncových bodů se vytvoří.

Souhrn:

Šířka pásma a latence v architektuře projekce privátních koncových bodů

Tento návrh nemá žádná známá omezení šířky pásma a latence, protože nemá žádná síťová virtuální zařízení omezující propustnost pro výměnu dat cílové zóny mezi daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).

Souhrn:

Souhrn architektury projekce privátního koncového bodu

Exponenciální růst privátních koncových bodů v této síťové architektuře může způsobit ztrátu toho, které privátní koncové body se používají k jakému účelu v jakém umístění. Jste také omezeni problémy se správou přístupu a složitostí vrstvy DNS. Kvůli těmto problémům nemůžeme tento návrh sítě doporučit pro případy použití cílové zóny napříč daty.

Privátní koncové body v architektuře centra Připojení ivity (nedoporučuje se)

Další možností sítě je hostování privátních koncových bodů v centru Připojení ivity a jejich připojení k virtuální síti centra. V tomto řešení hostujete jeden privátní koncový bod pro každou službu ve vaší podnikové virtuální síti. Vzhledem k existující hvězdicové síťové architektuře ve většině společností a faktu, že centrum Připojení ivity hostuje vaše privátní koncové body v tomto řešení, není vyžadována tranzitita. Partnerský vztah virtuálních sítí mezi centrem Připojení ivity a cílovými zónami dat umožňuje přímý přístup.

Data procházejí jedním partnerským vztahem virtuálních sítí mezi centrem Připojení ivity a cílovou zónou dat, aby se načetla datová sada uložená v účtu úložiště A ve virtuálním počítači B. Jakmile se datová sada načte a zpracuje ((3) a (4)), prochází stejným partnerským vztahem virtuálních sítí podruhé (5), než se nakonec uloží do účtu úložiště B prostřednictvím privátního koncového bodu připojeného k virtuální síti centra (6).

Obrázek 5: Privátní koncové body v architektuře centra Připojení ivity

Správa uživatelských přístupů v architektuře centra Připojení ivity

V tomto návrhu sítě potřebují týmy cílové zóny dat a týmy datových aplikací dvě věci, aby bylo možné připojit privátní koncové body k virtuální síti centra:

• Zápis oprávnění ke skupině prostředků ve vašem předplatném centra Připojení ivity
• Připojení oprávnění k virtuální síti centra

Centrum Připojení ivity je určené pro tým platformy Azure vaší organizace a je vyhrazené pro hostování nezbytné a sdílené síťové infrastruktury vaší organizace (včetně bran firewall, bran a nástrojů pro správu sítě). Tato možnost sítě zajišťuje nekonzistentní návrh, protože nesleduje principy správy přístupu ze základních principů cílové zóny na podnikové úrovni. Většina týmů platformy Azure proto tuto možnost návrhu neschválí.

Souhrn:

Správa služeb v architektuře centra Připojení ivity

I když se podobá návrhu síťové architektury se sítí, nemá tento návrh žádné síťové virtuální zařízení, které funguje jako jediný bod selhání nebo omezování propustnosti. Snižuje také režii na správu centrálního týmu platformy Azure tím, že neodesílá datové sady prostřednictvím centra Připojení ivity, protože není potřeba škálovat virtuální zařízení na více instancí. To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.

Se všemi prostředky hostovanými v rámci jednoho předplatného se provoz nekontroluje v centrálním centru Připojení ivity. Síťové protokoly můžete dál zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě a můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb pomocí diagnostických Nastavení specifických pro službu. Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí zásad Azure.

Tento návrh také umožňuje vytvořit nativní řešení DNS Azure založené na Privátní DNS zónách a umožňuje automatizovat životní cyklus záznamu DNS A prostřednictvím zásad Azure.

Souhrn:

náklady na architekturu centra Připojení ivity

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 tomto návrhu sítě se vám účtují jenom vaše privátní koncové body (za hodinu) a příchozí a odchozí provoz odesílaný těmito privátními koncovými body za načtení nezpracované datové sady (1) a uložení zpracované datové sady (6).

Souhrn:

Šířka pásma a latence v architektuře centra Připojení ivity

Tento návrh nemá žádná známá omezení šířky pásma a latence, protože nemá žádná síťová virtuální zařízení omezující propustnost pro výměnu dat cílové zóny mezi daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).

Souhrn:

Souhrn architektury privátních koncových bodů v centru Připojení ivity

I když tento návrh architektury sítě má několik výhod, jeho dříve zmíněná správa přístupu je nekonzistencí, což je podparovat. Tento přístup k návrhu proto nemůžeme doporučit.

Závěr připojení cílové zóny dat v jedné oblasti

Ze všech kontrolovaných možností síťové architektury a jejich výhod a nevýhod je jasná síťová architektura . Má obrovské výhody pro propustnost a správu, což je důvod, proč ho doporučujeme použít při nasazování analýz v cloudovém měřítku. Virtuální sítě peeringové paprsky nebyly dříve běžné a to vedlo k problémům se sdílením datových sad mezi doménami a obchodními jednotkami.

Analýzy v cloudovém měřítku můžete zobrazit jako ucelené řešení, které zahrnuje více předplatných. V nastavení jednoho předplatného se tok síťového provozu rovná toku v síťové architektuře se sítí. V rámci jednoho nastavení předplatného se uživatelé s největší pravděpodobností dostanou k limitům a kvótám na úrovni předplatného platformy, kterým se má analýza na úrovni cloudu vyhnout.

Další kroky

• Cílová zóna dat mezi oblastmi Připojení ivity