Ringkasan #

Panduan ini memberikan pendekatan terstruktur untuk memvalidasi dan memecahkan masalah konfigurasi GSLB (Global Server Load Balancing / GTM) di RELIANOID lingkungan, khususnya ketika layanan diharapkan untuk melakukan failover secara otomatis dari on-premises ke situs Disaster Recovery (DR).

Panduan ini juga mencakup praktik terbaik untuk IP publik berbasis aplikasi dan layanan GSLB internal.

Lingkup Validasi #

Panduan ini berlaku untuk:

• Implementasi GSLB dengan banyak lokasi (on-premises + DR)
• Layanan yang terekspos melalui IP publik
• Failover berbasis DNS menggunakan RELIANOID GSLB
• Skenario failover otomatis berdasarkan pemeriksaan kesehatan.

Komponen Kunci untuk Validasi #

Sebelum melakukan pemecahan masalah terkait perilaku failover, verifikasi hal-hal berikut:

Konfigurasi GSLB #

• Layanan GSLB telah dikonfigurasi dengan benar dengan:
  • Beberapa situs backend (on-premise + DR)
  • Kebijakan resolusi yang tepat (prioritas, latensi, dll.)
• Zona dan catatan DNS telah didefinisikan dengan benar.

Pemeriksaan Kesehatan #

• Pemeriksaan kesehatan meliputi:
  • Diaktifkan untuk semua layanan backend
  • Menargetkan titik akhir aplikasi dengan tepat (bukan hanya IP/port)
• Kode respons yang diharapkan atau validasi konten telah dikonfigurasi.

Konfigurasi DNS #

• Nilai TTL dikonfigurasi dengan tepat (TTL rendah disarankan untuk failover)
• DNS otoritatif mengarah ke RELIANOID GSLB

Memvalidasi Failover dari On-Premise ke DR #

Langkah 1: Konfirmasi Operasi Normal (Aktif Utama) #

• Permintaan resolusi DNS:

  menggali

• Verifikasi bahwa:
  • IP yang berhasil diidentifikasi sesuai dengan situs lokal.
  • Aplikasi ini mudah diakses dan sehat.

Langkah 2: Simulasikan Kegagalan #

Memicu kondisi kegagalan pada situs utama:

• Hentikan layanan backend
• Blokir titik akhir pemeriksaan kesehatan
• Nonaktifkan farm atau backend

Langkah 3: Validasi Deteksi Pemeriksaan Kesehatan #

• Memastikan RELIANOID menandai situs utama sebagai DOWN
• Periksa log dan pemantauan untuk memastikan:
  • Pemeriksaan kesehatan gagal seperti yang diperkirakan.
  • Tidak ada hasil positif/negatif palsu.

Langkah 4: Validasi Failover DNS #

• Jalankan ulang kueri DNS:

  menggali

• Hasil yang diharapkan:
  • Alamat IP sekarang seharusnya mengarah ke situs DR.

Catatan: Cache DNS dapat menunda propagasi tergantung pada TTL.

Langkah 5: Validasi Ketersediaan Aplikasi #

• Akses aplikasi menggunakan IP DR yang telah diresolusi.
• Konfirmasi:
  • Aplikasi berfungsi sepenuhnya.
  • Tidak ada masalah ketergantungan (DB, API, dll.)

Masalah Umum dan Pemecahan Masalah #

Failover Tidak Terpicu #

• Pemeriksaan kesehatan terlalu longgar (misalnya, TCP вместо HTTP)
• Titik akhir pemeriksaan kesehatan yang salah
• Backend masih merespons sebagian.

Perbaikan : Gunakan pemeriksaan tingkat aplikasi (status HTTP, isi respons)

DNS Masih Mengarah ke Server Utama #

• TTL terlalu tinggi
• Caching DNS sisi klien
• Server DNS rekursif tidak diperbarui

Memperbaiki :

• TTL lebih rendah (misalnya, 30–60 detik)
• Bersihkan cache DNS lokal
• Uji dengan resolver eksternal (dig @8.8.8.8)

Situs DR Tidak Melayani Lalu Lintas #

• Backend DR tidak dikonfigurasi dengan benar.
• Ketergantungan yang hilang (basis data, penyimpanan, otentikasi)
• Masalah firewall atau routing

Perbaikan : Validasi kesiapan seluruh tumpukan DR, bukan hanya penyeimbang beban.

Pengalihan Kegagalan Intermiten (Berkedip) #

• Pemeriksaan kesehatan yang tidak stabil
• Latensi jaringan atau kehilangan paket
• Respons backend yang tidak konsisten

Memperbaiki :

• Sesuaikan interval dan ambang batas pemeriksaan kesehatan.
• Meningkatkan toleransi kegagalan

Pertimbangan Kekayaan Intelektual Publik Berdasarkan Aplikasi #

Saat menggunakan IP publik per situs:

• Pastikan setiap situs mengiklankan IP publiknya sendiri.
• GSLB harus mengembalikan IP yang benar untuk setiap situs.
• Mengesahkan:
  • Aturan NAT dan firewall
  • Sertifikat SSL per titik akhir
  • Perilaku aplikasi yang konsisten di seluruh situs.

Pedoman untuk Layanan Internal GSLB #

Untuk layanan internal saja (DNS pribadi / aplikasi internal):

Konfigurasi DNS #

• Gunakan server DNS internal yang terintegrasi dengan RELIANOID GSLB
• Pastikan klien menyelesaikan masalah melalui penyelesai internal yang tepat.

Pertimbangan Jaringan #

• Verifikasi perutean antar situs (VPN/MPLS)
• Pastikan situs DR dapat dijangkau dari semua jaringan klien.

Pemeriksaan Kesehatan #

• Gunakan titik akhir internal (IP pribadi)
• Validasi respons lapisan aplikasi

Penghindaran Otak Terbelah #

• Pastikan sinkronisasi yang tepat antara node GSLB.
• Hindari skenario di mana kedua situs dianggap aktif secara tidak benar.

Praktik Terbaik #

• Gunakan nilai TTL rendah untuk failover yang lebih cepat.
• Selalu gunakan pemeriksaan kesehatan tingkat aplikasi.
• Lakukan latihan failover secara berkala
• Pantau resolusi DNS secara global.
• Pastikan konfigurasi sama antara sistem utama dan sistem pemulihan bencana (DR).

Daftar Periksa Validasi #

[ ] Layanan GSLB dikonfigurasi dengan semua situs
[ ] Pemeriksaan kesehatan tervalidasi dan dapat diandalkan
[ ] TTL dikonfigurasi dengan tepat
[ ] Lingkungan DR beroperasi penuh
[ ] Failover DNS telah diuji dan dikonfirmasi
[ ] Aplikasi diuji setelah failover
[ ] Layanan internal divalidasi (jika berlaku)

Ringkasan #

Validasi yang tepat dari RELIANOID GSLB memastikan failover otomatis yang lancar dari lingkungan on-premises ke lingkungan DR, meminimalkan waktu henti dan menjaga kontinuitas layanan.

Keberhasilan implementasi memerlukan koordinasi antara:

• konfigurasi DNS
• Pemeriksaan kesehatan
• Kesiapan aplikasi
• Desain jaringan