Pertanyaan Beberapa pusat data dan lalu lintas HTTP: DNS Round Robin adalah SATU-SATUNYA cara untuk memastikan kegagalan instan?


Beberapa catatan A menunjuk ke domain yang sama tampaknya digunakan hampir secara eksklusif untuk menerapkan DNS Round Robin sebagai teknik load balancing murah.

Peringatan biasa terhadap DNS RR adalah bahwa ini tidak baik untuk ketersediaan tinggi. Ketika 1 IP turun, klien akan terus menggunakannya selama beberapa menit.

Penyeimbang beban sering disarankan sebagai pilihan yang lebih baik.

Kedua klaim itu tidak sepenuhnya benar:

  1. Ketika lalu lintas adalah HTTP, sebagian besar peramban HTML dapat secara otomatis mencoba A record berikutnya jika sebelumnya tidak aktif, tanpa pencarian DNS baru. Baca baca disini bab 3.1 dan sini.

  2. Ketika beberapa pusat data terlibat kemudian, DNS RR adalah satu-satunya pilihan untuk mendistribusikan lalu lintas di antara mereka.

Jadi, apakah benar bahwa, dengan beberapa pusat data dan lalu lintas HTTP, penggunaan DNS RR adalah cara HANYA untuk memastikan kegagalan instan ketika satu pusat data turun?

Terima kasih,

Valentino

Edit:

  • Tentu saja setiap pusat data memiliki Load Balancer lokal dengan cadangan panas.
  • Tidak apa-apa mengorbankan kesetiaan sesi untuk kegagalan instan.
  • AFAIK satu-satunya cara bagi DNS untuk menyarankan pusat data daripada yang lain adalah membalas hanya dengan IP (atau IP) yang terkait dengan pusat data tersebut. Jika pusat data menjadi tidak dapat dijangkau maka semua IP tersebut juga tidak terjangkau. Ini berarti bahwa, bahkan jika peramban HTML pintar dapat langsung mencoba rekaman A lainnya, semua upaya akan gagal hingga entri cache lokal kedaluwarsa dan pencarian DNS baru dilakukan, mengambil IP kerja yang baru (saya berasumsi bahwa DNS secara otomatis menyarankan ke pusat data baru ketika salah satu gagal). Jadi, "DNS cerdas" tidak dapat menjamin kegagalan instan.
  • Sebaliknya, DNS round-robin mengijinkannya. Ketika satu pusat data gagal, peramban HTML cerdas (kebanyakan dari mereka) langsung mencoba catatan C tembolok lainnya yang melompat ke pusat data lain (yang berfungsi). Jadi, DNS round-robin tidak menjamin afinitas sesi atau RTT terendah tetapi tampaknya menjadi satu-satunya cara untuk memastikan kegagalan instan ketika klien adalah peramban HTML "pintar".

Edit 2:

  • Beberapa orang menyarankan TCP Anycast sebagai solusi definitif. Di ini kertas (Bab 6) dijelaskan bahwa Anycast gagal-over terkait dengan konvergensi BGP. Untuk alasan ini Anycast dapat menggunakan dari 15 menit hingga 20 detik untuk menyelesaikannya. 20 detik dimungkinkan pada jaringan di mana topologi dioptimalkan untuk ini. Mungkin hanya operator CDN yang dapat memberikan fail-overs yang cepat.

Sunting 3: *

  • Saya melakukan beberapa pencarian DNS dan traceroute (mungkin beberapa ahli dapat memeriksa ulang) dan:
    • Satu-satunya CDN yang menggunakan TCP Anycast tampaknya CacheFly, operator lain seperti jaringan CDN dan BitGravity menggunakan CacheFly. Tampaknya ujung-ujungnya tidak dapat digunakan sebagai proxy terbalik. Oleh karena itu, mereka tidak dapat digunakan untuk memberikan failover instan.
    • Akamai dan LimeLight tampaknya menggunakan DNS geo-aware. Tapi! Mereka mengembalikan banyak catatan A. Dari traceroute tampak bahwa IP yang dikembalikan berada di pusat data yang sama. Jadi, saya bingung bagaimana mereka dapat menawarkan SLA 100% ketika satu pusat data turun.

76
2017-09-30 08:44




Dengan ketersediaan tinggi saya tersirat hampir gagal instan. Klien seharusnya tidak melihat masalah apa pun bahkan jika satu pusat data turun. Saya memperbaiki pertanyaan itu. - Valentino Miazzo
MaxCDN menggunakan anycast TCP dan ujungnya dapat digunakan dalam mode proxy caching ("origin fetch" dalam terminologi industri CDN). - rmalayter
@vmiazzo, tautan pdf Anda turun ... Maksud Anda 15 menit atau 20 detik hingga 15 menit? - Pacerier


Jawaban:


Ketika saya menggunakan istilah "DNS Round Robin" saya biasanya bermaksud dalam arti "teknik load balancing murah" sebagai OP menggambarkannya.

Tapi itu bukan satu-satunya cara DNS dapat digunakan untuk ketersediaan tinggi global. Sering kali, sulit bagi orang-orang dengan latar belakang teknologi yang berbeda untuk berkomunikasi dengan baik.

Teknik load balancing terbaik (jika uang bukan masalah) umumnya dianggap:

  1. Jaringan global anycast'ed server DNS 'cerdas',
  2. dan satu set pusat data yang tersebar di seluruh dunia,
  3. di mana setiap node DNS mengimplementasikan Split Horizon DNS,
  4. dan pemantauan ketersediaan dan arus lalu lintas tersedia untuk node DNS 'cerdas' dalam beberapa mode,
  5. supaya itu permintaan DNS pengguna mengalir ke server DNS terdekat melalui IP Anycast,
  6. dan ini Server DNS memberikan TTL A Record / set A Record untuk terdekat / terbaik Pusat Data untuk pengguna akhir ini melalui DNS cakrawala split 'cerdas'.

Menggunakan anycast untuk DNS umumnya baik-baik saja, karena respons DNS tidak memiliki negara dan hampir sangat pendek. Jadi, jika rute BGP berubah, itu sangat tidak mungkin mengganggu permintaan DNS.

Anycast kurang cocok untuk percakapan HTTP yang lebih panjang dan lengkap, sehingga sistem ini menggunakan split horizon DNS. Sesi HTTP antara klien dan server disimpan ke satu pusat data; itu umumnya tidak dapat gagal ke pusat data lain tanpa melanggar sesi.

Seperti yang saya sebutkan dengan "set A Records" apa yang saya sebut 'DNS Round Robin' dapat digunakan bersama dengan pengaturan di atas. Ini biasanya digunakan untuk menyebarkan beban trafik ke banyak load balancer yang tersedia di setiap pusat data (sehingga Anda bisa mendapatkan redundansi yang lebih baik, menggunakan load balancer yang lebih kecil / lebih murah, tidak membanjiri buffer jaringan Unix dari server host tunggal, dll).

Jadi, apakah benar, dengan banyak pusat data   dan lalu lintas HTTP, penggunaan DNS RR adalah HANYA   cara untuk memastikan ketersediaan tinggi?

Tidak, itu tidak benar, tidak jika oleh 'DNS Round Robin' kami hanya berarti membagi-bagikan beberapa catatan A untuk domain. Tapi memang benar bahwa penggunaan DNS yang cerdas adalah komponen penting dalam sistem ketersediaan tinggi global. Di atas mengilustrasikan satu cara umum (sering kali terbaik) untuk pergi.

Edit: Makalah Google "Bergerak di Luar Informasi Jalur End-to-End untuk Mengoptimalkan Kinerja CDN" bagi saya adalah state-of-the-art dalam distribusi beban global untuk kinerja pengguna akhir terbaik.

Edit 2: Saya membaca artikelnya "Mengapa Berbasis DNS .. GSLB .. Tidak berfungsi" yang terkait dengan OP, dan ini adalah ikhtisar yang bagus - Saya sarankan untuk melihatnya. Baca dari atas.

Di bagian "Solusi untuk masalah cache peramban" ini mendukung tanggapan DNS dengan banyak A Records yang menunjuk ke banyak pusat data sebagai satu-satunya solusi yang mungkin untuk gagal secara instan.

Pada bagian "Watering it down" di dekat bagian bawah, itu memperluas pada yang jelas, bahwa mengirim beberapa A Records tidak keren jika mereka menunjuk pusat data di beberapa benua, karena klien akan terhubung secara acak dan dengan demikian cukup sering mendapatkan 'lambat' DC di benua lain. Oleh karena itu untuk bekerja dengan sangat baik, beberapa pusat data di setiap benua diperlukan.

Ini adalah solusi yang berbeda dari langkah saya 1 - 6. Saya tidak bisa memberikan jawaban yang sempurna untuk ini, saya pikir seorang spesialis DNS dari orang-orang seperti Akamai atau Google diperlukan, karena banyak dari ini bermuara pada pengetahuan praktis pada keterbatasan cache dan browser DNS yang digunakan saat ini. AFAIK, langkah saya 1-6 adalah apa yang dilakukan Akamai dengan DNS mereka (siapa pun dapat mengonfirmasi ini?).

Perasaan saya - datang dari bekerja sebagai PM di portal browser mobile (ponsel) - adalah bahwa keragaman dan tingkat kehancuran total dari peramban di luar sana luar biasa. Saya pribadi tidak akan mempercayai solusi HA yang membutuhkan terminal pengguna akhir untuk 'melakukan hal yang benar'; jadi saya percaya bahwa global instan gagal tanpa melanggar sesi tidak layak hari ini.

Saya pikir langkah saya 1-6 di atas adalah yang terbaik yang tersedia dengan teknologi komoditas. Solusi ini tidak gagal secara instan.

Saya akan senang untuk salah satu spesialis DNS dari Akamai, Google dll untuk datang dan membuktikan saya salah. :-)


34
2017-09-30 10:56



Saya menambahkan lebih banyak penjelasan dalam pertanyaan itu. Jika saya memahami "teknik load balancing terbaik" Anda (poin 6), ia hanya mengiklankan catatan A dari pusat data 'terbaik'. Ketika saya mencoba untuk menjelaskan dalam pertanyaan ini tidak memungkinkan kegagalan instan pada klien. - Valentino Miazzo
@vmiazzo: Ya, Anda mengerti saya dengan benar. Saya menambahkan pengeditan kedua ke posting saya untuk memperjelas - tetapi pada dasarnya saya pikir gagal instan atas yang Anda cari tidak praktis / tidak mungkin. - Jesper Mortensen
Apa yang saya temukan menarik adalah bahwa tidak ada yang menyarankan menggabungkan dua pendekatan bersama. Meskipun tidak ideal, itu akan memberikan kecepatan yang wajar ketika sesuatu berfungsi dengan benar, dan ketahanan tambahan ketika mereka tidak. Hukuman akan menjadi penundaan besar karena klien beralih dari satu alamat DNS berbasis-aliran ke yang lain. - Avery Payne
@JesperMortensen, Ketika Anda mengatakan DNS 'cerdas', maksud Anda adalah split-horizon DNS? Atau maksud Anda yang lain (memutuskan berdasarkan faktor luar sumber IP)? - Pacerier


Pertanyaan Anda adalah: "Apakah DNS Round Robin adalah satu-satunya cara untuk memastikan kegagalan instan?"

Jawabannya adalah: "DNS Round Robin adalah TAK PERNAH cara yang benar untuk memastikan kegagalan instan ".

(setidaknya tidak sendiri)

Cara yang benar untuk mencapai kegagalan instan adalah dengan menggunakan routing BGP4 sedemikian rupa sehingga kedua situs menggunakan alamat IP yang sama. Menggunakan inti internet ini rute teknologi digunakan untuk rute permintaan ke pusat data yang benar, daripada menggunakan inti internet berbicara teknologi.

