Round robin tertimbang melalui TTL - mungkin?

Saat ini saya menggunakan round robin DNS untuk load balancing, yang bekerja sangat baik. Catatan terlihat seperti ini (Saya punya TTL 120 detik)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Saya belajar bahwa tidak setiap ISP / perangkat memperlakukan respons seperti itu dengan cara yang sama. Misalnya beberapa server DNS memutar alamat secara acak atau selalu memutarnya. Beberapa hanya menyebarkan entri pertama, yang lain mencoba untuk menentukan mana yang terbaik (dekat secara regional) dengan melihat alamat IP.

Namun jika basis pengguna cukup besar (tersebar di beberapa ISP, dll.) Keseimbangannya cukup baik. Perbedaan dari server bermuatan tertinggi ke terendah hampir tidak setiap melebihi 15%.

Namun sekarang saya memiliki masalah bahwa saya memperkenalkan lebih banyak server ke dalam sistem, dan tidak semua memiliki kapasitas yang sama.

Saat ini saya hanya memiliki 1 server Gbps, tetapi saya ingin bekerja dengan 100 Mbps dan juga server 10 Gbps.

Jadi yang saya inginkan adalah saya ingin memperkenalkan server dengan 10 Gbps dengan berat 100, server 1 Gbps dengan berat 10 dan server 100 Mbps dengan bobot 1.

Saya sebelumnya menambahkan server dua kali untuk membawa lebih banyak lalu lintas ke mereka (yang bekerja dengan baik — bandwidth hampir dua kali lipat). Tetapi menambahkan server 10 Gbps 100 kali ke DNS agak konyol.

Jadi saya berpikir untuk menggunakan TTL.

Jika saya memberikan server A 240 detik TTL dan server B hanya 120 detik (yaitu sekitar minimum untuk digunakan untuk round robin, karena banyak server DNS diatur ke 120 jika TTL yang lebih rendah ditentukan (jadi saya dengar)). Saya pikir sesuatu seperti ini harus terjadi dalam skenario ideal:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Seperti yang Anda lihat ini menjadi sangat rumit untuk diprediksi dan pasti tidak akan berhasil seperti ini dalam praktiknya. Tapi itu pasti berpengaruh pada distribusi!

Saya tahu bahwa round robin tertimbang ada dan hanya dikendalikan oleh server root. Itu hanya siklus melalui catatan DNS ketika merespons dan mengembalikan catatan DNS dengan probabilitas yang ditetapkan sesuai dengan bobot. Server DNS saya tidak mendukung ini, dan persyaratan saya tidak tepat. Jika beratnya tidak sempurna, tidak apa-apa, tetapi harus mengarah ke arah yang benar.

Saya pikir menggunakan bidang TTL bisa menjadi solusi yang lebih elegan dan lebih mudah — dan itu tidak memerlukan server DNS yang mengontrol ini secara dinamis, yang menghemat sumber daya — yang menurut saya merupakan titik utama dari penyeimbangan beban DNS vs penyeimbang beban perangkat keras.

Pertanyaan saya sekarang adalah: Apakah ada praktik terbaik / metode / aturan praktis untuk distribusi round robin menggunakan atribut TTL dari catatan DNS?

Edit:

Sistem ini adalah sistem server proxy yang maju. Jumlah Bandwidth (bukan permintaan) melebihi apa yang bisa ditangani oleh satu server tunggal dengan Ethernet. Jadi saya butuh solusi penyeimbangan yang mendistribusikan bandwidth ke beberapa server. Apakah ada metode alternatif selain menggunakan DNS? Tentu saja saya bisa menggunakan penyeimbang beban dengan saluran serat dll, tetapi biayanya konyol dan juga hanya menambah lebar kemacetan dan tidak menghilangkannya. Satu-satunya hal yang dapat saya pikirkan adalah anycast (apakah anycast atau multicast?) Alamat IP, tetapi saya tidak memiliki sarana untuk mengatur sistem seperti itu.

Pertama, saya sepenuhnya setuju dengan @Alnitak bahwa DNS tidak dirancang untuk hal semacam ini, dan praktik terbaik adalah tidak (ab) menggunakan DNS sebagai penyeimbang beban orang miskin.

Pertanyaan saya sekarang adalah ... apakah ada prectices / methos / aturan terbaik untuk distribusi round robin menggunakan atribut TTL dari catatan DNS?

Untuk menjawab pada premis pertanyaan, pendekatan yang digunakan untuk melakukan round robin rounded basix menggunakan DNS adalah dengan:

