Kebijakan pemilihan rute DNS dan health check

Anda dapat mengonfigurasi kebijakan pemilihan rute DNS untuk set data resource di zonapribadi ataupublik untuk mengarahkan traffic berdasarkan kriteria tertentu. Buat set data resource dengan nilai kebijakan pemilihan rute tertentu untuk menyiapkan kebijakan tersebut. Nilai ini menentukan cara Cloud DNS mengarahkan traffic kueri.

Cloud DNS mendukung kebijakan pemilihan rute berikut:

• Kebijakan pemilihan rute round robin berbobot (WRR): Gunakan kebijakan pemilihan rute WRR untuk menetapkan bobot yang berbeda ke setiap set data resource untuk nama DNS. Kebijakan pemilihan rute WRR membantu memastikan bahwa traffic didistribusikan sesuai dengan bobot yang dikonfigurasi. Menggabungkan kebijakan pemilihan rute WRR dan geolokasi tidak didukung.

  Catatan: Resolver dapat meng-cache dan menyajikan respons ke berbagai klien hingga time to live (TTL) data resource berakhir. Perilaku bawaan pengarahan traffic DNS ini terkadang dapat menyebabkan pengarahan traffic yang tidak tepat.

• Kebijakan pemilihan rute geolokasi: Gunakan kebijakan pemilihan rute geolokasi untuk menentukan geolokasi sumber dan memberikan respons yang sesuai untuk geolokasi tersebut. Kebijakan pemilihan rute geolokasi menerapkan kecocokan terdekat untuk lokasi sumber jika tidak ada item kebijakan yang sama persis dengan sumber traffic.

  • Kebijakan pemilihan rute geolokasi dengan pembatasan wilayah: Gunakan kebijakan pemilihan rute geolokasi dengan pembatasan wilayah untuk membatasi traffic ke geolokasi tertentu meskipun semua endpoint di geolokasi tersebut tidak responsif.

• Kebijakan pemilihan rute failover: Gunakan kebijakan pemilihan rute failover untuk menyiapkan konfigurasi pencadangan aktif.

Kebijakan pemilihan rute DNS tidak dapat dikonfigurasi untuk zona pribadi berikut:

• Zona penerusan
• Zona peering DNS
• Zona pencarian balik yang dikelola
• Zona Direktori Layanan

Kebijakan pemilihan rute WRR

Kebijakan pemilihan rute WRR memungkinkan Anda menentukan bobot yang berbeda per target DNS, dan Cloud DNS memastikan bahwa traffic Anda didistribusikan sesuai dengan bobot tersebut. Anda dapat menggunakan kebijakan ini untuk mendukung konfigurasi active-active atau active-passive manual. Anda juga dapat memisahkan traffic antara layanan versi produksi dan eksperimental.

Cloud DNS mendukung health check dan failover dalam kebijakan pemilihan rute untuk load balancer internal dan endpoint eksternal. Cloud DNS mengaktifkan failover otomatis saat endpoint gagal dalam health check. Selama failover, Cloud DNS akan otomatis menyesuaikan pemisahan traffic di antara endpoint lain yang responsif. Untuk mengetahui informasi selengkapnya, lihat Health check.

Kebijakan pemilihan rute geolokasi

Kebijakan pemilihan rute geolokasi memungkinkan Anda memetakan traffic yang berasal dari geografi sumber (regionGoogle Cloud ) ke target DNS tertentu. Gunakan kebijakan ini untuk mendistribusikan permintaan masuk ke berbagai instance layanan berdasarkan asal traffic. Anda dapat menggunakan fitur ini dengan traffic dariGoogle Cloud luar atau dengan traffic yang berasal dari dalam Google Cloud dan ditujukan untuk Load Balancer Jaringan passthrough internal. Cloud DNS menggunakan region tempat kueri memasukkan Google Cloud sebagai geografi sumber.

Kebijakan pemilihan rute geolokasi memetakan sumber secara berbeda untuk DNS publik dan pribadi dengan cara berikut:

