Gateway Load Balancer (GWLB) sangat ideal untuk menerapkan, memperluas, atau mengelola aplikasi jaringan virtual pihak ketiga (NVAs) dalam skenario seperti firewall, deteksi intrusi, pemantulan lalu lintas, dan Deep Packet Inspection (DPI). GWLB beroperasi secara transparan di Lapisan 3 pada model referensi Open Systems Interconnection (OSI). Oleh karena itu, diperlukan persiapan sebelum menggunakan GWLB untuk menerapkan NVAs. Topik ini menjelaskan cara kerja GWLB serta langkah-langkah untuk mengintegrasikan NVAs dengan GWLB.
Apa itu GWLB?
GWLB adalah load balancer yang beroperasi di Lapisan 3, juga dikenal sebagai lapisan jaringan, dalam model referensi OSI. GWLB membantu aplikasi perusahaan menerapkan, memperluas, dan mengelola berbagai jenis NVAs pihak ketiga dalam skenario seperti firewall, deteksi intrusi, pemantulan lalu lintas, dan DPI. GWLB menawarkan kemampuan berikut:
Mendukung penerapan beberapa NVAs pihak ketiga.
Memberikan penerapan NVAs pihak ketiga yang lebih andal.
Mendukung ketersediaan NVAs pihak ketiga lintas zona.
Bekerja dengan PrivateLink untuk mempertahankan ketersediaan NVAs pihak ketiga di seluruh Virtual Private Clouds (VPCs) dan akun.
Kompatibel dengan layanan software as a service (SaaS) dari penyedia NVA pihak ketiga.
Cara kerjanya
Alur Kerja
Seperti yang ditunjukkan pada gambar berikut, sebuah instance GWLB terhubung ke endpoint GWLB dari VPC lain. Endpoint GWLB adalah jenis endpoint VPC khusus. Sebuah instance GWLB dapat terhubung ke beberapa endpoint GWLB.
Tabel berikut menjelaskan cara kerja instance GWLB.
No. | Deskripsi |
① | Lalu lintas jaringan dari klien ke server diarahkan ke endpoint GWLB. |
② | Endpoint GWLB meneruskan lalu lintas jaringan ke instance GWLB terkait melalui PrivateLink. |
③ | Instance GWLB mengenkapsulasi paket asli menggunakan GENEVE dan meneruskan lalu lintas ke NVA yang sehat di backend berdasarkan algoritma penjadwalan lalu lintas. NVA mengidentifikasi sumber lalu lintas berdasarkan informasi seperti ID endpoint GWLB 64-bit yang dibawa oleh GENEVE. |
④ | Setelah NVA memproses paket, ia meneruskan paket ke instance GWLB menggunakan GENEVE. |
⑤ | Instance GWLB meneruskan lalu lintas ke endpoint GWLB terkait melalui PrivateLink. |
⑥ | Endpoint GWLB memeriksa rute berdasarkan alamat tujuan dan meneruskan lalu lintas ke server tujuan. |
Metode Penjadwalan Lalu Lintas
GWLB mendukung penjadwalan lalu lintas berdasarkan algoritma hash konsisten dari paket 5-tupel, 3-tupel, atau 2-tupel. Paket 5-tupel mencakup alamat IP sumber, alamat IP tujuan, protokol, port sumber, dan port tujuan. Paket 3-tupel mencakup alamat IP sumber, alamat IP tujuan, dan protokol. Paket 2-tupel mencakup alamat IP sumber dan alamat IP tujuan. GWLB merutekan lalu lintas dengan tupel yang sama ke server backend yang sama.
Kasus umum:
Untuk lalu lintas melalui TCP atau UDP, Anda dapat memilih algoritma hash berdasarkan paket 5-tupel.
Untuk lalu lintas melalui protokol selain TCP dan UDP, Anda dapat memilih algoritma hash berdasarkan paket 3-tupel.
Mekanisme Pemeriksaan Kesehatan
GWLB secara berkala melakukan pemeriksaan kesehatan pada interval tertentu. GWLB mengirimkan paket TCP, HTTP, atau HTTPS ke NVA backend dan memeriksa status kesehatan NVA berdasarkan respons dari NVA backend.
TCP: Jika GWLB dapat membangun koneksi TCP dengan NVA backend, GWLB menganggap NVA backend sehat.
HTTP atau HTTPS: Jika kode status HTTP 2xx atau 3xx dikembalikan setelah GWLB mengirimkan Permintaan HTTP atau HTTPS ke NVA backend, GWLB menganggap NVA backend sehat. Jika tidak, GWLB menganggap NVA backend tidak sehat. GWLB tidak memverifikasi nama host pada Sertifikat yang diterima. Oleh karena itu, sertifikat, termasuk Sertifikat tanda tangan sendiri, dapat digunakan selama tidak kedaluwarsa.
Paket pemeriksaan kesehatan tidak dienkapsulasi oleh GENEVE.
Jika NVA tidak merespons sebelum periode timeout pemeriksaan kesehatan berakhir, NVA gagal dalam pemeriksaan kesehatan.
Integrasi NVA dengan GWLB
Metode Integrasi
GWLB berkomunikasi dengan NVAs backend melalui protokol GENEVE. GWLB mengenkapsulasi type-length-value (TLV) GENEVE dalam setiap paket untuk mengirimkan informasi tambahan, seperti ID endpoint GWLB dan Flow Cookie, ke NVA. Paket GENEVE yang diterima oleh NVA mungkin berisi satu atau lebih TLV GENEVE.
ID endpoint GWLB: ID 64-bit yang ditetapkan untuk endpoint GWLB. NVA dapat menggunakan ID endpoint GWLB untuk mengaitkan paket dengan konfigurasinya. ID ini juga digunakan untuk menentukan sumber lalu lintas.
Flow Cookie: Angka acak 32-bit yang dihasilkan untuk aliran saat GWLB membuat entri aliran dalam tabel aliran. Setiap aliran memiliki cookie unik. NVA harus mengembalikan cookie asli. Saat GWLB menerima paket dari NVA, GWLB hanya meneruskan paket jika cookie dalam paket cocok dengan cookie yang ditetapkan untuk aliran. Jika cookie tidak cocok atau tidak ada, paket akan dihapus.
Proses berikut menjelaskan bagaimana NVA merespons permintaan:
Enkapsulasi paket asli dalam header GENEVE.
Tukar alamat IP sumber dan alamat IP tujuan di header IPv4 luar. Alamat IP sumber adalah alamat IP NVA dan alamat IP tujuan adalah alamat IP GWLB.
Simpan port asli dan jangan tukar port sumber dan tujuan di header IPv4 luar.
Perbarui checksum IP di header IPv4 luar.
Kembalikan semua bidang asli di header GENEVE.
Kembalikan semua TLV asli di GENEVE Option, termasuk ID endpoint GWLB dan Flow Cookie.
Format Paket GENEVE
Contoh berikut menunjukkan format paket GENEVE. Untuk informasi lebih lanjut tentang GENEVE, lihat RFC 8926.
Header IPv4 Luar:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Versi| IHL |Jenis Layanan| Panjang Total |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifikasi |Bendera| Offset Fragmen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waktu Hidup |Protokol=17 UDP| Checksum Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alamat IPv4 Sumber Luar |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alamat IPv4 Tujuan Luar |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Sumber = xxxx | Port Tujuan = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Panjang UDP | Checksum UDP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Geneve Luar:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C| Cadangan | EtherType = 0x0800 atau 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pengenal Jaringan Virtual (VNI) = 0 | Cadangan |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opsi Geneve Luar: Alibaba Cloud Gateway Load Balancer TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kelas Opsi = 0x0139 (Ali)| Tipe = 1 |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ID endpoint GWLB 64-bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kelas Opsi = 0x0139 (Ali)| Tipe = 3 |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie Aliran 32-bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Muatan pelanggan mengikuti...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Muatan pelanggan diidentifikasi oleh EtherType di header Geneve |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+