Több Google Cloud-projekt, egy hibrid VPN? Először döntsön
A megosztott VPC, a peering és egy kapcsolódási központ különböző tulajdonosi kérdésekre válaszol. Válassza ki a hálózati határt, mielőtt projektenként egy VPN-t telepít.
Amikor több Google Cloud-projektnek hibrid hozzáférésre van szüksége, a beidegződés projektenként egy VPN, és ez szinte mindig rossz forma. A projekt tulajdonjoga és a csomagok útvonalválasztása összefüggő, de külön kérdések, és a hasznos architektúra megtartja a szükséges igazgatási határokat, miközben a szánt előtagoknak egyetlen megfontolt utat ad az irodába vagy az adatközpontba. Ezek az ellenőrzések eldöntik, valójában melyik hálózati modellt akarja, abban a sorrendben, amely elkerüli az újramunkát. Mindegyik korán lezárhatja a vitát, és ez a lényeg.
A projekt határa nem igényel automatikusan saját alagutat.
Ellenőrizze, hogy a közös objektum a hálózat-e
Kezdje a tulajdonjogra vonatkozó kérdéssel, nem a kapcsolódással: támogathatja-e a központi hálózati tulajdon ezeket a számítási feladatokat? Ha a válasz igen, és a szervezetnek megfelelő konfigurációja van, a gazdaprojekt birtokolja a VPC-t, az alhálózatokat és a kapcsolódást, míg a szolgáltatásprojektek a saját alkalmazáserőforrásaikat. Egy Cloud VPN-kapcsolat ebben a megosztott hálózatban ezután kiszolgálhatja a szánt munkaterhelés-előtagokat, az útvonalválasztási és biztonsági szabályzatok függvényében .
Legyen pontos abban, mit tesz a társítás. Egy szolgáltatásprojekt csatolása nem olvasztja be meglévő független VPC-jét a gazdahálózatba, és nem mozgat minden erőforrást automatikusan. A munkaterhelés csatolása, az engedélyek, a címterület és a DNS mind az architektúra részei, nem a beállítás következményei. A társítást először engedélyváltozásként, aztán útvonalváltozásként olvassa, mert a csapatok általában az átállás során fedezik fel a különbséget.
Ha a központi tulajdon nem elfogadható az érintett csapatoknak, álljon meg itt, és a többit peering- vagy központi tervként kezelje. A Shared VPC rákényszerítése egy független hálózati életciklusokat igénylő csoportra technikai nevű politikai problémát szül.
Ellenőrizze, hogy a független VPC-k függetlenek maradhatnak-e
A peering megőrzi a külön VPC-ket, és éppen ezért vonzza azokat a csapatokat, amelyek saját címterveket és saját változáskezelést akarnak. A csapda az, hogy a peering nem tranzitív: az A-B és B-C peering önmagában nem hoz létre A-C útvonalválasztást B-n keresztül. Ha három projektnek egy hibrid célállomást kell elérnie, megfontolt cseretervre van szüksége, nem peeringek láncolatára.
A hibrid elérhetőség megosztása a dokumentált egyéni útvonalcserétől és a szánt Cloud Router-hirdetésektől is függ. Az aktív peering állapot azt bizonyítja, hogy a peering létezik, nem azt, hogy a feleket érdeklő előtagok valaha exportálva lettek. Ellenőrizze az exportált tartományokat a peer mindkét oldalán, abban a konfigurációban, amely az exportot végzi, és hasonlítsa össze őket azokkal a címekkel, amelyeket a munkaterhelései ténylegesen használnak. Az ottani eltérés a leggyakoribb oka annak, hogy egy peering egészségesnek tűnik, miközben egy előtag elérhetetlen marad.
Írja meg a címtervet mindenek előtt. Az át nem fedő tartományok, az egyes szánt célok felé vezető útvonalak és a visszahirdetések az a három összetevő, amelyen ez a modell él vagy meghal.
Ellenőrizze, hogy a központi modell illik-e a topológiához
Nagyobb vagy másképp tagolt tervhez a Google Network Connectivity Center áttekintése a központi és küllős modelleket írja le. Azt olvassa ki belőle, amit a jelenlegi kiadás támogat, és ne azt, amit az ábra sugall: mely VPC- és hibrid kombinációkat, mely útvonalcsaládokat és milyen szabályzatokat enged meg az egyes küllőtípus.
Ellenőrizze kifejezetten a címcsaládot. A legtöbb útmutatóban, így ebben is, a tervezési példák az IPv4-re vonatkoznak, és az egyik küllőtípushoz létező funkció nem feltétlenül érvényes változatlanul a másikra. Ha a környezete kettős verem, ez a kérdés a modellválasztáshoz tartozik, nem egy későbbi migrációhoz.
Az alábbi táblázat a három modell összefoglalója és az a kérdés, amely mindegyiket eldönti.
| 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? |
Ellenőrizze, mit nem ad az útvonalválasztás
Az útvonalcsere nem általános bizalmi engedmény. A DNS-feloldás, a tűzfalengedély és az alkalmazásengedélyezés a saját felelősségük marad, és mindegyiket más tulajdonos konfigurálja a legtöbb szervezetben. Az a terv, amely feltételezi, hogy az elérhetőség engedélyezést jelent, átmegy a kapcsolódási tesztjén, és elbukik a biztonsági felülvizsgálaton.
Erősítse meg a DNS-történetet mindegyik modellnél is, mert a zóna- és továbbítási megoldások különböznek a megosztott hálózat és a peeringelt hálózatok között. Az egyik projektben feloldódó privát nevek nem követnek útvonalat egy másikba.
Rögzítse a döntést és annak tulajdonosát
Központosítson ott, ahol a szervezet közös hálózati tulajdonost akar; tartson külön VPC-ket ott, ahol az életciklus vagy a szabályzat megköveteli. Ezután válasszon támogatott kapcsolódási viszonyt, és írja le, melyiket választotta, ki birtokolja a megosztott hálózatot, és mit hirdethet az egyes projektek.
A projektek megszámolása és mindegyikhez egy VPN vásárlása nem helyettesíti ezt a tulajdonosi döntést. Ugyanaz a döntés, később meghozva, az által, aki örökli a számlát és az útválasztási táblázatot.