Miradi kadhaa ya Google Cloud, VPN moja mseto? Amua kwanza
VPC inayoshirikiwa, peering na kitovu cha muunganisho hujibu maswali tofauti ya umiliki. Chagua mpaka wa mtandao kabla ya kupeleka VPN moja kwa kila mradi.
Wakati miradi kadhaa ya Google Cloud inahitaji ufikiaji mseto, silika ni VPN moja kwa kila mradi, na hiyo ni karibu kila wakati umbo lisilofaa. Umiliki wa mradi na uelekezaji wa pakiti ni masuala yanayohusiana lakini tofauti, na usanifu wenye manufaa huhifadhi mipaka ya kiutawala unayohitaji huku ukitoa viambishi vilivyokusudiwa njia moja ya makusudi kuelekea ofisi au kituo cha data. Ukaguzi huu huamua ni modeli gani ya mtandao unayotaka kwa kweli, kwa mpangilio unaoepuka kufanya kazi upya. Kila mmoja unaweza kumaliza mjadala mapema, na hilo ndilo lengo.
Mpaka wa mradi hauhitaji kiotomatiki handaki yake mwenyewe.
Angalia ikiwa kitu kinachoshirikiwa ni mtandao
Anza na swali kuhusu umiliki, si muunganisho: je, umiliki wa mtandao wa kati unaweza kusaidia mizigo hii ya kazi? Ikiwa jibu ni ndiyo na shirika lina usanidi unaofaa, mradi mwenyeji unamiliki VPC, subneti na muunganisho, wakati miradi ya huduma inamiliki rasilimali zake za programu. Muunganisho mmoja wa Cloud VPN katika mtandao huo unaoshirikiwa unaweza kisha kuhudumia viambishi vya mzigo wa kazi vilivyokusudiwa, kwa kuzingatia sera za uelekezaji na usalama .
Kuwa sahihi kuhusu kile ushirikiano unachofanya. Kuunganisha mradi wa huduma hakuunganishi VPC yake huru iliyopo katika mtandao mwenyeji, na hakuhamishi kila rasilimali kiotomatiki. Uunganishaji wa mzigo wa kazi, ruhusa, nafasi ya anwani na DNS zote ni sehemu ya usanifu, si matokeo ya mpangilio. Soma ushirikiano kwanza kama mabadiliko ya ruhusa na kisha kama mabadiliko ya uelekezaji, kwa sababu timu kwa kawaida hugundua tofauti wakati wa mpito.
Ikiwa umiliki wa kati haukubaliki kwa timu zinazohusika, simama hapa na chukulia mengine kama muundo wa peering au kitovu. Kulazimisha Shared VPC kwa kikundi kinachohitaji mizunguko huru ya maisha ya mtandao huzaa tatizo la kisiasa lenye jina la kiufundi.
Angalia ikiwa VPC huru zinaweza kubaki huru
Peering huhifadhi VPC tofauti, na ndiyo sababu inavutia timu zinazotaka mipango yao ya anwani na udhibiti wao wa mabadiliko. Mtego ni kwamba peering si ya kupitisha: peering A-hadi-B na B-hadi-C yenyewe haizalishi uelekezaji A-hadi-C kupitia B. Ikiwa miradi mitatu inahitaji kufikia lengwa moja mseto, unahitaji mpango wa kubadilishana wa makusudi badala ya mnyororo wa peering.
Kushiriki ufikikaji mseto pia kunategemea ubadilishanaji ulioandikwa wa njia maalum na matangazo ya Cloud Router yaliyokusudiwa. Hali ya peering hai inathibitisha kwamba peering ipo, si kwamba viambishi vinavyojali kila upande viliwahi kuhamishwa nje. Angalia safu zilizohamishwa kwa pande zote za peer, katika usanidi unaofanya uhamishaji, na uzilinganishe na anwani ambazo mizigo yako ya kazi hutumia kwa kweli. Kutofautiana huko ndiyo sababu ya kawaida zaidi ya peering kuonekana nzuri wakati kiambishi kinabaki kisichofikika.
Andika mpango wa anwani kabla ya kitu kingine chochote. Safu zisizopishana, njia kuelekea kila lengwa lililokusudiwa na matangazo ya kurudi ni vitu vitatu ambavyo modeli hii inaishi au inakufa.
Angalia ikiwa modeli ya kitovu inafaa topolojia
Kwa muundo mkubwa au uliogawanywa tofauti, muhtasari wa Google Network Connectivity Center unaelezea modeli za kitovu na mionzi. Iisome kwa kile toleo la sasa linasaidia, si kwa kile mchoro unadokeza: michanganyiko gani ya VPC na mseto, familia gani za njia na sera gani kila aina ya mionzi inaruhusu.
Angalia familia ya anwani kwa uwazi. Mifano ya upangaji katika miongozo mingi, ikiwa ni pamoja na huu, inahusu IPv4, na kipengele kilichopo kwa aina moja ya mionzi hakitumiki kiotomatiki bila mabadiliko kwa nyingine. Ikiwa mazingira yako ni ya safu mbili, swali hilo ni la uchaguzi wa modeli, si la uhamishaji wa baadaye.
Jedwali lililo hapa chini ni muhtasari wa modeli tatu na swali linaloamua kila moja.
| 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? |
Angalia kile uelekezaji hautoi
Ubadilishanaji wa njia si utoaji wa uaminifu wa jumla. Utatuzi wa DNS, ruhusa ya firewall na idhini ya programu zinabaki majukumu yao wenyewe, na kila moja husanidiwa na mmiliki tofauti katika mashirika mengi. Muundo unaodhani ufikikaji unamaanisha idhini utapita jaribio la muunganisho na utashindwa katika ukaguzi wa usalama.
Thibitisha pia simulizi la DNS kwa kila modeli, kwa sababu mipangilio ya eneo na uhamishaji hutofautiana kati ya mtandao unaoshirikiwa na mitandao iliyopangwa peer. Majina ya kibinafsi yanayotatuliwa katika mradi mmoja hayafuati njia kuingia mwingine.
Rekodi uamuzi na mmiliki wake
Weka katikati ambapo shirika linataka mmiliki wa mtandao unaoshirikiwa; weka VPC tofauti ambapo mzunguko wa maisha au sera inahitaji. Kisha chagua uhusiano wa muunganisho unaosaidiwa na uandike ni upi ulichagua, nani anamiliki mtandao unaoshirikiwa, na kila mradi unaruhusiwa kutangaza nini.
Kuhesabu miradi na kununua VPN moja kwa kila mmoja si mbadala wa uamuzi huo wa umiliki. Ni uamuzi huo huo, uliofanywa baadaye, na yeyote anayerithi bili na jedwali la uelekezaji.