Няколко проекта в 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 за всеки не замества това решение за собственост. Това е същото решение, взето по-късно, от този, който наследява сметката и таблицата за маршрутизиране.