Praktik Terbaik Penyeimbangan Beban untuk Ketekunan


8

Kami menjalankan aplikasi web yang menyajikan API web untuk semakin banyak klien. Untuk memulainya, klien pada umumnya adalah rumah, kantor, atau jaringan nirkabel lainnya yang mengirimkan unggahan http chunk ke API kami. Kami sekarang telah bercabang untuk menangani lebih banyak klien seluler. File-file mulai dari beberapa k hingga beberapa pertunjukan, dipecah menjadi potongan-potongan kecil dan disusun kembali di API kami.

Penyeimbangan beban kami saat ini dilakukan pada dua lapisan, pertama kami menggunakan round robin DNS untuk mengiklankan beberapa catatan A untuk alamat api.company.com kami. Di setiap IP, kami meng-host Linux LVS: http://www.linuxvirtualserver.org/ , load-balancer yang melihat alamat IP sumber dari permintaan untuk menentukan server API mana yang akan disambungkan ke koneksi. Kotak LVS ini dikonfigurasi dengan detak jantung untuk mengambil alih VIP eksternal dan IP gateway internal satu sama lain.

Akhir-akhir ini, kami telah melihat dua kondisi kesalahan baru.

Kesalahan pertama adalah ketika klien berosilasi atau bermigrasi dari satu LVS ke yang lain, unggahan tengah. Hal ini pada gilirannya menyebabkan penyeimbang beban kami kehilangan jejak koneksi yang persisten dan mengirimkan lalu lintas ke server API baru, sehingga memecah unggahan yang terpotong di dua atau lebih server. Tujuan kami adalah untuk nilai Round Robin DNS TTL untuk api.company.com kami (yang telah kami tentukan pada 1 jam) untuk dihormati oleh server nama caching hilir, lapisan cache OS, dan lapisan aplikasi klien. Kesalahan ini terjadi sekitar 15% dari unggahan kami.

Kesalahan kedua yang kita lihat jauh lebih jarang. Klien akan memulai lalu lintas ke kotak LVS dan diarahkan ke server realserver di belakangnya. Setelah itu, klien akan masuk melalui alamat IP sumber baru, yang tidak dikenali oleh kotak LVS, dengan demikian merutekan lalu lintas yang sedang berlangsung ke server realserver B juga di belakang LVS itu.

Mengingat arsitektur kami seperti yang dijelaskan pada bagian di atas, saya ingin tahu apa pengalaman orang-orang dengan pendekatan yang lebih baik yang akan memungkinkan kami untuk menangani masing-masing kasus kesalahan di atas dengan lebih anggun?

Sunting 5/3/2010:

Ini seperti yang kita butuhkan. Pengarsipan GSLB tertimbang pada alamat IP sumber.

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674


Pertanyaan Anda tidak terlalu spesifik untuk seluler saat ini. Mungkin Anda akan mempertimbangkan untuk merevisi dan menyederhanakannya?
Jesper M

Jawaban:


11

Solusi kanonik untuk ini adalah tidak bergantung pada alamat IP pengguna akhir, tetapi sebaliknya menggunakan penyeimbang beban Layer 7 (HTTP / HTTPS) dengan "Sesi Sticky" melalui cookie.

Sesi lengket berarti penyeimbang beban akan selalu mengarahkan klien yang diberikan ke server backend yang sama. Melalui cookie berarti penyeimbang beban (yang sendiri merupakan perangkat HTTP yang mampu sepenuhnya) menyisipkan cookie (yang pembuat penyeimbang beban buat dan kelola secara otomatis) untuk mengingat server backend mana yang harus digunakan koneksi HTTP.

Kelemahan utama dari sesi sticky adalah bahwa beckend server load menjadi agak tidak seimbang. Penyeimbang beban hanya dapat mendistribusikan beban secara adil ketika koneksi baru dibuat, tetapi mengingat bahwa koneksi yang ada mungkin berumur panjang dalam skenario Anda, maka dalam beberapa periode waktu beban tidak akan didistribusikan sepenuhnya secara adil.

Hampir setiap penyeimbang beban Layer 7 harus dapat melakukan ini. Di Unix / Linux, beberapa contoh umum adalah nginx, HAProxy, Apsis Pound, Apache 2.2 dengan mod_proxy, dan banyak lagi. Pada Windows 2008+ ada Routing Permintaan Aplikasi Microsoft. Seperti peralatan, Coyote Point, loadbalancer.org, Kemp dan Barracuda adalah hal biasa di ruang kelas bawah; dan F5, Citrix NetScaler dan lainnya di kelas atas.

Willy Tarreau, penulis HAProxy, memiliki tinjauan yang bagus tentang teknik load balancing di sini .

Tentang Robin Round DNS:

Tujuan kami adalah untuk nilai Round Robin DNS TTL untuk api.company.com kami (yang telah kami tentukan pada 1 jam) untuk dihormati oleh server nama caching hilir, lapisan cache OS, dan lapisan aplikasi klien.

Itu tidak akan terjadi . Dan DNS Round Robin tidak cocok untuk load balancing . Dan jika tidak ada yang meyakinkan Anda, perlu diingat bahwa klien modern mungkin lebih suka satu host daripada yang lain karena menyematkan pencocokan awalan terpanjang , jadi jika klien seluler mengubah alamat IP, mungkin memilih untuk beralih ke host RR lain.

Pada dasarnya, boleh saja menggunakan round round DNS sebagai distribusi beban kasar, dengan mengarahkan 2 atau lebih catatan RR ke alamat IP yang sangat tersedia, ditangani oleh penyeimbang beban nyata dalam HA aktif / pasif atau aktif / aktif. Dan jika itu yang Anda lakukan, maka Anda mungkin juga melayani catatan DNS RR dengan nilai Time To Live yang lama, karena alamat IP yang terkait sudah sangat tersedia.


Terima kasih. Kami berada dalam mode Aktif / Aktif dengan LVS. IP sangat tersedia dan kami memiliki banyak kendali atas klien saat kami menulisnya sendiri dan mereka bergantung pada server API kami yang tidak sepenuhnya tanpa kewarganegaraan seperti dijelaskan di atas. Saya menguji masalah caching level OS pada kotak Linux saya di tempat kerja (tidak ada caching dihidupkan) serta laptop Mac OSX saya di rumah (cache di lapisan OS, yang "menyematkan" IP ke satu hasil atau yang lain ).
dmourati

Saya akhirnya menulis server DNS khusus saya sendiri untuk memperbaiki masalah round robin. Itu terlihat pada alamat IP sumber dan menggunakan hash untuk membalas dengan catatan yang konsisten. Tampaknya berfungsi dan mengurangi masalah "sakelar pop" kami dengan faktor 10.
dmourati

4

Untuk menjawab pertanyaan Anda tentang alternatif: Anda bisa mendapatkan load balancing layer-7 solid melalui HAProxy .

Sejauh memperbaiki masalah afinitas LVS, saya agak kering pada ide-ide yang solid. Ini bisa sesederhana timeout atau overflow. Beberapa klien seluler akan berpindah alamat IP saat mereka terhubung ke jaringan; mungkin ini mungkin sumber kesengsaraan Anda? Saya akan menyarankan, paling tidak, bahwa Anda menyebarkan granularity afinitas ke setidaknya kelas C.


HAProxy benar-benar dalam pandangan saya. Saya membaca artikel yang cukup menarik tentang L4 v L7 load balancing. blog.loadbalancer.org/why-layer-7-sucks Saya ambil: Saya ingin meninggalkan ini di tangan aplikasi. "Kecerdasan" tambahan apa pun yang saya tambahkan ke lapisan LB hanya perlu ditambal / dibaca saat kita mengubah aplikasi kita. Memecahkan masalah dalam aplikasi itu sendiri berarti kita dapat mengoptimalkan dan menyempurnakan hal-hal di LB sambil tetap yakin bahwa bahkan jika ada kesalahan langkah LB kita masih akan mendapatkan data.
dmourati

@dmourati: Maaf, tetapi posting blog itu penuh dengan asumsi yang tidak akurat. Jangan membabi buta mengikutinya. Benar-benar benar bahwa arsitektur "tidak berbagi" untuk server aplikasi web adalah 'terbaik'. Dalam hal ini, Anda harus menggunakan Round Robin atau Random load balancing. Tetapi, selama Anda memiliki unggahan HTTP multi-GB, Anda memiliki percakapan HTTP yang bertahan lama, dan penyeimbang beban HTTP adalah posisi yang lebih baik untuk memahami pertukaran HTTP yang panjang ini dan bertindak dengan benar. Menggunakan penyeimbang HTTP tidak menghalangi membuat kode aplikasi backend Anda 'lebih pintar', Anda masih bebas melakukannya kapan saja.
Jesper M
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.