Łączność między regionami i wieloma chmurami

Ten artykuł pomaga łączyć obciążenia platformy Azure między wieloma regionami i rozszerzać łączność na innych dostawców chmury, takich jak Amazon Web Services (AWS) i Google Cloud.

Co opisano w tym artykule

W tym artykule omówiono decyzje projektowe dotyczące łączenia sieci wirtualnych platformy Azure (VNet) między regionami oraz tworzenia tras sieciowych do obciążeń uruchomionych w innych środowiskach chmurowych. Dowiesz się, kiedy używać globalnej komunikacji równorzędnej sieci wirtualnych, Virtual WAN, usługi ExpressRoute Global Reach, sieci VPN typu lokacja-lokacja i Azure Route Server dla scenariuszy obejmujących wiele regionów i wielu chmur.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli ma zastosowanie co najmniej jeden z następujących warunków:

  • Twoja architektura obejmuje wiele Azure regionów i wymaga prywatnej łączności między nimi.
  • Należy połączyć Azure obciążenia z usługami AWS, Google Cloud lub inną siecią zewnętrzną.
  • Należy porównać globalny peering sieci wirtualnych, Virtual WAN, usługę ExpressRoute Global Reach, sieć VPN typu lokacja-lokacja lub Azure Route Server.
  • Należy zaprojektować odporną łączność na potrzeby odzyskiwania po awarii, globalnego rozszerzania lub wielochmurowych operacji.

Tip

Podążasz ścieżką scenariusza? Wybierz swój scenariusz w górnej części strony, aby uzyskać dostosowane wskazówki. Poniższe podstawowe wskazówki dotyczą wszystkich czytelników.

Fokus lift-and-shift: Dołącz ten artykuł do ścieżki do czytania tylko wtedy, gdy migracja obejmuje wiele Azure regionów lub łączy się z inną chmurą. Większość projektów metodą "lift-and-shift" rozpoczyna się od jednego regionu i dodaje łączność między regionami później, gdy odzyskiwanie po awarii lub rozszerzanie geograficzne staje się priorytetem.

Zakres modernizacji: Uwzględnij ten artykuł, jeśli modernizacja wymaga jawnie zdefiniowanej prywatnej łączności między regionami, wykraczającej poza zakres omówiony w artykule o wielu regionach. Te wskazówki będą potrzebne, gdy spoke’i w różnych regionach wymagają bezpośrednich ścieżek komunikacji lub gdy wdrożenie active-active wymaga prywatnego połączenia peeringowego między regionalnymi hubami.

Podejście wielochmurowe: Ten artykuł stanowi podstawę tej kluczowej decyzji projektowej. Przeczytaj to przed wyborem między architekturą hub-spoke a Virtual WAN na potrzeby architektury tranzytowej między chmurami. W tym artykule opisano istniejącą topologię wielochmurową, mapowanie usług między platformami AWS lub Google Cloud i Azure oraz definiowanie sposobu łączenia się Azure z obciążeniami, które pozostają w innych chmurach podczas migracji.

Usługi i funkcje platformy Azure

Azure oferuje kilka usług łączności między regionami i wieloma chmurami. Każda usługa odpowiada różnym wymaganiom w zakresie skalowania, przepustowości i zarządzania.

