Pendengar (listener) mengarahkan permintaan layanan ke kelompok server tertentu berdasarkan aturan pengalihan yang dikonfigurasi. Kelompok server tersebut mendistribusikan lalu lintas layanan ke server backend sesuai dengan algoritma penjadwalan.
Cara kerja
Jenis kelompok server
Jenis kelompok server | Kelompok server default | Kelompok vServer | Kelompok server utama/cadangan |
Deskripsi | Setiap instans CLB dilengkapi satu kelompok server default. (tepat satu) | Anda membuat dan mengelolanya. | Anda membuat dan mengelolanya. |
Jumlah server backend | Satu atau lebih | Satu atau lebih | Dua (satu utama dan satu cadangan) |
Karakteristik |
|
|
|
Skenario | Arsitektur sederhana di mana semua permintaan diarahkan ke kelompok server backend yang sama. | Arsitektur kompleks, seperti mendistribusikan permintaan layanan berdasarkan nama domain atau port. | Layanan dengan mode utama/cadangan tetap, seperti database dan layanan 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 yang diterima ke beberapa server backend. Bobot merupakan parameter dalam algoritma yang mendukung distribusi berbobot dan mengontrol proporsi lalu lintas yang didistribusikan ke setiap server.
Ruang lingkup: Berlaku untuk algoritma penjadwalan yang mendukung distribusi berbobot. Algoritma round-robin tidak menggunakan bobot.
Rentang nilai: 0 hingga 100. Nilai default adalah 100.
Perilaku saat bobot bernilai 0: Server berhenti menerima permintaan baru, tetapi koneksi yang telah terbentuk tetap diproses hingga ditutup. Pemeriksaan kesehatan juga tetap berjalan. Konfigurasi ini sering digunakan untuk shutdown server secara graceful.
Ruang lingkup perubahan bobot: Perubahan bobot hanya berlaku untuk koneksi baru dan tidak memengaruhi koneksi yang telah terbentuk. Dalam skenario koneksi persisten, perubahan distribusi lalu lintas terjadi secara bertahap setelah penyesuaian bobot.
Ketersediaan tinggi layanan
Anda dapat mengaktifkan pemeriksaan kesehatan CLB, yang secara berkala mengirim permintaan untuk memverifikasi status server.
Pemeriksaan kesehatan berhasil: Status server normal, dan CLB meneruskan lalu lintas ke server tersebut.
Pemeriksaan kesehatan gagal: Status server abnormal. CLB berhenti meneruskan permintaan baru ke server tersebut hingga statusnya pulih.
Pemeriksaan kesehatan CLB menggunakan blok CIDR 100.64.0.0/10. Pastikan kebijakan security group pada server backend mengizinkan akses dari blok CIDR ini. Jika tidak, pemeriksaan kesehatan akan gagal dan menyebabkan gangguan layanan.Server utama/cadangan mengandalkan pemeriksaan kesehatan untuk failover:
Jika pemeriksaan kesehatan server utama gagal, lalu lintas dialihkan ke server cadangan. Secara default, server cadangan tidak menjalankan pemeriksaan kesehatan. Pastikan server cadangan tersedia agar failover berhasil.
Waktu failover untuk server utama/cadangan bergantung pada timeout respons pemeriksaan kesehatan yang dikonfigurasi. Lalu lintas secara otomatis kembali ke server utama setelah pemeriksaan kesehatannya pulih.
Ruang lingkup
Asosiasi:
Listener dan kelompok server merupakan resource tingkat instans CLB. Informasi listener dan kelompok server tidak dibagikan antar instans CLB yang berbeda.
Satu kelompok server dapat diasosiasikan dengan beberapa listener, tetapi satu listener hanya dapat diasosiasikan dengan satu kelompok server.
Listener Lapisan 4 CLB tidak mendukung instans ECS yang berperan sebagai server backend sekaligus client. Jika Anda memerlukan konfigurasi ini, gunakan listener Lapisan 7.
Menyambungkan server backend:
CLB hanya mendukung penyambungan server backend dari akun dan wilayah yang sama.
Instans CLB jaringan privat: Anda hanya dapat menyambungkan server backend yang berada dalam VPC yang sama dengan instans CLB.
Instans CLB jaringan publik: Jika Anda menambahkan beberapa server backend, semuanya harus berada dalam VPC yang sama.
Semua jenis kelompok server CLB mendukung penyambungan resource berikut: instans ECS, elastic network interface (ENI), dan Elastic Container Instance (ECI).
Anda hanya dapat menambahkan ENI yang sudah tersambung ke instans ECS. Anda dapat menambahkan baik Alamat IP pribadi utama maupun Alamat IP pribadi sekunder dari suatu ENI.
Ketika instans ECS yang berperan sebagai server backend menjalani migrasi panas, koneksi persisten ke CLB mungkin terputus. Koneksi akan pulih setelah reconnect. Pastikan aplikasi Anda memiliki mekanisme reconnect otomatis.
Konfigurabilitas:
Konfigurabilitas
Tambah/hapus kelompok server
Ubah port
Ubah bobot
Kelompok server default
Setelah Anda pertama kali membuat dan mengasosiasikan listener, port tidak dapat diubah.
Kelompok vServer
Kelompok server utama/cadangan
Peran utama/cadangan tidak dapat diubah.
Konfigurasi kelompok server
Konsol
Kelompok server default
Anda tidak perlu membuat kelompok server default. Setiap instans CLB sudah mencakup satu kelompok server default.
Tambahkan server:
Buka atau halaman manajemen instans CLB. Klik ID instans target. Pilih tab Default Server Group. Klik Add.
Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
Untuk menambahkan elastic network interface (ENI), aktifkan Advanced Mode. Klik ikon tanda plus di samping instans ECS yang memiliki ENI terkait. Temukan ENI target, pilih untuk bind, lalu pilih IP.
Konfigurasi port dan bobot:
Konfigurasi port: Pilih tab Listener. Klik Add Listener. Pada halaman wizard Backend Servers, atur Port untuk server dalam kelompok server default. Semua server dalam kelompok server default untuk listener yang sama harus menggunakan port yang sama.
Anda hanya dapat menentukan port saat menambahkan listener. Anda tidak dapat mengubahnya nanti.
Konfigurasi Weight untuk server yang dipilih.
Kelompok vServer
Buka atau halaman manajemen instans CLB. Klik ID instans target. Pilih vServer groups. Klik Create vServer Group.
Add server:
Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
Untuk menambahkan ENI, aktifkan Advanced Mode. Klik ikon tanda plus di samping instans ECS yang memiliki ENI terkait. Temukan ENI target. Pilih ENI untuk bind. Pilih IP.
Anda dapat mengonfigurasi Port dan Weight untuk server yang dipilih. Anda dapat memilih Add Port untuk mengonfigurasi beberapa port berbeda untuk server backend yang sama.
Kelompok server utama/cadangan
Buka atau halaman manajemen instans CLB. Klik ID instans target. Pilih Primary/Secondary Server Groups. Klik Create Primary/Secondary Server Group.
Add server:
Atur Server Type dan Resource Group untuk memfilter resource yang tersedia.
Untuk menambahkan ENI, aktifkan Advanced Mode. Klik ikon plus di samping instans ECS target. Pilih ENI untuk bind, lalu pilih IP.
Anda hanya dapat menambahkan dua server backend.
Konfigurasi port untuk server yang dipilih dengan mengklik Port. Untuk menambahkan beberapa port ke server backend yang sama, klik Add Port. Setelah menambahkan port, pilih Primary Server untuk mengonfigurasi 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, menambahkan server backend, serta mengonfigurasi port dan bobot.
Panggil AddVServerGroupBackendServers atau 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 atau kelompok vServer: Ya, Anda bisa. Anda dapat menambah atau mengurangi jumlah instans ECS backend kapan saja, serta mengganti antar instans ECS berbeda. Untuk memastikan stabilitas layanan, aktifkan pemeriksaan kesehatan sebelum melakukan operasi ini dan pastikan setidaknya satu instans ECS backend dalam kondisi sehat.
Kelompok server utama/cadangan: Tidak, Anda tidak bisa.
Apakah instans ECS backend dapat menjalankan sistem operasi yang berbeda?
Bisa berbeda.
CLB tidak membatasi sistem operasi yang digunakan oleh instans ECS backend, selama layanan aplikasi dan data konsisten di seluruh instans. Kami merekomendasikan penggunaan sistem operasi yang sama untuk menyederhanakan manajemen dan maintenance.
Apakah saya dapat menggunakan instans ECS dari wilayah berbeda sebagai server backend?
Tidak, Anda tidak bisa. CLB tidak mendukung asosiasi langsung server backend lintas wilayah. Untuk mencapai deployment lintas wilayah, Anda dapat menggunakan salah satu solusi berikut:
Deploy Global Traffic Manager (GTM) di depan beberapa instans CLB lintas wilayah. Untuk informasi lebih lanjut, lihat Global Traffic Manager.
Gunakan Application Load Balancer (ALB) atau Network Load Balancer (NLB), keduanya mendukung server backend lintas wilayah. Untuk informasi lebih lanjut, lihat Application Load Balancer ALB atau Network Load Balancer NLB.
Mengapa alamat IP yang dimulai dengan 100 sering mengakses instans ECS saya?
Permintaan ini berasal dari pemeriksaan kesehatan dan pemantauan ketersediaan CLB.
Sumber: Blok CIDR reservasi Alibaba Cloud
100.64.0.0/10.Keamanan: Blok CIDR ini dicadangkan untuk penggunaan internal Alibaba Cloud. Pengguna lain tidak dapat diberi alamat IP dalam rentang ini, sehingga tidak ada risiko keamanan.
Rekomendasi konfigurasi: Anda harus mengizinkan traffic dari blok CIDR ini di security group Anda untuk memastikan ketersediaan layanan.
Kompresi tidak dikonfigurasi pada instans ECS saya. Mengapa respons HTTP dari CLB dikompresi?
Penyebab: Kompresi Gzip diaktifkan dalam konfigurasi listener CLB, dan browser client mendukung kompresi.
Tindakan: Untuk menonaktifkan kompresi, Anda dapat mematikan fitur kompresi Gzip di konsol CLB saat mengonfigurasi listener, atau gunakan listener TCP sebagai gantinya.
Apakah instans ECS yang menggunakan HTTP 1.0 mendukung chunked transfer encoding?
Didukung.
Mengapa instans ECS backend CLB sering menerima permintaan dengan User-Agent 'KeepAliveClient'?
Gejala: Instans ECS backend menerima banyak permintaan GET dari alamat IP internal Alibaba Cloud, dengan User-Agent diatur ke
KeepAliveClient.Penyebab: Protokol listener adalah TCP, tetapi protokol pemeriksaan kesehatan adalah HTTP. Saat Anda menggunakan pemeriksaan kesehatan HTTP pada listener TCP, metode GET digunakan secara default.
Solusi: Gunakan protokol yang sama untuk listener dan pemeriksaan kesehatan, misalnya TCP untuk keduanya atau HTTP untuk keduanya.
Apakah saya dapat mengubah port server dalam kelompok server default?
Anda tidak dapat mengubahnya secara langsung.
Batasan: Anda hanya dapat mengatur port server untuk kelompok server default saat pertama kali membuat listener. Semua server backend dalam kelompok server default yang sama untuk listener tertentu harus menggunakan port yang sama.
Solusi: Untuk mengonfigurasi port server berbeda untuk listener yang sama, Anda dapat menggunakan kelompok vServer.
Apakah listener Lapisan 4 CLB mendukung instans ECS yang berperan sebagai server backend sekaligus client?
Tidak. Konfigurasi ini menyebabkan loop.
Sebagai gantinya, Anda dapat menggunakan salah satu opsi berikut:
Gunakan listener Lapisan 7 CLB (HTTP atau HTTPS).
Gunakan instans NLB dan nonaktifkan fitur Preserve Client IP untuk kelompok server NLB. Untuk informasi lebih lanjut, lihat Bagaimana cara mengonfigurasi instans NLB saya agar instans ECS dalam kelompok server dapat berfungsi sebagai server backend sekaligus client?.
Mengapa terdapat banyak koneksi TIME-WAIT pada backend CLB tetapi sedikit pada backend ALB?
CLB dan ALB menggunakan mekanisme koneksi berbeda saat berinteraksi dengan server backend.
CLB: Secara default menggunakan koneksi HTTP berumur pendek. Saat CLB meneruskan permintaan ke server backend, CLB menyisipkan field
Connection: closeke dalam header HTTP. Setelah server backend memproses permintaan, server tersebut secara aktif mengirim paket FIN untuk menutup koneksi berdasarkan header ini. Setiap kali koneksi ditutup, koneksi tersebut memasuki status TIME-WAIT (60 detik secara default). Dalam skenario konkurensi tinggi, banyak koneksi TIME-WAIT dapat terakumulasi dengan cepat.ALB: Secara default mendukung koneksi HTTP persisten (keep-alive). Satu koneksi TCP dapat digunakan ulang untuk memproses beberapa permintaan. Mengaktifkan koneksi persisten mengurangi jumlah pemutusan koneksi, sehingga mengurangi jumlah koneksi TIME-WAIT.
Mengapa traffic tidak terdistribusi merata di seluruh server backend?
Penyebab umum | Deskripsi | Pemecahan masalah dan penyelesaian |
Persistensi sesi | Saat persistensi sesi diaktifkan, permintaan dari client yang sama selalu dikirim ke server backend yang sama. Jika hanya sedikit client yang menghasilkan traffic, seperti saat uji stres dengan jumlah client kecil, traffic dapat terkonsentrasi hanya pada beberapa server. | Periksa apakah persistensi sesi diaktifkan dan pastikan apakah bisnis Anda memerlukannya. |
Koneksi persisten | Koneksi persisten yang sudah ada tidak didistribusikan ulang saat bobot diubah. Oleh karena itu, setelah Anda menyesuaikan bobot, distribusi traffic berubah secara perlahan. |
|
Kegagalan atau flapping pemeriksaan kesehatan | Beberapa server backend gagal pemeriksaan kesehatan dan berhenti menerima traffic. Atau, status kesehatannya sering berubah antara sehat dan tidak sehat, yang menyebabkan distribusi traffic tidak stabil. |
|
Volume permintaan keseluruhan rendah | Anda dapat memeriksa metrik pemantauan CLB. Jika jumlah total permintaan rendah, ketidakseimbangan kecil dalam distribusi traffic adalah hal yang normal. | Amati distribusi traffic setelah volume permintaan meningkat. Jika ketidakseimbangan tetap terjadi di bawah beban tinggi, Anda harus menyelidiki penyebab lainnya. |
Konfigurasi bobot salah | Bobot server tidak sesuai dengan kapasitas pemrosesan aktual. Akibatnya, beberapa server menjadi kelebihan beban sementara yang lain menganggur. |
|