Vairāki Google Cloud projekti, viens hibrīds VPN? Vispirms izlemiet
Kopīgs VPC, peering un savienojamības centrs atbild uz dažādiem īpašumtiesību jautājumiem. Izvēlieties tīkla robežu pirms izvietojat vienu VPN katram projektam.
Kad vairākiem Google Cloud projektiem nepieciešama hibrīda piekļuve, instinkts ir viens VPN katram projektam, un tas gandrīz vienmēr ir nepareizā forma. Projekta īpašumtiesības un pakešu maršrutēšana ir saistīti, bet atšķirīgi jautājumi, un noderīgā arhitektūra saglabā nepieciešamās administratīvās robežas un vienlaikus dod paredzētajiem prefiksiem vienu apzinātu ceļu uz biroju vai datu centru. Šīs pārbaudes izlemj, kuru tīkla modeli jūs patiešām vēlaties, tādā secībā, kas izvairās no pārstrādes. Katra no tām var agri beigt diskusiju, un tā ir jēga.
Projekta robeža automātiski neprasa savu tuneli.
Pārbaudiet, vai kopīgais objekts ir tīkls
Sāciet ar jautājumu par īpašumtiesībām, nevis savienojamību: vai centrālās tīkla īpašumtiesības var atbalstīt šīs darba slodzes? Ja atbilde ir jā un organizācijai ir piemērota konfigurācija, resursdatora projekts pārvalda VPC, apakštīklus un savienojamību, bet pakalpojumu projekti pārvalda savus lietojumprogrammu resursus. Viens Cloud VPN savienojums šajā kopīgajā tīklā tad var apkalpot paredzētos darba slodzes prefiksus, ievērojot maršrutēšanas un drošības politikas .
Esiet precīzi par to, ko dara asociācija. Pakalpojuma projekta pievienošana neapvieno tā esošo neatkarīgo VPC ar resursdatora tīklu un nepārvieto katru resursu automātiski. Darba slodzes pievienošana, atļaujas, adrešu telpa un DNS ir arhitektūras daļa, nevis iestatījuma sekas. Lasiet asociāciju vispirms kā atļauju maiņu un pēc tam kā maršrutēšanas maiņu, jo komandas parasti atklāj atšķirību pārejas laikā.
Ja centrālās īpašumtiesības iesaistītajām komandām nav pieņemamas, apstājieties šeit un pārējo uzskatiet par peering vai centra dizainu. Shared VPC uzspiešana grupai, kurai nepieciešami neatkarīgi tīkla dzīves cikli, rada politisku problēmu ar tehnisku nosaukumu.
Pārbaudiet, vai neatkarīgi VPC var palikt neatkarīgi
Peering saglabā atsevišķus VPC, un tieši tāpēc tas piesaista komandas, kas vēlas savus adrešu plānus un savu izmaiņu kontroli. Āķis ir tāds, ka peering nav transitīvs: A-uz-B un B-uz-C peering pats par sevi neveido A-uz-C maršrutēšanu caur B. Ja trim projektiem jāsasniedz viens hibrīds galamērķis, jums nepieciešams apzināts apmaiņas plāns, nevis peeringu ķēde.
Hibrīda sasniedzamības koplietošana arī ir atkarīga no dokumentētās pielāgoto maršrutu apmaiņas un paredzētajiem Cloud Router paziņojumiem. Peering statuss aktīvs pierāda, ka peering pastāv, nevis to, ka prefiksi, kas svarīgi katrai pusei, kādreiz tika eksportēti. Pārbaudiet eksportētos diapazonus abās peer pusēs, konfigurācijā, kas veic eksportu, un salīdziniet tos ar adresēm, ko jūsu darba slodzes faktiski izmanto. Neatbilstība tur ir visbiežākais iemesls, kāpēc peering izskatās veselīgs, kamēr prefikss paliek nesasniedzams.
Uzrakstiet adrešu plānu pirms visa cita. Nepārklājošies diapazoni, maršruti uz katru paredzēto galamērķi un atgriešanās paziņojumi ir trīs artefakti, uz kuriem šis modelis dzīvo vai mirst.
Pārbaudiet, vai centra modelis atbilst topoloģijai
Lielākam vai citādi segmentētam dizainam Google Network Connectivity Center pārskats apraksta centra un spieķa modeļus. Lasiet to par to, ko atbalsta pašreizējais laidums, nevis par to, ko liecina diagramma: kuras VPC un hibrīdās kombinācijas, kuras maršrutu saimes un kādas politikas pieļauj katrs spieķa tips.
Skaidri pārbaudiet adrešu saimi. Lielākajā daļā ceļvežu, tostarp šajā, plānošanas piemēri attiecas uz IPv4, un funkcija, kas pastāv vienam spieķa tipam, automātiski neattiecas nemainīta uz citu. Ja jūsu vide ir dubultā steka, šis jautājums pieder pie modeļa izvēles, nevis pie vēlākas migrācijas.
Zemāk esošā tabula ir trīs modeļu kopsavilkums un jautājums, kas izlemj katru.
| 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? |
Pārbaudiet, ko maršrutēšana nedod
Maršrutu apmaiņa nav vispārēja uzticēšanās piešķiršana. DNS izšķiršana, ugunsmūra atļauja un lietojumprogrammas autorizācija paliek paši savā atbildībā, un katru no tām lielākajā daļā organizāciju konfigurē cits īpašnieks. Dizains, kas pieņem, ka sasniedzamība nozīmē autorizāciju, izturēs savienojamības testu un neizturēs drošības pārskatu.
Apstipriniet arī DNS stāstu katram modelim, jo zonas un pārsūtīšanas kārtība atšķiras starp kopīgu tīklu un peer tīkliem. Privātie nosaukumi, kas tiek atrisināti vienā projektā, neseko maršrutam uz citu.
Reģistrējiet lēmumu un tā īpašnieku
Centralizējiet tur, kur organizācija vēlas kopīgu tīkla īpašnieku; saglabājiet atsevišķus VPC tur, kur to prasa dzīves cikls vai politika. Pēc tam izvēlieties atbalstītu savienojamības attiecību un pierakstiet, kuru izvēlējāties, kam pieder kopīgais tīkls un ko katrs projekts drīkst paziņot.
Projektu skaitīšana un viena VPN pirkšana katram neaizstāj šo īpašumtiesību lēmumu. Tas ir tas pats lēmums, pieņemts vēlāk, ko pieņem tas, kurš manto rēķinu un maršrutēšanas tabulu.