Pengenalan #

Panduan ini menyediakan pendekatan berstruktur untuk mengesahkan dan menyelesaikan masalah konfigurasi GSLB (Global Server Load Balancing / GTM) dalam RELIANOID persekitaran, terutamanya apabila perkhidmatan dijangka gagal secara automatik dari lokasi di premis ke tapak Pemulihan Bencana (DR).

Ia juga merangkumi amalan terbaik untuk IP awam berasaskan aplikasi dan perkhidmatan GSLB dalaman.

Skop Pengesahan #

Panduan ini terpakai kepada:

• Pelaksanaan GSLB dengan berbilang tapak (di premis + DR)
• Perkhidmatan terdedah melalui IP awam
• Kegagalan berasaskan DNS menggunakan RELIANOID GSLB
• Senario failover automatik berdasarkan pemeriksaan kesihatan

Komponen Utama untuk Disahkan #

Sebelum menyelesaikan masalah tingkah laku failover, sahkan perkara berikut:

Konfigurasi GSLB #

• Perkhidmatan GSLB dikonfigurasikan dengan betul dengan:
  • Berbilang tapak backend (on-prem + DR)
  • Dasar penyelesaian yang betul (keutamaan, kependaman, dsb.)
• Zon dan rekod DNS ditakrifkan dengan betul

Pemeriksaan Kesihatan #

• Pemeriksaan kesihatan adalah:
  • Didayakan untuk semua perkhidmatan backend
  • Menyasarkan titik akhir aplikasi dengan betul (bukan hanya IP/port)
• Kod respons yang dijangkakan atau pengesahan kandungan dikonfigurasikan

Konfigurasi DNS #

• Nilai TTL dikonfigurasikan dengan sewajarnya (TTL rendah disyorkan untuk failover)
• DNS berwibawa sedang menunjuk ke RELIANOID GSLB

Mengesahkan Failover daripada On-Prem kepada DR #

Langkah 1: Sahkan Operasi Normal (Aktif Utama) #

• Resolusi DNS pertanyaan:

  menggali

• Sahkan bahawa:
  • IP yang diselesaikan sepadan dengan tapak di premis
  • Permohonan boleh diakses dan sihat

Langkah 2: Simulasikan Kegagalan #

Cetuskan keadaan kegagalan di tapak utama:

• Hentikan perkhidmatan backend
• Titik akhir semakan kesihatan blok
• Lumpuhkan ladang atau bahagian belakang

Langkah 3: Sahkan Pengesanan Pemeriksaan Kesihatan #

• Sahkan RELIANOID menandakan tapak utama sebagai BAWAH
• Semak log dan pemantauan untuk memastikan:
  • Pemeriksaan kesihatan gagal seperti yang dijangkakan
  • Tiada positif/negatif palsu

Langkah 4: Sahkan Kegagalan DNS #

• Jalankan semula pertanyaan DNS:

  menggali

• Hasil yang diharapkan:
  • IP kini sepatutnya diselesaikan ke tapak DR

Nota: Caching DNS mungkin melambatkan penyebaran bergantung pada TTL.

Langkah 5: Sahkan Ketersediaan Aplikasi #

• Akses aplikasi menggunakan IP DR yang telah diselesaikan
• Sahkan:
  • Aplikasi berfungsi sepenuhnya
  • Tiada isu kebergantungan (DB, API, dll.)

Isu Biasa dan Penyelesaian Masalah #

Kegagalan Tidak Dicetuskan #

• Pemeriksaan kesihatan terlalu permisif (cth., pengesahan TCP dan bukannya HTTP)
• Titik akhir pemeriksaan kesihatan yang salah
• Bahagian belakang masih bertindak balas sebahagiannya

Menetapkan: Gunakan semakan peringkat aplikasi (status HTTP, badan respons)

DNS Masih Beralih ke Utama #

• TTL terlalu tinggi
• Cache DNS bahagian klien
• Pelayan DNS rekursif tidak disegarkan semula

Menetapkan:

• TTL yang lebih rendah (cth., 30–60 saat)
• Siram cache DNS setempat
• Uji dengan penyelesai luaran (dig @8.8.8.8)

Laman DR Tidak Melayani Trafik #

• Bahagian belakang DR tidak dikonfigurasikan dengan betul
• Kebergantungan yang hilang (pangkalan data, storan, pengesahan)
• Isu tembok api atau penghalaan

MenetapkanSahkan kesediaan tindanan DR penuh, bukan sekadar pengimbang beban

Kegagalan Berselang-seli (Kepak) #

• Pemeriksaan kesihatan yang tidak stabil
• Kependaman rangkaian atau kehilangan paket
• Respons backend yang tidak konsisten

Menetapkan:

• Selang masa dan ambang semakan kesihatan talaan
• Meningkatkan toleransi kegagalan

Pertimbangan IP Awam Berasaskan Aplikasi #

Apabila menggunakan IP awam bagi setiap tapak:

• Pastikan setiap laman web mengiklankan IP awamnya sendiri
• GSLB harus mengembalikan IP yang betul bagi setiap tapak
• Sahkan:
  • Peraturan NAT dan tembok api
  • Sijil SSL setiap titik akhir
  • Tingkah laku aplikasi yang konsisten merentasi laman web

Garis Panduan untuk Perkhidmatan GSLB Dalaman #

Untuk perkhidmatan dalaman sahaja (DNS peribadi / aplikasi dalaman):

Konfigurasi DNS #

• Gunakan pelayan DNS dalaman yang disepadukan dengan RELIANOID GSLB
• Pastikan pelanggan menyelesaikan masalah melalui penyelesai dalaman yang betul

Pertimbangan Rangkaian #

• Sahkan penghalaan antara tapak (VPN/MPLS)
• Pastikan tapak DR boleh dicapai dari semua rangkaian klien

Pemeriksaan Kesihatan #

• Gunakan titik akhir dalaman (IP persendirian)
• Sahkan respons lapisan aplikasi

Pengelakan Otak Berpecah #

• Pastikan penyegerakan yang betul antara nod GSLB
• Elakkan senario di mana kedua-dua tapak dianggap aktif secara salah

Amalan Terbaik #

• Gunakan nilai TTL yang rendah untuk failover yang lebih pantas
• Sentiasa gunakan pemeriksaan kesihatan peringkat aplikasi
• Lakukan latihan failover secara berkala
• Pantau resolusi DNS secara global
• Pastikan pariti konfigurasi antara primer dan DR

Senarai Semak Pengesahan #

[ ] Perkhidmatan GSLB dikonfigurasikan dengan semua tapak
[ ] Pemeriksaan kesihatan disahkan dan boleh dipercayai
[ ] TTL dikonfigurasikan dengan sewajarnya
[ ] Persekitaran DR beroperasi sepenuhnya
[ ] Kegagalan DNS diuji dan disahkan
[ ] Aplikasi diuji selepas kegagalan
[ ] Perkhidmatan dalaman disahkan (jika berkenaan)

Ringkasan #

Pengesahan yang betul RELIANOID GSLB memastikan failover automatik yang lancar dari persekitaran di premis ke DR, meminimumkan masa henti dan mengekalkan kesinambungan perkhidmatan.

Pelaksanaan yang berjaya memerlukan penyelarasan antara:

• Konfigurasi DNS
• Pemeriksaan kesihatan
• Kesediaan permohonan
• Reka bentuk rangkaian