Kelompok server CLB - Server Load Balancer - Alibaba Cloud Documentation Center

Pendengar (listener) mengarahkan permintaan layanan ke kelompok server tertentu berdasarkan aturan pengalihan lalu lintas yang dikonfigurasi. Kelompok server tersebut mendistribusikan lalu lintas layanan ke server backend menggunakan algoritma penjadwalan.

Cara kerja

Jenis kelompok server

Jenis kelompok server	Kelompok server default	Kelompok vServer	Kelompok server utama/cadangan
Deskripsi jenis	Setiap instans CLB mencakup satu kelompok server default (tepat satu)	Dibuat dan dikelola oleh Anda	Dibuat dan dikelola oleh Anda
Jumlah server backend	Satu atau lebih	Satu atau lebih	Dua (satu utama, satu cadangan)
Fitur	Berbagi instans: Digunakan secara global di seluruh instans dan digunakan oleh semua listener Pembatasan port: Semua server backend di bawah listener yang sama harus menggunakan port yang sama	Layanan fleksibel: Listener berbeda dapat bind ke kelompok server berbeda Port ganda: Satu kelompok vServer mendukung server backend dengan port berbeda Routing lanjutan: Gabungkan nama domain dan aturan path URL untuk distribusi lalu lintas detail halus	Layanan fleksibel: Listener berbeda dapat bind ke kelompok server berbeda Ketersediaan tinggi: Failover otomatis antara server utama dan cadangan Port ganda: Satu kelompok server utama/cadangan mendukung server backend dengan port berbeda
Skenario	Arsitektur sederhana di mana semua permintaan dialihkan ke kelompok server backend yang sama	Arsitektur kompleks, seperti mendistribusikan permintaan layanan berdasarkan nama domain atau port	Layanan yang memerlukan mode aktif-pasif tetap, seperti database atau API inti
Jenis listener yang didukung	TCP/UDP/HTTP/HTTPS	TCP/UDP/HTTP/HTTPS	Hanya TCP/UDP

Konfigurasi bobot

Algoritma penjadwalan menentukan cara CLB mendistribusikan permintaan masuk ke beberapa server backend. Bobot adalah parameter yang digunakan dalam algoritma weighted untuk mengontrol proporsi lalu lintas yang dialokasikan ke setiap server.

Cakupan: Hanya berlaku saat menggunakan algoritma penjadwalan weighted. Tidak berpengaruh pada algoritma round-robin.
Rentang: 0–100, dengan nilai default 100.
Perilaku saat bobot bernilai 0: Server berhenti menerima lalu lintas permintaan baru. Koneksi yang sudah ada tetap berlanjut hingga ditutup secara normal, dan pemeriksaan kesehatan tetap berjalan. Ini umumnya digunakan untuk shutdown yang mulus.
Dampak perubahan bobot: Penyesuaian bobot hanya berlaku untuk koneksi baru dan tidak memengaruhi koneksi yang sudah ada. Dalam skenario koneksi persisten, redistribusi lalu lintas setelah perubahan bobot terjadi secara perlahan.

Ketersediaan tinggi layanan

Aktifkan pemeriksaan kesehatan CLB untuk mengirim permintaan secara berkala dan memverifikasi status server.

Pemeriksaan kesehatan berhasil: Server dalam kondisi sehat, dan CLB meneruskan lalu lintas ke server tersebut.
Pemeriksaan kesehatan gagal: Server tidak sehat, dan CLB berhenti mengirim lalu lintas permintaan baru ke server tersebut hingga pulih kembali.

Pemeriksaan kesehatan CLB berasal dari blok CIDR 100.64.0.0/10. Pastikan iptables atau perangkat lunak keamanan pihak ketiga lainnya di server backend Anda tidak memblokir blok CIDR ini. Jika tidak, pemeriksaan kesehatan akan gagal dan menyebabkan gangguan layanan.

Kelompok server utama/cadangan mengandalkan pemeriksaan kesehatan untuk failover otomatis:

