Mengapa DNS failover tidak disarankan?

Dari membaca, sepertinya DNS failover tidak disarankan hanya karena DNS tidak dirancang untuk itu. Tetapi jika Anda memiliki dua server web pada subnet yang berbeda yang menghosting konten yang berlebihan, metode lain apa yang ada untuk memastikan bahwa semua lalu lintas dialihkan ke server langsung jika satu server turun?

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

Maksud saya 'DNS failover' maksud saya DNS Round Robin dikombinasikan dengan beberapa pemantauan, yaitu menerbitkan beberapa alamat IP untuk nama host DNS, dan menghapus alamat mati ketika pemantauan mendeteksi bahwa server sedang down. Ini bisa diterapkan untuk situs web kecil dan kurang diperdagangkan.

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

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

Metode yang lebih umum untuk mendapatkan waktu aktif yang baik meliputi:

• Menempatkan server bersama di LAN yang sama.
• Tempatkan LAN di pusat data dengan daya yang sangat tersedia dan pesawat jaringan.
• Gunakan penyeimbang beban HTTP untuk menyebarkan beban dan gagal pada kegagalan server individual.
• Dapatkan tingkat redundansi / perkiraan waktu aktif yang Anda perlukan untuk firewall, load balancers, dan sakelar Anda.
• Siapkan strategi komunikasi untuk kegagalan pusat data lengkap, dan sesekali kegagalan switch / server database / sumber daya lain yang tidak mudah dicerminkan.

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

Kegagalan DNS sangat berhasil. Saya telah menggunakannya selama bertahun-tahun untuk secara manual mengubah lalu lintas antara pusat data, atau secara otomatis ketika sistem pemantauan mendeteksi pemadaman, masalah konektivitas, atau server yang kelebihan beban. Ketika Anda melihat kecepatan di mana ia bekerja, dan volume lalu lintas dunia nyata yang dapat digeser dengan mudah - Anda tidak akan pernah melihat ke belakang. Saya menggunakan Zabbix untuk memantau semua sistem saya dan grafik visual yang menunjukkan apa yang terjadi selama situasi DNS failover menempatkan semua keraguan saya ke dan berakhir. 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 pergantian lalu lintas DNS - lalu lintas residual yang mengabaikan TTL menggelikan.

DNS tidak dirancang untuk failover - tetapi dirancang dengan TTL yang bekerja luar biasa untuk kebutuhan failover bila dikombinasikan dengan sistem pemantauan yang solid. TTL dapat diatur sangat singkat. Saya telah menggunakan TTL secara efektif selama 5 detik untuk menghasilkan solusi berbasiskan DNS failover cepat. Anda harus memiliki server DNS yang mampu menangani beban tambahan - dan namanya tidak akan memotongnya. Namun, powerdns sesuai dengan tagihan ketika didukung dengan database replikasi mysql pada server nama yang berlebihan. 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 secara instan - memperbarui catatan mysql yang digunakan oleh powerdns dengan cepat - dan memberikan kegagalan instan hampir selama pemadaman dan lonjakan lalu lintas.

Tapi hei - saya membangun perusahaan yang menyediakan layanan DNS failover setelah bertahun-tahun membuatnya berfungsi 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 failover DNS bekerja - email saya, saya senang berbagi.

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

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

Pendapat umum adalah bahwa dengan DNS RR, ketika IP turun, beberapa klien akan terus menggunakan IP yang rusak selama beberapa menit. Ini dinyatakan dalam beberapa jawaban sebelumnya untuk pertanyaan dan 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 berikutnya dalam hitungan detik.

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

Penggunaan beberapa catatan A bukan tipuan perdagangan, atau fitur yang disusun oleh vendor peralatan penyeimbang beban. Protokol DNS dirancang dengan dukungan untuk beberapa catatan A karena alasan ini. Aplikasi seperti browser dan proxy dan server email memanfaatkan bagian protokol DNS itu.

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

Terima kasih,

Valentino

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

Saya menjalankan DNS RR failover pada situs web produksi yang ditrafik moderat namun bisnis-kritis (di dua wilayah geografis) selama bertahun-tahun.

Ini berfungsi dengan baik, tetapi setidaknya ada tiga kehalusan yang saya pelajari dengan cara yang sulit.

1) Browser akan gagal dari IP yang tidak berfungsi ke IP yang bekerja setelah 30 detik (terakhir kali saya periksa) jika keduanya dianggap aktif dalam DNS caching 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, bukan beberapa hari atau minggu sehingga jika terjadi pemadaman, Anda dapat dengan cepat menghapus server down dari DNS Anda. Yang lain menyinggung ini dalam tanggapan mereka.

2) Jika salah satu server nama Anda (atau salah satu dari dua geografi Anda seluruhnya) turun yang melayani domain round-robin Anda, dan jika yang utama dari mereka turun, saya samar-samar ingat Anda dapat mengalami masalah lain mencoba untuk menghapus itu server nama turun dari DNS jika Anda belum menetapkan SOA TTL / kedaluwarsa untuk server nama Anda ke nilai yang cukup rendah juga. Saya dapat memiliki rincian teknis yang salah di sini, tetapi ada lebih dari satu pengaturan TTL yang Anda butuhkan untuk benar-benar bertahan melawan satu titik kegagalan.

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

Ini murah, sudah teruji, dan "sebagian besar bekerja". Jadi seperti kebanyakan hal, jarak tempuh Anda mungkin berbeda.

Ada banyak orang yang menggunakan kami (Dyn) untuk failover. Itu adalah alasan yang sama mengapa situs dapat melakukan halaman status ketika mereka memiliki waktu henti (pikirkan hal-hal seperti Paus Gagal Twitter) ... atau hanya mengubah rute lalu lintas berdasarkan TTL. Beberapa orang mungkin berpikir bahwa DNS Failover adalah ghetto ... tapi kami secara serius merancang jaringan kami dengan failover sejak awal ... sehingga itu akan berfungsi juga sebagai perangkat keras. Saya tidak yakin bagaimana DME melakukannya, tetapi kami memiliki 3 dari 17 PoP Anycasted terdekat kami memonitor server Anda dari lokasi terdekat. Ketika mendeteksi dari dua dari tiga yang turun, kita cukup mengalihkan rute lalu lintas ke IP lain. Satu-satunya downtime adalah bagi mereka yang pada saat itu diminta untuk sisa interval TTL itu.

Beberapa orang suka menggunakan kedua server sekaligus ... dan dalam hal ini dapat melakukan sesuatu seperti penyeimbangan muatan round robin ... atau penyeimbangan muatan berbasis geografis. Bagi mereka yang benar-benar peduli dengan kinerja ... manajer lalu lintas waktu nyata kami akan memonitor setiap server ... dan jika ada yang lebih lambat ... rutekan ulang lalu lintas ke yang tercepat berdasarkan IP yang Anda tautkan di nama host Anda. Sekali lagi ... ini berfungsi berdasarkan nilai yang Anda tempatkan di UI / API / Portal kami.

Saya kira maksud saya adalah ... kami merekayasa kegagalan secara sengaja. Sementara DNS tidak dibuat untuk failover saat awalnya dibuat ... jaringan DNS kami dirancang untuk mengimplementasikannya sejak awal. Biasanya bisa sama efektifnya dengan perangkat keras..tanpa penyusutan atau biaya perangkat keras. Harapan itu tidak membuat saya terdengar lemah untuk menghubungkan Dyn ... ada banyak perusahaan lain yang melakukannya ... Saya hanya berbicara dari sudut pandang tim kami. Semoga ini membantu...

