Pertanyaan Mengapa DNS failover tidak direkomendasikan?


Dari membaca, sepertinya DNS failover tidak disarankan hanya karena DNS tidak dirancang untuk itu. Tetapi jika Anda memiliki dua webservers di subnet hosting yang berbeda konten redundan, apa metode lain yang ada untuk memastikan bahwa semua traffic dialihkan ke server langsung jika satu server turun?

Bagi saya sepertinya DNS failover adalah satu-satunya opsi failover di sini, tetapi konsensus itu bukan pilihan yang baik. Namun layanan seperti DNSmadeeasy.com menyediakannya, jadi harus ada manfaatnya. Ada komentar?


166
2017-08-30 17:57




Melihat sini untuk pembahasan terbaru tentang masalah ini. Pengalihan ini sekarang dilakukan secara otomatis oleh peramban modern. - GetFree


Jawaban:


Dengan 'DNS failover' Saya menganggap maksud Anda DNS Round Robin dikombinasikan dengan beberapa pemantauan, yaitu mempublikasikan beberapa alamat IP untuk nama host DNS, dan menghapus alamat mati ketika pemantauan mendeteksi bahwa server sedang tidak aktif. Ini dapat diterapkan untuk situs web kecil yang kurang diperdagangkan.

Secara desain, ketika Anda menjawab permintaan DNS, Anda juga menyediakan Time To Live (TTL) untuk respons yang Anda berikan. Dengan kata lain, Anda memberi tahu server DNS dan cache lain "Anda dapat menyimpan jawaban ini dan menggunakannya selama x menit sebelum memeriksa kembali dengan saya". Kekurangannya berasal dari ini:

  • Dengan failover DNS, persentase yang tidak diketahui dari pengguna Anda akan memiliki data DNS Anda yang disimpan dalam cache dengan jumlah TTL yang berbeda-beda. Sampai TTL kedaluwarsa ini dapat terhubung ke server mati. Ada cara cepat untuk menyelesaikan failover dari ini.
  • Karena hal di atas, Anda cenderung untuk menetapkan TTL cukup rendah, katakanlah 5-10 menit. Tetapi pengaturannya lebih tinggi memberikan manfaat kinerja (sangat kecil), dan dapat membantu propagasi DNS Anda bekerja dengan andal bahkan jika ada kesalahan kecil dalam lalu lintas jaringan. Jadi, menggunakan failover berbasis DNS bertentangan dengan TTL tinggi, tetapi TTL tinggi adalah bagian dari DNS dan dapat berguna.

Metode yang lebih umum untuk mendapatkan uptime yang baik adalah:

  • Menempatkan server bersama di LAN yang sama.
  • Tempatkan LAN di pusat data dengan kekuatan dan jaringan pesawat yang sangat tersedia.
  • Gunakan load balancing HTTP untuk menyebarkan beban dan gagal pada kegagalan server individu.
  • Dapatkan tingkat redundancy / uptime yang Anda harapkan untuk firewall Anda, load balancers dan switch.
  • Memiliki strategi komunikasi di tempat untuk kegagalan pusat data penuh, dan kegagalan sesekali switch / server database / sumber daya lain yang tidak dapat dengan mudah dicerminkan.

Sebagian kecil situs web menggunakan pengaturan multi-datacenter, dengan 'geo-balancing' antara pusat data.


93
2017-08-30 18:39



Saya pikir dia secara khusus mencoba untuk mengelola failover antara dua pusat data yang berbeda (perhatikan komentar tentang subnet yang berbeda), sehingga menempatkan server bersama-sama / menggunakan load balancer / ekstra redundasi tidak akan membantunya (terlepas dari pusat data redundan. Tapi Anda masih perlu memberitahu internet untuk pergi ke salah satu yang masih ada). - Cian
Tambahkan anycast ke pengaturan multi-datacenter dan itu menjadi bukti kegagalan datacenter. - petrus
wikipedia entry on anycast (en.wikipedia.org/wiki/Anycast) membahas ini terkait dengan ketahanan root server DNS. - dunxd
Serangan DDoS sangat umum sekarang seluruh pusat data dapat dibawa offline (terjadi pada Linode London dan pusat data mereka lainnya pada Desember 2015). Jadi menggunakan penyedia yang sama, di pusat data yang sama tidak disarankan. Oleh karena itu beberapa pusat data dengan penyedia yang berbeda akan menjadi strategi yang baik, yang membawa kita kembali ke failover DNS kecuali ada alternatif yang lebih baik. - Laurence Cope
Mengapa tidak ada failover, karena Anda perlu menjaga situs Anda tetap hidup saat perangkat rusak / rusak? Apa gunanya failover Anda ketika berada di jaringan yang sama yang berbagi perangkat yang sama misalnya router? - user2128576


Kegagalan DNS bekerja sangat baik. Saya telah menggunakannya selama bertahun-tahun untuk mengalihkan lalu lintas secara manual antara pusat data, atau secara otomatis ketika sistem pemantauan mendeteksi gangguan, masalah konektivitas, atau server yang kelebihan beban. Ketika Anda melihat kecepatan kerjanya, dan volume lalu lintas dunia nyata yang dapat digeser dengan mudah - Anda tidak akan pernah melihat ke belakang. Saya menggunakan Zabbix untuk memonitor semua sistem saya dan grafik visual yang menunjukkan apa yang terjadi selama situasi failover DNS meletakkan semua keraguan saya dan mengakhiri. Mungkin ada beberapa ISP di luar sana yang mengabaikan TTL, dan ada beberapa pengguna masih di luar sana dengan browser lama - tetapi ketika Anda melihat lalu lintas dari jutaan tampilan halaman setiap hari di 2 lokasi pusat data dan Anda melakukan peralihan lalu lintas DNS - lalu lintas residual yang masuk yang mengabaikan TTL itu menggelikan. DNS failover adalah teknik yang solid.

DNS tidak dirancang untuk failover - tetapi dirancang dengan TTL yang bekerja luar biasa untuk kebutuhan failover ketika dikombinasikan dengan sistem monitoring yang solid. TTL dapat disetel sangat singkat. Saya telah secara efektif menggunakan TTL dari 5 detik dalam produksi untuk solusi berbasis failover DNS yang cepat. Anda harus memiliki server DNS yang mampu menangani beban tambahan - dan diberi nama tidak akan memotongnya. Namun, powerdns cocok dengan tagihan ketika didukung dengan database mysql yang direplikasi pada server nama yang redundan. Anda juga memerlukan sistem pemantauan terdistribusi yang solid yang dapat Anda percayai untuk integrasi failover otomatis. Zabbix bekerja untuk saya - saya dapat memverifikasi pemadaman dari beberapa sistem Zabbix terdistribusi hampir seketika - memperbarui catatan mysql yang digunakan oleh powerdns dengan cepat - dan menyediakan failover hampir instan selama padam dan lonjakan lalu lintas.

Tapi, hei - saya membangun perusahaan yang menyediakan layanan failover DNS setelah bertahun-tahun membuatnya bekerja untuk perusahaan besar. Jadi ambillah pendapat saya dengan sebutir garam. Jika Anda ingin melihat beberapa grafik lalu lintas zabbix dari situs bervolume tinggi selama pemadaman - untuk melihat sendiri seberapa baik kegagalan DNS bekerja - email saya, saya lebih dari senang untuk berbagi.


44
2017-10-20 17:17



