Server Load Balancer：Algoritma penjadwalan SLB

Bagian ini menjelaskan algoritma penjadwalan yang didukung oleh SLB. Algoritma penjadwalan yang didukung oleh Application Load Balancer (ALB), Classic Load Balancer (CLB), dan Network Load Balancer (NLB) berbeda.

• ALB mendukung round-robin berbobot, koneksi paling sedikit berbobot, dan hashing konsisten berdasarkan alamat IP sumber dan URL.

• NLB mendukung round-robin, round-robin berbobot, koneksi paling sedikit berbobot, dan hashing konsisten berdasarkan alamat IP sumber, kombinasi empat elemen, dan ID QUIC.

• CLB mendukung round-robin, round-robin berbobot, dan hashing konsisten berdasarkan alamat IP sumber, kombinasi empat elemen, dan ID QUIC.

Round-robin

Ikhtisar

Algoritma round-robin mendistribusikan permintaan ke server backend secara bergantian. Round-robin umumnya diterapkan pada koneksi non-konsisten, seperti koneksi HTTP.

Sebagai contoh, jika dua Instance ECS berada dalam grup server backend, permintaan akan didistribusikan secara merata ke Instance ECS tersebut secara bergantian.

Keuntungan

1. Penjadwalan mudah: Round-robin adalah algoritma dasar untuk load balancing, mudah dipahami dan dikelola.

2. Kinerja tinggi: Round-robin mendistribusikan permintaan secara merata ke server backend untuk menyeimbangkan beban di antara server.

Kekurangan

1. Server diharapkan memiliki celah performa yang kecil. Round-robin tidak dapat menentukan beban real-time pada server backend. Jika performa server bervariasi secara signifikan, beberapa server mungkin kelebihan beban dan yang lain kurang beban.

2. Koneksi mungkin tetap terbuka untuk jangka waktu lama. Round-robin tidak dapat memprediksi periode waktu suatu koneksi akan digunakan. Jika koneksi tetap terbuka untuk waktu yang lama, waktu tunggu koneksi lain meningkat.

Skema penggunaan

1. Server dengan celah performa kecil: Jika celah performa di antara server kecil, round-robin dapat menyeimbangkan beban dengan efisiensi tinggi dengan mendistribusikan permintaan secara merata ke server.

2. Penjadwalan sederhana: Round-robin ideal untuk skenario yang tidak memerlukan deteksi beban real-time atau waktu koneksi pendek.

Round-robin berbobot

Ikhtisar

Algoritma round-robin berbobot dikembangkan dari algoritma round-robin tetapi memperhitungkan bobot server. Ini lebih efisien karena mendistribusikan permintaan berdasarkan bobot server. Server backend dengan bobot lebih tinggi menerima lebih banyak permintaan daripada server backend dengan bobot lebih rendah. Round-robin berbobot ideal untuk koneksi non-konsisten, seperti koneksi HTTP.

Sebagai contoh, dua Instance ECS berada dalam grup server backend dengan bobot 60 dan 40. Dalam hal ini, 60% permintaan didistribusikan ke Instance ECS dengan bobot 60, dan 40% permintaan didistribusikan ke Instance ECS dengan bobot 40.

Keuntungan

1. Fleksibilitas: Round-robin berbobot mendistribusikan permintaan berdasarkan bobot dan kapasitas server. Lebih banyak permintaan didistribusikan ke server dengan kapasitas lebih tinggi.

2. Load balancing: Round-robin berbobot memperhitungkan bobot setiap server saat menyeimbangkan beban di antara server.

Kekurangan

1. Konfigurasi kompleks: Round-robin berbobot mengharuskan Anda menentukan bobot untuk setiap server backend. Jika Anda memiliki sejumlah besar server backend atau layanan Anda memerlukan penyesuaian sering, pekerjaan konfigurasi dan O&M memakan waktu.

2. Pengaturan bobot yang tepat: Jika Anda menentukan bobot yang tidak tepat untuk server Anda, beban pada server mungkin tidak seimbang. Anda mungkin perlu sering menyesuaikan bobot server.

