Propojení mezi regiony a v multicloudových prostředích

Tento článek vám pomůže připojit Azure úlohy napříč několika oblastmi a rozšířit připojení k dalším poskytovatelům cloudu, jako jsou Amazon Web Services (AWS) a Google Cloud.

Co tento článek popisuje

Tento článek popisuje rozhodnutí o návrhu pro připojení Azure virtuálních sítí mezi oblastmi a vytvoření síťových cest k úlohám běžícím v jiných cloudech. Dozvíte se, kdy použít Global VNet Peering, Virtual WAN, ExpressRoute Global Reach, síť VPN typu site-to-site a Azure Route Server pro scénáře mezi oblastmi a ve více cloudech.

Kdo potřebuje tento článek

Pokud platí jedna nebo více z těchto podmínek, přečtěte si tento článek:

  • Vaše architektura zahrnuje několik Azure oblastí a potřebuje mezi nimi privátní připojení.
  • Potřebujete připojit Azure úlohy k AWS, Google Cloud nebo jiné externí síti.
  • Potřebujete porovnat Global VNet Peering, Virtual WAN, ExpressRoute Global Reach, síť VPN typu site-to-site nebo Azure Route Server.
  • Potřebujete navrhnout odolné připojení pro zotavení po havárii, globální rozšíření nebo vícecloudové operace.

Tip

Postupujete podle scénáře? V horní části stránky vyberte svůj scénář pro přizpůsobené pokyny. Následující základní pokyny platí pro všechny čtenáře.

Zaměření na přístup „lift and shift“: Tento článek zařaďte do svého studijního postupu pouze pokud vaše migrace zahrnuje více oblastí Azure nebo se připojuje k jinému cloudu. Většina projektů metodou "lift and shift" začíná jednou oblastí a později přidá připojení mezi oblastmi, jakmile se stane prioritou zotavení po havárii nebo geografické rozšíření.

Zaměření modernizace: Tento článek uveďte, pokud vaše modernizace vyžaduje explicitní privátní připojení mezi oblastmi nad rámec článku o více oblastech . Tyto pokyny budete potřebovat, když paprskové sítě v různých oblastech vyžadují přímá komunikační propojení nebo když vaše nasazení v režimu active-active vyžaduje privátní peering mezi regionálními rozbočovači.

Zaměření na více cloudů: Tento článek je vaším hlavním vodítkem pro rozhodnutí o návrhu. Přečtěte si to předtím, než se rozhodnete mezi architekturou hub-and-spoke a službou Virtual WAN pro svou tranzitní architekturu mezi cloudy. V tomto článku zjistíte stávající topologii s více cloudy, mapujete služby mezi AWS nebo Google Cloudem a Azure a definujete, jak se Azure připojit k úlohám, které během migrace zůstanou v jiných cloudech.

Azure služby a funkce

Azure poskytuje několik služeb pro propojení mezi oblastmi a multicloudovou konektivitu. Každá služba řeší různé požadavky na škálování, šířku pásma a správu.

Service Co poskytuje Kdy ji použít
Globální propojení VNet Privátní připojení s nízkou latencí mezi virtuálními sítěmi v různých Azure oblastech Provoz zůstává na páteřní síti Microsoft. Šířka pásma je omezená pouze skladovou jednotkou virtuálního počítače, nikoli bránou. Přímá komunikace mezi dvěma virtuálními sítěmi v různých oblastech bez zařízení brány
Azure Virtual WAN (úroveň Standard) Globální tranzitní uzel spravovaný společností Microsoft, který propojuje virtuální sítě, pobočky a vzdálené uživatele ve všech regionech. Poskytuje tranzitivní směrování mezi všemi připojenými sítěmi. Organizace s mnoha regiony a pobočkami, které potřebují konektivitu any-to-any bez nutnosti spravovat jednotlivá peeringová propojení.
ExpressRoute přes cloudovou burzu Vyhrazené propojení mezi cloudy prostřednictvím externího poskytovatele propojovací platformy (například Equinix nebo Megaport). Poskytuje privátní připojení k AWS nebo Google Cloudu s velkou šířkou pásma. Vícecloudové architektury s požadavky SLA na šířku pásma, kde datový provoz nesmí procházet veřejným internetem.
Vpn typu Site-to-Site do jiných cloudů Šifrovaný tunel IPsec mezi Službu Azure VPN Gateway a bránou VPN jiného poskytovatele cloudu (AWS Virtual Private Gateway nebo Google Cloud VPN). Multicloudové připojení pro testovací, vývojové nebo produkční scénáře, kde nejsou vyhrazené okruhy odůvodněné.
Azure Route Server Umožňuje dynamickou výměnu tras protokolu BGP mezi virtuální sítí a síťovými virtuálními zařízeními (NVA). Vkládá trasy naučené pomocí NVA do směrovací infrastruktury Azure SDN. Vlastní směrování se síťovými virtuálními zařízeními třetích stran v centrální virtuální síti nebo komplexní směrování ve více cloudových prostředích, které vyžaduje propagaci BGP do sítí připojených k Azure.

