Segmentasi jaringan dan konektivitas untuk aplikasi terdistribusi di Jaringan Lintas Cloud

Last reviewed 2024-04-05 UTC

Dokumen ini merupakan bagian dari rangkaian panduan desain untuk Jaringan Lintas Cloud.

Rangkaian ini terdiri dari bagian berikut:

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

  • Segmentasi jaringan secara keseluruhan dan struktur project.
  • Di mana beban kerja Anda ditempatkan.
  • Cara project Anda terhubung ke jaringan lokal eksternal dan jaringan penyedia cloud lainnya, 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, 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 yang dikombinasikan dengan project host yang berbeda untuk setiap aplikasi

Selama tahap perencanaan, sebaiknya Anda juga menentukan domain administratif untuk lingkungan workload Anda. Tentukan cakupan izin untuk administrator dan developer infrastruktur berdasarkan prinsip hak istimewa terendah, dan cakupankan resource aplikasi ke berbagai project aplikasi. 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 mungkin mengelola beban kerja mereka dalam project terpisah. Selanjutnya, developer 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 jumlah jaringan VPC yang akan diimplementasikan pada awalnya dan cara pengaturannya dalam hierarki resource. 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.

Untuk Jaringan Lintas Cloud, sebaiknya gunakan VPC berikut:

  • Satu atau beberapa VPC aplikasi untuk menghosting resource bagi berbagai aplikasi.
  • VPC transit, tempat semua konektivitas eksternal ditangani.
  • VPC layanan pusat opsional, yang dapat digunakan untuk mengonsolidasikan 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 terkonsolidasi atau tersegmentasi, seperti yang dijelaskan di bagian selanjutnya. Diagram yang ditampilkan di sini tidak menunjukkan konektivitas antarjaringan VPC.

Struktur VPC yang direkomendasikan

Project host infrastruktur terkonsolidasi

Anda dapat menggunakan project host infrastruktur gabungan untuk mengelola semua resource jaringan, seperti subnet, peering, dan load balancer.

Beberapa VPC Bersama aplikasi dengan project layanan aplikasinya yang sesuai dapat dibuat dalam project host infrastruktur agar sesuai dengan struktur organisasi. Gunakan beberapa project layanan aplikasi untuk mendelegasikan administrasi resource. Seluruh jaringan di seluruh VPC aplikasi ditagih ke project host infrastruktur terkonsolidasi.

Untuk struktur project ini, banyak project layanan aplikasi yang dapat berbagi VPC aplikasi dalam jumlah yang lebih kecil.

Diagram berikut memberikan representasi visual dari project host infrastruktur gabungan 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 disegmentasikan

Dalam pola ini, setiap grup aplikasi memiliki VPC dan project host aplikasinya sendiri. Beberapa project layanan aplikasi dapat ditambahkan 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 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 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 mengetahui panduan penempatan 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 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-jaringan ini secara fisik terhubung 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 kembali, dan kemampuan untuk menyisipkan NVA keamanan, tempatkan koneksi eksternal dan perutean 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 sekali di VPC transit dan dimanfaatkan oleh banyak jaringan VPC lainnya.

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

Diagram berikut menunjukkan penayangan VPC transit sebagai layanan konektivitas bersama untuk VPC lain, yang terhubung menggunakan Peering Jaringan VPC, Network Connectivity Center, atau VPN dengan ketersediaan tinggi (HA):

VPC Transit digunakan sebagai layanan konektivitas bersama untuk VPC lain

Koneksi pribadi ke penyedia cloud lain

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 kelayakan operasional.

Untuk memaksimalkan throughput sekaligus meningkatkan privasi, gunakan koneksi langsung berkecepatan tinggi antarjaringan cloud. Koneksi langsung menghilangkan kebutuhan peralatan jaringan fisik menengah. Sebaiknya gunakan Cross-Cloud Interconnect yang menyediakan koneksi langsung ini, serta enkripsi MAC 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 region target. Untuk memilih lokasi, pertimbangkan hal berikut:

  • Periksa daftar lokasi:
    • Untuk Cross-Cloud Interconnect, lihat 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 beban kerja 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 tidak memerlukan bandwidth tinggi antar-CSP yang berbeda, Anda dapat menggunakan tunnel VPN. Pendekatan ini dapat membantu Anda memulai, dan Anda dapat melakukan upgrade 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 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

Perutean 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 harus diperiksa oleh perangkat keamanan stateful. Akibatnya, simetri aliran pada batas antar-domain diperlukan.

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

Siapkan kebijakan perutean antar-domain guna memenuhi persyaratan Anda untuk transportasi umum 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 yang berdekatan disusun dari sistem otonom dan perspektif pengalamatan IP (subnetting) di berbagai region. Untuk meningkatkan skalabilitas tanpa melebihi batas awalan pada perangkat edge, sebaiknya paket alamat IP Anda menghasilkan awalan gabungan yang lebih sedikit untuk setiap kombinasi region dan domain.

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

  • Jaringan VPC Google Cloud dan Cloud Router mendukung perutean lintas region global. CSP lain mungkin memiliki cakupan VPC regional dan cakupan Border Gateway Protocol (BGP). Untuk detailnya, lihat dokumentasi dari CSP lainnya.
  • 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 dari VPC. Anda mungkin perlu mengganti preferensi ini untuk perilaku perutean yang diinginkan.
  • 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 Menetapkan sesi BGP.
  • CSP yang berbeda mungkin menggunakan atribut tie-breaking BGP yang berbeda untuk menentukan preferensi rute. Lihat dokumentasi CSP Anda untuk detailnya.

Perutean antar-domain satu region

Sebaiknya mulai dengan perutean antar-domain region tunggal, yang Anda kembangkan untuk membuat beberapa koneksi 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 dari kedua jalur dan menggunakannya secara bersamaan untuk traffic antar-domain. Cloud Interconnect juga mendukung penggunaan link gabungan LCP untuk mencapai bandwidth agregat hingga 200 Gbps per jalur.
  • Aktif/pasif memaksa satu link menjadi siap digunakan, yang hanya menangani traffic jika link yang aktif terganggu.

Kami merekomendasikan 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 lebih tinggi daripada yang diberikan oleh satu elemen. Diagram berikut menunjukkan bagaimana semua koneksi 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 yang dikelola dalam satu region:

Koneksi yang tangguh dapat menggunakan Cloud Router tunggal

Perutean antar-domain multi-region

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

Diagram berikut menunjukkan arsitektur SLA 99,99%. Contoh 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 pilihan untuk komunikasi antar-regional, yang dapat Anda lakukan dengan perutean hot potato dan cold-potato. Sambungkan perutean cold-potato di satu domain dengan perutean hot potato di domain peer. Untuk domain cold-potato, sebaiknya gunakan domain jaringan Google Cloud, yang menyediakan fungsi perutean VPC global.

Simetri flow 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 transportasi umum antar-regional pilihan Anda. Dalam hal ini, traffic dari awalan X dan Y tetap berada di jaringan asal hingga sampai ke region yang paling dekat dengan tujuan (perutean cold-potato). Traffic dari awalan A dan B beralih ke jaringan lain di region asal, lalu berpindah melintasi jaringan lain ke tujuan (pemilihan rute hot potato).

Menggunakan perutean hot potato dan cold potato untuk menentukan jaringan transportasi umum antar-regional pilihan Anda

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 for 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) di Cloud Interconnect: Menggunakan beberapa terowongan VPN dengan ketersediaan tinggi (HA) agar dapat memberikan bandwidth penuh untuk koneksi Cloud Interconnect yang mendasarinya. Tunnel VPN dengan ketersediaan tinggi (HA) dienkripsi IPsec dan di-deploy melalui koneksi Cloud Interconnect yang mungkin juga 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 balasan diasumsikan mengikuti secara tegas arah kebalikan dari arah permintaan asli.

Secara umum, 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.

Semua jenis Cloud Load Balancing menyediakan jalur tersendiri untuk traffic yang kembali ke sumber internet, terlepas dari apakah Anda menggunakan jalur kembali khusus VPC atau subnet proxy yang ditentukan pengguna. Desain VPC umumnya tidak bergantung pada kemampuannya dalam menyediakan konektivitas internet masuk.

Konektivitas internet keluar

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

Untuk konektivitas keluar, Anda dapat menggunakan opsi bawaan Google Cloud, 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 merupakan rute default di VPC Google. IP eksternal dan Cloud NAT (layanan NAT yang dikelola Google 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 Firewall Cloud Next Generation dan Secure Web Proxy untuk memberikan pemfilteran lebih dalam 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 Bring your own IP address (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 selanjutnya adalah menyediakan konektivitas ini untuk resource yang dihosting di VPC lain.

Diagram berikut menunjukkan struktur umum VPC, terlepas dari cara Anda mengaktifkan konektivitas eksternal. Layanan ini menunjukkan VPC transportasi yang menghentikan koneksi eksternal dan menghosting Cloud Router di setiap region. Setiap Cloud Router menerima rute dari peer eksternal melalui NIS 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 Jaringan Lintas Cloud

Selain itu, konfigurasikan penerusan dan peering DNS di VPC transit. Untuk mengetahui detailnya, lihat bagian desain infrastruktur DNS.

Untuk mendapatkan performa dan layanan jaringan cloud bawaan yang lebih baik, sebaiknya lakukan interkoneksi VPC dengan Cross-Cloud Network atau Peering Jaringan VPC, bukan VPN dengan ketersediaan tinggi (HA).

Endpoint Private Service Connect dan frontend akses layanan pribadi tidak dapat dijangkau di seluruh Peering Jaringan VPC atau Jaringan Lintas Cloud. Kami merekomendasikan penggunaan VPN dengan ketersediaan tinggi (HA) untuk konektivitas antar-VPC guna mengatasi batasan tersebut. Karena penggunaan VPN dengan ketersediaan tinggi (HA) untuk konektivitas antar-VPC dapat menghasilkan throughput yang lebih rendah dan peningkatan overhead operasional, desain layanan terpusat mengurangi rentang deployment VPN dengan ketersediaan tinggi (HA).

Atau, Anda dapat menerapkan konektivitas transitif antar-VPC ke endpoint layanan yang dipublikasikan dengan menempatkan Load Balancer Jaringan proxy internal di depan endpoint layanan. Pendekatan ini memiliki beberapa batasan yang perlu dipertimbangkan, yang dibahas di bagian konektivitas dengan spoke Network Connectivity Center menggunakan load balancing.

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

Konektivitas antar-VPC untuk layanan terpusat

Saat endpoint layanan yang dipublikasikan dapat di-deploy di VPC layanan terpusat, sebaiknya VPC aplikasi terhubung melalui Peering Jaringan VPC ke hub (VPC transit) dan VPC layanan pusat terhubung ke hub melalui VPN dengan ketersediaan tinggi (HA).

Dalam desain ini, VPC transit adalah hub, dan Anda men-deploy aturan penerusan untuk endpoint layanan pribadi di VPC layanan pusat. Jadikan VPC layanan pusat sebagai jaringan VPC Bersama, dan izinkan administrator project layanan membuat endpoint layanan di jaringan bersama.

Desain ini adalah kombinasi dari dua jenis konektivitas:

  • Peering Jaringan VPC: menyediakan konektivitas antara VPC hub dan VPC aplikasi.
  • Koneksi antar-VPC VPN dengan ketersediaan tinggi (HA): menyediakan konektivitas transitif untuk VPC layanan pusat ke hub.

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

Saat Anda menggabungkan arsitektur ini, rencanakan pertimbangan berikut:

  • Pendistribusian ulang subnet peer VPC ke perutean dinamis (ke VPN dengan ketersediaan tinggi (HA) dan ke hybrid)
  • Pertimbangan pemilihan rute multi-regional
  • Penerapan rute dinamis ke peering VPC (dari VPN dengan ketersediaan tinggi (HA) dan dari hybrid)

Diagram berikut menunjukkan VPC layanan pusat yang terhubung ke VPC transit dengan VPN dengan ketersediaan tinggi (HA), dan VPC aplikasi yang terhubung ke VPC transit menggunakan 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 menggunakan Peering Jaringan VPC

Struktur yang ditampilkan dalam diagram sebelumnya berisi komponen-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 ke jaringan VPC lain.
  • VPC Transit: Jaringan VPC di project hub yang mendapatkan koneksi dari lokal dan CSP lainnya, 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 Layanan: Jaringan VPC yang menghosting akses terpusat ke layanan yang dibutuhkan 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 hub-and-spoke, saat VPC aplikasi perlu berkomunikasi satu sama lain, Anda dapat menghubungkan VPC aplikasi ke hub Network Connectivity Center sebagai spoke. Pendekatan ini memberikan konektivitas di antara semua VPC di hub Network Connectivity Center. Subgrup komunikasi dapat dibuat menggunakan beberapa hub {i>Network Connectivity Center<i}. Batasan komunikasi apa pun yang diperlukan di antara endpoint dalam hub tertentu dapat dicapai dengan menggunakan kebijakan firewall.

Konektivitas dengan Network Connectivity Center menggunakan VPC menggunakan load balancing

Pola ini mencakup semua VPC sebagai jari-jari di hub Network Connectivity Center, dan dapat menampung hingga 250 VPC yang saling terhubung. Hub Network Connectivity Center adalah konstruksi bidang pengelolaan yang membuat konektivitas bidang data mesh penuh di antara jaringan VPC yang terdaftar sebagai jari-jari ke hub Network Connectivity Center. Pola ini menyediakan konektivitas apa saja dan memungkinkan deployment layanan terkelola di VPC mana pun, sehingga tidak perlu lagi memutuskan antara layanan terpusat atau terdistribusi.

Untuk mengatasi batasan transitivitas, layanan terkelola dan koneksi hybrid diakses melalui Load Balancer Jaringan proxy internal. Keamanan workload untuk koneksi timur-barat dapat menggunakan Cloud Next Generation Firewall. Anda juga dapat menggunakan NAT Antar-VPC dengan pola ini.

Pola ini memiliki beberapa batasan, jadi hal berikut harus dipertimbangkan sebelum mengadopsi pola ini:

  • Anda tidak dapat menggunakan NVA untuk {i>firewall<i} perimeter dengan pola ini. Firewall perimeter harus tetap berada di jaringan eksternal.
  • Hanya traffic TCP yang didukung ke dan dari jaringan eksternal. Batasan ini terjadi karena koneksi ke jaringan eksternal dijalankan melalui Load Balancer Jaringan proxy internal.
  • Layanan yang dipublikasikan akan memiliki frontend tambahan di load balancer proxy. Frontend tambahan ini memperbanyak data tambahan di DNS dan memerlukan pencarian DNS terpisah.
  • Layanan Lapisan 4 memerlukan Load Balancer Jaringan proxy internal baru untuk setiap layanan baru. Anda mungkin memerlukan load balancer yang berbeda, bergantung pada protokol yang diperlukan untuk koneksi.
  • Kuota Load Balancing dibatasi untuk setiap jaringan VPC. Hal ini merupakan pertimbangan penting karena layanan Lapisan 4 memerlukan Load Balancer Jaringan proxy internal baru untuk setiap layanan tujuan.
  • Opsi desain ketersediaan tinggi dan failover lintas region yang dipilih bergantung pada persyaratan Anda.
  • Traffic terenkripsi melintasi batas hybrid memiliki implikasi pada koordinasi pengelolaan sertifikat.

Jika pertimbangan sebelumnya merupakan penyusupan yang dapat dikelola, atau tidak relevan dengan lingkungan Anda, kami merekomendasikan pola ini sebagai opsi yang disarankan.

Diagram berikut menunjukkan hub hybrid Network Connectivity Center sebagai bidang pengelolaan untuk koneksi Cloud Interconnect. Contoh ini juga menunjukkan hub VPC Network Connectivity Center yang menghubungkan spoke VPC aplikasi dan layanan:

VPC aplikasi yang terhubung sebagai spoke ke hub Network Connectivity Center

Load balancing proxy untuk transittivitas

Berikut ini tidak dapat dijangkau di seluruh VPC Network Connectivity Center:

  • Endpoint layanan Private Service Connect dan frontend layanan terkelola.
  • Jaringan di balik koneksi hybrid (Cloud Interconnect atau VPN dengan ketersediaan tinggi (HA)) karena rute dinamis tidak disebarkan melalui Jaringan Lintas Cloud.

Batasan transittivitas ini dapat diatasi dengan men-deploy Load Balancer Jaringan proxy internal dengan resource non-transitif yang ditangani sebagai grup endpoint jaringan hybrid (NEG). Anda dapat men-deploy Load Balancer Jaringan proxy internal di depan frontend layanan dan di depan endpoint yang dapat dijangkau di seluruh koneksi hybrid. Frontend Load Balancer Jaringan proxy internal di-deploy di subnet VPC yang disebarkan di seluruh VPC berbicara Cross-Cloud Network. Load Balancer Jaringan proxy internal memungkinkan keterjangkauan melalui Jaringan Lintas Cloud untuk resource non-transitif. Untuk host dan layanan eksternal, endpoint Private Service Connect, dan jaringan akses layanan pribadi, backend harus dikonfigurasi sebagai NEG hybrid. Backend Private Service Connect adalah satu-satunya model yang NEG tidak perlu berupa hybrid.

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 zona Google 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 layanan pusat, 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 ke administrator project layanan.

Dalam kasus transportasi umum, saat jaringan eksternal berkomunikasi dengan jaringan eksternal lainnya melalui Google Cloud, zona DNS eksternal harus dikonfigurasi untuk meneruskan permintaan satu sama lain secara langsung. Jaringan Cross-Cloud Google akan menyediakan konektivitas untuk permintaan dan balasan DNS agar dapat diselesaikan, tetapi DNS Google Cloud terlibat dalam meneruskan traffic resolusi DNS antar-zona di jaringan eksternal. Setiap aturan firewall yang diterapkan di Jaringan Lintas Cloud harus mengizinkan traffic resolusi DNS antarjaringan eksternal.

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

hub-and-spoke<i}" class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,title,class" src="https://cloud.google.com/static/architecture/images/ccn-distributed-apps-design/ccn-13a.svg" title="Desain DNS yang dapat digunakan dengan pola konektivitas {i>hub-and-spoke<i}" />

Diagram sebelumnya menunjukkan langkah-langkah berikut dalam alur desain:

  1. DNS lokal
    Konfigurasi server DNS lokal agar menjadi otoritatif untuk zona DNS lokal. Konfigurasikan penerusan DNS (untuk nama DNS Google Cloud) 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 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 infrastruktur lokal bersumber dari rentang alamat IP ini.
  3. VPC Transit - Cloud DNS
    1. Konfigurasikan kebijakan server masuk untuk permintaan DNS masuk dari infrastruktur lokal.
    2. Mengonfigurasi zona penerusan Cloud DNS (untuk nama DNS lokal) yang menargetkan server DNS lokal.
  4. VPC Layanan - Cloud DNS
    1. Konfigurasikan zona peering DNS layanan (untuk nama DNS lokal) dengan menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk resource lokal dan layanan melalui VPC hub.
    2. Konfigurasi zona pribadi DNS layanan di project host layanan dan tambahkan layanan VPC Bersama, 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 Host Aplikasi - Cloud DNS
    1. Mengonfigurasi zona peering DNS Aplikasi untuk nama DNS lokal yang menyetel VPC hub sebagai jaringan peer. Resolusi DNS untuk {i>host<i} lokal dilakukan melalui VPC hub.
    2. Konfigurasikan zona pribadi DNS Aplikasi 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 talk.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: