Zagadnienia dotyczące projektowania sieci usługi Azure VMware Solution

Rozwiązanie Azure VMware Solution oferuje prywatne środowisko chmury VMware, do którego użytkownicy i aplikacje mogą uzyskiwać dostęp z lokalnych i opartych na platformie Azure środowisk lub zasobów. Usługi sieciowe, takie jak Azure ExpressRoute i połączenia wirtualnej sieci prywatnej (VPN) zapewniają łączność.

Przed skonfigurowaniem środowiska usługi Azure VMware Solution należy zapoznać się z kilkoma zagadnieniami dotyczącymi sieci. Ten artykuł zawiera rozwiązania dla przypadków użycia, które mogą wystąpić podczas konfigurowania sieci przy użyciu rozwiązania Azure VMware Solution.

Zgodność rozwiązania Azure VMware z prepend ścieżką AS

Usługa Azure VMware Solution ma uwagi dotyczące używania prepend ścieżki AS dla nadmiarowych konfiguracji usługi ExpressRoute. Jeśli korzystasz z co najmniej dwóch ścieżek usługi ExpressRoute między środowiskiem lokalnym i platformą Azure, zapoznaj się z poniższymi wskazówkami dotyczącymi wpływu na ruch z usługi Azure VMware Solution do lokalizacji lokalnej za pośrednictwem usługi ExpressRoute GlobalReach.

Ze względu na routing asymetryczny problemy z łącznością mogą wystąpić, gdy usługa Azure VMware Solution nie obserwuje prepend ścieżki as-path i dlatego używa routingu wielościeżkowego (ECMP) równego kosztu w celu wysyłania ruchu do środowiska za pośrednictwem obu obwodów usługi ExpressRoute. To zachowanie może powodować problemy z stanowymi urządzeniami inspekcji zapory umieszczonymi za istniejącymi obwodami usługi ExpressRoute.

Wymagania wstępne

W przypadku prepend ścieżki AS należy wziąć pod uwagę następujące wymagania wstępne:

  • Kluczowym punktem jest to, że należy wstępnie utworzyć publiczne numery ASN, aby wpłynąć na sposób, w jaki usługa Azure VMware Solution kieruje ruch z powrotem do środowiska lokalnego. Jeśli wstępnie utworzono usługę Private ASN, rozwiązanie Azure VMware Solution zignoruje prepend, a wcześniej wymienione zachowanie ECMP zostanie wykonane. Nawet jeśli używasz lokalnej sieci ASN prywatnego protokołu BGP, nadal można skonfigurować urządzenia lokalne do korzystania z publicznej nazwy ASN podczas dołączania tras wychodzących, aby zapewnić zgodność z usługą Azure VMware Solution.
  • Zaprojektuj ścieżkę ruchu dla prywatnych numerów ASN po publicznym numerze ASN, który ma zostać uhonorowany przez rozwiązanie Azure VMware Solution. Obwód usługi ExpressRoute rozwiązania Azure VMware Solution nie usuwa żadnych prywatnych numerów ASN, które istnieją w ścieżce po przetworzeniu publicznej nazwy ASN.
  • Oba obwody są połączone z rozwiązaniem Azure VMware Solution za pośrednictwem usługi Azure ExpressRoute Global Reach.
  • Te same blokady są anonsowane z co najmniej dwóch obwodów.
  • Chcesz użyć prepend ścieżki AS, aby wymusić użycie rozwiązania Azure VMware, aby preferować jeden obwód na drugim.
  • Użyj 2-bajtowych lub 4-bajtowych publicznych numerów ASN.

Zarządzanie maszynami wirtualnymi i trasami domyślnymi ze środowiska lokalnego

Ważne

Maszyny wirtualne do zarządzania usługą Azure VMware Solution nie będą uwzględniać trasy domyślnej ze środowiska lokalnego dla RFC1918 miejsc docelowych.

Jeśli kierujesz z powrotem do sieci lokalnych przy użyciu tylko trasy domyślnej anonsowanej w kierunku platformy Azure, ruch z maszyn wirtualnych vCenter Server i NSX Manager używanych do miejsc docelowych lokalnych z prywatnymi adresami IP nie będzie podążał tą trasą.

Aby uzyskać dostęp do programu vCenter Server i menedżera NSX ze środowiska lokalnego, podaj określone trasy, aby umożliwić ruchowi powrót do tych sieci. Na przykład anonsuj podsumowania RFC1918 (10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16).

Domyślna trasa do rozwiązania Azure VMware Solution na potrzeby inspekcji ruchu internetowego

