Udostępnij za pośrednictwem


Zagadnienia dotyczące sieci dla wdrożeń z dwoma regionami rozwiązania Azure VMware Solution

W tym artykule opisano sposób konfigurowania łączności sieciowej, gdy chmury prywatne usługi Azure VMware Solution są wdrażane w dwóch regionach świadczenia usługi Azure na potrzeby odporności na awarie. Jeśli wystąpią częściowe lub kompletne awarie regionalne, topologia sieci w tym artykule umożliwia zachowanie łączności między składnikami (chmurami prywatnymi, zasobami natywnymi platformy Azure i lokacjami lokalnymi) w celu zachowania łączności ze sobą i z Internetem.

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 katastrofy dla usługi Azure ExpressRoute (dwa obwody w dwóch różnych lokalizacjach peeringowych, z każdym obwodem połączonym z sieciami wirtualnymi koncentratora w obu regionach). Wskazówki przedstawione w poniższych sekcjach pozostają takie same w przypadku skonfigurowania rezerwowego połączenia VPN .
  • Chmura prywatna rozwiązania Azure VMware Solution została wdrożona w każdym regionie.

Diagram rysunku 1, który przedstawia scenariusz z dwoma regionami opisanymi w tym artykule.

Rysunek 1. Scenariusz z dwoma regionami pokazujący, jak globalne peering sieci wirtualnych łączy dwie sieci wirtualne w różnych regionach

Notatka

W scenariuszu referencyjnym na rysunku 1, dwie regionalne sieci wirtualne hubów są połączone za pomocą globalnego równoległego połączenia 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ę. Peering sieci wirtualnej minimalizuje opóźnienia i maksymalizuje przepływność, ponieważ eliminuje konieczność przekierowywania ruchu przez routery brzegowe meet-me usługi ExpressRoute.

Wzorce komunikacji w dwóch regionach

W następnych sekcjach opisano konfigurację sieci usługi Azure VMware Solution, która jest niezbędna do włączenia w scenariuszu referencyjnym z dwoma regionami następujących wzorców komunikacji:

Łączność regionalna rozwiązania Azure VMware Solution

Jeśli istnieje wiele chmur prywatnych usługi Azure VMware Solution, łączność między nimi warstwy 3 jest często wymagana w przypadku zadań takich jak obsługa replikacji danych.

Rozwiązanie 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ą Azure w swoim regionie za pośrednictwem obwodów usługi ExpressRoute, które są zarządzane przez platformę i kończą się w dedykowanych lokalizacjach meet-me usługi ExpressRoute. W tym artykule te obwody są określane jako obwodów zarządzanych usługi Azure VMware Solution. Obwody zarządzane usługi Azure VMware Solution 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 usługi ExpressRoute Global Reach połączeń między obwodami zarządzanymi usługi Azure VMware Solution, jak pokazano na zielonym wierszu na poniższym diagramie. Aby uzyskać więcej informacji, zobacz Samouczek: Połącz środowiska lokalne z Azure VMware Solution. W tym artykule opisano procedurę łączenia obwodu zarządzanego usługi Azure VMware Solution z obwodem zarządzanym przez klienta. Ta sama procedura dotyczy łączenia dwóch obwodów zarządzanych usługi Azure VMware Solution.

Diagram rysunku 2, który przedstawia chmury prywatne w różnych regionach połączonych za pośrednictwem połączenia Global Reach między zarządzanymi obwodami usługi ExpressRoute.

Rysunek 2. W tym scenariuszu referencyjnym przedstawiono chmury prywatne usługi Azure VMware Solution w różnych regionach. Połączenie Global Reach bezpośrednio łączy chmury między zarządzanymi obwodami usługi ExpressRoute.

Łączność hybrydowa

Zalecaną opcją łączenia chmur prywatnych usługi Azure VMware Solution 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 zarządzanymi obwodami usługi ExpressRoute w usłudze Azure VMware Solution. Połączenia Global Reach nie są przechodnie, dlatego pełna siatka (każdy obwód zarządzany przez usługę Azure VMware Solution połączony z każdym obwodem zarządzanym przez klienta) jest niezbędna do odporności na awarie, jak pokazano na poniższym rysunku 3 (linie pomarańczowe przedstawiają połączenia).

Diagram rysunku 3, który przedstawia połączenia Global Reach łączące obwody usługi ExpressRoute zarządzane przez klienta i obwody usługi ExpressRoute rozwiązania VMware Solution.

Rysunek 3. W tym scenariuszu referencyjnym przedstawiono połączenia Global Reach między obwodami usługi ExpressRoute zarządzanymi przez klienta a obwodami usługi ExpressRoute rozwiązania Azure VMware Solution.