Jika server utama gagal dalam pemeriksaan kesehatan, lalu lintas dialihkan ke server cadangan. Secara default, server cadangan tidak menjalani pemeriksaan kesehatan, sehingga Anda harus memastikan ketersediaannya secara manual agar failover tanpa hambatan dapat dijamin.
Waktu failover bergantung pada periode timeout respons pemeriksaan kesehatan yang dikonfigurasi. Ketika server utama pulih, lalu lintas secara otomatis dialihkan kembali kepadanya.

Penerapan

Hubungan asosiasi:
- Listener dan kelompok server merupakan resource yang cakupannya terbatas pada instans CLB. Informasi listener dan kelompok server tidak dibagikan antar instans CLB yang berbeda.
- Kelompok server dapat di-bind ke beberapa listener, tetapi satu listener hanya dapat di-bind ke satu kelompok server dalam satu waktu.
- Listener Lapisan 4 CLB tidak mendukung penggunaan instans ECS yang sama sebagai server backend sekaligus client. Jika diperlukan, gunakan listener Lapisan 7 sebagai gantinya.
Menyambungkan server backend:
- CLB hanya mendukung penyambungan server backend dari akun dan wilayah yang sama.
  - Instans CLB jaringan privat: Hanya dapat menyambungkan server backend dalam VPC instans CLB tersebut.
  - Instans CLB jaringan publik: Semua server backend yang disambungkan harus berada dalam VPC yang sama.
- Semua jenis kelompok server CLB mendukung penyambungan resource berikut: Elastic Compute Service (ECS), elastic network interface (ENI), dan Elastic Container Instance (ECI).
  - Hanya ENI yang sudah disambungkan ke instans ECS yang dapat ditambahkan. Alamat IP pribadi utama maupun alamat IP pribadi tambahan dari ENI didukung.
- Ketika instans ECS yang digunakan sebagai server backend menjalani migrasi panas, koneksi persisten CLB mungkin terputus. Layanan dilanjutkan setelah koneksi dipulihkan. Pastikan aplikasi Anda menerapkan mekanisme reconnect otomatis.

Kemampuan modifikasi konfigurasi:

Kemampuan modifikasi konfigurasi	Tambah/hapus kelompok server	Ubah port	Ubah bobot
Kelompok server default	Tidak didukung	Setelah membuat listener dan mengaitkannya, port tidak dapat diubah	Didukung
Kelompok vServer	Didukung	Didukung	Didukung
Kelompok server utama/cadangan	Didukung	Tidak didukung	Mengubah peran utama/cadangan tidak didukung

Konfigurasi kelompok server

Konsol

Kelompok server default

Tidak perlu pembuatan. Setiap instans CLB mencakup satu kelompok server default.
Tambahkan server:
1. Buka halaman CLB – Instances page, klik ID instans target, pilih tab Default Server Group, lalu klik Add.
  - Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
  - Untuk menambahkan ENI, aktifkan dulu mode lanjutan, lalu klik ikon plus di samping instans ECS yang memiliki ENI terpasang untuk menemukan ENI target. Pilih ENI tersebut dan pilih IP.
2. Konfigurasi port dan bobot:
  - Konfigurasi port: Buka tab Listener, klik Add Listener. Pada halaman wizard Backend Servers, atur Port untuk server dalam kelompok server default. Semua server dalam kelompok server default di bawah listener yang sama harus menggunakan port yang sama.
    
    Anda hanya dapat menentukan port saat menambahkan listener. Port tersebut tidak dapat diubah nanti.
  - Konfigurasi bobot: Atur Weight untuk server yang dipilih.

Kelompok vServer

Buka halaman CLB – Instances page, klik ID instans target, pilih vServer groups, lalu klik Create vServer Group.
Add server:
- Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
- Untuk menambahkan ENI, aktifkan dulu mode lanjutan, lalu klik ikon plus di samping instans ECS yang memiliki ENI terpasang untuk menemukan ENI target. Pilih ENI tersebut dan pilih IP.
Konfigurasi Port dan Weight untuk server yang dipilih. Klik Add Port untuk menetapkan beberapa port berbeda ke server backend yang sama.

Kelompok server utama/cadangan

