it-swarm-id.com

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 apa lagi 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?

172
Lin

Maksud saya dengan '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 memberikan 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 bervariasi TTL tersisa. Hingga TTL berakhir, ini dapat terhubung ke server mati. Ada cara yang lebih cepat untuk menyelesaikan failover daripada ini.
  • Karena hal di atas, Anda cenderung mengatur TTL cukup rendah, katakan 5-10 menit. Tetapi pengaturan yang lebih tinggi memberikan manfaat kinerja (sangat kecil), dan dapat membantu penyebaran DNS Anda bekerja andal bahkan jika ada kesalahan pendek 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 butuhkan untuk firewall, load balancers, dan sakelar Anda.
  • Siapkan strategi komunikasi untuk kegagalan pusat data lengkap, dan sesekali kegagalan saklar/server basis data/sumber daya lain yang tidak mudah dicerminkan.

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

94
Jesper M

Kegagalan DNS sangat berhasil. Saya telah menggunakannya selama bertahun-tahun untuk secara manual mengalihkan 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 - sisa lalu lintas yang mengabaikan TTL menggelikan. Kegagalan DNS adalah teknik yang solid.

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 cocok 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 DNS failover berfungsi - email saya, saya senang berbagi.

47
Scott McDonald

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 ketika cache DNS pengguna habis, dan mereka berakhir menuju ke server lain.

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

32
Cian

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 proksi 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

19
Valentino Miazzo

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) Peramban 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 Anda TTL menjadi beberapa menit, bukan beberapa hari atau minggu sehingga dalam kasus suatu pemadaman, Anda dapat dengan cepat menghapus server dari DNS Anda. Orang lain telah 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 Anda untuk nameserver ke nilai yang cukup rendah juga. Saya bisa memiliki rincian teknis yang salah di sini, tetapi ada lebih dari satu = TTL pengaturan yang Anda butuhkan untuk benar-benar bertahan melawan satu titik kegagalan.

3) Jika Anda mempublikasikan API web, REST layanan, 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 disarankan". Inilah mengapa saya mengatakan itu. Pertama, aplikasi yang menggunakan URL tersebut biasanya bukan browser, sehingga tidak memiliki properti failover/logika browser umum 30 detik. Kedua, apakah atau tidak entri DNS kedua disebut 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 klien API/REST app (di bawah sampulnya, apakah panggilan perpustakaan get_addr, dan kapan? Jika soket menggantung atau ditutup, 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.

12
GregW

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 dari awal ... sehingga itu akan berfungsi juga sebagai perangkat keras. Saya tidak yakin bagaimana DME melakukannya, tetapi kami memiliki 3 dari 17 PoP terdekat kami memantau 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.

Beberapa orang suka menggunakan kedua server sekaligus ... dan dalam hal ini dapat melakukan sesuatu seperti penyeimbangan muatan round robin ... atau penyeimbangan beban 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 ... ubah rute 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...

9
Ryan

Pilihan lain adalah untuk mengatur server nama 1 di lokasi A dan server nama 2 di lokasi B, tetapi mengatur masing-masing sehingga semua catatan 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, itu 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.

5
Amal

Alternatifnya adalah sistem failover berbasis BGP. Ini tidak mudah untuk diatur, tetapi harus menjadi bukti. Atur situs A di satu lokasi, situs B dalam detik semua dengan alamat IP lokal, lalu dapatkan kelas C atau blok ip lainnya 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
Kyle Hodgson

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.

3
thelsdj

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.

2
Greeblesnort

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 juga opsi TTL dan failover DNS. Kami tidak akan menjalankan bisnis 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, ini 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 waktu bangun untuk 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 berhasil, tetapi apakah itu untuk semua orang dan setiap anggaran? Mungkin tidak, tetapi sampai Anda mencobanya dan melakukan tes sendiri, sulit untuk diabaikan jika Anda adalah bisnis kecil hingga menengah dengan anggaran TI terbatas yang menginginkan waktu kerja terbaik.

2

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/

1
Ricardo Polo

"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 jenis 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".

1
spenser

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

0
Seth

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.

0
spenser