Paprskové sítě

Nejběžnější vzory návrhu sítí v Azure zahrnují vytváření hvězdicové topologie virtuální sítě v jedné nebo několika oblastech Azure, volitelně připojené k místním sítím přes Azure ExpressRoute nebo tunely virtuální privátní sítě (VPN) typu site-to-site přes veřejný internet.

Většina průvodců návrhem se zaměřuje na provoz aplikací do těchto virtuálních sítí od uživatelů v interních, místních sítích nebo z internetu (to, co odvětví obvykle označuje provoz na sever-jih, protože je často reprezentován svislými čárami v síťových diagramech). Tento článek se zaměřuje na různé vzory, které jsou k dispozici pro provoz východ-západ. To znamená, že komunikace probíhá mezi úlohami nasazenými ve virtuálních sítích Azure, a to buď v jedné oblasti, nebo v různých oblastech.

Zajištění, aby návrh sítě splňoval požadavky na provoz východ-západ, je zásadní pro zajištění výkonu, škálovatelnosti a odolnosti vašich aplikací, které běží v Azure.

Potenciální případy použití

Paprskový provoz může být důležitý v několika scénářích:

• Různé úrovně jedné aplikace jsou v samostatných virtuálních sítích. Například hraniční síťové servery (označované také jako servery DMZ) v hraniční virtuální síti komunikují s aplikačními službami v interní virtuální síti.
• Aplikační úlohy v různých prostředích (vývoj, příprava, produkční prostředí) musí replikovat data mezi sebou.
• Různé aplikace nebo mikroslužby musí vzájemně komunikovat.
• Databáze musí replikovat data napříč oblastmi, aby se zajistila kontinuita podnikových procesů v případě havárie.
• Uživatelé se nacházejí ve virtuálních sítích Azure. Používají například Azure Virtual Desktop.

Vzory a topologie pro komunikaci mezi paprsky

Existují dvě hlavní topologie, které můžete použít v návrzích Azure, které protínají více virtuálních sítí: tradiční hvězdicovou hvězdicovou síť aAzure Virtual WAN. V prostředí Virtual WAN spravuje Microsoft virtuální síť rozbočovače a všechno v něm. V tradičním hvězdicovém prostředí spravujete virtuální síť centra.

Topologie Virtual WAN a hvězdicové topologie jsou příklady architektur, ve kterých úlohy běží v paprskových virtuálních sítích a připojení k místnímu prostředí jsou centralizované v centrální virtuální síti. Tolik konceptů, které jsme vysvětlili v tomto článku, platí pro návrhy hvězdicové i virtuální sítě WAN.

Existují dva hlavní vzory pro vzájemné propojení paprskových virtuálních sítí:

• Paprsky jsou vzájemně propojené přímo. Partnerské vztahy virtuálních sítí nebo tunely VPN se vytvářejí mezi paprskovými virtuálními sítěmi, aby poskytovaly přímé připojení bez procházení virtuální sítě rozbočovače.
• Paprsky komunikují přes síťové zařízení. Každá paprsková virtuální síť má partnerský vztah ke službě Virtual WAN nebo k centrální virtuální síti. Zařízení směruje provoz z paprsku do paprsku. Zařízení může spravovat Microsoft (stejně jako virtual WAN) nebo vy.

Model 1: Paprsky jsou vzájemně propojené přímo

Přímá připojení mezi paprsky obvykle nabízejí lepší propustnost, latenci a škálovatelnost než připojení, která procházejí síťovým virtuálním zařízením v centru. Odesílání provozu prostřednictvím síťových virtuálních zařízení může do provozu přidat latenci, pokud jsou síťová virtuální zařízení v jiné zóně dostupnosti a při odesílání provozu přes centrum je potřeba projít alespoň dva partnerské vztahy virtuálních sítí. Existuje několik možností pro přímé propojení dvou paprskových virtuálních sítí: partnerské vztahy virtuálních sítí, Azure Virtual Network Manager a tunely VPN.

• Partnerský vztah virtuálních sítí Mezi výhody přímých partnerských vztahů virtuálních sítí nad paprsky patří:

  • Nižší náklady, protože se vyžaduje méně směrování peeringu virtuálních sítí.
  • Lepší výkon, protože provoz nemusí procházet žádným síťovým zařízením, které představuje latenci nebo potenciální kritické body.

  Mezi další scénáře patří připojení mezi tenanty. Možná ale budete muset zkontrolovat provoz mezi paprskovými virtuálními sítěmi, což může vyžadovat odesílání provozu prostřednictvím centralizovaných síťových zařízení v centrální virtuální síti.