Dalam konfigurasi paling sederhana ini hanya menyediakan fail-over. Ini juga dapat digunakan untuk menyediakan Anycast, dengan peringatan bahwa protokol berbasis TCP akan gagal pada saat switch-over jika ada ketidakstabilan dalam routing.


18
2017-09-30 16:04



Menambahkan beberapa info tentang Anycast failover pada pertanyaan. Pada dasarnya juga TCP Anycast bukanlah solusi sempurna. - Valentino Miazzo
@vmiazzo re TCP Anycast - memang, maka catatan dalam jawaban saya tentang ketidakstabilan routing dan bagaimana hal itu mempengaruhi TCP. - Alnitak


Jadi, apakah benar bahwa, dengan beberapa pusat data dan lalu lintas HTTP, penggunaan DNS RR adalah cara HANYA untuk menjamin ketersediaan tinggi?

Jelas itu adalah klaim yang salah - Anda hanya perlu melihat Google, Akamai, Yahoo, untuk melihat bahwa mereka tidak menggunakan round-robin [*] sebagai solusi satu-satunya (beberapa mungkin menggunakannya sebagian, bersama dengan pendekatan lain) .)

Ada banyak opsi yang memungkinkan, tetapi itu benar-benar tergantung pada kendala apa yang Anda miliki, dengan layanan / aplikasi Anda yang Anda pilih.

Adalah mungkin untuk menggunakan teknik round-robin pada pendekatan server yang sederhana dan ditempatkan bersama, dan tidak perlu khawatir tentang kegagalan server, jika Anda juga mengatur 'kegagalan-atas' dari alamat IP. (Tapi kebanyakan memilih teknik load balancing, satu alamat IP, dan gagal-over antara load-balancers.)

Mungkin Anda memerlukan semua permintaan untuk satu sesi untuk pergi ke server yang sama, tetapi Anda ingin permintaan tersebar di berbagai kluster server regional? Round robin tidak tepat, untuk itu: Anda perlu melakukan sesuatu yang memastikan setiap klien yang diberikan mengakses kluster server fisik yang sama setiap kali (kecuali ketika 'pengecualian' terjadi, seperti kegagalan server). Entah mereka menerima alamat IP yang konsisten dari permintaan DNS, atau dialihkan ke kluster server fisik yang sama. Solusi untuk itu termasuk berbagai "load balancer" DNS komersial dan non-komersial, atau (jika Anda memiliki kontrol lebih dari jaringan Anda) iklan jaringan BGP. Anda dapat dengan mudah mengatur nama server domain Anda sendiri untuk memberikan tanggapan yang sama sekali berbeda (tetapi, karena permintaan DNS dapat dikirim ke semua tempat, Anda tidak akan mencapai kedekatan lokasi dengan pendekatan itu.)

[* Saya akan menggunakan "round-robin", karena 'RR' dalam terminologi DNS berarti "catatan sumber daya".]


6
2017-09-30 09:47



Saya menambahkan lebih banyak penjelasan dalam jawabannya. Saran Anda untuk menggunakan DNS "load balancers" IMHO tidak mengizinkan fail-over instan. Tentang BGP, apakah Anda mengacu pada solusi TCP Anycast? - Valentino Miazzo
Saya tidak menyarankan solusi khusus atas yang lain - Saya mengatakan bahwa Anda perlu memilih solusi yang tepat untuk masalah Anda (yang Anda belum benar-benar dinyatakan dalam pertanyaan Anda) dan kendala Anda (idem.) DNS round-robin tidak tidak menyediakan fail-over instan lebih dari DNS LB, karena browser tidak dijamin untuk melakukan "hal yang benar" (terutama karena "hal yang benar" tidak ditentukan secara ketat atau ditentukan. Saya tidak percaya ada cukup "pintar Browser HTML ", bahkan sekarang - saya setuju dengan Jesper bahwa mereka terlalu bervariasi dalam perilaku mereka untuk bergantung pada mereka sama sekali.) - jrg
Saya memahami skeptisisme Anda. Bagaimanapun, seperti yang bisa Anda baca di sini crypto.stanford.edu/dns/dns-rebinding.pdf sebagian besar peramban HTML saat ini sudah "pintar". - Valentino Miazzo


Observasi vmiazzo +1 yang sangat bagus untuk Anda !! Saya terjebak persis di mana Anda .. bingung dengan bagaimana CDN ini melakukan sihir mereka.

Berikut ini adalah tebakan saya tentang bagaimana CDN menjalankan jaringan mereka:

  • Gunakan Anycast DNS (disebutkan oleh Jesper Mortensen) untuk mendapatkan pusat data terdekat
  • Mereka menjalankan jaringan lokal yang membentang di pusat data yang berbeda yang memungkinkan mereka untuk melakukan sesuatu seperti KARPER pada host mereka di seluruh pusat data yang berbeda

Atau

Pada saat solusi berikut ini bekerja untuk saya: - DNS mengembalikan beberapa IP, misalnya:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy
  • Titik masuk terakhir ke proxy terbalik di cloud amazon, yang secara cerdas lolos ke server yang tersedia (atau menyediakan di bawah halaman pemeliharaan)

Proksi terbalik masih tertabrak tetapi bot seberat yang utama.


5
2017-12-14 08:15



Urutan dari beberapa catatan DNS yang akan diterima klien secara sengaja diacak sehingga proxy reverse Anda mungkin tertabrak sekitar 1/6 dari waktu (1/2 dari 1/3). Bagaimana itu lebih baik atau berbeda daripada memiliki 6 A catatan? - ColinM


Mengapa RFC 2782 (berlaku sama dengan MX / prioritas untuk layanan seperti http, imap, ...) tidak diimplementasikan dalam jenis peramban apa pun? Hal akan lebih mudah ... Ada bug tentang, dibuka selama sepuluh tahun di Mozilla !!! karena ini akan menjadi akhir industri penyeimbang beban komersial ??? Saya sangat kecewa tentang itu.


3
2018-04-16 15:05





2 - Anda dapat melakukannya dengan Anycast menggunakan Quagga

(Bahkan jika ada beberapa info yang Anycast buruk dengan TCP ada beberapa perusahaan besar yang menggunakannya seperti CacheFly)


2
2017-09-30 09:08



Tentu saja, tetapi Anda tidak dapat melakukannya dengan server sewaan, Anda memerlukan jaringan Anda sendiri. - Julien Tartarin
Menambahkan beberapa info tentang Anycast failover pada pertanyaan. Pada dasarnya juga TCP Anycast bukanlah solusi sempurna. - Valentino Miazzo


Saya bertanya-tanya berapa banyak orang yang menjawab pertanyaan-pertanyaan ini sebenarnya menjalankan jaringan server besar di seluruh dunia? Google menggunakan round robin dan perusahaan saya telah menggunakannya selama bertahun-tahun. Ini dapat bekerja dengan baik, dengan beberapa keterbatasan. Ya, itu perlu ditambah dengan ukuran lain.

Kunci sebenarnya adalah bersedia menerima satu atau dua cegukan jika server turun. Ketika saya menarik steker ke server, jika browser mencoba mengakses server tersebut, akan ada penundaan satu menit atau lebih ketika browser mengetahui bahwa alamat IP sedang tidak aktif. Tapi kemudian pergi ke server lain dengan sangat cepat.

Ini bekerja hebat, dan orang-orang yang mengklaim bahwa itu menyebabkan banyak masalah tidak tahu apa yang mereka bicarakan. Itu hanya membutuhkan desain yang tepat.

Failover menyebalkan. HA terbaik menggunakan semua sumber daya sepanjang waktu.

Saya telah bekerja dengan HA sejak 1986. Saya menjalani pelatihan ekstensif untuk membuat sistem failover dan saya sama sekali bukan penggemar failover.

Juga, RR bekerja untuk mendistribusikan beban, meskipun pasif dan tidak aktif. Log server kami dengan jelas menunjukkan persentase lalu lintas yang sesuai di setiap server - dengan alasan.


2
2017-07-19 14:34