Бир нече Google Cloud долбоору, бир гибриддик VPN? Адегенде чечиңиз
Жалпы VPC, пиринг жана байланыш борбору ар кандай менчик суроолоруна жооп берет. Ар бир долбоор үчүн бир VPN жайгаштыруудан мурун тармактын чек арасын тандаңыз.
Бир нече Google Cloud долбооруна гибриддик кирүү керек болгондо, инстинкт ар бир долбоор үчүн бир VPN сунуштайт, жана бул дээрлик дайыма туура эмес форма. Долбоордун менчиги жана пакеттерди маршруттоо байланыштуу, бирок ар кандай маселелер, жана пайдалуу архитектура керектүү административдик чек араларды сактап, белгиленген префикстерге кеңсеге же маалымат борборуна бир ойлонулган жол берет. Бул текшерүүлөр кайсы тармактык моделди чындап каалайарыңызды, кайра иштөөдөн качкан тартипте чечет. Алардын ар бири талкууну эрте бүтүрө алат, жана маселе ушунда.
Долбоордун чек арасы автоматтык түрдө өз туннелин талап кылбайт.
Жалпы объект тармакпы же жокпу текшериңиз
Менчик жөнүндө суроодон баштаңыз, байланыш жөнүндө эмес: борбордук тармактык менчик бул жүктөрдү колдой алабы? Жооп ооба болсо жана уюмда ылайыктуу конфигурация болсо, хост долбоор VPCга, ички тармактарга жана байланышка ээ, ал эми кызмат долбоорлору өз колдонмо ресурстарына ээ. Ошол жалпы тармактагы бир Cloud VPN байланышы андан кийин белгиленген жүк префикстерине кызмат кыла алат, маршруттоо жана коопсуздук саясаттарын сактоо менен .
Бириктирүү эмне кылаарында так болуңуз. Кызмат долбоорун тиркөө анын учурдагы көз карандысыз VPCсын хост тармагына бириктирбейт жана ар бир ресурсту автоматтык түрдө жылдырбайт. Жүктү тиркөө, уруксаттар, дарек мейкиндиги жана DNS — баары архитектуранын бөлүгү, жөндөөнүн кесепети эмес. Бириктирүүнү адегенде уруксат өзгөрүүсү, анан маршруттоо өзгөрүүсү катары окуңуз, анткени командалар айырмачылыкты адатта өтүү учурунда аныкташат.
Эгер борбордук менчик катышкан командалар үчүн кабыл алынбаса, ушул жерден токтоңуз жана калганын пиринг же борбор дизайны катары караңыз. Көз карандысыз тармактык жашоо циклдери керек болгон топко Shared VPCди күч менен таңуу техникалык аталышы бар саясий маселе жаратат.
Көз карандысыз VPCлар көз карандысыз кала алабы, текшериңиз
Пиринг өзүнчө VPCларды сактайт, ошондуктан өз дарек пландарын жана өз өзгөрүү көзөмөлүн каалаган командаларды тартат. Куулук — пиринг транзиттик эмес: Aдан-Bге жана Bден-Cге пиринг өзүнөн өзү B аркылуу Aдан-Cге маршруттоо түзбөйт. Эгер үч долбоор бир гибриддик багытка жетүүсү керек болсо, сизге пиринг тизмеги эмес, ойлонулган алмашуу планы керек.
Гибриддик жеткиликтүүлүктү бөлүшүү ошондой эле документтештирилген ыңгайлаштырылган маршруттардын алмашуусуна жана белгиленген 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 сатып алуу ошол менчик чечимин алмаштырбайт. Бул ошол эле чечим, кийинчерээк кабыл алынган, эсеп-фактураны жана маршруттоо таблицасын мураска алган адам тарабынан.