Skema penggunaan

1. Server dengan celah performa: Jika server Anda memiliki celah performa yang besar, Anda dapat menentukan bobot server untuk menyeimbangkan beban di antara server. Server dengan performa lebih tinggi dapat menerima lebih banyak permintaan.

2. Penjadwalan dinamis: Jika performa atau beban server Anda berfluktuasi, Anda dapat menyesuaikan bobot server secara dinamis untuk menahan beban.

3. Penjadwalan granular lebih baik: Jika Anda ingin mendistribusikan permintaan ke server Anda berdasarkan granularitas yang lebih baik, Anda dapat menetapkan bobot untuk setiap server untuk menentukan persentase permintaan yang akan didistribusikan ke setiap server.

Koneksi paling sedikit berbobot

Ikhtisar

Algoritma koneksi paling sedikit berbobot mendistribusikan permintaan berdasarkan bobot server dan memperhitungkan jumlah koneksi antara SLB dan server backend. Jika dua server backend memiliki bobot yang sama, server backend yang memiliki lebih sedikit koneksi menerima lebih banyak permintaan. Algoritma koneksi paling sedikit berbobot ideal untuk koneksi konsisten, seperti koneksi database.

Sebagai contoh, dua Instance ECS berada dalam grup server backend dengan bobot yang sama yaitu 100. Jika jumlah koneksi pada satu Instance ECS adalah 100 dan pada Instance ECS lainnya adalah 50, permintaan didistribusikan secara prioritas ke Instance ECS yang memiliki lebih sedikit koneksi.

Keuntungan

1. Penyesuaian dinamis: Koneksi paling sedikit berbobot dapat menyesuaikan penjadwalan permintaan secara dinamis berdasarkan jumlah koneksi secara real time dan bobot server. Permintaan didistribusikan ke server yang memiliki koneksi paling sedikit.

2. Kinerja tinggi dari load balancing: Algoritma koneksi paling sedikit berbobot memperhitungkan jumlah koneksi dan bobot setiap server. Ini mendistribusikan permintaan secara adil ke server untuk mencegah situasi kelebihan beban atau kurang beban.

Kekurangan

1. Perhitungan kompleks: Dibandingkan dengan round-robin dan round-robin berbobot, algoritma koneksi paling sedikit berbobot melakukan perhitungan yang lebih kompleks untuk membandingkan jumlah koneksi antara SLB dan server backend secara real time sebelum server dipilih.

2. Ketergantungan pada koneksi server: Algoritma koneksi paling sedikit berbobot mendistribusikan permintaan berdasarkan jumlah koneksi antara SLB dan server backend. Jika data pemantauan tidak akurat atau kedaluwarsa, permintaan mungkin tidak didistribusikan ke server dengan koneksi paling sedikit. Selain itu, algoritma koneksi paling sedikit berbobot hanya dapat memperoleh jumlah koneksi antara SLB dan server backend. Tidak dapat memperoleh jumlah total koneksi pada server. Jika server ditambahkan ke beberapa instance SLB, server mungkin kelebihan beban atau kurang beban.

3. Lonjakan beban karena server backend baru: Jika server backend baru ditambahkan ke instance SLB ketika jumlah koneksi yang ada besar, koneksi baru mungkin dijadwalkan ke server backend baru. Akibatnya, server backend baru mungkin kelebihan beban dan stabilitas sistem terganggu.

Skema penggunaan

1. Server dengan celah performa besar: Jika server Anda memiliki celah performa yang besar, Anda dapat menggunakan algoritma koneksi paling sedikit berbobot dan menentukan bobot server untuk menyeimbangkan beban di antara server Anda. Server dengan performa lebih tinggi menerima lebih banyak permintaan.

2. Penjadwalan dinamis: Jika jumlah koneksi dan beban pada server berubah, algoritma koneksi paling sedikit dapat menyesuaikan penjadwalan permintaan secara dinamis berdasarkan jumlah koneksi secara real time untuk menyeimbangkan beban di antara server.