Niektóre wdrożenia wymagają inspekcji całego ruchu wychodzącego z rozwiązania Azure VMware Solution do Internetu. Chociaż istnieje możliwość utworzenia wirtualnych urządzeń sieciowych (WUS) w rozwiązaniu Azure VMware Solution, istnieją przypadki użycia, w których te urządzenia już istnieją na platformie Azure i można je zastosować do inspekcji ruchu internetowego z usługi Azure VMware Solution. W takim przypadku można wstrzyknąć trasę domyślną z urządzenia WUS na platformie Azure, aby przyciągnąć ruch z usługi Azure VMware Solution i sprawdzić ruch przed wyjściem do publicznego Internetu.

Na poniższym diagramie opisano podstawową topologię piasty i szprych połączoną z chmurą rozwiązania Azure VMware Solution oraz z siecią lokalną za pośrednictwem usługi ExpressRoute. Na diagramie pokazano, jak urządzenie WUS na platformie Azure pochodzi z trasy domyślnej (0.0.0.0/0). Usługa Azure Route Server propaguje trasę do usługi Azure VMware Solution za pośrednictwem usługi ExpressRoute.

Diagram rozwiązania Azure VMware Solution z usługą Route Server i trasą domyślną.

Ważne

Domyślna trasa anonsowana przez urządzenie WUS zostanie rozpropagowana do sieci lokalnej. Aby upewnić się, że ruch z usługi Azure VMware Solution jest przesyłany przez urządzenie WUS, należy dodać trasy zdefiniowane przez użytkownika.

Komunikacja między usługą Azure VMware Solution i siecią lokalną zwykle odbywa się za pośrednictwem usługi ExpressRoute Global Reach, zgodnie z opisem w temacie Peer on-premises environments to Azure VMware Solution (Komunikacja równorzędna między środowiskiem lokalnym a rozwiązaniem Azure VMware Solution).

Połączenie ivity między rozwiązaniem Azure VMware Solution i siecią lokalną

Istnieją dwa główne scenariusze dotyczące łączności między usługą Azure VMware Solution i siecią lokalną za pośrednictwem urządzenia WUS innej firmy:

  • Organizacje muszą wysyłać ruch między usługą Azure VMware Solution i siecią lokalną za pośrednictwem urządzenia WUS (zazwyczaj zapory).
  • Usługa ExpressRoute Global Reach nie jest dostępna w określonym regionie w celu połączenia obwodów usługi ExpressRoute rozwiązania Azure VMware Solution i sieci lokalnej.

Istnieją dwie topologie, które można zastosować, aby spełnić wszystkie wymagania dla tych scenariuszy: sieć wirtualna supersieci i sieci wirtualnej szprychy tranzytowej.

Ważne

Preferowaną opcją połączenia z rozwiązaniem Azure VMware Solution i środowiskami lokalnymi jest bezpośrednie połączenie ExpressRoute Global Reach. Wzorce opisane w tym artykule dodają złożoność środowiska.

Topologia projektowania supersieci

Jeśli oba obwody usługi ExpressRoute (do rozwiązania Azure VMware Solution i lokalnego) zostaną zakończone w tej samej bramie usługi ExpressRoute, możesz założyć, że brama będzie kierować pakiety między nimi. Jednak brama usługi ExpressRoute nie jest w tym celu zaprojektowana. Musisz przypiąć ruch do urządzenia WUS, który może kierować ruch.

Istnieją dwa wymagania dotyczące odpinania ruchu sieciowego do urządzenia WUS:

  • Urządzenie WUS powinno anonsować supersieć dla rozwiązania Azure VMware Solution i lokalnych prefiksów.

    Możesz użyć supersieci obejmującej zarówno rozwiązanie Azure VMware Solution, jak i prefiksy lokalne. Możesz też użyć pojedynczych prefiksów dla rozwiązania Azure VMware Solution i lokalnego (zawsze mniej specyficzne niż rzeczywiste prefiksy anonsowane za pośrednictwem usługi ExpressRoute). Należy pamiętać, że wszystkie prefiksy supersieci anonsowane do usługi Route Server są propagowane zarówno do rozwiązania Azure VMware Solution, jak i lokalnego.

  • Trasy zdefiniowane przez użytkownika w podsieci bramy, które dokładnie odpowiadają prefiksom anonsowanym z usługi Azure VMware Solution i lokalnie, powodują ruch odpinania włosów z podsieci bramy do urządzenia WUS.

Ta topologia powoduje duże obciążenie związane z zarządzaniem dużymi sieciami, które zmieniają się w czasie. Weź pod uwagę następujące ograniczenia:

  • Za każdym razem, gdy segment obciążenia zostanie utworzony w usłudze Azure VMware Solution, może być konieczne dodanie tras zdefiniowanych przez użytkownika, aby upewnić się, że ruch z usługi Azure VMware Solution jest przesyłany przez urządzenie WUS.
  • Jeśli środowisko lokalne ma dużą liczbę tras, które się zmieniają, konieczne może być zaktualizowanie konfiguracji protokołu BGP (Border Gateway Protocol) i trasy zdefiniowanej przez użytkownika w supersieci.
  • Ponieważ jedna brama usługi ExpressRoute przetwarza ruch sieciowy w obu kierunkach, wydajność może być ograniczona.
  • Istnieje limit 400 tras zdefiniowanych przez użytkownika dla sieci wirtualnej platformy Azure.

Na poniższym diagramie przedstawiono sposób, w jaki urządzenie WUS musi anonsować prefiksy, które są bardziej ogólne (mniej specyficzne) i które obejmują sieci ze środowiska lokalnego i rozwiązania Azure VMware Solution. Zachowaj ostrożność przy użyciu tego podejścia. Urządzenie WUS może potencjalnie przyciągnąć ruch, którego nie powinno, ponieważ reklamuje szersze zakresy (na przykład całą 10.0.0.0/8 sieć).

Diagram przedstawiający komunikację lokalną rozwiązania Azure VMware Solution z usługą Route Server w jednym regionie.

Topologia sieci wirtualnej będącej szprychą tranzytowa

Uwaga

Jeśli prefiksy reklamowe, które są mniej specyficzne, nie są możliwe z powodu wcześniej opisanych limitów, możesz zaimplementować alternatywny projekt, który używa dwóch oddzielnych sieci wirtualnych.

W tej topologii zamiast propagować trasy, które są mniej specyficzne dla przyciągania ruchu do bramy usługi ExpressRoute, dwa różne urządzenia WUS w oddzielnych sieciach wirtualnych mogą wymieniać trasy między sobą. Sieci wirtualne mogą propagować te trasy do odpowiednich obwodów usługi ExpressRoute za pośrednictwem protokołu BGP i usługi Azure Route Server. Każde urządzenie WUS ma pełną kontrolę nad tym, które prefiksy są propagowane do każdego obwodu usługi ExpressRoute.

Na poniższym diagramie pokazano, jak pojedyncza 0.0.0.0/0 trasa jest anonsowana do rozwiązania Azure VMware Solution. Pokazuje również, jak poszczególne prefiksy rozwiązania VMware Solution są propagowane do sieci lokalnej.

Diagram przedstawiający komunikację lokalną rozwiązania Azure VMware Solution z usługą Route Server w dwóch regionach.

Ważne

Protokół hermetyzacji, taki jak VXLAN lub IPsec, jest wymagany między urządzeniami WUS. Wymagana jest hermetyzacja, ponieważ karta sieciowa urządzenia WUS (NIC) będzie uczyć się tras z usługi Azure Route Server za pomocą urządzenia WUS jako następnego przeskoku i utworzyć pętlę routingu.

Alternatywą jest użycie nakładki. Stosowanie pomocniczych kart sieciowych w urządzeniu WUS, które nie uczą się tras z usługi Azure Route Server. Następnie skonfiguruj trasy zdefiniowane przez użytkownika, aby platforma Azure mogła kierować ruch do środowiska zdalnego za pośrednictwem tych kart sieciowych. Więcej szczegółów można znaleźć w temacie Topologia sieci w skali przedsiębiorstwa i łączność dla usługi Azure VMware Solution.

Ta topologia wymaga złożonej konfiguracji początkowej. Topologia działa zgodnie z oczekiwaniami z minimalnym obciążeniem zarządzania. Złożoność konfiguracji obejmuje następujące elementy:

  • Istnieje dodatkowy koszt dodawania kolejnej tranzytowej sieci wirtualnej, która obejmuje usługę Azure Route Server, bramę usługi ExpressRoute i inne urządzenie WUS. Urządzenia WUS mogą również wymagać użycia dużych rozmiarów maszyn wirtualnych w celu spełnienia wymagań dotyczących przepływności.
  • Tunelowanie protokołu IPsec lub VXLAN jest wymagane między dwoma urządzeniami WUS, co oznacza, że urządzenia WUS znajdują się również w ścieżce danych. W zależności od typu używanego urządzenia WUS może to spowodować niestandardową i złożoną konfigurację tych urządzeń WUS.

Następne kroki

Po zapoznaniu się z zagadnieniami dotyczącymi projektowania sieci dla rozwiązania Azure VMware Solution rozważ zapoznanie się z następującymi artykułami: