Praktik terbaik untuk Cloud DNS

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

Manusia dan 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 cloud 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 kredibel, seperti BIND di lingkungan UNIX/Linux atau Active Directory di lingkungan Microsoft Windows.

Dokumen ini menjelaskan praktik terbaik untuk meneruskan permintaan DNS pribadi antar-lingkungan untuk memastikan bahwa layanan dapat ditangani 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 virtual machine dan load balancer internal di Compute Engine.
  • Cloud DNS adalah layanan yang menyediakan layanan zona DNS latensi rendah dan ketersediaan tinggi. Server ini dapat bertindak sebagai server DNS resmi untuk zona publik yang dapat dilihat di internet, atau untuk zona pribadi yang hanya dapat dilihat dalam jaringan Anda.
  • Layanan Terkelola untuk 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 tidak merupakan bagian dari Google Cloud dan berfungsi sebagai resolver DNS terbuka dan rekursif.
  • 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 Anda mempertimbangkan untuk membuat strategi DNS di lingkungan hybrid, sebaiknya kenali arsitektur Anda saat ini dan hubungi semua pemangku kepentingan. Lakukan tindakan berikut:

  • Identifikasi dan hubungi administrator server DNS perusahaan organisasi Anda. Minta informasi tentang konfigurasi yang diperlukan untuk memetakan konfigurasi lokal Anda ke arsitektur yang sesuai di Google Cloud. Untuk 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.
  • Pelajari 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). Tempat zona publik dihosting tidak relevan untuk tujuan dokumen ini karena cakupannya adalah memigrasikan zona pribadi.

Untuk memberi nama resource perusahaan di lokal, 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 berbagai lingkungan Anda—misalnya, corp.example.com untuk server lokal dan gcp.example.com untuk semua resource di Google Cloud. Jika Anda menggunakan lingkungan cloud publik lainnya, setiap lingkungan tersebut dapat memiliki subdomain terpisah. Ini adalah pola yang lebih disukai, karena Anda dapat meneruskan permintaan antar-lingkungan.

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

  • Anda dapat memiliki domain Google Cloud sebagai subdomain dari domain yang berisi server lokal. Dengan menggunakan domain example.com, on-premise 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 lokal.

  • Anda dapat memiliki domain on-premise sebagai subdomain dari domain yang berisi catatan Google Cloud. Dengan menggunakan domain example.com, Google Cloud dapat menggunakan corp.example.com dan secara 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 lokasi.

  • Anda dapat menggunakan domain yang sama untuk Google Cloud dan untuk lokal. Dalam hal ini, Google Cloud dan lokal menggunakan resource yang menggunakan domain corp.example.com. Hindari pola ini karena akan membuat pengelolaan data di lingkungan hybrid jauh lebih sulit; hal ini hanya dapat dilakukan jika Anda menggunakan satu sistem DNS resmi.

Bagian lain 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 yang konsisten di seluruh organisasi Anda.
Gambar 1. Penyiapan nama domain konsisten di seluruh organisasi.

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

Dalam lingkungan campuran, resolusi DNS dapat dilakukan di lokasi yang berbeda. Anda dapat melakukan hal berikut:

  • Gunakan pendekatan campuran dengan dua sistem DNS yang kredibel.
  • Mempertahankan resolusi DNS di lokal.
  • Pindahkan semua resolusi DNS ke Cloud DNS.

Kami merekomendasikan pendekatan campuran, sehingga dokumen ini berfokus pada pendekatan tersebut. Namun, untuk kelengkapan, dokumen ini menjelaskan secara singkat pendekatan alternatif.

Menggunakan pendekatan campuran dengan dua sistem DNS otoritatif

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

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

Gambar 2 menunjukkan pengaturan ini.

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

Skenario yang ditampilkan pada gambar 2 adalah kasus penggunaan yang lebih disukai. Detail berikut akan dibahas nanti 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 di lokal

Pendekatan alternatifnya adalah terus menggunakan server DNS lokal yang ada untuk menghosting semua nama domain internal secara resmi. Dalam hal ini, Anda dapat menggunakan server nama alternatif untuk meneruskan semua permintaan dari Google Cloud melalui penerusan DNS keluar.

Pendekatan ini memiliki keunggulan berikut:

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

Namun, pendekatan 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 merasa kesulitan untuk mengintegrasikan lingkungan yang sangat fleksibel seperti grup instance yang diskalakan otomatis.
  • Sistem mungkin tidak kompatibel dengan produk seperti Dataproc karena produk tersebut mengandalkan resolusi balik nama instance Google Cloud.

Memindahkan semua resolusi DNS ke Cloud DNS

Pendekatan lainnya 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 keunggulan berikut:

  • Anda tidak perlu mempertahankan layanan DNS dengan ketersediaan tinggi di lokasi.
  • Sistem Anda dapat menggunakan Cloud DNS untuk memanfaatkan logging dan pemantauan terpusat.

Namun, pendekatan ini memiliki kekurangan berikut:

  • Permintaan DNS dari 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 dibahas dalam dokumen ini. Zona publik mencakup data publik organisasi, seperti data DNS untuk situs publik, dan tidak terlalu relevan dalam penyiapan campuran.

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 dilampirkan ke jaringan VPC Bersama. Atau, Anda dapat menyiapkan zona dalam project layanan menggunakan binding lintas project.

Gambar 3 menunjukkan cara zona pribadi dihosting di jaringan VPC Bersama.

Gambar 3. Zona pribadi yang dihosting di jaringan VPC Bersama (klik untuk memperbesar).
Gambar 3. Penyiapan ini menunjukkan cara zona pribadi dilampirkan ke 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 menetapkan data DNS mereka sendiri di subdomain tertentu. Aplikasi memverifikasi bahwa data tersebut 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 DNS Administrator IAM 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-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 yang khusus untuk DNS.

Jika penting untuk memisahkan kemampuan membuat zona DNS pribadi dari kemampuan 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 membuat kueri server lokal

Untuk memastikan Anda dapat membuat kueri data DNS di lingkungan lokal, siapkan zona penerusan untuk domain yang Anda gunakan di lokal untuk resource perusahaan (seperti corp.example.com). Pendekatan ini lebih disukai daripada menggunakan kebijakan DNS yang mengaktifkan server nama alternatif. Tindakan ini akan mempertahankan akses ke nama DNS internal Compute Engine, dan alamat IP eksternal masih di-resolve tanpa hop tambahan melalui server nama on-premise.

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

Gunakan server nama alternatif hanya jika semua traffic DNS perlu dipantau atau difilter di lokal, dan jika logging DNS pribadi tidak dapat memenuhi persyaratan 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 peering.

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

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 tindakan 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/19 disertakan.

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

Menggunakan penerusan kondisional untuk mengakses data DNS dari infrastruktur lokal

Dengan Cloud DNS, untuk mengakses data pribadi yang dihosting di server DNS perusahaan di lokal, 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 lokal. Dalam setiap kasus, akses ke data terjadi dengan menggunakan penerusan DNS masuk:

  • Penerusan bersyarat. Menggunakan penerusan bersyarat berarti server DNS perusahaan Anda meneruskan permintaan untuk zona atau subdomain tertentu ke alamat IP penerusan di Google Cloud. Sebaiknya gunakan pendekatan ini karena paling tidak kompleks 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 infrastruktur 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 berkomunikasi dengan alamat IP penerusan di Google 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 dari beberapa jaringan VPC karena akan menimbulkan masalah pada traffic yang ditampilkan. Google Cloud hanya menerima respons dari server DNS Anda jika 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 diarahkan dengan benar kecuali jika Anda memiliki lingkungan terpisah di lokal.

Gambar 4. Masalah terjadi saat beberapa VPC meneruskan traffic ke luar jaringannya.
Gambar 4. Masalah dengan memiliki beberapa jaringan VPC yang melakukan penerusan keluar.

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