Service Co zapewnia Kiedy należy go używać
Globalna komunikacja równorzędna sieci wirtualnych Prywatne połączenie o niskich opóźnieniach między sieciami wirtualnymi w różnych regionach Azure. Ruch sieciowy pozostaje w obrębie sieci szkieletowej firmy Microsoft. Przepustowość jest ograniczona tylko przez jednostkę SKU maszyny wirtualnej, a nie przez bramę. Bezpośrednia komunikacja między dwiema sieciami VNet w różnych regionach bez urządzenia brzegowego.
Azure Virtual WAN (warstwa Standardowa) Globalne centrum tranzytowe zarządzane przez firmę Microsoft, które łączy sieci VNets, oddziały i użytkowników pracujących zdalnie we wszystkich regionach. Zapewnia tranzytowy routing między wszystkimi połączonymi sieciami. Organizacje z wieloma regionami i oddziałami, które potrzebują łączności każdy z każdym bez konieczności zarządzania poszczególnymi połączeniami peeringowymi.
Usługa ExpressRoute za pośrednictwem usługi Cloud Exchange Dedykowane połączenie między środowiskami chmurowymi za pośrednictwem zewnętrznego dostawcy usługi wymiany (na przykład Equinix lub Megaport). Zapewnia prywatną łączność o wysokiej przepustowości z usługami AWS lub Google Cloud. Architektury wielochmurowe z wymaganiami umowy SLA dotyczącymi przepustowości, w przypadku których ruch nie może przechodzić przez publiczny Internet.
Sieć VPN typu punkt-punkt do innych chmur Zaszyfrowany tunel IPsec między Azure VPN Gateway i bramą sieci VPN innego dostawcy chmury (wirtualna brama prywatna platformy AWS lub sieć VPN w chmurze Google). Łączność z wieloma chmurami na potrzeby testowania, programowania lub scenariuszy produkcyjnych, w których dedykowane obwody nie są uzasadnione.
Azure Route Server Umożliwia dynamiczną wymianę tras protokołu BGP między siecią wirtualną (VNet) a wirtualnymi urządzeniami sieciowymi (NVA). Wprowadza trasy uzyskane przez składnik NVA do infrastruktury routingu SDN platformy Azure. Niestandardowe trasowanie z użyciem wirtualnych urządzeń sieciowych (NVA) innych firm w sieci wirtualnej typu hub lub złożone trasowanie wielochmurowe, które wymaga propagowania tras BGP do sieci połączonych z platformą Azure.

Jak działa globalna komunikacja równorzędna sieci wirtualnych

Globalna komunikacja równorzędna sieci wirtualnych tworzy bezpośrednie połączenie między dwiema sieciami wirtualnymi w różnych regionach platformy Azure. Łącze przebiega w całości przez sieć szkieletową firmy Microsoft i nigdy nie przechodzi przez publiczny Internet. Po skonfigurowaniu relacji komunikacji równorzędnej zasoby w każdej sieci wirtualnej mogą komunikować się przy użyciu prywatnych adresów IP tak, jakby znajdowały się w tej samej sieci.

W przeciwieństwie do metod opartych na bramie komunikacja równorzędna nie wprowadza jednego punktu dławiania. Przepustowość między sparowanymi sieciami wirtualnymi (VNet) skaluje się wraz z rozmiarem SKU maszyny wirtualnej po każdej stronie. Nie ma dedykowanej bramy ograniczającej przepustowość. Ta konstrukcja sprawia, że globalne komunikowanie równorzędne sieci wirtualnych (Global VNet Peering) jest opcją o najmniejszych opóźnieniach w komunikacji międzyregionalnej między niewielką liczbą sieci wirtualnych.

Jednak peering z założenia nie jest tranzytywny. Jeśli sieć wirtualna A jest połączona komunikacją równorzędną z siecią wirtualną B, a sieć wirtualna B jest połączona komunikacją równorzędną z siecią wirtualną C, ruch z sieci wirtualnej A nie może dotrzeć do sieci wirtualnej C za pośrednictwem sieci wirtualnej B. Każda para sieci wirtualnych wymagających bezpośredniej komunikacji wymaga własnego połączenia równorzędnego. W modelu gwiazdy i szprych oznacza to, że zazwyczaj zestawia się połączenia równorzędne między regionalnymi sieciami wirtualnymi koncentratorów i używa tras zdefiniowanych przez użytkownika (UDR) lub urządzeń NVA do przekazywania ruchu między szprychami między regionami przez koncentratory.

Globalny tranzyt Virtual WAN

Azure Virtual WAN (warstwa Standard) eliminuje konieczność ręcznego konfigurowania komunikacji równorzędnej między regionalnymi węzłami. Gdy wdrażasz huby Virtual WAN w wielu regionach, Microsoft automatycznie tworzy połączenia między hubami przez sieć szkieletową. Trasy nauczone w jednym koncentratorze są propagowane do wszystkich pozostałych koncentratorów, tworząc sieć tranzytową typu każdy z każdym.

