Wskazówki dotyczące sieci zoptymalizowanej pod kątem mobilności VMware HCX (MON)

Uwaga

Sieć zoptymalizowana pod kątem mobilności VMware HCX jest oficjalnie obsługiwana przez oprogramowanie VMware i rozwiązanie Azure VMware z rozwiązania HCX w wersji 4.1.0.

Ważne

Przed włączeniem rozwiązania HCX MON zapoznaj się z poniższymi ograniczeniami i nieobsługiwaną konfiguracją:

Nieobsługiwane konfiguracje źródłowe dla rozwiązania HCX NE

Ograniczenia dotyczące dowolnego wdrożenia HCX, w tym mon

Sieć zoptymalizowana pod kątem mobilności VMware HCX (MON) nie jest obsługiwana w przypadku korzystania z bramy innej firmy. Może być używana tylko z bramą T1 bezpośrednio połączoną z bramą T0 bez wirtualnego urządzenia sieciowego (WUS). Możesz utworzyć tę funkcję konfiguracji, ale nie obsługujemy jej.

HCX Mobility Optimized Networking (MON) to opcjonalna funkcja umożliwiająca korzystanie z rozszerzeń sieciowych HCX (NE). Baza danych MON zapewnia optymalny routing ruchu w niektórych scenariuszach, aby zapobiec pumboningowi sieci między zasobami lokalnymi i chmurowymi w sieciach rozszerzonych.

Ponieważ mon jest funkcją NE dla przedsiębiorstw, upewnij się, że włączono rozwiązanie VMware HCX Enterprise za pośrednictwem witryny Azure Portal.

W całym cyklu migracji mon optymalizuje mobilność aplikacji pod kątem:

• Optymalizacja pod kątem komunikacji maszyny wirtualnej z maszyną wirtualną L2 podczas korzystania z sieci rozproszony

• Optymalizowanie i unikanie asymetrycznych przepływów ruchu między środowiskiem lokalnym, rozwiązaniem Azure VMware Solution i platformą Azure

Ten artykuł zawiera informacje na temat przypadków użycia specyficznych dla rozwiązania VMware platformy Azure dla bazy danych MON.

Optymalizowanie przepływów ruchu w standardowych i rozciągniętych segmentach po stronie chmury prywatnej

W tym scenariuszu maszyna WIRTUALNa VM1 jest migrowana do chmury przy użyciu rozwiązania NE, co zapewnia optymalne opóźnienie maszyny wirtualnej. W związku z tym maszyna VM1 wymaga małego opóźnienia do maszyny VM3 w lokalnym segmencie rozwiązania Azure VMware Solution. Migrujemy bramę VM1 ze środowiska lokalnego do rozwiązania Azure VMware Solution (w chmurze), aby zapewnić optymalną ścieżkę ruchu (niebieska linia). Jeśli brama pozostanie lokalna (czerwona linia), zaobserwowano efekt pumboningu i większe opóźnienie.

Uwaga

Po włączeniu mon bez migrowania bramy maszyny wirtualnej po stronie chmury nie zapewnia optymalnej ścieżki przepływu ruchu. Nie zezwala również na ocenę tras zasad.

Optymalizowanie i unikanie przepływów ruchu asymetrycznego

W tym scenariuszu założono, że maszyna wirtualna ze środowiska lokalnego jest migrowana do usługi Azure VMware Solution i uczestniczy w L2, a ruch L3 z powrotem do środowiska lokalnego w celu uzyskania dostępu do usług. Zakładamy również, że komunikacja między maszynami wirtualnymi z platformy Azure (w połączonej sieci wirtualnej azure VMware Solution) może dotrzeć do chmury prywatnej usługi Azure VMware Solution.

Ważne

Głównym punktem jest zaplanowanie i dokładne uniknięcie asymetrycznych przepływów ruchu.

Domyślnie i bez korzystania z bazy danych MON maszyna wirtualna w rozwiązaniu Azure VMware Solution w sieci rozproszonej bez mon może komunikować się z powrotem do środowiska lokalnego przy użyciu preferowanej ścieżki usługi ExpressRoute. W oparciu o przypadki użycia klienta należy ocenić, w jaki sposób maszyna wirtualna w ramach rozproszonego segmentu usługi Azure VMware Solution włączona za pomocą bazy danych MON powinna przechodzić z powrotem do środowiska lokalnego za pośrednictwem rozszerzenia sieciowego lub bramy T0 za pośrednictwem usługi ExpressRoute przy zachowaniu symetryczności przepływów ruchu.

Jeśli na przykład wybrano ścieżkę NE, trasy zasad MON muszą konkretnie adresować podsieć po stronie lokalnej; w przeciwnym razie używana jest trasa domyślna 0.0.0.0/0. Trasy zasad można znaleźć w obszarze segmentu NE, wybierając pozycję Zaawansowane.

Domyślnie wszystkie adresy IP RFC 1918 są zawarte w definicji tras zasad MON.

Dzięki temu cały ruch wychodzący RFC 1918 jest tunelowany przez ścieżkę NE oraz cały ruch internetowy i publiczny kierowany do bramy T0.

Trasy zasad są oceniane tylko wtedy, gdy brama maszyny wirtualnej jest migrowana do chmury. Efektem tej konfiguracji jest to, że wszystkie pasujące podsieci dla miejsca docelowego są tunelowane przez urządzenie NE. Jeśli nie są one zgodne, są one kierowane przez bramę T0.

Uwaga

Szczególną uwagę na używanie bazy danych MON w usłudze Azure VMware Solution należy zwrócić /32 trasy anonsowane za pośrednictwem protokołu BGP do swoich elementów równorzędnych; Obejmuje to lokalne i platformę Azure za pośrednictwem połączenia usługi ExpressRoute. Na przykład maszyna wirtualna na platformie Azure uczy się ścieżki do maszyny wirtualnej rozwiązania Azure VMware Solution w segmencie mon rozwiązania VMware Solution platformy Azure. Po odesłaniu ruchu powrotnego do bramy T0 zgodnie z oczekiwaniami, jeśli zwracana podsieć jest zgodna z RFC 1918, ruch jest wymuszany przez sieć NE zamiast T0. Następnie ruch wychodzący przez usługę ExpressRoute z powrotem na platformę Azure po stronie lokalnej. Może to spowodować zamieszanie w przypadku stanowych zapór w środkowym i asymetrycznym zachowaniu routingu. Dobrym pomysłem jest również określenie, w jaki sposób maszyny wirtualne w segmentach MON NE muszą uzyskiwać dostęp do Internetu za pośrednictwem bramy T0 w rozwiązaniu Azure VMware Solution lub tylko za pośrednictwem sieci wirtualnej z powrotem do środowiska lokalnego. Ogólnie rzecz biorąc, należy usunąć wszystkie domyślne trasy zasad, aby uniknąć ruchu asymetrycznego. Włącz trasy zasad tylko wtedy, gdy infrastruktura sieciowa została skonfigurowana w taki sposób, aby uwzględnić i zapobiec ruchowi asymetrycznemu.

Trasy zasad MON można usunąć bez zdefiniowanych. Powoduje to kierowanie całego ruchu wychodzącego do bramy T0.

Trasy zasad MON można zaktualizować przy użyciu trasy domyślnej (0.0.0.0/0). Powoduje to, że cały ruch wychodzący jest tunelowany przez ścieżkę NE.

Jak opisano na powyższych diagramach, ważne jest dopasowanie trasy zasad do każdej wymaganej podsieci. W przeciwnym razie ruch jest kierowany przez T0 i nie tunelowany przez sieć NE.

Aby dowiedzieć się więcej na temat tras zasad, zobacz Mobility Optimized Networking Policy Routes (Trasy zasad sieci zoptymalizowanych pod kątem mobilności).