Cara Menyiapkan DNS Failover agar Website Tetap Bisa Diakses

Apa yang terjadi pada website bisnismu kalau server utamanya mati jam dua pagi? Tanpa persiapan, website tidak bisa dibuka sampai ada orang yang bangun, sadar, dan memperbaikinya. DNS failover adalah salah satu cara agar pengunjung otomatis diarahkan ke server cadangan begitu server utama terdeteksi bermasalah.

Cara kerjanya sederhana. Penyedia DNS rutin mengecek kesehatan server utama. Begitu pengecekan gagal beberapa kali berturut-turut, record DNS otomatis diganti ke alamat server cadangan. Saat server utama pulih, record kembali seperti semula. Yang tidak sederhana adalah persiapannya, dan itulah yang dibahas langkah demi langkah di bawah.

Apa batasan DNS failover yang perlu dipahami?

DNS failover bukan tombol ajaib. Ada dua batasan yang perlu kamu terima sejak awal:

• Ada jeda. Pengunjung yang resolver-nya sudah menyimpan IP lama di cache akan tetap diarahkan ke server mati sampai TTL habis. Jadi failover lewat DNS biasanya butuh beberapa menit, bukan sekejap.
• Cadangan hanya sebagus datanya. Kalau server cadangan berisi data seminggu lalu, pengunjung memang bisa membuka website, tapi pesanan atau artikel terbaru tidak ada.

Untuk website company profile atau blog, jeda beberapa menit biasanya bisa diterima. Untuk toko online dengan transaksi terus-menerus, DNS failover cocok sebagai lapisan pertama, tapi perlu dipikirkan juga bagaimana database tetap konsisten.

Langkah menyiapkan DNS failover

Langkah 1: Siapkan server cadangan di lokasi berbeda

Server cadangan sebaiknya tidak berada di mesin fisik atau pusat data yang sama dengan server utama. Kalau keduanya ada di lokasi yang sama, gangguan listrik atau jaringan di lokasi itu akan menjatuhkan keduanya sekaligus. Server cadangan bisa berupa VPS di penyedia atau region lain dengan sistem operasi dan versi software yang sama.

Langkah 2: Sinkronkan file dan database

Ini langkah yang paling menentukan. Beberapa pilihan, dari yang paling sederhana:

• Sinkron berkala. File disalin dengan rsync dan database di-dump lalu dipulihkan di server cadangan lewat cron, misalnya setiap jam. Mudah, tapi ada data yang bisa hilang di antara jadwal.
• Replikasi database. MySQL, MariaDB, dan PostgreSQL punya fitur replikasi bawaan. Server cadangan menerima perubahan hampir seketika, tapi pengaturannya lebih teknis.
• Website statis. Kalau website bisa diekspor menjadi file statis, cadangannya cukup salinan file. Ini paling mudah dibuat redundan.

Apa pun pilihannya, pastikan backup tetap berjalan terpisah. Failover melindungi dari server mati, bukan dari data terhapus atau terkena ransomware. Untuk itu ikuti prinsip di aturan backup 3-2-1-1-0.

Langkah 3: Pilih penyedia DNS yang punya health check

DNS biasa tidak tahu apakah server hidup atau mati. Kamu butuh penyedia DNS dengan fitur health check dan failover. Contohnya Amazon Route 53 yang punya health check dan kebijakan routing failover¹, atau Cloudflare Load Balancing yang memantau endpoint dari banyak pusat data dan memindahkan trafik ke endpoint yang sehat². Cloudflare menyebut Load Balancing sebagai fitur tambahan (add-on), jadi cek biayanya di dashboard sebelum memakai.

Banyak penyedia DNS terkelola lain juga menawarkan fitur serupa dengan nama monitoring atau failover. Bandingkan dari sisi seberapa sering mengecek, dari berapa lokasi, dan apakah ada notifikasi.

Langkah 4: Buat endpoint health check yang jujur

Health check yang hanya mengecek port 80 terbuka bisa tertipu. Web server bisa saja hidup sementara database mati dan setiap halaman menampilkan error. Lebih baik buat halaman khusus, misalnya /health, yang ikut mengecek koneksi ke database lalu mengembalikan kode 200 bila semua normal dan kode error bila tidak.

Jaga halaman ini tetap ringan agar pengecekan berulang tidak membebani server.

Langkah 5: Atur TTL record yang pendek

TTL menentukan berapa lama resolver boleh menyimpan jawaban DNS. Dengan TTL satu hari, failover praktis tidak berguna karena banyak pengunjung masih memegang IP lama. Untuk record yang dilindungi failover, TTL pendek seperti 60 sampai 300 detik lebih masuk akal. Penjelasan lengkap soal TTL ada di artikel tentang TTL dan propagasi DNS.

Perlu diingat, sebagian resolver tidak selalu patuh pada TTL yang sangat pendek. Itu sebabnya jeda failover tetap ada.

Langkah 6: Konfigurasikan aturan failover

Di panel penyedia DNS, umumnya kamu akan:

1. Mendaftarkan IP server utama sebagai primary dan IP server cadangan sebagai secondary.
2. Menghubungkan health check ke server utama.
3. Menentukan berapa kali gagal berturut-turut sebelum dianggap mati.
4. Mengaktifkan notifikasi email atau webhook saat status berubah.

Jangan pasang dua record A berbeda untuk nama yang sama sebagai pengganti failover. Itu disebut round robin, dan resolver akan membagi pengunjung ke kedua IP tanpa peduli salah satunya mati.

Langkah 7: Pastikan SSL ada di kedua server

Server cadangan harus memiliki sertifikat SSL yang valid untuk domain yang sama. Kalau tidak, pengunjung yang dialihkan akan melihat peringatan keamanan. Untuk Let's Encrypt, ingat bahwa validasi HTTP-01 hanya berhasil di server yang sedang ditunjuk DNS. Server cadangan bisa memakai validasi DNS-01, atau menyalin sertifikat dari server utama secara berkala.

Langkah 8: Uji dengan mematikan server utama

Failover yang tidak pernah diuji sama saja dengan tidak punya failover. Pilih jam sepi, hentikan web server utama, lalu pantau:

dig domainmu.com A +short

Catat berapa lama sampai IP berubah ke server cadangan, dan apakah website di server cadangan benar-benar berfungsi, termasuk login dan formulir. Setelah itu hidupkan lagi server utama dan pastikan record kembali.

Pendekatan mana yang cocok untuk website kamu?

Bagian penting yang sering terlupa adalah pemantauan. Failover otomatis tidak berarti masalah selesai sendiri. Pasang pemantauan terpisah, misalnya dengan Uptime Kuma, agar tim tahu server utama sedang mati dan bisa segera memperbaikinya.

Checklist sebelum menganggap failover siap:

• Server cadangan ada di lokasi atau penyedia berbeda.
• Sinkron file dan database berjalan, dan jedanya diketahui.
• Health check mengecek halaman yang benar-benar menyentuh database.
• TTL record dipendekkan.
• SSL valid di kedua server.
• Uji mati-hidup sudah dilakukan dan hasilnya dicatat.