全部产品
Search
文档中心

Server Load Balancer:Arsitektur layanan

更新时间:Dec 04, 2025

Classic Load Balancer (CLB) diterapkan dalam kluster dan menyediakan layanan load balancing Lapisan 4 (TCP dan UDP) serta Lapisan 7 (HTTP dan HTTPS). CLB menyinkronkan sesi dan menghilangkan single points of failure (SPOFs) untuk meningkatkan redundansi serta memastikan stabilitas layanan.

CLB menggunakan kluster CLB untuk meneruskan permintaan klien ke server backend dan menerima tanggapan dari server backend melalui jaringan internal.

Arsitektur dasar

CLB menyediakan layanan load balancing pada Lapisan 4 dan Lapisan 7.

  • Pada Lapisan 4, CLB menggabungkan Linux Virtual Server (LVS) open-source dengan Keepalived untuk menyeimbangkan beban dan menerapkan optimasi guna memenuhi kebutuhan komputasi awan.

  • Pada Lapisan 7, CLB menggunakan Tengine untuk menyeimbangkan beban. Tengine adalah proyek server web yang diluncurkan oleh Taobao dan berbasis NGINX, dengan berbagai fitur lanjutan yang dioptimalkan untuk situs web bertrafik tinggi.

    Tengine

Seperti yang ditunjukkan pada gambar berikut, di setiap wilayah, CLB Lapisan 4 berjalan dalam kluster LVS yang terdiri dari beberapa server fisik LVS. Model penerapan kluster ini meningkatkan ketersediaan, stabilitas, dan skalabilitas CLB bahkan saat terjadi anomali.

LVS

Setiap server backend dalam kluster LVS menggunakan paket multicast untuk menyinkronkan sesi di seluruh kluster. Sebagai contoh, seperti yang ditunjukkan pada gambar berikut, setelah klien mengirim tiga paket ke server, Sesi A yang dibuat di LVS1 disinkronkan dengan server lainnya. Garis utuh menunjukkan koneksi aktif, sedangkan garis putus-putus menunjukkan bahwa permintaan dialihkan ke server sehat lainnya (dalam hal ini LVS2) jika LVS1 gagal atau sedang dalam pemeliharaan. Hal ini memungkinkan Anda melakukan hot upgrade, pemecahan masalah server, dan mengambil kluster offline untuk pemeliharaan tanpa memengaruhi layanan yang disediakan oleh aplikasi Anda.

Catatan

Jika koneksi tidak berhasil dibuat karena three-way handshake gagal, atau jika koneksi telah terbentuk tetapi sesi belum tersinkronisasi selama hot upgrade, layanan Anda mungkin terganggu. Dalam kasus tersebut, Anda harus menginisiasi ulang permintaan koneksi dari klien.

LVS

Alur lalu lintas inbound

CLB mendistribusikan lalu lintas inbound berdasarkan aturan pengalihan yang Anda konfigurasikan di Konsol CLB atau melalui operasi API. Gambar berikut menunjukkan alur lalu lintas inbound.

Figure 1. Alur lalu lintas inbound

  1. Lalu lintas inbound yang menggunakan TCP, UDP, HTTP, atau HTTPS harus diteruskan melalui kluster Lapisan 4.

  2. Sejumlah besar lalu lintas inbound didistribusikan secara merata di antara semua node dalam kluster Lapisan 4, dan node-node tersebut menyinkronkan sesi untuk memastikan ketersediaan tinggi.

    • Jika instance CLB menggunakan pendengar Lapisan 4 berbasis UDP atau TCP, node dalam kluster Lapisan 4 mendistribusikan permintaan langsung ke instance Elastic Compute Service (ECS) backend berdasarkan aturan pengalihan yang dikonfigurasikan untuk instance CLB tersebut.

    • Jika instance CLB menggunakan pendengar Lapisan 7 berbasis HTTP, node dalam kluster Lapisan 4 terlebih dahulu mendistribusikan permintaan ke kluster Lapisan 7. Selanjutnya, node dalam kluster Lapisan 7 mendistribusikan permintaan tersebut ke instance ECS backend berdasarkan aturan pengalihan yang dikonfigurasikan untuk instance CLB tersebut.

    • Jika instance CLB menggunakan pendengar Lapisan 7 berbasis HTTPS, permintaan didistribusikan dengan cara yang mirip dengan instance CLB yang menggunakan pendengar berbasis HTTP. Perbedaannya adalah sistem memanggil Key Server untuk memvalidasi sertifikat dan mendekripsi paket data sebelum permintaan didistribusikan ke instance ECS backend.

