Spoke VPC
Network Connectivity Center menyediakan network connectivity antar-VPC dalam skala besar dengan dukungan untuk spoke VPC. Spoke VPC mengurangi kompleksitas operasional pengelolaan setiap koneksi Peering Jaringan VPC berpasangan melalui penggunaan spoke VPC dan model pengelolaan konektivitas terpusat. Spoke VPC mengekspor dan mengimpor semua rute subnet IPv4 dari VPC spoke lainnya di hub Network Connectivity Center. Hal ini memastikan konektivitas IPv4 penuh antara semua workload yang berada di semua jaringan VPC ini. Traffic jaringan antar-VPC tetap berada dalam jaringan Google Cloud dan tidak berpindah melalui internet, sehingga membantu memastikan privasi dan keamanan.
Spoke VPC dapat berada dalam project dan organisasi yang sama atau dalam project dan organisasi yang berbeda dengan hub Network Connectivity Center. Spoke VPC dapat dihubungkan ke satu hub dalam satu waktu.
Untuk mengetahui informasi tentang cara membuat spoke VPC, lihat Membuat spoke VPC.
Perbandingan dengan Peering Jaringan VPC
Spoke VPC dirancang untuk mendukung persyaratan workload perusahaan sedang hingga besar untuk konektivitas yang dirutekan di antara rentang subnet IPv4 yang terletak di banyak jaringan VPC yang berbeda.
Jaringan VPC dapat berupa spoke VPC Network Connectivity Center dan terhubung ke jaringan VPC lain menggunakan Peering Jaringan VPC. Namun, rute subnet yang diimpor spoke jaringan VPC menggunakan Peering Jaringan VPC tidak dibagikan dengan spoke VPC lain yang terhubung ke hub Network Connectivity Center. Akibatnya, layanan terkelola yang didukung oleh akses layanan Pribadi tidak dapat dijangkau secara transitif secara default menggunakan spoke VPC lain dari suatu hub Network Connectivity Center. Dalam hal ini, Anda dapat membuat layanan terkelola dapat dijangkau dengan menggunakan spoke VPC produsen (Pratinjau).
Fitur | Peering Jaringan VPC | Spoke VPC |
---|---|---|
Jaringan VPC |
Hingga 25 (memerlukan penurunan kuota VPC lainnya). |
Hingga 250 spoke VPC aktif per hub. |
Instance VM |
Network Connectivity Center mendukung hingga maksimum per jaringan VPC (tidak perlu kuota grup peering terpisah). |
|
Rentang subnet (rute subnet) | ||
Rute statis dan dinamis |
500 rute dinamis per hub. Pertukaran rute statis tidak didukung. |
|
Ekspor filter |
Filter tertentu tidak didukung; lihat Opsi pertukaran rute dalam dokumentasi Peering Jaringan VPC. |
Hingga 16 rentang CIDR yang didukung per spoke VPC. |
Alamat IP |
Alamat IP internal, termasuk alamat IP pribadi dan alamat IPv4 publik yang digunakan secara pribadi. Lihat Rentang IPv4 yang valid. |
Alamat IPv4 internal, termasuk alamat IP pribadi dan tidak termasuk alamat IPv4 publik yang digunakan secara pribadi. Lihat Rentang IPv4 yang valid. |
Kelompok alamat IP |
Alamat stack ganda IPv4 dan IPv6/IPv4. |
Hanya alamat IPv4. |
Performa dan throughput (jika dibandingkan dengan mekanisme konektivitas VPC lainnya) |
Latensi terendah, throughput tertinggi (setara dengan VM-VM). |
Latensi terendah, throughput tertinggi (setara dengan VM-VM). |
Spoke VPC di project yang berbeda dengan hub
Dengan menggunakan Network Connectivity Center, Anda dapat melampirkan jaringan VPC, yang ditampilkan sebagai spoke VPC, ke satu hub di project yang berbeda, termasuk project di organisasi yang berbeda. Hal ini memungkinkan Anda menghubungkan jaringan VPC ke beberapa project dan organisasi secara bersamaan dalam skala besar.
Anda dapat menjadi salah satu jenis pengguna berikut:
- Administrator hub yang memiliki hub dalam satu project
- Administrator spoke jaringan VPC atau administrator jaringan yang ingin menambahkan jaringan VPC mereka dalam project yang berbeda sebagai spoke dari hub
Administrator hub mengontrol siapa yang dapat membuat spoke VPC di project berbeda yang terkait dengan hub mereka menggunakan izin Identity and Access Management (IAM). Administrator spoke jaringan VPC membuat spoke di project yang berbeda dengan hub. Spoke ini tidak aktif saat dibuat. Administrator hub harus meninjaunya, dan mereka dapat menerima atau menolak spoke tersebut. Jika administrator hub menerima spoke, maka spoke tersebut akan menjadi aktif.
Network Connectivity Center akan selalu otomatis menerima spoke yang dibuat dalam project yang sama dengan hub.
Untuk mengetahui informasi mendetail tentang cara mengelola hub yang memiliki spoke VPC dalam project yang berbeda dengan hub, lihat Ringkasan administrasi Hub. Untuk mengetahui informasi mendetail tentang administrator spoke, lihat Ringkasan administrasi Spoke.
Konektivitas VPC dengan filter ekspor
Dengan Network Connectivity Center, Anda dapat membatasi konektivitas semua jaringan VPC spoke hanya ke subset dari subnetwork di VPC spoke. Anda dapat membatasi konektivitas dengan menentukan rentang alamat IP agar tidak diiklankan dan dengan membuat daftar rentang CIDR yang dapat diiklankan dari jaringan VPC. Anda juga dapat membatasi konektivitas dengan menentukan daftar rentang CIDR yang diizinkan, sehingga memblokir semua kecuali rentang yang diizinkan.
Mengecualikan rentang ekspor
Anda dapat mempertahankan rentang alamat IP agar tidak diberitahukan
menggunakan flag --exclude-export-ranges
di Google Cloud CLI atau
kolom excludeExportRanges
di API. Setiap subnetwork yang cocok dengan
rentang yang ditentukan tidak akan ikut diekspor ke hub. Pemfilteran ini
berguna saat Anda memiliki subnet yang harus bersifat pribadi dalam
jaringan VPC, atau yang mungkin tumpang tindih dengan subnet lain dalam
tabel rute hub.
Menyertakan rentang ekspor
Anda dapat membuat daftar rentang CIDR yang diizinkan untuk diiklankan
dari spoke VPC menggunakan flag include-export-ranges
atau kolom includeExportRanges
di API. Konektivitas yang lebih akurat
akan dibuat saat Anda menggunakannya bersama rentang alamat IP filter ekspor
yang dikecualikan. Pemfilteran ini menentukan apakah rentang subnet tertentu dapat
diiklankan dari jaringan VPC.
Pertimbangan
Pertimbangkan hal berikut saat menggunakan filter rentang ekspor yang dikecualikan dan disertakan:
Rentang yang disertakan harus eksklusif satu sama lain, yang berarti bahwa rentang yang disertakan tidak boleh tumpang-tindih. Misalnya, ada tiga rentang alamat IP:
Range 1
:10.100.64.0/18
Range 2
:10.100.250.0/21
Range 3
:10.100.100.0/22
Range 1
danrange 2
adalah rentang yang valid karena keduanya tidak tumpang-tindih. Namun,range 3
berada di bawahrange 1
, yang dapat menyebabkan tumpang-tindih, sehinggarange 3
tidak valid.Karena Network Connectivity Center sudah memiliki filter ekspor pengecualian yang tersedia di kebijakan konfigurasi jaringan, filter ekspor sertakan dan kecualikan akan memengaruhi rentang CIDR konfigurasi jaringan yang valid. Saat filter ekspor sertakan dan kecualikan digunakan, rentang alamat IP yang disertakan harus merupakan superset dari rentang alamat IP yang dikecualikan.
Secara default, semua kebijakan konektivitas VPC memiliki rentang CIDR yang disertakan
0.0.0.0/0
, yang berarti bahwa jika Anda tidak menentukan filter yang disertakan saat membuat spoke VPC, Network Connectivity Center akan menetapkan rentang yang disertakan default ke semua alamat IPv4 pribadi yang valid seperti yang ditentukan dalam Rentang IPv4 yang valid.Untuk menyaring rentang penyertaan, Anda dapat menambahkan beberapa rentang pengecualian. Misalnya, jika Anda menentukan
10.1.0.0/16
sebagai rentang penyertaan dan10.1.100.0/24
serta10.1.200.0/24
sebagai rentang pengecualian, hasilnya adalah konektivitas yang ditingkatkan dengan kombinasi filter penyertaan dan pengecualian. Rentang ini mencakup semuanya mulai dari10.1.0.0/24
hingga10.1.99.0/24
,10.1.101.0/24
hingga10.1.199.0/24
, dan10.1.201.0/24
hingga10.1.255.0/24
.Rentang subnet yang ada akan terus berfungsi seperti yang diharapkan. Tumpang-tindih dengan rentang yang disertakan dan dikecualikan saat membuat rentang subnet baru akan menyebabkan error.
Contoh rentang subnet baru yang tidak valid
Contoh berikut menunjukkan rentang subnet yang tidak valid:
Tumpang-tindih dengan rentang pengecualian: Misalkan ada rentang alamat IP berikut.
Sertakan rentang:
10.0.0.0/8
Exclude range 4
:10.1.1.0/24
Subnet range 4
:10.1.0.0/16
Dalam hal ini, rentang yang disertakan berisi
subnet range 4
. Namun, ini adalah superset dariexclude range 4
. Oleh karena itu,subnet range 4
tidak valid.Tumpang-tindih dengan rentang yang disertakan: Misalkan ada rentang alamat IP berikut.
Sertakan rentang:
10.1.1.0/24
Subnet range 5
:10.1.0.0/16
Subnet range 5
tumpang-tindih dengan rentang yang disertakan, sehingga tidak valid.
Saat memasukkan rentang subnet yang tidak valid selama proses pembuatan subnet, Anda akan
mendapatkan error Invalid IPCiderRange
, mirip dengan berikut:
Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION
Topologi preset
Dengan Network Connectivity Center, Anda dapat menentukan konfigurasi konektivitas yang diinginkan di semua spoke VPC. Anda dapat memilih salah satu dari dua topologi preset berikut:
- Topologi mesh
- Topologi bintang
Saat Anda membuat hub menggunakan
perintah gcloud network-connectivity hubs create
,
pilih topologi mesh atau bintang preset. Jika tidak ditentukan, topologi akan
ditetapkan secara default ke mesh. Setelah ditetapkan selama pembuatan hub, Anda tidak dapat mengubah topologi
hub tertentu.
Untuk mengubah setelan topologi spoke, Anda dapat menghapus spoke dan membuat spoke baru dengan hub baru yang menggunakan topologi yang berbeda.
Topologi mesh
Topologi mesh menyediakan konektivitas jaringan skala tinggi antara
spoke VPC.
Topologi ini memungkinkan semua spoke terhubung dan berkomunikasi satu sama lain. Subnet dalam spoke VPC ini dapat dijangkau sepenuhnya kecuali jika Anda menentukan exclude export filters
.
Secara default, saat dua atau beberapa jaringan VPC workload
dikonfigurasi untuk bergabung ke hub Network Connectivity Center sebagai spoke,
Network Connectivity Center akan otomatis membuat mesh konektivitas penuh di antara
setiap spoke.
Semua spoke dalam topologi mesh termasuk dalam satu grup default. Topologi mesh didukung di VPC dan jenis spoke hybrid.
Diagram berikut menunjukkan konektivitas topologi mesh di Network Connectivity Center.
Topologi bintang
Topologi bintang hanya didukung dengan spoke VPC. Saat Anda menggunakan topologi bintang untuk konektivitas, spoke edge dan subnet terkaitnya hanya menjangkau spoke center yang ditetapkan, sedangkan spoke center dapat menjangkau semua spoke lainnya. Hal ini membantu memastikan pemisahan segmentasi dan konektivitas di seluruh jaringan VPC tepi.
Karena spoke VPC dapat dilampirkan ke hub di project yang berbeda, spoke VPC dapat berasal dari domain administratif yang berbeda. Spoke ini yang berada dalam project yang berbeda dengan hub mungkin tidak perlu berkomunikasi dengan setiap spoke lain di hub Network Connectivity Center.
Anda dapat memilih topologi bintang untuk kasus penggunaan berikut:
Beban kerja yang berjalan di berbagai jaringan VPC yang tidak memerlukan konektivitas satu sama lain, tetapi hanya memerlukan akses ke jaringan VPC melalui jaringan VPC layanan bersama pusat.
Kontrol keamanan atas komunikasi di beberapa jaringan VPC yang mengharuskan traffic melewati serangkaian peralatan virtual jaringan (NVA) terpusat.
Diagram berikut menunjukkan konektivitas topologi bintang di Network Connectivity Center.
center-vpc-a
dan center-vpc-b
dikaitkan dengan grup tengah, dan
edge-vpc-c
dan edge-vpc-d
dikaitkan dengan grup tepi. Dalam hal ini,
menggunakan topologi bintang memungkinkan edge-vpc-c
dan edge-vpc-d
terhubung ke center-vpc-a
dan center-vpc-b
serta menyebarkan subnetnya ke
grup tengah, tetapi tidak terhubung satu sama lain (tidak ada keterjangkauan langsung
antara edge-vpc-c
dan edge-vpc-d
). Sementara itu, center-vpc-a
dan center-vpc-b
terhubung satu sama lain dan ke edge-vpc-c
dan
edge-vpc-d
, sehingga memungkinkan keterjangkauan penuh dari VPC grup tengah
ke VPC grup tepi.
Grup spoke
Grup jari-jari adalah subkumpulan jari-jari yang terpasang ke hub. Untuk mengonfigurasi Network Connectivity Center menggunakan topologi bintang, Anda harus memisahkan semua spoke VPC menjadi dua grup yang berbeda, yang juga disebut sebagai domain perutean:
- Grup spoke pusat, yang berkomunikasi dengan setiap spoke lain yang terhubung ke hub
- Grup spoke edge, yang hanya berkomunikasi dengan spoke yang termasuk dalam grup tengah
Spoke VPC hanya dapat menjadi bagian dari satu grup dalam satu waktu. Grup dibuat secara otomatis saat Anda membuat hub.
Administrator hub dapat memperbarui grup spoke menggunakan
perintah gcloud network-connectivity hubs groups update
. Administrator hub dapat menambahkan daftar project ID atau
nomor project untuk mengaktifkan setujui otomatis untuk spoke. Jika terima otomatis
diaktifkan, spoke dari project terima otomatis akan otomatis terhubung ke
hub tanpa perlu peninjauan proposal spoke satu per satu.
Anda dapat mencantumkan grup center dan edge sebagai resource bertingkat untuk
hub tertentu menggunakan
perintah gcloud network-connectivity hubs groups list --hub
.
Untuk hub yang dibuat dengan topologi mesh, output akan menampilkan grup default.
Untuk hub yang dibuat dengan topologi bintang, output akan menampilkan grup pusat dan tepi.
Untuk informasi mendetail tentang cara mengonfigurasi topologi mesh atau bintang untuk spoke VPC, lihat Mengonfigurasi hub.
Batasan
Bagian ini menjelaskan batasan spoke VPC secara umum dan kapan spoke dipasang ke hub dalam project yang berbeda. Batasan ini juga berlaku untuk spoke VPC produsen (Pratinjau).
Batasan-batasan spoke VPC
- Jaringan VPC dapat terhubung satu sama lain secara eksklusif melalui hub Network Connectivity Center atau melalui Peering Jaringan VPC.
- Anda tidak dapat menggunakan Peering Jaringan VPC di antara dua spoke VPC
yang terhubung ke hub Network Connectivity Center yang sama. Namun, pertimbangkan
hal berikut:
- Spoke VPC produsen memerlukan koneksi peering ke spoke VPC di hub yang sama. Konektivitas melalui Network Connectivity Center tidak dibuat antara spoke VPC produsen dan spoke VPC yang di-peering.
- Anda dapat memiliki spoke VPC yang terhubung ke Network Connectivity Center yang di-peering melalui Peering Jaringan VPC dengan VPC terpisah yang bukan bagian dari Network Connectivity Center.
- Beberapa VPC yang dihubungkan antara satu sama lain menggunakan Network Connectivity Center dan Peering Jaringan VPC dengan kombinasi apa pun tidak bersifat transitif.
- Pertukaran rute statis IPv4 di seluruh spoke VPC tidak didukung.
- Rute yang mengarah ke alamat IP virtual Load Balancer Jaringan passthrough internal di spoke VPC lain tidak didukung.
- Subnet yang tumpang-tindih harus disamarkan dengan filter ekspor yang dikecualikan.
- Update
export range filters
setelah pembuatan spoke VPC tidak didukung. - Untuk spoke di project yang berbeda dengan hub, saat perimeter Kontrol Layanan VPC baru ditambahkan, Anda tidak dapat menambahkan spoke baru yang melanggar perimeter tersebut, tetapi spoke yang sudah ada akan tetap berfungsi.
- Konektivitas topologi bintang tidak mendukung spoke hybrid atau pertukaran rute dinamis.
Persyaratan periode tunggu setelah menghapus spoke VPC
Untuk spoke baru untuk jaringan VPC yang sama yang terpasang ke hub berbeda, Anda harus menunggu periode tunggu setidaknya 10 menit. Jika periode tunggu yang memadai tidak diizinkan, konfigurasi baru mungkin tidak akan diterapkan. Periode tunggu ini tidak diperlukan jika jaringan VPC ditambahkan sebagai spoke ke hub yang sama.
Kuota dan batas
Untuk informasi kuota mendetail, lihat Kuota dan batas.
Penagihan
Jam kerja spoke
Jam kerja spoke dikenakan biaya bagi project tempat resource spoke berada dan
mengikuti harga jam kerja spoke standar. Jam kerja spoke hanya akan dikenakan biaya saat
spoke dalam keadaan ACTIVE
.
Traffic keluar
Traffic keluar dikenakan biaya bagi project resource spoke tempat traffic berasal. Harganya sama terlepas dari apakah traffic melintasi batas project atau tidak.
Perjanjian tingkat layanan
Untuk mengetahui informasi tentang perjanjian tingkat layanan Network Connectivity Center, lihat Perjanjian Tingkat Layanan (SLA) Network Connectivity Center.
Harga
Untuk mengetahui informasi tentang harga, lihat Harga Network Connectivity Center.
Langkah selanjutnya
- Untuk membuat hub dan spoke, lihat Bekerja dengan hub dan spoke.
- Untuk melihat daftar partner yang solusinya terintegrasi dengan Network Connectivity Center, lihat Partner Network Connectivity Center.
- Untuk menemukan solusi atas masalah umum, lihat Pemecahan masalah.
- Untuk mendapatkan detail tentang API dan perintah
gcloud
, lihat API dan referensi.