• Sesuaikan kemunculan relatif catatan dalam respons DNS otoritatif. Yaitu jika Server Aingin memiliki 1/3 dari lalu lintas dan Server Buntuk memiliki 2/3, maka 1/3 dari tanggapan DNS otoritatif untuk proxy DNS hanya akan berisi AIP, dan 2/3 dari respon hanya BIP. (Jika 2 atau lebih server berbagi 'bobot' yang sama, maka mereka dapat digabungkan menjadi satu respons.)
• Pertahankan DNS TTL yang rendah agar beban yang tidak seimbang diratakan dengan relatif cepat. Karena proksi DNS hilir memiliki jumlah klien yang sangat tidak merata di belakang mereka, Anda ingin mengacak-acak catatan secara sering.

Layanan DNS Route 53 Amazon menggunakan metode ini .

Jumlah Bandwidth (bukan permintaan) melebihi apa yang bisa ditangani oleh satu server tunggal dengan ethernet. Jadi saya butuh solusi penyeimbangan yang mendistribusikan bandwidth ke beberapa server.

Baik. Jadi, seperti yang saya pahami, Anda memiliki semacam layanan unduhan / distribusi video / unduhan file 'murah', di mana total bitrate layanan melebihi 1 GBit.

Tanpa mengetahui spesifikasi pasti dari layanan Anda dan tata letak server Anda, sulit untuk menjadi tepat. Tapi sebuah solusi umum dalam hal ini adalah:

• DNS round robin ke dua atau lebih instance TCP / IP atau HTTP level load balancer.
• Setiap instance penyeimbang beban sangat tersedia (2 penyeimbang beban identik bekerja sama menjaga satu alamat IP selalu aktif).
• Setiap instance penyeimbang beban menggunakan round robin tertimbang atau penanganan koneksi acak tertimbang ke server backend.

Pengaturan semacam ini dapat dibangun dengan perangkat lunak sumber terbuka, atau dengan perangkat yang dibuat khusus dari banyak vendor. The load balancing tag di sini adalah titik awal yang bagus, atau Anda bisa menyewa sysadmin yang telah melakukan ini sebelumnya untuk berkonsultasi untuk Anda ...

Pertanyaan saya sekarang adalah ... apakah ada prectices / methos / aturan terbaik untuk distribusi round robin menggunakan atribut TTL dari catatan DNS?

Ya, praktik terbaik adalah jangan lakukan itu !!

Silakan ulangi setelah saya

• DNS bukan untuk penyeimbangan beban
• DNS tidak memberikan ketahanan
• DNS tidak menyediakan fasilitas fail-over

DNS adalah untuk memetakan nama ke satu atau lebih alamat IP . Setiap penyeimbangan berikutnya yang Anda dapatkan adalah melalui keberuntungan, bukan desain.

Lihatlah PowerDNS . Hal ini memungkinkan Anda untuk membuat backend pipa kustom. Saya telah memodifikasi contoh backend DNS penyeimbang beban yang ditulis dalam perl untuk menggunakan modul Algoritma :: ConsistentHash :: Ketama. Ini memungkinkan saya mengatur bobot acak seperti:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

Dan satu lagi:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

Saya telah menambahkan cname dari domain tingkat atas yang saya inginkan ke subdoman yang saya sebut gslb, atau Global Server Load Balancing. Dari sana, saya memanggil server DNS khusus ini dan mengirimkan catatan A sesuai dengan bobot yang saya inginkan.

Bekerja seperti jagoan. Hash ketama memiliki properti bagus gangguan minimal untuk konfigurasi yang ada saat Anda menambahkan server atau menyesuaikan bobot.

Saya sarankan membaca Server DNS Alternatif, oleh Jan-Piet Mens. Dia punya banyak ide bagus di sana dan juga contoh kode.

Saya juga merekomendasikan meninggalkan modulasi TTL. Anda sudah cukup jauh dan menambahkan kludge di atas akan membuat pemecahan masalah dan dokumentasi menjadi sangat sulit.

Anda dapat menggunakan PowerDNS untuk melakukan round robin tertimbang, meskipun mendistribusikan beban dengan cara yang tidak seimbang (100: 1?) Mungkin menjadi sangat menarik, setidaknya dengan algoritma yang saya gunakan dalam solusi saya, di mana setiap entri RR memiliki bobot yang terkait dengannya , antara 1-100, dan nilai acak digunakan untuk memasukkan atau mengecualikan catatan.

Berikut ini adalah artikel yang saya tulis tentang menggunakan backend MySQL di PowerDNS untuk melakukan DNS RR tertimbang: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar juga memiliki beberapa contoh berbasis Ruby (menggunakan backend pipa PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Untuk menghadapi pengaturan semacam ini, Anda perlu melihat solusi penyeimbangan beban nyata. Baca Linux Virtual Server dan HAProxy . Anda mendapatkan manfaat tambahan dari server yang secara otomatis dihapus dari kolam jika mereka gagal dan efeknya jauh lebih mudah dipahami. Pembobotan hanyalah pengaturan yang harus diubah.