• Azure Virtual Network Manager. Kromě výhod, které partnerský vztah virtuálních sítí nabízí, poskytuje Azure Virtual Network Manager službu pro správu, která umožňuje spravovat prostředí virtuální sítě a vytváří připojení ve velkém měřítku. Pomocí Azure Virtual Network Manageru můžete vytvořit tři typy topologií napříč předplatnými pro stávající i nové virtuální sítě:

  • Hvězdicová architektura s paprsky, které nejsou vzájemně propojené.

  • Hvězdicové hvězdicové paprsky, které jsou vzájemně přímo propojené, bez jakéhokoli segmentu směrování uprostřed.

  • Skupina sítí virtuálních sítí, které jsou vzájemně propojené.

    

    Stáhněte si všechny diagramy Visia v tomto článku.

    Když vytvoříte hvězdicovou topologii pomocí Azure Virtual Network Manageru, ve kterém jsou paprsky vzájemně propojené, přímé připojení mezi paprskovými virtuálními sítěmi ve stejné skupině sítí se automaticky vytvoří obousměrně. Pomocí Azure Virtual Network Manageru můžete staticky nebo dynamicky vytvářet paprskové virtuální sítě členy konkrétní skupiny sítě, která automaticky vytvoří připojení pro libovolnou virtuální síť.

    Můžete vytvořit několik skupin sítě pro izolaci clusterů paprskových virtuálních sítí od přímého připojení. Každá skupina sítí poskytuje stejnou oblast a podporu více oblastí pro připojení paprsků k paprskům. Nezapomeňte zůstat pod maximálními limity pro Azure Virtual Network Manager, které jsou popsané v nejčastějších dotazech k Azure Virtual Network Manageru.

• Tunely VPN propojující virtuální sítě. Služby VPN můžete nakonfigurovat pro přímé propojení paprskových virtuálních sítí pomocí bran VPN microsoftu nebo síťových virtuálních zařízení VPN třetích stran. Výhodou této možnosti je, že paprskové virtuální sítě se propojují mezi komerčními a suverénními cloudy v rámci stejného poskytovatele cloudu nebo připojení mezi poskytovateli cloudu. Pokud jsou v každé paprskové virtuální síti softwarově definované síťové virtuální zařízení (SD-WAN), může tato konfigurace usnadnit použití řídicí roviny a funkce poskytovatele třetí strany ke správě připojení k virtuální síti.

  Tato možnost vám také pomůže splnit požadavky na dodržování předpisů pro šifrování provozu napříč virtuálními sítěmi v jednom datacentru Azure, které ještě šifrování MACsec neposkytuje. Tato možnost má ale vlastní sadu výzev z důvodu omezení šířky pásma tunelů IPsec (1,25 Gb/s na tunel) a omezení návrhu, která mají brány virtuální sítě v hvězdicových virtuálních sítích: Pokud má paprsková virtuální síť bránu virtuální sítě, není možné ji připojit ke službě Virtual WAN nebo použít bránu virtuální sítě centra pro připojení k místním sítím.

Model 1: Jedna oblast

Bez ohledu na technologii, kterou používáte k vzájemnému propojení paprskových virtuálních sítí, by topologie sítě vypadaly jako v jedné oblasti:

Model 1: Více oblastí

Návrhy, které vzájemně propojují všechny paprskové virtuální sítě, je možné rozšířit také do několika oblastí. V této topologii je Azure Virtual Network Manager ještě důležitější, aby se snížila administrativní režie při údržbě požadovaného velkého počtu připojení.

Když mezi sebou přímo propojíte paprskové virtuální sítě v plně síťované topologii, musíte zvážit potenciálně vysoký počet požadovaných partnerských vztahů virtuálních sítí. Tento problém znázorňuje následující diagram. V tomto scénáři se důrazně doporučuje Azure Virtual Network Manager, abyste mohli automaticky vytvářet připojení virtuální sítě.

Model 2: Paprsky komunikující přes síťové zařízení

Místo přímého propojení paprskových virtuálních sítí můžete pomocí síťových zařízení směrovat provoz mezi paprsky. Síťová zařízení poskytují další síťové služby, jako je hloubková kontrola paketů a segmentace provozu nebo monitorování, ale můžou zavádět kritické body latence a výkonu, pokud nejsou správně velké. Tato zařízení se obvykle nacházejí ve virtuální síti centra, ke které se paprsky připojují. Pro přesměrování provozu mezi paprsky existuje několik možností použití síťového zařízení:

• Směrovač rozbočovače Virtual WAN. Virtual WAN je plně spravovaný Microsoftem, obsahuje virtuální směrovač, který přiláká provoz z paprsků a směruje ho do jiné virtuální sítě, která je připojená k Virtual WAN, nebo k místním sítím prostřednictvím ExpressRoute nebo tunelů VPN typu site-to-site nebo point-to-site VPN. Směrovač Virtual WAN automaticky vertikálně navyšuje a snižuje kapacitu, takže je potřeba zajistit, aby objem provozu mezi paprsky zůstal v mezích virtuální sítě WAN.

