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.