Useita Google Cloud -projekteja, yksi hybridi VPN? Päättäkää ensin
Jaettu VPC, peering ja yhteyskeskus vastaavat erilaisiin omistuskysymyksiin. Valitse verkon raja ennen kuin otat käyttöön yhden VPN:n projektia kohden.
Kun useat Google Cloud -projektit tarvitsevat hybridikäyttöä, vaisto on yksi VPN projektia kohden, ja se on lähes aina väärä muoto. Projektin omistus ja pakettien reititys ovat toisiinsa liittyviä mutta eri kysymyksiä, ja hyödyllinen arkkitehtuuri säilyttää tarvitsemasi hallinnolliset rajat ja antaa samalla aiottuihin etuliitteisiin yhden harkitun polun toimistoon tai datakeskukseen. Nämä tarkistukset ratkaisevat, mitä verkkomallia todella haluat, siinä järjestyksessä, joka välttää uudelleentyön. Kukin niistä voi lopettaa keskustelun aikaisin, ja se on tarkoitus.
Projektin raja ei vaadi automaattisesti omaa tunnelia.
Tarkista, onko jaettu objekti verkko
Aloita kysymyksellä omistuksesta, ei yhteydestä: voiko keskitetty verkon omistus tukea näitä työkuormia? Jos vastaus on kyllä ja organisaatiolla on sopiva kokoonpano, isäntäprojekti omistaa VPC:n, aliverkot ja yhteyden, kun taas palveluprojektit omistavat omat sovellusresurssinsa. Yksi Cloud VPN -yhteys tässä jaetussa verkossa voi sitten palvella aiottuja työkuorman etuliitteitä, reititys- ja tietoturvakäytäntöjen mukaisesti .
Ole täsmällinen siitä, mitä liittäminen tekee. Palveluprojektin liittäminen ei yhdistä sen olemassa olevaa itsenäistä VPC:tä isäntäverkkoon eikä siirrä jokaista resurssia automaattisesti. Työkuorman liittäminen, käyttöoikeudet, osoiteavaruus ja DNS ovat kaikki osa arkkitehtuuria, eivät asetuksen seurauksia. Lue liittäminen ensin käyttöoikeusmuutoksena ja vasta sitten reititysmuutoksena, koska tiimit löytävät eron yleensä siirtymävaiheessa.
Jos keskitetty omistus ei ole mukana oleville tiimeille hyväksyttävää, pysähdy tähän ja käsittele loput peering- tai keskusmallina. Shared VPC:n pakottaminen ryhmälle, joka tarvitsee itsenäisiä verkon elinkaaria, tuottaa poliittisen ongelman, jolla on tekninen nimi.
Tarkista, voivatko itsenäiset VPC:t pysyä itsenäisinä
Peering säilyttää erilliset VPC:t, ja juuri siksi se houkuttelee tiimejä, jotka haluavat omat osoitesuunnitelmat ja oman muutoshallinnan. Kompastuskivi on, että peering ei ole transitiivinen: A-B- ja B-C-peering ei itsessään luo A-C-reititystä B:n kautta. Jos kolmen projektin on saavutettava yksi hybridikohde, tarvitset harkitun vaihtosuunnitelman, et peering-ketjua.
Hybridisaavutettavuuden jakaminen riippuu myös dokumentoidusta mukautettujen reittien vaihdosta ja aiotuista Cloud Router -ilmoituksista. Peeringin tila aktiivinen todistaa, että peering on olemassa, ei sitä, että kummankin osapuolen tärkeinä pitämät etuliitteet olisi koskaan viety. Tarkista viedyt alueet peeringin molemmilta puolilta siinä kokoonpanossa, joka viennin tekee, ja vertaa niitä osoitteisiin, joita työkuormasi todella käyttävät. Epäjohdonmukaisuus siellä on yleisin syy siihen, että peering näyttää terveeltä, kun etuliite pysyy tavoittamattomana.
Kirjoita osoitesuunnitelma ennen kaikkea muuta. Päällekkäisyyttä välttävät alueet, reitit jokaiseen aiottuun kohteeseen ja paluuilmoitukset ovat ne kolme artefaktia, joiden varassa tämä malli elää tai kuolee.
Tarkista, sopiiko keskusmalli topologiaan
Suurempaa tai eri tavoin segmentoitua suunnittelua varten Googlen Network Connectivity Center -yleiskatsaus kuvaa keskus- ja kehämallit. Lue se sen varalta, mitä nykyinen versio tukee, ei sen varalta, mitä kaavio antaa ymmärtää: mitkä VPC- ja hybridiyhdistelmät, mitkä reittiperheet ja mitkä käytännöt kukin kehätyyppi sallii.
Tarkista osoiteperhe nimenomaisesti. Useimpien oppaiden, myös tämän, suunnitteluesimerkit koskevat IPv4:ää, eikä yhdelle kehätyypille olemassa oleva ominaisuus päde automaattisesti muuttumattomana toiseen. Jos ympäristösi on kaksoispino, kysymys kuuluu mallin valintaan, ei myöhempään migraatioon.
Alla oleva taulukko on kolmen mallin yhteenveto ja kysymys, joka ratkaisee kunkin.
| 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? |
Tarkista, mitä reititys ei anna
Reittien vaihto ei ole yleinen luottamuksen myöntö. DNS-resoluutio, palomuurilupa ja sovelluksen valtuutus pysyvät omina vastuinaan, ja kunkin määrittää useimmissa organisaatioissa eri omistaja. Suunnittelu, joka olettaa saavutettavuuden tarkoittavan valtuutusta, läpäisee yhteystestinsä ja epäonnistuu tietoturvakatselmuksessa.
Vahvista myös DNS-tarina kullekin mallille, koska vyöhyke- ja edelleenlähetysjärjestelyt eroavat jaetun verkon ja peering-verkkojen välillä. Yksityiset nimet, jotka ratkeavat yhdessä projektissa, eivät seuraa reittiä toiseen.
Kirjaa päätös ja sen omistaja
Keskitä sinne, missä organisaatio haluaa jaetun verkon omistajan; pidä erilliset VPC:t siellä, missä elinkaari tai käytäntö sitä vaatii. Valitse sitten tuettu yhteysuhde ja kirjoita, minkä valitsit, kuka omistaa jaetun verkon ja mitä kukin projekti saa ilmoittaa.
Projektien laskeminen ja yhden VPN:n ostaminen kullekin ei korvaa tuota omistuspäätöstä. Se on sama päätös, myöhemmin tehty, sen toimesta, joka perii laskun ja reititystaulun.