Łączność z siecią wirtualną platformy Azure

Sieć wirtualna platformy Azure można połączyć z chmurami prywatnymi usługi Azure VMware Solution za pośrednictwem połączeń między bramami usługi ExpressRoute i obwodami zarządzanymi rozwiązania Azure VMware Solution. To połączenie jest dokładnie w taki sam sposób, w jaki usługa Azure Virtual Network może być połączona z lokacjami lokalnymi za pośrednictwem obwodów usługi ExpressRoute zarządzanych przez klienta. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Nawiązywanie połączenia z chmurą prywatną ręcznie.

W scenariuszach z dwoma regionami zalecamy kompletną siatkę połączeń ExpressRoute między regionalnymi sieciami centralnymi a chmurami prywatnymi, jak pokazano na rysunku 4 (reprezentowane przez żółte linie).

Diagram rysunku 4, który pokazuje, że zasoby natywne platformy Azure w każdym regionie mają bezpośrednią łączność L3 z chmurami prywatnymi usługi Azure VMware Solution.

Rysunek 4. Ten scenariusz referencyjny przedstawia zasoby natywne platformy Azure w każdym regionie, które mają bezpośrednią łączność L3 z chmurami prywatnymi usługi Azure VMware Solution.

Łączność z Internetem

Podczas wdrażania chmur prywatnych Azure VMware Solution w wielu regionach zalecamy natywne opcje łączności z internetem, takie jak zarządzanie translacją adresów źródłowych sieci (SNAT) lub wykorzystywanie publicznych adresów IP aż do NSX-T. Jedną z opcji można skonfigurować za pośrednictwem witryny 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 5.

Diagram rysunku 5, który przedstawia natywne opcje usługi Azure VMware Solution dotyczące łączności z Internetem w witrynie Azure Portal.

Rysunek 5. Ten zrzut ekranu przedstawia opcje natywne rozwiązania Azure VMware Solution dotyczące łączności z Internetem w witrynie Azure Portal.

pl-PL: Obie opcje wyróżnione na rysunku 5 zapewniają każdej chmurze prywatnej bezpośrednie wyjście do Internetu we własnym regionie. Następujące zagadnienia powinny poinformować decyzję o tym, która natywna opcja łączności z Internetem ma być używana:

  • Zarządzane SNAT powinno być używane w scenariuszach z podstawowymi wymaganiami dotyczącymi połączeń wychodzących (o małej liczbie połączeń wychodzących i bez potrzeby szczegółowej kontroli nad pulą SNAT).
  • Publiczne adresy IP do poziomu NSX-T powinny być preferowane w scenariuszach z dużą liczbą połączeń wychodzących lub gdy wymagana jest szczegółowa kontrola nad adresami NAT. Na przykład, które maszyny wirtualne w rozwiązaniu Azure VMware Solution używają SNAT za określonymi 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 opisana w tym artykule.

Zmiana konfiguracji łączności internetowej chmury prywatnej po początkowym wdrożeniu jest możliwa. Jednak chmura prywatna traci łączność z Internetem, usługą Azure Virtual Network i lokacjami lokalnymi podczas aktualizowania konfiguracji. Jeśli jedna z natywnych opcji łączności z Internetem w poprzednim rysunku 5 jest używana, w scenariuszach z dwoma regionami nie jest wymagana żadna dodatkowa konfiguracja (topologia pozostaje taka sama jak ta pokazana na rysunku 4). Aby uzyskać więcej informacji na temat łączności internetowej dla usługi Azure VMware Solution, zobacz zagadnienia dotyczące projektowania łączności internetowej.

Przerwanie internetu natywnego dla platformy Azure

Jeśli bezpieczna krawędź internetowa została utworzona w usłudze Azure Virtual Network przed wdrożeniem rozwiązania Azure VMware Solution, może być konieczne użycie jej do uzyskiwania dostępu do Internetu dla chmur prywatnych usługi Azure VMware Solution. Korzystanie z bezpiecznej krawędzi internetowej w ten sposób jest niezbędne do scentralizowanego zarządzania zasadami zabezpieczeń sieci, optymalizacją kosztów i nie tylko. Zabezpieczenia krawędziowe internetu w usłudze Azure Virtual Network można zaimplementować za pomocą usługi Azure Firewall lub zapory oraz wirtualnych urządzeń sieciowych innych firm, takich jak serwery proxy, dostępnych w Azure Marketplace.

Ruch związany z Internetem emitowany przez maszyny wirtualne usługi 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 witryny 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.

