Ferskate Google Cloud-projekten, ien hybride VPN? Beslis earst
Dielde VPC, peering en in ferbiningshub beantwurdzje ferskate eigendomsfragen. Kies de netwurkgrins foardat jo ien VPN per projekt útrôlje.
As ferskate Google Cloud-projekten hybride tagong nedich hawwe, is it ynstinkt ien VPN per projekt, en dat is hast altyd de ferkearde foarm. Projekt-eigendom en pakketrouting binne besibbe mar ferskillende kwestjes, en de nuttige arsjitektuer hâldt de bestjoerlike grinzen dy't jo nedich hawwe wylst it de bedoelde prefiksen ien bewuste paad nei it kantoar of datacenter jout. Dizze kontrôles beslisse hokker netwurkmodel jo eins wolle, yn 'e folchoarder dy't werwurk foarkomt. Elk fan harren kin de diskusje betiid einigje, en dat is it punt.
In projektgrins freget net automatysk om syn eigen tunnel.
Kontrolearje oft it dielde objekt it netwurk is
Begjin mei in fraach oer eigendom, net oer ferbining: kin sintraal netwurkeigendom dizze wurklasten stypje? As it antwurd ja is en de organisaasje hat in geskikte konfiguraasje, dan hat in hostprojekt de VPC, subnetten en ferbining, wylst tsjinstprojekten har eigen applikaasjeboarnen hawwe. Ien Cloud VPN-ferbining yn dat dielde netwurk kin dan de bedoelde wurklastprefiksen tsjinje, ûnder foarbehâld fan routing- en befeiligingsbelied .
Wês presys oer wat assosjaasje docht. It taheakjen fan in tsjinstprojekt fusearret syn besteande selsstannige VPC net mei it hostnetwurk, en it ferpleatst net elk boarne automatysk. Wurklasttaheakke, tastimmingen, adresromte en DNS binne allegear diel fan 'e arsjitektuer, net gefolgen fan 'e ynstelling. Lês de assosjaasje earst as in tastimmingsoanpassing en dêrnei as in routingsoanpassing, want teams ûntdekke it ferskil meastentiids by de oergong.
As sintraal eigendom net akseptabel is foar de belutsen teams, stopje hjir en behannelje de rest as in peering- of hubûntwerp. It twingen fan Shared VPC op in groep dy't selsstannige netwurk-libbenssyklussen nedich hat, makket in politikaal probleem mei in technyske namme.
Kontrolearje oft selsstannige VPC's selsstannich bliuwe kinne
Peering behâldt aparte VPC's, en dat is krekt wêrom't it teams lûkt dy't har eigen adresplannen en har eigen feroaringskontrôle wolle. De knipe is dat peering net transityf is: peering A-nei-B en B-nei-C skeppe op himsels gjin A-nei-C-routing fia B. As trije projekten ien hybride bestimming berikke moatte, hawwe jo in bewust útwikselingsplan nedich ynstee fan in keatling peerings.
It dielen fan hybride berikberens hinget ek ôf fan 'e dokumintearre útwikseling fan oanpaste rûtes en de bedoelde Cloud Router-oankundigings. In peeringstatus fan aktyf bewiist dat de peering bestiet, net dat de prefiksen dêr't elke kant om jout ea eksportearre binne. Kontrolearje de eksportearre berikken oan beide kanten fan 'e peer, yn 'e konfiguraasje dy't de eksport docht, en fergelykje se mei de adressen dy't jo wurklasten eins brûke. In mismatch dêre is de meast foarkommende reden dat in peering sûn liket wylst in prefiks ûnberikber bliuwt.
Skriuw it adresplan foar al it oare. Net-oerlaapjende berikken, de rûtes nei elke bedoelde bestimming en de werom-oankundigings binne de trije artefakten dêr't dit model fan libbet of stjert.
Kontrolearje oft in hubmodel by de topology past
Foar in grutter of oars segmintearre ûntwerp beskriuwt Google syn oersjoch fan Network Connectivity Center de hub- en spaakmodellen. Lês it foar wat de hjoeddeiske ferzje stipet, net foar wat it diagram ymplisearret: hokker VPC- en hybride kombinaasjes, hokker rûtefamyljes en hokker belied elk type spaak tasteat.
Kontrolearje de adresfamylje eksplisyt. Planningsfoarbylden yn 'e measte hantliedings, ynklusyf dizze, geane oer IPv4, en in funksje dy't foar ien type spaak bestiet jildt net automatysk ûnferoare foar in oar. As jo omjouwing dûbelstack is, heart dy fraach by de modelkar, net by in lettere migraasje.
De tabel hjirûnder is de gearfetting fan 'e trije modellen en de fraach dy't elk beslút.
| 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? |
Kontrolearje wat routing net jout
Rûte-útwikseling is gjin algemiene jefte fan fertrouwen. DNS-oplossing, firewalltastimming en applikaasje-autorisaasje bliuwe har eigen ferantwurdlikheden, en elk wurdt yn 'e measte organisaasjes troch in oare eigner konfigurearre. In ûntwerp dat oannimt dat berikberens autorisaasje betsjut, sil syn ferbiningstest helje en syn befeiligingsresinsje misse.
Befêstigje ek it DNS-ferhaal foar elk model, want de sône- en trochstjoerregelingen ferskille tusken in dield netwurk en peere netwurken. Priveenammen dy't yn ien projekt oplosse, folgje gjin rûte nei in oar.
Registrearje it beslút en syn eigner
Sintralisearje dêr't de organisaasje in dielde netwurkeigner wol; hâld aparte VPC's dêr't libbenssyklus of belied it freget. Kies dan in stipe ferbiningsrelaasje en skriuw op hokker jo keazen hawwe, wa't it dielde netwurk besit, en wat elk projekt oankundigje mei.
It tellen fan projekten en it keapjen fan ien VPN foar elk is gjin ferfanging foar dat eigendomsbeslút. It is itselde beslút, letter nommen, troch wa't de rekken en de routingtabel erft.