Beberapa Projek Google Cloud, Satu VPN Hibrid? Tentukan Dahulu
VPC Dikongsi, peering dan hab ketersambungan menjawab soalan pemilikan yang berbeza. Pilih sempadan rangkaian sebelum menggunakan satu VPN bagi setiap projek.
Apabila beberapa projek Google Cloud memerlukan akses hibrid, naluri ialah satu VPN bagi setiap projek, dan ia hampir selalu bentuk yang salah. Pemilikan projek dan penghalaan paket ialah perkara berkaitan tetapi berbeza, dan seni bina yang berguna mengekalkan sempadan pentadbiran yang anda perlukan sambil memberikan awalan yang dimaksudkan satu laluan yang disengajakan ke pejabat atau pusat data. Semakan ini menentukan model rangkaian yang sebenarnya anda mahukan, dalam susunan yang mengelakkan kerja semula. Setiap satu boleh menamatkan perbincangan lebih awal, dan itulah intinya.
Sempadan projek tidak secara automatik memerlukan terowongnya sendiri.
Semak sama ada objek yang dikongsi ialah rangkaian
Mulakan dengan soalan tentang pemilikan, bukan ketersambungan: bolehkah pemilikan rangkaian pusat menyokong beban kerja ini? Jika jawapannya ya dan organisasi mempunyai konfigurasi yang layak, projek hos memiliki VPC, subrangkaian dan ketersambungan, manakala projek perkhidmatan memiliki sumber aplikasi mereka sendiri. Satu sambungan Cloud VPN dalam rangkaian dikongsi itu kemudian boleh melayani awalan beban kerja yang dimaksudkan, tertakluk kepada dasar penghalaan dan keselamatan .
Tepat tentang apa yang dilakukan oleh persekutuan. Melampirkan projek perkhidmatan tidak menggabungkan VPC bebasnya yang sedia ada ke dalam rangkaian hos, dan ia tidak memindahkan setiap sumber secara automatik. Lampiran beban kerja, kebenaran, ruang alamat dan DNS semuanya sebahagian daripada seni bina, bukan akibat tetapan. Baca persekutuan sebagai perubahan kebenaran dahulu dan perubahan penghalaan kedua, kerana pasukan biasanya menemui perbezaannya semasa peralihan.
Jika pemilikan pusat tidak boleh diterima oleh pasukan yang terlibat, berhenti di sini dan anggap selebihnya sebagai reka bentuk peering atau hab. Memaksa Shared VPC ke atas kumpulan yang memerlukan kitaran hayat rangkaian bebas menghasilkan masalah politik dengan nama teknikal.
Semak sama ada VPC bebas boleh kekal bebas
Peering mengekalkan VPC berasingan, dan itulah sebabnya ia menarik pasukan yang mahukan pelan alamat sendiri dan kawalan perubahan sendiri. Perangkapnya ialah peering tidak transitif: peering A-ke-B dan B-ke-C tidak dengan sendirinya mencipta penghalaan A-ke-C melalui B. Jika tiga projek perlu mencapai satu destinasi hibrid, anda memerlukan pelan pertukaran yang disengajakan, bukan rantaian peering.
Perkongsian kebolehsampaian hibrid juga bergantung pada pertukaran laluan tersuai yang didokumenkan dan iklan Cloud Router yang dimaksudkan. Status peering aktif membuktikan peering wujud, bukan bahawa awalan yang penting kepada setiap pihak pernah dieksport. Semak julat yang dieksport pada kedua-dua belah peer, dalam konfigurasi yang melakukan eksport, dan bandingkan dengan alamat yang benar-benar digunakan oleh beban kerja anda. Ketidakpadanan di sana ialah sebab paling biasa sesuatu peering kelihatan sihat sementara awalan kekal tidak dapat dicapai.
Tulis pelan alamat sebelum apa-apa lagi. Julat tidak bertindih, laluan ke setiap destinasi yang dimaksudkan dan iklan balik ialah tiga artifak yang menjadi tempat model ini hidup atau mati.
Semak sama ada model hab sesuai dengan topologi
Untuk reka bentuk yang lebih besar atau bersegmen secara berbeza, gambaran keseluruhan Google Network Connectivity Center menerangkan model hab dan jejari. Bacalah untuk apa yang disokong oleh keluaran semasa, bukan untuk apa yang tersirat oleh rajah: gabungan VPC dan hibrid yang mana, keluarga laluan yang mana dan dasar yang mana dibenarkan oleh setiap jenis jejari.
Semak keluarga alamat secara eksplisit. Contoh perancangan dalam kebanyakan panduan, termasuk yang ini, berkaitan IPv4, dan ciri yang wujud untuk satu jenis jejari tidak secara automatik terpakai tanpa perubahan kepada jenis lain. Jika persekitaran anda ialah tindanan berganda, soalan itu tergolong dalam pilihan model, bukan migrasi kemudian.
Jadual di bawah ialah ringkasan ketiga-tiga model dan soalan yang menentukan setiap satu.
| 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? |
Semak apa yang tidak diberikan oleh penghalaan
Pertukaran laluan bukanlah pemberian kepercayaan secara menyeluruh. Penyelesaian DNS, kebenaran tembok api dan kebenaran aplikasi kekal sebagai tanggungjawab masing-masing, dan setiap satu dikonfigurasikan oleh pemilik berbeza dalam kebanyakan organisasi. Reka bentuk yang menganggap kebolehsampaian bermaksud kebenaran akan lulus ujian ketersambungannya dan gagal dalam semakan keselamatannya.
Sahkan juga kisah DNS untuk setiap model, kerana susunan zon dan pemajuan berbeza antara rangkaian dikongsi dan rangkaian yang di-peer. Nama peribadi yang diselesaikan dalam satu projek tidak mengikut laluan ke projek lain.
Rekod keputusan dan pemiliknya
Pusatkan di tempat organisasi mahukan pemilik rangkaian dikongsi; kekalkan VPC berasingan di tempat kitaran hayat atau dasar memerlukannya. Kemudian pilih hubungan ketersambungan yang disokong dan catat yang mana anda pilih, siapa memiliki rangkaian dikongsi, dan apa yang boleh diiklankan oleh setiap projek.
Mengira projek dan membeli satu VPN untuk setiap satu bukan pengganti keputusan pemilikan itu. Ia adalah keputusan yang sama, diambil kemudian, oleh sesiapa yang mewarisi bil dan jadual penghalaan.