Segmentasi dan konektivitas jaringan untuk aplikasi terdistribusi di Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Dokumen ini adalah bagian dari rangkaian panduan desain untuk Jaringan Cross-Cloud.

Rangkaian ini terdiri dari bagian berikut:

Bagian ini membahas struktur dan konektivitas segmentasi jaringan, yang merupakan dasar dari desain. Dokumen ini menjelaskan fase-fase saat Anda membuat pilihan berikut:

  • Segmentasi jaringan dan struktur project secara keseluruhan.
  • Tempat Anda menempatkan workload.
  • Cara project Anda terhubung ke jaringan penyedia cloud lain dan lokal eksternal, termasuk desain untuk konektivitas, perutean, dan enkripsi.
  • Cara jaringan VPC Anda terhubung secara internal satu sama lain.
  • Cara subnet VPC Google Cloud Anda terhubung satu sama lain dan ke jaringan lain, termasuk cara Anda menyiapkan keterjangkauan layanan dan DNS.

Segmentasi jaringan dan struktur project

Selama tahap perencanaan, Anda harus memutuskan antara salah satu dari dua struktur project:

  • Project host infrastruktur gabungan, yang menggunakan satu project host infrastruktur untuk mengelola semua resource jaringan untuk semua aplikasi
  • Project host tersegmentasi, yang menggunakan project host infrastruktur yang dikombinasikan dengan project host yang berbeda untuk setiap aplikasi

Selama tahap perencanaan, sebaiknya Anda juga memutuskan domain administratif untuk lingkungan workload Anda. Tentukan cakupan izin untuk administrator dan developer infrastruktur Anda berdasarkan prinsip hak istimewa terendah, dan tentukan cakupan resource aplikasi ke dalam project aplikasi yang berbeda. Karena administrator infrastruktur perlu menyiapkan konektivitas untuk berbagi resource, resource infrastruktur dapat ditangani dalam project infrastruktur. Misalnya, untuk menyiapkan konektivitas ke resource infrastruktur bersama, administrator infrastruktur dapat menggunakan project infrastruktur untuk menangani resource bersama tersebut. Pada saat yang sama, tim pengembangan mungkin mengelola workload mereka dalam satu project, dan tim produksi mungkin mengelola workload mereka dalam project terpisah. Developer kemudian akan menggunakan resource infrastruktur dalam project infrastruktur untuk membuat dan mengelola resource, layanan, load balancing, dan kebijakan perutean DNS untuk workload mereka.

Selain itu, Anda harus memutuskan berapa banyak jaringan VPC yang akan diimplementasikan pada awalnya dan bagaimana jaringan tersebut akan diatur dalam hierarki resource Anda. Untuk mengetahui detail tentang cara memilih hierarki resource, lihat Menentukan hierarki resource untuk zona landing Google Cloud . Untuk mengetahui detail tentang cara memilih jumlah jaringan VPC, lihat Memutuskan apakah akan membuat beberapa jaringan VPC atau tidak.

Untuk Cross-Cloud Network, sebaiknya gunakan VPC berikut:

  • Satu atau beberapa VPC aplikasi untuk menghosting resource bagi berbagai aplikasi.
  • Satu atau beberapa VPC transit, tempat semua konektivitas eksternal ditangani.
  • Satu atau beberapa VPC akses layanan, yang dapat digunakan untuk menggabungkan deployment akses pribadi ke layanan yang dipublikasikan.

Diagram berikut menunjukkan representasi visual dari struktur VPC yang direkomendasikan yang baru saja dijelaskan. Anda dapat menggunakan struktur VPC yang ditampilkan dalam diagram dengan struktur project gabungan atau tersegmentasi, seperti yang dijelaskan di bagian berikutnya. Diagram yang ditampilkan di sini tidak menunjukkan konektivitas antara jaringan VPC.

Struktur VPC yang direkomendasikan

Project host infrastruktur gabungan

Anda dapat menggunakan project host infrastruktur gabungan untuk mengelola semua resource jaringan seperti jaringan VPC dan subnet, hub Network Connectivity Center, Peering Jaringan VPC, dan load balancer.

Beberapa VPC Bersama aplikasi dengan project layanan aplikasi yang sesuai dapat dibuat di project host infrastruktur agar sesuai dengan struktur organisasi. Gunakan beberapa project layanan aplikasi untuk mendelegasikan administrasi resource. Semua jaringan di semua VPC aplikasi ditagih ke project host infrastruktur gabungan.

Untuk struktur project ini, banyak project layanan aplikasi dapat berbagi sejumlah kecil VPC aplikasi.