Alur lalu lintas outbound

CLB dan instance ECS backend berkomunikasi melalui jaringan internal.

  • Jika instance ECS backend hanya menangani lalu lintas yang didistribusikan dari CLB, Anda tidak perlu membeli sumber daya bandwidth Internet, seperti Alamat IP publik, elastic IP addresses (EIPs), Anycast EIPs, atau NAT gateway, untuk instance ECS tersebut.

    Catatan

    Instance ECS yang dibuat sebelumnya langsung diberikan Alamat IP publik. Anda dapat melihat Alamat IP publik tersebut dengan menjalankan perintah ipconfig. Jika instance ECS hanya menyediakan layanan eksternal melalui CLB, tidak ada biaya lalu lintas Internet yang dikenakan meskipun statistik lalu lintas dibaca pada elastic network interfaces (ENIs).

  • Jika Anda ingin instance ECS backend Anda langsung menyediakan layanan eksternal atau mengakses Internet, Anda harus mengonfigurasi atau membeli Alamat IP publik, EIPs, Anycast EIPs, atau NAT gateway untuk instance tersebut.

Gambar berikut menunjukkan alur lalu lintas outbound.

Figure 2. Alur lalu lintas outbound

Prinsip umum alur lalu lintas outbound adalah lalu lintas keluar dari tempat asalnya masuk.

  • Lalu lintas yang mengalir melalui instance CLB dikendalikan lajunya atau ditagih pada instance CLB tersebut. Anda tidak dikenai biaya untuk komunikasi internal antara instance CLB dan instance ECS backend.

  • Anda dikenai biaya untuk lalu lintas dari EIPs atau NAT gateway. Anda dapat mengendalikan laju lalu lintas pada EIPs atau NAT gateway. Jika sumber daya bandwidth publik dikonfigurasikan untuk instance ECS, Anda dikenai biaya untuk lalu lintas dari instance ECS tersebut, dan Anda dapat mengendalikan laju lalu lintas pada instance ECS tersebut.

  • CLB mendukung akses responsif ke Internet. Instance ECS backend hanya dapat mengakses Internet jika perlu merespons permintaan dari Internet. Permintaan tersebut diteruskan ke instance ECS backend oleh instance CLB. Jika instance ECS backend Anda perlu mengakses Internet secara proaktif, Anda harus mengaitkan EIPs atau menggunakan NAT gateway dengan instance ECS tersebut.

  • Sumber daya bandwidth publik yang dikonfigurasikan untuk instance ECS, EIPs, Anycast EIPs, dan NAT gateway memungkinkan instance ECS mengakses Internet atau diakses dari Internet, tetapi sumber daya tersebut tidak dapat mendistribusikan lalu lintas atau menyeimbangkan beban lalu lintas.

FAQ

Apakah nilai bandwidth maksimum yang saya tetapkan saat membeli instance CLB sama dengan jumlah bandwidth maksimum inbound dan outbound?

Tidak.

Nilai bandwidth maksimum berlaku secara terpisah untuk lalu lintas inbound dan outbound. Setiap jenis lalu lintas dapat mencapai nilai bandwidth maksimum yang Anda tentukan secara independen tanpa memengaruhi yang lainnya.

Untuk informasi lebih lanjut, lihat Batas bandwidth.