Dokumen ini memberikan praktik terbaik untuk zona pribadi, penerusan DNS, dan arsitektur referensi untuk DNS hybrid.
Baik manusia maupun aplikasi lebih mudah menggunakan Domain Name System (DNS)
untuk menangani aplikasi dan layanan karena menggunakan nama lebih mudah
diingat dan lebih fleksibel daripada menggunakan alamat IP. Dalam lingkungan hybrid yang terdiri dari platform lokal dan satu atau beberapa platform cloud, data DNS untuk resource internal sering kali perlu diakses di seluruh lingkungan. Biasanya,
data DNS lokal dikelola secara manual menggunakan server DNS otoritatif, seperti BIND di lingkungan UNIX/Linux atau Active Directory di lingkungan Microsoft Windows.
Dokumen ini menjelaskan praktik terbaik untuk meneruskan permintaan DNS pribadi antarlingkungan guna memastikan bahwa layanan dapat diakses dari lingkungan lokal dan dalam Google Cloud.
Prinsip umum
Mempelajari konsep DNS di Google Cloud
Saat Anda menggunakan DNS di Google Cloud, penting untuk memahami berbagai sistem dan layanan yang tersedia di Google Cloud untuk resolusi DNS dan nama domain:
- DNS internal adalah layanan yang secara otomatis membuat nama DNS untuk mesin virtual dan load balancer internal di Compute Engine.
- Cloud DNS adalah layanan yang menyediakan layanan zona DNS berlatensi rendah dan ketersediaan tinggi. Cloud DNS dapat bertindak sebagai server DNS otoritatif untuk zona publik yang dapat dilihat di internet, atau untuk zona pribadi yang hanya dapat dilihat dalam jaringan Anda.
- Managed Service for Microsoft Active Directory adalah layanan yang sangat tersedia dan telah melalui proses hardening yang menjalankan Microsoft Active Directory, termasuk pengontrol domain.
- DNS Publik adalah layanan Google yang bukan bagian dari Google Cloud yang bertindak sebagai DNS resolver rekursif terbuka.
- Cloud Domains adalah registrar domain untuk membeli, mentransfer, dan mengelola domain dalam Google Cloud. Cloud Domains memungkinkan Anda berinteraksi dengan sistem pendaftaran domain melalui API.
Mengidentifikasi pemangku kepentingan, alat, dan proses
Saat memikirkan cara membangun strategi untuk DNS di lingkungan hybrid, Anda harus memahami arsitektur saat ini dan menghubungi semua pemangku kepentingan. Lakukan tindakan berikut:
- Identifikasi dan hubungi administrator server DNS perusahaan organisasi Anda. Tanyakan kepada mereka informasi tentang konfigurasi yang diperlukan untuk memetakan konfigurasi lokal Anda ke arsitektur yang sesuai diGoogle Cloud. Untuk mengetahui informasi tentang metode untuk mengakses data DNSGoogle Cloud , lihat Menggunakan penerusan bersyarat untuk mengakses data DNS dari infrastruktur lokal.
- Pahami software DNS saat ini dan identifikasi nama domain yang digunakan secara pribadi dalam organisasi Anda.
- Identifikasi kontak di tim jaringan yang dapat memastikan bahwa traffic ke server Cloud DNS dirutekan dengan benar.
- Pahami strategi konektivitas hybrid Anda serta pola dan praktik hybrid dan multicloud.
Membuat standar penamaan yang konsisten
Buat standar penamaan yang konsisten di seluruh organisasi Anda.
Misalnya, asumsikan bahwa organisasi Anda menggunakan example.com
sebagai nama domain tingkat kedua dan domain untuk resource publik (misalnya,
www.example.com). Lokasi hosting zona publik tidak relevan untuk tujuan dokumen ini karena cakupannya adalah memigrasikan zona pribadi.
Untuk memberi nama resource perusahaan di lokasi, Anda dapat memilih dari pola berikut:
Anda dapat memiliki nama domain yang berbeda untuk server lokal dan untuk Google Cloud. Pola ini menggunakan domain terpisah untuk lingkungan yang berbeda—misalnya,
corp.example.comuntuk server lokal dangcp.example.comuntuk semua resource di Google Cloud. Jika Anda menggunakan lingkungan cloud publik lainnya, setiap lingkungan dapat memiliki subdomain terpisah. Ini adalah pola yang lebih disarankan, karena Anda dapat meneruskan permintaan antarlingkungan.Anda juga dapat menggunakan nama domain terpisah seperti
example.comdanexample.cloud.Anda dapat memiliki domain Google Cloud sebagai subdomain dari domain yang berisi server lokal. Dengan menggunakan domain
example.com, infrastruktur lokal dapat menggunakancorp.example.com, dan Google Cloud dapat menggunakangcp.corp.example.com. Ini adalah pola umum saat sebagian besar resource tetap berada di lokal.Anda dapat memiliki domain lokal sebagai subdomain dari domain yang berisi kumpulan dataGoogle Cloud . Dengan menggunakan domain
example.com, Google Clouddapat menggunakancorp.example.comdan infrastruktur lokal dapat menggunakandc.corp.example.com. Pola ini tidak umum, tetapi dapat digunakan untuk organisasi digital yang hanya memiliki jejak kecil di infrastruktur lokal.Anda dapat menggunakan domain yang sama untuk Google Cloud dan untuk infrastruktur lokal. Dalam hal ini, Google Cloud dan infrastruktur lokal menggunakan resource yang menggunakan domain
corp.example.com. Hindari pola ini karena akan mempersulit pengelolaan data di lingkungan hybrid; pola ini hanya dapat dilakukan jika Anda menggunakan satu sistem DNS otoritatif.
Bagian selanjutnya dari halaman ini menggunakan nama domain berikut:
example.comsebagai nama domain untuk data publik Anda, terlepas dari tempat data tersebut dihosting.corp.example.comsebagai zona yang dihosting oleh server DNS lokal Anda. Zona ini menampung data resource lokal Anda.gcp.example.comsebagai zona pribadi terkelola Cloud DNS yang menghosting data untuk resource Google Cloud Anda.
Gambar 1 mengilustrasikan penyiapan nama domain yang konsisten di seluruh jaringan lokal dan Google Cloud.
Untuk memberi nama resource dalam jaringan Virtual Private Cloud (VPC), Anda dapat mengikuti panduan seperti yang ada dalam panduan solusi Praktik terbaik dan arsitektur referensi untuk desain VPC.
Memilih tempat resolusi DNS dilakukan
Di lingkungan hybrid, resolusi DNS dapat dilakukan di lokasi yang berbeda. Anda dapat melakukan hal berikut:
- Gunakan pendekatan hybrid dengan dua sistem DNS otoritatif.
- Pertahankan resolusi DNS lokal.
- Pindahkan semua resolusi DNS ke Cloud DNS.
Sebaiknya gunakan pendekatan hybrid, jadi dokumen ini berfokus pada pendekatan tersebut. Namun, agar lengkap, dokumen ini secara singkat menjelaskan pendekatan alternatif.
Menggunakan pendekatan hybrid dengan dua sistem DNS otoritatif
Sebaiknya gunakan pendekatan hybrid dengan dua sistem DNS otoritatif. Dalam pendekatan ini:
- Resolusi DNS otoritatif untuk lingkungan pribadi Google Cloud Anda dilakukan oleh Cloud DNS.
- Resolusi DNS otoritatif untuk resource lokal dihosting oleh server DNS lokal yang ada.
Gambar 2 menunjukkan pengaturan ini.
Skenario yang ditunjukkan pada gambar 2 adalah kasus penggunaan yang lebih disarankan. Detail berikut akan dibahas di halaman ini:
- Cara menyiapkan penerusan antar-lingkungan menggunakan zona pribadi dan penerusan DNS.
- Cara mengonfigurasi firewall dan pemilihan rute.
- Arsitektur referensi yang menunjukkan cara menggunakan satu atau beberapa jaringan VPC.
Mempertahankan resolusi DNS secara lokal
Pendekatan alternatifnya adalah dengan terus menggunakan server DNS lokal yang ada untuk menghosting semua nama domain internal secara otoritatif. Dalam hal ini, Anda dapat menggunakan server nama alternatif untuk meneruskan semua permintaan dariGoogle Cloud melalui penerusan DNS keluar.
Pendekatan ini memiliki keuntungan sebagai berikut:
- Anda membuat lebih sedikit perubahan dalam proses bisnis.
- Anda dapat terus menggunakan alat yang ada.
- Anda dapat menggunakan daftar penolakan untuk memfilter setiap permintaan DNS secara lokal.
Namun, metode ini memiliki kekurangan berikut:
- Permintaan DNS dari Google Cloud memiliki latensi yang lebih tinggi.
- Sistem Anda mengandalkan konektivitas ke lingkungan lokal untuk operasi DNS.
- Anda mungkin kesulitan mengintegrasikan lingkungan yang sangat fleksibel seperti grup instance yang diskalakan otomatis.
- Sistem mungkin tidak kompatibel dengan produk seperti Dataproc karena produk tersebut mengandalkan resolusi terbalik dari nama instance Google Cloud.
Memindahkan semua resolusi DNS ke Cloud DNS
Pendekatan lain adalah bermigrasi ke Cloud DNS sebagai layanan otoritatif untuk semua resolusi domain. Kemudian, Anda dapat menggunakan zona pribadi dan penerusan DNS masuk untuk memigrasikan resolusi nama lokal yang ada ke Cloud DNS.
Pendekatan ini memiliki keuntungan sebagai berikut:
- Anda tidak perlu mempertahankan layanan DNS ketersediaan tinggi secara lokal.
- Sistem Anda dapat menggunakan Cloud DNS untuk memanfaatkan logging dan pemantauan terpusat.
Namun, metode ini memiliki kekurangan berikut:
- Permintaan DNS dari infrastruktur lokal memiliki latensi yang lebih tinggi.
- Sistem Anda memerlukan koneksi yang andal ke jaringan VPC Anda untuk resolusi nama.
Praktik terbaik untuk zona pribadi Cloud DNS
Zona pribadi menghosting data DNS yang hanya dapat dilihat di dalam organisasi Anda. Zona publik di Cloud DNS tidak dibahas dalam dokumen ini. Zona publik mencakup data publik organisasi, seperti data DNS untuk situs publik, dan tidak terlalu relevan dalam penyiapan hybrid.
Menggunakan otomatisasi untuk mengelola zona pribadi di project host VPC Bersama
Jika Anda menggunakan jaringan VPC Bersama dalam organisasi, Anda harus menghosting semua zona pribadi di Cloud DNS dalam project host. Semua project layanan secara otomatis dapat mengakses data di zona pribadi yang terhubung ke jaringan VPC Bersama. Atau, Anda dapat menyiapkan zona di project layanan menggunakan binding lintas project.
Gambar 3 menunjukkan cara zona pribadi dihosting di jaringan VPC Bersama.
Jika Anda ingin tim menetapkan data DNS mereka sendiri, sebaiknya otomatiskan pembuatan data DNS. Misalnya, Anda dapat membuat aplikasi web atau API internal tempat pengguna menyetel data DNS mereka sendiri di subdomain tertentu. Aplikasi memverifikasi bahwa data mematuhi aturan organisasi Anda.
Atau, Anda dapat menempatkan konfigurasi DNS di repositori kode seperti Cloud Source Repositories dalam bentuk deskripsi Terraform atau Cloud Deployment Manager dan menerima permintaan pull dari tim.
Dalam kedua kasus tersebut, akun layanan dengan peran IAM DNS Administrator di project host dapat otomatis men-deploy perubahan setelah disetujui.
Menetapkan peran IAM menggunakan prinsip hak istimewa terendah
Gunakan prinsip keamanan hak istimewa terendah untuk memberikan hak mengubah data DNS hanya kepada orang di organisasi Anda yang perlu melakukan tugas ini. Hindari penggunaan peran dasar karena peran tersebut dapat memberikan akses ke resource di luar yang diperlukan pengguna. Cloud DNS menawarkan peran dan izin yang memungkinkan Anda memberikan akses baca dan tulis khusus untuk DNS.
Jika Anda perlu memisahkan kemampuan untuk membuat zona DNS pribadi dari
kemampuan untuk membuat zona publik, gunakan izin dns.networks.bindPrivateDNSZone.
Praktik terbaik untuk zona penerusan DNS dan kebijakan server
Cloud DNS menawarkan zona penerusan DNS dan kebijakan server DNS untuk mengizinkan pencarian nama DNS antara lingkungan lokal dan Google Cloud Anda. Anda memiliki beberapa opsi untuk mengonfigurasi penerusan DNS. Bagian berikut mencantumkan praktik terbaik untuk penyiapan DNS hybrid. Praktik terbaik ini diilustrasikan dalam Arsitektur referensi untuk DNS hybrid.
Menggunakan zona penerusan untuk mengkueri server lokal
Untuk memastikan bahwa Anda dapat membuat kueri data DNS di lingkungan lokal, siapkan zona penerusan untuk domain yang Anda gunakan secara lokal untuk resource perusahaan Anda (seperti corp.example.com). Pendekatan ini lebih disarankan daripada menggunakan kebijakan DNS yang mengaktifkan server nama alternatif. Dengan pendekatan ini, akses ke nama DNS internal Compute Engine dipertahankan dan alamat IP eksternal tetap di-resolve tanpa hop tambahan melalui server nama lokal.
Alur traffic yang menggunakan penyiapan ini ditampilkan dalam Arsitektur referensi untuk DNS hybrid.
Gunakan server nama alternatif hanya jika semua traffic DNS perlu dipantau atau difilter secara lokal, dan jika pencatatan DNS pribadi tidak dapat memenuhi kebutuhan Anda.
Menggunakan kebijakan server DNS untuk mengizinkan kueri dari infrastruktur lokal
Untuk mengizinkan host lokal membuat kueri data DNS yang dihosting di zona pribadi Cloud DNS (misalnya, gcp.example.com), buat kebijakan server DNS menggunakan penerusan DNS masuk. Penerusan DNS masuk memungkinkan sistem Anda mengkueri semua zona pribadi dalam project serta alamat IP DNS internal dan zona yang di-peering.
Alur traffic yang menggunakan penyiapan ini ditampilkan dalam Arsitektur referensi untuk DNS hybrid.
Membuka firewall lokal dan Google Cloud untuk mengizinkan traffic DNS
Pastikan traffic DNS tidak difilter di mana pun di dalam jaringan VPC atau lingkungan lokal Anda dengan melakukan hal berikut:
Pastikan firewall lokal Anda meneruskan kueri dari Cloud DNS. Cloud DNS mengirimkan kueri dari rentang alamat IP
35.199.192.0/19. DNS menggunakan port UDP 53 atau port TCP 53, bergantung pada ukuran permintaan atau respons.Pastikan server DNS Anda tidak memblokir kueri. Jika server DNS lokal Anda hanya menerima permintaan dari alamat IP tertentu, pastikan rentang alamat IP
35.199.192.0/19disertakan.Pastikan traffic dapat mengalir dari infrastruktur lokal ke alamat IP penerusan Anda. Di instance Cloud Router, tambahkan rute kustom yang diberitahukan untuk rentang alamat IP
35.199.192.0/19di jaringan VPC Anda ke lingkungan lokal.
Menggunakan penerusan bersyarat untuk mengakses data DNS dari infrastruktur lokal
Dengan Cloud DNS, untuk mengakses data pribadi yang dihosting di server DNS perusahaan di lokasi, Anda hanya dapat menggunakan zona penerusan. Namun, bergantung pada software server DNS yang Anda gunakan, Anda mungkin memiliki beberapa opsi untuk mengakses data DNS di Google Cloud dari lingkungan lokal. Dalam setiap kasus, akses ke data terjadi dengan menggunakan penerusan DNS masuk:
Penerusan bersyarat. Dengan menggunakan penerusan bersyarat, server DNS perusahaan Anda akan meneruskan permintaan untuk zona atau subdomain tertentu ke alamat IP penerusan di Google Cloud. Sebaiknya gunakan pendekatan ini karena prosedurnya paling tidak rumit dan memungkinkan Anda memantau semua permintaan DNS secara terpusat di server DNS perusahaan.
Delegasi. Jika zona pribadi Anda di Google Cloud adalah subdomain dari zona yang Anda gunakan di lingkungan lokal, Anda juga dapat mendelegasikan subdomain ini ke server namaGoogle Cloud dengan menetapkan entri NS dalam zona Anda. Saat Anda menggunakan penyiapan ini, klien dapat berkomunikasi dengan alamat IP penerusan diGoogle Cloud secara langsung, jadi pastikan firewall meneruskan permintaan ini.
Transfer zona. Cloud DNS tidak mendukung transfer zona, sehingga Anda tidak dapat menggunakan transfer zona untuk menyinkronkan data DNS dengan server DNS lokal.
Menggunakan peering DNS untuk menghindari penerusan keluar dari beberapa jaringan VPC
Jangan gunakan penerusan keluar ke server DNS lokal Anda dari beberapa jaringan VPC karena akan menimbulkan masalah pada traffic kembali. Google Cloud menerima respons dari server DNS Anda hanya jika respons tersebut dirutekan ke jaringan VPC tempat kueri berasal. Namun, kueri dari jaringan VPC mana pun memiliki rentang alamat IP 35.199.192.0/19 yang sama sebagai sumber. Oleh karena itu, respons tidak dapat dirutekan dengan benar kecuali jika Anda memiliki lingkungan terpisah di infrastruktur lokal.
Sebaiknya tentukan satu jaringan VPC untuk mengkueri server nama lokal menggunakan penerusan keluar. Kemudian, jaringan VPC tambahan dapat membuat kueri ke server nama lokal dengan menargetkan jaringan VPC yang ditentukan dengan zona peering DNS. Kueri tersebut kemudian akan diteruskan ke server nama lokal sesuai dengan urutan resolusi nama dari jaringan VPC yang ditentukan. Penyiapan ini ditunjukkan dalam Arsitektur referensi untuk DNS hybrid.
Memahami perbedaan antara peering DNS dan Peering Jaringan VPC
Peering Jaringan VPC tidak sama dengan peering DNS. Peering Jaringan VPC memungkinkan instance virtual machine (VM) di beberapa project saling terhubung, tetapi tidak mengubah resolusi nama. Resource di setiap jaringan VPC tetap mengikuti urutan resolusinya sendiri.
Sebaliknya, melalui peering DNS, Anda dapat mengizinkan permintaan diteruskan untuk zona tertentu ke jaringan VPC lain. Dengan begitu, Anda dapat meneruskan permintaan ke lingkungan Google Cloud yang berbeda, terlepas dari apakah jaringan VPC saling terhubung atau tidak.
Peering Jaringan VPC dan peering DNS juga disiapkan secara berbeda. Untuk Peering Jaringan VPC, kedua jaringan VPC harus menyiapkan hubungan peering ke jaringan VPC lainnya. Peering kemudian akan otomatis menjadi dua arah.
Peering DNS meneruskan permintaan DNS secara satu arah dan tidak memerlukan hubungan dua arah antara jaringan VPC. Jaringan VPC yang disebut sebagai jaringan konsumen DNS melakukan pencarian untuk zona peering Cloud DNS di jaringan VPC lain, yang disebut sebagai jaringan produsen DNS. Pengguna dengan izin IAM dns.networks.targetWithPeeringZone di project jaringan produsen dapat membuat peering DNS antara jaringan konsumen dan produsen. Untuk menyiapkan peering DNS dari jaringan VPC konsumen, Anda memerlukan peran peer DNS untuk project host jaringan VPC produsen.
Jika Anda menggunakan nama yang dibuat otomatis, gunakan peering DNS untuk zona internal
Jika Anda menggunakan nama yang dibuat otomatis untuk VM yang dibuat oleh layanan DNS internal, Anda dapat menggunakan peering DNS untuk meneruskan zona projectname.internal ke project lain. Seperti yang ditunjukkan pada gambar 5, Anda dapat mengelompokkan semua zona .internal
dalam project hub agar dapat diakses dari jaringan lokal Anda.
.internal menjadi satu hub.Jika Anda mengalami masalah, ikuti panduan pemecahan masalah
Panduan pemecahan masalah Cloud DNS memberikan petunjuk untuk menyelesaikan error umum yang mungkin Anda alami saat menyiapkan Cloud DNS.
Arsitektur referensi untuk DNS hybrid
Bagian ini memberikan beberapa arsitektur referensi untuk skenario umum yang menggunakan zona pribadi Cloud DNS di lingkungan hybrid. Dalam setiap kasus, resource lokal dan catatan resource serta zona Google Cloud dikelola dalam lingkungan. Semua data tersedia untuk pembuatan kueri dari host lokal dan Google Cloud .
Gunakan arsitektur referensi yang sesuai dengan desain jaringan VPC Anda:
Arsitektur hybrid menggunakan satu jaringan VPC Bersama: Menggunakan satu jaringan VPC yang terhubung ke atau dari lingkungan lokal.
Arsitektur hybrid menggunakan beberapa jaringan VPC terpisah: Menghubungkan beberapa jaringan VPC ke lingkungan lokal melalui tunnel VPN atau lampiran VLAN yang berbeda dan berbagi infrastruktur DNS yang sama di infrastruktur lokal.
Arsitektur hybrid menggunakan jaringan VPC hub yang terhubung ke jaringan VPC spoke: Menggunakan Peering Jaringan VPC agar jaringan VPC hub terhubung ke beberapa jaringan VPC spoke independen.
Dalam setiap kasus, lingkungan lokal terhubung ke jaringan VPC Google Cloud oleh satu atau beberapa tunnel Cloud VPN atau koneksi Dedicated Interconnect atau Partner Interconnect. Kedua metode koneksi tersebut dapat digunakan untuk setiap jaringan VPC.
Arsitektur hybrid menggunakan satu jaringan VPC Bersama
Kasus penggunaan yang paling umum adalah satu jaringan VPC Bersama yang terhubung ke lingkungan lokal seperti yang ditunjukkan pada gambar 6.
Untuk menyiapkan arsitektur ini:
- Siapkan server DNS lokal Anda sebagai server otoritatif untuk
corp.example.com. - Konfigurasi zona pribadi otoritatif (misalnya,
gcp.example.com) di Cloud DNS di project host jaringan VPC Bersama, dan siapkan semua data untuk resource di zona tersebut. - Tetapkan kebijakan server DNS di project host untuk jaringan VPC Bersama agar mengizinkan penerusan DNS masuk.
- Tetapkan zona penerusan DNS yang meneruskan
corp.example.comke server DNS lokal. Jaringan VPC Bersama harus diizinkan untuk membuat kueri zona penerusan. - Siapkan penerusan ke
gcp.example.comdi server DNS lokal Anda, yang mengarah ke alamat IP penerus masuk di jaringan VPC Bersama. - Pastikan traffic DNS diizinkan di firewall lokal Anda.
- Di instance Cloud Router, tambahkan rute kustom yang diberitahukan untuk rentang
35.199.192.0/19ke lingkungan lokal.
Arsitektur hybrid menggunakan beberapa jaringan VPC terpisah
Opsi lain untuk arsitektur hybrid adalah memiliki beberapa jaringan VPC terpisah. Jaringan VPC di lingkunganGoogle Cloud Anda ini tidak terhubung satu sama lain melalui Peering Jaringan VPC. Semua jaringan VPC menggunakan tunnel Cloud VPN atau lampiran VLAN terpisah untuk terhubung ke lingkungan lokal Anda.
Seperti yang ditunjukkan pada gambar 7, kasus penggunaan umum untuk arsitektur ini adalah saat Anda memiliki lingkungan produksi dan pengembangan terpisah yang tidak saling berkomunikasi, tetapi menggunakan server DNS yang sama.
Untuk menyiapkan arsitektur ini:
- Siapkan server DNS lokal Anda sebagai server otoritatif untuk
corp.example.com. - Konfigurasi zona pribadi (misalnya,
prod.gcp.example.com) di Cloud DNS dalam project host jaringan VPC Bersama produksi, dan siapkan semua data untuk resource di zona tersebut. - Konfigurasi zona pribadi (misalnya,
dev.gcp.example.com) di Cloud DNS dalam project host jaringan VPC Bersama pengembangan, dan siapkan semua data untuk resource di zona tersebut. - Tetapkan kebijakan server DNS di project host untuk jaringan VPC Bersama produksi dan izinkan penerusan DNS masuk.
- Di jaringan VPC Bersama produksi, tetapkan zona DNS untuk meneruskan
corp.example.comke server DNS lokal. - Tetapkan zona peering DNS dari jaringan VPC Bersama pengembangan ke jaringan VPC Bersama produksi untuk
prod.gcp.example.com. - Tetapkan zona peering DNS dari jaringan VPC Bersama produksi ke jaringan VPC Bersama pengembangan untuk
dev.gcp.example.com. - Siapkan penerusan masuk dengan mendelegasikan resolusi
gcp.example.com.ke alamat IP virtual penerusan masuk Cloud DNS di server nama lokal Anda. - Pastikan firewall mengizinkan traffic DNS di firewall lokal danGoogle Cloud .
- Di instance Cloud Router, tambahkan rute kustom yang diberitahukan untuk rentang alamat IP
35.199.192.0/19di jaringan VPC Bersama produksi ke lingkungan lokal.
Arsitektur hybrid menggunakan jaringan VPC hub yang terhubung ke jaringan VPC spoke
Opsi lainnya adalah menggunakan Cloud Interconnect atau Cloud VPN untuk menghubungkan infrastruktur lokal ke jaringan VPC hub. Seperti yang ditunjukkan pada gambar 8, Anda dapat menggunakan Peering Jaringan VPC untuk melakukan peering jaringan VPC dengan beberapa jaringan VPC spoke. Setiap jaringan VPC spoke menghosting zona pribadinya sendiri di Cloud DNS. Rute kustom pada Peering Jaringan VPC, bersama dengan pemberitahuan rute kustom di Cloud Router, memungkinkan pertukaran rute dan konektivitas penuh antara jaringan VPC lokal dan semua spoke. Peering DNS berjalan secara paralel dengan koneksi Peering Jaringan VPC untuk memungkinkan resolusi nama antar-lingkungan.
Diagram berikut menampilkan arsitektur ini.
Untuk menyiapkan arsitektur ini:
- Siapkan server DNS lokal Anda sebagai server otoritatif untuk
corp.example.com. - Konfigurasi zona pribadi (misalnya,
projectX.gcp.example.com) di Cloud DNS untuk setiap jaringan VPC spoke, dan siapkan semua data untuk resource di zona tersebut. - Tetapkan kebijakan server DNS di project hub untuk jaringan VPC Bersama produksi agar mengizinkan penerusan DNS masuk.
- Di jaringan VPC hub, buat zona DNS pribadi untuk
corp.example.comdan konfigurasikan penerusan keluar ke server DNS lokal. - Tetapkan zona peering DNS dari jaringan VPC hub ke setiap jaringan VPC spoke untuk
projectX.gcp.example.com. - Tetapkan zona peering DNS dari setiap jaringan VPC spoke ke jaringan VPC hub untuk
example.com. - Siapkan penerusan ke
gcp.example.comdi server DNS lokal Anda untuk mengarah ke alamat IP forwarder masuk di jaringan VPC hub. - Pastikan firewall mengizinkan traffic DNS di firewall lokal danGoogle Cloud .
- Di instance Cloud Router, tambahkan rute kustom yang diberitahukan untuk rentang alamat IP
35.199.192.0/19di jaringan VPC hub ke lingkungan lokal. - (Opsional) Jika Anda juga menggunakan nama DNS internal yang dibuat secara otomatis, lakukan peering pada setiap zona project spoke (misalnya,
spoke-project-x.internal) dengan project hub, dan teruskan semua kueri untuk.internaldari infrastruktur lokal.
DNS publik multi-penyedia menggunakan Cloud DNS
Sebagai komponen dasar jaringan aplikasi, DNS yang andal berperan penting untuk memastikan aplikasi atau layanan Anda tersedia bagi pengguna. Anda dapat meningkatkan ketersediaan dan ketahanan aplikasi serta layanan dengan mengonfigurasi beberapa penyedia DNS. Jika beberapa penyedia DNS dikonfigurasi, aplikasi atau layanan Anda dapat tersedia bagi pengguna Anda meskipun terjadi gangguan pada salah satu penyedia DNS. Anda juga dapat menyederhanakan deployment dan migrasi aplikasi hybrid yang memiliki dependensi di seluruh lingkungan lokal dan cloud dengan konfigurasi DNS multi-penyedia.
Google Cloud menawarkan solusi open source berdasarkan octoDNS untuk membantu Anda menyiapkan dan mengoperasikan lingkungan dengan beberapa penyedia DNS. Solusi DNS multi-penyedia memanfaatkan Cloud DNS sebagai salah satu penyedia DNS Anda dalam konfigurasi aktif-aktif (direkomendasikan) atau aktif-pasif untuk memastikan arsitektur DNS dengan ketersediaan tinggi. Setelah Anda men-deploy solusi, octoDNS akan melakukan sinkronisasi satu kali dan berkelanjutan antara zona DNS saat ini dan zona DNS terkelola yang dihosting di Cloud DNS. Saat setiap data DNS diperbarui, perubahan akan disebarkan ke zona DNS terkait yang dihosting di Cloud DNS tanpa memerlukan perubahan pada pipeline CI/CD Anda.
- Untuk mengonfigurasi Cloud DNS dalam konfigurasi DNS publik multi-penyedia, lihat multi-provider-dns-with-clouddns.
Langkah berikutnya
- Untuk menemukan solusi atas masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS, lihat Pemecahan masalah.
- Untuk menemukan panduan tentang cara memahami dan menerapkan penyiapan hybrid yang menggunakan Google Cloud, lihat panduan solusi Pola dan praktik hybrid dan multi-cloud.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Cloud Architecture Center.