Jawaban Cian serverfault.com/a/60562/87017 langsung bertentangan dengan Anda ..... jadi siapa yang benar? - Pacerier
Ini adalah pengalaman saya bahwa TTL singkat TIDAK BEKERJA di internet. Anda mungkin menjalankan server DNS yang menghormati RFC - tetapi ada banyak server di luar sana yang tidak. Tolong jangan menganggap ini adalah argumen terhadap DNS Round Robin - lihat juga jawaban vmiazzo di bawah - Saya telah menjalankan situs sibuk menggunakan RR DNS dan mengujinya - ia bekerja. Satu-satunya masalah yang saya temui adalah dengan beberapa klien berbasis Java (bukan browser) yang bahkan tidak mencoba untuk menghubungkan kembali pada kegagalan apalagi siklus daftar host di RST - symcbean
Saya yakin orang-orang yang mengatakan bahwa DNSover DNS terpantau sangat bagus dan orang-orang yang mengatakannya menyebalkan memiliki pengalaman serupa, tetapi dengan harapan yang berbeda. DNS failover TIDAK mulus, tetapi TIDAK mencegah downtime yang signifikan. Jika Anda memerlukan akses yang benar-benar mulus (tidak pernah kehilangan satu permintaan pun, bahkan selama kegagalan server), Anda mungkin memerlukan arsitektur yang jauh lebih canggih - dan mahal. Itu bukan persyaratan untuk banyak aplikasi. - Tom Wilson


Masalah dengan failover DNS adalah, dalam banyak kasus, tidak dapat diandalkan. Beberapa ISP akan mengabaikan TTL Anda, itu tidak langsung terjadi bahkan jika mereka menghormati TTL Anda, dan ketika situs Anda muncul kembali, itu dapat menyebabkan beberapa keanehan dengan sesi ketika cache DNS pengguna habis, dan mereka akhirnya menuju ke server lain.

Sayangnya, ini adalah satu-satunya pilihan, kecuali Anda cukup besar untuk melakukan perutean (eksternal) Anda sendiri.


31
2017-08-30 18:27



+1 Lambat dan Tidak Dapat Diandalkan - Chris S
Juga lihat serverfault.com/q/315199/87017 - Pacerier


Pendapat umum adalah bahwa dengan RR DNS, ketika IP turun, beberapa klien akan terus menggunakan IP yang rusak selama beberapa menit. Ini dinyatakan dalam beberapa jawaban sebelumnya untuk pertanyaan dan itu juga ditulis di Wikipedia.

Bagaimanapun,

http://crypto.stanford.edu/dns/dns-rebinding.pdf menjelaskan bahwa itu tidak benar untuk sebagian besar peramban HTML saat ini. Mereka akan mencoba IP selanjutnya dalam hitungan detik.

http://www.tenereillo.com/GSLBPageOfShame.htm tampaknya menjadi lebih kuat:

Penggunaan beberapa catatan A bukan merupakan trik perdagangan, atau fitur yang dikandung oleh vendor peralatan penyeimbang beban. Protokol DNS dirancang dengan dukungan untuk beberapa catatan A karena alasan ini. Aplikasi seperti browser dan proksi dan server email memanfaatkan bagian dari protokol DNS.

Mungkin beberapa ahli dapat berkomentar dan memberikan penjelasan yang lebih jelas tentang mengapa DNS RR tidak baik untuk ketersediaan tinggi.

Terima kasih,

Valentino

PS: maaf untuk tautan yang rusak tetapi, sebagai pengguna baru, saya tidak dapat memposting lebih dari 1


19
2017-09-29 10:06



Rekaman Multiple A dirancang, tetapi untuk load balancing, alih-alih untuk gagal. Klien akan menyimpan hasil cache, dan terus menggunakan pool penuh (termasuk IP rusak) selama beberapa menit setelah Anda mengubah catatan. - Cian
Jadi, itulah yang ditulis crypto.stanford.edu/dns/dns-rebinding.pdf bab 3.1 salah? << Penandaan DNS Internet Explorer 7 pin selama 30 menit.1 Sayangnya, jika domain penyerang memiliki banyak data A dan server saat ini menjadi tidak tersedia, browser akan mencoba alamat IP yang berbeda dalam satu detik. >> - Valentino Miazzo
Pindah pertanyaanku di sini serverfault.com/questions/69870/… - Valentino Miazzo


Saya menjalankan failover DNS RR di situs web yang diperdagangkan dengan perdagangan moderat (di dua geografi) selama bertahun-tahun.