• Azure Firewall.Azure Firewall je síťové zařízení spravované Microsoftem a je možné ho nasadit v centrálních virtuálních sítích, které spravujete, nebo v centrech Virtual WAN. Může předávat pakety PROTOKOLU IP a může je také kontrolovat a používat pravidla segmentace provozu definovaná v zásadách. Poskytuje automatické vertikální navýšení kapacity na limity služby Azure Firewall, aby se nestal kritickým bodem. Mějte na paměti, že Azure Firewall poskytuje předvykoncované funkce pro více oblastí jenom v případech, kdy se používá se službou Virtual WAN. Bez služby Virtual WAN je potřeba implementovat trasy definované uživatelem, abyste dosáhli komunikace mezi oblastmi paprsky a paprsky.

• Síťová virtuální zařízení třetích stran. Pokud dáváte přednost síťovému virtuálnímu zařízení od partnera Microsoftu k provádění směrování a segmentace sítě, můžete síťová virtuální zařízení nasadit buď v hvězdicové topologii, nebo topologii Virtual WAN. Další informace najdete v tématu Nasazení vysoce dostupných síťových virtuálních zařízení nebo síťových virtuálních zařízení v centru Virtual WAN. Musíte mít jistotu, že síťové virtuální zařízení podporuje šířku pásma, kterou generuje komunikace mezi paprsky.

• Azure VPN Gateway. Bránu Azure VPN můžete použít jako typ dalšího směrování trasy definované uživatelem, ale Microsoft nedoporučuje používat brány virtuální sítě VPN ke směrování provozu paprsku do paprsku. Jsou navržené pro šifrování provozu do místních lokalit nebo uživatelů VPN. Například neexistuje žádná záruka šířky pásma mezi paprsky, které může brána VPN směrovat.

• ExpressRoute. V určitých konfiguracích může brána ExpressRoute inzerovat trasy, které přilákají komunikaci paprsku do paprsku, a odesílat provoz do hraničního směrovače Microsoftu, kde je směrována do cílového paprsku. Microsoft tento scénář důrazně nedoporučuje, protože zavádí latenci odesláním provozu do páteřní hraniční sítě Microsoftu a zpět. Kromě toho Microsoft tento přístup nedoporučuje, a to kvůli jedinému bodu selhání a velkému poloměru výbuchu. Tento scénář také představuje několik problémů způsobených dodatečným tlakem na infrastrukturu ExpressRoute (bránu a fyzické směrovače). Tento dodatečný tlak může způsobit výpadky paketů.

V hvězdicových síťových návrzích, které mají centralizované síťové virtuální zařízení, je zařízení obvykle umístěné v centru. Partnerské vztahy virtuálních sítí mezi hvězdicovými virtuálními sítěmi je potřeba vytvořit ručně nebo automaticky pomocí Azure Virtual Network Manageru:

• Ruční partnerské vztahy virtuálních sítí Tento přístup stačí, když máte malý počet paprskových virtuálních sítí, ale vytváří režijní náklady na správu ve velkém měřítku.

• Azure Virtual Network Manager. Jak jsme si poznamenali dříve, Azure Virtual Network Manager poskytuje funkce pro správu prostředí virtuální sítě a partnerských vztahů ve velkém měřítku. Konfigurace peeringu mezi hvězdicovými virtuálními sítěmi se pro skupiny sítí konfigurují automaticky obousměrně.

  Azure Virtual Network Manager poskytuje možnost staticky nebo dynamicky přidávat členství v paprskové virtuální síti do konkrétní skupiny sítě, která automaticky vytvoří připojení peeringu pro nové členy. Paprskové virtuální sítě ve skupinách sítí můžou pro připojení používat hvězdicovou síť VPN nebo brány ExpressRoute. Nezapomeňte zůstat pod maximálními limity pro Azure Virtual Network Manager.

Model 2: Jedna oblast

Následující diagram znázorňuje hvězdicovou topologii s jednou oblastí, která odesílá provoz mezi paprsky přes bránu firewall Azure nasazenou ve virtuální síti centra. Provoz se přesměruje do centralizovaného zařízení v centru prostřednictvím tras definovaných uživatelem, které se aplikují na podsítě paprsků.

Za určitých okolností může být výhodné oddělit síťová virtuální zařízení, která zpracovávají paprskový a internetový provoz pro zajištění škálovatelnosti. Toto oddělení můžete provést takto:

• Ladění směrovacích tabulek v paprskech tak, aby odesílaly privátní adresy (ty, které mají trasu pro předpony RFC 1918) do síťového virtuálního zařízení zodpovědného za provoz Azure-to-Azure a Azure-to-on-premises (označované také jako provoz východ-západ).
• Ladění internetového provozu (který má trasu 0.0.0.0/0) do druhého síťového virtuálního zařízení. Toto síťové virtuální zařízení zodpovídá za provoz azure-internet (označovaný také jako provoz ze severu na jih).

Následující diagram znázorňuje tuto konfiguraci:

Model 2: Více oblastí

Stejnou konfiguraci můžete rozšířit na více oblastí. Například v hvězdicovém návrhu, který používá Azure Firewall, byste měli použít další směrovací tabulky do podsítí služby Azure Firewall v každém centru pro paprsky ve vzdálené oblasti. Tato konfigurace zajišťuje, že provoz mezi oblastmi je možné předávat mezi bránami firewall Azure v každé virtuální síti centra. Meziregionální provoz mezi paprskovými virtuálními sítěmi pak prochází oběma branami firewall Azure. Další informace najdete v tématu Azure Firewall pro směrování hvězdicové topologie:

Varianta návrhu s samostatnými bránami Azure Firewall nebo síťovými virtuálními zařízeními pro provoz na severu a východě je také možná v hvězdicové topologii s více oblastmi:

Virtual WAN vytvoří podobnou topologii a převezme složitost směrování. Dělá to jak v centrech (které Microsoft spravuje), tak i v paprskech (kde je možné vkládané trasy a není potřeba je ručně definovat ve směrovacích tabulkách). Takže správce sítě potřebuje pouze připojit paprskové virtuální sítě k centru Virtual WAN a nemusí se starat o přesměrování provozu mezi oblastmi.

Hybridní vzory

Mnoho situací vyžaduje hybridní přístup, který kombinuje dva vzory popsané výše. V tomto přístupu musí provoz mezi určitými paprsky přecházet přes přímá připojení, ale zbývající paprsky komunikují přes centrální síťové zařízení. Například v prostředí Virtual WAN můžete přímo připojit dva konkrétní paprsky, které mají vysokou šířku pásma a požadavky na nízkou latenci. Další scénář zahrnuje paprskové virtuální sítě, které jsou součástí jednoho prostředí. Můžete například povolit, aby se paprsková vývojová virtuální síť připojila přímo k jiné paprskové vývojové virtuální síti, ale vynuťte komunikaci úloh vývojových a produkčních prostředí prostřednictvím centrálního zařízení.

Dalším běžným vzorem je propojení paprsků v jedné oblasti prostřednictvím přímých partnerských vztahů virtuálních sítí nebo připojených skupin Azure Virtual Network Manageru, ale umožňuje meziregionální provoz přes síťová virtuální zařízení. Hlavní motivací pro tento model je obvykle snížení počtu partnerských vztahů virtuálních sítí v architektuře. Ve srovnání s prvním modelem (přímé připojení mezi paprsky) je jednou nevýhodou zavedenou v tomto modelu více směrování peeringu virtuálních sítí pro provoz mezi oblastmi. Tyto segmenty směrování zvyšují náklady z důvodu více partnerských vztahů virtuálních sítí, které se protínají. Další nevýhodou je dodatečné zatížení síťových virtuálních zařízení rozbočovače pro zajištění veškerého provozu napříč oblastmi.

Stejné návrhy platí pro Virtual WAN. Jedním z aspektů je ale to, že přímé připojení mezi paprskovými virtuálními sítěmi je potřeba nakonfigurovat ručně přímo mezi virtuálními sítěmi, a ne prostřednictvím prostředku Virtual WAN. Azure Virtual Network Manager v současné době nepodporuje architektury založené na službě Virtual WAN. Příklad:

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Jay Li | Vedoucí produktový manažer
• Jose Moreno | Hlavní zákaznický inženýr
• Alejandra Palacios | Vedoucí zákaznický inženýr infrastruktury Azure

Další přispěvatelé:

• Mick Alberts | Technický spisovatel
• Mohamed Hassan | Hlavní manažer pm
• Andrea Michael | Programový manažer
• Yasukuni Morishima | Zákaznický inženýr II
• Jithin PP| Customer Engineer

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Architektura přechodu na cloud: Topologie sítě cílové zóny a možnosti připojení
• Partnerský vztah virtuální sítě
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Zabezpečení síťového připojení v Azure
• Úvod do virtuálních sítí Azure

Související prostředky

• Hvězdicová síťová topologie v Azure
• Hvězdicová síťová topologie se službou Azure Virtual WAN
• Tradiční síťová topologie Azure