Неколико Google Cloud пројеката, један хибридни VPN? Прво одлучите
Заједнички VPC, пиринг и центар повезивања одговарају на различита питања власништва. Изаберите границу мреже пре него што распоредите један VPN по пројекту.
Када је неколико Google Cloud пројеката потребан хибридни приступ, инстинкт је један VPN по пројекту, и то је скоро увек погрешан облик. Власништво пројекта и рутирање пакета су повезана, али различита питања, и корисна архитектура задржава административне границе које су вам потребне, а истовремено даје предвиђеним префиксима један смишљен пут до канцеларије или центра података. Ове провере одлучују који модел мреже заиста желите, редом који избегава поновни рад. Свака од њих може рано да заврши дискусију, и то је поента.
Граница пројекта не захтева аутоматски сопствени тунел.
Проверите да ли је заједнички објекат мрежа
Почните питањем о власништву, не о повезаности: може ли централно власништво мреже да подржи ова радна оптерећења? Ако је одговор да и организација има одговарајућу конфигурацију, хост пројекат поседује VPC, подмреже и повезаност, док сервисни пројекти поседују сопствене ресурсе апликација. Једна Cloud VPN веза у тој заједничкој мрежи може затим да опслужује предвиђене префиксе радног оптерећења, уз поштовање политика рутирања и безбедности .
Будите прецизни у погледу тога шта придруживање ради. Повезивање сервисног пројекта не спаја његов постојећи независни VPC са хост мрежом и не премешта аутоматски сваки ресурс. Повезивање радног оптерећења, дозволе, адресни простор и DNS су део архитектуре, а не последица подешавања. Читајте придруживање прво као промену дозвола, а затим као промену рутирања, јер тимови разлику обично открију током преласка.
Ако централно власништво није прихватљиво за укључене тимове, зауставите се овде и остатак третирајте као дизајн пиринга или центра. Наметање Shared VPC групи која захтева независне животне циклусе мреже ствара политички проблем са техничким именом.
Проверите да ли независни VPC могу да остану независни
Пиринг задржава одвојене VPC, и управо зато привлачи тимове који желе сопствене адресне планове и сопствену контролу измена. Зачкољица је у томе што пиринг није транзитиван: пиринг А-ка-Б и Б-ка-Ц сам по себи не ствара рутирање А-ка-Ц преко Б. Ако три пројекта треба да достигну једну хибридну дестинацију, потребан вам је смишљен план размене, а не ланац пиринга.
Дељење хибридне доступности такође зависи од документоване размене прилагођених рута и од предвиђених огласа Cloud Router. Активни статус пиринга доказује да пиринг постоји, а не да су префикси који су важни за сваку страну икада извезени. Проверите извезене опсеге са обе стране пира, у конфигурацији која обавља извоз, и упоредите их са адресама које ваша радна оптерећења заиста користе. Неслагање тамо је најчешћи разлог зашто пиринг изгледа здраво, а префикс остаје недоступан.
Напишите план адреса пре свега осталог. Опсези који се не преклапају, руте ка свакој предвиђеној дестинацији и повратни огласи су три артефакта на којима овај модел живи или умире.
Проверите да ли модел центра одговара топологији
За већи или другачије сегментиран дизајн, преглед Google Network Connectivity Center описује моделе центра и крака. Читајте га због онога што тренутно издање подржава, а не због онога што дијаграм подразумева: које VPC и хибридне комбинације, које породице рута и какве политике дозвољава сваки тип крака.
Проверите породицу адреса експлицитно. Примери планирања у већини водича, укључујући овај, тичу се IPv4, а функција која постоји за један тип крака не примењује се аутоматски непромењена на други. Ако је ваше окружење са двоструким стеком, то питање припада избору модела, а не каснијој миграцији.
Табела испод је резиме три модела и питања које одлучује сваки.
| 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? |
Проверите шта рутирање не даје
Размена рута није свеобухватно давање поверења. DNS резолуција, дозвола заштитног зида и ауторизација апликације остају сопствене одговорности, и сваку од њих у већини организација конфигурише други власник. Дизајн који претпоставља да доступност значи ауторизацију проћи ће тест повезаности и пасти на безбедносној провери.
Потврдите и причу о DNS за сваки модел, јер се поставке зона и прослеђивања разликују између заједничке мреже и мрежа са пирингом. Приватна имена која се решавају у једном пројекту не следе руту у други.
Забележите одлуку и њеног власника
Централизујте тамо где организација жели заједничког власника мреже; задржите одвојене VPC тамо где то захтева животни циклус или политика. Затим изаберите подржани однос повезаности и запишите који сте изабрали, ко поседује заједничку мрежу и шта сваки пројекат сме да оглашава.
Бројање пројеката и куповина једног VPN-а за сваки није замена за ту одлуку о власништву. То је иста одлука, донета касније, од стране онога који наследи рачун и табелу рутирања.