Nokkur Google Cloud-verkefni, eitt blendinga-VPN? Ákveðið fyrst
Sameiginlegt VPC, peering og tengistöð svara mismunandi spurningum um eignarhald. Veldu netmörkin áður en þú setur upp eitt VPN fyrir hvert verkefni.
Þegar nokkur Google Cloud-verkefni þurfa blendingaaðgang er eðlishvötin eitt VPN fyrir hvert verkefni, og það er næstum alltaf rangt form. Eignarhald verkefnis og leiðsla pakka eru skyld en mismunandi spurningar, og gagnleg arkitektúr heldur þeim stjórnsýslumörkum sem þú þarft á meðan hann gefur fyrirhuguðum forskeytum eina yfirvegaða leið til skrifstofunnar eða gagnavers. Þessar athuganir ákvarða hvaða netmódel þú vilt í raun, í þeirri röð sem kemur í veg fyrir endurvinnu. Hver þeirra getur endað umræðuna snemma, og það er punkturinn.
Verkefnamörk krefjast ekki sjálfkrafa eigin göngs.
Athugaðu hvort sameiginlega hluturinn sé netið
Byrjaðu á spurningu um eignarhald, ekki tengingu: getur miðlægt neteignarhald stutt þessi vinnuálag? Ef svarið er já og stofnunin hefur viðeigandi stillingar, á hýsilverkefnið VPC, undirnetin og tenginguna, en þjónustuverkefni eiga sín eigin forritatilföng. Ein Cloud VPN-tenging í því sameiginlega neti getur þá þjónað fyrirhuguðum vinnuálagsforskeytum, að því tilskildu að leiðslu- og öryggisstefnum sé fylgt .
Vertu nákvæm um hvað samtenging gerir. Að tengja þjónustuverkefni sameinar ekki núverandi sjálfstætt VPC þess við hýsilnetið og færir ekki hvert tilfang sjálfkrafa. Vinnuálagstenging, heimildir, netfangarými og DNS eru allt hluti arkitektúrsins, ekki afleiðing stillingarinnar. Lestu samtenginguna fyrst sem heimildabreytingu og síðan sem leiðslubreytingu, því teymin uppgötva muninn venjulega við yfirfærsluna.
Ef miðlægt eignarhald er óviðunandi fyrir teymin sem hlut eiga að máli, stöðvaðu hér og meðhöndlaðu restina sem peering- eða stöðvarhönnun. Að þvinga Shared VPC á hóp sem þarf sjálfstæða netlífsferla skapar pólitískt vandamál með tæknilegu nafni.
Athugaðu hvort sjálfstæð VPC geti haldist sjálfstæð
Peering varðveitir aðskilin VPC, og það er einmitt hvers vegna það laðar að teymin sem vilja eigin netfangaskipanir og eigin breytingastjórnun. Gildran er sú að peering er ekki gegnumstreymt: peering A-til-B og B-til-C skapar ekki af sjálfu sér leiðslu A-til-C í gegnum B. Ef þrjú verkefni þurfa að ná einum blendingaáfangastað þarftu yfirvegaða skiptiáætlun frekar en keðju af peeringum.
Deiling blendingaaðgengis veltur líka á skjalfestum skiptum á sérsniðnum leiðum og fyrirhuguðum tilkynningum Cloud Router. Virk peering-staða sannar að peeringið sé til, ekki að forskeytin sem hvorri hlið er annt um hafi einhvern tímann verið flutt út. Athugaðu útfluttu bilin beggja vegna peersins, í þeirri stillingu sem framkvæmir útflutninginn, og berðu þau saman við netföngin sem vinnuálagið þitt notar í raun. Ósamræmi þar er algengasta ástæðan fyrir því að peering virðist heilbrigt á meðan forskeyti er óaðgengilegt.
Skrifaðu netfangaskipanina fyrir allt annað. Bilin sem skarast ekki, leiðirnar að hverjum fyrirhuguðum áfangastað og tilkynningar til baka eru þrír hlutirnir sem þetta módel lifir eða deyr á.
Athugaðu hvort stöðvarmódel passi við netlögun
Fyrir stærri eða öðruvísi sundurhlutaða hönnun lýsir Google Network Connectivity Center yfirlitið stöðvar- og geislamódelunum. Lestu það fyrir það sem núverandi útgáfa styður, ekki fyrir það sem skýringarmyndin gefur í skyn: hvaða VPC- og blendingasamsetningar, hvaða leiðarfjölskyldur og hvaða stefnur hver geislategund leyfir.
Athugaðu netfangafjölskylduna sérstaklega. Skipulagsdæmi í flestum leiðbeiningum, þar á meðal þessum, snerta IPv4, og eiginleiki sem er til fyrir eina geislategund gildir ekki sjálfkrafa óbreyttur fyrir aðra. Ef umhverfið þitt er tvöfaldur stafli á sú spurning heima í módelvalinu, ekki í síðari flutningi.
Taflan hér að neðan er samantektin af módelunum þremur og spurningunni sem ákvarðar hvert þeirra.
| 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? |
Athugaðu hvað leiðsla veitir ekki
Leiðarskipti eru ekki almenn traustveiting. DNS-upplausn, eldveggjaheimild og forritaaðlögun vera eigin ábyrgð, og hver þeirra er stillt af mismunandi eiganda í flestum stofnunum. Hönnun sem gerir ráð fyrir að aðgengi feli í sér aðlögun mun standast tengiprófið og falla á öryggisendurskoðuninni.
Staðfestu líka DNS-söguna fyrir hvert módel, því svæðis- og framsendingarfyrirkomulag er mismunandi milli sameiginlegs nets og peers-tengdra neta. Einkaaðanöfn sem leysast í einu verkefni fara ekki eftir leið inn í annað.
Skráðu ákvörðunina og eiganda hennar
Miðstýrðu þar sem stofnunin vill sameiginlegan neteiganda; haltu aðskildum VPC þar sem lífsferill eða stefna krefst þess. Veldu síðan studda tengitengsl og skrifaðu niður hverja þú valst, hver á sameiginlega netið og hvað hvert verkefni má tilkynna.
Að telja verkefni og kaupa eitt VPN fyrir hvert er ekki staðgengill fyrir þá eignarhaldsákvörðun. Það er sama ákvörðunin, tekin síðar, af þeim sem erfir reikninginn og leiðslutöfluna.