Flere Google Cloud-projekter, én hybrid VPN? Beslut først
Delt VPC, peering og et connectivity-hub besvarer forskellige ejerskabsspørgsmål. Vælg netværksgrænsen, før du udruller én VPN pr. projekt.
Når flere Google Cloud-projekter har brug for hybrid adgang, er instinktet én VPN per projekt, og det er næsten altid den forkerte form. Projektets ejerskab og pakkeruting er beslægtede, men forskellige spørgsmål, og den nyttige arkitektur bevarer de administrative grænser, du har brug for, mens den giver de tilsigtede præfikser én bevidst vej til kontoret eller datacenteret. Disse kontroller afgør, hvilken netværksmodel du egentlig vil have, i den rækkefølge, der undgår omarbejde. Hver af dem kan afslutte diskussionen tidligt, og det er meningen.
En projektgrænse kræver ikke automatisk sin egen tunnel.
Kontroller, om det fælles objekt er netværket
Begynd med et spørgsmål om ejerskab, ikke om forbindelse: kan centralt netværksejerskab understøtte disse arbejdsbelastninger? Hvis svaret er ja, og organisationen har en passende konfiguration, ejer et værtprojekt VPC'en, undernettene og forbindelsen, mens serviceprojekter ejer deres egne applikationsressourcer. Én Cloud VPN-forbindelse i det fælles netværk kan derefter betjene de tilsigtede arbejdsbelastningspræfikser, med forbehold for ruting- og sikkerhedspolitikker .
Vær præcis om, hvad tilknytning gør. Tilknytning af et serviceprojekt fletter ikke dets eksisterende uafhængige VPC ind i værtnetværket, og det flytter ikke hver ressource automatisk. Tilknytning af arbejdsbelastninger, tilladelser, adresseområde og DNS er alle en del af arkitekturen, ikke konsekvenser af indstillingen. Læs tilknytningen som en tilladelsesændring først og en rutingændring derefter, fordi teams normalt opdager forskellen under overgangen.
Hvis centralt ejerskab ikke er acceptabelt for de involverede teams, stop her, og behandl resten som et peering- eller hubdesign. At tvinge Shared VPC ned over en gruppe, der har brug for uafhængige netværkslivscyklusser, skaber et politisk problem med et teknisk navn.
Kontroller, om uafhængige VPC'er kan forblive uafhængige
Peering bevarer separate VPC'er, og det er netop derfor, det tiltrækker teams, der vil have deres egne adresseplaner og deres egen ændringskontrol. Haken er, at peering ikke er transitiv: peering A-til-B og B-til-C skaber ikke i sig selv A-til-C-ruting gennem B. Hvis tre projekter skal nå én hybrid destination, har du brug for en bevidst udvekslingsplan i stedet for en kæde af peerings.
Deling af hybrid nåbarhed afhænger også af den dokumenterede udveksling af brugerdefinerede ruter og de tilsigtede Cloud Router-annonceringer. En peeringstatus på aktiv beviser, at peeringen findes, ikke at de præfikser, hver side bekymrer sig om, nogensinde blev eksporteret. Kontroller de eksporterede intervaller på begge sider af peeren, i den konfiguration, der udfører eksporten, og sammenlign dem med de adresser, dine arbejdsbelastninger faktisk bruger. En uoverensstemmelse der er den mest almindelige grund til, at en peering ser sund ud, mens et præfiks forbliver uopnåeligt.
Skriv adresseplanen før alt andet. Ikke-overlappende intervaller, ruterne mod hver tilsigtet destination og returannonceringerne er de tre artefakter, som denne model lever eller dør på.
Kontroller, om en hubmodel passer til topologien
Til et større eller anderledes segmenteret design beskriver Googles oversigt over Network Connectivity Center hub- og spoke-modellerne. Læs den for, hvad den nuværende udgave understøtter, i stedet for hvad diagrammet antyder: hvilke VPC- og hybridkombinationer, hvilke rutefamilier og hvilke politikker hver spoke-type tillader.
Kontroller adressefamilien eksplicit. Planlægningseksempler i de fleste vejledninger, inklusive denne, handler om IPv4, og en funktion, der findes for én spoke-type, gælder ikke automatisk uændret for en anden. Hvis dit miljø er dobbeltstakket, hører det spørgsmål til modelvalget, ikke til en senere migrering.
Tabellen nedenfor er opsummeringen af de tre modeller og det spørgsmål, der afgør hver af 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, hvad ruting ikke giver
Ruteudveksling er ikke en blanket tilladelse til tillid. DNS-opløsning, firewalltilladelse og applikationsgodkendelse forbliver deres egne ansvarsområder, og hver af dem konfigureres af en anden ejer i de fleste organisationer. Et design, der antager, at nåbarhed indebærer godkendelse, vil bestå sin forbindelsestest og dumpe sin sikkerhedsgennemgang.
Bekræft også DNS-historien for hver model, fordi zone- og videresendelsesordningerne er forskellige mellem et fælles netværk og peerede netværk. Private navne, der opløses i ét projekt, følger ikke en rute ind i et andet.
Registrer beslutningen og dens ejer
Centraliser, hvor organisationen ønsker en fælles netværksejer; behold separate VPC'er, hvor livscyklus eller politik kræver det. Vælg derefter et understøttet connectivity-forhold, og skriv ned, hvilket du valgte, hvem der ejer det fælles netværk, og hvad hvert projekt må annoncere.
At tælle projekter og købe én VPN til hver er ikke en erstatning for den ejerskabsbeslutning. Det er den samme beslutning, truffet senere, af den, der arver regningen og rutetabellen.