Artikel ini menjelaskan opsi paling umum untuk menyebarkan sekumpulan Network Virtual Appliances (NVA) untuk ketersediaan tinggi di Azure. NVA biasanya digunakan untuk mengontrol arus lalu lintas antara segmen jaringan yang diklasifikasikan dengan tingkat keamanan yang berbeda, misalnya antara Jaringan Virtual Zona De-Militarized (DMZ) dan Internet publik.
Ada sejumlah pola desain di mana NVA digunakan untuk memeriksa lalu lintas antara zona keamanan yang berbeda, misalnya:
- Untuk memeriksa lalu lintas keluar dari komputer virtual ke Internet dan mencegah penyelundupan data.
- Untuk memeriksa lalu lintas masuk dari Internet ke komputer virtual dan mencegah serangan.
- Untuk memfilter lalu lintas antara komputer virtual di Azure, untuk mencegah pemindahan lateral sistem yang disusupi.
- Untuk memfilter lalu lintas antara sistem lokal dan komputer virtual Azure, jika dianggap milik tingkat keamanan yang berbeda. (Misalnya, jika Azure menghosting DMZ, dan aplikasi internal lokal.)
Ada banyak contoh NVA, seperti firewall jaringan, proksi terbalik Layer-4, titik akhir IPsec VPN, proksi terbalik berbasis web dengan fungsionalitas firewall aplikasi web, proksi Internet untuk membatasi halaman Internet mana yang dapat diakses dari Azure, load balancer Layer-7, dan banyak lainnya. Semuanya dapat disisipkan dalam desain Azure dengan pola yang dijelaskan dalam artikel ini. Bahkan Network Virtual Appliance pihak pertama Azure seperti Azure Firewall dan Azure Application Gateway menggunakan desain yang dijelaskan nanti dalam artikel ini. Memahami opsi ini sangat penting baik dari perspektif desain maupun saat memecahkan masalah jaringan.
Pertanyaan pertama yang harus dijawab adalah mengapa Ketersediaan Tinggi untuk Appliance Virtual Jaringan diperlukan. Alasannya adalah karena perangkat ini mengontrol komunikasi antar segmen jaringan. Jika tidak tersedia, lalu lintas jaringan tidak dapat mengalir, dan aplikasi akan berhenti berfungsi. Pemadaman terjadwal dan tidak terjadwal dapat dan kadang-kadang akan menurunkan instans NVA (seperti komputer virtual lainnya di Azure atau cloud lainnya). Instans diturunkan bahkan jika NVA tersebut dikonfigurasi dengan Disk Terkelola Premium untuk menyediakan SLA instans tunggal di Azure. Oleh karena itu, aplikasi yang sangat tersedia akan membutuhkan setidaknya NVA kedua yang dapat memastikan konektivitas.
Prasyarat: Artikel ini mengasumsikan pemahaman dasar tentang jaringan Azure, Azure Load Balancer, dan Perutean Lalu Lintas Jaringan Virtual (UDR).
Saat memilih opsi terbaik untuk menyebarkan Network Virtual Appliance ke Azure VNet, aspek terpenting yang perlu dipertimbangkan adalah apakah vendor NVA telah memeriksa dan memvalidasi desain spesifik tersebut. Vendor juga harus menyediakan konfigurasi NVA yang diperlukan untuk mengintegrasikan NVA di Azure. Jika vendor NVA menawarkan alternatif yang berbeda sebagai opsi desain yang didukung untuk NVA, faktor-faktor ini dapat memengaruhi keputusan:
- Waktu konvergensi: berapa lama waktu yang dibutuhkan dalam setiap desain untuk mengarahkan lalu lintas menjauh dari instans NVA yang gagal?
- Dukungan topologi: konfigurasi NVA apa yang didukung setiap opsi desain? Kluster NVA aktif/aktif, aktif/siaga, peluasan skala dengan redundansi n+1?
- Simetri lalu lintas: apakah desain tertentu memaksa NVA untuk melakukan Source Network Address Translation (SNAT) pada paket untuk menghindari perutean asimetris? Atau apakah simetri lalu lintas diberlakukan dengan cara lain?
Bagian berikut dalam dokumen akan menjelaskan arsitektur paling umum yang digunakan untuk mengintegrasikan NVA ke dalam jaringan Hub dan Spoke.
Catatan
Artikel ini difokuskan pada desain Hub & Spoke. Virtual WAN tidak tercakup, karena Virtual WAN jauh lebih preskriptif tentang bagaimana NVA disebarkan, tergantung pada apakah NVA tertentu didukung di hub Virtual WAN. Lihat Appliance Virtual Jaringan di hub Virtual WAN untuk informasi selengkapnya.
Gambaran umum arsitektur HA
Arsitektur berikut menjelaskan sumber daya dan konfigurasi yang diperlukan untuk NVA yang sangat tersedia:
| Solusi | Keuntungan | Pertimbangan |
|---|---|---|
| Penyeimbang Beban Azure | Mendukung NVA aktif/aktif, aktif/siaga, dan peluasan skala. Waktu konvergensi yang sangat baik | NVA perlu menyediakan port untuk pemeriksaan kesehatan, terutama untuk penyebaran aktif/siaga. Alur ke/dari Internet memerlukan SNAT untuk simetri |
| Azure Route Server | NVA perlu mendukung BGP. Mendukung NVA aktif/aktif, aktif/siaga, dan peluasan skala. | Simetri lalu lintas memerlukan SNAT |
| Gateway Load Balancer | Simetri lalu lintas dijamin tanpa SNAT. NVA dapat dibagikan di seluruh penyewa. Waktu konvergensi yang sangat baik. Mendukung NVA aktif/aktif, aktif/siaga, dan peluasan skala. | Mendukung alur ke/dari Internet, tidak ada alur Timur-Barat |
| Mengubah PIP/UDR | Tidak ada fitur khusus yang diperlukan oleh NVA. Menjamin lalu lintas simetris | Hanya untuk desain aktif/pasif. Waktu konvergensi tinggi 1-2 menit |
Desain Load Balancer
Desain ini menggunakan dua Azure Load Balancer untuk mengekspos kluster NVA ke jaringan lainnya:
- Load Balancer internal digunakan untuk mengalihkan lalu lintas internal dari Azure dan lokal ke NVA. Penyeimbang beban internal ini dikonfigurasi dengan aturan Port HA, sehingga setiap port TCP/UDP dialihkan ke instans NVA.
- Load Balancer publik mengekspos NVA ke Internet. Karena Port HA adalah untuk lalu lintas masuk, setiap port TCP/UDP individu perlu dibuka dalam aturan penyeimbangan beban khusus.
Diagram berikut menjelaskan urutan hop yang paket dari Internet ke server aplikasi di VNet spoke akan mengikuti:
Unduh file Visio arsitektur ini.
Mekanisme untuk mengirim lalu lintas dari spoke ke Internet publik melalui NVA adalah Rute yang Ditentukan Pengguna untuk 0.0.0.0/0 dengan lompatan berikutnya alamat IP Load Balancer internal.
Untuk lalu lintas antara Azure dan Internet publik, setiap arah arus lalu lintas akan melintasi Azure Load Balancer yang berbeda (paket masuk melalui ALB publik, dan paket keluar melalui ALB internal). Akibatnya, jika simetri lalu lintas diperlukan, Source Network Address Translation (SNAT) perlu dilakukan oleh instans NVA untuk menarik lalu lintas kembali dan menghindari asimetri lalu lintas.
Desain ini juga dapat digunakan untuk memeriksa lalu lintas antara Azure dan jaringan lokal:
Mekanisme untuk mengirim lalu lintas antara spoke melalui NVA sama persis, sehingga tidak ada diagram tambahan yang disediakan. Dalam contoh diagram di atas, karena spoke1 tidak tahu tentang rentang spoke2, 0.0.0.0/0 UDR akan mengirim lalu lintas yang ditujukan ke spoke2 ke Azure Load Balancer internal NVA.
Untuk lalu lintas antara jaringan lokal dan Azure atau antara komputer virtual Azure, simetri lalu lintas dijamin oleh Azure Load Balancer internal: ketika kedua arah arus lalu lintas melintasi Azure Load Balancer yang sama, instans NVA yang sama akan dipilih.
Azure Load Balancer memiliki waktu konvergensi yang sangat baik jika terjadi pemadaman NVA individu. Karena pemeriksaan kesehatan dapat dikirim setiap 5 detik, dan dibutuhkan 3 pemeriksaan yang gagal untuk mendeklarasikan instans backend di luar layanan, biasanya diperlukan waktu 10-15 detik agar Azure Load Balancer dapat menyatukan lalu lintas ke instans NVA yang berbeda.
Penyiapan ini mendukung konfigurasi aktif/aktif dan aktif/siaga. Namun, untuk konfigurasi aktif/siaga, instans NVA perlu menawarkan port TCP/UDP atau titik akhir HTTP yang tidak merespons pemeriksaan kesehatan Load Balancer kecuali instans berada dalam peran aktif.
Menggunakan load balancer L7
Kasus tertentu dari desain ini adalah mengganti Load Balancer publik Azure dengan load balancer Layer-7 seperti Azure Application Gateway (yang dapat dianggap sebagai NVA sendiri). Dalam hal ini, NVA hanya akan memerlukan Load Balancer internal di depannya, karena lalu lintas dari Application Gateway akan bersumber dari dalam VNet, dan asimetri lalu lintas tidak menjadi perhatian.
NVA harus mengambil lalu lintas masuk untuk protokol yang tidak didukung oleh load balancer Layer-7 Anda, ditambah kemungkinan semua lalu lintas keluar. Untuk detail lebih lanjut tentang konfigurasi ini saat menggunakan Azure Firewall sebagai NVA dan Azure Application Gateway sebagai proksi terbalik web Layer-7, lihat Firewall dan Application Gateway untuk jaringan virtual.
Azure Route Server
Azure Route Server adalah layanan yang memungkinkan NVA berinteraksi dengan Azure SDN melalui Border Gateway Protocol (BGP). Tidak hanya NVA yang akan mempelajari awalan IP mana yang ada di Azure VNets, tetapi mereka akan dapat menyuntikkan rute dalam tabel rute efektif komputer virtual di Azure.
Dalam diagram di atas setiap instans NVA di-peering melalui BGP dengan Azure Route Server. Tidak ada tabel rute yang diperlukan dalam subnet spoke, karena Azure Route Server akan memprogram rute yang diiklankan oleh NVA. Jika dua rute atau lebih diprogram di komputer virtual Azure, rute tersebut akan menggunakan Equal Cost MultiPathing (ECMP) untuk memilih salah satu instans NVA untuk setiap arus lalu lintas. Sebagai konsekuensinya, SNAT adalah suatu keharusan dalam desain ini jika simetri lalu lintas adalah persyaratan.
Metode penyisipan ini mendukung aktif/aktif (semua NVA mengiklankan rute yang sama ke Azure Route Server), serta aktif/siaga (satu NVA mengiklankan rute dengan jalur AS yang lebih pendek daripada yang lain). Azure Route Server mendukung maksimum 8 adjacencies BGP. Oleh karena itu, jika menggunakan kluster peluasan skala NVA aktif, desain ini akan mendukung maksimum 8 instans NVA.
Waktu konvergensi cukup cepat dalam pengaturan ini, dan akan dipengaruhi oleh timer keepalive dan holdtime dari kedekatan BGP. Sementara Azure Route Server memiliki timer keepalive dan holdtime default (masing-masing 60 detik dan 180 detik), NVA dapat menegosiasikan timer yang lebih rendah selama pendirian adjacency BGP. Mengatur timer ini terlalu rendah dapat menyebabkan ketidakstabilan BGP.
Desain ini adalah opsi paling umum untuk NVA yang perlu berinteraksi dengan perutean Azure, misalnya NVA penghentian VPN yang perlu mempelajari awalan yang dikonfigurasi di Azure VNets, atau mengiklankan rute tertentu melalui peering privat ExpressRoute.
Penyeimbang Beban Gateway
Azure Gateway Load Balancer adalah cara baru untuk menyisipkan NVA di jalur data tanpa perlu mengarahkan lalu lintas dengan Rute yang Ditentukan Pengguna. Untuk Komputer Virtual yang mengekspos beban kerja mereka melalui Azure Load Balancer atau alamat IP publik, lalu lintas masuk dan keluar dapat dialihkan secara transparan ke kluster NVA yang terletak di VNet yang berbeda. Diagram berikut menjelaskan jalur yang diikuti paket untuk lalu lintas masuk dari Internet publik jika beban kerja mengekspos aplikasi melalui Azure Load Balancer:
Salah satu keuntungan utama dari metode injeksi NVA ini adalah bahwa Source Network Address Translation (SNAT) tidak diperlukan untuk menjamin simetri lalu lintas. Manfaat lain dari opsi desain ini adalah bahwa NVA yang sama dapat digunakan untuk memeriksa lalu lintas ke/dari VNet yang berbeda, sehingga mencapai multitenansi dari perspektif NVA. Tidak ada peering VNet yang diperlukan antara VNet NVA dan VNet beban kerja, dan tidak ada Rute yang Ditentukan Pengguna yang diperlukan dalam VNet beban kerja, yang secara dramatis menyederhanakan konfigurasi.
Injeksi layanan dengan Load Balancer Gateway dapat digunakan untuk alur masuk yang mencapai Load Balancer publik Azure (dan lalu lintas pengembaliannya), serta untuk alur keluar yang berasal dari Azure. Lalu lintas Timur-Barat antara komputer virtual Azure tidak dapat memanfaatkan Gateway Load Balancer untuk injeksi NVA.
Dalam kluster NVA, pemeriksaan kesehatan Azure Load Balancer akan digunakan untuk mendeteksi kegagalan instans NVA individu, mencapai waktu konvergensi yang sangat cepat (10-15 detik).
Mengubah PIP-UDR
Ide di balik desain ini adalah memiliki pengaturan yang akan diperlukan tanpa redundansi NVA, dan mengubahnya jika NVA menderita waktu henti. Diagram di bawah ini menunjukkan bagaimana alamat IP Publik Azure dikaitkan dengan NVA aktif (NVA1), dan Rute yang Ditentukan Pengguna di spoke memiliki alamat IP NVA aktif sebagai hop berikutnya (10.0.0.37).
Jika NVA aktif menjadi tidak tersedia, NVA siaga akan memanggil Azure API untuk memetakan ulang alamat IP publik dan Rute yang Ditentukan Pengguna spoke ke dirinya sendiri (atau memindahkan alamat IP privat juga). Panggilan API ini dapat memakan waktu beberapa menit agar efektif, itulah sebabnya desain ini menawarkan waktu konvergensi terburuk dari semua opsi dalam dokumen ini.
Batasan lain dari desain ini adalah bahwa hanya konfigurasi aktif/siaga yang didukung, yang dapat menyebabkan masalah skalabilitas: jika Anda perlu meningkatkan bandwidth yang didukung oleh NVA Anda, satu-satunya opsi dengan desain ini adalah meningkatkan kedua instans.
Salah satu manfaat dari desain ini adalah bahwa tidak ada Terjemahan Alamat Jaringan Sumber (SNAT) yang diperlukan untuk menjamin simetri lalu lintas, karena hanya ada satu NVA aktif pada titik waktu tertentu.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Keith Mayer | Arsitek Solusi Cloud Utama
- Telmo Sampaio | Manajer Teknik Layanan Utama
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
- Pelajari cara menerapkan jaringan hibrid yang aman menggunakan Azure Firewall.
- Jaringan Perimeter - Kerangka Kerja Adopsi Cloud
- Cloud DMZ - Kerangka Kerja Adopsi Cloud