Apakah ada saran tentang kapan saya harus menggunakan roundrobin& kapan saya harus menggunakan leastconn?
Saya menggunakan roundrobinsaat ini dan mengamati pemuatan serve back-end saya tidak merata. Tentu saja mungkin ada masalah lain, tetapi kami ingin leastconnmencoba, tetapi karena ini adalah server mission mission, saya ingin berkonsultasi dengan pengalaman lain sebelum melakukan perubahan.
Ada ide untuk dibagikan?
Jawaban:
Saya belum bereksperimen dengan leastconn, tetapi pemahaman saya adalah bahwa use case yang umum untuk leastconn adalah ketika Anda menyeimbangkan sesuatu yang dapat memiliki koneksi yang tahan lama. Alasan untuk ini adalah bahwa leastconn fokus pada memastikan konkurensi seimbang di mana road robin akan memberikan tingkat kedatangan yang lebih seimbang . Jika perbedaan ini tidak jelas, lihat jawaban saya tentang perbedaannya .
Ketika Anda mengatakan bahwa muatannya tidak terdistribusi secara merata, mungkin membantu untuk mendefinisikan "memuat" sedikit lebih baik. Jika Anda maksud sumber daya server, daripada saya sarankan mengidentifikasi apa sebenarnya yang menyebabkan peningkatan beban (yaitu jenis koneksi tertentu) dan bekerja mundur dari sana.
Itu tergantung pada apa protokol dan use case untuk menyeimbangkan. Untuk apa pun di mana jumlah koneksi berkorelasi dengan beban / penggunaan, lebih baik digunakan leastconn. Karena cara kerja jaringan dan aplikasi, itu hampir selalu benar dan Anda lebih baik menggunakan leastconnsecara default.
Misalnya, perusahaan memiliki kumpulan desktop jarak jauh yang terhubung dengan karyawan. Anda ingin karyawan didistribusikan agak merata di seluruh desktop.
Jumlah koneksi aktif dalam use case kira-kira "berapa banyak karyawan yang menggunakan desktop itu sekarang". Tuan rumah dengan koneksi paling sedikit memiliki karyawan paling sedikit menggunakannya dan mungkin itu yang paling sedikit dimuat. Gunakan "leastconn" dalam keadaan ini, itu menyebarkan beban secara merata dengan jumlah pengguna.
Penyeimbang beban yang ideal harus mengetahui beban desktop jarak jauh. Berapa banyak pengguna? Berapa banyak aplikasi? Berapa banyak memori dan CPU yang dikonsumsi? Ada solusi komersial yang didedikasikan untuk desktop jarak jauh (Microsoft / Citrix / dll ...), mereka biasanya mengukur metrik ini untuk menyebarkan penggunaan dengan sangat baik. HAProxy adalah penyeimbang beban jaringan yang sederhana dan tidak bisa melakukan lebih baik daripada menghitung koneksi dengan leastconn.
Dengan HTTP, koneksi aktif berarti bahwa server sedang sibuk memproses permintaan. Koneksi berbanding lurus dengan beban. Anda ingin memilih server dengan paling sedikit koneksi aktif (permintaan sedang berlangsung). Gunakan leastconnuntuk lalu lintas HTTP (S).
Bayangkan sebuah skenario dengan dua server HTTP, di mana satu server lebih lambat untuk memproses permintaan (mungkin itu kelebihan beban, mungkin memiliki perangkat keras yang lebih tua).
roundrobinakan mendistribusikan permintaan setengah-setengah antara dua server. Ini sangat tidak efisien, server yang lebih cepat harus mengambil lebih banyak. Lebih buruk lagi, server yang lebih lambat bisa kelebihan beban, itu akan semakin lambat karena lebih banyak permintaan masuk dan bisa mulai menjatuhkan permintaan kapan saja. Anda tidak menginginkan itu.
leastconnakan mendeteksi bahwa server tidak merata. Server yang lebih lambat menahan koneksi lebih lama, ia memiliki jumlah koneksi yang lebih tinggi. leastconnakun untuk itu dan lebih suka server lain.
Dalam pengalaman saya, termasuk peran di mana saya secara eksklusif melakukan pengujian kinerja untuk situs web sedang hingga besar. leastconndapat 300% seefisien roundrobinHTTP (S). roundrobintidak mendistribusikan koneksi secara adil dan itu akan menyebabkan ketidakstabilan pada beban tinggi.
(Mari kita abaikan bahwa HAProxy tidak mendukung UDP dan UDP adalah koneksi yang kurang).
Satu contoh terakhir. DNS adalah protokol sederhana. Klien mengirim satu pesan UDP untuk meminta domain dan server DNS membalas dalam satu pesan.
Dalam hal ini, sebenarnya tidak ada koneksi. Kalaupun ada, itu akan langsung ditutup (secara teoritis).
Tidak masuk akal untuk menghitung koneksi dalam keadaan ini, itu tidak optimal untuk leastconn. Sederhana roundrobindapat mendistribusikan pesan.
Orang terkadang percaya bahwa mereka tidak boleh digunakan leastconnuntuk koneksi yang berumur pendek (mirip dengan contoh terakhir). Bahkan dokumentasi HAProxy menyesatkan tentang itu.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
Di dunia nyata, short connectionsbukanlah hal.
Aplikasi dibangun di atas TCP. Pesan dikirim dan sering diproses secara berurutan. Ketika server lambat atau kelebihan beban, koneksi "pendek" menjadi lebih lama. Jika ada (lebih banyak) koneksi, mungkin ada beberapa (lebih) pekerjaan yang dilakukan. Jumlah koneksi dan durasi koneksi bervariasi dan memiliki makna.
Pikirkan server HTTP dasar. Beberapa aset memerlukan waktu beberapa milidetik, beberapa panggilan API membutuhkan waktu beberapa detik, satu halaman dapat mengambil waktu kapan saja untuk memuat dengan jumlah permintaan di dalamnya, dll. Permintaan tidak berumur pendek, seumur hidup mereka mengikuti apa yang sedang diproses di server mana. leastconnmemahami aktivitas yang sedang berlangsung dan menyesuaikan distribusi, yang persis seperti yang Anda inginkan dari penyeimbang beban.