Diagram rysunku 6, który przedstawia konfigurację rozwiązania Azure VMware Solution w celu włączenia łączności z Internetem za pośrednictwem krawędzi internetowych w usłudze Azure Virtual Network.

Rysunek 6. Ten zrzut ekranu przedstawia konfigurację rozwiązania Azure VMware Solution, którą należy wybrać, aby włączyć łączność z Internetem za pośrednictwem krawędzi internetowych w usłudze Virtual Network.

Urządzenia sieciowe brzegu internetowego mogą tworzyć trasę domyślną, 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 rozwiązania Azure VMware Solution w jednym regionie, zobacz Implementowanie łączności internetowej dla rozwiązania Azure VMware Solution za pomocą wirtualnych urządzeń sieciowych 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 usługi Azure VMware Solution w tym samym regionie. Ta propagacja umożliwia obciążeniom Azure VMware Solution korzystanie z Internetu poprzez lokalne wyjście (w obrębie regionu). Jeśli jednak używasz topologii pokazanej na rysunku 4, każda chmura prywatna usługi Azure VMware Solution otrzyma 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 przerywane reprezentują tę niepożądaną propagację domyślnej trasy między regionami na rysunku 7.

Diagram z Rysunku 7, który pokazuje połączenia między bramami usługi ExpressRoute a obwodami usługi ExpressRoute zarządzanymi przez rozwiązanie VMware, należy usunąć.

Rysunek 7. W tym scenariuszu referencyjnym przedstawiono połączenia między bramami usługi ExpressRoute i obwodami usługi ExpressRoute zarządzanymi przez rozwiązanie Azure VMware Solution, które należy usunąć, aby zapobiec propagacji trasy domyślnej między regionami.

Usunięcie połączeń usługi ExpressRoute rozwiązania Azure VMware Solution między regionami umożliwia wstrzyknięcie w każdą prywatną chmurę trasy domyślnej, która przekazuje połączenia przeznaczone na Internet do krawędzi internetowej platformy Azure w regionie lokalnym.

Należy zauważyć, że jeśli połączenia usługi ExpressRoute obejmujące wiele regionów (czerwone linie kreskowane na rysunku 7) zostaną usunięte, propagacja trasy domyślnej między regionami nadal występuje w ramach usługi Global Reach. 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 protokołu BGP.

Rozpowszechnianie między regionami mniej preferowanej trasy domyślnej za pośrednictwem globalnego zasięgu zapewnia odporność na błędy lokalnej krawędzi internetowej. Jeśli krawędź internetowa regionu przechodzi w tryb offline, przestaje generować trasę domyślną. W takim przypadku mniej preferowana trasa domyślna nauczona z regionu zdalnego jest instalowana w prywatnej chmurze rozwiązania Azure VMware Solution, dzięki czemu ruch wychodzący do Internetu jest kierowany za pośrednictwem punktu wyjścia w regionie zdalnym.

Zalecana topologia wdrożeń dla dwóch regionów z przyłączami do Internetu w sieciach wirtualnych platformy Azure jest przedstawiona na poniższym rysunku 8.

Diagram rysunku 8, który przedstawia zalecaną topologię wdrożeń w dwóch regionach z dostępem wychodzącym z Internetu za pośrednictwem krawędzi internetowych.

Rysunek 8. W tym scenariuszu referencyjnym przedstawiono zalecaną topologię wdrożeń w dwóch regionach, które mają dostęp wychodzący z Internetu za pośrednictwem krawędzi internetowych w usłudze Azure Virtual Network.

W przypadku tworzenia tras domyślnych na platformie Azure należy zachować szczególną ostrożność, aby uniknąć propagacji do lokalnych lokalizacji, chyba że konieczne jest zapewnienie dostępu do Internetu do tych lokalizacji poprzez brzeg sieciowy na platformie Azure. Urządzenia obsługiwane przez klienta, które kończą obwody usługi ExpressRoute zarządzane przez klienta, muszą być skonfigurowane do filtrowania tras domyślnych odebranych z platformy Azure, jak pokazano na rysunku 9. Ta konfiguracja jest niezbędna, aby uniknąć zakłócania dostępu do Internetu w lokacjach lokalnych.

Diagram rysunku 9, który przedstawia serwery BGP kończące zarządzane przez klienta obwody usługi ExpressRoute, filtrujące domyślne trasy NVA Azure.

Rysunek 9: W tym scenariuszu referencyjnym przedstawiono głośniki protokołu Border Gateway Protocol, które przerywają obwody usługi ExpressRoute zarządzane przez klienta i filtrować domyślne trasy urządzeń wirtualnych sieci platformy Azure.

Następne kroki