Ini berfungsi dengan baik, tetapi setidaknya ada tiga seluk-beluk yang saya pelajari dengan cara yang sulit.

1) Browser akan failover dari IP yang tidak berfungsi ke IP yang bekerja setelah 30 detik (terakhir kali saya periksa) jika keduanya dianggap aktif dalam DNS cache apa pun yang tersedia untuk klien Anda. Ini pada dasarnya adalah hal yang baik.

Tetapi memiliki "setengah" pengguna Anda menunggu 30 detik tidak dapat diterima, jadi Anda mungkin ingin memperbarui catatan TTL Anda menjadi beberapa menit, tidak beberapa hari atau minggu sehingga jika terjadi gangguan, Anda dapat dengan cepat menghapus server turun dari DNS Anda. Orang lain telah menyinggung hal ini dalam tanggapan mereka.

2) Jika salah satu server nama Anda (atau salah satu dari dua geografi Anda sepenuhnya) turun yang melayani domain round-robin Anda, dan jika yang utama turun, saya samar-samar ingat Anda dapat mengalami masalah lain yang mencoba menghapusnya downed nameserver dari DNS jika Anda belum mengatur SOA TTL / kedaluwarsa untuk nameserver ke nilai yang cukup rendah juga. Saya bisa memiliki rincian teknis yang salah di sini, tetapi ada lebih dari satu pengaturan TTL yang Anda perlukan untuk benar-benar mempertahankan diri terhadap satu titik kegagalan.

3) Jika Anda mempublikasikan API web, layanan REST, dll, yang biasanya tidak dipanggil oleh browser, dan dengan demikian menurut saya, failover DNS mulai menunjukkan kekurangan nyata. Ini mungkin mengapa ada yang mengatakan, seperti yang Anda katakan "itu tidak disarankan". Inilah mengapa saya mengatakan itu. Pertama, aplikasi yang menggunakan URL tersebut biasanya bukan browser, sehingga mereka tidak memiliki properti / logika failover 30 detik dari browser umum. Kedua, apakah entri DNS kedua disebut atau bahkan DNS yang disurvei kembali sangat tergantung pada rincian pemrograman tingkat rendah dari perpustakaan jaringan dalam bahasa pemrograman yang digunakan oleh klien API / REST ini, ditambah persis bagaimana mereka dipanggil oleh aplikasi klien API / REST. (Di bawah mereka mencakup, apakah perpustakaan memanggil get_addr, dan kapan? Jika soket menggantung atau menutup, apakah aplikasi membuka kembali soket baru? Apakah ada semacam logika timeout? Dll dll)

Ini murah, teruji, dan "kebanyakan berfungsi". Jadi seperti kebanyakan hal, jarak tempuh Anda mungkin bervariasi.


11
2018-04-12 01:21



perpustakaan yang tidak mencoba lagi RRs lain untuk alamat yang rusak. arahkan para pengembang pada halaman manual untuk getaddrinfo () dll. - Jasen


Ada banyak orang yang menggunakan kami (Dyn) untuk failover. Ini adalah alasan yang sama situs dapat melakukan halaman status ketika mereka memiliki waktu henti (memikirkan hal-hal seperti Fail Whale Twitter) ... atau hanya mengubah rute lalu lintas berdasarkan TTL. Beberapa orang mungkin berpikir bahwa DNS Failover adalah ghetto ... tetapi kami secara serius mendesain jaringan kami dengan failover dari awal ... agar dapat berfungsi sebaik perangkat keras. Saya tidak yakin bagaimana DME melakukannya, tetapi kami memiliki 3 dari 17 PoP terdekat yang kami amati memantau server Anda dari lokasi terdekat. Ketika mendeteksi dari dua dari tiga bahwa itu turun, kita cukup mengalihkan lalu lintas ke IP yang lain. Satu-satunya waktu henti adalah bagi mereka yang diminta untuk sisa interval TTL tersebut.

Beberapa orang suka menggunakan kedua server sekaligus ... dan dalam hal ini dapat melakukan sesuatu seperti load balancing round robin ... atau load balancing berbasis geo. Bagi mereka yang benar-benar peduli tentang kinerja ... manajer lalu lintas waktu nyata kami akan memantau setiap server ... dan jika ada yang lebih lambat ... reroute lalu lintas ke yang tercepat berdasarkan IP apa yang Anda tautkan di nama host Anda. Sekali lagi ... ini bekerja berdasarkan nilai yang Anda tempatkan di UI / API / Portal kami.

Saya kira poin saya adalah ... kami merancang failover dns dengan sengaja. Meskipun DNS tidak dibuat untuk failover ketika awalnya dibuat ... jaringan DNS kami dirancang untuk menerapkannya dari awal. Biasanya bisa sama efektifnya dengan perangkat keras..tanpa depresiasi atau biaya perangkat keras. Harapan itu tidak membuat saya terdengar timpang untuk memasukkan Dyn ... ada banyak perusahaan lain yang melakukannya ... Saya hanya berbicara dari perspektif tim kami. Semoga ini membantu...


9
2018-05-25 19:38



Apa yang Anda maksud dengan "bisa sama efektifnya dengan perangkat keras"? Apa jenis perangkat keras yang melakukan perutean DNS? - mpen
@Ryan, Apa maksudmu saat mengatakan "ghetto"? - Pacerier
Untuk kata itu kamus perkotaan tidak memberikan definisi dengan konotasi positif, saya akan menganggap "solusi pengemis" mungkin terjemahan yang cocok. - Jasen


Pilihan lain adalah untuk mengatur nama server 1 di lokasi A dan server nama 2 di lokasi B, tetapi mengatur masing-masing sehingga semua catatan A pada lalu lintas titik NS1 ke IP untuk lokasi A, dan pada NS2 semua catatan A menunjuk ke IP untuk lokasi B. Kemudian tetapkan TTL Anda untuk jumlah yang sangat rendah, dan pastikan catatan domain Anda di registrar telah disiapkan untuk NS1 dan NS2. Dengan cara itu, secara otomatis akan memuat keseimbangan, dan gagal atas harus satu server atau satu tautan ke lokasi turun.

Saya telah menggunakan pendekatan ini dengan cara yang sedikit berbeda. Saya memiliki satu lokasi dengan dua ISP dan menggunakan metode ini untuk mengarahkan lalu lintas ke setiap tautan. Sekarang, mungkin sedikit lebih pemeliharaan dari yang Anda inginkan ... tapi saya bisa membuat perangkat lunak sederhana yang secara otomatis menarik catatan NS1, memperbarui alamat IP rekaman untuk zona pilih, dan mendorong zona tersebut ke NS2.


5
2017-08-07 05:13



Tidakkah server nama mengambil terlalu banyak untuk menyebar? Jika Anda mengubah data DNS dengan TTL rendah, ini akan bekerja secara instan, tetapi ketika Anda mengubah nameserver, diperlukan 24 horus atau lebih untuk disebarkan, maka saya tidak melihat bagaimana ini bisa menjadi solusi failover. - Marco Demaio


Alternatifnya adalah sistem failover berbasis BGP. Tidak mudah untuk mengaturnya, tetapi itu harus menjadi bukti yang jelas. Atur situs A di satu lokasi, situs B dalam hitungan detik semua dengan alamat IP lokal, kemudian dapatkan kelas C atau blok ip lain yang portabel dan atur pengalihan dari IP portabel ke IP lokal.

Ada jebakan, tetapi lebih baik daripada solusi berbasis DNS jika Anda membutuhkan tingkat kontrol itu.


4
2017-08-30 21:40



Solusi berbasis BGP tidak tersedia untuk semua orang sekalipun. Dan jauh lebih mudah untuk menerobos cara-cara yang sangat mengerikan daripada DNS. Ayunan dan bundaran, kurasa. - Cian