Zagadnienia dotyczące sieci dla wdrożeń Azure VMware Solution dwóch regionów
W tym artykule opisano sposób konfigurowania łączności sieciowej podczas wdrażania chmur prywatnych Azure VMware Solution w dwóch regionach świadczenia usługi Azure na potrzeby odporności na awarie. Jeśli występują częściowe lub kompletne awarie regionalne, topologia sieci w tym artykule umożliwia zachowanie łączności ze sobą i z Internetem składników ocalałych (chmur prywatnych, zasobów natywnych platformy Azure i lokacji lokalnych).
Scenariusz z dwoma regionami
Ten artykuł koncentruje się na typowym scenariuszu z dwoma regionami, pokazanym na poniższym rysunku 1:
- Sieć piasty i szprych platformy Azure istnieje w każdym regionie.
- Wdrożono konfigurację odporną na awarię dla usługi ExpressRoute (dwa obwody w dwóch różnych lokalizacjach komunikacji równorzędnej, z każdym obwodem połączonym z sieciami wirtualnymi koncentratora w obu regionach). Wskazówki podane w poniższych sekcjach pozostają takie same w przypadku skonfigurowania łączności sieci VPN rezerwowej .
- Chmura prywatna Azure VMware Solution została wdrożona w każdym regionie.
Uwaga
W scenariuszu referencyjnym rysunku 1 dwie regionalne sieci wirtualne koncentratora są połączone za pośrednictwem globalnej komunikacji równorzędnej sieci wirtualnych. Chociaż nie jest to absolutnie konieczne, ponieważ ruch między sieciami wirtualnymi platformy Azure w dwóch regionach może być kierowany za pośrednictwem połączeń usługi ExpressRoute, zdecydowanie zalecamy tę konfigurację. Komunikacja równorzędna sieci wirtualnych minimalizuje opóźnienie i maksymalizuje przepływność, ponieważ eliminuje potrzebę przypinania ruchu przez routery brzegowe meet-me usługi ExpressRoute.
Wzorce komunikacji w dwóch regionach
W następnych sekcjach opisano konfigurację sieci Azure VMware Solution, która jest niezbędna do włączenia w scenariuszu referencyjnym z podwójnym regionem następujących wzorców komunikacji:
- Azure VMware Solution Azure VMware Solution (opisane w sekcji Azure VMware Solution łączności między regionami);
- Azure VMware Solution do lokacji lokalnych połączonych za pośrednictwem usługi ExpressRoute (opisanej w sekcji Łączność hybrydowa);
- Azure VMware Solution do usługi Azure Virtual Network (opisano w sekcji Łączność z usługą Azure Virtual Network);
- Azure VMware Solution do Internetu (opisano w sekcji Łączność z Internetem).
Azure VMware Solution łączności między regionami
Jeśli istnieje wiele Azure VMware Solution chmur prywatnych, łączność między nimi w warstwie 3 jest często wymagana dla zadań, takich jak obsługa replikacji danych.
Azure VMware Solution natywnie obsługuje bezpośrednią łączność między dwiema chmurami prywatnymi wdrożonym w różnych regionach świadczenia usługi Azure. Chmury prywatne łączą się z siecią platformy Azure we własnym regionie za pośrednictwem obwodów usługi ExpressRoute, zarządzanych przez platformę i zakończonych w dedykowanych lokalizacjach usługi ExpressRoute meet-me. W tym artykule te obwody są określane jako obwody zarządzane Azure VMware Solution. Azure VMware Solution obwody zarządzane nie powinny być mylone z normalnymi obwodami wdrażanymi przez klientów w celu połączenia lokacji lokalnych z platformą Azure. Normalne obwody wdrażane przez klientów to obwody zarządzane przez klienta (zobacz Rysunek 2).
Bezpośrednia łączność między chmurami prywatnymi jest oparta na połączeniach Global Reach usługi ExpressRoute między obwodami zarządzanymi Azure VMware Solution, jak pokazano na zielonym wierszu na poniższym diagramie. Aby uzyskać więcej informacji, zobacz Samouczek: równorzędne środowiska lokalne do Azure VMware Solution. W tym artykule opisano procedurę łączenia obwodu zarządzanego Azure VMware Solution z obwodem zarządzanym przez klienta. Ta sama procedura dotyczy łączenia dwóch Azure VMware Solution obwodów zarządzanych.
Łączność hybrydowa
Zalecaną opcją łączenia Azure VMware Solution chmur prywatnych z lokacjami lokalnymi jest usługa ExpressRoute Global Reach. Połączenia global reach można ustanowić między obwodami usługi ExpressRoute zarządzanymi przez klienta i Azure VMware Solution zarządzanymi obwodami usługi ExpressRoute. Połączenia global reach nie są przechodnie, dlatego pełna siatka (każdy obwód zarządzany Azure VMware Solution połączony z każdym obwodem zarządzanym przez klienta) jest niezbędny do odporności na awarie, jak pokazano na poniższym rysunku 3 (reprezentowane przez pomarańczowe linie).
Łączność z usługą Azure Virtual Network
Usługę Azure Virtual Network można połączyć z chmurami prywatnymi Azure VMware Solution za pośrednictwem połączeń między bramami usługi ExpressRoute i obwodami zarządzanymi Azure VMware Solution. To połączenie jest dokładnie takie samo, jak usługa Azure Virtual Network może być połączona z lokacjami lokalnymi za pośrednictwem zarządzanych przez klienta obwodów usługi ExpressRoute. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Ręczne nawiązywanie połączenia z chmurą prywatną .
W scenariuszach z dwoma regionami zalecamy pełną siatkę połączeń usługi ExpressRoute między dwoma regionalnymi Virtual Network i chmurami prywatnymi, jak pokazano na rysunku 4 (reprezentowane przez żółte linie).
Łączność z Internetem
Podczas wdrażania Azure VMware Solution chmur prywatnych w wielu regionach zalecamy opcje natywne dla łączności z Internetem (zarządzane tłumaczenie adresów sieciowych (SNAT) lub publiczne adresy IP w dół do NSX-T. W czasie wdrażania można skonfigurować jedną z opcji za pomocą Azure Portal (lub za pośrednictwem programu PowerShell, interfejsu wiersza polecenia lub szablonów ARM/Bicep), jak pokazano na poniższym rysunku 5.
Obie opcje wyróżnione na rysunku 5 zapewniają każdą chmurę prywatną z bezpośrednim podziałem na Internet we własnym regionie. Poniższe zagadnienia powinny poinformować decyzję o tym, która natywna opcja łączności z Internetem ma być używana:
- Zarządzana funkcja SNAT powinna być używana w scenariuszach z podstawowymi i wychodzącymi wymaganiami (małe woluminy połączeń wychodzących i nie wymagają szczegółowej kontroli nad pulą SNAT).
- Publiczne adresy IP w dół do krawędzi NSX-T powinny być preferowane w scenariuszach z dużymi ilościami połączeń wychodzących lub gdy wymagana jest szczegółowa kontrola nad adresami IP translatora adresów sieciowych. Na przykład, które Azure VMware Solution maszyny wirtualne używają SNAT, za którymi adresami IP. Publiczne adresy IP w dół do krawędzi NSX-T obsługują również łączność przychodzącą za pośrednictwem DNAT. Łączność przychodząca z Internetem nie jest omówiona w tym artykule.
Zmiana konfiguracji łączności internetowej chmury prywatnej po początkowym wdrożeniu. Jednak chmura prywatna traci łączność z Internetem, platformą Azure Virtual Network i lokacjami lokalnymi podczas aktualizowania konfiguracji. Jeśli jest używana jedna z natywnych opcji łączności z Internetem w poprzednim rysunku 5, żadna dodatkowa konfiguracja nie jest konieczna w scenariuszach z dwoma regionami (topologia pozostaje taka sama jak ta pokazana na rysunku 4). Aby uzyskać więcej informacji na temat łączności internetowej dla Azure VMware Solution, zobacz Zagadnienia dotyczące projektowania łączności internetowej.
Natywne dla platformy Azure przerwy w Internecie
Jeśli bezpieczna krawędź internetowa została utworzona w usłudze Azure Virtual Network przed wdrożeniem Azure VMware Solution, może być konieczne użycie jej do dostępu do Internetu dla chmur prywatnych Azure VMware Solution. Korzystanie z bezpiecznej przeglądarki internetowej w ten sposób jest niezbędne do scentralizowanego zarządzania zasadami zabezpieczeń sieci, optymalizacją kosztów i nie tylko. Krawędzie zabezpieczeń internetowych w usłudze Azure Virtual Network można zaimplementować przy użyciu zapory Azure Firewall lub zapory innej firmy oraz wirtualnych urządzeń sieciowych proxy (WUS) dostępnych w Azure Marketplace.
Ruch związany z Internetem emitowany przez maszyny wirtualne Azure VMware Solution może być przyciągany do sieci wirtualnej platformy Azure przez utworzenie trasy domyślnej i ogłoszenie go za pośrednictwem protokołu BGP (Border Gateway Protocol) do zarządzanego obwodu usługi ExpressRoute w chmurze prywatnej. Tę opcję łączności z Internetem można skonfigurować za pośrednictwem Azure Portal (lub za pośrednictwem programu PowerShell, interfejsu wiersza polecenia lub szablonów ARM/Bicep) w czasie wdrażania, jak pokazano na poniższym rysunku 6. Aby uzyskać więcej informacji, zobacz Wyłączanie dostępu do Internetu lub włączanie trasy domyślnej.
Wirtualne urządzenia WUS przeglądarki internetowej mogą pochodzić z trasy domyślnej, jeśli obsługują protokół BGP. W przeciwnym razie należy wdrożyć inne urządzenia WUS z obsługą protokołu BGP. Aby uzyskać więcej informacji na temat implementowania łączności wychodzącej z Internetu dla Azure VMware Solution w jednym regionie, zobacz Implementowanie łączności internetowej dla Azure VMware Solution za pomocą urządzeń WUS platformy Azure. W scenariuszu z dwoma regionami opisanymi w tym artykule należy zastosować tę samą konfigurację do obu regionów.
Kluczową kwestią w scenariuszach z dwoma regionami jest to, że trasa domyślna pochodząca z każdego regionu powinna być propagowana za pośrednictwem usługi ExpressRoute tylko do chmury prywatnej Azure VMware Solution w tym samym regionie. Propagacja ta umożliwia Azure VMware Solution obciążenia dostępu do Internetu za pośrednictwem podziału lokalnego (w regionie). Jeśli jednak używasz topologii pokazanej na rysunku 4, każda Azure VMware Solution chmura prywatna otrzymuje również trasę domyślną o równym koszcie z regionu zdalnego za pośrednictwem połączeń usługi ExpressRoute między regionami. Czerwone linie kreskowane reprezentują tę niepożądane trasy domyślne między regionami propagację trasy domyślnej na rysunku 7.
Usunięcie połączeń usługi ExpressRoute między regionami Azure VMware Solution osiąga cel wstrzykiwania w każdej chmurze prywatnej domyślnej trasy do przekazywania połączeń powiązanych z Internetem platformy Azure w regionie lokalnym.
Należy zauważyć, że jeśli połączenia usługi ExpressRoute między regionami (czerwone linie kreskowane na rysunku 7) zostaną usunięte, propagacja między regionami trasy domyślnej nadal występuje w ramach zasięgu globalnego. Jednak trasy propagowane za pośrednictwem globalnego zasięgu mają dłuższą ścieżkę AS niż lokalnie pochodzące i są odrzucane przez proces wyboru trasy BGP.
Propagacja między regionami w ramach globalnego zasięgu mniej preferowanej trasy domyślnej zapewnia odporność na błędy lokalnej krawędzi internetowej. Jeśli krawędź internetowa regionu przejdzie w tryb offline, przestanie pochodzić z trasy domyślnej. W takim przypadku mniej preferowana trasa domyślna wyciągnięta z regionu zdalnego jest instalowana w chmurze prywatnej Azure VMware Solution, dzięki czemu ruch związany z Internetem jest kierowany przez awarię regionu zdalnego.
Zalecana topologia wdrożeń w dwóch regionach z podziałami internetowymi w sieciach wirtualnych platformy Azure jest pokazana na poniższym rysunku 8.
W przypadku tworzenia tras domyślnych na platformie Azure należy podjąć szczególną ostrożność, aby uniknąć propagacji do lokacji lokalnych, chyba że istnieje wymóg zapewnienia dostępu do Internetu do witryn lokalnych za pośrednictwem przeglądarki internetowej na platformie Azure. Urządzenia obsługiwane przez klienta, które przerywają zarządzane przez klienta obwody usługi ExpressRoute, muszą być skonfigurowane do filtrowania domyślnych tras odebranych z platformy Azure, jak pokazano na rysunku 9. Ta konfiguracja jest niezbędna, aby uniknąć zakłócania dostępu do Internetu dla lokacji lokalnych.
Następne kroki
Aby uzyskać więcej informacji na temat funkcji sieciowych Azure VMware Solution, zobacz Azure VMware Solution pojęcia dotyczące sieci i połączeń.
Aby uzyskać więcej informacji na temat łączności z Internetem dla Azure VMware Solution, zobacz Zagadnienia dotyczące projektowania łączności z Internetem.