Diversos projectes de Google Cloud, una VPN híbrida? Decidiu primer
La VPC compartida, el peerament i un centre de connectivitat responen a preguntes de propietat diferents. Tria la frontera de xarxa abans de desplegar una VPN per projecte.
Quan diversos projectes de Google Cloud necessiten accés híbrid, l'instint és una VPN per projecte, i gairebé sempre és la forma equivocada. La propietat del projecte i l'encaminament de paquets són qüestions relacionades però diferents, i l'arquitectura útil conserva les fronteres administratives que necessiteu mentre dona als prefixos previstos un camí deliberat cap a l'oficina o el centre de dades. Aquestes comprovacions decideixen quin model de xarxa voleu realment, en l'ordre que evita retreballar. Cadascuna pot acabar la discussió aviat, i aquest és el punt.
Una frontera de projecte no requereix automàticament el seu propi túnel.
Comproveu si l'objecte compartit és la xarxa
Comenceu amb una pregunta sobre la propietat, no sobre la connectivitat: pot la propietat central de la xarxa donar suport a aquestes càrregues de treball? Si la resposta és sí i l'organització té una configuració elegible, un projecte amfitrió posseeix la VPC, les subxarxes i la connectivitat, mentre que els projectes de servei posseeixen els seus recursos d'aplicació. Una connexió Cloud VPN en aquesta xarxa compartida pot llavors servir els prefixos de càrrega de treball previstos, subjecte a les polítiques d'encaminament i seguretat .
Sigueu precisos sobre què fa l'associació. Adjuntar un projecte de servei no fusiona la seva VPC independent existent amb la xarxa amfitriona, ni mou cada recurs automàticament. L'adjunció de càrregues de treball, els permisos, l'espai d'adreces i el DNS formen part de l'arquitectura, no són conseqüències de la configuració. Llegiu l'associació primer com un canvi de permisos i després com un canvi d'encaminament, perquè els equips solen descobrir la diferència durant la migració.
Si la propietat central no és acceptable per als equips implicats, atureu-vos aquí i tracteu la resta com un disseny de peerament o de centre. Forçar Shared VPC sobre un grup que necessita cicles de vida de xarxa independents produeix un problema polític amb un nom tècnic.
Comproveu si les VPC independents poden romandre independents
El peerament conserva VPC separades, i per això mateix atrau equips que volen els seus propis plans d'adreces i el seu propi control de canvis. La trampa és que el peerament no és transitiu: el peerament A-amb-B i B-amb-C no crea per si mateix encaminament A-amb-C a través de B. Si tres projectes han d'arribar a una destinació híbrida, necessiteu un pla d'intercanvi deliberat i no una cadena de peeraments.
Compartir l'abastabilitat híbrida també depèn de l'intercanvi documentat de rutes personalitzades i dels anuncis previstos de Cloud Router. Un estat de peerament actiu demostra que el peerament existeix, no que els prefixos que importen a cada costat s'hagin exportat mai. Comproveu els rangs exportats a banda i banda del peer, en la configuració que fa l'exportació, i compareu-los amb les adreces que les vostres càrregues de treball fan servir realment. Una discrepància aquí és la raó més comuna perquè un peerament sembli saludable mentre un prefix continua inaccessible.
Escriviu el pla d'adreces abans que res. Els rangs que no se solapen, les rutes cap a cada destinació prevista i els anuncis de retorn són els tres artefactes dels quals aquest model viu o mor.
Comproveu si un model de centre encaixa amb la topologia
Per a un disseny més gran o segmentat de manera diferent, la visió general de Google Network Connectivity Center descriu els models de centre i de radi. Llegiu-la pel que admet la versió actual i no pel que implica el diagrama: quines combinacions de VPC i híbrides, quines famílies de rutes i quines polítiques permet cada tipus de radi.
Comproveu la família d'adreces explícitament. Els exemples de planificació de la majoria de guies, inclosa aquesta, tracten d'IPv4, i una funció que existeix per a un tipus de radi no s'aplica automàticament sense canvis a un altre. Si la vostra infraestructura és de doble pila, aquesta pregunta pertany a l'elecció del model, no a una migració posterior.
La taula següent és el resum dels tres models i la pregunta que decideix cadascun.
| 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? |
Comproveu què no atorga l'encaminament
L'intercanvi de rutes no és una concessió global de confiança. La resolució de DNS, el permís del tallafoc i l'autorització d'aplicacions continuen sent responsabilitats pròpies, i cadascuna la configura un propietari diferent a la majoria d'organitzacions. Un disseny que assumeix que l'abastabilitat implica autorització passarà la seva prova de connectivitat i suspendrà la revisió de seguretat.
Confirmeu també la història de DNS per a cada model, perquè els arranjaments de zona i reenviament difereixen entre una xarxa compartida i xarxes amb peerament. Els noms privats que es resolen en un projecte no segueixen una ruta cap a un altre.
Registreu la decisió i el seu propietari
Centralitzeu on l'organització vol un propietari de xarxa compartit; manteniu VPC separades on ho requereixi el cicle de vida o la política. Després trieu una relació de connectivitat admesa i escriviu quina heu triat, qui posseeix la xarxa compartida i què pot anunciar cada projecte.
Comptar projectes i comprar una VPN per a cadascun no substitueix aquesta decisió de propietat. És la mateixa decisió, presa més tard, per qui hereta el compte i la taula d'encaminament.