Menghindari batas waktu DNS ketika server dns gagal

Kami memiliki pusat data kecil dengan sekitar seratus host yang menunjuk ke 3 server dns internal (bind 9). Masalah kami muncul ketika salah satu server dns internal menjadi tidak tersedia. Pada saat itu semua klien yang menunjuk ke server itu mulai berkinerja sangat lambat.

Masalahnya tampaknya bahwa resolver stock linux tidak benar-benar memiliki konsep "gagal" ke server dns yang berbeda. Anda dapat menyesuaikan batas waktu dan jumlah coba lagi yang digunakannya, (dan atur putar sehingga ia akan bekerja melalui daftar), tetapi tidak peduli apa pun pengaturan yang digunakan seseorang, layanan kami bekerja jauh lebih lambat jika server dns primer menjadi tidak tersedia. Saat ini, ini adalah salah satu sumber gangguan layanan terbesar bagi kami.

Jawaban ideal saya adalah "RTFM: tweak /etc/resolv.conf seperti ini ...", tetapi jika itu pilihan saya belum melihatnya.

Saya bertanya-tanya bagaimana orang lain menangani masalah ini?

Saya dapat melihat 3 kemungkinan jenis solusi:

• Gunakan linux-ha / Pacemaker dan failover ips (sehingga VIP dns IP "selalu" tersedia). Sayangnya, kami tidak memiliki infrastruktur pagar yang baik, dan tanpa pagar pemacu jantung tidak berfungsi dengan baik (dalam pengalaman saya Pacemaker menurunkan ketersediaan tanpa pagar).

• Jalankan server dns lokal di setiap node, dan arahkan resolv.conf ke localhost. Ini akan berhasil, tetapi akan memberi kami lebih banyak layanan untuk dipantau dan dikelola.

• Jalankan cache lokal di setiap node. Orang-orang tampaknya menganggap nscd "rusak", tetapi dnrd tampaknya memiliki set fitur yang tepat: menandai dns server sebagai naik atau turun, dan tidak akan menggunakan server dns 'turun'.

Any-casting tampaknya hanya berfungsi pada tingkat ip routing, dan tergantung pada pembaruan rute untuk kegagalan server. Multi-casting sepertinya itu akan menjadi jawaban yang sempurna, tetapi bind tidak mendukung penyiaran atau multi-casting, dan dokumen yang saya temukan nampaknya menyarankan bahwa multicast dns lebih ditujukan pada penemuan layanan dan konfigurasi otomatis daripada penyelesaian dns reguler .

Apakah saya kehilangan solusi yang jelas?

Beberapa pilihan. Keduanya akan mendistribusikan beban DNS di server DNS Anda.

• Coba gunakan options rotatedi resolv.conf. Ini akan meminimalkan dampak server utama menjadi turun. Jika salah satu server lain sedang down, itu akan memperlambat tindakan.
• Gunakan urutan server nama yang berbeda pada klien yang berbeda. Ini akan memungkinkan beberapa klien berjalan secara normal jika server DNS utama sedang down. Ini menyebarkan dampak dari server DNS di luar layanan di sekitar.

Opsi-opsi ini dapat dikombinasikan dengan options timeout:1 attempts:5. Tingkatkan upaya jika Anda mengurangi batas waktu sehingga Anda dapat menangani server eksternal yang lambat.

Bergantung pada konfigurasi router Anda, Anda mungkin dapat mengonfigurasi server DNS Anda untuk mengambil alih alamat IP server DNS primer ketika sedang turun. Ini dapat dikombinasikan dengan teknik di atas.

CATATAN: Saya menjalankan tahun tanpa gangguan DNS yang tidak terjadwal. Seperti yang telah dicatat orang lain, saya akan bekerja untuk memecahkan masalah yang menyebabkan server DNS gagal. Langkah-langkah di atas, juga membantu dengan server DNS yang salah konfigurasi dengan menentukan server nama yang tidak dapat dijangkau.

Lihat "man resolv.conf". Anda dapat menambahkan opsi batas waktu ke resolv.conf. Standarnya adalah 5, tetapi menambahkan berikut ini ke resolv.conf akan menurunkannya menjadi 1 detik:

opsi batas waktu: 1

Perangkat lunak pengelompokan seperti detak jantung atau alat pacu jantung / corosync adalah teman Anda di sini. Sebagai contoh, kami telah menyiapkan alat pacu jantung / corosync sebagai berikut:

• Pasangkan setiap server dengan yang lain
• Per pasang memiliki 2 dns vips, biasanya satu pada masing-masing
• Jika mengikat atau server gagal, vip pindah ke server lain dalam milidetik

Jam produksi 24x7, tetapi kami sangat percaya bahwa setiap server mungkin gagal tanpa memengaruhi pelanggan. opsi rotate hanyalah solusi, saya tidak akan melakukan itu.

Jalankan server dns lokal di setiap node, dan arahkan resolv.conf ke localhost. Ini akan berhasil, tetapi akan memberi kami lebih banyak layanan untuk dipantau dan dikelola.

FWIW, ini adalah satu-satunya solusi yang dapat saya temukan untuk masalah ini. Anda perlu membatasi server untuk hanya mendengarkan di localhost, tetapi server tersebut telah sepenuhnya menghilangkan pengguna yang melihat gangguan DNS di lingkungan kami.

Salah satu efek samping yang menarik adalah bahwa jika server localhost turun karena suatu alasan, perpustakaan resolver standar tampaknya menangani failover ke server berikutnya lebih cepat daripada dalam kasus standar.

Kami telah melakukan ini selama sekitar 3 tahun sekarang dan saya belum melihat satu masalah pun yang dapat dikaitkan dengan kegagalan / pemadaman server dns yang berjalan di localhost.

Jika server nama sedang turun untuk pemeliharaan, itu adalah prosedur normal untuk mengurangi waktu habis dalam SOA untuk domain itu sebelumnya, sehingga ketika pemeliharaan terjadi, perubahan (seperti menghapus catatan NS sebelum pemeliharaan dan meletakkannya kembali setelah pemeliharaan ) menyebar dengan cepat. Perhatikan bahwa ini adalah pendekatan sisi server - mengubah resolver adalah pendekatan sisi klien dan ... kecuali Anda dapat berbicara dengan masing-masing dan setiap klien Anda dan meminta mereka untuk membuat penyesuaian ini pada mesin mereka ... mungkin tidak pendekatan yang tepat. Yah, saya kira Anda memang mengatakan hanya seratus klien semua di pusat data menggunakan server DNS internal, tetapi apakah Anda benar-benar ingin mengubah konfigurasi pada seratus klien ketika Anda bisa mengubah zona?

Saya akan memberi tahu Anda nilai-nilai mana dalam SOA yang harus disesuaikan, tetapi saya menjelajahi web untuk mencari tahu informasi yang tepat ketika saya menemukan pertanyaan ini.

Mungkin Anda bisa meletakkan server DNS di belakang load balancer? Rupanya LVS dapat menyeimbangkan UDP. Jelas membuat LB Anda sangat tersedia sehingga itu bukan titik kegagalan tunggal.

Saya tahu ini mungkin terdengar usang, tetapi bagaimana dengan membangun infrastruktur DNS yang lebih stabil dan tangguh sebagai solusi permanen untuk masalah ini.

Solusi yang lebih berpusat pada jaringan akan menggunakan dua server DNS dengan routing IP dan Anycast yang sama (khusus) . (Saya belum melihat jawaban ini di utas ini sejauh ini, tapi itulah yang digunakan di sini.)

Selama keduanya naik, server terdekat digunakan. Jika salah satu turun, lalu lintas untuk IP itu akan dialihkan ke node lain sampai muncul lagi. Ini khususnya masuk akal jika Anda memiliki dua lokasi atau lebih atau pusat data.