Anda dapat mengonfigurasi kebijakan perutean DNS untuk kumpulan data resource di zonapribadi ataupublik untuk mengarahkan traffic berdasarkan kriteria tertentu. Buat kumpulan data resource dengan nilai kebijakan perutean tertentu untuk menyiapkan kebijakan ini. Nilai ini menentukan cara Cloud DNS merutekan traffic kueri.
Cloud DNS mendukung kebijakan pemilihan rute berikut:
Kebijakan perutean weighted round robin (WRR): Gunakan kebijakan perutean WRR untuk menetapkan bobot yang berbeda ke setiap kumpulan 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.
Kebijakan perutean geolokasi: Gunakan kebijakan perutean geolokasi untuk menentukan geolokasi sumber dan memberikan respons yang sesuai ke geografi tersebut. Kebijakan pemilihan rute geolokasi menerapkan pencocokan 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 perutean WRR
Kebijakan perutean WRR memungkinkan Anda menentukan bobot yang berbeda-beda
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 versi produksi dan versi eksperimental layanan Anda.
Cloud DNS mendukung health check dan failover dalam kebijakan rute untuk load balancer internal dan endpoint eksternal. Cloud DNS mengaktifkan failover otomatis saat endpoint gagal dalam pemeriksaan kesehatannya. Selama failover, Cloud DNS akan otomatis menyesuaikan pembagian traffic di antara endpoint yang masih berfungsi. Untuk mengetahui informasi selengkapnya, lihat Health check.
Kebijakan perutean geolokasi
Kebijakan perutean geolokasi memungkinkan Anda memetakan traffic yang berasal dari geografis sumber (region Google 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 dari luar Google Cloud atau dengan traffic yang berasal dari dalam Google Cloud dan diarahkan ke Load Balancer Jaringan passthrough internal. Cloud DNS menggunakan region tempat kueri 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 subnet klien mekanisme ekstensi untuk DNS (EDNS) dari kueri akan digunakan.
- Untuk DNS pribadi, subnet klien EDNS tidak digunakan. Sebagai gantinya, lokasi
kueri adalah lokasi sistem yang mengirim 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 appliance Router yang menerima paket untuk kueri. Wilayah 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 rute untuk load balancer internal dan endpoint eksternal. Cloud DNS mengaktifkan failover otomatis saat endpoint gagal dalam pemeriksaan kesehatannya. Saat Anda menggunakan kebijakan perutean geolokasi, traffic akan gagal diarahkan ke geolokasi terdekat berikutnya dengan traffic sumber.
Kebijakan pemilihan rute geolokasi dengan pembatasan wilayah
Pagar virtual membantu memastikan bahwa traffic diarahkan ke region tertentu, meskipun semua endpoint dalam region tersebut gagal dalam health check.
Jika pembatasan wilayah dinonaktifkan dan kegagalan health check terjadi untuk geolokasi tertentu, traffic akan otomatis dialihkan ke geolokasi terdekat berikutnya. Namun, jika pembatasan wilayah diaktifkan, failover otomatis ini tidak akan terjadi. Sebagai server resmi, Cloud DNS harus menampilkan nilai, dan dalam skenario ini, Cloud DNS menampilkan semua alamat IP yang tidak diubah saat endpoint gagal dalam pemeriksaan status.
Kebijakan perutean failover
Kebijakan perutean 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 kumpulan active
. Jika semua alamat IP dalam kumpulan active
menjadi tidak sehat, Cloud DNS akan menayangkan alamat IP dari kumpulan
backup
. Jika Anda mengonfigurasi kumpulan backup
sebagai kebijakan perutean geolokasi, kumpulan tersebut
akan beroperasi seperti yang dijelaskan di bagian Kebijakan perutean geolokasi. Jika Anda mengonfigurasi kumpulan backup
untuk load balancer internal,
health check Cloud DNS akan memeriksa semua alamat IP virtual (VIP) cadangan.
Cloud DNS memungkinkan Anda mengalirkan traffic secara bertahap ke alamat VIP cadangan sehingga Anda dapat memverifikasi bahwa alamat VIP cadangan 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 standarnya 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 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
Jika Anda ingin menggunakan pemeriksaan status 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 diperiksa kondisinya dan alamat IP yang tidak diperiksa kondisinya dalam kebijakan tertentu.
Untuk informasi tentang praktik terbaik yang perlu diingat saat Anda mengonfigurasi catatan dan health check Cloud DNS, 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 menerima kueri, load balancer hanya mendistribusikan traffic ke layanan backend yang responsif. Untuk membantu memastikan bahwa ada backend yang sehat, Anda dapat mengelola siklus proses backend menggunakan layanan seperti grup instance terkelola (MIG). Cloud DNS tidak perlu mengetahui status kondisi setiap backend; load balancer menangani tugas ini.
Untuk Load Balancer Jaringan passthrough internal, Cloud DNS memeriksa informasi status di setiap instance backend load balancer. Cloud DNS menerapkan nilai minimum 20% secara default, dan jika setidaknya 20% instance backend responsif, endpoint load balancer dianggap responsif. Kebijakan pemilihan rute DNS menandai endpoint sebagai responsif atau tidak responsif berdasarkan nilai minimum ini, dan merutekan traffic sebagaimana mestinya.
Satu alamat IP virtual (VIP) Load Balancer Jaringan passthrough internal dapat memiliki beberapa instance backend. Jika Load Balancer Jaringan passthrough internal tidak memiliki instance backend, Cloud DNS masih menganggapnya responsif. Agar health check berfungsi dengan benar, tentukan setidaknya satu instance backend dalam konfigurasi load balancer.
Jika endpoint ditandai sebagai tidak sehat, kondisi berikut dapat terjadi:
- Jika ada beberapa alamat VIP yang diprogram berdasarkan kebijakan, hanya alamat VIP yang sehat yang akan ditampilkan.
Jika semua alamat VIP yang diprogram terhadap bucket kebijakan tidak berfungsi, baris kebijakan tersebut telah gagal. Perilaku berikut berlaku:
- Untuk kebijakan WRR, Cloud DNS mendistribusikan traffic secara proporsional di antara endpoint yang masih berfungsi yang ditentukan dalam kebijakan.
- Untuk kebijakan geolokasi yang tidak mengaktifkan pembatasan, traffic akan beralih ke endpoint di geografi terdekat berikutnya ke region Google Cloud sumber yang ditentukan dalam kebijakan.
- 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.
- 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 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 (Pratinjau)
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, termasuk VIP Load Balancer Aplikasi eksternal global, VIP Load Balancer Aplikasi eksternal Regional, VIP Load Balancer Jaringan proxy eksternal global, endpoint lokal, atau endpoint lainnya 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 tidak berfungsi.
- Untuk mengalihkan traffic ke Load Balancer Aplikasi eksternal regional lain jika backend Load Balancer Aplikasi eksternal regional tertentu menjadi tidak berfungsi.
- Untuk memantau kondisi endpoint lokal atau endpoint lain yang dapat dijangkau di internet publik.
Saat Anda membuat kebijakan perutean DNS dengan health check untuk endpoint eksternal, Cloud DNS akan mengirim probe health check ke endpoint Anda. Proba pemeriksaan kesehatan ini berasal dari tiga region sumber Google Cloud yang Anda tentukan. Penguji health check setiap region berjalan secara independen, dan Cloud DNS menggabungkan hasilnya untuk menentukan kesehatan keseluruhan endpoint. Dalam setiap region, tiga instance penguji health check akan memeriksa setiap endpoint. Jika satu probe gagal, Cloud DNS masih dapat menentukan kondisi endpoint menggunakan probe yang tersisa. Artinya, Anda memiliki sembilan penguji secara total untuk setiap endpoint, dan setiap pemeriksaan terjadi pada frekuensi yang Anda tentukan dalam interval pemeriksaan health check. Berdasarkan parameter kebijakan perutean dan informasi kesehatan, Cloud DNS memilih endpoint dan merutekan traffic ke endpoint yang dipilih.
Cloud DNS mendukung protokol TCP, HTTP, dan HTTPS dengan ketentuan 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 terhubung ke endpoint.
Untuk protokol HTTP dan HTTPS, Cloud DNS memverifikasi bahwa endpoint
menampilkan kode respons HTTP 200
. Anda juga dapat mengonfigurasi pemeriksaan kesehatan berbasis konten, yaitu 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 probe 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 health check berfungsi dengan benar, konfigurasikan 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 tersebut akan gagal, sehingga Cloud DNS menganggap endpoint yang diblokir sebagai tidak responsif. Jika setiap endpoint ditampilkan sebagai tidak responsif, Cloud DNS tetap menyediakan semuanya sebagai hasilnya, meskipun tidak responsif.
Interval health check
Cloud DNS secara berkala mengirimkan probe health check sesuai dengan interval health check. Misalnya, jika interval health check adalah 30 detik, Cloud DNS akan mengirimkan satu pemeriksaan kondisi setiap 30 detik.
Untuk pemeriksaan kesehatan 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 1.000, 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 dengan bobot non-nol, Cloud DNS akan menghitung pembagian traffic secara dinamis di antara target (dengan setiap permintaan) dan mendistribusikan traffic dengan tepat. Misalnya, jika Anda telah mengonfigurasi tiga target dengan bobot 0, 25, dan 75, target dengan bobot 0 tidak akan mendapatkan traffic, target dengan bobot 25 akan mendapatkan seperempat traffic, dan target lainnya akan mendapatkan tiga perempat traffic masuk.
- Jika health check dikaitkan dengan target berbobot non-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 dengan bobot nol.
- Jika pemeriksaan kesehatan dikaitkan dengan data berbobot non-nol dan nol, dan jika semua data gagal dalam pemeriksaan kesehatan, Cloud DNS akan menampilkan target berbobot non-nol dan mengabaikan target 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 perutean dan health check geolokasi
Untuk kebijakan perutean geolokasi dengan health check diaktifkan, hal berikut akan terjadi:
- Jika kebijakan memiliki beberapa alamat IP yang dikonfigurasi, dan semua alamat IP tersebut memiliki health check, hanya alamat IP yang responsif yang akan ditampilkan.
- Jika ada campuran alamat IP yang diperiksa kesehatannya dan yang tidak diperiksa kesehatannya, dan semua alamat IP yang diperiksa kesehatannya 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 kesehatan alamat IP yang mengaktifkan health check saat Anda mengkueri nama DNS yang merujuk ke alamat IP tersebut.
Logging health check memungkinkan Anda melakukan hal berikut:
- Validasi apakah kebijakan pemilihan rute berperforma seperti yang diharapkan. Misalnya:
- Untuk kebijakan geolokasi, kebijakan ini memungkinkan Anda memvalidasi apakah kebijakan mendeteksi geografis yang benar dan menampilkan set data data resource yang benar.
- Untuk kebijakan WRR, kebijakan ini memungkinkan Anda memvalidasi apakah kebijakan menampilkan alamat IP dengan bobot yang benar.
- Identifikasi masalah infrastruktur dengan backend dan alamat IP tertentu yang mengalami kegagalan.
- Memecahkan masalah mengapa backend tertentu tidak pernah disertakan atau merupakan satu-satunya backend yang ditampilkan.
Untuk mengetahui informasi selengkapnya, lihat informasi logging health check.
Jenis data yang didukung untuk kebijakan perutean 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 pemeriksaan kesehatan internal (zona pribadi) dan eksternal (zona publik) . |
AAAA | Alamat IPv6 untuk pemeriksaan kesehatan eksternal (zona publik). |
CNAME | Nama kanonis. Health check tidak didukung. |
MX | Data pertukaran surat. Health check tidak didukung. |
SRV | Host/port (RFC 2782). Health check tidak didukung. |
TXT | Data teks. Health check tidak didukung. |