Flere Google Cloud-prosjekter, én hybrid VPN? Bestem først
Delt VPC, peering og et tilkoblingssenter svarer på ulike eierskapsspørsmål. Velg nettverksgrensen før du distribuerer én VPN per prosjekt.
Når flere Google Cloud-prosjekter trenger hybrid tilgang, er instinktet én VPN per prosjekt, og det er nesten alltid feil form. Prosjekteierskap og pakkeruting er beslektede, men forskjellige spørsmål, og den nyttige arkitekturen beholder de administrative grensene du trenger, samtidig som den gir de tiltenkte prefiksene én bevisst vei til kontoret eller datasenteret. Disse kontrollene avgjør hvilken nettverksmodell du egentlig vil ha, i den rekkefølgen som unngår omarbeid. Hver av dem kan avslutte diskusjonen tidlig, og det er poenget.
En prosjektgrense krever ikke automatisk sin egen tunnel.
Kontroller om det delte objektet er nettverket
Begynn med et spørsmål om eierskap, ikke om tilkobling: kan sentralt nettverkseierskap støtte disse arbeidsbelastningene? Hvis svaret er ja og organisasjonen har en egnet konfigurasjon, eier et vertsprosjekt VPC-en, subnettene og tilkoblingen, mens tjenesteprosjekter eier sine egne applikasjonsressurser. Én Cloud VPN-tilkobling i det delte nettverket kan deretter betjene de tiltenkte arbeidsbelastningsprefiksene, med forbehold om ruting- og sikkerhetspolicyer .
Vær presis på hva tilknytningen gjør. Tilknytning av et tjenesteprosjekt slår ikke sammen dets eksisterende uavhengige VPC i vertsnettverket, og det flytter ikke hver ressurs automatisk. Tilknytning av arbeidsbelastninger, tillatelser, adresseområde og DNS er alle en del av arkitekturen, ikke konsekvenser av innstillingen. Les tilknytningen som en tillatelsesendring først og en rutingendring deretter, fordi team vanligvis oppdager forskjellen under overgangen.
Hvis sentralt eierskap ikke er akseptabelt for teamene som er involvert, stopp her og behandle resten som et peering- eller hubsdesign. Å tvinge Shared VPC på en gruppe som trenger uavhengige nettverkslivssykluser, skaper et politisk problem med et teknisk navn.
Kontroller om uavhengige VPC-er kan forbli uavhengige
Peering bevarer separate VPC-er, og det er nettopp derfor det tiltrekker team som vil ha egne adresseplaner og egen endringskontroll. Haken er at peering ikke er transitiv: peering A-til-B og B-til-C skaper ikke i seg selv A-til-C-ruting gjennom B. Hvis tre prosjekter må nå én hybrid destinasjon, trenger du en bevisst utvekslingsplan i stedet for en kjede av peerings.
Deling av hybrid nåbarhet avhenger også av den dokumenterte utvekslingen av egendefinerte ruter og de tiltenkte Cloud Router-kunngjøringene. En peeringstatus på aktiv beviser at peeringen finnes, ikke at prefiksene hver side bryr seg om noen gang ble eksportert. Kontroller de eksporterte områdene på begge sider av peeren, i konfigurasjonen som utfører eksporten, og sammenlign dem med adressene arbeidsbelastningene dine faktisk bruker. Et avvik der er den vanligste grunnen til at en peering ser sunn ut mens et prefiks forblir uoppnåelig.
Skriv adresseplanen før alt annet. Ikke-overlappende områder, rutene mot hver tiltenkt destinasjon og returkunngjøringene er de tre artefaktene denne modellen lever eller dør på.
Kontroller om en hubmodell passer til topologien
For et større eller annerledes segmentert design beskriver Googles oversikt over Network Connectivity Center hub- og spokemodellene. Les den for hva gjeldende utgivelse støtter, ikke for hva diagrammet antyder: hvilke VPC- og hybridkombinasjoner, hvilke rutefamilier og hvilke policyer hver spoketype tillater.
Kontroller adressefamilien eksplisitt. Planleggingseksemplene i de fleste veiledninger, inkludert denne, gjelder IPv4, og en funksjon som finnes for én spoketype gjelder ikke automatisk uendret for en annen. Hvis miljøet ditt er dobbeltstakket, hører det spørsmålet til modellvalget, ikke til en senere migrering.
Tabellen nedenfor er oppsummeringen av de tre modellene og spørsmålet som avgjør hver av dem.
| 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 hva ruting ikke gir
Ruteutveksling er ikke en generell tillatelse til tillit. DNS-oppslag, brannmurstillatelse og applikasjonsautorisasjon forblir egne ansvarsområder, og hver av dem konfigureres av en annen eier i de fleste organisasjoner. Et design som antar at nåbarhet innebærer autorisasjon, vil bestå tilkoblingstesten og stryke i sikkerhetsgjennomgangen.
Bekreft også DNS-historien for hver modell, fordi sone- og videresendingsordningene er forskjellige mellom et delt nettverk og peer-de nettverkene. Private navn som løses i ett prosjekt, følger ikke en rute inn i et annet.
Registrer beslutningen og dens eier
Sentraliser der organisasjonen ønsker en felles nettverkseier; behold separate VPC-er der livssyklus eller policy krever det. Velg deretter et støttet tilkoblingsforhold og skriv ned hvilket du valgte, hvem som eier det delte nettverket, og hva hvert prosjekt har lov til å annonsere.
Å telle prosjekter og kjøpe én VPN til hver er ikke en erstatning for den eierskapsbeslutningen. Det er den samme beslutningen, tatt senere, av den som arver regningen og rutetabellen.