Praktik terbaik untuk Cloud DNS

Dokumen ini memberikan praktik terbaik untuk zona pribadi, penerusan DNS, dan arsitektur referensi untuk DNS hybrid.

Lebih mudah bagi manusia dan aplikasi untuk 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 lokal dan satu atau beberapa platform cloud, data DNS untuk resource internal sering kali perlu diakses di seluruh lingkungan. Secara tradisional, data DNS lokal dikelola secara manual menggunakan server DNS yang otoritatif, seperti BIND di lingkungan UNIX/Linux atau Active Directory di lingkungan Microsoft Windows.

Artikel ini menjelaskan praktik terbaik dalam meneruskan permintaan DNS pribadi antarlingkungan guna memastikan bahwa layanan dapat ditangani dari lingkungan lokal dan dalam Google Cloud.

Prinsip umum

Pelajari konsep DNS di Google Cloud

Saat 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 otomatis membuat nama DNS untuk virtual machine dan load balancer internal di Compute Engine.
• Cloud DNS adalah layanan yang menyediakan layanan zona DNS latensi rendah dan ketersediaan tinggi. DNS ini dapat berfungsi sebagai server DNS otoritatif untuk zona publik yang dapat dilihat oleh internet, atau untuk zona pribadi yang hanya terlihat dalam jaringan Anda.
• Layanan Terkelola untuk Microsoft Active Directory adalah layanan 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 dan bertindak sebagai DNS resolver terbuka dan rekursif.
• Cloud Domains adalah registrar domain untuk membeli, mentransfer, dan mengelola domain dalam Google Cloud. Dengan Cloud Domains, Anda dapat berinteraksi dengan sistem pendaftaran domain melalui API.

Mengidentifikasi pemangku kepentingan, {i>tool<i}, dan proses

Ketika memikirkan cara membangun strategi untuk DNS di lingkungan hybrid, penting untuk memahami arsitektur Anda saat ini dan menghubungi semua pemangku kepentingan. Lakukan tindakan berikut:

• Identifikasi dan hubungi administrator server DNS perusahaan organisasi Anda. Minta mereka untuk memberikan informasi tentang konfigurasi yang diperlukan untuk memetakan konfigurasi lokal Anda ke arsitektur yang sesuai di Google Cloud. Untuk mengetahui informasi tentang metode untuk mengakses data DNS Google Cloud, lihat Menggunakan penerusan bersyarat untuk mengakses data DNS dari infrastruktur lokal.
• Pelajari 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 serta pola dan praktik hybrid dan multi-cloud Anda.

Membuat standar penamaan yang sederhana dan konsisten

Buat standar penamaan yang konsisten di seluruh organisasi, tetapi mudah diingat. Misalnya, anggaplah organisasi Anda menggunakan example.com sebagai nama domain level kedua dan domain untuk resource publik (misalnya, www.example.com). Tempat zona publik dihosting tidak relevan untuk tujuan dokumen ini karena cakupannya adalah untuk memigrasikan zona pribadi.

Untuk menamai resource perusahaan secara lokal, Anda dapat memilih salah satu pola berikut:

• Anda dapat memiliki nama domain yang terpisah-pisah untuk server lokal dan Google Cloud. Pola ini menggunakan domain terpisah untuk lingkungan yang berbeda—misalnya, corp.example.com untuk server lokal dan gcp.example.com untuk semua resource di Google Cloud. Jika Anda menggunakan lingkungan cloud publik lainnya, masing-masing dapat memiliki subdomain terpisah. Ini adalah pola yang lebih disukai, karena mudah untuk meneruskan permintaan antarlingkungan.

  Anda juga dapat menggunakan nama domain terpisah seperti example.com dan example.cloud.

• Anda dapat memiliki domain Google Cloud sebagai subdomain domain yang berisi server lokal. Dengan menggunakan domain example.com, infrastruktur lokal dapat menggunakan corp.example.com, dan Google Cloud dapat menggunakan gcp.corp.example.com. Ini adalah pola umum saat sebagian besar resource tetap berada di infrastruktur lokal.

• Anda dapat memiliki domain lokal sebagai subdomain dari domain yang berisi data Google Cloud. Dengan menggunakan domain example.com, Google Cloud dapat menggunakan corp.example.com dan infrastruktur lokal dapat menggunakan dc.corp.example.com. Ini adalah pola yang 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, baik Google Cloud maupun infrastruktur lokal menggunakan resource yang menggunakan domain corp.example.com. Hindari pola ini karena akan membuat pengelolaan data di lingkungan hybrid menjadi jauh lebih sulit. Anda hanya dapat melakukannya jika menggunakan satu sistem DNS otoritatif.

