Бірнеше 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 сатып алу сол меншік шешімін алмастырмайды. Бұл сол шешім, кейінірек шот пен маршруттау кестесін мұраға алатын адам қабылдайды.