Projekt sieci wieloregionowej

W tym artykule wyjaśniono, jak projektować Azure sieci obejmujące wiele regionów. Sieć wieloregionowa zapewnia wysoką dostępność w przypadku awarii regionalnych, obsługuje geograficznie rozproszonych użytkowników z mniejszym opóźnieniem i obsługuje wymagania dotyczące rezydencji danych regulacyjnych.

Co opisano w tym artykule

W tym artykule omówiono nadmiarowość strefową i regionalną, strategie routingu między regionami, wybór topologii typu hub dla wdrożeń wieloregionowych, wzorce przełączania awaryjnego active-active i active-passive oraz zagadnienia związane z opóźnieniami replikacji.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli środowisko jest zgodne z dowolnym z następujących warunków:

  • Twoje obciążenie robocze wymaga zabezpieczenia na potrzeby odzyskiwania po awarii na wypadek awarii całego regionu platformy Azure.
  • Użytkownicy są obsługiwani w wielu lokalizacjach geograficznych i trzeba zminimalizować opóźnienie sieci.
  • Wymagania dotyczące przepisów lub zgodności nakazują, aby dane pozostawały w określonych granicach geograficznych.
  • Cele ciągłości działania definiują cel czasu odzyskiwania (RTO), którego pojedynczy region nie może osiągnąć sam.

Jeśli obciążenie działa w jednym regionie, a wdrożenia z nadmiarowością strefową spełniają wymagania dotyczące dostępności, architektura wieloregionowa może jeszcze nie być potrzebna. Zacznij od topologii piasty i szprych lub Virtual WAN w jednym regionie i rozszerz później.

Podejście lift-and-shift: Starsze obciążenia robocze często nie mogą działać w trybie active-active w różnych regionach. Zaplanuj odzyskiwanie po awarii przy użyciu usługi Azure Site Recovery i centrum w regionie odzyskiwania po awarii zamiast pełnej architektury active-active.

Priorytet modernizacji: Wdróż aplikacje skierowane do klientów w konfiguracji aktywna-aktywna w dwóch regionach, z jednostkami SKU nadmiarowymi strefowo, używając nienakładającej się przestrzeni adresowej, aby w razie potrzeby można było połączyć regiony w trybie komunikacji równorzędnej.

Podejście wielochmurowe: Użyj usługi Azure Virtual WAN, aby połączyć wiele regionów i oddziałów oraz zaplanować trasowanie między regionami równolegle z tranzytem między chmurami.

Usługi i funkcje platformy Azure

W poniższej tabeli wymieniono usługi i funkcje Azure, które umożliwiają korzystanie z sieci w wielu regionach:

Usługa lub funkcja Rola w projekcie wieloregionowym Learn more
Azure Traffic Manager Routing ruchu opartego na systemie DNS w różnych regionach dla dowolnego protokołu Omówienie usługi Traffic Manager
Azure Front Door Globalne równoważenie obciążenia dla HTTP/HTTPS z CDN i WAF na brzegu sieci Omówienie usługi Front Door
Globalna komunikacja równorzędna sieci wirtualnych Prywatna łączność o wysokiej przepustowości między sieciami wirtualnymi w różnych regionach Peering sieci wirtualnych
ExpressRoute Global Reach Łączy lokacje lokalne ze sobą za pośrednictwem sieci szkieletowej Azure ExpressRoute Global Reach
Azure Virtual WAN (multi-hub) globalny tranzyt zarządzany przez firmę Microsoft z automatycznym trasowaniem między koncentratorami Globalny tranzyt Virtual WAN
Azure Virtual Network Manager (AVNM) Automatyzuje topologię połączeń równorzędnych między regionami oraz zarządzanie grupami sieciowymi Omówienie usługi AVNM

Dlaczego wiele regionów wymaga wielu sieci wirtualnych

Sieć wirtualna obejmuje jeden region. Podsieci w tej sieci wirtualnej obejmują wszystkie strefy dostępności w regionie, ale sama sieć wirtualna nie może wykraczać poza granice regionów. W związku z tym sieć wieloregionowa oznacza wdrażanie wielu sieci wirtualnych, co najmniej jednej sieci na region i łączenie ich z usługami między regionami.

Diagram przedstawiający topologię active-active w dwóch regionach, w której usługi Azure Front Door i WAF kierują globalny ruch przychodzący do regionów West Europe i East US, z których każdy zawiera centralną sieć wirtualną (VNet) z usługami Azure Firewall i Azure Bastion, połączoną komunikacją równorzędną z siecią wirtualną obciążenia typu spoke, przy czym oba regiony są połączone za pomocą Global VNet Peering przez sieć szkieletową Microsoft.

To podstawowe ograniczenie kształtuje każdy projekt w wielu regionach:

  • Każdy region potrzebuje własnej przestrzeni adresowej sieci wirtualnej, niepokrywającej się z przestrzeniami innych regionów na potrzeby peeringu.
  • Ruch między regionami wymaga jawnie określonego mechanizmu łączności: globalnego peeringu sieci wirtualnych, połączenia między koncentratorami Virtual WAN lub routingu opartego na bramach.
  • Globalne usługi równoważenia obciążenia (Traffic Manager lub Front Door) kierują użytkowników do poprawnego wdrożenia regionalnego.

Aby uzyskać wskazówki dotyczące planowania podsieci i adresów, zobacz Planowanie adresów IP.

Strefy dostępności a nadmiarowość regionalna

Przed zaprojektowaniem topologii wieloregionowej zapoznaj się z dwoma poziomami nadmiarowości infrastruktury w Azure:

Level Chroni przed Mechanizm Example
Strefy dostępności Awaria pojedynczego centrum danych w regionie Fizyczne oddzielne centra danych z niezależnym zasilaniem, chłodzeniem i siecią Strefowo nadmiarowe Azure Firewall wdrożone w 3 strefach
Redundancja regionalna Awaria pełnego regionu (klęska żywiołowa, powszechna awaria) Wdrażanie obciążeń w co najmniej dwóch regionach Azure Aktywna aplikacja internetowa w regionach Wschodnie stany USA i Zachodnie stany USA

Zacznij od nadmiarowości strefowej. Wdrożenia strefowo nadmiarowe chronią przed najczęstszymi scenariuszami awarii (problemy z pojedynczym centrum danych) bez złożoności routingu w wielu regionach. Dodaj nadmiarowość regionalną, gdy firma wymaga ochrony przed awariami w całym regionie lub gdy musisz obsługiwać geograficznie rozproszonych użytkowników.

Dokumentacja usług sieciowych strefowo nadmiarowych

W poniższej tabeli przedstawiono opcje wdrożenia nadmiarowych strefowo podstawowych usług sieciowych. Wdróż je w każdym regionie, w którym są uruchamiane obciążenia:

Service Opcja strefowo nadmiarowa Notatki
Azure Firewall Wdrażanie w różnych strefach dostępności Jest rozdzielony między wszystkie 3 strefy w regionie
usługa Load Balancer w warstwie Standardowa Fronton strefowo nadmiarowy Domyślne zachowanie dla standardowej jednostki SKU
Application Gateway (wersja 2) Wdrożenie strefowo nadmiarowe Wymaga jednostki SKU Standard_v2 lub WAF_v2
brama VPN Aktywny-aktywny z jednostkami SKU strefowo nadmiarowymi Użyj jednostek SKU z sufiksem AZ (VpnGw1AZ, VpnGw2AZ itp.)
Brama ExpressRoute Jednostki SKU strefowo nadmiarowe Użyj ErGw1AZ, ErGw2AZ lub ErGw3AZ
Azure Bastion Strefowo nadmiarowy (wersja zapoznawcza) SKU Podstawowe, Standardowe i Premium
Brama translatora adresów sieciowych (StandardowaV2) Nadmiarowość strefowa Wymagana jest jednostka SKU StandardV2; jednostka SKU Standard jest dostępna wyłącznie jako strefowa

Jak wybrać podejście do routingu ruchu między regionami

Poniższa tabela decyzyjna umożliwia wybranie odpowiedniej usługi na potrzeby routingu ruchu między regionami:

Wymaganie Zalecana usługa Jak to działa
Przełączanie awaryjne lub równoważenie obciążenia w wielu regionach dla dowolnego protokołu (HTTP, TCP, UDP) Azure Traffic Manager Zwraca najlepszy adres IP punktu końcowego za pośrednictwem rozpoznawania nazw DNS. Klient łączy się bezpośrednio z punktem końcowym. Szybkość przełączenia awaryjnego zależy od wartości TTL DNS (zazwyczaj 30–300 sekund).
Globalne równoważenie obciążenia HTTP/HTTPS z CDN, WAF i szybkim przełączaniem awaryjnym Azure Front Door Kończy połączenia w brzegowych punktach obecności (PoP). Kieruje żądania do najbliższego sprawnego backendu. Zapewnia przełączanie awaryjne na poziomie połączenia (w ciągu kilku sekund, bez zależności od DNS TTL).
Prywatny ruch zaplecza między regionami (replikacja, wewnętrzne interfejsy API) Globalna komunikacja równorzędna sieci wirtualnych Łączy sieci wirtualne między regionami za pośrednictwem sieci szkieletowej Microsoft. Peering nie ma charakteru przechodniego; każda relacja peeringu musi być jawnie zdefiniowana. Obowiązują opłaty za transfer danych za każdy GB.
Łączność lokalna typu lokacja-lokacja za pośrednictwem platformy Azure ExpressRoute Global Reach Łączy dwa obwody usługi ExpressRoute, aby lokalizacje lokalne mogły komunikować się za pośrednictwem sieci szkieletowej firmy Microsoft bez przechodzenia przez routery koncentratora.

Tip

Połącz te usługi. Na przykład użyj usługi Front Door do obsługi ruchu HTTP skierowanego do użytkowników, a Global VNet Peering do replikacji zaplecza między regionami.

Jak wybrać topologię koncentratora wieloregionalnego

Po podjęciu decyzji o rozszerzeniu sieci między regionami wybierz wzorzec koncentratora do zarządzania łącznością między regionami:

Czynnik Koncentrator na region (tradycyjny) Virtual WAN wielu koncentratorów
Łączność między regionami Klient konfiguruje globalny peering sieci wirtualnych między regionalnymi koncentratorami sieci i zarządza trasami definiowanymi przez użytkownika Automatyczne trasowanie między koncentratorami: wszystkie koncentratory Virtual WAN są domyślnie połączone ze sobą
Management Pełna kontrola klienta nad routingiem, regułami zapory i komunikacją równorzędną Infrastruktura koncentratora zarządzana przez firmę Microsoft z zarządzaniem opartym na zasadach
Najlepsze dla Organizacje, które potrzebują precyzyjnej kontroli routingu, niestandardowych urządzeń NVA lub istniejących inwestycji w architekturę koncentratora Organizacje z wieloma regionami, 30+ lokacjami oddziałów lub preferencjami infrastruktury zarządzanej
Tranzyt globalny Wymaga jawnej konfiguracji komunikacji równorzędnej i tras zdefiniowanych przez użytkownika między każdą parą koncentratorów Wbudowane: ruch między dowolnymi dwoma koncentratorami jest automatycznie kierowany
Scaling Dodawaj ręcznie koncentratory i połączenia równorzędne (AVNM może zautomatyzować ten proces) Dodawanie centrów za pośrednictwem konfiguracji Virtual WAN: automatyczne aktualizowanie routingu
Model kosztów Zasoby Hub VNet (zapora, brama, peering) są rozliczane oddzielnie Ceny jednostkowe usługi Virtual WAN oraz połączone zasoby

Aby uzyskać szczegółowe porównanie topologii piasty i szprych w porównaniu z Virtual WAN w jednym regionie, zobacz Topologia piasty i szprych oraz Virtual WAN.

Uwagi dotyczące projektowania

Ukierunkowanie projektu lift-and-shift na wiele regionów

  • W przypadku starszych obciążeń, które nie mogą być rozproszone między strefami lub regionami, zaprojektuj je z myślą o odzyskiwaniu po awarii zamiast o architekturze active-active: użyj Azure Site Recovery do replikacji do regionu odzyskiwania.
  • Utwórz węzeł centralny w regionie odzyskiwania po awarii, który odzwierciedla podstawowy węzeł centralny, tak aby ruch po przełączeniu awaryjnym miał te same usługi współdzielone.
  • Użyj Azure Traffic Manager lub trybu failover DNS, aby przekierować użytkowników podczas awarii regionalnej.
  • Utrzymuj przestrzeń adresową regionu odzyskiwania tak, aby nie nakładała się na przestrzeń adresową regionu podstawowego, co pozwoli uniknąć konfliktów podczas przełączenia awaryjnego i późniejszego połączenia równorzędnego.

