Fleire Google Cloud-prosjekt, éin hybrid VPN? Avgjer først
Delt VPC, peering og eit tilknytingssenter svarar på ulike eigarskapsspørsmål. Vel nettverksgrensa før du rullar ut éin VPN per prosjekt.
Når fleire Google Cloud-prosjekt treng hybrid tilgang, er instinktet éin VPN per prosjekt, og det er nesten alltid feil form. Prosjekteige og pakkeruting er skylde, men ulike spørsmål, og den nyttige arkitekturen held på dei administrative grensene du treng, samstundes som han gjev dei tiltenkte prefiksa éin medviten veg til kontoret eller datasenteret. Desse kontrollane avgjer kva nettverksmodell du eigentleg vil ha, i den rekkjefølgja som unngår omarbeid. Kvar av dei kan avslutte diskusjonen tidleg, og det er poenget.
Ei prosjektgrense krev ikkje automatisk sin eigen tunnel.
Kontroller om det delte objektet er nettverket
Byrja med eit spørsmål om eige, ikkje om tilknyting: kan sentralt nettverkseige støtte desse arbeidslastene? Viss svaret er ja og organisasjonen har ein eigna konfigurasjon, eig eit vertsprosjekt VPC-en, subnetta og tilknytinga, medan tenesteprosjekt eig sine eigne applikasjonsressursar. Éi Cloud VPN-tilknyting i det delte nettverket kan då tene dei tiltenkte arbeidslastprefiksa, med atterhald om ruting- og tryggleikspolicyar .
Ver presis på kva tilknytinga gjer. Tilknyting av eit tenesteprosjekt slår ikkje saman det eksisterande uavhengige VPC-et i vertsnettverket, og det flyttar ikkje kvar ressurs automatisk. Tilknyting av arbeidslaster, løyve, adresseområde og DNS er alle delar av arkitekturen, ikkje konsekvensar av innstillinga. Les tilknytinga som ei løyvesendring først og ei rutingsendring deretter, fordi team oppdagar vanlegvis skilnaden under overgangen.
Viss sentralt eige ikkje er akseptabelt for teama som er involverte, stopp her og handsam resten som eit peering- eller hubsdesign. Å tvinge Shared VPC på ei gruppe som treng uavhengige nettverkslivssyklusar, skapar eit politisk problem med eit teknisk namn.
Kontroller om uavhengige VPC-ar kan halde fram som uavhengige
Peering bevarer separate VPC-ar, og det er nettopp derfor det trekkjer til seg team som vil ha eigne adresseplanar og eigen endringskontroll. Haken er at peering ikkje er transitiv: peering A-til-B og B-til-C skapar ikkje i seg sjølv A-til-C-ruting gjennom B. Viss tre prosjekt må nå éin hybrid destinasjon, treng du ein medviten utvekslingsplan i staden for ei kjede av peerings.
Deling av hybrid nåbarheit avheng òg av den dokumenterte utvekslinga av eigendefinerte ruter og dei tiltenkte Cloud Router-kunngjeringane. Ein peeringstatus på aktiv provar at peeringa finst, ikkje at prefiksa kvar side bryr seg om nokon gong vart eksporterte. Kontroller dei eksporterte områda på begge sider av peeren, i konfigurasjonen som utfører eksporten, og samanlikn dei med adressene arbeidslastene dine faktisk brukar. Eit avvik der er den vanlegaste grunnen til at ei peering ser sunn ut medan eit prefiks blir verande uoppnåeleg.
Skriv adresseplanen før alt anna. Ikkje-overlappande område, rutene mot kvar tiltenkt destinasjon og returkunngjeringane er dei tre artefaktane denne modellen lever eller døyr på.
Kontroller om ein hubmodell passar til topologien
For eit større eller annleis segmentert design skildrar Googles oversikt over Network Connectivity Center hub- og spokemodellane. Les han for kva gjeldande utgåve støttar, ikkje for kva diagrammet antydar: kva VPC- og hybridkombinasjonar, kva rutefamiliar og kva policyar kvar spoketype tillèt.
Kontroller adressefamilien eksplisitt. Planleggingseksempla i dei fleste rettleiingar, òg denne, gjeld IPv4, og ein funksjon som finst for éin spoketype gjeld ikkje automatisk uendra for ein annan. Viss miljøet ditt er dobbeltstakka, høyrer det spørsmålet til modellvalet, ikkje til ein seinare migrasjon.
Tabellen nedanfor er oppsummeringa av dei tre modellane og spørsmålet som avgjer kvar av dei.
| 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? |
Kontroller kva ruting ikkje gjev
Ruteutveksling er ikkje ei generell løyve til tillit. DNS-oppslag, brannmurlogøyve og applikasjonsautorisasjon blir verande eigne ansvarsområde, og kvart av dei blir konfigurert av ein annan eigar i dei fleste organisasjonar. Eit design som legg til grunn at nåbarheit inneber autorisasjon, vil bestå tilknytingstesten og stryke i tryggleiksgjennomgangen.
Stadfest òg DNS-historia for kvar modell, fordi sone- og vidaresendingsordningane er ulike mellom eit delt nettverk og peera nettverk. Private namn som blir løyste i eitt prosjekt, følgjer ikkje ei rute inn i eit anna.
Registrer avgjerda og eigenaren hennar
Sentraliser der organisasjonen ønskjer ein felles nettverkseigar; hald separate VPC-ar der livssyklus eller policy krev det. Vel deretter eit støtta tilknytingsforhold og skriv ned kva du valde, kven som eig det delte nettverket, og kva kvart prosjekt har lov til å annonsere.
Å telje prosjekt og kjøpe éin VPN til kvar er ikkje ei erstatning for den eigarskapsavgjerda. Det er den same avgjerda, teken seinare, av den som arvar rekninga og rutetabellen.