Dokumen ini adalah bagian dari seri panduan desain untuk Jaringan Lintas Cloud.
Rangkaian ini terdiri dari bagian berikut:
- Cross-Cloud Network untuk aplikasi terdistribusi
- Segmentasi dan konektivitas jaringan untuk aplikasi terdistribusi di Cross-Cloud Network (dokumen ini)
- Jaringan layanan untuk aplikasi terdistribusi di Jaringan Lintas Cloud
- Keamanan jaringan untuk aplikasi terdistribusi di Cross-Cloud Network
Bagian ini membahas struktur dan konektivitas segmentasi jaringan, yang merupakan fondasi desain. Dokumen ini menjelaskan fase-fase saat Anda membuat pilihan berikut:
- Segmentasi jaringan dan struktur project secara keseluruhan.
- Tempat Anda menempatkan beban kerja.
- Cara project Anda terhubung ke jaringan penyedia cloud lokal dan eksternal lainnya, termasuk desain untuk konektivitas, pemilihan rute, dan enkripsi.
- Cara jaringan VPC Anda terhubung secara internal satu sama lain.
- Cara Google Cloud subnet VPC Anda terhubung satu sama lain dan ke jaringan lain, termasuk cara Anda menyiapkan jangkauan layanan dan DNS.
Segmentasi jaringan dan struktur project
Selama tahap perencanaan, Anda harus memilih antara salah satu dari dua struktur project:
- Project host infrastruktur gabungan, tempat Anda menggunakan satu project host infrastruktur untuk mengelola semua resource jaringan untuk semua aplikasi
- Project host 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 beban kerja Anda. Cakupan izin untuk developer dan administrator infrastruktur Anda berdasarkan prinsip hak istimewa terendah, dan 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 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 diimplementasikan pada awalnya dan cara jaringan tersebut akan diatur dalam hierarki resource Anda. Untuk mengetahui detail tentang cara memilih hierarki resource, lihat Menentukan hierarki resource untuk Google Cloud zona landing. Untuk mengetahui detail tentang cara memilih jumlah jaringan VPC, lihat Menentukan apakah akan membuat beberapa jaringan VPC atau tidak.
Untuk Jaringan Lintas 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 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 antar-jaringan VPC.
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 cocok 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 VPC aplikasi dalam jumlah yang lebih sedikit.
Diagram berikut memberikan representasi visual project host infrastruktur konsolidasi dan beberapa project layanan aplikasi yang baru saja dijelaskan. Diagram tidak menunjukkan konektivitas di antara semua project.
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 untuk 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.
Penempatan beban kerja
Banyak pilihan konektivitas bergantung pada lokasi regional workload Anda. Untuk panduan menempatkan beban kerja, lihat Praktik terbaik untuk pemilihan region Compute Engine. Anda harus memutuskan lokasi workload 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 beban kerja, 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 penggunaan kembali, 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 pemilihan rute untuk ketahanan, penggantian, dan preferensi jalur di seluruh domain dapat dikonfigurasi satu kali di VPC transisi 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 memudahkan ilustrasi, diagram menunjukkan satu VPC transit, tetapi Anda dapat menggunakan beberapa VPC transit untuk konektivitas di berbagai region.
Koneksi pribadi ke penyedia cloud lainnya
Jika memiliki layanan yang berjalan di jaringan penyedia layanan cloud (CSP) lain yang ingin dihubungkan 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 kelangsungan operasional.
Untuk memaksimalkan throughput sekaligus meningkatkan privasi, gunakan koneksi berkecepatan tinggi langsung antara jaringan cloud. Koneksi langsung menghilangkan kebutuhan 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 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) tertentu dan region yang relevan di setiap CSP.
Untuk memaksimalkan keandalan koneksi lintas cloud Anda, 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 hibrida 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 lain.
Diagram berikut menunjukkan koneksi ke jaringan lokal dan cara router lokal dapat terhubung ke Cloud Router melalui kebijakan peering:
Pemilihan rute antar-domain dengan jaringan eksternal
Untuk meningkatkan ketahanan dan throughput antar-jaringan, gunakan beberapa jalur untuk menghubungkan jaringan.
Saat ditransfer di seluruh domain jaringan, traffic harus diperiksa oleh perangkat keamanan stateful. Akibatnya, diperlukan simetri aliran di 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 pemilihan rute 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 tepi setiap domain. Konfigurasi juga bergantung pada cara domain tetangga disusun dari perspektif sistem otonom dan alamat IP (subnetting) di berbagai region. Untuk meningkatkan skalabilitas tanpa melebihi batas awalan di perangkat edge, sebaiknya rencana alamat IP Anda menghasilkan lebih sedikit awalan gabungan untuk setiap kombinasi wilayah dan domain.
Saat mendesain pemilihan rute antar-regional, pertimbangkan hal berikut:
- Google Cloud Jaringan VPC dan Cloud Router mendukung perutean lintas region global. CSP lain mungkin memiliki cakupan Border Gateway Protocol (BGP) dan VPC 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 pemilihan rute ini bergantung pada mode pemilihan rute dinamis yang dikonfigurasi di VPC. 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 Membangun sesi BGP.
- CSP yang berbeda mungkin menggunakan atribut pemutusan BGP yang berbeda untuk menentukan preferensi rute. Lihat dokumentasi CSP Anda untuk mengetahui detailnya.
Pemilihan rute antar-domain satu region
Sebaiknya mulai dengan pemilihan rute antar-domain satu region, yang Anda buat untuk membuat beberapa koneksi region dengan pemilihan rute antar-domain.
Desain yang menggunakan Cloud Interconnect harus memiliki minimal dua lokasi koneksi yang berada di region yang sama, tetapi domain ketersediaan edge-nya 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 agregat LACP untuk mencapai bandwidth agregat hingga 200 Gbps per jalur.
- Aktif/pasif memaksa satu link menjadi siaga siap, 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 dibuat instance-nya di beberapa zona, yang memberikan ketahanan yang lebih tinggi daripada yang diberikan oleh satu elemen. Diagram berikut menunjukkan bagaimana semua koneksi tangguh berkumpul 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:
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 yang berbeda.
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. Menyambungkan 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 pemilihan rute 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 wilayah yang paling dekat dengan tujuan (cold-potato routing). Traffic dari awalan A dan B beralih ke jaringan lain di region asal, lalu melintasi jaringan lain ke tujuan (hot-potato routing).
Enkripsi traffic antar-domain
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) agar dapat memberikan bandwidth penuh 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 terbalik dari arah permintaan asli secara bertahap.
Umumnya, fitur yang menyediakan konektivitas internet masuk terpisah dari fitur internet keluar, dengan pengecualian 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 di Google 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:
- Jalur perutean untuk Load Balancer Jaringan passthrough eksternal menyediakan konektivitas antara klien dan VM backend.
- Jalur pemilihan rute antara Google Front End (GFE) dan backend menyediakan konektivitas antara proxy GFE untuk Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal global dan VM backend.
- Subnet khusus proxy menyediakan konektivitas antara proxy Envoy untuk Load Balancer Aplikasi eksternal regional atau Load Balancer Jaringan proxy eksternal regional dan VM backend.
Konektivitas internet keluar
Contoh konektivitas internet keluar (saat 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 Google Cloud opsi bawaan, seperti yang dijelaskan dalam Mem-build 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 di tabel perutean 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 rute 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 dukungan alamat IP yang dapat dirutekan internet menggunakan 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. Gambar 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.
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 hal berikut:
- Akses transitif ke endpoint L4 dan L7 Private Service Connect serta layanan terkait
- Akses transitif ke jaringan lokal yang dipelajari melalui BGP
- Skala jaringan VPC sebesar 250 jaringan per hub
Jika ingin menyisipkan virtual appliance 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 merupakan persyaratan, gunakan pola Konektivitas antar-VPC dengan Peering Jaringan VPC untuk menghubungkan 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 campuran yang mendukung konektivitas IP dasar serta deployment titik akses API.
Konektivitas antar-VPC dengan Network Connectivity Center
Sebaiknya VPC aplikasi, VPC transit, dan VPC akses layanan semuanya 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 dapat 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.
Desain ini adalah 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): memberikan konektivitas transit 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 subnet peering VPC Network Peering dan Network Connectivity Center ke perutean dinamis (ke VPC akses layanan melalui VPN dengan ketersediaan tinggi (HA) dan ke jaringan eksternal melalui interkoneksi hybrid)
- Pertimbangan pemilihan rute multi-regional
- Propagasi 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 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 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 di project hub yang menampung koneksi dari CSP lokal dan CSP lainnya, 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 Network Connectivity Center untuk menghubungkan VPC aplikasi ke lampiran VLAN Cloud Interconnect dan instance VPN dengan ketersediaan tinggi (HA) di VPC transit. Buat semua VPC menjadi spoke hub Network Connectivity Center, dan buat lampiran VLAN dan VPN dengan ketersediaan tinggi (HA) menjadi spoke campuran 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. Setiap VPC layanan konsumen yang terhubung melalui VPN dengan ketersediaan tinggi (HA) tidak boleh merupakan spoke hub Network Connectivity Center. Endpoint Private Service Connect dapat di-deploy di spoke VPC Network Connectivity Center dan tidak memerlukan koneksi VPN HA 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 VPC Network Peering ke VPC transit dan VPC akses layanan terhubung ke VPC transit melalui VPN HA.
Dalam desain ini, VPC transportasi umum adalah hub, dan Anda men-deploy titik akses konsumen untuk endpoint layanan pribadi di VPC akses layanan.
Desain ini adalah 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 transportasi umum.
Saat Anda menggabungkan arsitektur ini, rencanakan pertimbangan berikut:
- Distribusi 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:
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 minimal satu jaringan VPC yang berfungsi sebagai hub ke jaringan VPC lainnya.
- VPC Transit: Jaringan VPC dalam project hub yang menyediakan koneksi dari CSP 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 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. Setiap batasan komunikasi yang diperlukan di antara endpoint dalam hub tertentu dapat dicapai menggunakan kebijakan firewall.
Keamanan beban kerja untuk koneksi east-west 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 project layanan aplikasi yang berbeda 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 secara langsung satu sama lain. Jaringan lintas-Cloud Google akan menyediakan konektivitas agar permintaan dan respons DNS selesai, tetapi Google Cloud DNS terlibat dalam meneruskan traffic resolusi DNS apa pun di antara zona di jaringan eksternal. Setiap aturan firewall yang diterapkan di Jaringan Lintas Cloud harus mengizinkan traffic resolusi DNS di antara jaringan eksternal.
Diagram berikut menunjukkan desain DNS yang dapat digunakan dengan konfigurasi konektivitas VPC hub-and-spoke apa pun yang diusulkan dalam panduan desain ini:
Diagram sebelumnya menunjukkan langkah-langkah berikut dalam alur desain:
- DNS lokal
Konfigurasi 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 Google Cloud DNS. - Transit VPC - Proxy Traffic Keluar DNS
Iklankan rentang proxy traffic keluar DNS Google35.199.192.0/19
ke jaringan lokal menggunakan Cloud Router. Permintaan DNS keluar dari Google ke lokal berasal dari rentang alamat IP ini. - VPC Transit - Cloud DNS
- Konfigurasikan kebijakan server masuk untuk permintaan DNS masuk dari lokal.
- Konfigurasikan zona penerusan Cloud DNS (untuk nama DNS lokal) yang menargetkan server DNS lokal.
- VPC akses layanan - Cloud DNS
- Konfigurasikan zona peering DNS layanan (untuk nama DNS lokal) yang menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk resource lokal dan layanan akan melalui VPC hub.
- 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 (di lokal dan di semua project layanan) untuk me-resolve nama DNS layanan.
- Project host aplikasi - Cloud DNS
- Konfigurasikan zona peering DNS Aplikasi untuk nama DNS lokal yang menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk host lokal akan melewati VPC hub.
- Konfigurasikan zona pribadi DNS Aplikasi di Project Host Aplikasi dan lampirkan VPC aplikasi, VPC Bersama layanan, dan VPC hub ke zona. Konfigurasi ini memungkinkan semua host (di 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
- Buat desain jaringan layanan untuk aplikasi Cross-Cloud Network.
- Men-deploy konektivitas antar-VPC Jaringan Lintas Cloud menggunakan Network Connectivity Center.
- Men-deploy konektivitas antar-VPC Jaringan Lintas Cloud menggunakan Peering Jaringan VPC.
- Pelajari lebih lanjut Google Cloud produk yang digunakan dalam panduan desain ini:
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis:
- Victor Moreno | Product Manager, Cloud Networking
- Ghaleb Al-habian | Network Specialist
- Deepak Michael | Networking Specialist Customer Engineer
- Osvaldo Costa | Networking Specialist Customer Engineer
- Jonathan Almaleh | Staff Technical Solutions Consultant
Kontributor lainnya:
- Zach Seils | Networking Specialist
- Christopher Abraham | Networking Specialist Customer Engineer
- Emanuele Mazza | Networking Product Specialist
- Aurélien Legrand | Cloud Engineer Strategis
- Eric Yu | Networking Specialist Customer Engineer
- Kumar Dhanagopal | Developer Solusi Lintas Produk
- Mark Schlagenhauf | Technical Writer, Networking
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer