Niekoľko projektov Google Cloud, jedna hybridná VPN? Najprv sa rozhodnite
Zdieľaná VPC, peering a centrum pripojiteľnosti odpovedajú na rôzne otázky vlastníctva. Vyberte hranicu siete predtým, než nasadíte jednu VPN na projekt.
Keď viacero projektov Google Cloud potrebuje hybridný prístup, inštinktom je jedna VPN na projekt, a to je takmer vždy nesprávny tvar. Vlastníctvo projektu a smerovanie paketov sú súvisiace, ale odlišné otázky, a užitočná architektúra zachováva administratívne hranice, ktoré potrebujete, a zároveň dáva zamýšľaným prefixom jednu premyslenú cestu do kancelárie alebo dátového centra. Tieto kontroly rozhodujú, ktorý sieťový model vlastne chcete, v poradí, ktoré sa vyhýba prerábaniu. Každá z nich môže diskusiu ukončiť skoro, a o to ide.
Hranica projektu automaticky nevyžaduje vlastný tunel.
Skontrolujte, či je zdieľaným objektom sieť
Začnite otázkou o vlastníctve, nie o pripojení: môže centrálne vlastníctvo siete podporiť tieto pracovné zaťaženia? Ak je odpoveď áno a organizácia má vhodnú konfiguráciu, hostiteľský projekt vlastní VPC, podsiete a pripojenie, zatiaľ čo servisné projekty vlastnia svoje aplikačné zdroje. Jedno pripojenie Cloud VPN v tejto zdieľanej sieti potom môže obsluhovať zamýšľané prefixy pracovného zaťaženia, pri dodržaní pravidiel smerovania a zabezpečenia .
Buďte presní v tom, čo pridruženie robí. Pripojenie servisného projektu nezlúči jeho existujúcu nezávislú VPC s hostiteľskou sieťou a nepresunie automaticky každý prostriedok. Pripojenie pracovných zaťažení, povolenia, adresný priestor a DNS sú všetky súčasťou architektúry, nie dôsledkom nastavenia. Čítajte pridruženie najprv ako zmenu povolení a až potom ako zmenu smerovania, pretože tímy rozdiel zvyčajne objavia počas prechodu.
Ak centrálne vlastníctvo nie je pre zúčastnené tímy prijateľné, zastavte sa tu a zvyšok berte ako návrh s peeringom alebo centrom. Vnucovanie Shared VPC skupine, ktorá potrebuje nezávislé životné cykly siete, vytvára politický problém s technickým názvom.
Skontrolujte, či nezávislé VPC môžu zostať nezávislé
Peering zachováva oddelené VPC, a práve preto priťahuje tímy, ktoré chcú vlastné adresné plány a vlastnú kontrolu zmien. Háčik je v tom, že peering nie je tranzitívny: peering A-k-B a B-k-C sám o sebe nevytvára smerovanie A-k-C cez B. Ak tri projekty potrebujú dosiahnuť jeden hybridný cieľ, potrebujete premyslený plán výmeny, nie reťaz peeringov.
Zdieľanie hybridnej dostupnosti závisí aj od zdokumentovanej výmeny vlastných trás a od zamýšľaných inzerátov Cloud Router. Aktívny stav peeringu dokazuje, že peering existuje, nie že prefixy, ktoré sú pre každú stranu dôležité, boli niekedy exportované. Skontrolujte exportované rozsahy na oboch stranách peeru, v konfigurácii, ktorá export vykonáva, a porovnajte ich s adresami, ktoré vaše pracovné zaťaženia skutočne používajú. Nezhoda tam je najčastejším dôvodom, prečo peering vyzerá zdravo, zatiaľ čo prefix zostáva nedostupný.
Napíšte adresný plán pred všetkým ostatným. Neprekrývajúce sa rozsahy, trasy ku každému zamýšľanému cieľu a spätné inzeráty sú tri artefakty, na ktorých tento model žije alebo zomiera.
Skontrolujte, či model centra vyhovuje topológii
Pre väčší alebo inak segmentovaný návrh prehľad Google Network Connectivity Center opisuje modely centra a lúča. Čítajte ho kvôli tomu, čo aktuálne vydanie podporuje, a nie kvôli tomu, čo naznačuje diagram: ktoré kombinácie VPC a hybridov, ktoré rodiny trás a aké pravidlá povoľuje každý typ lúča.
Skontrolujte rodinu adries výslovne. Príklady plánovania vo väčšine príručiek, vrátane tejto, sa týkajú IPv4, a funkcia, ktorá existuje pre jeden typ lúča, sa automaticky bez zmien nevzťahuje na iný. Ak je vaše prostredie s dvojitým zásobníkom, táto otázka patrí k voľbe modelu, nie k neskoršej migrácii.
Tabuľka nižšie je zhrnutím troch modelov a otázky, ktorá rozhoduje každý z nich.
| 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? |
Skontrolujte, čo smerovanie neposkytuje
Výmena trás nie je všeobecným poskytnutím dôvery. Rozlíšenie DNS, povolenie firewallu a autorizácia aplikácií zostávajú vlastnými zodpovednosťami a každú z nich vo väčšine organizácií konfiguruje iný vlastník. Návrh, ktorý predpokladá, že dostupnosť znamená autorizáciu, prejde testom pripojenia a neprejde bezpečnostnou kontrolou.
Potvrďte aj príbeh DNS pre každý model, pretože usporiadanie zón a presmerovania sa líši medzi zdieľanou sieťou a sieťami s peeringom. Privátne názvy, ktoré sa rozlišujú v jednom projekte, nenasledujú trasu do druhého.
Zaznamenajte rozhodnutie a jeho vlastníka
Centralizujte tam, kde organizácia chce zdieľaného vlastníka siete; zachovajte oddelené VPC tam, kde to vyžaduje životný cyklus alebo pravidlá. Potom vyberte podporovaný vzťah pripojiteľnosti a zapíšte, ktorý ste zvolili, kto vlastní zdieľanú sieť a čo smie každý projekt inzerovať.
Počítanie projektov a kúpa jednej VPN pre každý nenahrádza to rozhodnutie o vlastníctve. Je to to isté rozhodnutie, prijaté neskôr, tým, kto zdedí účet a smerovaciu tabuľku.