Pilihan lain adalah untuk mengatur server nama 1 di lokasi A dan server nama 2 di lokasi B, tetapi mengatur masing-masing sehingga semua A mencatat pada lalu lintas titik NS1 ke IP untuk lokasi A, dan pada NS2 semua catatan A menunjuk ke IP untuk lokasi B. Kemudian atur TTL Anda untuk angka yang sangat rendah, dan pastikan catatan domain Anda di registrar telah diatur untuk NS1 dan NS2. Dengan begitu, ia akan secara otomatis memuat saldo, dan gagal jika 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 melalui setiap tautan. Sekarang, ini mungkin sedikit lebih banyak pemeliharaan daripada yang mau Anda lakukan ... tapi saya bisa membuat perangkat lunak sederhana yang secara otomatis menarik catatan NS1, memperbarui catatan alamat IP untuk zona tertentu, dan mendorong zona itu untuk NS2.

Alternatifnya adalah sistem failover berbasis BGP. Ini tidak mudah untuk diatur, tetapi harus menjadi bukti peluru. Atur situs A di satu lokasi, situs B di detik semua dengan alamat IP lokal, kemudian dapatkan kelas C atau blok lain dari ip yang portabel dan mengatur pengalihan dari IP portabel ke IP lokal.

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

Salah satu opsi untuk failover pusat data multi adalah untuk melatih pengguna Anda. Kami beriklan kepada pelanggan kami bahwa kami menyediakan beberapa server di banyak kota dan dalam email pendaftaran kami dan menyertakan tautan langsung ke setiap "server" sehingga pengguna tahu jika satu server tidak ada, mereka dapat menggunakan tautan ke server lain.

Ini benar-benar mem-bypass masalah DNS failover dengan hanya mempertahankan beberapa nama domain. Pengguna yang masuk ke www.company.com atau company.com dan masuk diarahkan ke server1.company.com atau server2.company.com dan memiliki pilihan untuk mem-bookmark salah satu dari mereka jika mereka melihat mereka mendapatkan kinerja yang lebih baik menggunakan satu atau yang lain . Jika salah satu turun pengguna dilatih untuk pergi ke server lain.

Saya telah menggunakan penyeimbangan dan kegagalan situs berbasis DNS selama sepuluh tahun terakhir, dan ada beberapa masalah, tetapi hal itu dapat dikurangi. BGP, sementara unggul dalam beberapa hal bukanlah solusi 100% baik dengan peningkatan kompleksitas, mungkin biaya perangkat keras tambahan, waktu konvergensi, dll ...

Saya menemukan bahwa menggabungkan penyeimbangan beban lokal (berbasis LAN), GSLB, dan hosting zona berbasis cloud bekerja cukup baik untuk menutup beberapa masalah yang biasanya terkait dengan penyeimbangan beban DNS.

Semua jawaban ini memiliki beberapa validitas untuk mereka, tetapi saya pikir itu benar-benar tergantung pada apa yang Anda lakukan dan berapa anggaran Anda. Di sini, di CloudfloorDNS, sebagian besar bisnis kami adalah DNS, dan tidak hanya menawarkan DNS cepat, tetapi opsi TTL rendah dan failover DNS. Kami tidak akan berbisnis jika ini tidak berhasil dan bekerja dengan baik.

Jika Anda adalah perusahaan multinasional dengan anggaran tidak terbatas pada waktu aktif, ya, penyeimbang beban perangkat keras GSLB dan pusat data tingkat 1 sangat bagus, tetapi DNS Anda masih harus cepat dan solid. Seperti yang Anda ketahui, DNS adalah aspek penting dari infrastruktur apa pun, selain nama domain itu sendiri, itu adalah layanan tingkat terendah yang digunakan setiap bagian lain dari keberadaan online Anda. Dimulai dengan pendaftar domain yang solid, DNS sama pentingnya dengan tidak membiarkan domain Anda kedaluwarsa. DNS turun, artinya seluruh aspek online organisasi Anda juga turun!

Saat menggunakan DNS Failover, aspek-aspek penting lainnya adalah pemantauan server (selalu beberapa lokasi geografis untuk memeriksa dan selalu beberapa (setidaknya 3) harus memeriksa untuk menghindari kesalahan positif) dan mengelola catatan DNS dengan benar kegagalan terdeteksi. TTL rendah dan beberapa opsi dengan failover dapat menjadikan ini sebagai proses yang mulus, dan mengalahkan bangun dari pager di tengah malam jika Anda adalah sys admin.

Secara keseluruhan, DNS Failover benar-benar berfungsi dan bisa sangat terjangkau. Dalam kebanyakan kasus dari kami atau sebagian besar penyedia DNS yang dikelola, Anda akan mendapatkan DNS Anycast bersama dengan pemantauan Server dan failover untuk sebagian kecil dari biaya opsi perangkat keras.

Jadi jawaban sebenarnya adalah ya, itu berfungsi, tetapi apakah itu untuk semua orang dan setiap anggaran? Mungkin tidak, tetapi sampai Anda mencobanya dan melakukan tes sendiri, sulit untuk mengabaikan jika Anda adalah bisnis kecil hingga menengah dengan anggaran TI terbatas yang menginginkan waktu kerja terbaik.

"Dan mengapa Anda mengambil risiko untuk menggunakannya di sebagian besar lingkungan produksi (meskipun lebih baik daripada tidak sama sekali)."

Sebenarnya, "lebih baik daripada tidak sama sekali" lebih baik dinyatakan sebagai "satu-satunya pilihan" ketika kehadiran secara geografis beragam. Penyeimbang beban perangkat keras sangat bagus untuk satu titik keberadaan, tetapi satu titik keberadaan juga merupakan satu titik kegagalan.

Ada banyak situs besar yang menggunakan manipulasi lalu lintas berbasis dns untuk efek yang baik. Mereka adalah tipe situs yang tahu setiap jam jika penjualannya tidak aktif. Tampaknya mereka adalah yang terakhir untuk "mengambil peluang Anda menggunakannya untuk sebagian besar lingkungan produksi". Memang, mereka telah meninjau opsi mereka dengan cermat, memilih teknologi, dan membayarnya dengan baik. Jika mereka berpikir ada sesuatu yang lebih baik, mereka akan pergi dalam sekejap. Fakta bahwa mereka masih memilih untuk tetap berbicara banyak tentang penggunaan dunia nyata.

Kegagalan berbasis Dns memang menderita sejumlah latensi. Tidak ada jalan lain. Tapi, itu masih satu-satunya pendekatan yang layak untuk manajemen failover dalam skenario multi-pop. Sebagai satu-satunya pilihan, itu jauh lebih dari "lebih baik daripada tidak sama sekali".

Saat ini penyeimbang beban global yang baik yang bekerja menggunakan teknik itu dan bekerja dengan cukup baik. Periksa misalnya Manajer Lalu Lintas Azure https://azure.microsoft.com/en-us/services/traffic-manager/

Jika Anda ingin mempelajari lebih lanjut, baca catatan aplikasi di

http://edgedirector.com

Mereka mencakup: failover, penyeimbangan muatan global, dan sejumlah hal terkait.

Jika arsitektur backend Anda mengizinkannya, opsi yang lebih baik adalah penyeimbangan beban global dengan opsi failover. Dengan begitu, semua server dan bandwidth dapat dimainkan sebanyak mungkin. Alih-alih menyisipkan server tambahan yang tersedia pada kegagalan, pengaturan ini menarik server yang gagal dari layanan sampai pulih.

Jawaban singkatnya: itu berhasil, tetapi Anda harus memahami keterbatasannya.

Saya percaya gagasan failover dimaksudkan untuk pengelompokan, tetapi karena itu bisa juga berjalan solo masih memungkinkan untuk beroperasi dalam ketersediaan satu-ke-satu.

Saya akan merekomendasikan agar Anda memilih A, pilih pusat data yang multihomed di AS sendiri, atau B, host server nama Anda di cloud publik. BENAR-BENAR tidak mungkin EC2, atau HP, atau IBM akan turun. Hanya pemikiran saja. Sementara DNS bekerja sebagai perbaikan, itu hanya perbaikan untuk desain yang buruk dalam fondasi jaringan dalam kasus ini.

Pilihan lain, tergantung pada lingkungan Anda, adalah menggunakan kombinasi dengan IPSLA, PBR dan FHRP untuk memenuhi kebutuhan redundansi Anda.