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

Last reviewed 2024-04-05 UTC

Dokumen ini adalah bagian dari seri panduan desain untuk Jaringan Lintas Cloud.

Rangkaian ini terdiri dari bagian berikut:

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 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 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 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 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 zona landing Google Cloud Anda. 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.
  • VPC transit, tempat semua konektivitas eksternal ditangani.
  • VPC layanan opsional, 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.

Struktur VPC yang direkomendasikan

Project host infrastruktur gabungan

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 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 menampilkan 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 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 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 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 workload, terutama konektivitas keluar

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

Untuk modularitas, kemampuan 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):

VPC Transit yang digunakan sebagai layanan konektivitas bersama untuk VPC lain

Koneksi pribadi ke penyedia cloud lainnya

Jika Anda memiliki layanan yang berjalan di jaringan penyedia layanan cloud (CSP) lain yang ingin 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 di 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, 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 yang digunakan 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:

Koneksi ke jaringan lokal

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:

  • Jaringan VPC Google Cloud 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 perutean ini bergantung pada mode pemilihan rute dinamis yang dikonfigurasi untuk 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 untuk mengetahui detailnya.

Pemilihan rute antar-domain region tunggal

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:

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 yang berbeda.

Koneksi Cloud Interconnect di beberapa region

Selain ketahanan, desain perutean multi-region 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 pemilihan rute cold-potato di satu domain dengan pemilihan rute hot-potato di domain peer. Untuk domain cold-potato, sebaiknya gunakan domain jaringan Google 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).

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

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 status.

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:

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 opsi bawaan Google Cloud, seperti yang dijelaskan dalam Membuat 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 terkelola 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 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 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.

Struktur umum Cross-Cloud Network

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

Untuk performa yang lebih baik dan layanan jaringan cloud bawaan, sebaiknya hubungkan 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. Sebaiknya gunakan 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 overhead operasional yang meningkat, desain layanan terpusat akan mengurangi cakupan deployment VPN dengan ketersediaan tinggi (HA).

Atau, Anda dapat menerapkan konektivitas transitive 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 akses layanan bersama

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

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

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 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:

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

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

VPC layanan pusat yang terhubung ke VPC transit dengan VPN 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 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 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 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.

Konektivitas dengan spoke VPC Network Connectivity Center menggunakan load balancing

Pola ini mencakup semua VPC sebagai spoke di hub Network Connectivity Center, dan dapat mengakomodasi hingga 250 VPC yang saling terhubung. Hub Network Connectivity Center adalah konstruksi platform pengelolaan yang membuat konektivitas platform data mesh penuh di antara jaringan VPC yang terdaftar sebagai spoke ke hub Network Connectivity Center. Pola ini menyediakan konektivitas any-to-any dan memungkinkan deployment titik akses ke layanan terkelola di VPC mana pun.

Untuk mengatasi batasan transitivitas, titik akses ke layanan terkelola dan koneksi hybrid diakses melalui Load Balancer Jaringan proxy internal. Keamanan beban kerja untuk koneksi east-west dapat menggunakan Cloud Next Generation Firewall. Anda juga dapat menggunakan Inter-VPC NAT dengan pola ini.

Pola ini memiliki beberapa batasan, sehingga hal berikut harus dipertimbangkan sebelum mengadaptasi pola ini:

  • Anda tidak dapat menggunakan NVA untuk firewall 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 berjalan melalui Load Balancer Jaringan proxy internal.
  • Layanan yang dipublikasikan akan memiliki frontend tambahan di load balancer proxy. Frontend tambahan ini akan menyebarkan 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 wilayah yang dipilih bergantung pada persyaratan Anda.
  • Traffic terenkripsi di seluruh batas hybrid memiliki implikasi pada koordinasi pengelolaan sertifikat.

Jika pertimbangan sebelumnya merupakan kompromi yang dapat dikelola, atau tidak relevan dengan lingkungan Anda, sebaiknya gunakan pola ini sebagai opsi yang lebih disukai.

Diagram berikut menunjukkan hub hybrid Network Connectivity Center sebagai platform manajemen untuk koneksi Cloud Interconnect. Diagram 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 transitivitas

Hal berikut tidak dapat dijangkau di seluruh spoke 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 transitivitas ini dapat diatasi dengan men-deploy Load Balancer Jaringan proxy internal dengan resource non-transitif yang ditangani sebagai grup endpoint jaringan (NEG) hibrida. Anda dapat men-deploy Load Balancer Jaringan proxy internal di depan frontend layanan dan di depan endpoint yang dapat dijangkau di seluruh koneksi hibrida. Frontend Load Balancer Jaringan proxy internal di-deploy di subnet VPC yang di-propagate di seluruh VPC spoke Cross-Cloud Network. Load Balancer Jaringan proxy internal memungkinkan keterjangkauan melalui Jaringan Lintas Cloud dari resource non-transitif. Untuk host dan layanan eksternal, endpoint Private Service Connect, dan jaringan akses layanan pribadi, backend harus dikonfigurasi sebagai NEG campuran. Backend Private Service Connect adalah satu-satunya model yang NEG-nya tidak perlu bersifat campuran.

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 admin 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 balasan 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:

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. 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.
  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. VPC Transit - Cloud DNS
    1. Konfigurasikan kebijakan server masuk untuk permintaan DNS masuk dari lokal.
    2. Konfigurasikan 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) yang menetapkan VPC hub sebagai jaringan peer. Resolusi DNS untuk resource lokal dan layanan akan melalui VPC hub.
    2. Konfigurasikan zona pribadi DNS layanan di project host layanan dan lampirkan VPC Bersama layanan, VPC Bersama aplikasi, dan VPC hub ke zona tersebut. Hal ini memungkinkan semua host (di lokal dan di semua project layanan) me-resolve nama DNS layanan.
  5. Project Host Aplikasi - Cloud DNS
    1. 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.
    2. 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 selanjutnya

Kontributor

Penulis:

Kontributor lainnya: