Arsitektur produk Classic Load Balancer (CLB) - Server Load Balancer

Classic Load Balancer (CLB) menggunakan arsitektur berbasis kluster untuk menyediakan load balancing Lapisan 4 (TCP dan UDP) serta Lapisan 7 (HTTP dan HTTPS). CLB mendukung sinkronisasi sesi guna menghilangkan single point of failure (SPOF), meningkatkan redundansi, dan memastikan stabilitas layanan.

Sebagai layanan pengalihan trafik, CLB mengarahkan permintaan dari klien melalui kluster load balancing ke server backend. Server backend kemudian mengembalikan tanggapan ke CLB melalui jaringan internal.

Ikhtisar arsitektur

Alibaba Cloud menyediakan layanan load balancing Lapisan 4 dan Lapisan 7.

Load balancing Lapisan 4 menggunakan stack open-source Linux Virtual Server (LVS) dan Keepalived yang telah dikustomisasi oleh Alibaba Cloud untuk memenuhi kebutuhan komputasi awan.
Load balancing Lapisan 7 menggunakan Tengine, sebuah proyek server web yang diprakarsai oleh Taobao. Berbasis Nginx, Tengine mencakup fitur-fitur canggih untuk menangani situs web bertrafik tinggi.

Seperti yang ditunjukkan pada gambar berikut, layanan load balancing Lapisan 4 di setiap wilayah berjalan pada kluster server LVS. Arsitektur ini menjamin ketersediaan, stabilitas, dan skalabilitas layanan load balancing, bahkan ketika node individu mengalami kegagalan.

LVS

Setiap server LVS menyinkronkan semua sesi dengan server lain dalam kluster menggunakan paket multicast. Seperti yang terlihat pada gambar berikut, setelah klien mengirim tiga paket data ke server, Sesi A dibuat di LVS1 dan mulai disinkronkan ke server LVS lainnya. Garis utuh merepresentasikan koneksi yang aktif, sedangkan garis putus-putus menunjukkan bagaimana trafik dialihkan ke server sehat, yaitu LVS2, jika LVS1 mengalami kegagalan atau sedang dalam pemeliharaan. Arsitektur ini memungkinkan kluster mendukung hot upgrade. Kegagalan dan pemeliharaan bersifat transparan bagi pengguna dan tidak memengaruhi layanan Anda.

Catatan

Saat hot upgrade berlangsung, koneksi dapat terputus jika three-way handshake belum lengkap atau jika koneksi yang telah terbentuk belum memicu sinkronisasi sesi. Dalam kasus tersebut, klien harus melakukan koneksi ulang.

LVS

Jalur lalu lintas masuk

Untuk lalu lintas masuk, CLB meneruskan dan memproses permintaan berdasarkan aturan pengalihan yang Anda konfigurasikan di Konsol atau Developer Portal. Gambar berikut mengilustrasikan alur data tersebut.

Gambar 1. Jalur lalu lintas masuk

Seluruh trafik TCP, UDP, HTTP, dan HTTPS melewati kluster Lapisan 4.
Setiap node dalam kluster Lapisan 4 mendistribusikan volume permintaan yang tinggi secara merata, dan kebijakan sinkronisasi sesi antar-node menjamin ketersediaan tinggi.
- Jika pendengar untuk instans CLB menggunakan protokol Lapisan 4 (TCP atau UDP), setiap node dalam kluster Lapisan 4 langsung mendistribusikan permintaan ke instans Elastic Compute Service (ECS) backend berdasarkan aturan pengalihan instans CLB.
- Jika pendengar untuk instans CLB menggunakan protokol HTTP Lapisan 7, setiap node dalam kluster Lapisan 4 terlebih dahulu mendistribusikan permintaan secara merata ke kluster Lapisan 7. Selanjutnya, setiap node dalam kluster Lapisan 7 mendistribusikan permintaan tersebut ke instans ECS backend berdasarkan aturan pengalihan instans CLB.
- Jika pendengar untuk instans CLB menggunakan protokol HTTPS Lapisan 7, prosesnya mirip dengan HTTP. Namun, sebelum mendistribusikan permintaan ke instans ECS backend, CLB memanggil Key Server untuk melakukan validasi sertifikat serta enkripsi dan dekripsi paket.

Jalur lalu lintas keluar

CLB dan instans ECS backend saling berkomunikasi melalui jaringan internal.

Jika instans ECS Anda hanya memproses permintaan dari CLB, Anda tidak perlu membeli resource bandwidth publik, seperti alamat IP publik untuk instans ECS, elastic IP addresses (EIPs), Anycast EIPs, atau NAT gateway.

Catatan
Beberapa instans ECS lama langsung diberikan alamat IP publik. Anda dapat melihat alamat tersebut dengan menjalankan perintah ipconfig pada instans. Jika instans tersebut hanya melayani trafik melalui CLB, Anda tidak akan dikenai biaya jaringan publik untuk instans ECS tersebut, meskipun statistik trafik terlihat pada antarmuka jaringan elastis.
Jika instans ECS backend Anda perlu melayani trafik eksternal secara langsung atau memerlukan akses internet, Anda harus mengonfigurasi atau membeli layanan yang diperlukan, seperti alamat IP publik, EIP, Anycast EIP, atau NAT gateway untuk instans tersebut.

Gambar berikut menunjukkan jalur trafik publik untuk sebuah instans ECS.

Gambar 2. Jalur lalu lintas keluar

Prinsip umumnya adalah: trafik keluar mengikuti jalur yang sama dengan saat masuk.

Trafik yang masuk melalui CLB mengalami pembatasan kecepatan atau penagihan pada instans CLB. Komunikasi antara CLB dan instans ECS berlangsung melalui jaringan internal Alibaba Cloud dan tidak dikenai biaya trafik publik.
Trafik dari EIP atau NAT gateway mengalami pembatasan kecepatan atau penagihan pada resource masing-masing. Jika Anda membeli bandwidth publik saat membuat instans ECS, pembatasan kecepatan dan penagihan dilakukan pada level instans.
CLB hanya menyediakan akses internet responsif. Artinya, instans ECS backend hanya dapat mengakses internet untuk merespons permintaan yang diteruskan oleh CLB. Untuk mengizinkan instans ECS backend memulai koneksi keluar, Anda harus mengaitkan EIP ke instans tersebut atau menempatkannya di belakang NAT gateway.
Bandwidth publik yang dikonfigurasi untuk instans ECS, EIP, Anycast EIP, atau NAT gateway menyediakan akses internet dua arah untuk instans tersebut. Namun, resource ini tidak menyediakan kemampuan distribusi trafik atau load balancing.

FAQ

Perhitungan bandwidth CLB

Tidak.

Bandwidth instans CLB diterapkan secara terpisah untuk lalu lintas masuk dan keluar. Alibaba Cloud mengalokasikan jumlah bandwidth yang dibeli untuk masing-masing arah. Oleh karena itu, baik lalu lintas masuk maupun keluar dapat mencapai puncak bandwidth maksimum secara independen.

Untuk informasi lebih lanjut, lihat Batas bandwidth.