Jak funguje globální partnerské propojení sítí VNet

Globální propojení partnerských virtuálních sítí vytváří přímé propojení mezi dvěma virtuálními sítěmi v různých oblastech Azure. Propojení vede zcela přes páteřní síť společnosti Microsoft a nikdy nevede přes veřejný internet. Po nakonfigurování partnerského propojení můžou prostředky v každé síti VNet komunikovat prostřednictvím privátních IP adres, jako by se nacházely ve stejné síti.

Na rozdíl od přístupů založených na bráně peering nepředstavuje jediné úzké místo. Šířka pásma mezi spárovanými virtuálními sítěmi závisí na SKU virtuálního počítače na každé straně. Žádné vyhrazené zařízení brány neomezuje propustnost. Díky tomuto návrhu je Global VNet Peering variantou s nejnižší latencí pro meziregionální komunikaci mezi malým počtem virtuálních sítí.

Peering je však záměrně nepřenosný. Pokud je VNet A vzájemně propojená s VNet B a VNet B je vzájemně propojená s VNet C, provoz z VNet A se nemůže dostat do VNet C přes VNet B. Každá dvojice virtuálních sítí, která potřebuje přímou komunikaci, vyžaduje vlastní propojení partnerských sítí. V modelu hub-and-spoke to znamená, že obvykle navzájem propojujete partnerským vztahem virtuální sítě regionálních hubů a pomocí uživatelsky definovaných tras (UDR) nebo NVA směrujete provoz mezi paprsky přes huby napříč oblastmi.

Virtual WAN globální tranzit

Azure Virtual WAN (ve verzi Standard) odstraňuje nutnost ručně konfigurovat peering mezi regionálními rozbočovači. Když nasadíte rozbočovače Virtual WAN ve více regionech, Microsoft automaticky vytvoří propojení mezi rozbočovači prostřednictvím páteřní sítě. Trasy získané v jednom centru se šíří do všech ostatních center a vytvářejí prostředky infrastruktury přenosu typu any-to-any.

Toto automatické směrování znamená, že paprsková síť VNet připojená k hubu v East US může dosáhnout paprskové sítě VNet připojené k hubu ve West Europe bez jakéhokoli dalšího partnerského propojení nebo konfigurace směrovací tabulky. Virtual WAN tuto průchodnost rozšiřuje také na pobočky (připojené prostřednictvím sítě VPN typu site-to-site nebo ExpressRoute) a vzdálené uživatele (připojené prostřednictvím vpn typu point-to-site). Výsledkem je plně propojená globální síť spravovaná společností Microsoft.

Pro inspekci provozu mezi oblastmi povolte v zabezpečených virtuálních hubech možnost Routing Intent. Směrovací záměr směruje provoz mezi huby přes Azure Firewall a poskytuje centralizovaný přehled a vynucování zásad napříč všemi regiony bez nutnosti nasazovat a spravovat jednotlivá zařízení NVA v každém hubu.

Jak zvolit

Pomocí následujících rozhodovacích tabulek vyberte správný přístup k připojení pro váš scénář.

Možnosti připojení mezi oblastmi