• Untuk DNS publik, alamat IP sumber atau subnet klien mekanisme ekstensi untuk DNS (EDNS) kueri digunakan.
• Untuk DNS pribadi, subnet klien EDNS tidak digunakan. Sebagai gantinya, lokasi kueri adalah lokasi sistem yang mengirimkan paket untuk kueri:
  • Untuk kueri dari instance virtual machine (VM) Compute Engine dengan antarmuka jaringan di jaringan VPC, lokasi kueri adalah region yang berisi instance VM.
  • Untuk kueri yang diterima oleh titik entri kebijakan server masuk, lokasi kueri adalah region tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, atau Router appliance yang menerima paket untuk kueri tersebut. Region alamat IP titik entri tidak relevan. Untuk mengetahui informasi selengkapnya, lihat Jaringan dan region untuk kueri masuk.

Cloud DNS mendukung health check dan failover dalam kebijakan pemilihan rute untuk load balancer internal dan endpoint eksternal. Cloud DNS mengaktifkan failover otomatis saat endpoint gagal dalam health check. Saat Anda menggunakan kebijakan pemilihan rute geolokasi, traffic akan di-failover ke geolokasi terdekat berikutnya dengan traffic sumber.

Kebijakan pemilihan rute geolokasi dengan pembatasan wilayah

Pembatasan wilayah membantu memastikan bahwa traffic diarahkan ke region tertentu, meskipun semua endpoint dalam region tersebut gagal dalam health check.

Jika pembatasan wilayah dinonaktifkan dan terjadi kegagalan health check untuk geolokasi tertentu, traffic akan otomatis di-failover ke geolokasi terdekat berikutnya. Namun, saat pembatasan wilayah diaktifkan, failover otomatis ini tidak terjadi. Sebagai server yang kredibel, Cloud DNS harus menampilkan nilai, dan dalam skenario ini, Cloud DNS menampilkan semua alamat IP tanpa diubah saat endpoint gagal dalam health check.

Kebijakan pemilihan rute failover

Kebijakan pemilihan rute failover memungkinkan Anda menyiapkan konfigurasi pencadangan aktif untuk memberikan ketersediaan tinggi bagi resource internal dalam jaringan VPC Anda.

Dalam operasi normal, Cloud DNS selalu menampilkan alamat IP dari set active. Jika semua alamat IP dalam set active menjadi tidak responsif, Cloud DNS akan menyajikan alamat IP dari set backup. Jika Anda mengonfigurasi set backup sebagai kebijakan pemilihan rute geolokasi, set tersebut akan beroperasi seperti yang dijelaskan di bagian Kebijakan pemilihan rute geolokasi. Jika Anda mengonfigurasi set backup untuk load balancer internal, Cloud DNS akan melakukan health check pada semua alamat IP virtual (VIP) cadangan.

Cloud DNS memungkinkan Anda secara bertahap mengirimkan traffic ke alamat VIP cadangan sehingga Anda dapat memverifikasi bahwa alamat VIP cadangan tersebut berfungsi. Anda dapat mengonfigurasi persentase traffic yang dikirim ke cadangan sebagai pecahan dari 0 hingga 1. Anda dapat memicu failover secara manual dengan mengirim 100% traffic ke alamat VIP cadangan. Nilai umumnya adalah 0,1. Health check hanya dapat diterapkan ke load balancer internal dan endpoint eksternal.

Health check

Cloud DNS mendukung health check dan failover dalam kebijakan pemilihan rute untuk load balancer internal dan endpoint eksternal berikut:

• Load Balancer Aplikasi Internal (regional dan lintas region)
• Load Balancer Jaringan passthrough internal
• Load Balancer Jaringan proxy internal (Pratinjau)
• Endpoint eksternal

Penting: Pastikan Anda mengaktifkan akses global untuk load balancer regional.

Jika Anda ingin menggunakan health check dengan zona terkelola dan DNS Security Extensions (DNSSEC) diaktifkan, hanya satu alamat IP yang dapat digunakan dalam setiap item kebijakan(WRR atau geolokasi). Anda tidak dapat mencampur alamat IP yang telah dilakukan health check dan alamat IP yang belum dilakukan health check dalam kebijakan tertentu.

