Keli Google Cloud projektai, vienas hibridinis VPN? Pirmiausia nuspręskite
Bendras VPC, peering ir jungiamumo centras atsako į skirtingus nuosavybės klausimus. Pasirinkite tinklo ribą prieš diegdami po vieną VPN kiekvienam projektui.
Kai keliems Google Cloud projektams reikia hibridinės prieigos, instinktas yra vienas VPN kiekvienam projektui, ir tai beveik visada netinkama forma. Projekto nuosavybė ir paketų maršrutizavimas yra susiję, bet skirtingi klausimai, o naudinga architektūra išlaiko reikiamas administracines ribas ir kartu suteikia numatytiems prefiksams vieną apgalvotą kelią į biurą ar duomenų centrą. Šie patikrinimai nusprendžia, kurio tinklo modelio iš tikrųjų norite, tokia tvarka, kuri išvengia perdarymo. Kiekvienas jų gali anksti baigti diskusiją, ir tai yra esmė.
Projekto riba automatiškai nereikalauja savo tunelio.
Patikrinkite, ar bendras objektas yra tinklas
Pradėkite nuo klausimo apie nuosavybę, o ne apie jungiamumą: ar centrinė tinklo nuosavybė gali palaikyti šiuos darbo krūvius? Jei atsakymas taip ir organizacija turi tinkamą konfigūraciją, pagrindinis projektas valdo VPC, potinklius ir jungiamumą, o paslaugų projektai valdo savo programų išteklius. Viena Cloud VPN jungtis tame bendrame tinkle tada gali aptarnauti numatytus darbo krūvio prefiksus, laikantis maršrutizavimo ir saugos politikos .
Būkite tikslūs, ką daro susiejimas. Paslaugų projekto prijungimas nesujungia jo esamo nepriklausomo VPC su pagrindiniu tinklu ir neperkelia kiekvieno ištekliaus automatiškai. Darbo krūvio prijungimas, leidimai, adresų erdvė ir DNS yra architektūros dalis, o ne nustatymo pasekmė. Susiejimą skaitykite pirmiausia kaip leidimų pakeitimą, o paskui kaip maršrutizavimo pakeitimą, nes komandos paprastai skirtumą atranda perėjimo metu.
Jei centrinė nuosavybė susijusioms komandoms nepriimtina, sustokite čia ir likusią dalį traktuokite kaip peering arba centro dizainą. Shared VPC primetimas grupei, kuriai reikia nepriklausomų tinklo gyvavimo ciklų, sukuria politinę problemą su techniniu pavadinimu.
Patikrinkite, ar nepriklausomi VPC gali likti nepriklausomi
Peering išlaiko atskirus VPC, ir būtent todėl jis traukia komandas, kurios nori savo adresų planų ir savo pokyčių kontrolės. Kabliukas tas, kad peering nėra tranzityvus: A-B ir B-C peering savaime nesukuria A-C maršrutizavimo per B. Jei trims projektams reikia pasiekti vieną hibridinę paskirties vietą, jums reikia apgalvoto mainų plano, o ne peering grandinės.
Hibridinio pasiekiamumo bendrinimas taip pat priklauso nuo dokumentuotų pasirinktinių maršrutų mainų ir numatytų Cloud Router skelbimų. Aktyvus peering statusas įrodo, kad peering egzistuoja, o ne tai, kad prefiksai, kurie svarbūs kiekvienai pusei, kada nors buvo eksportuoti. Patikrinkite eksportuotus diapazonus abiejose peer pusėse, konfigūracijoje, kuri atlieka eksportą, ir palyginkite juos su adresais, kuriuos jūsų darbo krūviai iš tikrųjų naudoja. Ten esantis neatitikimas yra dažniausia priežastis, kodėl peering atrodo sveikas, o prefiksas lieka nepasiekiamas.
Parašykite adresų planą prieš viską kita. Nesikertantys diapazonai, maršrutai į kiekvieną numatytą paskirties vietą ir grįžtamieji skelbimai yra trys artefaktai, ant kurių šis modelis gyvena arba miršta.
Patikrinkite, ar centro modelis tinka topologijai
Didesniam ar kitaip segmentuotam dizainui Google Network Connectivity Center apžvalga aprašo centro ir stipino modelius. Skaitykite ją dėl to, ką palaiko dabartinė versija, o ne dėl to, ką sufleruoja diagrama: kurie VPC ir hibridiniai deriniai, kurios maršrutų šeimos ir kokias politikas leidžia kiekvienas stipino tipas.
Aiškiai patikrinkite adresų šeimą. Daugumos vadovų, įskaitant šį, planavimo pavyzdžiai susiję su IPv4, o funkcija, kuri egzistuoja vienam stipino tipui, automatiškai nepersikelia nepakeista į kitą. Jei jūsų aplinka yra dviguba rietuvė, tas klausimas priklauso modelio pasirinkimui, o ne vėlesnei migracijai.
Žemiau esanti lentelė yra trijų modelių santrauka ir klausimas, kuris nusprendžia kiekvieną.
| 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? |
Patikrinkite, ko maršrutizavimas nesuteikia
Maršrutų mainai nėra visuotinis pasitikėjimo suteikimas. DNS sprendimas, ugniasienės leidimas ir programos autorizavimas lieka jų pačių atsakomybe, ir kiekvieną jų daugumoje organizacijų konfigūruoja skirtingas savininkas. Dizainas, kuris daro prielaidą, kad pasiekiamumas reiškia autorizavimą, praeis jungiamumo testą ir nepraeis saugos peržiūros.
Taip pat patvirtinkite DNS istoriją kiekvienam modeliui, nes zonos ir persiuntimo tvarka skiriasi tarp bendro tinklo ir peer tinklų. Privatūs vardai, kurie išsprendžiami viename projekte, neseka maršrutu į kitą.
Užfiksuokite sprendimą ir jo savininką
Centralizuokite ten, kur organizacija nori bendro tinklo savininko; laikykite atskirus VPC ten, kur to reikalauja gyvavimo ciklas arba politika. Tada pasirinkite palaikomą jungiamumo ryšį ir užrašykite, kurį pasirinkote, kas valdo bendrą tinklą ir ką kiekvienas projektas gali skelbti.
Projektų skaičiavimas ir vieno VPN pirkimas kiekvienam nepakeičia to nuosavybės sprendimo. Tai tas pats sprendimas, priimtas vėliau, to, kuris paveldi sąskaitą ir maršrutizavimo lentelę.