Pluraj Google Cloud-projektoj, unu hibrida VPN? Decidu unue
Komuna VPC, samrangigo kaj konekteca centro respondas malsamajn demandojn pri posedo. Elektu la retan limon antaŭ ol starigi unu VPN por ĉiu projekto.
Kiam pluraj Google Cloud-projektoj bezonas hibridan aliron, la instinkto estas unu VPN por ĉiu projekto, kaj tio preskaŭ ĉiam estas la malĝusta formo. Projektposedo kaj paketa enkursigo estas rilataj sed malsamaj demandoj, kaj la utila arkitekturo konservas la administrajn limojn, kiujn vi bezonas, dum ĝi donas al la celataj prefiksoj unu pripensitan vojon al la oficejo aŭ datencentro. Ĉi tiuj kontroloj decidas, kiun retan modelon vi efektive volas, en la ordo, kiu evitas ripetlaboron. Ĉiu el ili povas fini la diskuton frue, kaj tio estas la senco.
Projekta limo ne aŭtomate postulas propran tunelon.
Kontrolu, ĉu la komuna objekto estas la reto
Komencu per demando pri posedo, ne pri konekteco: ĉu centra retposedo povas subteni ĉi tiujn laborŝarĝojn? Se la respondo estas jes kaj la organizo havas taŭgan agordon, gastiga projekto posedas la VPC, la subretojn kaj la konektecon, dum servaj projektoj posedas siajn aplikaĵajn rimedojn. Unu Cloud VPN-konekto en tiu komuna reto tiam povas servi la celatajn laborŝarĝajn prefiksojn, kondiĉe de enkursigaj kaj sekurecaj politikoj .
Estu preciza pri tio, kion faras la aliĝo. Aldoni servan projekton ne kunfandas ĝian ekzistantan sendependan VPC en la gastigan reton, kaj ĝi ne movas ĉiun rimedon aŭtomate. Laborŝarĝa aliĝo, permesoj, adresspaco kaj DNS estas ĉiuj partoj de la arkitekturo, ne konsekvencoj de la agordo. Legu la aliĝon unue kiel permesan ŝanĝon kaj due kiel enkursigan ŝanĝon, ĉar teamoj kutime malkovras la diferencon dum la transiro.
Se centra posedo ne estas akceptebla por la koncernaj teamoj, haltu ĉi tie kaj traktu la reston kiel samrangigan aŭ centran dezajnon. Trudi Shared VPC al grupo, kiu bezonas sendependajn retajn vivociklojn, produktas politikan problemon kun teknika nomo.
Kontrolu, ĉu sendependaj VPC-oj povas resti sendependaj
Samrangigo konservas apartajn VPC-ojn, kaj ĝuste tial ĝi allogas teamojn, kiuj volas proprajn adresplanojn kaj propran ŝanĝkontrolon. La kaptilo estas, ke samrangigo ne estas transira: samrangigo A-al-B kaj B-al-C ne per si mem kreas enkursigon A-al-C tra B. Se tri projektoj devas atingi unu hibridan celon, vi bezonas pripensitan interŝanĝan planon anstataŭ ĉeno de samrangigoj.
Kundivido de hibrida atingeblo ankaŭ dependas de la dokumentita interŝanĝo de propraj itineroj kaj de la celataj anoncoj de Cloud Router. Stato de samrangigo «aktiva» pruvas, ke la samrangigo ekzistas, ne ke la prefiksoj, kiuj gravas al ĉiu flanko, iam estis eksportitaj. Kontrolu la eksportitajn gamojn ambaŭflanke de la samrangigo, en la agordo, kiu faras la eksporton, kaj komparu ilin kun la adresoj, kiujn viaj laborŝarĝoj efektive uzas. Miskongruo tie estas la plej ofta kialo, kial samrangigo aspektas sana dum prefikso restas neatingebla.
Skribu la adresplanon antaŭ ĉio alia. Ne-overlapantaj gamoj, la itineroj al ĉiu celata celloko kaj la revenaj anoncoj estas la tri artefaktoj, sur kiuj ĉi tiu modelo vivas aŭ mortas.
Kontrolu, ĉu centra modelo taŭgas por la topologio
Por pli granda aŭ alie segmentita dezajno, la superrigardo de Google Network Connectivity Center priskribas la centrajn kaj radiajn modelojn. Legu ĝin por tio, kion subtenas la nuna eldono, ne por tio, kion sugestas la diagramo: kiujn VPC- kaj hibridajn kombinaĵojn, kiujn itinero-familiojn kaj kiujn politikojn ĉiu radia tipo permesas.
Kontrolu la adresan familion eksplicite. Planaj ekzemploj en plej multaj gvidiloj, inkluzive de ĉi tiu, koncernas IPv4, kaj trajto, kiu ekzistas por unu radia tipo, ne aŭtomate aplikiĝas senŝanĝe al alia. Se via medio estas duobla stako, tiu demando apartenas al la elekto de modelo, ne al posta migrado.
La suba tabelo estas la resumo de la tri modeloj kaj la demando, kiu decidas ĉiun.
| 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? |
Kontrolu, kion enkursigo ne donas
Itinera interŝanĝo ne estas ĝenerala dono de konfido. DNS-rezolucio, fajroŝirma permeso kaj aplikaĵa rajtigo restas propraj respondecoj, kaj ĉiun el ili en plej multaj organizoj agordas malsama posedanto. Dezajno, kiu supozas, ke atingeblo implicas rajtigon, pasos sian konektecan teston kaj malsukcesos sian sekurecan revizion.
Konfirmu ankaŭ la DNS-historion por ĉiu modelo, ĉar la zonaj kaj plusendaj aranĝoj diferencas inter komuna reto kaj samrangigitaj retoj. Privataj nomoj, kiuj solviĝas en unu projekto, ne sekvas itinerojn en alian.
Notu la decidon kaj ĝian posedanton
Centralizu tie, kie la organizo volas komunan retposedanton; konservu apartajn VPC-ojn tie, kie vivociklo aŭ politiko tion postulas. Poste elektu subtenatan konektecan rilaton kaj notu, kiun vi elektis, kiu posedas la komunan reton, kaj kion ĉiu projekto rajtas anonci.
Kalkuli projektojn kaj aĉeti unu VPN por ĉiu ne anstataŭas tiun posedan decidon. Ĝi estas la sama decido, farita poste, de tiu, kiu heredas la fakturon kaj la enkursigan tabelon.