Untuk mengetahui informasi tentang praktik terbaik yang perlu diperhatikan saat Anda mengonfigurasi data Cloud DNS dan health check, lihat Praktik terbaik.

Health check untuk load balancer internal

Health check untuk load balancer internal hanya tersedia di zona pribadi.

Untuk Load Balancer Aplikasi internal dan Load Balancer Jaringan proxy internal, Cloud DNS mempertimbangkan responsivitas load balancer itu sendiri selama keputusan pemilihan rute. Saat load balancer menerima kueri, load balancer hanya akan mendistribusikan traffic ke layanan backend yang responsif. Untuk membantu memastikan terdapat backend yang responsif, Anda dapat mengelola siklus proses backend menggunakan layanan seperti grup instance terkelola (MIG). Cloud DNS tidak perlu mengetahui status responsivitas backend individual. Load balancer menangani tugas ini.

Untuk Load Balancer Jaringan passthrough internal, Cloud DNS memeriksa informasi responsivitas di backend instance individual load balancer. Cloud DNS menerapkan nilai minimum default 20%. Jika setidaknya 20% backend instance responsif, endpoint load balancer dianggap responsif. Kebijakan pemilihan rute DNS menandai endpoint sebagai responsif atau tidak responsif berdasarkan nilai minimum ini, dan mengarahkan traffic dengan tepat.

Satu alamat IP virtual (VIP) Load Balancer Jaringan passthrough internal dapat memiliki beberapa backend instance. Jika Load Balancer Jaringan passthrough internal tidak memiliki backend instance, Cloud DNS tetap menganggapnya responsif. Agar health check berfungsi dengan semestinya, tentukan setidaknya satu backend instance dalam konfigurasi load balancer.

Jika endpoint ditandai tidak responsif, kondisi berikut dapat terjadi:

• Jika ada beberapa alamat VIP yang diprogram berdasarkan kebijakan, hanya alamat VIP yang responsif yang ditampilkan.

• Jika semua alamat VIP yang diprogram terhadap bucket kebijakan tidak responsif, baris kebijakan tersebut telah gagal. Perilaku berikut berlaku:

  • Untuk kebijakan WRR, Cloud DNS mendistribusikan traffic secara proporsional di antara endpoint responsif lain yang ditentukan dalam kebijakan tersebut.
  • Untuk kebijakan geolokasi yang tidak mengaktifkan pembatasan, traffic beralih ke endpoint di geografi terdekat berikutnya dengan region Google Cloud sumber yang ditentukan dalam kebijakan tersebut.
  • Untuk kebijakan geolokasi yang mengaktifkan pembatasan wilayah, Cloud DNS mendistribusikan traffic ke alamat VIP yang paling dekat dengan region Google Cloud sumber yang ditentukan dalam kebijakan tersebut.
  • Untuk kebijakan failover, Cloud DNS mengalihkan traffic ke endpoint cadangan yang ditentukan dalam kebijakan tersebut.
  • Jika semua bucket kebijakan tidak responsif, Cloud DNS akan berperilaku seolah-olah semua endpoint responsif. Skenario ini berpotensi menyebabkan traffic didistribusikan ke endpoint yang tidak responsif.

Untuk mengetahui informasi selengkapnya tentang health check untuk load balancer internal, lihat Ringkasan health check.

Health check untuk endpoint eksternal

Health check untuk endpoint eksternal hanya tersedia di zona publik. Endpoint yang ingin Anda lakukan health check harus dapat diakses melalui internet publik. Endpoint yang ditentukan dapat berupa alamat IP dan port eksternal apa pun, termasuk VIP Load Balancer Aplikasi eksternal global, VIP Load Balancer Aplikasi eksternal regional, VIP Load Balancer Jaringan proxy eksternal global, endpoint lokal, atau endpoint lain apa pun yang dapat diakses melalui internet publik.

Gunakan health check untuk endpoint eksternal dalam skenario berikut:

• Untuk mengalihkan traffic ke Load Balancer Aplikasi eksternal regional jika backend Load Balancer Aplikasi eksternal global atau backend Load Balancer Jaringan proxy eksternal global menjadi tidak responsif.
• Untuk mengalihkan traffic ke Load Balancer Aplikasi eksternal regional lain jika backend Load Balancer Aplikasi eksternal regional tertentu menjadi tidak responsif.
• Untuk memantau responsivitas endpoint lokal atau endpoint lain yang dapat dijangkau di internet publik.

Saat Anda membuat kebijakan pemilihan rute DNS dengan health check untuk endpoint eksternal, Cloud DNS akan mengirimkan pemeriksaan health check ke endpoint Anda. Pemeriksaan health check ini berasal dari tiga region sumber Google Cloud yang Anda tentukan. Pemeriksa health check setiap region berjalan secara mandiri, dan Cloud DNS menggabungkan hasilnya untuk menentukan responsivitas endpoint secara keseluruhan. Dalam setiap region, tiga instance pemeriksa health check memeriksa setiap endpoint. Jika satu pemeriksaan gagal, Cloud DNS masih dapat menentukan responsivitas endpoint dengan pemeriksaan yang lain. Artinya, Anda memiliki total sembilan pemeriksa untuk setiap endpoint, dan setiap pemeriksaan dilakukan pada frekuensi yang Anda tentukan dalam interval pemeriksaan health check. Berdasarkan parameter kebijakan pemilihan rute dan informasi responsivitas, Cloud DNS memilih endpoint dan rute traffic ke endpoint yang dipilih.

Cloud DNS mendukung protokol TCP, HTTP, dan HTTPS dengan beberapa batasan berikut:

• Kolom permintaan TCP tidak didukung.
• Kolom proxyHeader untuk HTTP, HTTPS, dan TCP tidak didukung.

Protokol SSL, HTTP/2, dan gRPC tidak didukung.

Untuk protokol TCP, Cloud DNS mencoba menghubungkan ke endpoint. Untuk protokol HTTP dan HTTPS, Cloud DNS memverifikasi bahwa endpoint menampilkan kode respons HTTP 200. Anda juga dapat mengonfigurasi health check berbasis konten, dengan Cloud DNS memeriksa apakah respons berisi string tertentu.

Tidak seperti health check untuk load balancer internal, health check Cloud DNS untuk endpoint eksternal tidak berasal dari rentang alamat IP tetap. Rentang alamat IP sumber pemeriksaan dapat berubah dari waktu ke waktu.

Protokol dan port yang Anda tentukan saat membuat health check menentukan cara pemeriksaan health check dilakukan. Jika Anda tidak menentukan port, Cloud DNS akan menggunakan port 80. Untuk membantu memastikan bahwa health check berfungsi dengan benar, konfigurasi aturan firewall Anda untuk mengizinkan pemeriksaan health check dari alamat IP sumber mana pun dan di port tertentu yang dikonfigurasi dalam health check.

Jika Anda belum mengonfigurasi firewall untuk mengizinkan pemeriksaan health check, pemeriksaan akan gagal, sehingga Cloud DNS menganggap endpoint yang diblokir sebagai tidak responsif. Jika setiap endpoint ditampilkan sebagai tidak responsif, Cloud DNS tetap menyediakannya semua sebagai hasil, meskipun tidak responsif.

Interval health check

Cloud DNS secara berkala mengirimkan pemeriksaan health check sesuai dengan interval health check. Misalnya, jika interval health check adalah 30 detik, Cloud DNS akan mengirimkan satu pemeriksaan health check setiap 30 detik.

Untuk health check endpoint eksternal Cloud DNS, interval health check harus antara 30 dan 300 detik.

Kebijakan pemilihan rute round robin berbobot dan health check

Cloud DNS mendukung bobot dari 0 hingga 1000, termasuk keduanya. Jika health check disertakan, hal berikut akan terjadi:

• Jika Anda mengonfigurasi beberapa target, semuanya dengan bobot 0, traffic akan didistribusikan secara merata di antara target.
• Jika Anda mengonfigurasi target berbobot baru yang bukan nol, target tersebut akan menjadi target utama, dan semua traffic akan dialihkan ke target tersebut.
• Saat Anda menambahkan lebih banyak target berbobot bukan nol, Cloud DNS akan menghitung pemisahan traffic secara dinamis di antara target (dengan setiap permintaan) dan mendistribusikan traffic dengan tepat. Misalnya, jika Anda telah mengonfigurasi tiga target berbobot 0, 25, dan 75, target berbobot 0 tidak akan mendapatkan traffic, target berbobot 25 akan mendapatkan seperempat traffic, dan target yang tersisa akan mendapatkan tiga perempat traffic masuk.
• Jika health check dikaitkan dengan target berbobot bukan nol, tetapi tidak dengan target berbobot nol, target berbobot nol akan selalu dianggap responsif. Jika semua data yang bukan nol tidak responsif, Cloud DNS akan menampilkan data berbobot nol.
• Jika health check dikaitkan dengan data yang berbobot bukan nol dan nol, dan jika semua data gagal dalam health check, Cloud DNS akan menampilkan target yang berbobot bukan nol dan mengabaikan target yang berbobot nol.
• Saat Cloud DNS memilih bucket bobot untuk ditampilkan kepada pemohon (satu item kebijakan), hanya alamat IP dalam bucket bobot tersebut yang ditampilkan. Jika Anda hanya menentukan satu alamat IP dalam bucket bobot, hanya alamat IP tersebut yang ada dalam respons. Jika ada lebih dari satu alamat IP dalam bucket bobot, Cloud DNS akan menampilkan semua alamat IP dalam urutan acak.

Kebijakan pemilihan rute geolokasi dan health check

Untuk kebijakan pemilihan rute geolokasi dengan health check yang diaktifkan, hal berikut akan terjadi:

• Jika kebijakan memiliki beberapa alamat IP yang dikonfigurasi, dan semua alamat IP dilakukan health check, hanya alamat IP yang responsif yang ditampilkan.
• Jika ada kombinasi alamat IP yang telah dilakukan health check dan yang belum dilakukan health check, dan semua alamat IP yang telah dilakukan health check gagal, Cloud DNS akan menampilkan semua alamat IP yang tidak dikonfigurasi health check-nya. Dalam skenario ini, failover otomatis ke geografi terdekat berikutnya tidak terjadi.

Logging health check

Cloud DNS mendukung logging health check dan mencatat status responsivitas alamat IP yang mendukung health check saat Anda mengkueri nama DNS yang merujuk ke alamat IP tersebut.

Logging health check memungkinkan Anda melakukan hal berikut:

• Memvalidasi apakah kebijakan pemilihan rute berfungsi seperti yang diharapkan. Contoh:
  • Untuk kebijakan geolokasi, Anda dapat memvalidasi apakah kebijakan mendeteksi geografi yang benar dan menampilkan set data resource yang benar.
  • Untuk kebijakan WRR, Anda dapat memvalidasi apakah kebijakan menampilkan alamat IP dengan bobot yang benar.
• Melakukan identifikasi terhadap masalah infrastruktur dengan backend dan alamat IP tertentu yang mengalami kegagalan.
• Memecahkan masalah penyebab backend tertentu tidak pernah disertakan atau hanya backend tersebut yang ditampilkan.

Untuk mengetahui informasi selengkapnya, lihat informasi logging health check.

Jenis data yang didukung untuk kebijakan pemilihan rute DNS

Kebijakan pemilihan rute DNS tidak mendukung semua jenis data yang didukung oleh Cloud DNS.

Jenis data berikut didukung:

Jenis data	Deskripsi
A	Alamat IPv4 untuk health check internal (zona pribadi) dan eksternal (zona publik).
AAAA	Alamat IPv6 untuk health check eksternal (zona publik).
CNAME	Nama kanonis. Health check tidak didukung.
MX	Data pertukaran email. Health check tidak didukung.
SRV	Host/port (RFC 2782). Health check tidak didukung.
TXT	Data teks. Health check tidak didukung.

Langkah berikutnya

• Mengonfigurasi kebijakan pemilihan rute DNS dan health check