Google Cloud proiektu batzuk, VPN hibrido bat? Erabaki aurrena
VPC partekatuak, peering-ak eta konektibitate-zentro batek jabetza-galdera desberdinei erantzuten diete. Aukeratu sarearen muga proiektu bakoitzeko VPN bat inplementatu aurretik.
Google Cloud proiektu batzuek sarbide hibridoa behar dutenean, senak proiektu bakoitzeko VPN bat eskatzen du, eta ia beti da forma okerra. Proiektuaren jabetza eta paketeen bideratzea lotutako baina desberdinak diren gaiak dira, eta arkitektura erabilgarriak behar dituzun muga administratiboak gordetzen ditu, aldi berean aurreikusitako aurrizkiei bulegora edo datu-zentrora bide deliberatu bakarra emanez. Egiaztapen hauek erabakitzen dute zein sare-eredu nahi duzun benetan, berrikuntza saihesten duen ordenan. Bakoitzak eztabaida goiz amai dezake, eta hori da kontua.
Proiektu-muga batek ez du automatikoki bere tunela eskatzen.
Egiaztatu partekatutako objektua sarea den
Hasi jabetzari buruzko galdera batekin, ez konektibitateari buruzkoarekin: sare-jabetza zentralak lan-karga hauek onar ditzake? Erantzuna bai bada eta erakundeak konfigurazio egokia badu, proiektu ostalari batek VPCa, azpisareak eta konektibitatea ditu, eta zerbitzu-proiektuek beren aplikazio-baliabideak dituzte. Sare partekatu horretako Cloud VPN konexio batek aurreikusitako lan-kargen aurrizkiak zerbitza ditzake gero, bideratze- eta segurtasun-politiken menpe .
Izan zehatza elkartzeak zer egiten duen. Zerbitzu-proiektu bat erantsiz ez du bere VPC independente existitzailea ostalari-sarean fusionatzen, eta ez du baliabide bakoitza automatikoki mugitzen. Lan-kargen eranskinak, baimenak, helbide-espazioa eta DNS arkitekturaren parte dira, ez ezarpenaren ondorio. Irakurri elkartzea lehenengo baimen-aldaketa gisa eta gero bideratze-aldaketa gisa, taldeek aldea normalean trantsizioan aurkitzen dutelako.
Jabetza zentrala inplikatutako taldeentzat onargarria ez bada, gelditu hemen eta trata ezazu gainerakoa peering edo zentro diseinu gisa. Shared VPC sare-bizi-ziklo independenteak behar dituen talde bati inposatzeak arazo politikoa sortzen du izen teknikoarekin.
Egiaztatu VPC independenteek independente iraun dezaketen
Peering-ak VPC bereiziak gordetzen ditu, eta horregatik erakartzen ditu beren helbide-planak eta beren aldaketa-kontrola nahi dituzten taldeak. Tranpa da peering-a ez dela trantsitiboa: A-B arteko eta B-C arteko peering-ak ez du berez A-C bideratzerik sortzen Bren bidez. Hiru proiektuk helburu hibrido bat lortu behar badute, truke-plan deliberatu bat behar duzu, peering kate bat ez.
Konektibitate hibridoaren partekatzeak dokumentatutako ibilbide pertsonalizatuen trukearen eta Cloud Router iragarpenen mende ere badago. Peering egoera aktiboak peering-a badagoela frogatzen du, ez alde bakoitzari axola zaizkion aurrizkiak inoiz esportatu zirenik. Egiaztatu esportatutako barrutiak peer-aren bi aldeetan, esportazioa egiten duen konfigurazioan, eta alderatu zure lan-kargek benetan erabiltzen dituzten helbideekin. Hango desadostasuna da peering-a osasuntsu dirudien bitartean aurrizki bat iristezin jarraitzearen arrazoi ohikoena.
Idatzi helbide-plana beste edozeren aurretik. Gainjartzen ez diren barrutiak, aurreikusitako helmuga bakoitzerako ibilbideak eta itzulerako iragarpenak dira eredu hau bizi edo hiltzen den hiru artefaktuak.
Egiaztatu zentro-eredu bat topologiari egokitzen zaion
Diseinu handiago edo bestela segmentatu baterako, Google-ren Network Connectivity Center berrikuspena zentro eta izpi ereduak deskribatzen ditu. Irakurri uneko bertsioak onartzen duenagatik, ez diagramak iradokitzen duenagatik: zein VPC eta hibrido konbinazio, zein ibilbide-familia eta zein politika onartzen dituen izpi mota bakoitzak.
Egiaztatu helbide-familia espresuki. Gida gehienetako plangintza-adibideek, hau barne, IPv4ri buruz dihardute, eta izpi mota batentzat dagoen ezaugarriak ez dio automatikoki aldatzerik gabe beste bati aplikatzen. Zure ingurunea pila bikoitza bada, galdera hori ereduaren aukeraketari dagokio, ez geroko migrazioari.
Beheko taula hiru ereduen laburpena da eta bakoitza erabakitzen duen galdera.
| 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? |
Egiaztatu bideratzeak zer ematen ez duen
Ibilbide-trukea ez da konfiantza-emate orokorra. DNS ebazpena, suebaki-baimena eta aplikazio-baimena beren erantzukizunak dira oraindik, eta bakoitza jabe desberdin batek konfiguratzen du erakunde gehienetan. Iristagarritasunak baimena dakarrela suposatzen duen diseinuak konektibitate-proba gaindituko du eta segurtasun-berrikuspenean huts egingo du.
Baieztatu DNS istorioa eredu bakoitzerako ere, zona eta birbidaltze-konfigurazioak desberdinak baitira sare partekatu eta peer sareen artean. Proiektu batean ebazten diren izen pribatuek ez dute beste batera bideratzerik jarraitzen.
Erregistratu erabakia eta bere jabea
Zentralizatu erakundeak sare-jabe partekatua nahi duen tokian; mantendu VPC bereiziak bizi-zikloak edo politikak hala eskatzen duen tokian. Ondoren aukeratu onartutako konektibitate-harreman bat eta idatzi zein aukeratu duzun, nor den sare partekatuaren jabea eta zer iragar dezakeen proiektu bakoitzak.
Proiektuak zenbatzea eta bakoitzeko VPN bat erostea ez da jabetza-erabaki horren ordezkoa. Erabaki bera da, geroago hartua, faktura eta bideratze-taula oinordetzen dituenak.