Buka halaman CLB – Instances page, klik ID instans target, pilih Primary/Secondary Server Groups, lalu klik Create Primary/Secondary Server Group.
Add server:
- Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
- Untuk menambahkan ENI, aktifkan dulu mode lanjutan, lalu klik ikon plus di samping instans ECS yang memiliki ENI terpasang untuk menemukan ENI target. Pilih ENI tersebut dan pilih IP.
- Hanya dua server backend yang dapat ditambahkan.
Konfigurasi Port untuk server yang dipilih. Klik Add Port untuk menetapkan beberapa port berbeda ke server backend yang sama. Setelah menambahkan, pilih Primary Server untuk menentukan hubungan utama/cadangan.

API

Kelompok server default

Panggil AddBackendServers untuk menambahkan server backend.
Panggil SetBackendServers untuk mengatur bobot server backend.
Panggil RemoveBackendServers untuk menghapus server backend.

Kelompok vServer

Panggil CreateVServerGroup untuk membuat kelompok vServer dan menambahkan server backend dengan konfigurasi port dan bobot.
Panggil AddVServerGroupBackendServers / RemoveVServerGroupBackendServers untuk menambahkan atau menghapus server backend dari kelompok vServer tertentu.
Panggil DeleteVServerGroup untuk menghapus kelompok vServer.

Kelompok server utama/cadangan

Panggil CreateMasterSlaveServerGroup untuk membuat kelompok server utama/cadangan.
Panggil DeleteMasterSlaveServerGroup untuk menghapus kelompok server utama/cadangan.

FAQ

Apakah saya dapat menyesuaikan jumlah instans ECS saat instans CLB sedang berjalan?

Kelompok server default dan kelompok vServer: Anda dapat menambahkan atau menghapus instans ECS backend kapan saja dan beralih antar instans ECS berbeda. Untuk memastikan stabilitas layanan, aktifkan pemeriksaan kesehatan sebelum melakukan operasi ini dan pastikan setidaknya satu instans ECS sehat tetap tersedia di backend.
Kelompok server utama/cadangan: Tidak didukung.

Apakah instans ECS backend dapat menggunakan sistem operasi berbeda?

Boleh berbeda.

CLB tidak membatasi sistem operasi instans ECS backend, selama layanan aplikasi dan datanya konsisten. Kami merekomendasikan penggunaan sistem operasi yang sama untuk memudahkan manajemen dan maintenance.

Apakah saya dapat menggunakan instans ECS dari wilayah berbeda sebagai server backend?

CLB tidak mendukung penyambungan langsung server backend cross-region. Untuk menerapkan deployment cross-region, gunakan salah satu solusi berikut:

Terapkan Pengelola Lalu Lintas Global di atas CLB dan deploy beberapa instans CLB di berbagai wilayah. Lakukan switching antar instans CLB untuk mencapai penyambungan cross-region.
Gunakan Application Load Balancer (ALB) atau Network Load Balancer (NLB), yang mendukung penyambungan backend cross-region.

Mengapa instans ECS saya sering menerima permintaan dari IP yang dimulai dengan 100?

Permintaan tersebut berasal dari pemeriksaan kesehatan dan pemantauan ketersediaan load balancer.

Sumber: Blok CIDR reservasi Alibaba Cloud 100.64.0.0/10.
Keamanan: Blok CIDR ini dicadangkan oleh Alibaba Cloud dan tidak dapat dialokasikan ke pengguna lain, sehingga tidak menimbulkan risiko keamanan.
Rekomendasi: Pastikan iptables atau perangkat lunak keamanan pihak ketiga lainnya di server backend Anda tidak memblokir blok CIDR ini agar ketersediaan layanan tetap terjaga.

Jika pemeriksaan kesehatan gagal, lihat Bagaimana cara mengatasi kegagalan pemeriksaan kesehatan?

Instans ECS saya tidak mengaktifkan kompresi, tetapi respons HTTP dari CLB dikompresi. Mengapa?

Alasan: Kompresi Gzip diaktifkan dalam konfigurasi listener CLB, dan browser client mendukung kompresi.
Tindakan: Untuk menonaktifkannya, matikan kompresi Gzip di pengaturan listener Konsol CLB atau beralih ke listener TCP.

