Meerdere Google Cloud-projecten, één hybride VPN? Beslis eerst
Gedeelde VPC, peering en een connectiviteitshub beantwoorden verschillende eigenaarsvragen. Kies de netwerkgrens voordat u één VPN per project uitrolt.
Wanneer meerdere Google Cloud-projecten hybride toegang nodig hebben, is het instinct één VPN per project, en dat is bijna altijd de verkeerde vorm. Projecteigendom en pakketroutering zijn verwante maar verschillende kwesties, en de bruikbare architectuur behoudt de administratieve grenzen die u nodig hebt en geeft de beoogde prefixen één bewuste route naar het kantoor of het datacenter. Deze controles bepalen welk netwerkmodel u werkelijk wilt, in de volgorde die herwerk voorkomt. Elk ervan kan de discussie vroeg beëindigen, en dat is het punt.
Een projectgrens vereist niet automatisch een eigen tunnel.
Controleer of het gedeelde object het netwerk is
Begin met een vraag over eigendom, niet over connectiviteit: kan centraal netwerkeigendom deze workloads ondersteunen? Als het antwoord ja is en de organisatie een geschikte configuratie heeft, bezit een hostproject de VPC, de subnetten en de connectiviteit, terwijl serviceprojecten hun eigen applicatieresources bezitten. Eén Cloud VPN-verbinding in dat gedeelde netwerk kan dan de beoogde workloadprefixen bedienen, onder voorbehoud van routerings- en beveiligingsbeleid .
Wees precies over wat associatie doet. Het koppelen van een serviceproject voegt het bestaande onafhankelijke VPC niet samen met het hostnetwerk, en het verplaatst niet automatisch elke resource. Workloadkoppeling, machtigingen, adresruimte en DNS maken allemaal deel uit van de architectuur, niet van de gevolgen van de instelling. Lees de associatie eerst als een machtigingswijziging en daarna als een routeringswijziging, omdat teams het verschil meestal tijdens de overgang ontdekken.
Als centraal eigendom niet aanvaardbaar is voor de betrokken teams, stop hier en behandel de rest als een peering- of hubontwerp. Shared VPC opdringen aan een groep die onafhankelijke netwerklevencycli nodig heeft, levert een politiek probleem met een technische naam op.
Controleer of onafhankelijke VPC's onafhankelijk kunnen blijven
Peering behoudt afzonderlijke VPC's, en daarom trekt het teams aan die hun eigen adresplannen en hun eigen wijzigingsbeheer willen. De adder is dat peering niet transitief is: peering A-naar-B en B-naar-C creëert op zichzelf geen A-naar-C-routering via B. Als drie projecten één hybride bestemming moeten bereiken, hebt u een bewust uitwisselingsplan nodig in plaats van een keten van peerings.
Het delen van hybride bereikbaarheid hangt ook af van de gedocumenteerde uitwisseling van aangepaste routes en de beoogde Cloud Router-aankondigingen. Een peeringstatus actief bewijst dat de peering bestaat, niet dat de prefixen die elke kant belangrijk vindt ooit zijn geëxporteerd. Controleer de geëxporteerde bereiken aan beide zijden van de peer, in de configuratie die de export uitvoert, en vergelijk ze met de adressen die uw workloads werkelijk gebruiken. Een afwijking daar is de meest voorkomende reden dat een peering gezond lijkt terwijl een prefix onbereikbaar blijft.
Schrijf het adresplan vóór al het andere. Niet-overlappende bereiken, de routes naar elke beoogde bestemming en de retouraankondigingen zijn de drie artefacten waarop dit model leeft of sterft.
Controleer of een hubmodel bij de topologie past
Voor een groter of anders gesegmenteerd ontwerp beschrijft Googles overzicht van Network Connectivity Center de hub- en spokemodellen. Lees het voor wat de huidige release ondersteunt, niet voor wat het diagram suggereert: welke VPC- en hybride combinaties, welke routefamilies en welk beleid elk spoketype toestaat.
Controleer de adresfamilie expliciet. Planningsvoorbeelden in de meeste handleidingen, ook deze, gaan over IPv4, en een functie die voor één spoketype bestaat, geldt niet automatisch ongewijzigd voor een ander. Als uw omgeving dual-stack is, hoort die vraag bij de modelkeuze, niet bij een latere migratie.
De onderstaande tabel is de samenvatting van de drie modellen en de vraag die elk beslist.
| 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? |
Controleer wat routering niet geeft
Route-uitwisseling is geen algemene verlening van vertrouwen. DNS-resolutie, firewallspermissie en applicatieautorisatie blijven hun eigen verantwoordelijkheden, en elk daarvan wordt in de meeste organisaties door een andere eigenaar geconfigureerd. Een ontwerp dat aanneemt dat bereikbaarheid autorisatie impliceert, slaagt voor zijn connectiviteitstest en zakt voor zijn beveiligingsreview.
Bevestig ook het DNS-verhaal voor elk model, omdat de zone- en doorstuurregelingen verschillen tussen een gedeeld netwerk en gepeerde netwerken. Privénamen die in één project worden opgelost, volgen geen route naar een ander.
Leg de beslissing en de eigenaar vast
Centraliseer waar de organisatie een gedeelde netwerkeigenaar wil; houd afzonderlijke VPC's waar levenscyclus of beleid dat vereist. Kies vervolgens een ondersteunde connectiviteitsrelatie en noteer welke u hebt gekozen, wie het gedeelde netwerk bezit en wat elk project mag aankondigen.
Projecten tellen en voor elk één VPN kopen is geen vervanging voor die eigendomsbeslissing. Het is dezelfde beslissing, later genomen, door wie de rekening en de routeringstabel erft.