To automatyczne trasowanie oznacza, że sieć wirtualna typu spoke połączona z hubem w regionie East US może uzyskać dostęp do sieci wirtualnej typu spoke połączonej z hubem w regionie West Europe bez dodatkowej konfiguracji komunikacji równorzędnej ani tabel tras. Virtual WAN również rozszerza tę przechodniość do oddziałów (połączonych za pośrednictwem sieci VPN typu lokacja-lokacja lub usługi ExpressRoute) i użytkowników zdalnych (połączonych za pośrednictwem sieci VPN typu punkt-lokacja). Wynikiem jest w pełni połączona globalna sieć zarządzana przez firmę Microsoft.

Na potrzeby inspekcji ruchu między regionami włącz funkcję Routing Intent w zabezpieczonych koncentratorach wirtualnych. Funkcja Routing Intent wymusza kierowanie ruchu między hubami przez usługę Azure Firewall, zapewniając scentralizowaną widoczność i egzekwowanie zasad we wszystkich regionach bez konieczności wdrażania oddzielnych urządzeń NVA i zarządzania nimi w każdym hubie.

Jak wybrać

Skorzystaj z poniższych tabel decyzyjnych, aby wybrać odpowiednie podejście do łączności dla danego scenariusza.

Opcje łączności między regionami

Diagram pokazujący wzorce łączności między regionami, w tym Global VNet Peering, tranzyt między koncentratorami Virtual WAN oraz ścieżki VPN między chmurami.

Twój scenariusz Zalecane podejście Dlaczego
Dwie sieci VNet w różnych regionach muszą komunikować się bezpośrednio Globalna komunikacja równorzędna sieci wirtualnych Najmniejsze opóźnienia w porównaniu z trasami internetowymi, bez wąskiego gardła na bramie, łatwa konfiguracja. Przepustowość skaluje się wraz z rozmiarem SKU maszyny wirtualnej.
Wiele regionów, wiele gałęzi, wymagany jest tranzyt zarządzany Azure Virtual WAN (warstwa Standardowa) Zapewnia routing tranzytowy między dowolnymi punktami pomiędzy wszystkimi połączonymi koncentratorami. Microsoft zarządza infrastrukturą routingu.
Łączenie lokacji lokalnych ze sobą za pośrednictwem Azure ExpressRoute Global Reach Łączy dwa obwody usługi ExpressRoute, aby ruch lokalny przechodził przez sieć szkieletową Microsoft. Nie ma potrzeby korzystania z routingu hairpin przez sieci wirtualne Azure.
Niestandardowy routing lub urządzenia NVA innych firm w regionalnym węźle centralnym Azure Route Server Umożliwia dynamiczne zestawianie połączeń równorzędnych BGP między urządzeniami NVA i platformą Azure. Trasy wyuczone przez NVA są automatycznie wstrzykiwane do sieci wirtualnych typu spoke.

Opcje łączności z wieloma chmurami

Twój scenariusz Zalecane podejście Dlaczego
Wysoka przepustowość i umowa SLA wymagana dla ruchu między chmurami Usługa ExpressRoute za pośrednictwem dostawcy Exchange w chmurze Zapewnia dedykowaną pojemność z przewidywalnym opóźnieniem. Dostawca usługi wymiany łączy obwód ExpressRoute z usługą bezpośredniego połączenia innej chmury.
Obciążenia ograniczone budżetowo, testowe lub o niskiej przepływności Międzylokacyjna sieć VPN Używa istniejącej łączności z Internetem bez kosztów obwodu. Odpowiednie, gdy wymagania dotyczące przepustowości są skromne.
Środowisko hybrydowe i wielochmurowe (lokalnie, Azure i inna chmura) ExpressRoute Global Reach + Cloud Exchange Łączy usługę Global Reach dla tranzytu między środowiskiem lokalnym a platformą Azure z punktem wymiany ruchu w chmurze do łączności między platformą Azure a innymi chmurami, tworząc ujednoliconą prywatną sieć szkieletową.

Uwagi dotyczące projektowania

W przypadku większości migracji metodą „lift-and-shift” łączność między regionami jest kwestią do rozważenia na etapie przyszłej rozbudowy, a nie wymogiem od samego początku. Początkowe wdrożenie prawdopodobnie jest przeznaczone dla pojedynczego regionu Azure.

Podczas planowania przyszłej ekspansji:

  • Global VNet Peering: Użyj funkcji Global VNet Peering między regionalnymi centralnymi sieciami wirtualnymi po dodaniu drugiego regionu Azure. Takie podejście zapewnia prywatną łączność o niskich opóźnieniach bez wdrażania urządzenia bramy. Ruch pozostaje w obrębie sieci szkieletowej firmy Microsoft i skaluje się wraz z SKU maszyny wirtualnej.
  • Odroczona złożoność: Unikaj wdrażania Virtual WAN lub usługi ExpressRoute Global Reach, dopóki Twoje środowisko nie rozszerzy się poza dwa regiony lub nie pojawią się wymagania dotyczące łączności z oddziałami.
  • Przygotowanie do odzyskiwania po awarii: Nawet jeśli łączność między regionami nie jest dziś potrzebna, udokumentuj, które obciążenia robocze wymagają odzyskiwania po awarii, i wstępnie zaplanuj topologię komunikacji peeringowej, aby w razie potrzeby można ją było szybko wdrożyć.

Twoja zmodernizowana architektura wykorzystuje wdrożenia typu active-active w wielu regionach. Komunikacja równorzędna międzyregionowa umożliwia bezpośrednią komunikację między sieciami typu spoke, gdy warstwy aplikacji obejmują więcej niż jeden region.

Kluczowe decyzje projektowe dotyczące modernizacji:

  • Połączenie równorzędne między regionami dla trybu aktywny-aktywny: Skonfiguruj połączenie równorzędne między centralnymi sieciami wirtualnymi (VNet) regionu podstawowego i zapasowego, aby umożliwić dwukierunkowy przepływ ruchu. Zespoły aplikacyjne w segmentach spoke ContosoBiz i ContosoCare mogą uzyskać dostęp do zasobów w obu regionach przez połączenie peeringowe za pośrednictwem hubu.
  • Routing przez huby: Ponieważ globalny peering sieci wirtualnych nie jest tranzytywny, kieruj międzyregionalny ruch między sieciami spoke przez regionalne urządzenie NVA lub usługę Azure Firewall. Użyj tras zdefiniowanych przez użytkownika (UDR), aby kierować międzyregionalny ruch między sieciami szprychowymi przez zaporę w sieci centralnej w celu inspekcji.
  • Selektywna komunikacja równorzędna: Nie wszystkie szprychy wymagają łączności między regionami. Skonfiguruj komunikację równorzędną tylko z sieciami wirtualnymi centrum i użyj propagacji tras, aby uzyskać dostęp do określonych sieci wirtualnych szprych uczestniczących w obciążeniach w trybie aktywny-aktywny.

W tym artykule projektujesz architekturę łączności wielochmurowej. Przed planowaniem Azure infrastruktury należy odnaleźć istniejącą topologię chmury i mapować usługi między dostawcami.

Przepływ pracy wykrywania między chmurami

  1. Poznaj swoją obecną topologię: Użyj funkcji Workload Discovery w AWS oraz Google Cloud Network Intelligence Center, aby zmapować bieżącą topologię Virtual Private Cloud (VPC), połączenia peeringowe i wzorce przepływu ruchu.
  2. Identyfikowanie przepływów ruchu: Dokumentowanie komunikacji między sieciami VPC, ścieżek przychodzących i wychodzących z Internetu oraz połączeń między oddziałami i chmurą w środowisku AWS lub Google Cloud.
  3. Mapowanie usług na odpowiedniki Azure: Mapowanie kluczy dla projektu łączności to:
AWS / Google Cloud Service Odpowiednik platformy Azure
Brama tranzytowa Azure Virtual WAN
VPC / Sieć VPC Azure Virtual Network
Grupy zabezpieczeń / Reguły zapory sieciowej Sieciowe grupy zabezpieczeń (NSG):

Aby uzyskać pełne mapowania usług AWS-to-Azure i Google Cloud-to-Azure, zobacz Lista kontrolna odnajdywania między chmurami.

Decyzje dotyczące architektury łączności

Po zakończeniu odnajdywania i mapowania usług zdecyduj:

  • Model tranzytowy: Wybierz Virtual WAN, jeśli masz wiele sieci VPN, gałęzi, regionów lub krawędzi chmury. Virtual WAN stanowi odpowiednik usługi AWS Transit Gateway w platformie Azure i oferuje zarządzany routing typu any-to-any.
  • VPN między chmurami: Wdróż połączenia usługi VPN Gateway z koncentratora Virtual WAN (lub sieci VNet koncentratora) do usługi AWS Virtual Private Gateway i Google Cloud VPN. Użyj tuneli IPsec do zaszyfrowanej komunikacji między chmurami.
  • Aplikacje, które pozostają: Identyfikowanie obciążeń, które pozostają w usługach AWS lub Google Cloud podczas migracji. Te obciążenia wymagają trwałej łączności za pośrednictwem tuneli vpn między chmurami do momentu zakończenia migracji.

Prerequisites

Przed wdrożeniem łączności między regionami lub wieloma chmurami potwierdź następujące wymagania:

  • Dwa lub więcej regionów platformy Azure z wdrożonymi sieciami wirtualnymi: Twoje obciążenia muszą już istnieć (lub być uwzględnione w planach) w wielu regionach. Zobacz artykuł Dotyczący sieci wirtualnych i podsieci , aby uzyskać wskazówki dotyczące planowania sieci wirtualnej.
  • Topologia typu hub-and-spoke lub Virtual WAN: Architektury międzyregionalne opierają się na ustalonej topologii w każdym regionie. Zobacz artykuł z piastą i szprychą lub artykuł Virtual WAN.
  • Obwody usługi ExpressRoute (dla usługi Global Reach): Jeśli planujesz połączenie lokacji lokalnych, potrzebujesz istniejących obwodów usługi ExpressRoute w każdej lokalizacji. Zobacz artykuł dotyczący łączności hybrydowej.
  • Dostęp do konta między chmurami: W przypadku łączności VPN w środowisku wielochmurowym lub połączenia typu Exchange potrzebny jest dostęp administracyjny do konsoli sieciowej innego dostawcy chmury, aby skonfigurować zdalną stronę połączenia.

Zagadnienia dotyczące zabezpieczeń

Łączność między regionami i wieloma chmurami wprowadza konkretne obawy dotyczące zabezpieczeń, które nie istnieją we wdrożeniach w jednym regionie.

Inspekcja ruchu między regionami

Global VNet Peering jest nieprzechodni. Ruch między równorzędnymi sieciami wirtualnymi przepływa bezpośrednio bez przechodzenia przez zaporę lub punkt inspekcji. Jeśli musisz inspekcjonować ruch między regionami, skieruj go przez sieciowe urządzenie wirtualne (NVA) lub usługę Azure Firewall w każdym regionalnym węźle centralnym.

W przypadku Virtual WAN włącz opcję Routing Intent z zasadami ruchu prywatnego w zabezpieczonych koncentratorach wirtualnych. Funkcja Routing Intent wymusza kierowanie ruchu między hubami przez zapory zarządzane za pomocą Azure Firewall Manager, co umożliwia scentralizowaną inspekcję ruchu między regionami. Ta konfiguracja wymaga warstwy Standard usługi Virtual WAN.

Szyfrowanie połączeń między chmurami

