Kebijakan perutean DNS dan health check

Anda dapat mengonfigurasi kebijakan pemilihan rute DNS untuk kumpulan data resource secara pribadi atau zona publik untuk mengarahkan lalu lintas berdasarkan kriteria tertentu. Buat fasilitas kumpulan data dengan nilai kebijakan perutean tertentu untuk menyiapkan kebijakan tersebut. Nilai ini menentukan cara Cloud DNS merutekan traffic kueri.

Cloud DNS mendukung kebijakan pemilihan rute berikut:

  • Kebijakan pemilihan rute round robin (WRR): Menggunakan WRR kebijakan perutean untuk menetapkan bobot yang berbeda bagi setiap kumpulan data sumber daya untuk Nama DNS. Kebijakan {i>routing<i} WRR membantu memastikan bahwa lalu lintas data didistribusikan sesuai dengan bobot yang dikonfigurasi. Menggabungkan WRR dan perutean geolokasi kebijakan kami tidak didukung.

  • Kebijakan perutean geolokasi: Menggunakan geolokasi kebijakan perutean untuk menentukan geolokasi sumber dan untuk memberikan respons terhadap geografi tersebut. Kebijakan perutean geolokasi menerapkan kecocokan terdekat untuk lokasi sumber jika tidak ada item kebijakan yang sama persis dengan sumber traffic tertentu.

  • Kebijakan perutean failover: Menggunakan perutean failover kebijakan untuk menyiapkan konfigurasi pencadangan aktif.

Kebijakan perutean DNS tidak dapat dikonfigurasi untuk zona pribadi berikut:

  • Zona penerusan
  • Zona peering DNS
  • Zona pencarian terbalik terkelola
  • Zona Direktori Layanan

Kebijakan pemilihan rute WRR

Kebijakan {i>routing<i} WRR memungkinkan Anda menentukan bobot yang berbeda sesuai target DNS, dan Cloud DNS memastikan bahwa traffic Anda terdistribusi sesuai dengan bobotnya. Anda dapat menggunakan kebijakan ini untuk mendukung panduan active-active atau active-passive konfigurasi Anda. Anda dapat juga memisahkan traffic antara versi produksi dan eksperimental layanan Anda.

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

Kebijakan perutean geolokasi

Kebijakan perutean geolokasi memungkinkan Anda memetakan lalu lintas yang berasal dari sumber (region Google Cloud) sesuai target DNS tertentu. Gunakan ini mendistribusikan permintaan masuk ke berbagai layanan instance berdasarkan asal traffic. Anda dapat menggunakan fitur ini dengan traffic dari luar Google Cloud atau dengan traffic yang berasal dari Google Cloud dan terikat untuk Load Balancer Jaringan passthrough internal. Cloud DNS menggunakan region tempat memasuki Google Cloud sebagai geografi sumber.

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

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

Cloud DNS mendukung health check dan failover dalam perutean kebijakan untuk load balancer internal dan endpoint eksternal. Cloud DNS mengaktifkan failover otomatis saat endpoint gagal health check. Jika Anda menggunakan kebijakan perutean geolokasi, traffic akan gagal ke geolokasi terdekat berikutnya dengan lalu lintas sumber.

Kebijakan perutean geolokasi dengan pembatasan wilayah

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

Saat pembatasan wilayah dinonaktifkan dan kegagalan health check terjadi untuk geolokasi, lalu lintas secara otomatis akan gagal ke geolokasi terdekat berikutnya. Namun, saat pembatasan wilayah diaktifkan, failover otomatis ini tidak akan terjadi. Sebagai server otoritatif, Cloud DNS harus menghasilkan nilai, dan dalam hal ini, Cloud DNS menampilkan semua alamat IP yang tidak diubah endpoint gagal dalam health check.

Kebijakan perutean failover

Kebijakan perutean failover memungkinkan Anda menyiapkan konfigurasi pencadangan aktif untuk menyediakan ketersediaan tinggi untuk sumber daya internal dalam Jaringan VPC.

Dalam operasi normal, Cloud DNS selalu menampilkan IP dari kumpulan active. Jika semua alamat IP di active ditetapkan tidak responsif, Cloud DNS akan menyalurkan alamat IP dari backup atur. Jika Anda mengonfigurasi backup yang ditetapkan sebagai kebijakan perutean geolokasi, beroperasi seperti yang dijelaskan dalam kebijakan perutean Geolokasi bagian. Jika Anda mengonfigurasi backup yang ditetapkan untuk load balancer internal, Health check Cloud DNS memeriksa semua alamat IP virtual (VIP) cadangan.

Dengan Cloud DNS, Anda dapat secara bertahap mengalir traffic ke alamat VIP cadangan sehingga Anda dapat memverifikasi bahwa alamat VIP cadangan berfungsi. Anda dapat konfigurasi persentase lalu lintas yang dikirim ke cadangan dalam bentuk pecahan dari 0 hingga 1. Anda dapat memicu failover secara manual dengan mengirimkan 100% traffic ke alamat VIP cadangan. Nilai umumnya adalah 0,1. Health check dapat hanya berlaku untuk load balancer internal dan endpoint eksternal.