Diagram znázorňující vzorce připojení mezi regiony, včetně Global VNet Peering, tranzitu mezi uzly Virtual WAN a tras VPN mezi cloudy.

Váš scénář Doporučený přístup Proč
Dvě virtuální sítě v různých oblastech potřebují přímou komunikaci. Globální propojení VNet Nejnižší latence ve srovnání s internetovými trasami, bez úzkého hrdla na bráně, snadná konfigurace. Šířka pásma závisí na SKU virtuálního počítače.
Mnoho oblastí, mnoho větví, potřebná spravovaná doprava Azure Virtual WAN (úroveň Standard) Poskytuje tranzitivní směrování typu any-to-any mezi všemi připojenými huby. Microsoft spravuje infrastrukturu směrování.
Propojení místních lokalit mezi sebou prostřednictvím Azure ExpressRoute Global Reach Propojuje dva okruhy ExpressRoute, takže provoz z místní infrastruktury prochází páteřní sítí Microsoftu. Není nutné směrovat provoz oklikou přes virtuální sítě Azure.
Vlastní směrování nebo virtuální síťová zařízení třetích stran (NVA) v regionálním uzlu Azure Route Server Umožňuje dynamické partnerské vztahy protokolu BGP mezi síťovými virtuálními zařízeními a Azure. Trasy naučené zařízením NVA se automaticky vkládají do virtuálních sítí typu spoke.

Možnosti připojení v prostředí multicloud

Váš scénář Doporučený přístup Proč
Vysoká šířka pásma a smlouva SLA vyžadovaná pro provoz mezi cloudy ExpressRoute přes poskytovatele cloudových Exchange Poskytuje vyhrazenou kapacitu s předvídatelnou latencí. Poskytovatel exchange připojí váš okruh ExpressRoute ke službě přímého připojení druhého cloudu.
Úlohy s omezeným rozpočtem, testováním nebo nízkou propustností Site-to-site VPN Používá stávající připojení k internetu bez nákladů na okruh. Vhodné v případech, kdy jsou požadavky na šířku pásma skromné.
Hybridní a multicloudové prostředí (místní, Azure a jiný cloud) ExpressRoute Global Reach + Cloud Exchange Kombinuje službu Global Reach pro tranzit z místního prostředí do Azure s cloudovou výměnou pro propojení mezi Azure a jinými cloudy a vytváří tak sjednocenou privátní páteřní síť.

Aspekty návrhu

U většiny migrací metodou lift-and-shift je propojení mezi oblastmi spíše otázkou budoucího rozšíření než požadavkem od prvního dne. Vaše počáteční nasazení pravděpodobně cílí na jednu Azure oblast.

Když plánujete budoucí rozšíření:

  • Globální partnerské vztahy virtuálních sítí: Když přidáte druhou oblast Azure, použijte globální partnerské vztahy virtuálních sítí mezi regionálními centrálními virtuálními sítěmi. Tento přístup poskytuje privátní připojení s nízkou latencí bez nasazení zařízení brány. Provoz zůstává v páteřní síti společnosti Microsoft a škáluje se podle velikosti virtuálního počítače.
  • Odložená složitost: Vyhněte se nasazování Virtual WAN nebo služby ExpressRoute Global Reach, dokud vaše aktiva nepřeroste nad rámec dvou oblastí nebo nepřidáte požadavky na připojení větví.
  • Příprava obnovy po havárii: I když dnes není připojení mezi oblastmi potřeba, zdokumentujte, které úlohy vyžadují obnovu po havárii, a předem naplánujte topologii partnerského propojení, abyste ji mohli v případě potřeby rychle nasadit.

Vaše modernizovaná architektura využívá nasazení typu active-active ve více oblastech. Partnerské propojení mezi oblastmi umožňuje přímou komunikaci mezi paprsky, pokud vaše aplikační vrstvy přesahují hranice regionů.

