Disa projekte Google Cloud, një VPN hibride? Vendosni së pari
VPC i përbashkët, peering dhe një hub lidhshmërie u përgjigjen pyetjeve të ndryshme të pronësisë. Zgjidhni kufirin e rrjetit para se të vendosni një VPN për projekt.
Kur disa projekte Google Cloud kanë nevojë për akses hibrid, instinkti është një VPN për projekt, dhe kjo është pothuajse gjithmonë forma e gabuar. Pronësia e projektit dhe rrugëtimi i paketave janë çështje të lidhura, por të ndryshme, dhe arkitektura e dobishme ruan kufijtë administrativë që ju nevojiten duke u dhënë prefikseve të synuara një rrugë të vetme të qëllimshme drejt zyrës ose qendrës së të dhënave. Këto kontrolle vendosin cili model rrjeti dëshironi vërtet, në rendin që shmang ripunën. Secili prej tyre mund ta përfundojë diskutimin herët, dhe ky është qëllimi.
Një kufi projekti nuk kërkon automatikisht tunelin e vet.
Kontrolloni nëse objekti i përbashkët është rrjeti
Filloni me një pyetje për pronësinë, jo për lidhshmërinë: a mundet pronësia qendrore e rrjetit t'i mbështesë këto ngarkesa pune? Nëse përgjigjja është po dhe organizata ka një konfigurim të përshtatshëm, një projekt pritës zotëron VPC-në, nënrrjetet dhe lidhshmërinë, ndërsa projektet e shërbimit zotërojnë burimet e tyre të aplikacionit. Një lidhje Cloud VPN në atë rrjet të përbashkët mund të shërbejë më pas prefikset e synuara të ngarkesës së punës, në varësi të politikave të rrugëtimit dhe sigurisë .
Jini të saktë për atë që bën shoqërimi. Lidhja e një projekti shërbimi nuk e shkrin VPC-në e tij ekzistuese të pavarur në rrjetin pritës dhe nuk e zhvendos automatikisht çdo burim. Lidhja e ngarkesës së punës, lejet, hapësira e adresave dhe DNS janë të gjitha pjesë e arkitekturës, jo pasoja të konfigurimit. Lexojeni shoqërimin fillimisht si një ndryshim lejesh dhe më pas si një ndryshim rrugëtimi, sepse ekipet zakonisht e zbulojnë ndryshimin gjatë kalimit.
Nëse pronësia qendrore nuk është e pranueshme për ekipet e përfshira, ndaloni këtu dhe trajtoni pjesën tjetër si një dizajn peering ose hub. Imponimi i Shared VPC mbi një grup që ka nevojë për cikle jete rrjeti të pavarura krijon një problem politik me emër teknik.
Kontrolloni nëse VPC-të e pavarura mund të mbeten të pavarura
Peering ruan VPC të veçanta, dhe pikërisht për këtë tërheq ekipe që duan planet e tyre të adresave dhe kontrollin e tyre të ndryshimeve. Kurthi është se peering nuk është kalimtar: peering A-në-B dhe B-në-C nuk krijon vetvetiu rrugëtim A-në-C përmes B. Nëse tre projekte duhet të arrijnë një destinacion hibrid, ju nevojitet një plan shkëmbimi i qëllimshëm dhe jo një zinxhir peering-esh.
Ndarja e arritshmërisë hibride varet gjithashtu nga shkëmbimi i dokumentuar i rrugëve të personalizuara dhe nga shpalljet e synuara të Cloud Router. Një status peering aktiv provon që peering ekziston, jo që prefikset që kanë rëndësi për secilën anë janë eksportuar ndonjëherë. Kontrolloni intervalet e eksportuara në të dyja anët e peerit, në konfigurimin që kryen eksportimin, dhe krahasojini me adresat që ngarkesat tuaja të punës përdorin në të vërtetë. Një mospërputhje atje është arsyeja më e zakonshme pse një peering duket i shëndetshëm ndërsa një prefiks mbetet i paarritshëm.
Shkruani planin e adresave para çdo gjëje tjetër. Intervalet që nuk mbivendosen, rrugët drejt çdo destinacioni të synuar dhe shpalljet e kthimit janë tre artefaktet mbi të cilat ky model jeton ose vdes.
Kontrolloni nëse një model hub përshtatet me topologjinë
Për një dizajn më të madh ose të segmentuar ndryshe, përmbledhja e Google Network Connectivity Center përshkruan modelet hub dhe rreze. Lexojeni për atë që mbështet versioni aktual, jo për atë që nënkupton diagrami: cilat kombinime VPC dhe hibride, cilat familje rrugësh dhe cilat politika lejon secili lloj rreze.
Kontrolloni familjen e adresave në mënyrë eksplicite. Shembujt e planifikimit në shumicën e udhëzuesve, përfshirë këtë, kanë të bëjnë me IPv4, dhe një veçori që ekziston për një lloj rreze nuk zbatohet automatikisht pa ndryshime për një tjetër. Nëse mjedisi juaj është me dy stack, ajo pyetje i përket zgjedhjes së modelit, jo një migrimi të mëvonshëm.
Tabela më poshtë është përmbledhja e tre modeleve dhe pyetja që vendos secilin.
| 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? |
Kontrolloni çfarë nuk jep rrugëtimi
Shkëmbimi i rrugëve nuk është një dhënie e përgjithshme besimi. Zgjidhja e DNS, leja e firewall-it dhe autorizimi i aplikacionit mbeten përgjegjësitë e tyre, dhe secila prej tyre konfigurohet nga një pronar tjetër në shumicën e organizatave. Një dizajn që supozon se arritshmëria nënkupton autorizim do ta kalojë testin e lidhshmërisë dhe do të dështojë në rishikimin e sigurisë.
Konfirmoni gjithashtu historinë e DNS për secilin model, sepse rregullimet e zonës dhe të përcjelljes ndryshojnë midis një rrjeti të përbashkët dhe rrjeteve me peering. Emrat privatë që zgjidhen në një projekt nuk ndjekin një rrugë në një tjetër.
Regjistroni vendimin dhe pronarin e tij
Centralizoni aty ku organizata dëshiron një pronar të përbashkët rrjeti; mbani VPC të veçanta aty ku e kërkon cikli i jetës ose politika. Pastaj zgjidhni një marrëdhënie lidhshmërie të mbështetur dhe shkruani cilën zgjodhët, kush e zotëron rrjetin e përbashkët dhe çfarë mund të shpallë secili projekt.
Numërimi i projekteve dhe blerja e një VPN për secilin nuk është zëvendësim për atë vendim pronësie. Është i njëjti vendim, i marrë më vonë, nga ai që trashëgon faturën dhe tabelën e rrugëtimit.