Modernizuj fokus projektowania w wielu regionach

  • Wdróż obciążenia obsługujące klientów w konfiguracji aktywne-aktywne w dwóch regionach, korzystając z jednostek SKU z nadmiarowością strefową, aby zapewnić najwyższy poziom odporności.
  • Przypisz nienakładające się zakresy adresów do regionów podstawowych i zapasowych, aby aktywne-aktywne szprychy mogły później używać globalnej komunikacji równorzędnej sieci wirtualnych bez ponownego adresowania.
  • Wybierz warstwę dostarczania według typu aplikacji: Azure Front Door dla aplikacji internetowych i usługi Traffic Manager dla aplikacji innych niż internetowe, dystrybuowanie między regionalnymi publicznymi punktami końcowymi.
  • Umieść publiczne punkty końcowe każdego regionu za zaporą centrum (SNAT i DNAT), aby ruch przychodzący był sprawdzany, zanim dotrze do systemów zaplecza.

Nacisk na projektowanie wielochmurowe i wieloregionowe

  • Użyj usługi Azure Virtual WAN, aby połączyć ze sobą wiele regionów platformy Azure, oddziałów i brzegów sieci chmurowej za pomocą automatycznego routingu typu każdy z każdym.
  • Zaplanuj zbiorczo nienakładające się zakresy adresów w różnych regionach i chmurach, aby routing tranzytowy pozostał prosty.
  • Terminuj połączenia IPsec między chmurami na regionalnych zabezpieczonych koncentratorach i pozostaw usłudze Virtual WAN obsługę routingu między koncentratorami.
  • Rozdziel publiczny ruch przychodzący między regionami za pomocą usługi Front Door lub Traffic Manager oraz utrzymuj inspekcję na zaporze każdego regionalnego koncentratora.

Prerequisites

Przed zaprojektowaniem sieci wieloregionowej upewnij się, że masz następujące elementy:

  • Wdrożono i przetestowano topologię z jednym regionem. Zacznij od hub-and-spoke lub Virtual WAN.
  • Określono wymagania dotyczące wysokiej dostępności i odtwarzania po awarii: RTO, docelowy czas odzyskiwania, docelowy punkt odzyskiwania (RPO) oraz wymogi zgodności.
  • Utworzono plan nienakładających się adresów IP we wszystkich regionach. Zobacz Planowanie adresów IP.
  • Zidentyfikowano, które obciążenia wymagają nadmiarowości regionalnej, a które tylko nadmiarowości strefowej.

Wzorce wdrażania aktywno-aktywne kontra aktywno-pasywne

Model wdrażania w wielu regionach określa, jak przepływa ruch podczas normalnego działania i podczas awarii regionalnej:

Active-active

Oba regiony obsługują ruch jednocześnie. Globalny moduł równoważenia obciążenia, taki jak Traffic Manager lub Front Door, dystrybuuje żądania między regionami w oparciu o bliskość, wydajność lub wagę.

Kiedy używać trybu „active-active”:

  • Aplikacja może obsługiwać żądania w dowolnym regionie bez zależności stanu specyficznego dla regionu.
  • Potrzebujesz możliwie najniższego RTO (przełączenie awaryjne następuje natychmiast, ponieważ sprawny region już obsługuje ruch).
  • Chcesz użyć pojemności w obu regionach podczas normalnego działania (efektywność kosztowa).

Zagadnienia dotyczące sieci:

  • Oba regiony muszą mieć identyczną infrastrukturę sieciową, w tym zapory, bramy i moduły równoważenia obciążenia.
  • Replikacja danych między regionami musi zapewniać aktualność obu wdrożeń.
  • Wartość TTL DNS i interwały sond kondycji określają, jak szybko Traffic Manager przełącza ruch. Usługa Front Door zapewnia szybsze przejście w tryb failover na poziomie połączenia.

Active-passive

Jeden region (podstawowy) obsługuje cały ruch. Region pomocniczy pozostaje gotowy, ale nie obsługuje żądań użytkowników do momentu wystąpienia zdarzenia trybu failover.

Kiedy należy używać trybu aktywno-pasywnego:

  • Aplikacja ma ścisłe wymagania dotyczące regionu zapisu lub nie może łatwo replikować stanu.
  • Ograniczenia kosztów uniemożliwiają jednoczesne uruchamianie pełnej pojemności w dwóch regionach.
  • Tolerancja RTO uwzględnia czas potrzebny do aktywowania regionu zapasowego.