Apakah instans ECS yang menggunakan HTTP/1.0 mendukung chunked transfer encoding?

Ya.

Mengapa instans ECS backend CLB saya sering menerima permintaan dengan User-Agent KeepAliveClient?

Pengamatan: Backend ECS menerima banyak permintaan GET dari alamat IP internal dengan User-Agent KeepAliveClient.
Alasan: Protokol listener adalah TCP, tetapi protokol pemeriksaan kesehatan diatur ke HTTP. Saat listener TCP menggunakan pemeriksaan kesehatan HTTP, metode GET digunakan secara default.
Solusi: Samakan protokol listener dan protokol pemeriksaan kesehatan (misalnya, gunakan keduanya TCP atau keduanya HTTP).

Apakah saya dapat mengubah port server dalam kelompok server default?

Modifikasi langsung tidak didukung.

Pembatasan: Port untuk kelompok server default hanya dapat diatur saat membuat listener, dan semua server backend di bawah listener yang sama harus menggunakan port yang sama.
Solusi: Untuk mengonfigurasi port backend berbeda untuk listener yang sama, gunakan kelompok vServer.

Apakah listener Lapisan 4 CLB mendukung penggunaan instans ECS yang sama sebagai server backend sekaligus client?

Tidak. Konfigurasi ini menyebabkan loop.

Alternatif:

Gunakan listener Lapisan 7 CLB (HTTP/HTTPS).
Gunakan instans NLB dan nonaktifkan pelestarian IP client untuk kelompok server. Lihat Bagaimana instans ECS dapat berfungsi sebagai server backend sekaligus client di NLB?

Mengapa backend CLB saya memiliki banyak koneksi TIME-WAIT, sedangkan ALB hanya sedikit?

Classic Load Balancer (CLB) dan Application Load Balancer (ALB) menggunakan mekanisme koneksi berbeda saat berinteraksi dengan server backend.

Classic Load Balancer (CLB): Secara default menggunakan koneksi singkat HTTP. CLB menyisipkan header Connection: close ke dalam permintaan HTTP. Setelah memproses permintaan, server backend mengirim paket FIN untuk menutup koneksi berdasarkan header ini. Setiap penutupan memasuki status TIME-WAIT (default 60 detik), sehingga menumpuk cepat dalam kondisi konkurensi tinggi.
Application Load Balancer (ALB): Secara default mendukung koneksi persisten HTTP (keep-alive). Satu koneksi TCP menangani beberapa permintaan, mengurangi penutupan koneksi dan karenanya mengurangi koneksi TIME-WAIT.

Untuk mengurangi akumulasi TIME-WAIT, pertimbangkan opsi berikut:

Beralih ke listener CLB Lapisan 4 (TCP). Pemeriksaan kesehatan Lapisan 4 mengirim paket RST setelah handshake berhasil untuk menutup koneksi tanpa memasuki status TIME-WAIT.
Migrasi ke ALB untuk memanfaatkan mekanisme reuse koneksi persisten HTTP default-nya.

Mengapa lalu lintas tidak merata di antara server backend?

