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 Cross-Cloud Network.

Rangkaian ini terdiri dari bagian berikut:

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

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

Segmentasi jaringan dan struktur project

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

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

Selama tahap perencanaan, sebaiknya Anda juga menentukan domain administratif untuk lingkungan workload Anda. Tetapkan cakupan izin untuk administrator dan developer infrastruktur Anda berdasarkan prinsip hak istimewa paling rendah, dan tetapkan cakupan resource aplikasi ke dalam project aplikasi yang berbeda. Karena administrator infrastruktur perlu menyiapkan konektivitas untuk membagikan 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 dapat mengelola beban kerja mereka dalam satu project, dan tim produksi dapat mengelola beban kerja mereka dalam project terpisah. Kemudian, developer akan menggunakan resource infrastruktur dalam project infrastruktur untuk membuat dan mengelola resource, layanan, load balancing, dan kebijakan perutean DNS untuk beban kerja mereka.

Selain itu, Anda harus memutuskan jumlah jaringan VPC yang akan diterapkan pada awalnya dan cara pengorganisasiannya 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 Menentukan apakah akan membuat beberapa jaringan VPC atau tidak.

Untuk Jaringan Antar-Cloud, 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 ditunjukkan 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 dan subnet VPC, 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 yang dikonsolidasikan dan beberapa project layanan aplikasi yang baru saja dijelaskan. Diagram tidak menunjukkan konektivitas di antara semua project.

Project host infrastruktur gabungan dan beberapa project layanan aplikasi

Project host yang 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 ditagih ke project host infrastruktur dan biaya jaringan, seperti biaya transfer data untuk aplikasi, ditagih ke setiap project host aplikasi.

Diagram berikut memberikan representasi visual dari beberapa project host dan beberapa project layanan aplikasi yang baru saja dijelaskan. Diagram 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 dalam menempatkan beban kerja, lihat Praktik terbaik untuk pemilihan region Compute Engine. Anda harus memutuskan lokasi workload Anda sebelum memilih lokasi konektivitas.

Konektivitas eksternal dan hybrid

Bagian ini menjelaskan persyaratan dan rekomendasi untuk jalur konektivitas berikut:

  • Koneksi pribadi ke penyedia cloud lain
  • 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, penggunaan ulang, dan kemampuan untuk menyisipkan NVA keamanan, tempatkan koneksi dan perutean eksternal di VPC transit, yang kemudian berfungsi sebagai layanan konektivitas bersama untuk VPC lain. Kebijakan perutean untuk ketahanan, failover, dan preferensi jalur di seluruh domain dapat dikonfigurasi satu kali di VPC transit dan dimanfaatkan oleh banyak jaringan VPC lainnya.

Desain NNI dan konektivitas eksternal akan 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 kesederhanaan ilustrasi, diagram 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 lain

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

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

Untuk memaksimalkan throughput sekaligus meningkatkan privasi, gunakan koneksi berkecepatan tinggi langsung 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 kecepatan throughput hingga 100 Gbps per link.

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

Pilih lokasi tempat Anda terhubung ke CSP lain berdasarkan kedekatan lokasi dengan wilayah 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). Google Cloud
    • Untuk Dedicated Interconnect atau Partner Interconnect, pilih lokasi latensi rendah untuk fasilitas kolokasi.
  • Mengevaluasi latensi antara edge titik kehadiran (POP) tertentu dan region yang relevan di setiap CSP.

Untuk memaksimalkan keandalan koneksi lintas cloud, sebaiknya gunakan konfigurasi yang mendukung SLA waktu beroperasi 99,99% untuk beban kerja produksi. Untuk 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 berbagai CSP, 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 hibrida berikut:

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

Pertimbangan perutean untuk koneksi ini mirip dengan pertimbangan untuk Koneksi pribadi ke penyedia cloud lain.

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

Koneksi ke jaringan lokal

Pemilihan rute antar-domain 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. Akibatnya, simetri alur di batas antara domain diperlukan.

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

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

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

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

  • Jaringan VPCGoogle Cloud dan Cloud Router sama-sama mendukung perutean lintas-region global. CSP lain mungkin memiliki VPC dan cakupan 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 yang dikonfigurasi di VPC. Anda mungkin perlu mengganti preferensi ini untuk perilaku perutean 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 penentuan pilihan BGP yang berbeda untuk menentukan preferensi rute. Lihat dokumentasi CSP Anda untuk mengetahui detailnya.