Sebaliknya, melalui peering DNS, Anda dapat mengizinkan permintaan diteruskan untuk zona tertentu ke jaringan VPC lain. Hal ini memungkinkan Anda 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 perlu menyiapkan hubungan peering ke jaringan VPC lainnya. Peering kemudian akan otomatis menjadi dua arah.

Peering DNS meneruskan permintaan DNS secara searah 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 menggunakan nama yang dibuat otomatis untuk VM yang dibuat 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.

Gambar 5. Peering DNS digunakan untuk mengatur semua zona .internal ke dalam hub.
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 memberikan petunjuk untuk mengatasi 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 data serta zona resource Google Cloud dikelola dalam lingkungan. Semua data tersedia untuk dikueri baik dari host lokal maupun Google Cloud.

Gunakan arsitektur referensi yang dipetakan ke 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 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 melalui satu atau beberapa tunnel Cloud VPN atau koneksi Dedicated Interconnect atau Partner Interconnect. Metode koneksi yang digunakan ke 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 yang ditunjukkan pada gambar 6.

Gambar 6. Arsitektur hybrid menggunakan satu jaringan VPC Bersama untuk terhubung ke jaringan lokal.
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 kredibel (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 on-premise. Jaringan VPC Bersama harus diberi otorisasi untuk membuat kueri zona penerusan.
  5. Siapkan penerusan ke gcp.example.com di server DNS lokal, yang mengarah ke alamat IP forwarder masuk di jaringan VPC Bersama.
  6. Pastikan traffic DNS diizinkan di firewall lokal Anda.
  7. Di instance Cloud Router, tambahkan rute kustom yang diiklankan untuk rentang 35.199.192.0/19 ke lingkungan lokal.

Arsitektur hybrid menggunakan beberapa jaringan VPC terpisah

Opsi lain untuk arsitektur hybrid 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 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 berkomunikasi satu sama lain, tetapi berbagi server DNS.

Gambar 7. Arsitektur hybrid dapat menggunakan beberapa jaringan VPC terpisah.
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 dalam 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 dalam 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. Di instance Cloud Router, tambahkan rute yang diiklankan secara kustom untuk rentang alamat IP 35.199.192.0/19 di jaringan Shared VPC 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 di Peering Jaringan VPC, bersama dengan iklan 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.

Gambar 8. Arsitektur hybrid dapat menggunakan jaringan VPC hub yang terhubung ke jaringan VPC spoke menggunakan Peering Jaringan VPC.
Gambar 8. Arsitektur hybrid dapat menggunakan jaringan VPC hub yang terhubung ke jaringan VPC spoke.

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 spoke, dan siapkan semua data untuk resource di zona tersebut.
  3. Tetapkan kebijakan server DNS di project hub untuk jaringan VPC Bersama produksi agar memungkinkan 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 spoke 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 Anda agar mengarah ke alamat IP forwarder masuk di jaringan VPC hub.
  8. Pastikan firewall mengizinkan traffic DNS di firewall lokal dan Google Cloud.
  9. Di instance Cloud Router, tambahkan rute kustom yang diiklankan untuk rentang alamat IP 35.199.192.0/19 di jaringan VPC hub ke lingkungan lokal.
  10. (Opsional) Jika Anda juga menggunakan nama DNS internal yang dibuat otomatis, buat peer setiap zona project spoke (misalnya, spoke-project-x.internal) dengan project hub, dan teruskan semua kueri untuk .internal dari lokal.

DNS publik multi-penyedia menggunakan Cloud DNS

Sebagai komponen dasar jaringan aplikasi, DNS yang andal adalah kunci untuk memastikan aplikasi atau layanan Anda tersedia bagi pengguna. Anda dapat meningkatkan ketersediaan dan ketahanan aplikasi dan layanan dengan mengonfigurasi beberapa penyedia DNS. Jika beberapa penyedia DNS dikonfigurasi, aplikasi atau layanan Anda dapat tersedia untuk pengguna meskipun ada 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 yang sangat tersedia. 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 diupdate, perubahan akan diterapkan ke zona DNS yang sesuai yang dihosting di Cloud DNS tanpa memerlukan perubahan apa pun pada pipeline CI/CD Anda.

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.