Penyebab umum	Deskripsi	Pemecahan masalah dan solusi
Persistensi sesi	Dengan persistensi sesi diaktifkan, permintaan dari client yang sama selalu diarahkan ke server backend yang sama. Dengan jumlah client sedikit (misalnya, saat uji stres dengan client terbatas), lalu lintas terkonsentrasi pada server tertentu.	Periksa apakah persistensi sesi diaktifkan dan evaluasi apakah layanan Anda benar-benar memerlukannya.
Koneksi persisten	Koneksi persisten yang telah terbentuk tidak didistribusikan ulang saat bobot berubah. Dalam skenario koneksi persisten, pergeseran lalu lintas setelah penyesuaian bobot terjadi secara perlahan.	Lakukan scaling atau penyesuaian bobot selama jam sepi dan tunggu koneksi lama ditutup secara alami. Pastikan pengaturan TCP Keepalive konsisten di seluruh server backend untuk mencegah akumulasi koneksi pada beberapa server.
Kegagalan atau fluktuasi pemeriksaan kesehatan	Beberapa server backend gagal dalam pemeriksaan kesehatan dan tidak dapat menerima permintaan, atau status kesehatannya berfluktuasi antara sehat dan tidak sehat, menyebabkan distribusi lalu lintas tidak stabil.	Tinjau log pemeriksaan kesehatan untuk fluktuasi status. Tingkatkan sedikit interval pemeriksaan kesehatan dan ambang batas tidak sehat untuk mengurangi false positive. Verifikasi bahwa konfigurasi kode respons pemeriksaan kesehatan sudah benar.
Volume total permintaan rendah	Periksa metrik pemantauan CLB. Ketidakseimbangan ringan merupakan hal normal saat volume total permintaan rendah.	Amati distribusi lalu lintas setelah meningkatkan volume permintaan. Jika ketidakseimbangan tetap terjadi di bawah beban tinggi, selidiki penyebab lainnya.
Konfigurasi bobot tidak tepat	Bobot server tidak sesuai dengan kapasitas pemrosesan aktual, menyebabkan beberapa server kelebihan beban sementara yang lain menganggur.	Konfirmasi bahwa Anda menggunakan algoritma penjadwalan weighted (round-robin mengabaikan bobot). Atur bobot sesuai dengan kapasitas pemrosesan aktual setiap server backend.

Bagaimana cara menghapus instans ECS backend dari CLB secara aman?

Menghapus instans ECS secara langsung dapat menyebabkan pemutusan sementara. Pertama-tama, atur bobot instans ECS menjadi 0. Tunggu hingga koneksi yang ada selesai sebelum menghapus instans tersebut. Untuk detail perilaku bobot saat diatur ke 0, lihat bagian Konfigurasi bobot di atas.

Jika permintaan bisnis tetap berlanjut setelah menghapus instans ECS, periksa hal berikut:

Apakah instans ECS juga disambungkan ke instans CLB lain.
Apakah instans ECS menyediakan layanan lain secara langsung. Gunakan perintah netstat untuk memeriksa status listening port.

Mengapa tidak ada lalu lintas yang dialihkan ke server backend yang baru ditambahkan?

Jika CLB tidak meneruskan lalu lintas ke server backend yang baru ditambahkan, periksa hal berikut:

Pemeriksaan kesehatan gagal: Port server backend tidak dapat dijangkau atau aplikasi tidak listening pada port yang diharapkan, menyebabkan kegagalan pemeriksaan kesehatan. Di Konsol CLB, konfirmasi status pemeriksaan kesehatan server dan verifikasi status listening port serta aplikasi di server backend. Jika pemeriksaan kesehatan gagal, lihat Bagaimana cara mengatasi kegagalan pemeriksaan kesehatan?
Bobot diatur ke 0: Server dengan bobot 0 tidak menerima lalu lintas permintaan baru. Periksa bobot server di kelompok server dan pastikan nilainya lebih besar dari 0. Untuk detailnya, lihat bagian Konfigurasi bobot di atas.
Ditambahkan ke kelompok server yang salah: Setiap listener CLB di-bind ke kelompok server tertentu (default atau kelompok vServer). Jika server baru ditambahkan ke kelompok yang tidak di-bind ke listener target, server tersebut tidak akan menerima lalu lintas untuk listener tersebut. Konfirmasi kelompok server yang sebenarnya di-bind ke listener dan tambahkan server ke kelompok yang benar.
iptables atau perangkat lunak keamanan pihak ketiga memblokir blok CIDR pemeriksaan kesehatan: Pemeriksaan kesehatan CLB menggunakan blok CIDR 100.64.0.0/10. Jika iptables atau perangkat lunak keamanan pihak ketiga lainnya di server backend memblokir blok CIDR ini, pemeriksaan kesehatan gagal dan CLB menganggap server tersebut tidak sehat. Pastikan aturan terkait tidak memblokir blok CIDR ini.
Periode jendela pemeriksaan kesehatan belum tercapai: Setelah menambahkan server backend, CLB menunggu pemeriksaan kesehatan berhasil sebelum meneruskan lalu lintas. Tunggu sebentar, lalu verifikasi apakah lalu lintas mengalir secara normal.