Health check

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

Saat 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 menggabungkan IP yang telah dicek kondisinya dan alamat IP yang tidak dicek kesehatannya dalam kebijakan tertentu.

Untuk informasi tentang praktik terbaik yang perlu diingat 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 secara pribadi serta region mendatang dan zonanya.

Untuk Load Balancer Aplikasi internal dan Load Balancer Jaringan proxy internal, Cloud DNS mempertimbangkan kondisi load balancer itu sendiri selama pengambilan keputusan perutean. Ketika seorang load balancer menerima kueri, lalu mendistribusikan traffic hanya ke jaringan yang dan layanan backend. Untuk membantu memastikan ada backend yang sehat, Anda dapat mengelola siklus proses backend menggunakan layanan seperti instance terkelola grup (MIG). Cloud DNS tidak perlu mengetahui status respons backend individu; load balancer menangani tugas ini.

Untuk Load Balancer Jaringan passthrough internal, Cloud DNS memeriksa informasi respons pada setiap backend instance load balancer. DNS Cloud menerapkan batas default 20%, dan jika setidaknya 20% backend instance responsif, endpoint load balancer dianggap responsif. Kebijakan perutean DNS menandai endpoint sebagai berbasis responsif atau tidak responsif pada nilai minimum ini, dan sesuaikan rute lalu lintas.

Satu alamat IP virtual (VIP) Jaringan Passthrough internal dapat memiliki beberapa backend instance Compute Engine. Jika Load Balancer Jaringan passthrough internal tidak memiliki backend instance, Cloud DNS masih menganggapnya sehat. Agar health check berfungsi dengan benar, tentukan di 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, maka hanya alamat VIP yang sehat akan dikembalikan.
  • Jika semua alamat VIP yang diprogram berdasarkan kelompok kebijakan tidak responsif, baris kebijakan itu gagal. Perilaku berikut berlaku:

    • Untuk kebijakan WRR, Cloud DNS mendistribusikan traffic secara proporsional di antara endpoint responsif lainnya yang ditentukan dalam lebih lanjut.
    • Untuk kebijakan geolokasi yang tidak mengaktifkan pagar, traffic akan beralih ke endpoint di geografi terdekat berikutnya region Google Cloud sumber yang ditentukan dalam kebijakan.
    • Untuk kebijakan geolokasi yang mengaktifkan pembatasan wilayah, Cloud DNS mendistribusikan traffic ke alamat VIP yang terdekat dengan region Google Cloud sumber yang ditentukan dalam kebijakan.
    • Untuk kebijakan failover, Cloud DNS mengalihkan traffic ke endpoint cadangan yang ditentukan dalam kebijakan.
    • Jika semua bucket kebijakan tidak responsif, Cloud DNS akan berperilaku seolah-olah semua endpoint responsif. Skenario ini dapat berpotensi menyebabkan traffic yang 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 (Pratinjau)

Health check untuk endpoint eksternal hanya tersedia di zona publik. Tujuan endpoint yang ingin Anda gunakan health check harus dapat diakses melalui di Internet. Endpoint yang ditentukan dapat berupa porta dan alamat IP eksternal, termasuk VIP Load Balancer Aplikasi eksternal global, VM Load Balancer Aplikasi eksternal regional, Virtual Load Balancer Jaringan proxy eksternal global, secara lokal endpoint lain, atau endpoint lain 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 Load Balancer Aplikasi eksternal global backend atau backend Load Balancer Jaringan proxy eksternal global menjadi tidak responsif.
  • Untuk mengubah rute traffic ke Load Balancer Aplikasi eksternal regional lain jika backend Load Balancer Aplikasi eksternal regional menjadi tidak responsif.
  • Untuk memantau kondisi endpoint lokal atau endpoint lain yang yang dapat dijangkau di internet publik.

Saat Anda membuat kebijakan perutean DNS dengan health check untuk eksternal endpoint, Cloud DNS mengirimkan pemeriksaan health check ke endpoint Anda. Ini pemeriksaan health check berasal dari tiga region sumber Google Cloud yang yang Anda tentukan. Setiap prober health check di region berjalan secara independen, dan Cloud DNS menggabungkan hasilnya untuk menentukan kesehatan. Dalam setiap region, masing-masing pemeriksaan dilakukan oleh tiga instance prober health check endpoint. Jika satu pemeriksaan gagal, Cloud DNS masih dapat menentukan kondisi endpoint dengan menggunakan pemeriksaan yang tersisa. Ini berarti Anda memiliki sembilan total prober untuk setiap titik akhir, dan setiap probe terjadi dengan frekuensi yang Anda tentukan dalam interval health check. Berdasarkan parameter tentang kebijakan perutean dan informasi respons, Cloud DNS memilih dan merutekan traffic ke endpoint yang dipilih.

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

  • Bidang 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 terhubung ke endpoint. Untuk protokol HTTP dan HTTPS, Cloud DNS memverifikasi bahwa endpoint menampilkan kode respons HTTP 200. Anda juga bisa mengonfigurasi kesehatan berbasis konten pemeriksaan, di mana Cloud DNS memeriksa apakah respons berisi {i>string<i}.

Tidak seperti health check untuk load balancer internal, Cloud DNS health check 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 bagaimana pemeriksaan health check dilakukan. Jika Anda tidak menentukan port, Cloud DNS menggunakan port 80. Untuk membantu memastikan bahwa health check berfungsi dengan benar, mengonfigurasi aturan firewall untuk mengizinkan pemeriksaan health check dari sumber mana pun dan di port tertentu yang dikonfigurasi di health check.

Jika Anda belum mengonfigurasi firewall untuk mengizinkan pemeriksaan health check, gagal, sehingga Cloud DNS menganggap endpoint yang diblokir tidak responsif. Jika setiap endpoint ditampilkan sebagai tidak responsif, Cloud DNS tetap menyediakan sebagai akibatnya, meskipun kondisi tersebut tidak sehat.

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 mengirimkan satu pemeriksaan health check setiap 30 detik.

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

Kebijakan pemilihan rute round robin dan health check

Cloud DNS mendukung bobot dari 0 hingga 1000, termasuk keduanya. Kapan 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 bukan nol, target itu kemudian menjadi target utama Anda, dan semua traffic beralih ke target tersebut.
  • Saat Anda menambahkan lebih banyak target dengan bobot yang bukan nol, secara dinamis menghitung pemisahan traffic di antara target (dengan setiap permintaan) dan mendistribusikan traffic dengan tepat. Misalnya, jika Anda memiliki mengonfigurasi tiga target dengan bobot 0, 25, dan 75, target dengan bobot 0 bobot tidak mendapatkan traffic, target dengan bobot 25 mendapatkan seperempat dari lalu lintas, dan target yang tersisa mendapatkan tiga perempat dari kemacetan.
  • Jika health check dikaitkan dengan target berbobot bukan nol, tetapi tidak dengan nol target berbobot, target berbobot nol selalu dipertimbangkan sehat. Jika semua data selain nol tidak responsif, Cloud DNS mengembalikan catatan berbobot nol.
  • Jika health check dikaitkan dengan bobot selain nol dan nol dan jika semua data gagal dalam health check, Cloud DNS menampilkan target berbobot bukan nol dan mengabaikan target berbobot nol.
  • Saat Cloud DNS memilih bucket bobot untuk dikembalikan ke pemohon (satu item kebijakan), hanya alamat IP di bucket bobot tersebut yang dikembalikan. Jika Anda hanya menentukan satu alamat IP dalam bucket bobot, maka Alamat IP ada dalam respons. Jika ada lebih dari satu alamat IP dalam bucket bobot, Cloud DNS menampilkan semua alamat IP dalam urutan acak.

Kebijakan pemilihan rute geolokasi dan health check

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

  • Saat kebijakan memiliki beberapa alamat IP yang dikonfigurasi, dan semua alamat IP memiliki health check, hanya alamat IP yang responsif.
  • Saat ada kecocokan antara IP yang telah dicek dan tidak dicek kondisinya alamat IP, dan semua alamat IP yang telah dicek responsnya akan gagal. menampilkan semua alamat IP yang tidak memiliki health check yang dikonfigurasi. Di beberapa skenario ini, failover otomatis ke geografi terdekat berikutnya tidak terjadi.

Logging health check

Cloud DNS mendukung logging health check dan mencatat status respons alamat IP yang mengaktifkan {i>health-check<i} ketika Anda membuat kueri nama DNS yang mengacu ke alamat IP tersebut.

Pencatatan health check memungkinkan Anda melakukan hal berikut:

  • Validasi apakah kebijakan pemilihan rute berfungsi seperti yang diharapkan. Sebagai contoh:
    • Untuk kebijakan geolokasi, Anda dapat memvalidasi apakah kebijakan tersebut mendeteksi geografi yang benar dan mengembalikan {i>dataset<i} pencatatan sumber daya yang benar.
    • Untuk kebijakan WRR, memungkinkan Anda memvalidasi apakah kebijakan tersebut alamat IP dengan pembobotan yang benar.
  • Mengidentifikasi masalah infrastruktur pada backend dan alamat IP tertentu yang ada yang gagal.
  • Memecahkan masalah mengapa backend tertentu tidak pernah disertakan atau merupakan satu-satunya backend yang dikembalikan.

Untuk informasi selengkapnya, lihat informasi logging health check.

Jenis data yang didukung untuk kebijakan pemilihan rute DNS

Kebijakan perutean 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 Catatan pertukaran surat. Health check tidak didukung.
SRV Host/port (RFC 2782). Health check tidak didukung.
TXT Data teks. Health check tidak didukung.

Langkah selanjutnya