Неколку Google Cloud проекти, еден хибриден VPN? Прво одлучете
Споделен VPC, пиринг и центар за поврзување одговараат на различни прашања за сопственоста. Изберете ја границата на мрежата пред да распоредите еден VPN по проект.
Кога неколку Google Cloud проекти бараат хибриден пристап, инстинктот е еден VPN по проект, и тоа е речиси секогаш погрешна форма. Сопственоста на проектот и рутирањето на пакети се поврзани, но различни прашања, и корисната архитектура ги задржува административните граници што ви се потребни, а истовремено им дава на предвидените префикси еден смислен пат до канцеларијата или центарот за податоци. Овие проверки одлучуваат кој мрежен модел всушност го сакате, по редот што избегнува повторна работа. Секоја од нив може рано да ја заврши дискусијата, и тоа е поентата.
Границата на проектот не бара автоматски сопствен тунел.
Проверете дали споделениот објект е мрежата
Започнете со прашање за сопственоста, не за поврзаноста: може ли централната сопственост на мрежата да ги поддржи овие работни оптоварувања? Ако одговорот е да и организацијата има соодветна конфигурација, хост проектот го поседува VPC, подмрежите и поврзаноста, додека сервисните проекти ги поседуваат сопствените ресурси за апликации. Една Cloud VPN врска во таа споделена мрежа потоа може да ги опслужува предвидените префикси на работното оптоварување, предмет на политиките за рутирање и безбедност .
Бидете прецизни за тоа што го прави здружувањето. Приклучувањето на сервисен проект не го спојува неговиот постоечки независен VPC во хост мрежата и не го преместува секој ресурс автоматски. Приклучувањето на работното оптоварување, дозволите, адресниот простор и DNS се дел од архитектурата, а не последица од поставката. Читајте го здружувањето прво како промена на дозволи, а потоа како промена на рутирање, бидејќи тимовите обично ја откриваат разликата за време на преминот.
Ако централната сопственост не е прифатлива за вклучените тимови, застанете тука и остатокот третирајте го како пиринг или дизајн на центар. Наметнувањето на Shared VPC врз група на која ѝ требаат независни мрежни животни циклуси создава политички проблем со техничко име.
Проверете дали независните VPC можат да останат независни
Пиринг ги задржува одделните VPC, и токму затоа ги привлекува тимовите што сакаат сопствени адресни планови и сопствена контрола на промените. Замината е што пиринг не е транзитивен: пиринг A-кон-B и B-кон-C сам по себе не создава рутирање A-кон-C преку B. Ако три проекти треба да достигнат една хибридна дестинација, ви треба смислен план за размена, а не синџир од пиринзи.
Споделувањето на хибридната достапност зависи и од документираната размена на приспособени рути и од предвидените објави на 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 за секој не е замена за таа одлука за сопственост. Тоа е истата одлука, донесена подоцна, од оној што ја наследува сметката и табелата за рутирање.