Klíčová rozhodnutí o návrhu pro modernizaci:

  • Partnerské propojení mezi oblastmi pro konfiguraci aktivní-aktivní: Propojte centrální virtuální sítě primární a záložní oblasti, aby se umožnil obousměrný tok provozu. Aplikační týmy ve větvích ContosoBiz a ContosoCare mohou přistupovat k prostředkům v kterékoli oblasti přes trasu partnerského propojení centra.
  • Směrování přes huby: Protože Global VNet Peering není tranzitivní, směrujte provoz mezi paprsky v různých oblastech přes regionální hub NVA nebo Azure Firewall. Pomocí uživatelsky definovaných tras (UDR) směrujte provoz z jednoho paprsku do druhého mezi oblastmi přes firewall centra ke kontrole.
  • Selektivní peering: Ne všechny větve potřebují propojení mezi oblastmi. Propojte jen centrální virtuální sítě (VNet) a pomocí šíření tras zajistěte přístup ke konkrétním paprskovým virtuálním sítím (VNet), které se účastní úloh v konfiguraci aktivní-aktivní.

V tomto článku navrhujete architekturu připojení s více cloudy. Před plánováním Azure infrastruktury musíte zjistit stávající cloudovou topologii a mapovat služby mezi poskytovateli.

Postup zjišťování napříč cloudovými prostředími

  1. Zjištění stávající topologie: Pomocí zjišťování úloh v centru AWS a Google Cloud Network Intelligence Center můžete mapovat aktuální topologii virtuálního privátního cloudu (VPC), vztahy peeringu a vzorce toku provozu.
  2. Identifikace toků provozu: Zdokumentujte komunikaci typu VPC-to-VPC, příchozí a odchozí cesty internetu a připojení typu branch-to-cloud ve vašem prostředí AWS nebo Google Cloud.
  3. Mapování služeb na ekvivalentní služby v Azure: Klíčová mapování pro návrh konektivity jsou:
Služba AWS / Google Cloud Ekvivalent Azure
Tranzitní brána Azure Virtual WAN
VPC / síť VPC Virtuální síť Azure
Skupiny zabezpečení / pravidla firewallu Skupiny zabezpečení sítě (NSG)

Kompletní mapování služeb AWS-to-Azure a Google Cloud-to-Azure najdete v kontrolním seznamu zjišťování napříč cloudy.

Rozhodnutí o architektuře připojení

Po dokončení zjišťování a mapování služeb se rozhodněte:

  • Model přenosu: Zvolte Virtual WAN, pokud máte více virtuálních počítačů, větví, oblastí nebo hran cloudu. Virtual WAN představuje v Azure ekvivalent služby AWS Transit Gateway se spravovaným směrováním typu any-to-any.
  • VPN mezi cloudy: Nasaďte připojení brány VPN z rozbočovače Virtual WAN (nebo z hubu VNet) do služby AWS Virtual Private Gateway a Google Cloud VPN. Pro šifrovanou komunikaci mezi cloudy používejte tunely IPsec.
  • Aplikace, které zůstávají: Identifikujte úlohy, které během migrace zůstávají v AWS nebo Google Cloudu. Tyto úlohy potřebují trvalé připojení prostřednictvím tunelů VPN mezi cloudy, dokud se migrace neskonží.

Předpoklady

Před implementací připojení mezi oblastmi nebo více cloudy ověřte následující požadavky:

  • Dvě nebo více oblastí Azure s nasazenými virtuálními sítěmi: Vaše úlohy již musí existovat (nebo musí být plánovány) ve více oblastech. Pokyny k plánování virtuálních sítí najdete v článku o virtuálních sítích a podsítích .
  • Hvězdicová nebo Virtual WAN topologie: Návrhy napříč oblastmi vycházejí ze zavedené topologie v každé oblasti. Podívejte se na článek o topologii typu hub-and-spoke nebo článek o Virtual WAN.
  • Okruhy ExpressRoute (pro Global Reach): Pokud plánujete připojit místní pracoviště, potřebujete v každé lokalitě existující okruhy ExpressRoute. Přečtěte si článek o hybridním připojení.
  • Přístup k účtům napříč cloudy: Pro připojení VPN s více cloudy nebo exchange potřebujete přístup pro správu ke síťové konzole jiného poskytovatele cloudu, abyste nakonfigurovali vzdálenou stranu připojení.

Bezpečnostní aspekty

Připojení mezi oblastmi a více cloudy přináší specifické aspekty zabezpečení, které v nasazeních s jednou oblastí neexistují.

Kontrola provozu mezi oblastmi

Global VNet Peering není tranzitivní. Provoz mezi propojenými virtuálními sítěmi proudí přímo, aniž by procházel firewallem nebo inspekčním bodem. Pokud potřebujete zkontrolovat provoz mezi oblastmi, přesměrujte ho přes síťové virtuální zařízení nebo Azure Firewall v každém regionálním centru.

Ve službě Virtual WAN povolte Routing Intent se zásadami pro privátní provoz v zabezpečených virtuálních hubech. Routing Intent vynucuje komunikaci mezi rozbočovači prostřednictvím bran firewall spravovaných nástrojem Azure Firewall Manager, čímž zajišťuje centralizovanou kontrolu komunikace napříč oblastmi. Tato konfigurace vyžaduje úroveň Standard Virtual WAN.

Šifrování připojení mezi cloudy

Tunely VPN typu Site-to-Site do jiných cloudů jsou ve výchozím nastavení šifrované (IPsec/IKE). Připojení ExpressRoute prostřednictvím cloudové burzy jsou sice soukromá, ale nejsou šifrovaná na úrovni síťové vrstvy. Pokud potřebujete šifrování přes ExpressRoute, nasaďte MACsec na okruhy ExpressRoute Direct nebo použijte šifrování TLS vrstvy aplikace.

U provozu mezi cloudy, který prochází cloudovou propojovací platformou bez překryvné vrstvy VPN, zvažte nasazení tunelu IPsec založeného na síťovém virtuálním zařízení (NVA) v rámci trasy ExpressRoute. Tento přístup přidává šifrování bez nutnosti vzdát se šířky pásma a latence vyhrazeného okruhu. Případně použijte vzájemné TLS (mTLS) na aplikační vrstvě, aby každý koncový bod služby ověřoval identitu a šifroval data bez ohledu na použitý transportní protokol. Volba závisí na tom, jestli potřebujete šifrování vrstvy sítě (all-traffic), nebo můžete vynutit šifrování na aplikační vrstvě.

Důležité informace o nákladech

Za veškeré připojení mezi oblastmi se účtují poplatky za přenos dat. Globální partnerské propojení virtuálních sítí, provoz Virtual WAN mezi rozbočovači a tunely VPN Gateway mezi oblastmi využívají zpoplatnění podle odchozího provozu. Sazby se liší podle páru zón:

  • V rámci kontinentu (například z Východu USA na Západ USA): Nižší sazba za GB, obvykle v rozsahu standardních cen za odchozí přenos dat v dané oblasti.
  • Mezikontinentální (například Východ USA do Západní Evropy): Vyšší sazba za GB kvůli delším vzdálenostem v páteřní síti a mezikontinentální kapacitě.

Virtual WAN účtuje poplatek za jednotku připojení pro každou spoke virtuální síť nebo pobočku připojenou k hubu a navíc poplatek za zpracování dat pro provoz, který prochází zabezpečeným hubem, na kterém běží Azure Firewall. Tato víceúrovňová cenotvorba znamená, že Virtual WAN může u architektur s několika regiony a jen několika připojenými sítěmi stát více než jednoduchý globální peering virtuálních sítí, ale při připojení desítek poboček a regionů nabízí ve větším měřítku výhodnější jednotkové náklady.

Pro multicloudové připojení přes ExpressRoute prostřednictvím cloudového propojení se účtují portové poplatky a poplatky za cross-connect od poskytovatele propojení a také poplatky za okruh Azure ExpressRoute a za přímé připojení jiného cloudu. VPN typu site-to-site eliminuje náklady na okruh, ale za data odcházející z Azure se stále účtují standardní poplatky za odchozí přenos dat.

Pokyny: Pokud je to možné, přidělte úlohy s vysokým provozem ve stejné oblasti. Rezervujte trasy mezi oblastmi pro synchronizaci řídicí roviny, asynchronní replikaci a převzetí služeb při selhání v rámci obnovy po havárii, což jsou obvykle datové toky s menším objemem.

Vzorce zotavení po havárii