Zagadnienia dotyczące sieci:

  • Infrastruktura sieciowa w regionie pasywnym może korzystać z niższych poziomów lub obniżonej przepustowości do momentu przełączenia awaryjnego.
  • Automatyczne przełączenie awaryjne wymaga sond kondycji systemu z odpowiednio ustawionymi progami (aby uniknąć niestabilnego przełączania).
  • Regularnie testuj mechanizm przełączania awaryjnego. Konfiguracje sieci w regionie pasywnym mogą dryfować, jeśli nie są weryfikowane.
  • Utrzymuj tabele tras i reguły NSG zsynchronizowane między regionami. Użyj szablonów infrastruktury jako kodu, aby upewnić się, że region pasywny jest zgodny ze stanem zabezpieczeń regionu podstawowego.
  • Wstępnie aprowizuj bramy VPN lub ExpressRoute w regionie pasywnym. Aprowizowanie bramy może potrwać od 20 do 45 minut. To zbyt wolno dla większości docelowych wartości RTO.

Wybieranie między siecią aktywne-aktywne i aktywne-pasywne

Wybór między trybem active-active a active-passive wpływa na wymiarowanie sieci, koszty i złożoność operacyjną:

Rozważenie Active-active Active-passive
Pojemność sieci Pełna pojemność w obu regionach Zmniejszona pojemność w regionie pasywnym (skalowanie w trybie failover)
Konfigurowanie bramy Zawsze włączone w obu regionach Wstępnie aprowizowana, ale może korzystać z mniejszych poziomów
Synchronizacja danych między regionami Ciągły, dwukierunkowy ruch replikacji Jednokierunkowa replikacja asynchroniczna do serwera zapasowego
Reguły zapory sieciowej Identyczne zestawy reguł, oba aktywnie wymuszane Identyczne zestawy reguł, ale zestaw pasywny jest rzadko używany
Adresowanie IP Oba regiony ogłaszają się do globalnego modułu równoważenia obciążenia Tylko region podstawowy ogłasza się do momentu przełączenia awaryjnego
Ryzyko operacyjne Dolna: obie ścieżki są stale wykorzystywane Wyższe: ścieżka pasywna może dryfować lub mieć nietestowane konfiguracje

Replikacja danych i opóźnienie

Replikacja między regionami wprowadza opóźnienie sieci, które ma wpływ na projekt aplikacji. Regiony platformy Azure w obrębie tego samego obszaru geograficznego zazwyczaj charakteryzują się opóźnieniem w obie strony wynoszącym 1–10 ms między pobliskimi parami (na przykład East US i East US 2) oraz 30–70 ms między odległymi parami (na przykład East US i West US). Pary transatlantyckie lub transpacyficzne mogą przekraczać 100 ms.

Kluczowe zagadnienia dotyczące projektowania:

  • Topologia replikacji: Wybierz replikację synchroniczną tylko dla par regionów z małym opóźnieniem (< 10 ms). Użyj replikacji asynchronicznej dla odległych par, aby uniknąć obniżenia wydajności aplikacji.
  • Planowanie przepustowości: Oszacuj wymagania dotyczące przepustowości replikacji i uwzględnij koszty transferu danych za GB dla globalnego peeringu sieci wirtualnych. Replikacja na dużą skalę między odległymi geograficznie regionami może generować znaczne opłaty za transfer wychodzący.
  • Rozwiązywanie konfliktów: Wzorce active-active z zapisami dwukierunkowymi wymagają strategii rozwiązywania konfliktów na poziomie aplikacji lub bazy danych. Sieć zapewnia łączność, ale aplikacje muszą obsługiwać konflikty zapisu.
  • Prywatne punkty końcowe replikacji PaaS: Podczas replikowania Azure SQL, usługi Cosmos DB lub magazynu w różnych regionach użyj prywatnych punktów końcowych w każdym regionie, aby zachować ruch związany z replikacją w sieci szkieletowej Microsoft i uniknąć publicznej ekspozycji w Internecie.

Zagadnienia dotyczące kosztów

