Ścieżka projektowania sieci między chmurami

Ten przewodnik przedstawia uporządkowaną ścieżkę lektury w Przewodniku projektowania sieci platformy Azure dla klientów łączących platformę Azure z Amazon Web Services (AWS) lub Google Cloud albo migrujących obciążenia od innego dostawcy chmury. Wykonaj ponumerowane kroki, aby zaprojektować bezpieczną, monitorowaną łączność między Azure a istniejącą infrastrukturą chmury.

Dlaczego odnajdywanie jest pierwsze

Sieć między chmurami łączy Azure z co najmniej jednym zewnętrznym środowiskiem chmury. Możesz uruchamiać obciążenia w usługach AWS lub Google Cloud, które wymagają prywatnej łączności z usługami Azure, lub migrować aplikacje z innej chmury do Azure przy zachowaniu łączności z aplikacjami, które pozostają w tyle. Tak czy inaczej sieć Azure musi być zintegrowana z infrastrukturą, która nie jest w pełni sterowana po drugiej stronie.

Ta ścieżka edukacyjna zaczyna się od poznawania, a nie od projektowania infrastruktury platformy Azure. Najpierw zamapujesz istniejącą topologię wielochmurową (zrozumiesz, gdzie działa, jak się łączy i jaki ruch przepływa między chmurami) przed zaprojektowaniem strony Azure. Takie podejście, oparte najpierw na rozpoznaniu, pozwala uniknąć konieczności wprowadzania poprawek: jeśli projektujesz sieć na platformie Azure bez zrozumienia topologii środowiska AWS lub Google Cloud, ryzykujesz konflikty adresów IP, luki w łączności i martwe pola w zabezpieczeniach.

Docelowa architektura wykorzystuje usługę Azure Virtual Wide Area Network (WAN) jako koncentrator tranzytowy (odpowiednik AWS Transit Gateway w usłudze Azure), z tunelami VPN IPSec do AWS Virtual Private Gateway i Google Cloud VPN. Usługa Azure Firewall w bezpiecznym centrum wirtualnym inspekcjonuje cały ruch między chmurami i z oddziałów. System DNS wymaga starannego planowania jednorazowego, aby rozpoznawanie nazw działało przez granice chmury podczas migracji.

Prerequisites

  • Zapoznaj się z omówieniem planowania i projektowania sieci na platformie Azure, aby zapoznać się z dostępnymi usługami sieciowymi platformy Azure.
  • Ukończ odnajdywanie topologii środowisk AWS i Google Cloud:
    • AWS: Uruchamianie centrum migracji platformy AWS lub odnajdywania obciążeń na platformie AWS w celu tworzenia spisu wirtualnych chmur prywatnych (VPC), bram tranzytowych i łączności między sieciami VPC.
    • Google Cloud: użyj centrum analizy sieciowej do mapowania sieci VPC, załączników Cloud Interconnect i reguł zapory.
  • Udokumentuj przepływy ruchu między chmurami: które aplikacje komunikują się między chmurami, jaka przepustowość jest wymagana, jaka jest wrażliwość na opóźnienia oraz jakie są wymagania dotyczące szyfrowania.
  • Utwórz spis zakresów adresów IP we wszystkich trzech chmurach, aby zidentyfikować nakładające się na siebie.

Ścieżka do czytania

Poniższe fazy prowadzą cię przez sekwencję projektowania sieci między chmurami.

Faza 1. Odnajdywanie

Zacznij od odnajdywania. Zapoznaj się z krajobrazem wielochmurowym przed projektowaniem infrastruktury Azure.

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

Ten artykuł jest centralnym punktem decyzyjnym projektowania. Mapowanie topologii wielochmurowej: które instancje VPC w AWS i Google Cloud wymagają łączności z platformą Azure, jaki ruch przepływa między chmurami oraz który wzorzec architektury najlepiej odpowiada skali wdrożenia. Użyj mapowania usług między dostawcami chmury (Transit Gateway na Virtual WAN, Security Groups na Network Security Groups, VPC Peering na komunikację równorzędną sieci wirtualnych — VNet peering), aby przełożyć istniejący projekt na terminy stosowane na platformie Azure.

2. Azure Virtual WAN

Virtual WAN jest zalecanym modelem tranzytowym, gdy masz wiele sieci VPN, gałęzi, regionów lub krawędzi chmury. Virtual WAN stanowi odpowiednik usługi AWS Transit Gateway na platformie Azure: oferuje automatyczne trasowanie, scentralizowane zabezpieczenia oraz skalowalność obejmującą wiele oddziałów i regionów. Oceń, czy Twoje środowisko wielochmurowe uzasadnia użycie Virtual WAN, czy wystarczy prostsza topologia piasty i szprych z użyciem VPN Gateway.

Faza 2. Podstawy

3. Sieci wirtualne i podsieci

Zaprojektuj sieć wirtualną Azure jako strefę docelową dla migrowanych lub połączonych obciążeń. Odwzoruj pojęcia z AWS VPC i Google Cloud VPC w następujący sposób: podsieci VPC stają się podsieciami Azure, strefy dostępności odpowiadają strefom dostępności platformy Azure, a tabele tras są odwzorowywane według podobnych wzorców. Skoncentruj się na określaniu rozmiaru podsieci dla obciążeń, które wylądowały w Azure.

4. Planowanie adresów IP

Zaplanuj nienakładające się przestrzenie adresowe we wszystkich trzech chmurach. Ten krok ma kluczowe znaczenie dla łączności między chmurami: jeśli zakresy sieci wirtualnych Azure nakładają się na zakresy VPC platformy AWS lub zakresy VPC usługi Google Cloud, nie można ustanowić między nimi tuneli sieci VPN. Udokumentuj każdy blok CIDR używany we wszystkich środowiskach przed przydzieleniem przestrzeni adresowej platformy Azure.

5. Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji

Odwzoruj grupy zabezpieczeń AWS i reguły zapory sieciowej Google Cloud jako sieciowe grupy zabezpieczeń (NSG) platformy Azure. Przetłumacz istniejące reguły zezwalające i odrzucające na format NSG. Użyj grup zabezpieczeń aplikacji (ASG), aby odtworzyć grupowanie oparte na tagach, jakie zapewniają odwołania do grup zabezpieczeń AWS.

Faza 3. Łączność

6. Łączność hybrydowa

Skonfiguruj tunele SIECI VPN IPSec między Azure i usługami AWS lub Google Cloud w celu szyfrowania przesyłania między chmurami. Połącz usługę Azure VPN Gateway (lub połączenia VPN usługi Virtual WAN) z usługami AWS Virtual Private Gateway i Google Cloud VPN. Wybierz przepustowość tunelu na podstawie potrzeb ruchu między chmurami. Zaplanuj nadmiarowe tunele, aby uniknąć pojedynczych punktów awarii.

Faza 4. Zabezpieczenia

7. Zabezpieczenia DNS i rozpoznawanie nazw prywatnych

Zaplanuj strategię przełączenia DNS przed migracją obciążeń. Aplikacje w AWS lub Google Cloud rozwiązują nazwy hostów, które po migracji mogą wymagać wskazywania na platformę Azure. Skonfiguruj usługę Azure DNS Private Resolver z wychodzącymi punktami końcowymi do rozpoznawania nazw między chmurami. Zapoznaj się z listą kontrolną migracji jednorazowej DNS w dalszej części tego artykułu, aby uzyskać szczegółowe wskazówki dotyczące migracji.

8. Azure Firewall

Wdróż Azure Firewall w bezpiecznym koncentratonie wirtualnym, aby sprawdzić cały ruch między chmurami i oddziałami. Każde przechodzenie pakietów między usługami Azure i AWS lub Google Cloud przechodzi przez zaporę na potrzeby rejestrowania i wymuszania zasad. Użyj reguł sieci dla wzorców ruchu między chmurami i filtrowania analizy zagrożeń, aby zablokować znane złośliwe miejsca docelowe.

Faza 5. Operacje

9. Monitorowanie sieci i obserwowanie

Środowiska obejmujące wiele chmur trudniej diagnozować, ponieważ nie kontrolujesz obu końców każdego połączenia. Włącz Azure Network Watcher na potrzeby testowania łączności, diagnostyki tunelu sieci VPN i przechwytywania pakietów. Monitoruj czas pracy tunelu, opóźnienie między chmurami i przepływność w zależności od wymagań dotyczących pojemności. Ustaw alerty dotyczące rozłączeń tunelu, które mają wpływ na dostępność aplikacji między chmurami.

Artykuły warunkowe

Uwzględnij następujące artykuły na podstawie określonych wymagań:

Warunek Artykuł Kiedy należy uwzględnić
Aplikacja publiczna Ruch przychodzący z Internetu Migrowana aplikacja jest dostępna z Internetu (wymagany jest bezpośredni dostęp publiczny)
Aplikacja HTTP/HTTPS Web Application Firewall Zapora aplikacji internetowych w warstwie 7 jest wymagana w przypadku publicznych aplikacji internetowych
Dystrybucja w warstwie 7 wymagana Dostarczanie i wydajność aplikacji Po migracji potrzebny jest globalny lub regionalny rozkład ruchu
Publiczne punkty końcowe Ochrona przed atakami DDoS Masz wymagania dotyczące dostępności usług dostępnych publicznie
Preferowana topologia piasta–szprychy Topologia piasty i szprych Twoje środowisko wielochmurowe jest na tyle małe, że wdrożenie Virtual WAN nie jest uzasadnione
Azure z wieloma regionami Sieć w wielu regionach Obiekt docelowy platformy Azure rozciąga się na wiele regionów i wykracza poza łączność między chmurami
Dostęp administratora maszyny wirtualnej Dostęp dewelopera i administratora Wymagany jest bezpieczny dostęp RDP/SSH do maszyn wirtualnych hostowanych Azure
Scentralizowany ruch wychodzący Wychodzący dostęp do Internetu Scentralizowane zasady ruchu wychodzącego z Internetu są częścią projektu docelowego
Duże środowisko sieci VNet Scentralizowane zarządzanie siecią Środowisko Azure przekształca się w objęte ładem środowisko obejmujące wiele subskrypcji
Prywatne punkty końcowe usługi PaaS Prywatny dostęp PaaS Architektura docelowa obejmuje usługi PaaS Azure z prywatnymi punktami końcowymi

Lista kontrolna wykrywania w wielu chmurach

Przed zaprojektowaniem sieci na platformie Azure przyporządkuj istniejące usługi chmurowe do ich odpowiedników na platformie Azure. To mapowanie przyspiesza podejmowanie decyzji projektowych i zapobiega niezgodności oczekiwań.

Mapowanie usług AWS na Azure

Usługa AWS Odpowiednik platformy Azure Notatki
Brama tranzytowa Azure Virtual WAN Scentralizowany koncentrator routingu dla wielu VPC, wielu regionów, wielu chmur
VPC Azure Virtual Network Izolowana granica sieci z podsieciami i tabelami tras
Komunikacja równorzędna VPC Komunikacja równorzędna sieci VNet Bezpośrednia łączność między dwiema sieciami wirtualnymi
Grupy zabezpieczeń Sieciowe grupy zabezpieczeń (NSG): Stanowe filtrowanie ruchu na poziomie podsieci lub interfejsu sieciowego
Listy ACL sieci Sieciowe grupy zabezpieczeń (poziom podsieci) Grupy zabezpieczeń sieci (NSG) platformy Azure łączą funkcje zarówno grup zabezpieczeń, jak i list kontroli dostępu do sieci (NACL)
Wirtualna brama prywatna brama VPN Punkt zakończenia sieci VPN protokołu IPSec
Bezpośrednie połączenie Azure ExpressRoute Dedykowana łączność prywatna (nie przez publiczny Internet)
Prywatne strefy hostowane Route 53 Prywatne strefy DNS usługi Azure Rozpoznawanie prywatnych nazw DNS w sieciach wirtualnych
Tablice routingu Trasy zdefiniowane przez użytkownika (UDR) Niestandardowe trasowanie umożliwiające zastąpienie tras systemowych platformy Azure lub domyślnych tras platformy AWS
Elastic Load Balancer (ALB/NLB) Azure Load Balancer/Application Gateway Równoważenie obciążenia L4 i L7; Application Gateway zapewnia funkcje WAF podobne do AWS ALB z usługą AWS WAF
AWS WAF Azure Web Application Firewall Ochrona protokołu HTTP/HTTPS w warstwie 7
Zapora sieciowa Azure Firewall Stanowa zapora sieciowa z analizą zagrożeń

Mapowanie usługi Google Cloud do Azure