3. Persyaratan tinggi untuk stabilitas: Jika Anda memerlukan respons real-time dan stabilitas sistem tinggi, Anda dapat menggunakan algoritma koneksi paling sedikit untuk mengurangi beban server dan meningkatkan stabilitas dan keandalan sistem.

Hashing konsisten

Ikhtisar

Algoritma hashing konsisten mendistribusikan permintaan secara merata di antara server backend berdasarkan faktor hash bahkan jika jumlah server backend berubah. Permintaan dengan nilai hash yang sama didistribusikan ke server backend yang sama.

Faktor hash meliputi:

• Alamat IP sumber: hashing berdasarkan alamat IP sumber. Permintaan dengan alamat IP sumber yang sama didistribusikan ke server backend yang sama.

• Empat elemen: hashing berdasarkan alamat IP sumber, port sumber, alamat IP tujuan, dan port tujuan. Permintaan dengan empat elemen yang sama didistribusikan ke server backend yang sama.

• ID QUIC: hashing berdasarkan ID QUIC. ID QUIC adalah pengenal unik koneksi QUIC. Hashing berdasarkan ID QUIC dapat menyeimbangkan beban di antara koneksi. Permintaan dengan ID QUIC yang sama didistribusikan ke server backend yang sama.

• String kueri URL: hashing berdasarkan string kueri URL. Permintaan dengan string kueri URL yang sama didistribusikan ke server backend yang sama.

Sebagai contoh, dua Instance ECS berada dalam grup server, dan permintaan terakhir didistribusikan ke ECS01. Jika permintaan saat ini memiliki nilai hash yang sama dengan permintaan terakhir, permintaan saat ini juga didistribusikan ke ECS01.

Keuntungan

1. Persistensi sesi: Hashing konsisten memastikan bahwa permintaan dengan nilai hash yang sama didistribusikan ke server backend yang sama untuk mempertahankan persistensi sesi. Algoritma hashing konsisten lebih disukai jika Anda perlu mempertahankan persistensi sesi atau menyimpan status penggunaan.

2. Load balancing: Hashing konsisten lebih efisien karena permintaan dengan nilai hash yang sama dapat didistribusikan ke server backend yang sama. Ini menyeimbangkan beban di antara server backend dengan efisiensi tinggi.

Kekurangan

1. Penjadwalan tidak seimbang karena perubahan server: Hashing konsisten memprioritaskan konsistensi permintaan jika server ditambahkan atau dihapus. Jika server diubah, beberapa permintaan dijadwalkan ulang. Jika jumlah server backend bertambah, lebih sedikit permintaan dijadwalkan ulang. Jika jumlah server backend berkurang, permintaan juga dijadwalkan ulang. Beban di antara server mungkin tidak seimbang.

2. Kompleksitas meningkat untuk ekspansi: Hashing konsisten menghitung nilai hash permintaan berdasarkan faktor hash. Jika server ditambahkan atau dihapus, beberapa permintaan mungkin dijadwalkan ulang. Ini meningkatkan kompleksitas aktivitas ekspansi server.

Skema penggunaan

1. Persistensi sesi: Jika aplikasi Anda perlu mempertahankan persistensi sesi atau menyimpan status pengguna, Anda dapat menggunakan hashing konsisten untuk mendistribusikan permintaan dengan nilai hash yang sama ke server backend yang sama.

2. Load balancing berperforma tinggi: Dalam skenario yang memiliki persyaratan tinggi untuk load balancing, hashing konsisten dapat mendistribusikan permintaan untuk menyeimbangkan beban di antara server.

3. Konsistensi data: Dalam skenario yang memerlukan konsistensi data, hashing konsisten dapat mempertahankan konsistensi data dengan mendistribusikan permintaan dengan nilai hash yang sama ke server backend yang sama.

Referensi

Untuk informasi lebih lanjut tentang ALB, NLB, dan CLB, lihat topik-topik berikut:

• Apa itu SLB?

• Apa itu ALB?

• Apa itu NLB?

• Apa itu CLB?