Tunele vpn typu lokacja-lokacja do innych chmur są domyślnie szyfrowane (IPsec/IKE). Jednak połączenia usługi ExpressRoute za pośrednictwem wymiany w chmurze są prywatne, ale nie są szyfrowane w warstwie sieciowej. Jeśli potrzebujesz szyfrowania za pośrednictwem usługi ExpressRoute, wdróż protokół MACsec w obwodach usługi ExpressRoute Direct lub użyj szyfrowania TLS w warstwie aplikacji.

W przypadku ruchu między chmurami przechodzącego przez punkt wymiany ruchu między chmurami bez nakładki VPN rozważ wdrożenie tunelu IPsec opartego na rozwiązaniu NVA w ramach ścieżki ExpressRoute. Takie podejście zapewnia szyfrowanie bez rezygnacji z korzyści w zakresie przepustowości i opóźnień łącza dedykowanego. Alternatywnie należy użyć wzajemnego protokołu TLS (mTLS) w warstwie aplikacji, aby każdy punkt końcowy usługi weryfikował tożsamość i szyfruje dane niezależnie od transportu bazowego. Wybór zależy od tego, czy potrzebujesz szyfrowania warstwy sieciowej (całego ruchu) lub może wymuszać szyfrowanie w warstwie aplikacji.

Zagadnienia dotyczące kosztów

Cała łączność między regionami wiąże się z opłatami za transfer danych. Globalna komunikacja równorzędna sieci wirtualnych (VNet), ruch między koncentratorami usługi Virtual WAN oraz tunele międzyregionalne usługi VPN Gateway są rozliczane na podstawie ruchu wychodzącego. Stawki różnią się w zależności od pary stref:

  • W obrębie kontynentu (na przykład z East US do West US): niższa stawka za GB, zazwyczaj w zakresie standardowych stawek za transfer wychodzący dla regionu.
  • Międzykontynentalny (na przykład ze Wschodnich stanów USA do Europy Zachodniej): Wyższa stawka za GB wynikająca z większych odległości w sieci szkieletowej i przepustowości międzykontynentalnej.

Usługa Virtual WAN nalicza opłatę za jednostkę połączeniową dla każdej sieci wirtualnej typu spoke lub oddziału podłączonych do koncentratora, a także opłatę za przetwarzanie danych dla ruchu przechodzącego przez zabezpieczony koncentrator z uruchomioną usługą Azure Firewall. Ten wielowarstwowy model cenowy oznacza, że usługa Virtual WAN może kosztować więcej niż prostsze globalne komunikowanie równorzędne sieci wirtualnych (Global VNet Peering) w architekturach obejmujących tylko kilka regionów i kilka sieci typu spoke, ale przy większej skali oferuje korzystniejszy koszt jednostkowy, gdy łączą się dziesiątki oddziałów i regionów.

W przypadku łączności wielochmurowej korzystanie z usługi ExpressRoute za pośrednictwem punktu wymiany ruchu chmurowego wiąże się z opłatami za port oraz opłatami za połączenia typu cross-connect pobieranymi przez dostawcę tego punktu wymiany, a także z opłatami za obwód Azure ExpressRoute i opłatami za usługę połączenia bezpośredniego w drugiej chmurze. Sieć VPN typu lokacja-lokacja pozwala uniknąć kosztów obwodu, ale nadal wiąże się ze standardowymi opłatami za ruch wychodzący dla danych opuszczających Azure.

Wskazówki: Kolokuj obciążenia o dużym natężeniu ruchu w tym samym regionie, gdy jest to możliwe. Zarezerwuj ścieżki międzyregionalne dla synchronizacji płaszczyzny sterowania, replikacji asynchronicznej i przełączania awaryjnego na potrzeby odzyskiwania po awarii, ponieważ są to zwykle przepływy o mniejszym natężeniu.

Wzorce odzyskiwania po awarii

Łączność między regionami jest podstawą odzyskiwania po awarii (DR). Wybrany wzorzec określa cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO).

Active-active

Oba regiony obsługują jednocześnie ruch produkcyjny. Globalny moduł równoważenia obciążenia (taki jak Azure Front Door lub Azure Traffic Manager) dystrybuuje żądania między regionami. Jeśli jeden region ulegnie awarii, ruch zostanie przeniesiony do ocalałego regionu z minimalnymi przerwami. Ten model zapewnia najniższy RTO (rzędu sekund do minut), ale wymaga pełnej infrastruktury w obu regionach oraz dwukierunkowej synchronizacji danych, co zwiększa koszty i złożoność.

Active-passive

Jeden region obsługuje ruch produkcyjny, podczas gdy drugi region pozostaje w gotowości z uprzednio wdrożoną infrastrukturą (choć potencjalnie o zmniejszonej skali). Replikacja przechowuje bieżące dane w regionie pasywnym. W razie awarii awansujesz region pasywny do roli aktywnego i przekierowujesz ruch. RTO zależy od tego, jak szybko można zwiększyć skalę zasobów pasywnych i przeprowadzić przełączenie awaryjne DNS lub modułu równoważenia obciążenia — zwykle od kilku do kilkudziesięciu minut.

Światło pilotażowe

Minimalna obecność w regionie zapasowym (replikowane bazy danych, wdrożona podstawowa infrastruktura sieciowa), bez aktywnych zasobów obliczeniowych. Podczas przełączenia awaryjnego wdrażasz lub skalujesz zasoby obliczeniowe dla aplikacji i przełączasz ruch. Ten wzorzec minimalizuje koszty stałe, ale zwiększa RTO, ponieważ zasoby obliczeniowe muszą zostać uruchomione, zanim region będzie mógł obsługiwać ruch.

We wszystkich scenariuszach łączność między regionami (globalny peering sieci wirtualnych lub połączenie między koncentratorami w usłudze Virtual WAN) zapewnia prywatną ścieżkę danych na potrzeby ruchu replikacji. Upewnij się, że procedury DR uwzględniają wszelkie opóźnienia propagacji tras, i zweryfikuj, czy reguły sieciowej grupy zabezpieczeń (NSG) w regionie pomocniczym zezwalają na ruch związany z przełączeniem awaryjnym.

Ograniczenia klucza

Ograniczenie Impact
Global VNet Peering nie jest tranzytywna To, że VNet A ma komunikację równorzędną z VNet B, a VNet B ma komunikację równorzędną z VNet C, nie oznacza, że VNet A może osiągnąć VNet C. Musisz bezpośrednio zestawić komunikację równorzędną między VNet A i VNet C albo użyć rozwiązania tranzytowego, takiego jak Virtual WAN.
Virtual WAN warstwa Podstawowa nie ma przechodniości Basic Virtual WAN nie obsługuje tranzytywnej łączności między sieciami VNet. Użyj warstwy Standard do tranzytu między regionami.
Usługa ExpressRoute Global Reach wymaga jednostki SKU Premium dla połączeń między geopolitycznych Obwody w różnych regionach geopolitycznych (na przykład Stany Zjednoczone i Europa) wymagają dodatku Premium. Obwody w standardowej jednostce SKU nawiązują połączenia tylko w obrębie tej samej granicy geopolitycznej.
VPN Gateway aktywne-aktywne zalecane dla platformy AWS Wirtualna brama prywatna platformy AWS tworzy dwa tunele na połączenie sieci VPN. Skonfiguruj Azure VPN Gateway w trybie aktywny-aktywny, aby używać wszystkich dostępnych tuneli i unikać routingu asymetrycznego.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Sieć wieloregionowa: Zaplanuj łączność wieloregionową i mechanizmy przełączania awaryjnego, jeśli migracja obejmie więcej niż jeden region.

Kolejny etap procesu modernizacji:

Monitorowanie i obserwowanie sieci: umożliwia obserwowanie w różnych regionach pod kątem gotowości produkcyjnej.

Kolejny krok w Twojej wielochmurowej podróży:

topologia Virtual WAN: użyj Virtual WAN jako koncentratora tranzytowego dla łączności wielochmurowej i wielobranżowej.

  • Last updated on