Panduan Mobility Optimized Networking (MON) HCX

  • Artikel

Catatan

VMware HCX Mobility Optimized Networking secara resmi didukung oleh VMware dan Azure VMware Solution dari HCX versi 4.1.0.

Penting

Sebelum mengaktifkan HCX MON, baca batasan dan konfigurasi yang tidak didukung berikut:

Konfigurasi sumber yang tidak didukung untuk HCX NE

Batasan untuk setiap penyebaran HCX termasuk MON

VMware HCX Mobility Optimized Networking (MON) tidak didukung dengan penggunaan gateway pihak ke-3. Ini hanya dapat digunakan dengan gateway T1 yang terhubung langsung ke gateway T0 tanpa appliance virtual jaringan (NVA). Anda mungkin dapat membuat fungsi konfigurasi ini, tetapi kami tidak mendukungnya.

HCX Mobility Optimized Networking (MON) adalah fitur opsional untuk diaktifkan saat menggunakan HCX Network Extensions (NE). MON menyediakan perutean lalu lintas yang optimal di bawah skenario tertentu untuk mencegah tromboning jaringan antara sumber daya berbasis lokal dan cloud pada jaringan yang diperluas.

Karena MON adalah kemampuan perusahaan dari fitur NE, pastikan Anda mengaktifkan VMware HCX Enterprise melalui portal Azure.

Sepanjang siklus migrasi, MON mengoptimalkan mobilitas aplikasi untuk:

  • Mengoptimalkan komunikasi mesin virtual (VM) ke VM L2 saat menggunakan jaringan yang terentang

  • Mengoptimalkan dan menghindari arus lalu lintas asimetris antara lokal, Azure VMware Solution, dan Azure

Dalam artikel ini, pelajari tentang kasus penggunaan khusus Azure VMware Solution untuk MON.

Mengoptimalkan arus lalu lintas di seluruh segmen standar dan terentang di bagian cloud pribadi

Dalam skenario ini, VM1 dimigrasikan ke cloud menggunakan NE, yang menyediakan VM optimal ke latensi VM. Akibatnya, VM1 membutuhkan latensi rendah ke VM3 pada segmen Azure VMware Solution lokal. Kami memigrasikan gateway VM1 dari lokal ke Azure VMware Solution (cloud) untuk memastikan jalur optimal untuk lalu lintas (garis biru). Jika gateway tetap di lokal (garis merah), efek tromboning dan latensi yang lebih tinggi diamati.

Catatan

Ketika Anda mengaktifkan MON tanpa memigrasikan gateway VM ke sisi cloud, MON tidak memastikan jalur optimal untuk arus lalu lintas. Ini juga tidak memungkinkan evaluasi rute kebijakan.

Diagram showing the optimization for VM to VM L2 communication when using stretched networks.

Mengoptimalkan dan menghindari arus lalu lintas asimetris

Dalam skenario ini, kami berasumsi VM dari lokal dimigrasikan ke Azure VMware Solution dan berpartisipasi dalam Arus lalu lintas L2, dan L3 kembali ke lokal untuk mengakses layanan. Kami juga mengasumsikan beberapa komunikasi VM dari Azure (di jaringan virtual yang terhubung dengan Azure VMware Solution) dapat menjangkau ke cloud privat Azure VMware Solution.

Penting

Poin utama di sini adalah merencanakan dan menghindari arus lalu lintas asimetris dengan hati-hati.

Secara default dan tanpa menggunakan MON, VM di Azure VMware Solution pada jaringan terentang tanpa MON dapat berkomunikasi kembali ke lokal menggunakan jalur pilihan ExpressRoute. Berdasarkan kasus penggunaan pelanggan, seseorang harus mengevaluasi bagaimana VM pada segmen yang direntangkan Azure VMware Solution yang diaktifkan dengan MON harus melintasi kembali ke lokal, baik melalui Ekstensi Jaringan atau gateway T0 melalui ExpressRoute sambil menjaga arus lalu lintas tetap simetris.

Jika memilih jalur NE misalnya, rute kebijakan MON harus secara khusus mengatasi subnet di sisi lokal; jika tidak, rute default 0.0.0.0/0 digunakan. Rute kebijakan dapat ditemukan di bawah segmen NE, dengan memilih tingkat lanjut.

Secara default, semua alamat IP RFC 1918 disertakan dalam definisi rute kebijakan MON.

Screenshot showing the egress traffic flow with default policy-based routes.

Ini menghasilkan semua lalu lintas keluar RFC 1918 terowongan melalui jalur NE dan semua lalu lintas internet dan publik dirutekan ke gateway T0.

Diagram showing the RFC 1918 egress and egress traffic flow.

Rute kebijakan dievaluasi hanya jika gateway VM dimigrasikan ke cloud. Efek dari konfigurasi ini adalah bahwa setiap subnet yang cocok untuk tujuan diterowongkan melalui appliance NE. Jika tidak cocok, mereka akan dirutekan melalui gateway T0.

Catatan

Pertimbangan khusus untuk menggunakan MON di Azure VMware Solution adalah memberikan rute /32 diiklankan melalui BGP kepada rekannya; ini termasuk lokal dan Azure melalui koneksi ExpressRoute. Misalnya, VM in Azure mempelajari jalur ke Azure VMware Solution VM pada segmen yang mengaktifkan Azure VMware Solution MON. Setelah lalu lintas kembali dikirim kembali ke gateway T0 seperti yang diharapkan, jika subnet pengembalian adalah kecocokan RFC 1918, lalu lintas dipaksa melalui NE alih-alih T0. Kemudian keluar melalui ExpressRoute kembali ke Azure di sisi lokal. Hal ini dapat menyebabkan kebingungan untuk firewall stateful di tengah dan perilaku routing asimetris. Ada baiknya juga untuk menentukan bagaimana VM pada segmen NE MON perlu mengakses internet, baik melalui gateway T0 di Azure VMware Solution atau hanya melalui NE kembali ke lokal. Secara umum, semua rute kebijakan default harus dihapus untuk menghindari lalu lintas asimetris. Hanya aktifkan rute kebijakan jika infrastruktur jaringan seperti yang telah dikonfigurasi sewaktu-waktu untuk memperhitungkan dan mencegah lalu lintas asimetris.

Rute kebijakan MON dapat dihapus tanpa ditentukan. Hal ini mengalihkan semua lalu lintas keluar yang dirutekan ke gateway T0.

Screenshot showing the egress traffic flow with no policy-based routes.

Rute kebijakan MON dapat diperbarui dengan rute default (0.0.0.0/0). Hal ini mengalihkan semua lalu lintas keluar yang terowongan melalui jalur NE.

Screenshot showing the egress traffic flow with a 0.0.0.0/0 policy-based route.

Seperti yang diuraikan dalam diagram di atas, pentingnya adalah mencocokkan rute kebijakan ke setiap subnet yang diperlukan. Jika tidak, lalu lintas akan dirutekan melalui T0 dan tidak terowongan melalui NE.

Untuk mempelajari selengkapnya tentang rute kebijakan, lihat Rute Kebijakan Jaringan Yang Dioptimalkan untuk Mobilitas.