Mitu Google Cloudi projekti, üks hübriidne VPN? Otsustage kõigepealt
Jagatud VPC, peering ja ühenduvuskeskus vastavad erinevatele omandi küsimustele. Valige võrgu piir enne, kui juurutate ühe VPN-i iga projekti kohta.
Kui mitmel Google Cloudi projektil on vaja hübriidjuurdepääsu, on instinkt üks VPN iga projekti kohta ja see on peaaegu alati vale kuju. Projekti omand ja pakettide marsruutimine on seotud, kuid erinevad küsimused, ning kasulik arhitektuur hoiab alles vajalikud halduspiirid, andes samal ajal kavandatud prefiksitele ühe teadliku tee kontorisse või andmekeskusesse. Need kontrollid otsustavad, millist võrgumudelit te tegelikult soovite, sellises järjekorras, mis väldib ümbertegemist. Igaüks neist võib arutelu varakult lõpetada, ja selles ongi mõte.
Projekti piir ei nõua automaatselt oma tunnelit.
Kontrollige, kas jagatud objekt on võrk
Alustage küsimusest omandi, mitte ühenduvuse kohta: kas tsentraalne võrguomand suudab neid töökoormusi toetada? Kui vastus on jah ja organisatsioonil on sobiv konfiguratsioon, omab hostprojekt VPC-d, alamvõrke ja ühenduvust, samal ajal kui teenuseprojektid omavad oma rakenduste ressursse. Üks Cloud VPN-i ühendus selles jagatud võrgus saab siis teenindada kavandatud töökoormuse prefikseid, järgides marsruutimis- ja turbepoliitikat .
Olge täpne selle suhtes, mida assotsiatsioon teeb. Teenuseprojekti kinnitamine ei ühenda selle olemasolevat sõltumatut VPC-d hostvõrguga ega liiguta automaatselt iga ressurssi. Töökoormuse kinnitamine, load, aadressiruum ja DNS on kõik arhitektuuri osa, mitte seade tagajärjed. Lugege assotsiatsiooni kõigepealt õiguste muudatusena ja seejärel marsruutimise muudatusena, sest meeskonnad avastavad erinevuse tavaliselt ülemineku ajal.
Kui tsentraalne omand ei ole asjassepuutuvatele meeskondadele vastuvõetav, peatuge siin ja käsitlege ülejäänut peeringu või keskuse disainina. Shared VPC sundimine grupile, kes vajab sõltumatuid võrgu elutsükleid, tekitab tehnilise nimega poliitilise probleemi.
Kontrollige, kas sõltumatud VPC-d saavad sõltumatuteks jääda
Peering säilitab eraldi VPC-d ja just seetõttu meelitab see meeskondi, kes soovivad oma aadressiplaane ja oma muudatuste kontrolli. Konks on selles, et peering ei ole transitiivne: peering A-st B-sse ja B-st C-sse ei loo iseenesest marsruutimist A-st C-sse läbi B. Kui kolm projekti peavad jõudma ühte hübriidsesse sihtkohta, vajate teadlikku vahetusplaani, mitte peeringute ahelat.
Hübriidse kättesaadavuse jagamine sõltub ka dokumenteeritud kohandatud marsruutide vahetusest ja kavandatud Cloud Routeri teadaannetest. Peeringu olek „aktiivne“ tõestab, et peering on olemas, mitte seda, et prefiksid, mis kummagi poole jaoks olulised on, on kunagi eksporditud. Kontrollige eksporditud vahemikke peeri mõlemal poolel, konfiguratsioonis, mis ekspordi teeb, ja võrrelge neid aadressidega, mida teie töökoormused tegelikult kasutavad. Sealne lahknevus on kõige tavalisem põhjus, miks peering näib terve, samal ajal kui prefiks jääb kättesaamatuks.
Kirjutage aadressiplaan enne kõike muud. Mittekattuvad vahemikud, marsruudid iga kavandatud sihtkoha suunas ja tagasiteadaanded on kolm artefakti, millel see mudel elab või sureb.
Kontrollige, kas keskusemudel sobib topoloogiaga
Suurema või teisiti segmenteeritud disaini jaoks kirjeldab Google'i Network Connectivity Centeri ülevaade keskuse ja kodara mudeleid. Lugege seda selle kohta, mida praegune väljaanne toetab, mitte selle kohta, mida diagramm vihjab: milliseid VPC ja hübriidseid kombinatsioone, milliseid marsruudiperekondi ja milliseid poliitikaid iga kodara tüüp lubab.
Kontrollige aadressiperekonda selgesõnaliselt. Enamiku juhendite, sealhulgas selle, planeerimisnäited puudutavad IPv4-t, ja ühe kodara tüübi jaoks olemasolev funktsioon ei kehti automaatselt muutmata kujul teisele. Kui teie keskkond on kahekordse virnaga, kuulub see küsimus mudeli valiku juurde, mitte hilisema migratsiooni juurde.
Allolev tabel on kolme mudeli kokkuvõte ja küsimus, mis igaühe otsustab.
| 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? |
Kontrollige, mida marsruutimine ei anna
Marsruutide vahetamine ei ole üldine usalduse andmine. DNS-i lahendamine, tulemüüri luba ja rakenduse autoriseerimine jäävad nende endi vastutuseks ning enamikus organisatsioonides konfigureerib igaüht erinev omanik. Disain, mis eeldab, et kättesaadavus tähendab autoriseerimist, läbib oma ühenduvustesti ja ebaõnnestub turbekontrollis.
Kinnitage ka DNS-i lugu iga mudeli puhul, sest tsooni- ja edastusseaded erinevad jagatud võrgu ja peeritud võrkude vahel. Privaatsed nimed, mis lahenduvad ühes projektis, ei järgi marsruuti teise.
Kirjutage otsus ja selle omanik üles
Tsentraliseerige seal, kus organisatsioon soovib jagatud võrgu omanikku; hoidke eraldi VPC-sid seal, kus elutsükkel või poliitika seda nõuab. Seejärel valige toetatud ühenduvussuhe ja kirjutage üles, mille valisite, kellele jagatud võrk kuulub ja mida iga projekt võib teada anda.
Projektide loendamine ja ühe VPN-i ostmine igaühe jaoks ei asenda seda omandiotsust. See on sama otsus, tehtud hiljem, selle poolt, kes pärib arve ja marsruutimistabeli.