Sieć typu szprycha-szprycha

Najbardziej typowe wzorce projektowania sieci na platformie Azure obejmują tworzenie topologii sieci wirtualnej piasty i szprych w jednym lub wielu regionach świadczenia usługi Azure, opcjonalnie połączone z sieciami lokalnymi za pośrednictwem usługi Azure ExpressRoute lub tuneli wirtualnej sieci prywatnej (VPN) typu lokacja-lokacja za pośrednictwem publicznego Internetu.

Większość przewodników projektowych koncentruje się na ruchu aplikacji do tych sieci wirtualnych od użytkowników w sieciach wewnętrznych, lokalnych lub z Internetu (co przemysł zazwyczaj wyznacza ruch na północ-południe, ponieważ jest często reprezentowany przez linie pionowe na diagramach sieciowych). Ten artykuł koncentruje się na różnych wzorcach, które są dostępne dla ruchu wschodnio-zachodniego. Oznacza to, że przepływy komunikacji między obciążeniami wdrożonym w sieciach wirtualnych platformy Azure w jednym regionie lub w różnych regionach.

Upewnij się, że projekt sieci spełnia wymagania dotyczące ruchu wschodnio-zachodniego, ma kluczowe znaczenie dla zapewnienia wydajności, skalowalności i odporności aplikacji uruchomionych na platformie Azure.

Potencjalne przypadki użycia

Ruch szprychy do szprych może być ważny w kilku scenariuszach:

• Różne warstwy pojedynczej aplikacji znajdują się w oddzielnych sieciach wirtualnych. Na przykład serwery sieci obwodowej (nazywane również serwerami DMZ) w sieci wirtualnej obwodowej komunikują się z usługami aplikacji w wewnętrznej sieci wirtualnej.
• Obciążenia aplikacji w różnych środowiskach (programowanie, przemieszczanie, produkcja) muszą replikować dane między sobą.
• Różne aplikacje lub mikrousługi muszą komunikować się ze sobą.
• Bazy danych muszą replikować dane między regionami, aby zagwarantować ciągłość działania w przypadku awarii.
• Użytkownicy znajdują się w sieciach wirtualnych platformy Azure. Na przykład używają usługi Azure Virtual Desktop.

Wzorce i topologie komunikacji między szprychami

Istnieją dwie główne topologie, których można używać w projektach platformy Azure, które korzystają z wielu sieci wirtualnych: tradycyjnego koncentratora i szprychy oraz usługi Azure Virtual WAN. W środowisku usługi Virtual WAN firma Microsoft zarządza siecią wirtualną koncentratora i wszystkim wewnątrz niego. W tradycyjnym środowisku piasty i szprych zarządzasz siecią wirtualną piasty.

Topologie sieci Virtual WAN i piasty i szprych są przykładami architektur, w których obciążenia działają w sieciach wirtualnych szprych, a łączność z siecią lokalną jest scentralizowana w sieci wirtualnej piasty. Tak wiele pojęć opisanych w tym artykule dotyczy zarówno projektów piasty i szprych, jak i wirtualnej sieci WAN.

Istnieją dwa główne wzorce łączenia ze sobą sieci wirtualnych szprych:

• Szprychy bezpośrednio połączone ze sobą. Komunikacja równorzędna sieci wirtualnych lub tunele vpn są tworzone między sieciami wirtualnymi szprych w celu zapewnienia bezpośredniej łączności bez przechodzenia przez sieć wirtualną koncentratora.
• Szprychy komunikują się za pośrednictwem urządzenia sieciowego. Każda sieć wirtualna szprych ma komunikację równorzędną z usługą Virtual WAN lub z siecią wirtualną piasty. Urządzenie kieruje ruch z szprychy do szprychy. Urządzenie może być zarządzane przez firmę Microsoft (podobnie jak w przypadku usługi Virtual WAN) lub przez Ciebie.

Wzorzec 1: Szprychy połączone bezpośrednio ze sobą

Bezpośrednie połączenia między szprychami zwykle oferują lepszą przepływność, opóźnienie i skalowalność niż połączenia przechodzące przez wirtualne urządzenie sieciowe (WUS) w koncentratonie. Wysyłanie ruchu przez urządzenia WUS może dodać opóźnienie do ruchu, jeśli urządzenia WUS znajdują się w innej strefie dostępności, a co najmniej dwie wirtualne sieci równorzędne muszą być przekraczane, gdy ruch jest wysyłany przez koncentrator. Istnieje kilka opcji łączenia ze sobą dwóch sieci wirtualnych szprych: komunikacja równorzędna sieci wirtualnych, usługa Azure Virtual Network Manager i tunele sieci VPN.

• Komunikacja równorzędna sieci wirtualnych. Zalety bezpośredniej komunikacji równorzędnej sieci wirtualnych na szprychach to:

  • Niższy koszt, ponieważ wymagana jest mniejsza liczba przeskoków komunikacji równorzędnej sieci wirtualnych.
  • Lepsza wydajność, ponieważ ruch nie musi przechodzić przez żadne urządzenie sieciowe, które wprowadza opóźnienia lub potencjalne wąskie gardła.

  Inne scenariusze obejmują łączność między dzierżawami. Może jednak być konieczne sprawdzenie ruchu między sieciami wirtualnymi będącej szprychą, co może wymagać wysyłania ruchu za pośrednictwem scentralizowanych urządzeń sieciowych w sieci wirtualnej piasty.

• Menedżer sieci wirtualnej platformy Azure. Oprócz zalet zapewnianych przez komunikację równorzędną sieci wirtualnych usługa Azure Virtual Network Manager udostępnia usługę zarządzania, która umożliwia zarządzanie środowiskami sieci wirtualnych i tworzenie łączności na dużą skalę. Za pomocą usługi Azure Virtual Network Manager można utworzyć trzy typy topologii w ramach subskrypcji zarówno dla istniejących, jak i nowych sieci wirtualnych:

  • Piasta i szprychy, które nie są ze sobą połączone.

  • Piasta i szprychy, które są bezpośrednio połączone ze sobą, bez żadnego przeskoku w środku.

  • Siatkowa grupa sieci wirtualnych, które są połączone ze sobą.

    

    Pobierz wszystkie diagramy programu Visio w tym artykule.

    Podczas tworzenia topologii piasty i szprych za pomocą usługi Azure Virtual Network Manager, w której szprychy są połączone ze sobą, bezpośrednia łączność między sieciami wirtualnymi szprych w tej samej grupie sieci jest automatycznie tworzona dwukierunkowo. Za pomocą usługi Azure Virtual Network Manager można statycznie lub dynamicznie tworzyć szprychy członków sieci wirtualnych określonej grupy sieci, co automatycznie tworzy łączność dla dowolnej sieci wirtualnej.

    Można utworzyć wiele grup sieciowych, aby odizolować klastry sieci wirtualnych szprych od łączności bezpośredniej. Każda grupa sieci zapewnia tę samą obsługę regionu i wielu regionów na potrzeby łączności szprychowo-szprychowej. Pamiętaj, aby zachować poniżej maksymalnych limitów dla usługi Azure Virtual Network Manager, które zostały opisane w temacie Azure Virtual Network Manager FAQ (Menedżer sieci wirtualnej platformy Azure — często zadawane pytania).

• Tunele vpn łączące sieci wirtualne. Usługi sieci VPN można skonfigurować do bezpośredniego łączenia sieci wirtualnych szprych przy użyciu bram sieci VPN firmy Microsoft lub urządzeń WUS sieci VPN innych firm. Zaletą tej opcji jest to, że sieci wirtualne będące szprychami łączą się w chmurach komercyjnych i suwerennych w ramach tego samego dostawcy usług w chmurze lub dostawców łączności między chmurami. Ponadto jeśli w każdej sieci wirtualnej będącej szprychą znajdują się urządzenia WUS sieci rozległej (SD-WAN) zdefiniowane programowo, ta konfiguracja może ułatwić korzystanie z płaszczyzny sterowania i funkcji dostawcy innej firmy w celu zarządzania łącznością sieci wirtualnej.

  Ta opcja może również pomóc spełnić wymagania zgodności dotyczące szyfrowania ruchu w sieciach wirtualnych w jednym centrum danych platformy Azure, które nie są jeszcze udostępniane przez szyfrowanie MACsec. Jednak ta opcja wiąże się z własnym zestawem wyzwań ze względu na limity przepustowości tuneli IPsec (1,25 Gb/s na tunel) i ograniczenia projektowe dotyczące bram sieci wirtualnej w sieciach wirtualnych piasty i szprych: jeśli sieć wirtualna szprych ma bramę sieci wirtualnej będącej szprychą, nie może być połączona z usługą Virtual WAN lub używać bramy sieci wirtualnej koncentratora do łączenia się z sieciami lokalnymi.

Wzorzec 1: Pojedynczy region

Niezależnie od technologii używanej do łączenia sieci wirtualnych szprych ze sobą topologie sieci wyglądają następująco w przypadku jednego regionu:

Wzorzec 1: Wiele regionów

Projekty łączące ze sobą wszystkie sieci wirtualne będące szprychami można również rozszerzyć na wiele regionów. W tej topologii usługa Azure Virtual Network Manager jest jeszcze bardziej krytyczna, aby zmniejszyć koszty administracyjne związane z utrzymaniem wymaganej dużej liczby połączeń.

W przypadku bezpośredniego łączenia sieci wirtualnych szprych ze sobą w topologii w pełni zagęszczonej należy wziąć pod uwagę potencjalnie dużą liczbę wymaganych komunikacji równorzędnej sieci wirtualnych. Na poniższym diagramie przedstawiono ten problem. W tym scenariuszu usługa Azure Virtual Network Manager jest zdecydowanie zalecana, aby można było automatycznie tworzyć połączenia sieci wirtualnej.

Wzorzec 2: Szprychy komunikujące się za pośrednictwem urządzenia sieciowego

Zamiast łączyć sieci wirtualne szprychy bezpośrednio ze sobą, można użyć urządzeń sieciowych do przesyłania dalej ruchu między szprychami. Urządzenia sieciowe zapewniają dodatkowe usługi sieciowe, takie jak głęboka inspekcja pakietów i segmentacja ruchu lub monitorowanie, ale mogą one wprowadzać opóźnienia i wąskie gardła wydajności, jeśli nie są one prawidłowo dopasowane. Te urządzenia są zwykle zlokalizowane w sieci wirtualnej piasty, z którą łączą się szprychy. Istnieje wiele opcji używania urządzenia sieciowego do przesyłania dalej ruchu między szprychami:

• Router koncentratora usługi Virtual WAN. W pełni zarządzana przez firmę Microsoft usługa Virtual WAN zawiera router wirtualny, który przyciąga ruch ze szprych i kieruje go do innej sieci wirtualnej połączonej z usługą Virtual WAN lub z sieciami lokalnymi za pośrednictwem usługi ExpressRoute lub tuneli vpn typu lokacja-lokacja lub punkt-lokacja. Router usługi Virtual WAN jest automatycznie skalowany w górę i w dół, więc musisz upewnić się, że ruch między szprychami pozostaje w granicach usługi Virtual WAN.

• Azure Firewall.Usługa Azure Firewall to urządzenie sieciowe zarządzane przez firmę Microsoft i można je wdrożyć w sieciach wirtualnych koncentratora, którymi zarządzasz, lub w koncentratorach usługi Virtual WAN. Może przekazywać pakiety IP, a także sprawdzać je i stosować reguły segmentacji ruchu zdefiniowane w zasadach. Zapewnia skalowanie automatyczne do limitów usługi Azure Firewall, dzięki czemu nie staje się wąskim gardłem. Należy pamiętać, że usługa Azure Firewall udostępnia gotowe funkcje obejmujące wiele regionów tylko wtedy, gdy jest używana z usługą Virtual WAN. Bez wirtualnej sieci WAN należy zaimplementować trasy zdefiniowane przez użytkownika, aby osiągnąć komunikację między regionalną szprychą i szprychą.

• Wirtualne urządzenia sieciowe innych firm. Jeśli wolisz używać wirtualnego urządzenia sieciowego od partnera firmy Microsoft do przeprowadzania segmentacji routingu i sieci, możesz wdrożyć wirtualne urządzenia sieciowe w topologii piasty i szprych lub wirtualnej sieci WAN. Aby uzyskać więcej informacji, zobacz Wdrażanie urządzeń WUS lub urządzeń WUS o wysokiej dostępności w koncentratorze usługi Virtual WAN. Należy upewnić się, że wirtualne urządzenie sieciowe obsługuje przepustowość generowaną przez komunikację między szprychami.

• Azure VPN Gateway. Bramę sieci VPN platformy Azure można użyć jako typu następnego przeskoku trasy zdefiniowanej przez użytkownika, ale firma Microsoft nie zaleca używania bram sieci wirtualnej sieci VPN do kierowania ruchu szprychy do szprychy. Są one przeznaczone do szyfrowania ruchu do lokacji lokalnych lub użytkowników sieci VPN. Na przykład nie ma gwarancji przepustowości między szprychami, którą brama sieci VPN może kierować.

• ExpressRoute. W niektórych konfiguracjach brama usługi ExpressRoute może anonsować trasy, które przyciągają komunikację szprychy, wysyłając ruch do routera brzegowego firmy Microsoft, gdzie jest kierowany do szprychy docelowej. Firma Microsoft zdecydowanie odradza ten scenariusz, ponieważ wprowadza opóźnienia, wysyłając ruch do sieci szkieletowej firmy Microsoft i z powrotem. Ponadto firma Microsoft nie zaleca tego podejścia ze względu na pojedynczy punkt awarii i duży promień wybuchu. Ten scenariusz przedstawia również wiele problemów spowodowanych przez wywieranie dodatkowej presji na infrastrukturę usługi ExpressRoute (bramę i routery fizyczne). To dodatkowe ciśnienie może spowodować spadek pakietów.

W projektach sieci piasty i szprych, które mają scentralizowane urządzenia WUS, urządzenie jest zwykle umieszczane w koncentratonie. Komunikacja równorzędna sieci wirtualnych między sieciami wirtualnymi piasty i szprych musi zostać utworzona ręcznie lub automatycznie za pomocą usługi Azure Virtual Network Manager:

• Ręczna komunikacja równorzędna sieci wirtualnych. Takie podejście jest wystarczające, gdy masz niewielką liczbę sieci wirtualnych szprych, ale tworzy obciążenie związane z zarządzaniem na dużą skalę.

• Menedżer sieci wirtualnej platformy Azure. Jak wspomniano wcześniej, usługa Azure Virtual Network Manager udostępnia funkcje do zarządzania środowiskami sieci wirtualnej i komunikacją równorzędną na dużą skalę. Konfiguracje komunikacji równorzędnej między sieciami wirtualnymi piasty i szprych są automatycznie konfigurowane dwukierunkowo dla grup sieciowych.

  Usługa Azure Virtual Network Manager umożliwia statyczne lub dynamiczne dodawanie członkostwa w sieci wirtualnej będącej szprychą do określonej grupy sieci, która automatycznie tworzy połączenie komunikacji równorzędnej dla nowych członków. Sieci wirtualne będące szprychami w grupach sieciowych mogą używać sieci VPN piasty lub bram usługi ExpressRoute na potrzeby łączności. Pamiętaj, aby utrzymać się poniżej maksymalnych limitów dla usługi Azure Virtual Network Manager.

Wzorzec 2: pojedynczy region

Na poniższym diagramie przedstawiono topologię piasty i szprych z jednym regionem, która wysyła ruch między szprychami za pośrednictwem zapory platformy Azure wdrożonej w sieci wirtualnej piasty. Ruch jest przekazywany do scentralizowanego urządzenia w centrum za pośrednictwem tras zdefiniowanych przez użytkownika, które są stosowane do podsieci szprych.

W pewnych okolicznościach korzystne może być oddzielenie wirtualnych urządzeń sieciowych obsługujących ruch szprychy i internetu w celu zapewnienia skalowalności. Tę separację można osiągnąć, wykonując następujące czynności:

• Dostrajanie tabel tras w szprychach w celu wysyłania adresów prywatnych (tych, które mają trasę dla prefiksów RFC 1918) do urządzenia WUS odpowiedzialnego za ruch azure-to-Azure i Azure-to-on-premises (nazywany również ruchem wschodnio-zachodnim).
• Dostrajanie ruchu internetowego (z trasą 0.0.0.0/0) do drugiego urządzenia WUS. To urządzenie WUS jest odpowiedzialne za ruch typu azure-internet (nazywany również ruchem północno-południowym).

Na poniższym diagramie przedstawiono tę konfigurację:

Wzorzec 2: Wiele regionów

Tę samą konfigurację można rozszerzyć na wiele regionów. Na przykład w projekcie piasty i szprych, który korzysta z usługi Azure Firewall, należy zastosować dodatkowe tabele tras do podsieci usługi Azure Firewall w każdym centrum szprych w regionie zdalnym. Ta konfiguracja gwarantuje, że ruch między regionami może być przekazywany między zaporami platformy Azure w każdej sieci wirtualnej koncentratora. Ruch między sieciami wirtualnymi będące szprychami przechodzi przez obie zapory platformy Azure. Aby uzyskać więcej informacji, zobacz Azure Firewall, aby kierować topologię z wieloma piastami i szprychami:

Odmiana projektu z oddzielnymi zaporami platformy Azure lub wirtualnymi urządzeniami sieciowymi dla ruchu północno-południowego i wschodniego-zachodniego jest również możliwa w topologii piasty i szprych w wielu regionach:

Usługa Virtual WAN tworzy podobną topologię i przejmuje złożoność routingu. Robi to zarówno w centrach (którymi zarządza firma Microsoft), jak i w szprychach (gdzie można wstrzykiwać trasy i nie trzeba ich ręcznie definiować w tabelach tras). Dlatego administrator sieci musi połączyć sieci wirtualne będące szprychami tylko z koncentratorem usługi Virtual WAN i nie musi martwić się o przekazywanie ruchu między regionami.

Wzorce hybrydowe

Wiele sytuacji wymaga podejścia hybrydowego, które łączy dwa opisane wcześniej wzorce. W tym podejściu ruch między niektórymi szprychami musi przechodzić przez połączenia bezpośrednie, ale pozostałe szprychy komunikują się za pośrednictwem centralnego urządzenia sieciowego. Na przykład w środowisku usługi Virtual WAN można bezpośrednio połączyć dwie konkretne szprychy, które mają wysoką przepustowość i wymagania dotyczące małych opóźnień. Inny scenariusz obejmuje sieci wirtualne będące szprychami, które są częścią jednego środowiska. Na przykład możesz zezwolić sieci wirtualnej rozwoju szprychy na łączenie się bezpośrednio z inną siecią wirtualną Development, ale wymuszaj komunikację obciążeń deweloperskich i produkcyjnych za pośrednictwem urządzenia centralnego.

Innym typowym wzorcem jest łączenie szprych w jednym regionie za pośrednictwem bezpośrednich wirtualnych sieci równorzędnych lub połączonych grup usługi Azure Virtual Network Manager, ale zezwalanie na ruch między regionalny do krzyżowych urządzeń WUS. Główną motywacją dla tego modelu jest zwykle zmniejszenie liczby komunikacji równorzędnej sieci wirtualnych w architekturze. Jednak w porównaniu z pierwszym modelem (bezpośrednia łączność między szprychami), jedną wadą wprowadzoną w tym modelu jest więcej nadziei na komunikację równorzędną sieci wirtualnych dla ruchu między regionami. Te przeskoki zwiększają koszty ze względu na wiele komunikacji równorzędnych sieci wirtualnych, które są przekraczane. Kolejną wadą jest dodatkowe obciążenie urządzeń WUS koncentratora do przodu całego ruchu między regionami.

Te same projekty mają zastosowanie do usługi Virtual WAN. Należy jednak pamiętać, że bezpośrednia łączność między sieciami wirtualnymi szprych musi być skonfigurowana ręcznie między sieciami wirtualnymi, a nie za pośrednictwem zasobu usługi Virtual WAN. Usługa Azure Virtual Network Manager nie obsługuje obecnie architektur opartych na usłudze Virtual WAN. Na przykład:

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• Jay Li | Starszy menedżer produktu
• Jose Moreno | Główny inżynier klienta
• Alejandra Vilas | Starszy inżynier ds. infrastruktury platformy Azure

Inni współautorzy:

• Mick Alberts | Składnik zapisywania technicznego
• Mohamed Hassan | Główny menedżer pm
• Andrea Michael | Menedżer programu
• Yasukuni Morishima | Inżynier klienta II
• Jithin PP| Inżynier klienta

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Cloud Adoption Framework: topologia sieci strefy docelowej i łączność
• Komunikacja równorzędna sieci wirtualnych
• Menedżer sieci wirtualnej platformy Azure
• Wirtualna sieć WAN
• Azure Firewall
• Zabezpieczanie łączności sieciowej na platformie Azure
• Wprowadzenie do sieci wirtualnych platformy Azure

Powiązane zasoby

• Topologia sieci piasty i szprych na platformie Azure
• Topologia sieci piasty i szprych za pomocą usługi Azure Virtual WAN
• Tradycyjna topologia sieci platformy Azure