Připojení mezi oblastmi je základem zotavení po havárii (DR). Zvolený vzor určuje cíl doby obnovení (RTO) a cíl bodu obnovení (RPO).

Active-active

Oba regiony současně obsluhují produkční provoz. Globální nástroj pro vyrovnávání zatížení (například Azure Front Door nebo Azure Traffic Manager) distribuuje požadavky napříč oblastmi. Pokud jedna oblast selže, provoz se přesune do oblasti, která přežije, s minimálním přerušením. Tato architektura zajišťuje nejnižší RTO (sekundy až minuty), ale vyžaduje plnou infrastrukturu v obou regionech a obousměrnou synchronizaci dat, což zvyšuje náklady i komplexitu.

Active-passive

Jeden region obsluhuje produkční zatížení, zatímco druhý region zůstává v záloze s předem nasazenou (ale případně omezenou) infrastrukturou. Replikace uchovává aktuální data pasivní oblasti. Při selhání zvýšíte úroveň pasivní oblasti a přesměrujete provoz. RTO závisí na tom, jak rychle navýšíte pasivní prostředky a dokončíte přepnutí při selhání DNS nebo nástroje pro vyvažování zátěže, obvykle během několika až několika desítek minut.

Signalizační kontrolka

Minimální stopa v sekundárním regionu (replikované databáze, nasazená základní síťová infrastruktura) bez aktivních výpočetních prostředků. Při převzetí služeb při selhání nasadíte nebo škálujete výpočetní prostředky pro aplikaci a přepnete provoz. Tento vzor minimalizuje provozní náklady v ustáleném stavu, ale zvyšuje RTO, protože výpočetní prostředky musí být spuštěny dříve, než region začne obsluhovat provoz.

Ve všech variantách zajišťuje konektivita mezi oblastmi (globální partnerské propojení virtuálních sítí nebo Virtual WAN mezi rozbočovači) privátní datovou cestu pro replikační provoz. Ujistěte se, že vaše runbooky pro zotavení po havárii zohledňují případná zpoždění při šíření tras, a ověřte, že pravidla skupiny zabezpečení sítě (NSG) v sekundární oblasti povolují provoz při převzetí služeb při selhání.

Klíčová omezení

Omezení Impact
Global VNet Peering je netranzitivní To, že je VNet A propojená partnerským vztahem s VNet B a VNet B je propojená partnerským vztahem s VNet C, neznamená, že VNet A může komunikovat s VNet C. Musíte propojit VNet A přímo s VNet C partnerským vztahem nebo použít tranzitní řešení, jako je Virtual WAN.
Virtual WAN úrovně Basic chybí tranzitivita Základní Virtual WAN nepodporuje tranzitivní připojení typu VNet-to-VNet. Pro průchod mezi oblastmi použijte úroveň Standard.
ExpressRoute Global Reach vyžaduje SKU Premium pro připojení mezi geopolitickými oblastmi. Okruhy v různých geopolitických oblastech (například USA a Evropa) vyžadují doplněk Premium. Standardní okruhy SKU se připojují pouze ve stejné geopolitické hranici.
Doporučené VPN Gateway aktivní pro AWS AWS Virtual Private Gateway vytvoří dva tunely na připojení VPN. Nakonfigurujte Službu Azure VPN Gateway v režimu aktivní-aktivní tak, aby využívala všechny dostupné tunely a zabránila asymetrickému směrování.

Další informace

Další kroky

Tip

Prozkoumáváte to sami? Vraťte se do navigátoru přehledu a vyhledejte další článek podle možností.

V dalším kroku na cestě metodou "lift and shift":

Síťové propojení mezi více regiony: Naplánujte propojení mezi více regiony a převzetí služeb při selhání, pokud se migrace rozšíří do více než jednoho regionu.

Další na cestě k modernizaci:

Monitorování a pozorovatelnost sítě: Povolte pozorovatelnost napříč oblastmi pro zajištění provozní připravenosti.

Dále na vaší cestě mezi cloudy:

Topologie Virtual WAN: Použijte Virtual WAN jako tranzitní centrum pro multicloudové připojení a připojení více poboček.

  • Last updated on