Pemilihan rute antar-domain satu region

Sebaiknya Anda mulai dengan perutean antar-domain satu region, yang Anda bangun untuk membuat koneksi multi-region dengan perutean antar-domain.

Desain yang menggunakan Cloud Interconnect harus memiliki minimal dua lokasi koneksi yang berada di region yang sama, tetapi 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 antar-domain. Cloud Interconnect juga mendukung penggunaan link yang diagregasi LACP untuk mencapai bandwidth gabungan hingga 200 Gbps per jalur.
  • Aktif/pasif memaksa satu link menjadi standby siap, yang hanya menangani 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 di-instansiasi 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 suatu 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 aliran. Desain juga harus menunjukkan jaringan pilihan untuk komunikasi antar-regional, yang dapat Anda lakukan dengan perutean hot-potato dan cold-potato. Pasangkan 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 Anda dapat menggunakan pemilihan rute hot-potato dan cold-potato untuk menentukan jaringan transit antar-region pilihan Anda. Dalam hal ini, traffic dari awalan X dan Y tetap berada di jaringan asal hingga mencapai region yang paling dekat dengan tujuan (routing cold-potato). Traffic dari awalan A dan B beralih ke jaringan lain di region asal, lalu melintasi jaringan lain ke tujuan (perutean hot-potato).

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

Enkripsi traffic antar-domain

Kecuali dinyatakan lain, traffic tidak dienkripsi pada koneksi Cloud Interconnect antara berbagai CSP atau antara pusat data lokal dan Google Cloud . 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 dengan IPsec dan di-deploy melalui koneksi Cloud Interconnect yang juga dapat dienkripsi dengan 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 respons diasumsikan mengikuti arah terbalik dari arah permintaan asli secara stateful.

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

Konektivitas internet masuk

Konektivitas internet inbound 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 inbound 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 (tempat permintaan awal berasal dari workload ke tujuan internet) mencakup workload yang mengakses API pihak ketiga, mendownload paket software dan update, serta mengirimkan notifikasi push ke endpoint webhook di internet.

Untuk konektivitas keluar, Anda dapat menggunakan Google Cloud opsi bawaan, seperti yang dijelaskan dalam Membangun konektivitas internet untuk VM pribadi. 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 perutean VPC, yang sering kali berupa 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 perutean VPC yang menggantikan rute default harus menyediakan konektivitas keluar melalui cara lain. Untuk mengetahui detailnya, lihat Ringkasan Cloud Router.

Untuk mengamankan konektivitas keluar, Google Cloud menawarkan penegakan 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 dalam 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 yang memerlukan alamat IP yang dapat dirutekan melalui internet mendukung penggunaan rentang BYOIP. Google Cloud

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 membuat konektivitas ini tersedia 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 Network Connectivity Center seperti yang dijelaskan dalam Konektivitas antar-VPC dengan Network Connectivity Center. Network Connectivity Center menyediakan berikut ini:

  • 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 250 jaringan per hub

Jika Anda ingin menyisipkan appliance 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 adalah persyaratan, gunakan pola Konektivitas antar-VPC dengan Peering Jaringan VPC untuk menghubungkan VPC Anda.

Konfigurasi penerusan dan peering DNS di VPC transit juga. 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 Network Connectivity Center

Sebaiknya semua VPC aplikasi, VPC transit, dan VPC akses layanan terhubung menggunakan spoke VPC Network Connectivity Center.

Titik akses konsumen layanan di-deploy di VPC akses layanan jika 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 pemilihan rute transitif dari jaringan lain.

Desainnya merupakan kombinasi dari dua jenis konektivitas:

  • Network Connectivity Center: 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 Network Connectivity Center.

Saat Anda menggabungkan jenis konektivitas ini, rencanakan pertimbangan berikut:

  • Redistribusi peering Jaringan VPC dan peering Network Connectivity Center subnet ke dalam perutean 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 Network Connectivity Center (dari VPC akses layanan melalui VPN 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 HA. Diagram ini juga menunjukkan VPC aplikasi, VPC transit, dan VPC akses layanan yang menghosting endpoint konsumen Private Service Connect yang terhubung menggunakan Network Connectivity Center:

Struktur umum Cross-Cloud Network menggunakan spoke VPC Network Connectivity Center

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 bersama menggunakan jaringan eksternal.
  • Jaringan VPC transit: Jaringan VPC dalam project hub yang menerima koneksi dari jaringan 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 dibutuhkan 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 Network Connectivity Center 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 Network Connectivity Center, dan jadikan lampiran VLAN dan VPN dengan ketersediaan tinggi (HA) sebagai spoke hybrid dari hub Network Connectivity Center yang sama. Gunakan topologi mesh Network Connectivity Center default untuk mengaktifkan komunikasi di antara semua spoke (VPC dan hybrid). Topologi ini juga memungkinkan komunikasi antar-VPC aplikasi yang tunduk pada kebijakan Cloud NGFW. VPC layanan konsumen yang terhubung melalui HA VPN tidak boleh menjadi spoke hub Network Connectivity Center. Endpoint Private Service Connect dapat di-deploy di spoke VPC Network Connectivity Center dan tidak memerlukan koneksi VPN dengan ketersediaan tinggi untuk transitivitas lintas-VPC saat menggunakan Network Connectivity Center.

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 HA VPN.

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

Desainnya merupakan kombinasi dari dua jenis konektivitas:

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

Saat Anda menggabungkan arsitektur ini, rencanakan pertimbangan berikut:

  • Redistribusi subnet peering VPC ke dalam perutean dinamis (ke VPC akses layanan melalui VPN dengan ketersediaan tinggi dan ke jaringan eksternal melalui koneksi hybrid)
  • Pertimbangan pemilihan rute multi-regional
  • Propagasi 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 HA VPN, dan VPC aplikasi, yang terhubung ke VPC transit dengan Peering Jaringan VPC:

VPC layanan pusat terhubung ke VPC transit dengan VPN HA, dan VPC aplikasi 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 terhubung bersama 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 untuk jaringan VPC lainnya.
  • VPC Transit: Jaringan VPC dalam project hub yang menerima koneksi dari jaringan lokal dan CSP lain, lalu berfungsi sebagai jalur transit dari VPC lain ke jaringan lokal dan CSP.
  • Project dan VPC host aplikasi: 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 entitas 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. Pembatasan komunikasi yang diperlukan di antara endpoint dalam hub tertentu dapat dicapai menggunakan kebijakan firewall.

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

Untuk panduan dan cetak biru konfigurasi mendetail dalam men-deploy jenis konektivitas ini, lihat Arsitektur jaringan hub-and-spoke.

Desain infrastruktur DNS

Di 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 project layanan aplikasi yang berbeda dapat membuat 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 lain melalui Google Cloud, zona DNS eksternal harus dikonfigurasi untuk meneruskan permintaan secara langsung satu sama lain. Google Cross-Cloud Network akan menyediakan konektivitas agar permintaan dan respons DNS selesai, tetapi Google Cloud DNS terlibat dalam meneruskan traffic resolusi DNS apa pun antar-zona di jaringan eksternal. Aturan firewall apa pun yang diterapkan di Jaringan Lintas Cloud harus mengizinkan traffic resolusi DNS di antara jaringan eksternal.

Diagram berikut menunjukkan desain DNS yang dapat digunakan dengan salah satu 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
    Konfigurasi server DNS lokal Anda agar bersifat otoritatif untuk zona DNS lokal. Konfigurasi 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 Google Cloud DNS.
  2. Transit VPC - Proxy Traffic Keluar DNS
    Iklankan rentang proxy traffic keluar DNS Google 35.199.192.0/19 ke jaringan lokal menggunakan Cloud Router. Permintaan DNS keluar dari Google ke lokal berasal dari rentang alamat IP ini.
  3. Transit VPC - Cloud DNS
    1. Konfigurasi kebijakan server masuk untuk permintaan DNS masuk dari lokal.
    2. Konfigurasi penerusan zona Cloud DNS (untuk nama DNS lokal) yang menargetkan server DNS lokal.
  4. VPC akses layanan - Cloud DNS
    1. Konfigurasi zona peering DNS layanan (untuk nama DNS lokal) dengan menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk resource lokal dan layanan dilakukan melalui VPC hub.
    2. Konfigurasi 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) me-resolve nama DNS layanan.
  5. Project host aplikasi - Cloud DNS
    1. Konfigurasi zona peering DNS Aplikasi untuk nama DNS lokal dengan menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk host lokal dilakukan melalui VPC hub.
    2. Konfigurasi zona pribadi App DNS 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) 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: