Beberapa Proyek Google Cloud, Satu VPN Hibrid? Putuskan Dulu
VPC Bersama, peering, dan hub konektivitas menjawab pertanyaan kepemilikan yang berbeda. Pilih batas jaringan sebelum men-deploy satu VPN per proyek.
Ketika beberapa proyek Google Cloud membutuhkan akses hibrid, naluri kita adalah satu VPN per proyek, dan itu hampir selalu bentuk yang salah. Kepemilikan proyek dan perutean paket adalah hal yang terkait tetapi berbeda, dan arsitektur yang berguna mempertahankan batas administratif yang Anda butuhkan sambil memberi prefiks yang dimaksud satu jalur yang disengaja ke kantor atau pusat data. Pemeriksaan ini menentukan model jaringan mana yang sebenarnya Anda inginkan, dalam urutan yang menghindari pengerjaan ulang. Masing-masing dapat mengakhiri diskusi lebih awal, dan itulah intinya.
Batas proyek tidak otomatis memerlukan terowongannya sendiri.
Periksa apakah objek bersama itu adalah jaringan
Mulailah dengan pertanyaan tentang kepemilikan, bukan konektivitas: dapatkah kepemilikan jaringan terpusat mendukung beban kerja ini? Jika jawabannya ya dan organisasi memiliki konfigurasi yang memenuhi syarat, proyek host memiliki VPC, subnet, dan konektivitas, sedangkan proyek layanan memiliki sumber daya aplikasinya sendiri. Satu koneksi Cloud VPN di jaringan bersama itu kemudian dapat melayani prefiks beban kerja yang dimaksud, tunduk pada kebijakan perutean dan keamanan .
Tepatlah tentang apa yang dilakukan asosiasi. Melampirkan proyek layanan tidak menggabungkan VPC independennya yang ada ke dalam jaringan host, dan tidak memindahkan setiap sumber daya secara otomatis. Lampiran beban kerja, izin, ruang alamat, dan DNS semuanya bagian dari arsitektur, bukan konsekuensi dari pengaturan. Bacalah asosiasi sebagai perubahan izin terlebih dahulu dan perubahan perutean kedua, karena tim biasanya menemukan perbedaannya saat cutover.
Jika kepemilikan terpusat tidak dapat diterima oleh tim yang terlibat, berhentilah di sini dan perlakukan sisanya sebagai desain peering atau hub. Memaksakan Shared VPC pada grup yang membutuhkan siklus hidup jaringan independen menghasilkan masalah politik dengan nama teknis.
Periksa apakah VPC independen dapat tetap independen
Peering mempertahankan VPC terpisah, dan itulah tepatnya alasan ia menarik tim yang menginginkan rencana alamat sendiri dan kendali perubahan sendiri. Jebakannya adalah peering tidak transitif: peering A-ke-B dan B-ke-C tidak dengan sendirinya menciptakan perutean A-ke-C melalui B. Jika tiga proyek perlu mencapai satu tujuan hibrid, Anda memerlukan rencana pertukaran yang disengaja, bukan rantai peering.
Berbagi keterjangkauan hibrid juga bergantung pada pertukaran rute khusus yang terdokumentasi dan iklan Cloud Router yang dimaksud. Status peering aktif membuktikan bahwa peering itu ada, bukan bahwa prefiks yang dipedulikan setiap sisi pernah diekspor. Periksa rentang yang diekspor di kedua sisi peer, dalam konfigurasi yang melakukan ekspor, dan bandingkan dengan alamat yang benar-benar digunakan beban kerja Anda. Ketidakcocokan di sana adalah alasan paling umum sebuah peering tampak sehat sementara sebuah prefiks tetap tidak terjangkau.
Tulis rencana alamat sebelum hal lain. Rentang yang tidak tumpang tindih, rute menuju setiap tujuan yang dimaksud, dan iklan balik adalah tiga artefak tempat model ini hidup atau mati.
Periksa apakah model hub cocok dengan topologi
Untuk desain yang lebih besar atau tersegmentasi berbeda, ikhtisar Google Network Connectivity Center menjelaskan model hub dan spoke. Bacalah untuk apa yang didukung rilis saat ini, bukan untuk apa yang disiratkan diagram: kombinasi VPC dan hibrid mana, keluarga rute mana, dan kebijakan mana yang diizinkan setiap jenis spoke.
Periksa keluarga alamat secara eksplisit. Contoh perencanaan di sebagian besar panduan, termasuk yang ini, menyangkut IPv4, dan fitur yang ada untuk satu jenis spoke tidak otomatis berlaku tanpa perubahan pada jenis lain. Jika lingkungan Anda tumpukan ganda, pertanyaan itu termasuk dalam pilihan model, bukan migrasi nanti.
Tabel di bawah ini adalah ringkasan ketiga model dan pertanyaan yang menentukan masing-masing.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Periksa apa yang tidak diberikan oleh perutean
Pertukaran rute bukanlah pemberian kepercayaan secara menyeluruh. Resolusi DNS, izin firewall, dan otorisasi aplikasi tetap menjadi tanggung jawab masing-masing, dan masing-masing dikonfigurasi oleh pemilik berbeda di sebagian besar organisasi. Desain yang mengasumsikan keterjangkauan berarti otorisasi akan lulus uji konektivitasnya dan gagal dalam tinjauan keamanannya.
Konfirmasikan juga kisah DNS untuk setiap model, karena pengaturan zona dan penerusan berbeda antara jaringan bersama dan jaringan yang di-peer. Nama privat yang diselesaikan di satu proyek tidak mengikuti rute ke proyek lain.
Catat keputusan dan pemiliknya
Pusatkan di tempat organisasi menginginkan pemilik jaringan bersama; pertahankan VPC terpisah di tempat siklus hidup atau kebijakan mengharuskannya. Lalu pilih hubungan konektivitas yang didukung dan tuliskan mana yang Anda pilih, siapa yang memiliki jaringan bersama, dan apa yang boleh diiklankan setiap proyek.
Menghitung proyek dan membeli satu VPN untuk masing-masing bukan pengganti keputusan kepemilikan itu. Itu adalah keputusan yang sama, diambil kemudian, oleh siapa pun yang mewarisi tagihan dan tabel perutean.