Topologia sieci typu hub-spoke w Azure

Ta architektura referencyjna szczegółowo opisuje topologię typu hub-spoke w Azure. Sieć wirtualna hub działa jako centralny punkt łączności z wieloma sieciami wirtualnymi spoke. Koncentrator może być również używany jako punkt łączności z sieciami lokalnymi. Sieci wirtualne szprychowe współpracują z koncentratorem i mogą być używane do izolowania obciążeń roboczych.

Korzyści z używania konfiguracji szprychowej obejmują oszczędność kosztów, pokonywanie limitów subskrypcji i izolowanie obciążeń roboczych.

Wdrożenie referencyjne

To wdrożenie obejmuje jedną sieć wirtualną szprychową i dwie szprychowe. Wdrożone są również zapora sieciowa Azure i host Azure Bastion. Opcjonalnie obraz stanowiska może zawierać maszyny wirtualne w pierwszej sieci szprychowej i bramę VPN.

az group create --name hub-spoke --location eastus

az deployment group create --resource-group hub-spoke \ --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

New-AzResourceGroup -Name hub-spoke -Location eastus

New-AzResourceGroupDeployment -ResourceGroupName hub-spoke ` -TemplateUri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

Szczegółowe informacje i dodatkowe opcje wdrażania można znaleźć w szablonach ARM używanych do wdrażania tego rozwiązania.

Przypadki użycia

Typowe zastosowania tej architektury obejmują:

• Obciążenia robocze wdrażane w różnych środowiskach, takich jak rozwój, testowanie i produkcja, które wymagają usług współdzielonych, takich jak DNS, IDS, NTP lub AD DS. Usługi współdzielone są umieszczone w sieci wirtualnej hub, podczas gdy każde środowisko jest rozmieszczone na szprychach w celu utrzymania izolacji.
• Obciążenia robocze, które nie wymagają łączności między sobą, ale wymagają dostępu do usług współdzielonych.
• Przedsiębiorstwa, które wymagają centralnej kontroli nad aspektami bezpieczeństwa, takimi jak zapora sieciowa w koncentratorze jako DMZ, oraz oddzielnego zarządzania obciążeniami roboczymi w każdym z ramion.

Architektura

Architektura składa się z następujących komponentów.

Sieć wirtualna koncentratora: Sieć wirtualna hub stanowi centralny punkt łączności z siecią lokalną oraz miejsce hostowania usług, które mogą być konsumowane przez różne obciążenia robocze hostowane w sieciach wirtualnych spoke.

Sieci wirtualne spoke: Sieci wirtualne typu spoke są używane do izolowania obciążeń roboczych w ich własnych sieciach wirtualnych, zarządzanych oddzielnie od innych sieci typu spoke. Każde obciążenie może obejmować wiele warstw, z wieloma podsieciami połączonymi za pomocą load balancerów Azure.

Sieć wirtualna peering: Dwie sieci wirtualne mogą być połączone za pomocą połączenia peeringowego. Połączenia peeringowe są nieprzechodnimi połączeniami o niskiej latencji między sieciami wirtualnymi. Po uzyskaniu połączenia peeringowego sieci wirtualne wymieniają się ruchem za pomocą sieci szkieletowej Azure bez potrzeby stosowania routera.

Bastion Host: Azure Bastion pozwala bezpiecznie połączyć się z maszyną wirtualną za pomocą przeglądarki i portalu Azure. Host Azure Bastion jest rozmieszczony wewnątrz sieci wirtualnej Azure i może uzyskać dostęp do maszyn wirtualnych w sieci VNet lub maszyn wirtualnych w sieci VNets.

Azure Firewall: Azure Firewall to zarządzana zapora sieciowa jako usługa. Instancja Firewall jest umieszczona w swojej własnej podsieci.

Brama sieci wirtualnej VPN lub brama ExpressRoute. Brama sieci wirtualnej umożliwia połączenie sieci wirtualnej z urządzeniem VPN lub układem ExpressRoute używanym do łączenia się z siecią lokalną. Aby uzyskać więcej informacji, zobacz Podłącz sieć lokalną do sieci wirtualnej Microsoft Azure.

Urządzenie VPN. Urządzenie lub usługa, która zapewnia zewnętrzną łączność z siecią lokalną. Urządzenie VPN może być urządzeniem sprzętowym lub rozwiązaniem programowym, takim jak usługa Routing and Remote Access Service (RRAS) w systemie Windows Server 2012. Aby uzyskać więcej informacji, zobacz O urządzeniach VPN dla połączeń Site-to-Site VPN Gateway.

Zalecenia

Następujące zalecenia dotyczą większości scenariuszy. Postępuj zgodnie z tymi zaleceniami, chyba że masz konkretne wymagania, które je zastępują.

Grupy zasobów

Przykładowe rozwiązanie zawarte w tym dokumencie wykorzystuje pojedynczą grupę zasobów Azure. W praktyce węzeł i każda szprycha mogą być wdrożone w różnych grupach zasobów, a nawet w różnych subskrypcjach. W przypadku łączenia sieci wirtualnych w różne subskrypcje, obie subskrypcje mogą być powiązane z tym samym lub różnym dzierżawcą usługi Azure Active Directory. Pozwala to na zdecentralizowane zarządzanie każdym obciążeniem roboczym przy jednoczesnym współdzieleniu usług utrzymywanych w hubie.

Sieć wirtualna i GatewaySubnet

Utwórz podsieć o nazwie GatewaySubnet, z zakresem adresów /27. Brama sieci wirtualnej wymaga tej podsieci. Przydzielenie 32 adresów do tej podsieci pomoże zapobiec osiągnięciu ograniczeń rozmiaru bramy w przyszłości.

Więcej informacji na temat konfigurowania bramy można znaleźć w następujących architekturach referencyjnych, w zależności od typu połączenia:

• Sieć hybrydowa przy użyciu ExpressRoute
• Sieć hybrydowa przy użyciu bramy VPN

W celu uzyskania większej dostępności można użyć ExpressRoute plus VPN do przełączania awaryjnego. Zobacz Podłącz sieć lokalną do Azure za pomocą ExpressRoute z funkcją VPN failover.

Topologia hub-spoke może być również używana bez bramy, jeśli nie jest potrzebna łączność z siecią lokalną.

Virtual network peering

Virtual network peering to nieprzechodnia relacja między dwiema sieciami wirtualnymi. Jeśli potrzebujesz, aby szprychy łączyły się ze sobą, rozważ dodanie oddzielnego połączenia peeringowego między tymi szprychami.

Załóżmy jednak, że masz kilka szprych, które muszą się ze sobą łączyć. W takim przypadku bardzo szybko zabraknie Ci możliwych połączeń peeringowych ze względu na ograniczenie liczby połączeń peeringowych sieci wirtualnej na sieć wirtualną. (Aby uzyskać więcej informacji, zobacz Limity sieciowe. W tym scenariuszu należy rozważyć użycie tras zdefiniowanych przez użytkownika (UDR), aby wymusić wysyłanie ruchu przeznaczonego do szprychy do Azure Firewall lub sieciowego urządzenia wirtualnego działającego jako router w węźle. Dzięki temu szprychy będą mogły łączyć się ze sobą.

Można również skonfigurować szprychy tak, aby używały bramy koncentratora do komunikacji z sieciami zdalnymi. Aby ruch bramowy mógł przepływać z węzła do koncentratora i łączyć się z sieciami zdalnymi, należy:

• Skonfigurować połączenie peeringowe w koncentratorze w celu umożliwienia tranzytu bramowego.
• Skonfigurować połączenie peeringowe w każdym z węzłów szprychowych w celu korzystania z bram zdalnych.
• Skonfigurować wszystkie połączenia peeringowe w celu umożliwienia przekazywania ruchu.

Dodatkowe informacje na temat tworzenia sieci wirtualnej peering, zobacz Tworzenie sieci VNet peerings.

Łączność między szprychami

Jeśli wymagana jest łączność między szprychami, należy rozważyć wdrożenie zapory Azure lub innego sieciowego urządzenia wirtualnego i utworzyć trasy w celu przekazania ruchu z szprychy do zapory / sieciowego urządzenia wirtualnego, które następnie może kierować ruch do drugiej szprychy. W tym scenariuszu należy skonfigurować połączenia peeringowe, aby zezwolić na przekazywanie ruchu.

Można również użyć bramy VPN do kierowania ruchu między szprychami, choć będzie to miało wpływ na opóźnienia i przepustowość. Aby uzyskać szczegóły konfiguracji, zobacz Konfiguracja tranzytu bramy VPN dla sieci wirtualnej peering.

Zastanów się, jakie usługi są współdzielone w koncentratorze, aby zapewnić skalowanie koncentratora dla większej liczby szprych. Na przykład, jeśli koncentrator udostępnia usługi zapory sieciowej, podczas dodawania wielu węzłów należy wziąć pod uwagę ograniczenia przepustowości rozwiązania zapory sieciowej. Niektóre z tych współdzielonych usług można przenieść na drugi poziom węzłów.

Uwagi operacyjne

Podczas wdrażania i zarządzania sieciami węzłów i szprych należy wziąć pod uwagę następujące kwestie.

Monitorowanie sieci

Użyj narzędzia Azure Network Watcher do monitorowania i rozwiązywania problemów z komponentami sieciowymi, narzędzia takie jak Traffic Analytics pokażą systemy w sieciach wirtualnych, które generują największy ruch, dzięki czemu można wizualnie zidentyfikować wąskie gardła, zanim przerodzą się w problemy. Network Performance Manager jest właściwym narzędziem do monitorowania informacji o obwodach Microsoft ExpressRoute. Diagnostyka VPN to kolejne narzędzie, które może pomóc w rozwiązywaniu problemów z połączeniami VPN typu site-to-site łączącymi aplikacje z użytkownikami w siedzibie firmy.

Więcej informacji można znaleźć w dokumencie Azure Network Watcher w dokumencie Azure Well-Architected Framework.

Uwagi dotyczące kosztów

Podczas wdrażania i zarządzania sieciami typu hub i spoke należy rozważyć następujące elementy związane z kosztami.

Azure Firewall

W tej architekturze zapora Azure Firewall jest wdrażana w sieci hub. W przypadku użycia jako rozwiązania współdzielonego i wykorzystywanego przez wiele obciążeń, zapora sieciowa Azure Firewall może zaoszczędzić do 30-50% w porównaniu z innymi sieciowymi urządzeniami wirtualnymi. Więcej informacji można znaleźć w części Azure Firewall vs network virtual appliance.

Virtual network peering

Możesz użyć wirtualnej sieci peering do kierowania ruchu między sieciami wirtualnymi przy użyciu prywatnych adresów IP. Oto kilka punktów:

• Ruch przychodzący i wychodzący jest obciążany na obu końcach sieci peeringowych.
• Różne strefy mają różne stawki transferu.

Na przykład, transfer danych z sieci wirtualnej w strefie 1 do innej sieci wirtualnej w strefie 2, będzie obciążony stawką transferu wychodzącego dla strefy 1 i stawką przychodzącą dla strefy 2. Aby uzyskać więcej informacji, zobacz Cenniki sieci wirtualnych.