Usługa Google Cloud Odpowiednik platformy Azure Notatki
Sieć VPC Azure Virtual Network Zasób globalny w Google Cloud; regionalny w Azure (użyj peeringu sieci wirtualnych — VNet peering — między regionami)
Połączenie między chmurami Azure ExpressRoute Prywatna łączność dedykowana
Sieć VPN w chmurze brama VPN Tunele SIECI VPN protokołu IPSec
Chmurowy NAT Azure NAT Gateway Wychodzący dostęp do Internetu dla zasobów prywatnych
Router w chmurze Azure Route Server Dynamiczna wymiana tras protokołu BGP z wirtualnymi urządzeniami sieciowymi
Cloud Armor Azure Web Application Firewall Warstwa 7 ataków DDoS i ochrona aplikacji
Reguły zapory sieciowej Grupy zabezpieczeń sieci Filtrowanie ruchu (reguły Google Cloud są globalne; sieciowe grupy zabezpieczeń Azure są przypisywane do poszczególnych podsieci lub interfejsów sieciowych)
Chmura — strefy prywatne DNS Prywatne strefy DNS usługi Azure Rozpoznawanie nazw prywatnych w sieciach
Centrum analizy sieciowej Azure Network Watcher Monitorowanie sieci, diagnostyka i wizualizacja topologii

Lista kontrolna przełączenia DNS

Przełączenie DNS to etap obarczony najwyższym ryzykiem w migracji między chmurami. Postępuj zgodnie z tą listą kontrolną, aby zminimalizować błędy rozwiązywania podczas przejścia.

Przed migracją

  1. Obniż wartości TTL (Time to Live) we wszystkich rekordach DNS, które ulegają zmianie. Ustaw TTL na 60–300 sekund co najmniej 48 godzin przed przełączeniem. Ten krok zapewnia szybkie wygaśnięcie pamięci podręcznej podczas aktualizowania rekordów.
  2. Udokumentuj każdy rekord DNS wskazujący migrowanie infrastruktury: rekordy dla serwerów, rekordy CNAME dla usług, rekordy MX dla poczty i rekordy SRV na potrzeby odnajdywania usługi.
  3. Skonfiguruj Azure DNS private resolver przy użyciu wychodzących punktów końcowych w sieci wirtualnej Azure. Ten program rozpoznawania nazw przekazuje zapytania dotyczące stref hostowanych przez platformę AWS/Google w chmurze do odpowiednich nadrzędnych serwerów DNS w okresie współistnienia.
  4. Przetestuj i odwróć rozpoznawanie z sieci wirtualnych Azure do nazw hostowanych w chmurze AWS/Google przed migracją wszystkich obciążeń.

Podczas migracji

  1. Zaktualizuj rekordy CNAME dla usług, które przechodzą do Azure. Skieruj rekordy CNAME do punktów końcowych usług Azure Front Door, Azure Traffic Manager lub Azure Application Gateway w miarę migrowania poszczególnych usług.
  2. Zaktualizuj rekordy A hosta dla poszczególnych migrowanych serwerów. Zastąp adresy IP AWS lub Google Cloud prywatnymi adresami IP platformy Azure w strefach DNS.
  3. Pozostaw przekazywanie warunkowe włączone, aby nazwy w strefach, których jeszcze nie zmigrowano, nadal były rozwiązywane za pośrednictwem serwerów DNS pierwotnej chmury.

Po migracji

  1. Zweryfikuj rozwiązywanie nazw ze wszystkich lokalizacji: klienci lokalni, sieci wirtualne platformy Azure oraz wszelkie pozostałe obciążenia uruchomione w AWS lub Google Cloud muszą prawidłowo rozwiązywać zmigrowane nazwy.
  2. Podnieś wartości czasu wygaśnięcia z powrotem do poziomów produkcji (3600 sekund lub więcej) po potwierdzeniu stabilnej rozdzielczości.
  3. Usuń warunkowe przekierowania dla stref, które zostały w pełni zmigrowane do Azure DNS. Zachowaj usługi przesyłania dalej tylko dla stref, które pozostają w usługach AWS lub Google Cloud.

Co utworzono

Korzystając z tej ścieżki szkoleniowej, połączysz platformę Azure z istniejącym środowiskiem AWS lub Google Cloud, korzystając z szyfrowanej transmisji, scentralizowanej inspekcji ruchu przez zaporę i monitorowanej łączności. Twój projekt obejmuje:

  • Odnajdywanie topologii w wielu chmurach i mapowanie usług
  • architektura tranzytowa Virtual WAN lub piasty i szprych
  • Tunele VPN IPSec do usług AWS i Google Cloud
  • Azure Firewall na potrzeby inspekcji ruchu między chmurami
  • Migracja jednorazowa DNS z usługą Private Resolver na potrzeby rozpoznawania nazw między chmurami
  • Network Watcher monitorowanie kondycji i wydajności tunelu

Następne kroki

  • Last updated on