Bagian selanjutnya dari halaman ini menggunakan nama domain berikut:

• example.com sebagai nama domain untuk data publik Anda, terlepas dari tempat data tersebut dihosting.
• corp.example.com sebagai zona yang dihosting oleh server DNS lokal Anda. Zona ini menghosting data resource lokal Anda.
• gcp.example.com sebagai zona terkelola pribadi Cloud DNS yang menghosting data untuk resource Google Cloud Anda.

Gambar 1 mengilustrasikan penyiapan nama domain yang konsisten di jaringan lokal dan Google Cloud.

Gambar 1. Penyiapan nama domain dilakukan secara konsisten di seluruh organisasi.

Untuk menamai resource dalam jaringan Virtual Private Cloud (VPC), Anda dapat mengikuti panduan seperti yang ada di panduan solusi Praktik terbaik dan arsitektur referensi untuk desain VPC.

Pilih tempat resolusi DNS dilakukan

Dalam 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 di infrastruktur lokal.
• Pindahkan semua resolusi DNS ke Cloud DNS.

Kami merekomendasikan pendekatan campuran, sehingga dokumen ini berfokus pada pendekatan tersebut. Namun, agar lebih lengkap, dokumen ini menjelaskan secara singkat pendekatan alternatif.

Menggunakan pendekatan hybrid dengan dua sistem DNS otoritatif

Sebaiknya gunakan pendekatan campuran dengan dua sistem DNS otoritatif. Dalam pendekatan ini:

• Resolusi DNS otoritatif untuk lingkungan Google Cloud pribadi dilakukan oleh Cloud DNS.
• Resolusi DNS otoritatif untuk resource lokal dihosting oleh server DNS lokal yang ada.

Gambar 2 menunjukkan pengaturan ini.

Gambar 2. Arsitektur DNS hybrid yang menggunakan Cloud DNS dan server DNS lokal menyediakan resolusi DNS yang otoritatif.

Skenario yang ditunjukkan pada gambar 2 adalah kasus penggunaan yang disarankan. Detail berikut akan dibahas nanti di halaman ini:

• Cara menyiapkan penerusan antar-lingkungan menggunakan zona pribadi dan penerusan DNS.
• Cara mengonfigurasi firewall dan perutean.
• Arsitektur referensi yang menunjukkan cara menggunakan satu atau beberapa jaringan VPC.

Pertahankan resolusi DNS di infrastruktur lokal

Pendekatan alternatifnya adalah dengan terus menggunakan server DNS lokal yang ada untuk menghosting semua nama domain internal secara otoritatif. Jika demikian, Anda dapat menggunakan server nama alternatif untuk meneruskan semua permintaan dari Google Cloud melalui penerusan DNS keluar.

Pendekatan ini memiliki keuntungan sebagai berikut:

• Anda membuat lebih sedikit perubahan pada proses bisnis.
• Anda dapat terus menggunakan alat yang ada.
• Anda dapat menggunakan daftar tolak untuk memfilter setiap permintaan DNS di infrastruktur lokal.

Namun, terdapat kekurangan berikut:

• Permintaan DNS dari Google Cloud memiliki latensi yang lebih tinggi.
• Sistem Anda mengandalkan konektivitas ke lingkungan lokal untuk operasi DNS.
• Anda mungkin merasa kesulitan untuk mengintegrasikan lingkungan yang sangat fleksibel seperti grup instance dengan penskalaan otomatis.
• Sistem mungkin tidak kompatibel dengan produk seperti Dataproc karena produk tersebut mengandalkan resolusi terbalik nama instance Google Cloud.

Pindahkan semua resolusi DNS ke Cloud DNS

Pendekatan lainnya adalah bermigrasi ke Cloud DNS sebagai layanan otoritatif untuk semua resolusi domain. Anda kemudian 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, terdapat kekurangan berikut:

• Permintaan DNS dari infrastruktur lokal memiliki latensi yang lebih tinggi.
• Sistem Anda memerlukan koneksi yang andal ke jaringan VPC 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 dicakup dalam dokumen ini. Zona publik mencakup data publik organisasi, seperti data DNS untuk situs publik, dan zona tersebut tidak terlalu relevan dalam konfigurasi hybrid.

Menggunakan otomatisasi untuk mengelola zona pribadi di project host VPC Bersama

Jika 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 terpasang 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.

Gambar 3. Penyiapan ini menunjukkan cara zona pribadi dihubungkan ke VPC Bersama.

Jika Anda ingin tim menetapkan data DNS mereka sendiri, sebaiknya Anda mengotomatiskan pembuatan data DNS. Misalnya, Anda dapat membuat aplikasi web atau API internal tempat pengguna menetapkan data DNS mereka sendiri di subdomain tertentu. Aplikasi akan memverifikasi bahwa data mematuhi aturan organisasi Anda.

Atau, Anda dapat menempatkan konfigurasi DNS Anda dalam repositori kode seperti Cloud Source Repositories dalam bentuk deskriptor Terraform atau Cloud Deployment Manager dan menerima permintaan pull dari tim.

Pada kedua kasus tersebut, akun layanan dengan peran DNS Administrator IAM dalam project host dapat otomatis men-deploy perubahan setelah disetujui.

Menetapkan peran IAM menggunakan prinsip hak istimewa terendah

Gunakan prinsip keamanan dengan hak istimewa terendah untuk memberikan hak guna mengubah data DNS hanya kepada data di organisasi Anda yang perlu melakukan tugas tersebut. Hindari penggunaan peran dasar karena dapat memberikan akses ke resource selain yang diperlukan pengguna. Cloud DNS menawarkan peran dan izin yang memungkinkan Anda memberikan akses baca dan tulis yang khusus untuk DNS.

Jika penting untuk memisahkan kemampuan 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 yang memungkinkan 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 di bagian Arsitektur referensi untuk DNS hybrid.

Catatan: Penerusan DNS tidak dapat digunakan untuk melakukan penerusan di antara lingkungan Google Cloud yang berbeda, terlepas dari cara keduanya saling terhubung. Untuk kasus penggunaan tersebut, gunakan peering DNS.

Menggunakan zona penerusan untuk membuat kueri server lokal

Untuk memastikan 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 disukai daripada menggunakan kebijakan DNS yang memungkinkan server nama alternatif. Hal ini akan mempertahankan akses ke nama DNS internal Compute Engine, dan alamat IP publik masih diselesaikan tanpa hop tambahan melalui server nama lokal.

Alur traffic yang menggunakan penyiapan ini ditampilkan di bagian Arsitektur referensi untuk DNS hybrid.

Gunakan server nama alternatif hanya jika semua traffic DNS perlu dipantau atau difilter secara lokal, dan jika logging DNS pribadi tidak dapat memenuhi persyaratan Anda.

Catatan: Cloud DNS tidak otomatis disinkronkan dengan server nama lokal. Server nama lokal harus tersedia untuk merespons kueri yang diteruskan ke luar. Seperti yang dijelaskan di zona penerusan DNS, Cloud DNS meng-cache hasil kueri yang diteruskan keluar hingga 60 detik, atau selama durasi TTL-nya. Google Cloud tidak menyinkronkan atau meng-cache catatan lokal; permintaan diteruskan begitu masuk. Oleh karena itu, server DNS lokal harus tersedia dan dapat dijangkau sehingga domain lokal dapat di-resolve.

Gunakan kebijakan server DNS untuk mengizinkan kueri dari infrastruktur lokal

Agar host lokal dapat mengkueri 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 di bagian Arsitektur referensi untuk DNS hybrid.

Membuka firewall Google Cloud dan lokal 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 mengirim kueri dari rentang alamat IP 35.199.192.0/19. DNS menggunakan UDP port 53 atau TCP port 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 IP 35.199.192.0/19 disertakan.

• Pastikan traffic dapat mengalir dari infrastruktur lokal ke alamat IP penerusan Anda. Dalam instance Cloud Router, tambahkan iklan rute kustom untuk rentang IP 35.199.192.0/19 di jaringan VPC Anda ke lingkungan lokal.

Menggunakan penerusan bersyarat untuk mengakses data DNS dari infrastruktur lokal

Dengan Cloud DNS, Anda hanya dapat menggunakan zona penerusan untuk mengakses data pribadi yang dihosting di server DNS perusahaan secara lokal. Namun, bergantung pada software server DNS yang Anda gunakan, Anda mungkin memiliki beberapa opsi untuk mengakses data DNS di Google Cloud dari infrastruktur lokal. Dalam setiap kasus, akses ke data terjadi menggunakan penerusan DNS masuk:

• Penerusan bersyarat. Menggunakan penerusan bersyarat berarti bahwa server DNS perusahaan Anda meneruskan permintaan untuk zona atau subdomain tertentu ke alamat IP penerusan di Google Cloud. Kami merekomendasikan pendekatan ini karena cara yang paling sederhana dan memungkinkan Anda memantau semua permintaan DNS secara terpusat di server DNS perusahaan.

• Delegasi. Jika zona pribadi Anda di Google Cloud merupakan subdomain dari zona yang Anda gunakan secara lokal, Anda juga dapat mendelegasikan subdomain ini ke server nama Google Cloud dengan menetapkan entri NS dalam zona Anda. Saat Anda menggunakan penyiapan ini, klien dapat langsung berkomunikasi dengan alamat IP penerusan di Google Cloud. 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 Anda.

Menggunakan peering DNS untuk menghindari penerusan keluar dari beberapa jaringan VPC

Jangan gunakan penerusan keluar ke server DNS lokal dari beberapa jaringan VPC karena hal ini 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 setiap jaringan VPC memiliki rentang IP 35.199.192.0/19 yang sama dengan sumber. Oleh karena itu, respons tidak dapat dirutekan dengan benar kecuali jika Anda memiliki lingkungan lokal terpisah.

Gambar 4. Masalah saat memiliki beberapa jaringan VPC saat melakukan penerusan keluar.

Sebaiknya tetapkan satu jaringan VPC untuk membuat kueri server nama lokal menggunakan penerusan keluar. Kemudian, jaringan VPC tambahan dapat mengkueri server nama lokal dengan menargetkan jaringan VPC yang ditetapkan dengan zona peering DNS. Kueri tersebut kemudian akan diteruskan ke server nama lokal sesuai dengan urutan resolusi nama jaringan VPC yang ditetapkan. Penyiapan ini ditampilkan di 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 untuk saling menjangkau satu sama lain, tetapi tidak mengubah resolusi nama. Resource di setiap jaringan VPC masih mengikuti urutan resolusinya sendiri.

Sebaliknya, melalui peering DNS, Anda dapat mengizinkan permintaan diteruskan untuk zona tertentu ke jaringan VPC lain. Hal ini memungkinkan Anda meneruskan permintaan ke berbagai lingkungan Google Cloud, terlepas dari apakah jaringan VPC tersebut saling berhubungan atau tidak.

Peering Jaringan VPC dan peering DNS juga disiapkan secara berbeda. Untuk Peering Jaringan VPC, kedua jaringan VPC perlu menyiapkan hubungan peering ke jaringan VPC lainnya. Selanjutnya, peering ini secara otomatis bersifat dua arah.

Peering DNS meneruskan permintaan DNS secara searah dan tidak memerlukan hubungan dua arah antarjaringan VPC. Jaringan VPC yang disebut sebagai jaringan konsumen DNS melakukan pencarian zona peering Cloud DNS di jaringan VPC lain, yang disebut sebagai jaringan produser DNS. Pengguna dengan izin IAM dns.networks.targetWithPeeringZone pada 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 produser.

Jika Anda menggunakan nama yang dibuat secara otomatis, gunakan peering DNS untuk zona internal

Jika Anda menggunakan nama yang dibuat secara 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.

Gambar 5. Peering DNS digunakan untuk mengatur semua zona .internal ke dalam hub.

Jika Anda mengalami masalah, ikuti panduan pemecahan masalah

Panduan pemecahan masalah Cloud DNS menyediakan petunjuk untuk menyelesaikan error umum yang mungkin Anda alami saat menyiapkan Cloud DNS.

Arsitektur referensi untuk DNS hibrid

Bagian ini menyediakan beberapa arsitektur referensi untuk skenario umum yang menggunakan zona pribadi Cloud DNS di lingkungan hybrid. Dalam setiap kasus, resource lokal maupun data dan zona resource Google Cloud dikelola dalam lingkungan. Semua data tersedia untuk membuat kueri, baik dari host lokal maupun Google Cloud.

Gunakan arsitektur referensi yang memetakan ke desain jaringan VPC Anda:

• Arsitektur hybrid menggunakan 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 berbicara: Menggunakan Peering Jaringan VPC agar jaringan VPC hub terhubung ke beberapa jaringan VPC bicara independen.

Dalam setiap kasus, lingkungan lokal terhubung ke jaringan VPC Google Cloud melalui satu atau beberapa tunnel Cloud VPN atau koneksi Dedicated Interconnect atau Partner Interconnect. Metode koneksi mana yang digunakan untuk setiap jaringan VPC tidak relevan.

Arsitektur hybrid menggunakan satu jaringan VPC Bersama

Kasus penggunaan yang paling umum adalah satu jaringan VPC Bersama yang terhubung ke lingkungan lokal seperti ditunjukkan dalam gambar 6.

Gambar 6. Arsitektur hybrid menggunakan satu jaringan VPC Bersama untuk terhubung ke jaringan lokal.

Untuk menyiapkan arsitektur ini:

1. Siapkan server DNS lokal Anda sebagai otoritatif untuk corp.example.com.
2. Konfigurasikan zona pribadi yang otoritatif (misalnya, gcp.example.com) di Cloud DNS di project host Jaringan VPC bersama, dan siapkan semua data untuk resource di zona tersebut.
3. Tetapkan kebijakan server DNS di project host untuk jaringan VPC Bersama agar mengizinkan penerusan DNS masuk.
4. Tetapkan zona penerusan DNS yang meneruskan corp.example.com ke server DNS lokal. Jaringan VPC Bersama harus diberi otorisasi untuk mengkueri zona penerusan.
5. Siapkan penerusan ke gcp.example.com di server DNS lokal Anda, yang mengarah ke alamat IP penerus masuk di jaringan VPC Bersama.
6. Pastikan traffic DNS diizinkan di firewall lokal Anda.
7. Dalam instance Cloud Router, tambahkan pemberitahuan rute kustom untuk rentang 35.199.192.0/19 ke lingkungan lokal.

Arsitektur hybrid menggunakan beberapa jaringan VPC terpisah

Pilihan lain untuk arsitektur hibrida adalah memiliki beberapa jaringan VPC terpisah. Jaringan VPC ini di lingkungan Google Cloud Anda tidak terhubung satu sama lain melalui Peering Jaringan VPC. Semua jaringan VPC menggunakan tunnel Cloud VPN terpisah atau lampiran VLAN untuk terhubung ke lingkungan lokal Anda.

Seperti ditunjukkan dalam gambar 7, kasus penggunaan umum untuk arsitektur ini adalah ketika Anda memiliki lingkungan produksi dan pengembangan terpisah yang tidak berkomunikasi satu sama lain, tetapi keduanya berbagi server DNS.

Gambar 7. Arsitektur hybrid dapat menggunakan beberapa jaringan VPC terpisah.

Untuk menyiapkan arsitektur ini:

1. Siapkan server DNS lokal Anda sebagai otoritatif untuk corp.example.com.
2. Konfigurasikan zona pribadi (misalnya, prod.gcp.example.com) di Cloud DNS di project host jaringan VPC bersama produksi, dan siapkan semua data untuk resource di zona tersebut.
3. Konfigurasikan zona pribadi (misalnya, dev.gcp.example.com) di Cloud DNS di project host jaringan VPC bersama pengembangan, dan siapkan semua data untuk resource di zona tersebut.
4. Tetapkan kebijakan server DNS di project host untuk jaringan VPC Bersama produksi dan izinkan penerusan DNS masuk.
5. Di jaringan VPC Bersama produksi, tetapkan zona DNS untuk meneruskan corp.example.com ke server DNS lokal.
6. Tetapkan zona peering DNS dari Jaringan VPC bersama pengembangan ke jaringan VPC bersama produksi untuk prod.gcp.example.com.
7. Tetapkan zona peering DNS dari jaringan VPC Bersama produksi ke jaringan VPC Bersama pengembangan untuk dev.gcp.example.com.
8. Siapkan penerusan masuk dengan mendelegasikan resolusi gcp.example.com. ke alamat IP virtual penerusan masuk Cloud DNS di server nama lokal Anda.
9. Pastikan firewall mengizinkan traffic DNS di firewall lokal dan Google Cloud.
10. Dalam instance Cloud Router, tambahkan iklan rute kustom untuk rentang IP 35.199.192.0/19 di jaringan VPC Bersama produksi ke lingkungan lokal.

Arsitektur hybrid menggunakan jaringan VPC hub yang terhubung ke jaringan VPC bicara

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 pada jaringan VPC dengan beberapa jaringan VPC spoke. Setiap jaringan VPC spoke menghosting zona pribadinya sendiri di Cloud DNS. Rute kustom di Peering Jaringan VPC, beserta iklan rute kustom di Cloud Router, memungkinkan pertukaran rute lengkap dan konektivitas antara jaringan VPC lokal dan semua jaringan VPC lokal. Peering DNS berjalan secara paralel dengan koneksi Peering Jaringan VPC untuk memungkinkan resolusi nama antarlingkungan.

Diagram berikut menunjukkan arsitektur ini.

Gambar 8. Arsitektur hybrid dapat menggunakan jaringan VPC hub yang terhubung ke jaringan VPC berbicara.

Untuk menyiapkan arsitektur ini:

1. Siapkan server DNS lokal Anda sebagai otoritatif untuk corp.example.com.
2. Konfigurasikan zona pribadi (misalnya, projectX.gcp.example.com) di Cloud DNS untuk setiap jaringan VPC berbicara, dan siapkan semua data untuk resource di zona tersebut.
3. Tetapkan kebijakan server DNS pada project hub untuk jaringan VPC Bersama produksi guna mengizinkan penerusan DNS masuk.
4. Di jaringan VPC hub, buat zona DNS pribadi untuk corp.example.com dan konfigurasikan penerusan keluar ke server DNS lokal.
5. Tetapkan zona peering DNS dari jaringan VPC hub ke setiap jaringan VPC berbicara untuk projectX.gcp.example.com.
6. Tetapkan zona peering DNS dari setiap jaringan VPC spoke ke jaringan VPC hub untuk example.com.
7. Siapkan penerusan ke gcp.example.com di server DNS lokal untuk mengarah ke alamat IP penerus masuk di jaringan VPC hub.
8. Pastikan firewall mengizinkan traffic DNS di firewall lokal dan Google Cloud.
9. Dalam instance Cloud Router, tambahkan iklan rute kustom untuk rentang IP 35.199.192.0/19 di jaringan VPC hub ke lingkungan lokal.
10. (Opsional) Jika Anda juga menggunakan nama DNS internal yang dihasilkan secara otomatis, lakukan peering setiap zona project spoke (misalnya, spoke-project-x.internal) dengan project hub, dan teruskan semua kueri untuk .internal dari infrastruktur lokal.

Catatan: Saat Anda menggunakan Cloud VPN, bukan Peering Jaringan VPC antara lingkungan Google Cloud dengan arsitektur ini, pastikan ada tunnel VM atau VPN di project hub di setiap region yang digunakan dalam project spoke. Hal ini memastikan bahwa semua VM dapat membuat kueri data melalui peering DNS.

DNS publik multi-penyedia menggunakan Cloud DNS

Sebagai komponen dasar jaringan aplikasi, DNS yang andal adalah kunci untuk memastikan bahwa aplikasi atau layanan Anda tersedia untuk pengguna. Anda dapat meningkatkan ketersediaan dan ketahanan aplikasi serta layanan Anda dengan mengonfigurasi beberapa penyedia DNS. Jika beberapa penyedia DNS dikonfigurasi, aplikasi atau layanan Anda dapat tersedia untuk pengguna 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 ini memanfaatkan Cloud DNS sebagai salah satu penyedia DNS Anda dalam konfigurasi aktif-aktif (direkomendasikan) atau aktif-pasif untuk memastikan arsitektur DNS yang sangat tersedia. Setelah Anda men-deploy solusi, octoDNS akan melakukan sinkronisasi satu kali dan juga berkelanjutan antara zona DNS Anda saat ini dan zona DNS terkelola yang dihosting di Cloud DNS. Saat setiap data DNS diperbarui, perubahan akan diterapkan ke zona DNS terkait yang dihosting di Cloud DNS tanpa memerlukan perubahan pada pipeline CI/CD Anda.

Penting: Untuk mencapai keandalan dan konfigurasi aktif-aktif, Anda harus memperbarui data NS di registrar untuk menyertakan server nama Cloud DNS.

• Untuk mengonfigurasi Cloud DNS dalam konfigurasi DNS publik multi-penyedia, lihat multi-provider-dns-with-clouddns.

Langkah selanjutnya

• Untuk menemukan solusi atas masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS, lihat Pemecahan masalah.
• Untuk menemukan panduan tentang cara mendekati 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 Pusat Arsitektur Cloud.