Sieć wieloregionowa zwiększa koszty dzięki zduplikowanej infrastrukturze i transferowi danych między regionami. Zaplanuj budżet wokół tych podstawowych czynników kosztów:

  • Przesył danych między regionami: Global Peering sieci wirtualnych oraz ruch między koncentratorami Virtual WAN podlegają opłatom naliczanym za każdy GB danych przesyłanych między regionami. Ruch wewnątrzregionalny między sparowanymi sieciami wirtualnymi w tym samym regionie nie podlega dodatkowym opłatom w tej samej strefie, a między strefami jest naliczany według niższej stawki.
  • Powielone urządzenia sieciowe: Każdy region wymaga własnej zapory sieciowej, modułu równoważenia obciążenia i instancji bramy. Wdrożenia w modelu active-active podwajają te koszty. Wdrożenia aktywne-pasywne mogą obniżyć koszty dzięki użyciu mniejszych warstw w regionie rezerwowym i skalowania w górę podczas pracy w trybie failover.
  • Globalne opłaty za równoważenie obciążenia: Zarówno usługa Traffic Manager, jak i usługa Front Door naliczają opłaty na podstawie zapytań DNS lub przetworzonych żądań. Front Door nalicza dodatkowe opłaty za transfer danych z brzegowych punktów PoP do serwerów zaplecza.
  • ExpressRoute i brama sieci VPN: Architektury wieloregionowe często wymagają instancji bramy w każdym regionie. Obwody ExpressRoute łączące wiele regionów wiążą się z miesięcznymi opłatami portowymi oraz opłatami za transfer danych naliczanymi za każdy GB.
  • Optymalizacja z uwzględnieniem lokalności ruchu: Projektuj warstwy aplikacji w celu zminimalizowania wywołań międzyregionalnych. Utrzymuj repliki do odczytu w każdym regionie w tej samej lokalizacji co zasoby obliczeniowe, aby ograniczyć wykorzystanie przepustowości na potrzeby replikacji i zmniejszyć opóźnienia w przypadku zapytań wrażliwych na czas odpowiedzi.

Zagadnienia dotyczące zabezpieczeń

Sieć wieloregionowa wprowadza zagadnienia dotyczące zabezpieczeń poza wdrożeniami w jednym regionie:

  • Ruch sieciowy pozostaje w obrębie sieci szkieletowej firmy Microsoft. Cały ruch między regionami w ramach globalnej komunikacji równorzędnej sieci wirtualnej lub łączności między koncentratorami w usłudze Virtual WAN przechodzi przez sieć szkieletową firmy Microsoft, a nie przez publiczny internet.
  • Wdróż zapory nadmiarowe między strefami w każdym regionie. Każde centrum regionalne potrzebuje własnej instancji zapory do inspekcji ruchu. Wdróż zapory w różnych strefach dostępności, aby zachować bezpieczeństwo podczas awarii strefy.
  • Zapora aplikacji internetowej usługi Front Door zapewnia zabezpieczenia brzegowe. Gdy używasz usługi Front Door, zintegrowana z nią zapora aplikacji internetowych analizuje ruch, zanim dotrze on do jakiegokolwiek wdrożenia regionalnego. Zapewnia to pierwszą warstwę obrony na brzegu sieci.
  • Starannie zaplanuj mechanizm przełączania awaryjnego DNS. Przełączenie awaryjne usługi Traffic Manager zależy od wartości TTL DNS. Krótsze wartości TTL umożliwiają szybsze przełączenie awaryjne, ale zwiększają liczbę zapytań DNS. Usługa Front Door zapewnia tryb failover na poziomie połączenia, który nie zależy od wygaśnięcia pamięci podręcznej DNS klienta.
  • Ruch usługi ExpressRoute Global Reach pozostaje prywatny. Ruch między lokacjami lokalnymi połączonymi za pośrednictwem usługi Global Reach nigdy nie dotyka publicznego Internetu. Pozostaje w sieci szkieletowej firmy Microsoft między obwodami.
  • Zabezpieczanie kanałów replikacji między regionami. Ruch replikacji zaplecza przez Global VNet Peering jest domyślnie prywatny, ale w przypadku poufnych danych podczas przesyłania należy stosować grupy zabezpieczeń sieciowych i szyfrowanie.

Jeśli projekt obejmujący wiele regionów obejmuje konkretne scenariusze omówione w innym miejscu w tym przewodniku, zobacz:

Learn more

Aby uzyskać więcej informacji na temat usług i pojęć omówionych w tym artykule, zobacz następujące zasoby:

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:

Połącz się z siecią lokalną: Po zaplanowaniu odzyskiwania po awarii skonfiguruj połączenie VPN lub ExpressRoute z siecią lokalną.

Kolejny etap procesu modernizacji:

Zaprojektuj wzorce ruchu przychodzącego z internetu: Określ, jak ruch klientów dociera do Twoich aplikacji w regionach podstawowych i zapasowych.

Kolejny krok w Twojej wielochmurowej podróży:

Skonfiguruj szyfrowane tunele w innych chmurach: po planowaniu wielu regionów skonfiguruj łączność sieci VPN między chmurami.

  • Last updated on