Diagram berikut memberikan representasi visual dari project host infrastruktur gabungan dan beberapa project layanan aplikasi yang baru saja dijelaskan. Diagram ini tidak menunjukkan konektivitas di antara semua project.

Project host infrastruktur gabungan dan beberapa project layanan aplikasi

Project host tersegmentasi

Dalam pola ini, setiap grup aplikasi memiliki project host aplikasi dan jaringan VPC-nya sendiri. Beberapa project layanan aplikasi dapat dilampirkan ke project host. Penagihan untuk layanan jaringan dibagi antara project host infrastruktur dan project host aplikasi. Biaya infrastruktur ditagihkan ke project host infrastruktur dan biaya jaringan, seperti biaya transfer data untuk aplikasi, ditagihkan ke setiap project host aplikasi.

Diagram berikut memberikan representasi visual dari beberapa project host dan beberapa project layanan aplikasi yang baru saja dijelaskan. Diagram ini tidak menunjukkan konektivitas di antara semua project.

Beberapa project host dan beberapa project layanan aplikasi

Penempatan workload

Banyak pilihan konektivitas bergantung pada lokasi regional workload Anda. Untuk panduan tentang penempatan workload, lihat Praktik terbaik untuk pemilihan region Compute Engine. Anda harus memutuskan di mana workload Anda akan berada sebelum memilih lokasi konektivitas.

Konektivitas eksternal dan hybrid

Bagian ini menjelaskan persyaratan dan rekomendasi untuk jalur konektivitas berikut:

  • Koneksi pribadi ke penyedia cloud lainnya
  • Koneksi pribadi ke pusat data lokal
  • Konektivitas internet untuk workload, terutama konektivitas keluar

Cross-Cloud Network melibatkan interkoneksi beberapa jaringan cloud atau jaringan lokal. Jaringan eksternal dapat dimiliki dan dikelola oleh organisasi yang berbeda. Jaringan ini terhubung secara fisik satu sama lain di satu atau beberapa antarmuka jaringan ke jaringan (NNI). Kombinasi NNI harus dirancang, disediakan, dan dikonfigurasi untuk performa, ketahanan, privasi, dan keamanan.

Untuk modularitas, kemampuan untuk digunakan kembali, dan kemampuan untuk menyisipkan NVA keamanan, tempatkan koneksi eksternal dan perutean di VPC transit, yang kemudian berfungsi sebagai layanan konektivitas bersama untuk VPC lainnya. Kebijakan perutean untuk ketahanan, failover, dan preferensi jalur di seluruh domain dapat dikonfigurasi sekali di VPC transit dan dimanfaatkan oleh banyak jaringan VPC lainnya.

Desain NNI dan konektivitas eksternal digunakan nanti untuk Konektivitas internal dan jaringan VPC.

Diagram berikut menunjukkan VPC transit yang berfungsi sebagai layanan konektivitas bersama untuk VPC lain, yang terhubung menggunakan Peering Jaringan VPC, Network Connectivity Center, atau VPN dengan ketersediaan tinggi (HA). Untuk menyederhanakan ilustrasi, diagram ini menunjukkan satu VPC transit, tetapi Anda dapat menggunakan beberapa VPC transit untuk konektivitas di berbagai region.

VPC transit yang digunakan sebagai layanan konektivitas bersama untuk VPC lain

Koneksi pribadi ke penyedia cloud lainnya

Jika Anda memiliki layanan yang berjalan di jaringan penyedia layanan cloud (CSP) lain yang ingin Anda hubungkan ke jaringan Google Cloud , Anda dapat terhubung ke layanan tersebut melalui internet atau melalui koneksi pribadi. Sebaiknya gunakan koneksi pribadi.

Saat memilih opsi, pertimbangkan throughput, privasi, biaya, dan kelayakan operasional.

Untuk memaksimalkan throughput sekaligus meningkatkan privasi, gunakan koneksi langsung berkecepatan tinggi antara jaringan cloud. Koneksi langsung menghilangkan kebutuhan akan peralatan jaringan fisik perantara. Sebaiknya gunakan Cross-Cloud Interconnect, yang menyediakan koneksi langsung ini, serta enkripsi MACsec dan kapasitas throughput hingga 100 Gbps per link.

Jika tidak dapat menggunakan Cross-Cloud Interconnect, Anda dapat menggunakan Dedicated Interconnect atau Partner Interconnect melalui fasilitas colocation.

Pilih lokasi tempat Anda terhubung ke CSP lain berdasarkan kedekatan lokasi dengan region target. Untuk pemilihan lokasi, pertimbangkan hal berikut:

  • Periksa daftar lokasi:
    • Untuk Cross-Cloud Interconnect, periksa daftar lokasi yang tersedia untuk Google Cloud dan CSP (ketersediaan bervariasi menurut penyedia cloud).
    • Untuk Dedicated Interconnect atau Partner Interconnect, pilih lokasi latensi rendah untuk fasilitas kolokasi.
  • Evaluasi latensi antara edge titik kehadiran (POP) yang diberikan dan region yang relevan di setiap CSP.

Untuk memaksimalkan keandalan koneksi lintas cloud, sebaiknya gunakan konfigurasi yang mendukung SLA waktu beroperasi 99,99% untuk workload produksi. Untuk mengetahui detailnya, lihat Ketersediaan tinggi Cross-Cloud Interconnect, Menetapkan ketersediaan 99,99% untuk Dedicated Interconnect, dan Menetapkan ketersediaan 99,99% untuk Partner Interconnect.

Jika Anda tidak memerlukan bandwidth tinggi di antara CSP yang berbeda, Anda dapat menggunakan tunnel VPN. Pendekatan ini dapat membantu Anda memulai, dan Anda dapat mengupgrade ke Cross-Cloud Interconnect saat aplikasi terdistribusi Anda menggunakan lebih banyak bandwidth. Tunnel VPN juga dapat mencapai SLA 99,99%. Untuk mengetahui detailnya, lihat Topologi VPN dengan ketersediaan tinggi (HA).

Koneksi pribadi ke pusat data lokal

Untuk konektivitas ke pusat data pribadi, Anda dapat menggunakan salah satu opsi konektivitas hybrid berikut:

  • Dedicated Interconnect
  • Partner Interconnect
  • VPN dengan ketersediaan tinggi (HA)

Pertimbangan pemilihan rute untuk koneksi ini mirip dengan pertimbangan untuk Koneksi pribadi ke penyedia cloud lainnya.

Diagram berikut menunjukkan koneksi ke jaringan lokal dan cara router lokal dapat terhubung ke Cloud Router melalui kebijakan peering:

Koneksi ke jaringan lokal

Pemilihan rute antardomain dengan jaringan eksternal

Untuk meningkatkan ketahanan dan throughput antarjaringan, gunakan beberapa jalur untuk menghubungkan jaringan.

Saat traffic ditransfer di seluruh domain jaringan, traffic tersebut harus diperiksa oleh perangkat keamanan stateful. Oleh karena itu, diperlukan simetri aliran pada batas antara domain.

Untuk jaringan yang mentransfer data di beberapa region, biaya dan tingkat kualitas layanan setiap jaringan mungkin berbeda secara signifikan. Anda dapat memutuskan untuk menggunakan beberapa jaringan daripada yang lain, berdasarkan perbedaan ini.

Siapkan kebijakan perutean antardomain untuk memenuhi persyaratan Anda terkait transit antar-region, simetri traffic, throughput, dan ketahanan.

Konfigurasi kebijakan perutean antardomain bergantung pada fungsi yang tersedia di edge setiap domain. Konfigurasi juga bergantung pada cara domain yang berdekatan disusun dari perspektif sistem otonom dan alamat IP (subnetting) di berbagai region. Untuk meningkatkan skalabilitas tanpa melebihi batas awalan pada perangkat edge, sebaiknya rencana alamat IP Anda menghasilkan lebih sedikit awalan gabungan untuk setiap kombinasi region dan domain.

Saat mendesain pemilihan rute antar-region, pertimbangkan hal berikut:

  • Google Cloud Jaringan VPC dan Cloud Router mendukung perutean lintas region global. CSP lain mungkin memiliki cakupan VPC dan Border Gateway Protocol (BGP) regional. Untuk mengetahui detailnya, lihat dokumentasi dari CSP Anda yang lain.
  • Cloud Router secara otomatis memberitahukan rute dengan preferensi jalur yang telah ditentukan berdasarkan kedekatan regional. Perilaku perutean ini bergantung pada mode perutean dinamis VPC yang dikonfigurasi. Anda mungkin perlu mengganti preferensi ini, untuk perilaku pemilihan rute yang Anda inginkan.
  • CSP yang berbeda mendukung fungsi BGP dan Deteksi Penerusan Dua Arah (BFD) yang berbeda, dan Cloud Router Google juga memiliki kemampuan kebijakan rute tertentu seperti yang dijelaskan dalam Membuat sesi BGP.
  • CSP yang berbeda mungkin menggunakan atribut penentu BGP yang berbeda untuk menentukan preferensi rute. Lihat dokumentasi CSP Anda untuk mengetahui detailnya.

Perutean antar-domain satu region

Sebaiknya mulai dengan pemilihan rute antar-domain satu region, yang Anda kembangkan untuk membuat koneksi beberapa region dengan pemilihan rute antar-domain.

Desain yang menggunakan Cloud Interconnect harus memiliki minimal dua lokasi koneksi yang berada di region yang sama, tetapi memiliki domain ketersediaan edge yang berbeda.

Tentukan apakah akan mengonfigurasi koneksi duplikat ini dalam desain aktif/aktif atau aktif/pasif:

  • Aktif/aktif menggunakan perutean Equal Cost Multi-Path (ECMP) untuk menggabungkan bandwidth kedua jalur dan menggunakannya secara bersamaan untuk traffic antardomain. Cloud Interconnect juga mendukung penggunaan link gabungan LACP untuk mencapai bandwidth gabungan hingga 200 Gbps per jalur.
  • Aktif/pasif memaksa satu link menjadi standby, dan hanya menerima traffic jika link aktif terganggu.

Sebaiknya gunakan desain aktif/aktif untuk link intra-regional. Namun, topologi jaringan lokal tertentu yang dikombinasikan dengan penggunaan fungsi keamanan stateful dapat memerlukan desain aktif/pasif.

Cloud Router dibuat di beberapa zona, yang memberikan ketahanan yang lebih tinggi daripada yang diberikan oleh satu elemen. Diagram berikut menunjukkan cara semua koneksi yang tangguh bertemu di satu Cloud Router dalam satu region. Desain ini dapat mendukung SLA ketersediaan 99,9% dalam satu area metropolitan jika mengikuti panduan untuk Menetapkan ketersediaan 99,9% untuk Dedicated Interconnect.

Diagram berikut menunjukkan dua router lokal yang terhubung secara redundan ke layanan Cloud Router terkelola di satu region:

Koneksi yang tangguh dapat menggunakan satu Cloud Router

Pemilihan rute antar-domain multi-region

Untuk menyediakan konektivitas cadangan, jaringan dapat melakukan peering di beberapa area geografis. Dengan menghubungkan jaringan di beberapa region, SLA ketersediaan dapat meningkat menjadi 99,99%.

Diagram berikut menunjukkan arsitektur SLA 99,99%. Diagram ini menunjukkan router lokal di dua lokasi berbeda yang terhubung secara redundan ke layanan Cloud Router terkelola di dua region berbeda.

Koneksi Cloud Interconnect di beberapa region

Selain ketahanan, desain perutean multi-regional harus mencapai simetri alur. Desain juga harus menunjukkan jaringan yang dipilih untuk komunikasi antar-regional, yang dapat Anda lakukan dengan pemilihan rute hot-potato dan cold-potato. Gabungkan perutean cold-potato di satu domain dengan perutean hot-potato di domain peer. Untuk domain cold-potato, sebaiknya gunakan domain jaringanGoogle Cloud , yang menyediakan fungsi perutean VPC global.

Simetri alur tidak selalu wajib, tetapi asimetri alur dapat menyebabkan masalah pada fungsi keamanan stateful.

Diagram berikut menunjukkan cara menggunakan pemilihan rute hot-potato dan cold-potato untuk menentukan jaringan transit antar-regional pilihan Anda. Dalam hal ini, traffic dari awalan X dan Y tetap berada di jaringan asal hingga mencapai region yang paling dekat dengan tujuan (cold-potato routing). Traffic dari awalan A dan B beralih ke jaringan lain di region asal, lalu berpindah melalui jaringan lain ke tujuan (perutean hot-potato).

Menggunakan pemilihan rute hot-potato dan cold-potato untuk menentukan jaringan transit antar-regional yang Anda inginkan

Enkripsi traffic antardomain

Kecuali jika dinyatakan lain, traffic tidak dienkripsi pada koneksi Cloud Interconnect antara CSP yang berbeda atau antara Google Cloud dan pusat data lokal. Jika organisasi Anda memerlukan enkripsi untuk traffic ini, Anda dapat menggunakan kemampuan berikut:

  • MACsec untuk Cloud Interconnect: Mengenkripsi traffic melalui koneksi Cloud Interconnect antara router Anda dan router edge Google. Untuk mengetahui detailnya, lihat Ringkasan MACsec untuk Cloud Interconnect.
  • VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect: Menggunakan beberapa tunnel VPN dengan ketersediaan tinggi (HA) untuk dapat menyediakan bandwidth penuh dari koneksi Cloud Interconnect yang mendasarinya. Tunnel VPN dengan ketersediaan tinggi (HA) dienkripsi IPsec dan di-deploy melalui koneksi Cloud Interconnect yang mungkin juga dienkripsi MACsec. Dalam konfigurasi ini, koneksi Cloud Interconnect dikonfigurasi untuk hanya mengizinkan traffic VPN dengan ketersediaan tinggi (HA). Untuk mengetahui detailnya, lihat ringkasan VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect.

Konektivitas internet untuk workload

Untuk konektivitas internet masuk dan keluar, traffic balasan diasumsikan mengikuti arah yang berlawanan dengan arah permintaan asli secara stateful.

Secara umum, fitur yang menyediakan konektivitas internet masuk terpisah dari fitur internet keluar, kecuali untuk alamat IP eksternal yang menyediakan kedua arah secara bersamaan.

Konektivitas internet masuk

Konektivitas internet masuk terutama berkaitan dengan penyediaan endpoint publik untuk layanan yang dihosting di cloud. Contohnya mencakup konektivitas internet ke server aplikasi web dan server game yang dihosting diGoogle Cloud.

Fitur utama yang menyediakan konektivitas internet masuk adalah produk Cloud Load Balancing Google. Desain jaringan VPC tidak bergantung pada kemampuannya untuk menyediakan konektivitas internet masuk:

Konektivitas internet keluar

Contoh konektivitas internet keluar (dengan permintaan awal berasal dari workload ke tujuan internet) mencakup workload yang mengakses API pihak ketiga, mendownload paket software dan update, serta mengirim notifikasi push ke endpoint webhook di internet.

Untuk konektivitas keluar, Anda dapat menggunakan opsi bawaan Google Cloud , seperti yang dijelaskan dalam Alternatif untuk menggunakan alamat IP eksternal. Atau, Anda dapat menggunakan NVA NGFW pusat seperti yang dijelaskan dalam Keamanan jaringan.

Jalur utama untuk menyediakan konektivitas internet keluar adalah tujuan gateway internet default dalam tabel pemilihan rute VPC, yang sering kali merupakan rute default di VPC Google. IP eksternal dan Cloud NAT (layanan NAT terkelolaGoogle Cloud) memerlukan rute yang mengarah ke gateway internet default VPC. Oleh karena itu, desain pemilihan rute VPC yang mengganti rute default harus menyediakan konektivitas keluar melalui cara lain. Untuk mengetahui detailnya, lihat Ringkasan Cloud Router.

Untuk mengamankan konektivitas keluar, Google Cloud menawarkan penerapan Cloud Next Generation Firewall dan Secure Web Proxy untuk memberikan pemfilteran yang lebih mendalam pada URL HTTP dan HTTPS. Namun, dalam semua kasus, traffic mengikuti rute default keluar ke gateway internet default atau melalui rute default kustom di tabel perutean VPC.

Menggunakan IP Anda sendiri

Anda dapat menggunakan alamat IPv4 milik Google untuk konektivitas internet atau menggunakan Bawa alamat IP Anda sendiri (BYOIP) untuk menggunakan ruang IPv4 yang dimiliki organisasi Anda. Sebagian besar produk Google Cloud yang memerlukan alamat IP yang dapat dirutekan ke internet mendukung penggunaan rentang BYOIP.

Anda juga dapat mengontrol reputasi ruang IP melalui penggunaan eksklusifnya. BYOIP membantu portabilitas konektivitas, dan dapat menghemat biaya alamat IP.

Konektivitas internal dan jaringan VPC

Dengan layanan konektivitas eksternal dan hybrid yang dikonfigurasi, resource di VPC transit dapat menjangkau jaringan eksternal. Langkah berikutnya adalah menyediakan konektivitas ini untuk resource yang dihosting di jaringan VPC lain.

Diagram berikut menunjukkan struktur umum VPC, terlepas dari cara Anda mengaktifkan konektivitas eksternal. Diagram ini menunjukkan VPC transit yang menghentikan koneksi eksternal dan menghosting Cloud Router di setiap region. Setiap Cloud Router menerima rute dari peer eksternalnya melalui NNI di setiap region. VPC aplikasi terhubung ke VPC transit sehingga dapat berbagi konektivitas eksternal. Selain itu, VPC transit berfungsi sebagai hub untuk VPC spoke. VPC spoke dapat menghosting aplikasi, layanan, atau kombinasi keduanya.

Struktur umum Cross-Cloud Network

Untuk performa dan skalabilitas yang optimal dengan layanan jaringan cloud bawaan, VPC harus dihubungkan menggunakan NCC seperti yang dijelaskan dalam Konektivitas antar-VPC dengan NCC. NCC menyediakan hal berikut:

  • Akses transitif ke endpoint L4 dan L7 Private Service Connect serta layanan terkaitnya
  • Akses transitif ke jaringan lokal yang dipelajari melalui BGP
  • Skala jaringan VPC sebesar 250 jaringan per hub

Jika Anda ingin menyisipkan peralatan virtual jaringan (NVA) untuk firewall atau fungsi jaringan lainnya, Anda harus menggunakan Peering Jaringan VPC. Firewall perimeter dapat tetap berada di jaringan eksternal. Jika penyisipan NVA diperlukan, gunakan pola Konektivitas antar-VPC dengan Peering Jaringan VPC untuk menghubungkan jaringan VPC Anda.

Konfigurasikan juga penerusan dan peering DNS di VPC transit. Untuk mengetahui detailnya, lihat bagian Desain infrastruktur DNS.

Bagian berikut membahas kemungkinan desain untuk konektivitas hybrid yang mendukung konektivitas IP dasar serta deployment titik akses API.

Konektivitas antar-VPC dengan NCC

Sebaiknya VPC aplikasi, VPC transit, dan VPC akses layanan semuanya terhubung menggunakan spoke VPC NCC.

Titik akses konsumen layanan di-deploy di VPC akses layanan saat perlu dijangkau dari jaringan lain (VPC lain atau jaringan eksternal). Anda dapat men-deploy titik akses konsumen layanan di VPC aplikasi jika titik akses ini hanya perlu dijangkau dari dalam VPC aplikasi

Jika Anda perlu memberikan akses ke layanan di balik akses layanan pribadi, buat VPC akses layanan yang terhubung ke VPC transit menggunakan VPN dengan ketersediaan tinggi (HA). Kemudian, hubungkan VPC layanan terkelola ke VPC akses layanan. VPN dengan ketersediaan tinggi (HA) memungkinkan perutean transitif dari jaringan lain.

Desain ini merupakan kombinasi dari dua jenis konektivitas:

  • NCC: menyediakan konektivitas antara VPC transit, VPC aplikasi, dan VPC akses layanan yang menghosting endpoint Private Service Connect.
  • Koneksi antar-VPC VPN dengan ketersediaan tinggi (HA): menyediakan konektivitas transitif untuk subnet akses layanan pribadi yang dihosting di VPC akses layanan. VPC akses layanan ini tidak boleh ditambahkan sebagai spoke hub NCC.

Saat Anda menggabungkan jenis konektivitas ini, rencanakan pertimbangan berikut:

  • Mendistribusikan ulang subnet Peering Jaringan VPC dan peer NCC ke dalam pemilihan rute dinamis (ke VPC akses layanan melalui VPN dengan ketersediaan tinggi (HA) dan ke jaringan eksternal melalui interkoneksi hybrid)
  • Pertimbangan pemilihan rute multi-regional
  • Penyebaran rute dinamis ke Peering Jaringan VPC dan peering NCC (dari VPC akses layanan melalui VPN dengan ketersediaan tinggi (HA) dan dari jaringan eksternal melalui interkoneksi hybrid)

Diagram berikut menunjukkan VPC akses layanan yang menghosting subnet akses layanan pribadi yang terhubung ke VPC transit dengan VPN dengan ketersediaan tinggi (HA). Diagram ini juga menunjukkan VPC aplikasi, VPC transit, dan VPC akses layanan yang menghosting endpoint konsumen Private Service Connect yang terhubung menggunakan NCC:

Struktur umum Cross-Cloud Network menggunakan spoke VPC NCC

Struktur yang ditampilkan dalam diagram sebelumnya berisi komponen berikut:

  • Jaringan eksternal: Pusat data atau kantor jarak jauh tempat Anda memiliki peralatan jaringan. Contoh ini mengasumsikan bahwa lokasi terhubung menggunakan jaringan eksternal.
  • Jaringan VPC transit: Jaringan VPC dalam project hub yang menerima koneksi dari infrastruktur lokal dan CSP lain, lalu berfungsi sebagai jalur transit dari VPC lain ke jaringan lokal dan CSP.
  • VPC Aplikasi: Project dan jaringan VPC yang menghosting berbagai aplikasi.
  • VPC konsumen untuk akses layanan pribadi: Jaringan VPC yang menghosting akses terpusat melalui akses layanan pribadi ke layanan yang diperlukan oleh aplikasi di jaringan lain.
  • VPC layanan terkelola: Layanan yang disediakan dan dikelola oleh entitas lain, tetapi dapat diakses oleh aplikasi yang berjalan di jaringan VPC.
  • VPC Konsumen untuk Private Service Connect: Jaringan VPC yang menghosting titik akses Private Service Connect ke layanan yang dihosting di jaringan lain.

Gunakan NCC untuk menghubungkan VPC aplikasi ke lampiran VLAN Cloud Interconnect dan instance VPN dengan ketersediaan tinggi (HA) di VPC transit. Jadikan semua VPC sebagai spoke hub NCC, dan jadikan lampiran VLAN serta VPN dengan ketersediaan tinggi (HA) sebagai spoke hybrid dari hub NCC yang sama. Gunakan topologi mesh NCC default untuk mengaktifkan komunikasi di antara semua spoke (VPC dan hybrid). Topologi ini juga memungkinkan komunikasi antara VPC aplikasi yang tunduk pada kebijakan Cloud NGFW. Setiap VPC layanan konsumen yang terhubung melalui VPN dengan ketersediaan tinggi (HA) tidak boleh menjadi spoke hub NCC. Endpoint Private Service Connect dapat di-deploy di spoke VPC NCC dan tidak memerlukan koneksi VPN dengan ketersediaan tinggi (HA) untuk transitivitas lintas VPC saat menggunakan NCC.

Konektivitas antar-VPC dengan Peering Jaringan VPC

Saat titik akses konsumen layanan yang dipublikasikan di-deploy di VPC akses layanan, sebaiknya VPC aplikasi terhubung menggunakan Peering Jaringan VPC ke VPC transit dan VPC akses layanan terhubung ke VPC transit melalui VPN dengan ketersediaan tinggi (HA).

Dalam desain ini, VPC transit adalah hub, dan Anda men-deploy titik akses konsumen untuk endpoint layanan pribadi di VPC akses layanan.

Desain ini merupakan kombinasi dari dua jenis konektivitas:

  • Peering Jaringan VPC: menyediakan konektivitas antara VPC transit dan VPC aplikasi.
  • Koneksi antar-VPC VPN dengan ketersediaan tinggi (HA): menyediakan konektivitas transitif antara VPC akses layanan dan VPC transit.

Saat Anda menggabungkan arsitektur ini, rencanakan pertimbangan berikut:

  • Mendistribusikan ulang subnet peer VPC ke perutean dinamis (ke VPC akses layanan melalui VPN dengan ketersediaan tinggi (HA) dan ke jaringan eksternal melalui koneksi hybrid)
  • Pertimbangan pemilihan rute multi-regional
  • Penyebaran rute dinamis ke peering VPC (dari VPC akses layanan melalui VPN dengan ketersediaan tinggi (HA) dan dari jaringan eksternal melalui koneksi hybrid)

Diagram berikut menunjukkan VPC akses layanan, yang terhubung ke VPC transit dengan VPN dengan ketersediaan tinggi (HA), dan VPC aplikasi, yang terhubung ke VPC transit dengan Peering Jaringan VPC:

VPC layanan pusat yang terhubung ke VPC transit dengan VPN dengan ketersediaan tinggi (HA), dan VPC aplikasi yang terhubung ke VPC transit dengan Peering Jaringan VPC

Struktur yang ditampilkan dalam diagram sebelumnya berisi komponen berikut:

  • Lokasi pelanggan: Pusat data atau kantor jarak jauh tempat Anda memiliki peralatan jaringan. Contoh ini mengasumsikan bahwa lokasi-lokasi tersebut terhubung satu sama lain menggunakan jaringan eksternal.
  • Metro: Area metropolitan yang berisi satu atau beberapa domain ketersediaan edge Cloud Interconnect. Cloud Interconnect terhubung ke jaringan lain di area metropolitan tersebut.
  • Project hub: Project yang menghosting setidaknya satu jaringan VPC yang berfungsi sebagai hub ke jaringan VPC lainnya.
  • VPC Transit: Jaringan VPC dalam project hub yang menerima koneksi dari infrastruktur lokal dan CSP lainnya, lalu berfungsi sebagai jalur transit dari VPC lain ke jaringan lokal dan CSP.
  • Project host aplikasi dan VPC: Project dan jaringan VPC yang menghosting berbagai aplikasi.
  • VPC akses layanan: Jaringan VPC yang menghosting akses terpusat ke layanan yang diperlukan oleh aplikasi di jaringan VPC aplikasi.
  • VPC layanan terkelola: Layanan yang disediakan dan dikelola oleh entity lain, tetapi dapat diakses oleh aplikasi yang berjalan di jaringan VPC.

Untuk desain Peering Jaringan VPC, saat VPC aplikasi perlu berkomunikasi satu sama lain, Anda dapat menghubungkan VPC aplikasi ke hub Network Connectivity Center sebagai spoke VPC. Pendekatan ini menyediakan konektivitas di antara semua VPC di hub Network Connectivity Center. Subgrup komunikasi dapat dibuat dengan menggunakan beberapa hub Network Connectivity Center. Setiap batasan komunikasi yang diperlukan di antara endpoint dalam hub tertentu dapat dicapai menggunakan kebijakan firewall.

Keamanan workload untuk koneksi timur-barat antara VPC aplikasi dapat menggunakan Cloud Next Generation Firewall.

Untuk panduan mendetail dan blueprint konfigurasi guna men-deploy jenis konektivitas ini, lihat Arsitektur jaringan hub-and-spoke.

Desain infrastruktur DNS

Dalam lingkungan hybrid, Cloud DNS atau penyedia eksternal (lokal atau CSP) dapat menangani pencarian DNS. Server DNS eksternal bersifat otoritatif untuk zona DNS eksternal, dan Cloud DNS bersifat otoritatif untuk zonaGoogle Cloud . Penerusan DNS harus diaktifkan secara dua arah antara Google Cloud dan jaringan eksternal, dan firewall harus disetel untuk mengizinkan traffic resolusi DNS.

Jika Anda menggunakan VPC Bersama untuk VPC akses layanan, tempat administrator dari berbagai project layanan aplikasi dapat membuat instance layanan mereka sendiri, gunakan binding lintas project zona DNS. Binding lintas project memungkinkan segmentasi dan delegasi namespace DNS kepada administrator project layanan.

Dalam kasus transit, saat jaringan eksternal berkomunikasi dengan jaringan eksternal lainnya melalui Google Cloud, zona DNS eksternal harus dikonfigurasi untuk meneruskan permintaan langsung satu sama lain. Google Cross-Cloud Network akan menyediakan konektivitas untuk permintaan dan balasan DNS, tetapi Google Cloud DNS terlibat dalam penerusan traffic resolusi DNS antara zona di jaringan eksternal. Setiap aturan firewall yang diterapkan di Cross-Cloud Network harus mengizinkan traffic resolusi DNS antara jaringan eksternal.

Diagram berikut menunjukkan desain DNS yang dapat digunakan dengan konfigurasi konektivitas VPC hub-and-spoke yang diusulkan dalam panduan desain ini:

Desain DNS yang dapat digunakan dengan pola konektivitas hub-and-spoke

Diagram sebelumnya menunjukkan langkah-langkah berikut dalam alur desain:

  1. DNS lokal
    Konfigurasikan server DNS lokal Anda agar bersifat otoritatif untuk zona DNS lokal. Konfigurasikan penerusan DNS (untuk nama Google Cloud DNS) dengan menargetkan alamat IP penerusan masuk Cloud DNS, yang dibuat melalui konfigurasi kebijakan server masuk di VPC hub. Konfigurasi ini memungkinkan jaringan lokal me-resolve nama DNS Google Cloud.
  2. VPC Transit - Proxy Egress DNS
    Beritahukan rentang proxy egress DNS Google 35.199.192.0/19 ke jaringan lokal menggunakan Cloud Router. Permintaan DNS keluar dari Google ke infrastruktur lokal berasal dari rentang alamat IP ini.
  3. VPC Transit - Cloud DNS
    1. Konfigurasikan kebijakan server masuk untuk permintaan DNS masuk dari infrastruktur lokal.
    2. Konfigurasikan zona penerusan Cloud DNS (untuk nama DNS lokal) yang menargetkan server DNS lokal.
  4. VPC akses layanan - Cloud DNS
    1. Konfigurasikan zona peering DNS layanan (untuk nama DNS lokal) yang menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk resource lokal dan layanan melewati VPC hub.
    2. Konfigurasikan zona pribadi DNS layanan di project host layanan dan lampirkan VPC Bersama layanan, VPC Bersama aplikasi, dan VPC hub ke zona tersebut. Hal ini memungkinkan semua host (lokal dan di semua project layanan) untuk me-resolve nama DNS layanan.
  5. Project App Hosting - Cloud DNS
    1. Konfigurasi zona peering DNS Aplikasi untuk nama DNS lokal yang menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk host lokal melewati VPC hub.
    2. Konfigurasikan zona pribadi DNS App Hosting di Project Host Aplikasi dan lampirkan VPC aplikasi, VPC Bersama layanan, dan VPC hub ke zona tersebut. Konfigurasi ini memungkinkan semua host (lokal dan di semua project layanan) untuk me-resolve nama DNS Aplikasi.

Untuk mengetahui informasi selengkapnya, lihat Arsitektur hybrid menggunakan jaringan VPC hub yang terhubung ke jaringan VPC spoke.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: